Di 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 l’architettura di rete non è ancora stato raggiunto dal dibattito su questa nuova architettura, 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 PaaS (Platform as a service). Dal punto di vista del PaaS tutto questo è positivo, dato che, come mercato, non era mai riuscito ad avere il successo che si sperava. Si trattava di un concetto che era rimasto in sospeso, con i sui fan che lo esaltavano anche se rimaneva ignorato dalla maggior parte del pubblico, con tassi di crescita molto lontani da quelli più emozionanti del cloud privato o pubblico, e certamente dal SaaS.
In un’architettura serverless, il provider del cloud è responsabile di tutto a parte il codice che è necessario per compiere le azioni, quando ad esempio un utente preme un pulsante o una checkbox o 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 più ampia che viene gestita da un altro servizio nel cloud.
L’aspetto importante è che le persone che scrivono la funzione non effettuano il provisioning, configurano o avviano una macchina virtuale o un container. Non si preoccupano dei 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, con sviluppatori di stack che 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 deve 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 l’”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 (nei prossimi 12 a 15 mesi), certo è importante fin da ora capire di cosa stiamo parlando è agire in modo proattivo prima che l’on-premise subisca un nuovo arresto.
