Preparati per il nuovo stack

La virtualizzazione potrebbe essere la tecnologia di maggior successo che abbia mai varcato la soglia del data center aziendale. L'utilizzo dell'hardware notevolmente migliore e la capacità di far girare le VM su un centesimo ha reso la virtualizzazione una vendita facile negli ultimi dieci anni, al punto che Gartner ha recentemente stimato che il 70% dei carichi di lavoro x86 è virtualizzato.

Tuttavia, le fantasiose cose del cloud privato in cima a quel livello di virtualizzazione hanno tardato ad arrivare. Sì, gli strumenti di gestione della virtualizzazione di VMware e Microsoft hanno abilitato un comportamento simile al cloud per i server e lo storage, e persino OpenStack sta finalmente ottenendo una piccola trazione aziendale, ma i cloud pubblici avanzati offerti da Amazon, Google, IBM, Microsoft e Rackspace offrono molto di più scalabilità automatica avanzata, misurazione e self-service (per non parlare di centinaia di altri servizi). Inoltre, il livello cloud PaaS per lo sviluppo, il test e la distribuzione di app, ora offerto da tutti i principali cloud pubblici, ha trovato la sua strada in relativamente pochi data center aziendali.

Quindi Docker è entrato in scena lo scorso anno, offrendo un nuovo cloud stack basato su container anziché su VM. I contenitori sono molto più leggeri delle VM e consentono di impacchettare e spostare le applicazioni con facilità, senza il problema dell'installazione convenzionale. Se i cloud basati su VM si sono bloccati e il nuovo stack basato su container offre vantaggi così evidenti, il nuovo stack si farà strada nell'azienda per fornire un nuovo cloud privato?

Zorawar Biri Singh, ex capo di HP Cloud Services e ora venture partner di Khosla Ventures, pensa che il trionfo del nuovo stack sia inevitabile, ma siamo ancora lontani anni dall'adozione aziendale. Ecco dove vede i colli di bottiglia:

In primo luogo, per le imprese tradizionali e i carichi di lavoro di produzione tradizionali, l'attuale spesa IT è incentrata sulla semplificazione e la gestione della proliferazione incontrollata delle VM tramite soluzioni convergenti nel data center. In secondo luogo, il nuovo stack è ancora fragile e precoce. La reale utilità intorno ai container, come la protezione rafforzata, non è ancora neanche lontanamente adeguata. In questo momento il nuovo stack è un ottimo terreno di semina per i carichi di lavoro di sviluppo e test. Ma il vero punto di attrito è che i team IT del carico di lavoro di produzione aziendale non hanno l'orientamento devops o un background IT agile per essere in grado di distribuire e supportare app distribuite o senza stato. Uno dei problemi maggiori è che c'è solo un enorme divario di competenze nei devops nelle organizzazioni aziendali tradizionali.

D'altra parte, dice Singh, "alcuni team di sviluppo e linee di business greenfield stanno già utilizzando questa infrastruttura". In questi casi, i metodi devops sono già in atto o gli sviluppatori pionieri gestiscono da soli il lato operativo dello stack basato sul contenitore.

Proprio come gli sviluppatori hanno guidato l'adozione di database NoSQL, sono in prima linea nel nuovo stack, scaricando software open source e sperimentando o passando a cloud pubblici come EC2 o Azure che già supportano i container.

L'imperativo dei microservizi

Perché agli sviluppatori piace così tanto il nuovo stack? In gran parte perché i contenitori favoriscono l'architettura dei microservizi, in cui le raccolte di servizi a scopo singolo e accessibili tramite API sostituiscono le app monolitiche. L'architettura dei microservizi consente agli sviluppatori di creare applicazioni più adattabili ai nuovi requisiti e di creare rapidamente applicazioni completamente nuove utilizzando i servizi esistenti.

John Sheehan, co-fondatore e CEO del servizio di monitoraggio e test delle API Runscope, vede i microservizi come una "modernizzazione" della SOA (architettura orientata ai servizi). "Le responsabilità principali sono in gran parte le stesse", afferma Sheehan. "Vogliamo distribuire parti diverse della nostra architettura software su sistemi diversi e suddividerla non solo in base ai limiti del codice, ma anche in base ai limiti del servizio. Questo apprendimento è stato trasferito ai microservizi".

L'architettura dei microservizi si basa su protocolli più semplici e più intuitivi rispetto a SOA: REST in contrapposizione a SOAP; JSON al contrario di XML. Sheehan nota un'altra differenza fondamentale:

I tipi di microservizi che vediamo e che i nostri clienti tendono a utilizzare sono molto basati su devops. Internamente, impieghiamo circa 31 volte al giorno presso la nostra azienda in tutti i nostri diversi servizi. Siamo 14 persone e abbiamo circa 40 diversi servizi in esecuzione internamente. Gran parte di esso consiste nel mettere in atto l'infrastruttura necessaria in modo che ogni team sia in grado di distribuire, ridimensionare, monitorare e misurare in modo indipendente ogni servizio.

