Platform Engineering. Integrazione. Ottimizzazione. Automazione

Il termine DevOps, derivato dalla combinazione delle parole "Development" e "Operations", rappresenta molto più di una semplice tendenza nel panorama dello sviluppo software. È un approccio metodologico e, allo stesso tempo, un insieme di strumenti progettati per rivoluzionare la collaborazione tra gli sviluppatori e gli operatori IT (amministratori di sistema). L'obiettivo principale di DevOps è quello di accelerare e ottimizzare il processo di sviluppo, velocizzando la distribuzione e la gestione di prodotti e servizi software all'interno di un'organizzazione.

L'evoluzione delle piattaforme moderne, contraddistinte da una crescente complessità e stratificazione, ha reso indispensabile l'adozione di metodologie come DevOps. Il crescente utilizzo della virtualizzazione e dei container, infatti, ha portato ad un aumento della flessibilità e della scalabilità delle infrastrutture, ma ha anche introdotto sfide nella distribuzione e gestione delle applicazioni finali.

Il DevOps si pone, dunque, l'obiettivo di affrontare queste sfide, consentendo alle organizzazioni di sfruttare appieno i vantaggi offerti dalla moderna tecnologia. La collaborazione sinergica tra sviluppatori e operatori IT permette di ridurre gli effetti negativi della complessità delle infrastrutture, offrendo una soluzione integrata per migliorare la flessibilità, la velocità e l'integrazione tra i diversi componenti del processo di sviluppo e distribuzione software.

 

GitOps e Infrastructure as Code

 

GitOps rappresenta un fondamentale principio DevOps, che pone il codice sorgente al centro di ogni operazione, fungendo da singolo punto di verità per gli ambienti di sviluppo e produzione. In questa prospettiva, ogni risorsa, che sia infrastrutturale o applicativa, viene gestita in modo dichiarativo, trattata come codice tramite il concetto di Infrastructure as Code. 

Attraverso l'utilizzo di strumenti appositi, come Ansible o Terraform, è possibile creare e aggiornare le risorse in maniera automatizzata, semplificando le operazioni e riducendo il rischio di errori derivanti da modifiche manuali. Inoltre, questa pratica favorisce una migliore Disaster Recovery e Riproducibilità degli ambienti, consentendo la replicazione o il ripristino delle configurazioni precedenti, in maniera idempotente, basandosi su configurazioni versionate e dati di backup.

L'adozione di GitOps si basa sull'utilizzo di strumenti che seguono il paradigma "as code" per la gestione delle risorse. Dalle tecnologie container, progettate per essere indipendenti dall'ambiente di destinazione e gestite tramite file di configurazione, alla gestione delle risorse Cloud Native, fino all'implementazione di procedure e automatismi per integrare l'intero ciclo di vita del software, lo sviluppatore è in grado di interagire con questi strumenti e sistemi per gestire l'intero processo, dall'inizio alla fine. Non è tanto il singolo prodotto o tecnologia utilizzata che conta, ma lo scopo e il problema che questa risolve. Di conseguenza, è comune trovare una serie di strumenti che includono:

• un repository Git per il versionamento del codice sorgente.
• Strumenti e programmi per la configurazione automatizzata delle risorse e degli ambienti a partire dal codice sorgente.
• Un ambiente virtualizzato, che possa consistere in una serie di macchine virtuali o container Docker o cluster Kubernetes, semplificato nell'ambito dei servizi cloud.
• Un sistema Agile di gestione delle attività e del team.
• Infine, un sistema di pipeline per integrare e automatizzare l'intero processo, dalla creazione dell'infrastruttura di base al rilascio del software in produzione e alla gestione dei ticket aziendali.
   

 

Platform engineering: la Metodologia

Se il DevOps può essere visto come l’integrazione e automazione delle diverse fasi della gestione del ciclo di vita di un’applicazione o servizio, il Platform Engineering è una sua evoluzione. Questa disciplina mira a semplificare ulteriormente la vita dello sviluppatore, fornendo tutti gli strumenti necessari per gestire in modo autonomo il ciclo di vita di un'applicazione, senza la necessità di coinvolgere direttamente il team Operations.

Questa nuova metodologia, emersa in risposta alla crescente complessità dell'architettura delle moderne piattaforme - complessità in parte aggravata dall'adozione delle pratiche DevOps - agevola l’attività degli sviluppatori e di quanti, pur non essendo esperti, devono operare su una serie di servizi che esulano dal loro campo di competenza o non sono pertinenti allo sviluppo del software.

L'idea di base è quella di fornire al team di sviluppo uno o più strumenti raggruppati sotto il nome di Internal Developer Platform. Questo permette loro di gestire il proprio software in tutte le fasi del ciclo di vita, con caratteristiche e funzionalità ben precise:

• Completa autonomia
• Creazione e gestione degli ambienti, delle risorse (cluster, database, ecc.) e dei test in modalità self-service
• Monitoraggio a 360 gradi delle proprie applicazioni
• La piattaforma stessa guida il team di sviluppo, imponendo il rispetto delle Best Practice e delle Policy aziendali, anche in relazione all'infrastruttura sottostante.

