Di Erica Langhi, EMEA Senior Solutions Architect, Red Hat
Implementata in modo efficace, una strategia di sviluppo delle app cloud-native può fornire un vantaggio competitivo significativo per le organizzazioni. Una strategia cloud-native può velocizzare lo sviluppo delle app, renderle più flessibili in base alle necessità aziendali, e fornire alle app stesse la scalabilità necessaria per soddisfare qualsiasi richiesta senza dover cambiare eccessivamente l’infrastruttura.
I container sono parte integrante di questa strategia, in quanto abilitano l’automazione avanzata, il vero valore aggiunto delle piattaforme cloud. Di conseguenza, sfruttare appieno il potenziale dei container è una delle chiavi per una strategia cloud-native ben implementata. Per fare questo, la scelta della piattaforma ideale è essenziale. Ma come è possibile scegliere quella giusta?
Il sistema operativo conta
Un errore da evitare quando si affronta la tematica container è scegliere il sistema operativo sbagliato. Forse anche in misura maggiore rispetto agli ambienti “tradizionali”, il sistema operativo scelto condiziona molto la soluzione finale. Nonostante sia possibile eseguire container su qualsiasi sistema operativo, Linux è la scelta predominante.
Ci sono diverse ragioni per cui, di solito, i container vengono eseguiti su un host Linux. I container sfruttano diverse caratteristiche tipiche di Linux come i gruppi di controllo (cgroups), i namespaces e SELinux per eseguire le applicazioni al loro interno. Inoltre, Kubernetes è stato creato usando concetti di base di Linux e utilizza anche tool di Linux e API per gestire i container.
Tutto questo significa che, per un uso efficiente delle risorse di sistema e del tempo di sviluppo delle applicazioni, la scelta del sistema operativo per i container non può che ricadere su Linux.
Oltre Kubernetes
Un tema che viene spesso trascurato quando si discute di container è il ruolo di Kubernetes. Il rischio è di considerare Kubernetes semplicemente come una piattaforma su cui vengono eseguiti container. Una descrizione più accurata di Kubernetes è invece un insieme di API e utility per l’orchestrazione e la gestione delle risorse. Tuttavia, questo non fornisce tutto ciò di cui si ha bisogno per una piattaforma container.
Una piattaforma container completa richiede anche un registry, strumenti per il networking, lo storage, logging e monitoring. La piattaforma ha bisogno inoltre di un sistema operativo su cui operare e di un modo per implementare le tecniche di Continuous Integration/Continuous Delivery (CI/CD).
Sulla base delle necessità aziendali, è possibile sia creare tool personalizzati d’orchestrazione che investire in un framework commerciale. L’adozione di una piattaforma commerciale può far risparmiare molto tempo e risorse che altrimenti sarebbero state investite nello sviluppo e nella manutenzione della piattaforma stessa. È anche un approccio più sicuro, in quanto una soluzione commerciale ha già svolto il lavoro, incredibilmente complesso, di una corretta installazione e configurazione della piattaforma.
I framework commerciali possono anche garantire ad un’organizzazione funzionalità immediatamente utilizzabili, che non richiedono configurazioni aggiuntive. Una delle caratteristiche disponibili più utili è quella del cosiddetto “agnosticismo del cloud” che consente alla piattaforma container di operare allo stesso modo e fornire la stessa esperienza su differenti cloud provider.
Le 4 C delle piattaforme container
Ogni azienda ha esigenze diverse. Ciò significa che la piattaforma container ideale non è sempre la stessa per realtà differenti. Per scegliere la migliore opzione si possono considerare le cosiddette 4 C.
La prima C è il codice: verificare il tipo e il livello di partecipazione al codice del progetto che il fornitore sta facendo. La seconda è il cliente: chiedersi se ci sono già clienti reali che utilizzano la piattaforma. La terza C è il cloud stesso: individuare dove gira la piattaforma e su quali fornitori di cloud è possibile utilizzarla. E infine, si esamina quanto sia completa la piattaforma, e se fornisce un portafoglio di prodotti e soluzioni che si adattano alle esigenze di tutto il team (sviluppatori e amministratori), fornendo anche la scalabilità richiesta.
Gli altri elementi della strategia cloud-native
Un elemento che si rischia di dimenticare in una strategia cloud-native è che i container, pur essendo fondamentali, sono solo un elemento del modello. Ci sono altre tre componenti altrettanto importanti.
La prima è l’adozione di un’architettura service based, in cui le componenti di business che possono essere considerate autonome sono separate in moduli che possono essere facilmente aggiornati, sostituiti e testati. La seconda è legata all’automazione DevOps, che consente ai gruppi di sviluppo e di gestione di lavorare con processi e modalità collaborativi e unificati. L’ultima riguarda le comunicazioni basate su API, che vedono i processi dialogare tra loro in rete attraverso interfacce pulite e basate su contratti definiti.
Il modo in cui si va a implementare la sicurezza in ciascuno di questi elementi può influenzare il funzionamento della strategia globale cloud-native. Ciò significa che, piuttosto che considerare questi componenti separatamente, una strategia cloud-native di successo considera i container, l’architettura service based, DevOps e la comunicazione API e il modo in cui interagiscono.
Se una piattaforma container funziona bene di per sé, ma ostacola qualche altra parte della formula cloud-native dell’organizzazione, allora è necessario fermarsi a riconsiderare la scelta iniziale.
Verso il futuro del Cloud-Native
Questo porta ad un’ultima riflessione che vale anche per la scelta di una piattaforma container, e per tutte le altre parti dell’equazione cloud-native: la strategia è pronta per il futuro?
Scegliere la strada di un approccio cloud-native non è una decisione una tantum. È un processo che enfatizza l’iterazione e il cambiamento costante. Parte di questo processo consiste nell’assicurarsi che la strategia cloud-native tenga conto degli sviluppi attuali e futuri e prepari il team IT a nuove sfide. Significa anche incoraggiare il team a sfidare costantemente sé stesso sviluppando e ripensando le proprie competenze.
Un esempio è Quarkus che permette agli sviluppatori Java di continuare a lavorare utilizzando il linguaggio di cui sono esperti, ma di ripensare le loro competenze nello spazio cloud-native. Quarkus è ottimizzato per ambienti container grazie alla sua elevata efficienza di runtime e di utilizzo della memoria. Tenere gli occhi aperti per nuovi strumenti e nuove tecnologie non significa solo assicurarsi di gestire la migliore piattaforma di container possibile, ma è vitale per l’intera strategia cloud-native.
