Rischio vs. ricompensa: una guida alla comprensione dei contenitori software

Quelli di noi che sono abbastanza grandi possono ricordare un giorno in cui il software veniva distribuito principalmente da supporti fisici. La diffusione di Internet a banda larga e degli smartphone ci ha portato all'era del servizio Web, software ospitato nel cloud a cui accedono i client degli utenti come browser e app.

Non molto tempo fa, le applicazioni web venivano eseguite direttamente su macchine fisiche in data center privati. Per facilità di gestione, queste applicazioni erano generalmente monolitiche: un unico grande server conterrebbe tutto il codice back-end e il database. Ora, i servizi di web hosting come Amazon e la diffusione della tecnologia hypervisor hanno cambiato tutto questo. Grazie ad Amazon Web Services (AWS) e strumenti come VirtualBox, è diventato facile creare pacchetti di un intero sistema operativo in un unico file.

Utilizzando servizi come EC2, è diventato facile creare pacchetti di immagini di macchine e mettere insieme insiemi di server virtuali. È arrivato il paradigma dei microservizi, un approccio all'architettura software in cui le app monolitiche di grandi dimensioni sono suddivise in servizi focalizzati più piccoli che fanno bene una cosa. In generale, questo approccio consente un ridimensionamento e uno sviluppo delle funzionalità più semplici poiché i colli di bottiglia sono più veloci da trovare e le modifiche al sistema sono più facili da isolare.

Animali domestici al bestiame

Sono diventato un ingegnere delle infrastrutture proprio al culmine di questa tendenza. Ricordo di aver costruito il mio primo ambiente di produzione su Amazon utilizzando una serie di script bash. I server erano come animali domestici per me. Ho dato a ciascuno di loro dei nomi carini. Li ho seguiti attentamente. Ho risposto rapidamente agli avvisi e li ho mantenuti sani. Ho trattato quei casi con amore e affetto perché era doloroso cercare di sostituirli, proprio come un amato animale domestico.

È arrivato Chef, uno strumento di gestione della configurazione, e quasi immediatamente la mia vita è diventata più facile. Con strumenti come Chef e Puppet, puoi eliminare la maggior parte del dolore manuale associato alla gestione di un sistema cloud. È possibile utilizzare il costrutto "ambienti" per separare i server di sviluppo, staging e produzione. È possibile utilizzare i suoi "sacchetti di dati" e "ruoli" per definire i parametri di configurazione e inviare insiemi di modifiche. Ora, tutti i miei servitori "animali domestici" si erano diplomati alla scuola di obbedienza.

Poi, nel 2013, è arrivato Docker ed è iniziata una nuova era: l'era del software come bestiame (scusate con tutti i vegani tra il pubblico). Il paradigma del contenitore è quello dell'orchestrazione, non della gestione della configurazione. Strumenti come Kubernetes, Docker Compose e Marathon si concentrano sullo spostamento di immagini predefinite invece di regolare i valori di configurazione sulle istanze in esecuzione. L'infrastruttura è immutabile; quando un contenitore si guasta, non proviamo a ripararlo, gli spariamo in testa e lo sostituiamo. Ci preoccupiamo più della salute della mandria che dei singoli animali. Non diamo più ai nostri server nomi carini.

Le ricompense

I contenitori rendono molte cose più facili. Consentono alle aziende di concentrarsi maggiormente sulla propria salsa speciale. I team tecnici possono preoccuparsi meno dell'infrastruttura e della gestione della configurazione e invece preoccuparsi principalmente del codice dell'app. Le aziende possono fare un ulteriore passo avanti e utilizzare i servizi gestiti per cose come MySQL, Cassandra, Kafka o Redis in modo da non avere a che fare con il livello di dati. Esistono diverse startup che offrono anche servizi di apprendimento automatico "plug and play" per consentire alle aziende di eseguire analisi sofisticate senza preoccuparsi dell'infrastruttura. Queste tendenze sono culminate nel modello serverless, un approccio all'architettura software che consente ai team di rilasciare software senza gestire una singola macchina virtuale o container. I servizi AWS come S3, Lambda, Kinesis e Dynamo lo rendono possibile. Quindi, per estendere l'analogia, siamo passati dagli animali domestici al bestiame a una sorta di servizio di animali su richiesta.

Tutto questo è molto bello. È pazzesco che viviamo in un'epoca in cui un bambino di dodici anni può far girare un sofisticato sistema software con pochi clic. Dovremmo ricordare che, non molto tempo fa, questo era impossibile. Solo pochi presidenti degli Stati Uniti fa, i media fisici erano lo standard e solo le grandi aziende avevano i mezzi per produrre e distribuire software. Le correzioni di bug erano un lusso. Ora, quel bambino di dodici anni può creare un account AWS e rendere il suo software disponibile al mondo intero. Se c'è un bug, qualcuno lo infastidirà su Slack e, in pochi minuti, una soluzione sarà disponibile per tutti gli utenti.

I rischi

Molto, molto interessante, ma non senza il suo prezzo: affidarsi a fornitori di servizi cloud come Amazon significa fare affidamento su grandi aziende e tecnologie proprietarie. Se Richard Stallman ed Edward Snowden non ti hanno fatto preoccupare di queste cose, la recente debacle con Facebook avrebbe sicuramente dovuto farlo.

Una maggiore astrazione dall'hardware comporta anche il rischio di una minore trasparenza e controllo. Quando qualcosa si rompe in un sistema che esegue centinaia di container, dobbiamo sperare che l'errore si manifesti da qualche parte che possiamo rilevare. Se il problema riguarda il sistema operativo host o l'hardware sottostante, potrebbe essere difficile da determinare. Un'interruzione che avrebbe potuto essere risolta in 20 minuti usando le macchine virtuali potrebbe richiedere ore o giorni per risolversi con i container se non si dispone della strumentazione giusta.

Non sono nemmeno solo i fallimenti di cui dobbiamo preoccuparci quando si tratta di cose come Docker. C'è anche il problema della sicurezza. Qualunque sia la piattaforma container che utilizziamo, dobbiamo confidare che non ci sono backdoor o vulnerabilità di sicurezza non divulgate. Anche l'utilizzo di piattaforme open source non è garanzia di sicurezza. Se ci affidiamo a immagini di container di terze parti per parti del nostro sistema, potremmo essere vulnerabili.

Incartare

Il paradigma del bestiame è attraente per una serie di ragioni, ma non è privo di aspetti negativi. Prima di affrettarsi a containerizzare l'intero stack, i team tecnologici devono pensare se sia la scelta giusta o meno e assicurarsi di poter mitigare gli effetti negativi.

Personalmente, amo lavorare con i container. Sono entusiasta di vedere dove andranno le cose nei prossimi dieci anni man mano che emergono nuove piattaforme e paradigmi. Tuttavia, come ex consulente per la sicurezza, sono abbastanza cauto da sapere che tutto ha un prezzo. Spetta agli ingegneri rimanere vigili per garantire che non rinunciamo alla nostra autonomia come utenti e sviluppatori. Anche il flusso di lavoro CD/CI più semplice al mondo non varrebbe il costo.