Il server non è più il cuore che batte al centro delle architetture It. O almeno non necessariamente. Nelle reti serverless cambiano i percorsi di transito e scambio di dati, ma non solo: assegnano nuove responsabilità ai fornitori di servizi cloud. Per gli sviluppatori scompare, inoltre, la necessità di preoccuparsi degli aspetti operativi. Per certi versi, le architettura serverless rappresentano un’estremizzazione delle logiche del cloud. Ne ha discusso Paolo Arcagni, system engineer manager di F5 Networks.
Paolo Arcagni, system engineer manager di F5 Networks
La tecnologia è sempre in evoluzione, o almeno così pare se consideriamo le tante tendenze, gli approcci e le architetture che affiorano continuamente. Uno dei più recenti trend è l’architettura serverless, al centro delle discussioni almeno per chi si trova sommerso dal mondo dei DevOps. Chi ha a che fare più spesso con le infrastrutture e con l’architettura di rete non è ancora stato raggiunto dal dibattito su questa nuova impostazione, ma è solo questione di tempo perché si tratta di una logica progressiva che si evolve da una visione monolitica verso i micro-servizi e poi verso le architetture serverless. Si tratta, in sostanza, di un’ulteriore suddivisione delle applicazioni aziendali in base al servizio e, quindi, alla funzione.
Queste funzioni sono essenzialmente “event-driven” e dalla grana fine, cioè ognuna si focalizza su uno scopo ancora più ristretto in termini di logica dell’applicazione rispetto al micro-servizio. Se il micro-servizio può contenere al suo interno tutta la logica applicativa necessaria per implementare un "servizio profilato", un’architettura serverless scompone il tutto ulteriormente fino alle singole funzioni. Una per il login, una per il logout, una per modificare la password, una per reimpostarla. In pratica, è come costruire un piccolo servizio, specifico per ogni azione che è possibile compiere rispetto all’app.
Il motivo per cui si chiama "serverless" è perché fondamentalmente si tratta di una forma altamente evoluta di Platform-as-a-Service. Dal punto di vista del PaaS tutto questo è positivo, dato che questo mercato non era mai riuscito ad avere il successo che si sperava. Si trattava di un concetto che era rimasto in sospeso, esaltato dai suoi “fan” ma ignorato dalla maggior parte del pubblico, con tassi di crescita molto lontani da quelli più emozionanti del cloud privato o pubblico e certamente dal Software-as-a-Service (SaaS).
In un’architettura serverless il fornitore del cloud è responsabile di tutto tranne che del codice necessario per compiere le azioni, quando ad esempio un utente preme un pulsante o una checkbox oppure clicca su un collegamento. Questo è il senso dell’"event-driven": quando un utente preme il tasto avvia una funzione nel cloud. Questa funzione è generalmente una parte di una Api (Application Programming Interface) più ampia che viene gestita da un altro servizio nella nuvola.
L’aspetto importante è che le persone che “scrivono” la funzione non effettuano il provisioning, né configurano o avviano una macchina virtuale o un container. Non si preoccupano di dettagli operativi come la scalabilità. Semplicemente scrivono il codice e, cliccando un pulsante, ottengono la funzionalità istantanea. Questo è il cloud portato al suo sviluppo estremo e gli sviluppatori di stack ora sono responsabili di restringere tutto verso un singolo strato, il livello dell’applicazione. Non conta altro, ogni ulteriore dettaglio operativo è fornito dalla piattaforma sottostante. Siamo giunti così al “NoOps”, per lo meno dal punto di vista dello sviluppatore.
Esistono i server e i servizi, le infrastrutture e la rete sotto la piattaforma che fornisce queste capacità magiche, ma non si tratta di qualcosa di cui lo sviluppatore debba preoccuparsi. Questi aspetti restano però importanti per i professionisti delle operazioni di rete e dell’infrastruttura. Per questo motivo è improbabile che le aziende scelgano a breve di abbracciare questa filosofia.
Si tratterebbe di un’impresa che richiede un ambiente di cloud computing completamente operativo che comprenda non soltanto le capacità di provisioning dei container e delle macchine virtuale ma anche una auto-scalabilità automatica. Cioè, in altre parole, una scalabilità automatica senza parametri o input da parte degli sviluppatori. Non si tratta del self-service, ma dell’auto-service; non della sola scalabilità, ma dell’auto-provisioning e così via anche per il monitoraggio e il reporting, e per qualsiasi aspetto che riguardi l’operatività di oggi.
Il percorso è iniziato. Oggi sul mercato vediamo affermarsi sempre più ambienti cloud provider ben consolidati che possiedono l’infrastruttura sottostante, l’automazione e l’orchestrazione necessarie per sostenere un modello operativo hands-off così esteso. La maggior parte delle attenzioni è rivolta a capire come interpretare il “serverless” e lavorare con esso concretamente a partire da ciò che è disponibile nel cloud: Amazon Lambda, Google Cloud Functions, Microsoft Azure Functions, e Ibm OpenWhisk. Non esistono, però, ancora offerte in grado di supportare implementazioni on-premise come Serverless and Iron.io.
Per il momento il “serverless” rappresenta solo il motore per l’avvio di una nuova architettura, ma ritengo probabile che avrà un impatto sulle organizzazioni interessante a breve termine, cioè nei prossimi dodici o quindici mesi. Certo è importante fin da ora capire di cosa stiamo parlando e agire in modo proattivo prima che l’on-premise subisca un nuovo arresto.