DevOps e Cloud Native sono degli approcci nello sviluppo software e, come tali, possono essere raggiunti con diversi strumenti e strategie applicative. Rappresentano quindi degli obiettivi comuni, dei metodi, intenti a risolvere problematiche specifiche.
Nel caso di Devops, questo ha come obiettivo l’integrazione tra il mondo dello sviluppo e quello della parte di operation, tramite l’ottimizzazione del ciclo di sviluppo a 360 gradi, introducendo pratiche di continuos integration, continuous delivery e continuos deployment.
Cloud Native si riferisce invece alla parte di progettazione applicativa ed infrastrutturale, rendendo la modularità e la scalabilità delle caratteristiche fondamentali dei progetti, grazie a tecnologie come i container che permettono di dividere la logica e l’effort computazionale in tanti piccoli componenti che interagiscono tra loro.
Come mai questi due termini sono così importanti e qual è la loro storia?
Nei primi anni 2000 il mercato era sempre più complesso e le aziende avevano necessità di ottimizzare il proprio lavoro e tenere i costi sotto controllo, per restare competitivi in una scena che si manifestava particolarmente aggressiva, con fette di mercato sempre più ristrette e deboli da mantenere.
Da un punto di vista cronologico sicuramente una data chiave nell’avvio della definizione di questi due concetti è il 2006, quando Amazon lancia AWS, la prima vera e propria piattaforma cloud esistente.
Di lì a poco venne coniato il termine DevOps: è il 2008, Patrick Debois ed Andrew Shafer lo nominano durante il talk “Agile Infrastructure” della “Agile Conference”.
Nel frattempo, nel 2009 Patrick Debois organizza la prima conferenza dedicata a questo nuovo approccio, la DevOpsDays. Questo segna anche l’inizio della community e di un vero e proprio movimento. A distanza di un anno, aziende del calibro di Netflix, Amazon e Google iniziarono ad introdurre le pratiche DevOps, influenzando inevitabilmente il resto dell’industria dello sviluppo software.
L’unione di questi due mondi, DevOps e Cloud Native, rimasti separati per anni, crea nuove opportunità ed accelera la ricerca di nuovi paradigmi.
L’evoluzione dei concetti: da termini a nuovi paradigmi
La pressione dei costi di esercizio e la necessità di essere sempre più scalabili ed allo stesso tempo meno legati al problema delle dipendenze crea il terreno ideale per la nascita della metodologia “Twelve-Factor App”.
Sul sito 12factor.net è possibile anche oggi trovare i riferimenti all’utilizzo di formati dichiarativi per favorire l’inserimento di nuovi sviluppatori, l’importanza della portabilità, il supporto a piattaforme cloud, la riduzione delle differenze tra i diversi ambienti ed ovviamente la possibilità di fare scaling dell’applicativo.
Il 2014 è stato l’anno di introduzione di una piattaforma estremamente importante perché si rivelerà fondamentale nell’affrontare queste tematiche: Kubernetes. Il suo strato di API, la sua naturale predisposizione al monitoraggio e alla scalabilità, la possibilità di installarla su ambienti diversi e l’utilizzo intrinseco di container hanno reso la sua adozione inevitabile. A distanza di 10 anni rappresenta ancora di più l’ideale di piattaforma da implementare nello sviluppo moderno di applicativi.
Il 2015 rappresenta un po’ il traguardo di questo percorso: viene fondata la Cloud Native Foundation e questo avvenimento chiarisce che quanto avvenuto fino a quel momento non era solo una moda tecnologica passeggera, ma il suo destino era rimanere ed evolvere.
Cloud Native e DevOps, due mondi uniti
Il percorso visto fin qui chiarisce anche come mai questi termini vengono spesso usati vicini e perché siano oggi difficilmente separabili: si può fare DevOps su infrastruttura legacy, ma non tutto sarà automatizzabile in assenza di API che controllino network, storage e capacità computazionale; allo stesso modo è possibile usare i vari portali per gestire a mano le infrastrutture in cloud, ma la complessità data dal maggior numero di livelli di astrazione e dall’aumento dei diversi componenti in gioco rende tutto questo estremamente difficoltoso e sopratutto incline a favorire gli errori.
Ma quali sono le sfide che limitano le aziende che ancora non hanno sposato queste tecnologie a farlo?
Il debito tecnologico
È molto facile partire da zero su un nuovo progetto ed essere diligenti o moderni, ma il discorso è diverso se ci troviamo a mantenere e continuare a sviluppare un progetto datato, fatto con linguaggi non moderni e con programmi monolitici.
Il lavoro da fare in una situazione di questo tipo è molto e comporta lo scorporamento di funzioni e dati dal core principale per creare tutti quelli che saranno un domani i nuovi microservizi, con pesanti modifiche sia al codice che alle basi dati coinvolte. Allo stesso modo c’è un problema di competenza: l’introduzione di API e microservizi porta nuove sfide, in alcuni ambienti mai affrontate, che richiedono competenze specifiche e la conoscenza di ambiti più ampi rispetto al passato, andando appunto a fondere temi di sviluppo e temi di infrastruttura.
La formazione continua, la creazione di team interni di competenza verticale, l’utilizzo di template condivisi, l’adozione delle nuove AI generative a supporto dello sviluppo: queste le strategie che possono facilitare un ammodernamento inevitabile e necessario, proprio perché dalla bontà tecnologica delle soluzioni, metodologie e strategie adottate, dipenderà un domani la capacità di competere nel proprio mercato, considerando che ormai il software è presente in praticamente qualsiasi ambito e mercato.
Cristiano Casella – Head of Platform Engineering @Seacom
Seacom – Società Benefit appartenente al gruppo ITWay e co – fondatore di RIOS (Rete Italiana Open Source), è un’azienda specializzata in consulenza e formazione su prodotti open source per aziende di livello Enterprise, enti e pubbliche amministrazioni.
Scopri di più su Seacom su: https://seacom.it
