Creare, gestire e provisionare un’infrastruttura Cloud è uno dei principali effort di un Cloud Provider, ed essere in grado di automatizzare tale processo può far risparmiare tempo e denaro.
Per farlo, ci sono due diverse strade o approcci: DevOps e Platform Engineer.
Per chi non avesse ben chiara la differenza:
- Con DevOps mi riferisco ad un insieme di pratiche e strumenti utili a migliorare la capacità di organizzazione e fornire servizi e applicazioni IT con una velocità maggiore rispetto ai processi di sviluppo tradizionali.
Con tale approccio il Team di sviluppo e il Team operational possono lavorare insieme in modo efficace e continuativo durante l’intero ciclo di vita del software, dalla sua fase di sviluppo passando per i test, alla distribuzione fino alle operazioni di manutenzione e aggiornamento. - Con Platform Engineer invece, mi riferisco ad un approccio “nuovo” che intende mantenere separato tutto ciò che è legato al mondo Dev da ciò che, invece, è relativo all’operatività e l’infrastruttura.
L'obiettivo è scindere ciò che la figura del DevOps unisce e consentire alla figura dello sviluppatore di specializzarsi maggiormente, senza conoscere le caratteristiche relative all’operatività.
Dall’ultimo KubeCon North America ho avuto la conferma di quanto gli strumenti DevOps oriented siano sempre più distanti dagli strumenti Platform Engineer oriented, e questi ultimi stanno via via attirando l’attenzione della community Cloud Native.
Per approfondire questi ed ulteriori argomenti relativi al mondo Cloud Native emersi a Detroit ad ottobre scorso, ti invito a leggere KubeCon North America 2022: Highlights.
Tornando a noi, in questo articolo il mio intento è quello di porre il focus su Terraform e Crossplane, due strumenti legati all’infrastruttura e ai suoi elementi, uno riconducibile all'approccio DevOps e l’altro più Platform Engineer Oriented con potenzialità e funzionalità differenti.
Premetto che, dietro ad entrambi, c’è un mondo da studiare e conoscere, e prima di andare ad evidenziare le differenze, preferisco approfondire ciò che li accumuna:
- Entrambi consentono di modellare l’infrastruttura IT attraverso l’approccio dichiarativo;
- Entrambi supportano la gestione di una miriade di infrastrutture diverse e di software utilizzando plug-in e provider;
- Entrambi sono strumenti open source con community forti.
Detto ciò, passiamo alle differenze tra i due.
Terraform per Infrastructure as a Code
Partiamo con Terraform: il tool di Hashicorp per l' IaaC (Infrastructure-as-a-Code).
Può essere utilizzato per la creazione automatica di qualsiasi servizio cloud, inclusi reti, servizi, firewall, database etc.. Tra le sue potenzialità risalta sicuramente il fatto che Terraform non sia legato a nessun particolare Cloud Provider e consente strategie multicloud e migrazioni facilitate.
Il principale vantaggio di utilizzare Terraform è rappresentato dalla possibilità di gestire qualsiasi infrastruttura con filosofia DevOps. Basandosi su un approccio dichiarativo, in cui si descrive l’intera infrastruttura in una serie di file di testo, Terraform esegue le azioni necessarie che porteranno al deploy di ciascun elemento descritto, senza ulteriori preoccupazioni. In questo modo, l’intera infrastruttura è già documentata e soprattutto replicabile in qualsiasi momento. Tale logica si contrappone al modello imperativo in cui, in precedenza, ogni componente andava installato e configurato a mano, lasciando ampio spazio ad errori e all’impossibilità di avere un ambiente controllato.
Semplificando, Terraform permette di scrivere un file in cui il team DevOps dichiara quali sono le esigenze di risorse infrastrutturali, ad esempio 3 istanze Public Cloud su provider CloudFire con 4vCPU e 8GB di RAM e 50GB di Scalable Storage ciascuna. A sua volta Terraform procede al provisioning delle istanze utilizzando le API del servizio Public Cloud richiesto.
Una volta concluso le operazioni, e portato il sistema allo stato desiderato (ovvero quello dichiarato nel file), Terraform salva lo stato di tali risorse.
Quest'ultimo processo, ovvero salvare lo stato delle risorse appena provisionate, diventa utile nel caso in cui le esigenze infrastrutturali dovessero cambiare. In questo modo se, ad esempio, si avesse bisogno di aumentare a 4 il numero di istanze, dichiarandolo nel file, Terraform provvederebbe a creare solo la quarta istanza, leggendo lo stato delle altre 3 istanze precedentemente provisionate. Viceversa, se le istanze dovessero venir modificate manualmente, usando la dashboard del servizio Public Cloud, Terraform sarebbe in grado, una volta eseguito, di riportare lo stato dell’ infrastruttura allo stato dichiarato nel file di configurazione, modificando e/o eliminando le risorse create esternamente.
Come in ogni strumento esistono vantaggi e svantaggi:
- Un vantaggio sicuramente è che finalmente l'infrastruttura diventa un insieme di risorse che possono essere provisionate sempre nello stesso modo, come fossero cloni, e che esiste uno stato associato a tali risorse;
- Uno svantaggio è legato al fatto che Terraform, se non eseguito manualmente, non è a conoscenza "in diretta" dello stato delle risorse o delle modifiche apportate al file di configurazione dell’ infrastruttura. Ciò significa che occorre eseguire Terraform periodicamente per assicurarsi l’allineamento tra lo stato desiderato e le risorse effettivamente in esecuzione.
- Un altro “difetto” seppur relativo, è che Terraform utilizza un proprio linguaggio per scrivere i file di configurazione, dal nome HCL, che obbliga l’utente ad impararlo.
- Per ultimo, Terraform è uno strumento nato per dichiarare lo stato finale desiderato delle risorse e si presta poco ad essere utilizzato come strumento per generare template o per gestire passaggi stato intermedi.
Crossplane per control plane cloud native
Crossplane, progetto nella fase Incubating nella CNCF Landscape, amplia invece il concetto di IaaS utilizzando il motore di riconciliazione di Kubernetes in modo da verificare continuamente lo stato desiderato, dichiarato nel file configurazione dell’ infrastruttura, confrontandolo con lo stato attuale ed eseguendo in totale autonomia le azioni necessarie alla riconciliazione delle risorse.
La peculiarità di Crossplane è proprio questa, estende le funzionalità di Kubernetes applicandole a scenari differenti dalle risorse tipiche di Kubernetes quali POD, Services, etc.. Mettendo a disposizione dei developers risorse infrastrutturali “pacchettizzate” dal reparto Operational.
Ovviamente non è tutto oro ciò che luccica, anche Crossplane ha dei difetti. Forte di una community molto estesa, mette a disposizione integrazioni per molte risorse, ma ovviamente la copertura non è totale e capita di dover scrivere da soli l’integrazione per particolari servizi. Va anche detto che Crossplane può utilizzare Terraform come tramite per l’ esecuzione delle azioni, particolarità che lo rende adatto ad essere integrato in modo graduale in infrastrutture che già utilizzano Terraform.
Uno strumento esclude l'altro?
In conclusione, come dicevo all’inizio, Terraform è più DevOps oriented ♾️ , si presta quindi bene ad ambienti in cui i Developers sono anche in grado di gestire l’infrastruttura nel suo complesso. Crossplane, di contro, è più Platform Engineer oriented ☸️, il che significa che i Developers potranno istanziare parti dell’ infrastruttura come fossero semplici POD o altri componenti di Kubernetes. In questo modo il team Operational metterà a disposizione in modo controllato pool di risorse che potranno essere provisionate o modificate senza che ci sia il pericolo di effettuare modifiche distruttive a parti di infrastruttura sensibili.
Ciò non toglie che i due strumenti possano essere utilizzati insieme 💥 per orchestrare l’infrastruttura IT di un’organizzazione, gestendo in modo meno automatico parti sensibili utilizzando Terraform e rendendo disponibili pool di risorse in modo self-service ai differenti reparti con Crossplane.
Spero ti averti fornito con questo articolo una buona panoramica di Terraform e Crossplane; considera che il mondo DevOps e Platform Engineer non finisce qui 👀 , anzi, in ambito infrastrutturale esistono altri strumenti quali FluxCD e Argo CD con diverse caratteristiche, a cui il Team CloudFire sta dedicando tempo e studio e che approfondiremo insieme più avanti! ☁️🔥