Questa piattaforma rappresenta un vero e proprio prodotto interno dell'azienda, solitamente sviluppato e gestito da un team dedicato allo scopo, chiamato Platform Team. Il team si impegna a creare una piattaforma che offra un'esperienza di sviluppo ottimale, priva di frizioni, che funga da layer intermedio, riducendo la conoscenza necessaria per interagire con l'infrastruttura sottostante, che, con tecnologie come Kubernetes e la virtualizzazione, tende ad essere sempre più complessa. Inoltre, si favorisce un onboarding più rapido dei nuovi membri del team di sviluppo, consentendo a quest'ultimo di concentrarsi esclusivamente sullo sviluppo del software e di migliorarne la qualità e la velocità di rilascio.

Sono quindi chiari i benefici che questo sistema può portare. Secondo Gartner®, infatti, «(...) entro il 2026, l’80% delle organizzazioni software si doterà di Platform Teams», ovvero di team dedicati alla costruzione e manutenzione di tale piattaforma digitale.

Questo nuovo paradigma non deve per forza essere visto come un sostituto del DevOps o di altre metodologie, ma può essere usato in combinazione con essi. 

Molto spesso, infatti, è proprio lo stesso Team Operations che insieme ad un Product Manager e a dei Site Reliability Engineers compongono il nuovo Platform Team, che tramite l’utilizzo degli stessi principi e tecnologie descritti nella sezione dedicata al DevOps permettono la costruzione e gestione di questa piattaforma dedicata agli sviluppatori.

 

Internal Developer Platform

Il Platform Engineering comprende, nel migliore dei casi, anche un portale dedicato agli sviluppatori, attraverso cui gestire tutte le risorse da un’unica interfaccia, nel qual caso si ha un Hub centrale, costruito sulla base di alcuni principi:

• la possibilità di gestire le configurazioni delle applicazioni, in maniera dinamica, scalabile e resiliente.
• La possibilità di orchestrare l’infrastruttura, in modo dinamico e dipendente dal contesto.
• La possibilità di creare nuovi ambienti on demand.
• La possibilità di implementare una Pipeline di Continuous Integration e Continuous Deployment.
• La possibilità di gestire in modo scalabile gli accessi RBAC (Role-Based).

Questo si traduce in uno strumento capace di collegare ogni componente infrastrutturale adibito ad una particolare funzione sotto un unico tetto, in cui i dettagli architetturali e implementativi vengono nascosti all’utilizzatore finale, lo sviluppatore.

Un esempio di Internal Developer Platform lo si ottiene con Backstage, che si autodefinisce «(...) an open source framework for building developer portals». Con Backstage è possibile costruire il proprio portale, aggiungendo una serie di plugin che vanno ad interfacciarsi con le diverse soluzioni infrastrutturali sottostanti (ad esempio una pagina che mostri le dashboard di monitoraggio più utili di Grafana, o la lista di Job CI/CD eseguiti di recente, o una serie di template che permettano di creare rapidamente nuovi ambienti, database o cluster kubernetes, interfacciandosi con un determinato Cloud Provide). In questo caso sta al Platform Team mantenere questi plugin o integrazioni.

Il portale possa essere uno strumento molto utile al fine di semplificare la vita al team di sviluppo, non è un componente essenziale per costruire una soluzione di Platform Engineering, infatti è sufficiente avere una serie di strumenti, anche separati, che se usati permettano di fare le stesse cose sempre restando “staccati” e “astratti” dall’infrastruttura sottostante.

Infrastruttura e architettura

Il principale strumento che il team di sviluppo utilizza per gestire le proprie applicazioni è il portale IDP - in alternativa, quando questa manca, deve accedere agli stessi strumenti impiegati dagli sviluppatori - ma per funzionare al meglio, e fornire tutte le funzionalità necessarie al ciclo di vita di un software, l’intera architettura sottostante, gestita dal Platform Team, deve comprendere numerose risorse eterogenee, integrate tra loro. Sono gli stessi elementi della metodologia DevOps/GitOps, ma unificati o comunque integrati tra di loro. Con questa configurazione, che potremmo definire developer centric, tutto diventa accessibile anche da chi non conosce o non ha la possibilità di intervenire nell’infrastruttura reale.

Un’architettura pensata per una soluzione più o meno completa di Platform Engineering potrebbe comprendere diversi strumenti.

• Sistema di Ticket e Attività da cui partire per la gestione del ciclo di vita del progetto e collegato direttamente con i repository di codice.
• Repository Git per il codice sorgente creato automaticamente in base al progetto che il Team di Sviluppo deve gestire e possibilmente partendo da dei template.
• IDE di sviluppo interfacciato con i repository di codice.
• Moduli e Template già configurati secondo i Golden Path prestabiliti dall’azienda per le possibili risorse necessarie alle applicazioni (esempio: database, cluster kubernetes, siti web e frontend, backend, etc…).
• Ambienti Virtualizzati dedicati o condivisi tra i Team e separati in diversi “namespace” automaticamente deployati o configurati on demand tramite Pipeline.
• Sistemi di backup automatici preconfigurati.
• Registry per container, artefatti, librerie e pacchetti vari.
• Strumenti di Observability (Metriche, Logging e Tracing) focalizzati sulle applicazioni.
• Uno o più sistemi di Pipeline e CI/CD per la gestione automatica di tutte le risorse infrastrutturali e applicative (tramite “IaC”) sfruttando la logica a moduli e template preconfigurati secondo i corretti standard e policy aziendali.
• Sistema condiviso di Documentazione, possibilmente legato al codice sorgente.