Capace di sperimentare e implementare in prima battuta nuove metodologie prima di altri settori, nonostante apportare cambiamenti all’interno di questo sistema, altamente regolato e dalle applicazioni particolarmente interconnesse, possa essere complesso.
Come si stanno comportando dunque banche, assicurazioni e società finanziarie rispetto alle soluzioni Open Source e alle metodologie DevOps (ossia l’integrazione tra la fase di Sviluppo e quella di Operations), entrambe capaci di dare adeguato supporto a quell’obiettivo di velocità che i nuovi scenari competitivi richiedono?
I legislatori del settore finanziario, i manager che si occupano di regolamentazione e compliance, i risk manager, e gli InfoSec manager fanno emergere preoccupazioni sulla possibilità che le linee di business e lo sviluppo possano porre come prioritaria la velocità del delivery a discapito della sicurezza e dell’affidabilità delle applicazioni.
In realtà l’adozione di pratiche DevOps come Continuous Delivery, Continuous Integration e una migliore collaborazione tra development e operations significa ridurre i rischi tecnici e operativi, incrementare l’efficienza e la trasparenza, non solo accelerare il time-to-market. Visto da questa prospettiva il valore del DevOps è chiaro: gestire i cambiamenti IT riducendo il tempo di delivery, i costi operativi, e i rischi, senza trascurare la conformità normativa. In Italia infatti si stima che il 59% delle aziende di credito punta ad avviare strategie di collaborazione e integrazione fra sviluppatori e team di operations.
- Eliminazione dei processi manuali e dei colli di bottiglia
- Riduzione fino all’85% di interruzioni non pianificate durante le operazioni di deployment
- Riduzione dell’80% dei costi operativi per il release management
- Riduzione fino al 90% del tempo necessario a verificare se il codice corretto è stato messo in produzione
- Deploy semplificato di change bancarie in diversi environment e in differenti Paesi
- Incremento del 15% della produttività dei team di sviluppo e dei DBA
- Monitoraggio completo dei componenti Open Source all’interno dell’applicazione
- Analisi dell’intera supplychain del software e individuazione di errori e vulnerabilità note
Il box accanto riporta alcune delle ragioni principali che stanno portando all’adozione su larga scala di pratiche agili e DevOps, seguendo le orme di chi già lo ha fatto. Il DevOps favorisce l’automazione, e l’automazione a sua volta riduce drasticamente la possibilità di errori umani.
E qui entrano in gioco le tecnologie: non trattandosi di un singolo tool o piattaforma che permette di accenderlo o spegnerlo, il DevOps si raggiunge solo attraverso strumenti capaci di garantire l’implementazione dei nuovi processi di cui tanto si parla.
Si tratta dunque di usare soluzioni automatizzate di configuration management, di creare pipeline di Continuous Integration e di Continuous Delivery, di automatizzare il deploy con i container software, di anticipare i controlli di sicurezza e di qualità del software al momento dello sviluppo e codifica, e di fare affidamento su tool di release management, per la completa conoscenza e revisione necessari alla gestione e al controllo dell’intero ciclo di vita di sviluppo.
Il software open source non può che rappresentare un valido alleato di un settore in cui efficienza, innovazione e continuità operativa sono un must. L’open source negli ultimi anni è maturato ed è oggi adatto a essere utilizzato anche in ambienti di produzione e in progetti complessi, anche grazie alle soluzioni commerciali pensate per i clienti enterprise, come quelle di Jenkins Enterprise diCloudBees.
Il software open source è preso sempre più in considerazione, come dimostra l’investimento di 30 milioni di dollari da parte di Goldman Sachs, la cui divisione tecnologica fa sempre più uso di librerie open source.
Purtroppo il vantaggio nell’adottare le librerie open source è controbilanciato dal fatto che con esso vengono ereditati anche problemi di qualità, vulnerabilità di sicurezza e intrinseche restrizioni di utilizzo. Dall’analisi di Sonatype, gestore del Maven Central Repository, risulta che un download ogni 16 contiene almeno una vulnerabilità di sicurezza conosciuta e ogni giorno vengono segnalate 50 nuove vulnerabilità critiche. Ma anche a questo proposito la soluzione esiste.