Applicare la modalità ‘as-a-service’ anche al modello di sviluppo software DevOps può rappresentare una strada decisiva per velocizzare in maniera sostanziale le iniziative in questo spazio dell’IT e abbattere gli ostacoli che ancora frenano l’instaurazione di efficienti processi d’integrazione continua e rilascio continuo del codice (CI/CD) all’interno dell’intera organizzazione aziendale. In effetti, proprio l’infrastruttura DevOps, o meglio la sua creazione e gestione, rischia di trasformarsi nel collo di bottiglia capace di rallentare l’adozione di questo stesso paradigma di sviluppo: e il perché DevOps as-a-service possa essere in grado di ovviare a questo problema sta già nella sua definizione. Si tratta di un modello di fornitura dei tool software per facilitare la collaborazione tra team di sviluppo e team delle IT operation, in cui è un provider di servizi a collezionare, integrare e far operare assieme i vari strumenti che servono a compiere il ciclo DevOps nella sua interezza. Si tratta dunque di servizi gestiti di infrastruttura DevOps, che costituiscono un approccio alternativo alla complessità di gestione del modello ‘best-of-breed’ on-premise, in cui sono i team DevOps ad occuparsi direttamente del reperimento e dell’integrazione delle catene di tool necessari per svolgere tutto il processo.
Una complessità che diventa sempre più difficile da sostenere. Il 2018, ha predetto Forrester, sarà l’anno dell’ ‘enterprise DevOps’: i dati della società di ricerche confermano che il 50% delle organizzazioni sta implementando il modello DevOps: ma le domande e discussioni degli utenti non riguardano più tanto il significato del termine, quanto le modalità d’implementazione di DevOps su larga scala.
Ora i reparti I&O (infrastructure & operation) devono comprendere come realizzare strategie di successo, nel clima di crescente pressione verso la fornitura accelerata di applicazioni e servizi, senza dover aggiungere ulteriori risorse e personale. Per preparare la propria organizzazione a passare dagli esperimenti pilota e ‘proof of concept’ all’enterprise DevOps, avverte Forrester, il reparto I&O deve focalizzarsi su alcune aree chiave, e una di queste è l’automazione. I ‘silos’ di automazione sono stati, e per molte organizzazioni continuano a esserlo, una barriera al successo. Essere in grado di trasferire l’automazione a livello end-to-end nell’intero ciclo di vita dello sviluppo software DevOps, è fondamentale per il successo di queste strategie, sottolinea Forrester, specialmente quando esse vengono declinate su larga scala.
Eliminare la complessità dell’infrastruttura DevOps
La diffusione della filosofia e metodologia Agile/DevOps risiede nella sua capacità di fondere, e far cooperare in maniera sistematica ed efficiente tra loro, team di sviluppo software e IT operation, attraverso un ambiente comune, in cui si concentrano competenze ed esperienze per usare strumenti software che permettono di automatizzare le attività CI/CD. Spesso però la realtà è che i team di lavoro sono costretti a padroneggiare un ampio numero di differenti strumenti DevOps, basati su diverse tecnologie. Come già abbiamo avuto modo di documentare, il mercato dei tool risulta ancora frammentato, e in vari casi gli sviluppatori devono eseguire integrazioni ad hoc dei toolset, per riuscire a coprire tutte le funzionalità richieste per gestire in modo completo il ciclo di sviluppo CI/CD. Senza poi considerare che questi tool si evolvono in modo molto rapido e dinamico, a livello sia tecnologico sia di funzionalità: si pensi solo ai container o ai microservizi, e restare sempre aggiornati su tutto non è facile. Oltre alla necessità d’indirizzare il cambiamento culturale e di creare all’interno dell’impresa le metodologie pratiche d’implementazione di DevOps (a seconda dei casi formando le risorse esistenti, assumendo profili esperti nel settore, o avvalendosi di consulenti), la costruzione e amministrazione dell’infrastruttura DevOps è un punto molto dolente che preoccupa i CIO, specie in quelle imprese che di questo modello non fanno il proprio core business.
Servizi gestiti DevOps: quali sono i benefici
Di fronte a tutta questa complessità occorre dunque chiedersi se sia proprio il caso di costruire e mantenere l’infrastruttura DevOps internamente, oppure se forse sia meglio esternalizzarla, avendo la consapevolezza che, nel primo caso, non sarà possibile ottenere risultati di business tangibili fino a che l’infrastruttura DevOps non sarà completamente operativa, lungo l’intero ciclo di sviluppo CI/CD. Scegliendo un servizio DevOps gestito, il vantaggio chiave ottenibile è che ci si potrà concentrare sullo sviluppo dell’applicazione, e che tutta la creazione dell’infrastruttura e la gestione operativa degli strumenti DevOps sarà a carico del provider di servizi DevOps. Sarà quindi quest’ultimo ad amministrare le attività di installazione, aggiornamento, configurazione degli stack di tool; il backup e restore di database e dati; il controllo delle prestazioni; la verifica dei requisiti di conformità con i principi di sicurezza. Sempre il provider di servizi DevOps dovrà occuparsi, in prima persona o tramite il supporto di altri provider, ad esempio AWS (Amazon Web Services) o GCP (Google Cloud Platform), anche della gestione operativa di tutta l’infrastruttura IT sottostante, quindi dell’amministrazione delle risorse di elaborazione, storage e networking di volta in volta richieste per il completamento del processo. In aggiunta, diversi provider possono anche fornire servizi di consulenza, indirizzati ad affrontare i cambiamenti culturali e nei processi di lavoro che l’adozione della filosofia DevOps comporta.