In uno scenario del genere, il confine tra dev e ops si confonde. Il personale operativo scrive codice per gestire l'infrastruttura, diventando essenzialmente parte del team di sviluppo. "C'è pochissima distinzione tra il team operativo e il team delle app", afferma Sheehan. Nelle operazioni, "ti capita di scrivere codice contro i server invece di scrivere codice contro il servizio".

Singh ritiene che l'approccio basato su microservizi devops potrebbe ovviare alla necessità di PaaS "formale". Tali offerte PaaS come Cloud Foundry o OpenShift offrono raccolte predeterminate di servizi e processi per la creazione, il test e la distribuzione di applicazioni, mentre, nel nuovo stack, è possibile incorporare in ogni livello ricchi set di microservizi accessibili tramite API. Sia lo sviluppo che le operazioni possono collegarsi a microservizi su e giù per lo stack, senza i vincoli imposti da PaaS.

Un diverso tipo di ibrido

L'architettura dei microservizi potrebbe superare PaaS, ma l'intero nuovo stack non attecchirà dall'oggi al domani. Ad esempio, Netflix è ampiamente considerato come avere la distribuzione di microservizi più avanzata ovunque e rende disponibili molti servizi predefiniti alla comunità open source come immagini Docker su Docker Hub, ma Netflix non utilizza Docker in produzione. Né Runscope, del resto. Entrambi utilizzano invece VM convenzionali.

Nonostante l'enorme interesse tra gli sviluppatori per le soluzioni basate su container, è solo l'inizio. Per prima cosa, gli strumenti di orchestrazione e gestione per container, come Mesosphere e Kubernetes, sono ancora in evoluzione. Inoltre, non è chiaro quale standard di container vincerà, con CoreOS che rappresenta una sfida importante per Docker lo scorso dicembre. Lo stack basato su container potrebbe trionfare alla fine, ma ci vorrà del tempo.

"Vediamo che il risultato più probabile è che i contenitori e le VM verranno utilizzati in combinazione", afferma Kurt Milne del provider di gestione multicloud Cliqr. Ciò potrebbe significare l'esecuzione di container all'interno delle VM o potrebbe semplicemente significare che i nuovi stack basati su container e gli stack basati su VM verranno eseguiti fianco a fianco.

Questo scenario ibrido apre un'opportunità per VMware e altri che hanno creato gestione e orchestrazione per la virtualizzazione. In un'intervista con la scorsa settimana, il vicepresidente esecutivo di VMware Raghu Raghuram ha rifiutato di considerare i container come una minaccia. Invece, ha detto:

Vediamo i container come un modo per portare nuove applicazioni sulla nostra piattaforma. Quando gli sviluppatori o il personale IT si chiedono di cosa hanno bisogno per eseguire i container in modo robusto, si scopre che hanno bisogno di un livello di infrastruttura sottostante: hanno bisogno di persistenza, hanno bisogno di rete, hanno bisogno di firewall, hanno bisogno di gestione delle risorse e tutti quei tipi di cose. L'abbiamo già costruito. Quando si posiziona il meccanismo del contenitore in cima a questo, è possibile iniziare a utilizzare la stessa infrastruttura anche per quelle cose. Stiamo vedendo modelli in cui il front-end Web senza stato è tutto contenitori e la persistenza e i database sono tutte VM . È un mix di entrambi. Quindi ora la domanda è: cosa sono un ambiente di infrastruttura comune e un ambiente di gestione comune? Lo vediamo come una straordinaria opportunità per noi.

Raghuram ha rifiutato di dire quando VMware potrebbe estendere i suoi strumenti di gestione al livello container, ma l'implicazione è chiara. Sarà interessante vedere come l'approccio orientato alle operazioni di VMware verrà soddisfatto dagli sviluppatori che guidano la sperimentazione basata su container di oggi.

Ciò che è chiaro è che, nonostante l'attuale eccitazione, il nuovo stack non sostituirà quello esistente in una drammatica ondata di rip-and-replace. Come con l'adozione del cloud, lo stack basato su container verrà utilizzato quasi esclusivamente per lo sviluppo e il test prima. L'enorme investimento esistente nell'infrastruttura di virtualizzazione non verrà buttato fuori dalla finestra del data center.

Tuttavia, il nuovo stack basato su container rappresenta un grande balzo in avanti nell'agilità e nel controllo degli sviluppatori. Gli sviluppatori stanno scoprendo e adottando gli strumenti di cui hanno bisogno per costruire l'architettura dei microservizi e per fornire più e migliori applicazioni in un clip fantastico. Man mano che i pezzi vanno a posto e le abilità di devops diventano onnipresenti, puoi scommettere che il nuovo stack attecchirà inesorabilmente come ha fatto la virtualizzazione.