Come sfruttare il serverless computing per risparmiare tempo e denaro

I (tanti) pregi e i (pochi) limiti del serverless computing, un modello di offerta function-as-a-service che può far risparmiare tempo e denaro in fase di sviluppo.

serverless computing

Gli sviluppatori dedicano innumerevoli ore a risolvere problemi tramite codice. Quindi è il turno del team ops passare ancora più ore sia a capire come far funzionare su qualunque computer il codice che gli sviluppatori scrivono, sia ad assicurandosi che quei computer funzionino senza intoppi. Visto che questa seconda parte è davvero un compito lunghissimo, perché non affidarla a qualcun’altro?

Negli ultimi vent’anni molta innovazione nell’IT (macchine virtuali, cloud computing e container) è stata incentrata sull’assicurarsi che non si debba pensare molto alla macchina fisica su cui viene eseguito il codice. Il serverless computing è un paradigma sempre più popolare che porta questo desiderio alla sua conclusione logica: grazie a esso infatti non dovete sapere nulla sull’hardware o sul sistema operativo su cui gira il vostro codice, dato che è un service provider a farsi carico di tutto.

Che cos’è il serverless computing?

Il serverless computing è un modello di esecuzione per il cloud in cui un provider di servizi cloud assegna dinamicamente (e quindi addebita all’utente) solo le risorse di elaborazione e l’archiviazione necessarie per eseguire una particolare parte di codice. Naturalmente, ci sono ancora server coinvolti, ma la loro fornitura e manutenzione sono interamente curate dal provider scelto.

Come spiega lo sviluppatore Mike Roberts, il termine serverless computing è stato usato per i cosiddetti scenari back-end-as-a-service, in cui un’app mobile si collegava a un server back-end ospitato interamente nel cloud. Ma oggi, quando si parla di computing senza server o di architettura senza server, si intende un’offerta function-as-a-service in cui un cliente scrive un codice e lo affida in un provider. Questo si occupa di tutto il provisioning hardware, la gestione di macchine virtuali e container e persino di attività come il multithreading che spesso sono integrate nel codice dell’applicazione.

Le funzioni serverless sono basate su eventi (event driven), il che significa che il codice viene richiamato solo quando viene attivato da una richiesta. Il provider fa pagare al cliente solo il tempo di elaborazione utilizzato da tale esecuzione, piuttosto che una tariffa mensile fissa per la manutenzione di un server fisico o virtuale. Queste funzioni possono essere collegate insieme per creare una pipeline di elaborazione o possono servire come componenti di un’applicazione più grande, interagendo con altri codici in esecuzione in container o su server convenzionali.

Vantaggi e svantaggi del serverless computing

Da questa descrizione due dei maggiori vantaggi del computing serverless dovrebbero essere chiari. Da un lato gli sviluppatori possono concentrarsi solo sugli obiettivi di business del codice che scrivono, piuttosto che su questioni infrastrutturali. Dall’altro alto e le organizzazioni pagano solo le risorse di calcolo che utilizzano effettivamente in modo granulare, piuttosto che acquistare hardware fisico o noleggiare istanze cloud che rimangono per lo più inattive.

Serverless computing

Come sottolinea Bernard Golden, quest’ultimo punto è di particolare beneficio per le applicazioni event-driven. Ad esempio, è possibile che un’applicazione sia inattiva per la maggior parte del tempo ma in determinate condizioni è necessario gestire molte richieste di eventi contemporaneamente. Oppure potreste avere un’applicazione che elabora i dati inviati da dispositivi IoT con connettività Internet limitata o intermittente.

In entrambi i casi, l’approccio tradizionale richiederebbe il provisioning di un server in grado di gestire le capacità di lavoro di punta, ma il server sarebbe inutilizzato per la maggior parte del tempo. Con un’architettura serverless invece paghereste solo le risorse del server che utilizzate effettivamente. Il serverless computing sarebbe utile anche per tipi specifici di elaborazione in batch. Uno degli esempi canonici di un caso di utilizzo dell’architettura senza server è un servizio che carica ed elabora una serie di singoli file di immagine e li invia ad un’altra parte dell’applicazione.

Forse il limite più ovvio delle funzioni serverless è che queste sono intenzionalmente effimere e, come afferma AlexSoft, “inadatte per task a lungo termine”. La maggior parte dei provider serverless non consente l’esecuzione del codice per più di qualche minuto, e quando avviate una funzione, questa non mantiene alcun dato di stato dalle istanze precedentemente eseguite. Un problema correlato è che il codice serverless può richiedere fino a diversi secondi per avviarsi; non un grande problema per molti casi d’uso, ma se la vostra applicazione richiede una bassa latenza, siete avvisati.

Molti degli altri aspetti negativi, come sottolineato da Rohit Akiwatkar e Gary Arora, hanno a che fare con il lock-in del fornitore. Sebbene siano disponibili opzioni open source, il mercato serverless è dominato dai grandi fornitori di cloud commerciali, come vedremo tra poco. Ciò significa che gli sviluppatori spesso finiscono per utilizzare gli strumenti dei loro fornitori, il che rende difficile cambiare nel caso diventino insoddisfatti del servizio con il passare del tempo. E poiché gran parte del serverless computing avviene, per definizione, sull’infrastruttura del fornitore, può essere difficile integrare il codice serverless in uno sviluppo interno.

Fornitori serverless: AWS Lambda, Azure Functions e Google Cloud Functions

L’era moderna dell’elaborazione serverless è iniziata con il lancio nel 2014 di AWS Lambda, una piattaforma basata sul servizio cloud di Amazon. Microsoft ha seguito l’esempio con Azure Functions nel 2016. Google Cloud Functions, che era in beta dal 2017, ha finalmente raggiunto lo stato di produzione nel luglio 2018. I tre servizi presentano limitazioni, vantaggi, linguaggi di programmazioni supportati e modalità leggermente diverse. Inoltre c’è anche IBM Cloud Functions, che si basa sulla piattaforma open source Apache OpenWhisk. Tra tutte le piattaforme di serverless computing, AWS Lambda è la più importante e ovviamente ha avuto il maggior tempo per evolversi e maturare.

Stack serverless

Come accade in molti software il mondo del serverless ha visto l’evoluzione di stack di software, che riuniscono diversi componenti necessari per costruire un’applicazione serverless. Ogni stack è costituito da un linguaggio di programmazione in cui scrivere il codice, un framework di applicazione che fornisce una struttura per il codice e un set di trigger che la piattaforma comprenderà e utilizzerà per avviare l’esecuzione del codice.

Sebbene sia possibile combinare diverse offerte specifiche in ciascuna di queste categorie, esistono limitazioni a seconda del fornitore che si utilizza. Ad esempio, per i linguaggi è possibile utilizzare Node.js, Java, Go, C# e Python su AWS Lambda, ma solo JavaScript, C# e F# funzionano in modo nativo su Azure Functions. Quando si tratta di trigger, AWS Lambda offre la lista più lunga, ma molti di questi sono specifici per la piattaforma AWS, come Amazon Simple Email Service e AWS CodeCommit.

Framework serverless

Vale la pena soffermarsi un po’ sul discorso legato al framework, poiché questo definisce molti aspetti importanti nella costruzione della propria applicazione. Amazon ha la propria offerta nativa e open source SAM (Serverless Application Model), ma ce ne sono anche altre, molte dei quali sono multipiattaforma e open source. Una delle più popolari è chiamata, piuttosto genericamente, Serverless, e fornisce la stessa esperienza per ciascuna piattaforma supportata, ad esempio AWS Lambda, Azure Funtions, Google Cloud Functions e IBM OpenWhisk. Un’altra offerta popolare è Apex, che può aiutare ad aggiungere linguaggi di programmazione altrimenti non disponibili su alcuni provider.

Database serverless

Come abbiamo detto poco fa, una stranezza nel lavorare con codice serverless è che non ha uno stato persistente, il che significa che i valori delle variabili locali non persistono attraverso le istanze. Qualsiasi dato persistente al quale il vostro codice deve accedere deve essere archiviato altrove e i trigger disponibili negli stack per i principali fornitori includono database con cui le vostre funzioni possono interagire.

Alcuni di questi database sono indicati come serverless. Ciò significa che si comportano in modo simile alle altre funzioni serverless di cui abbiamo discusso in questo articolo, con l’ovvia eccezione che i dati vengono archiviati indefinitamente. Gran parte del carico di gestione coinvolto nel provisioning e nel mantenimento di un database viene però messo da parte.

Come afferma lo sviluppatore Jeremy Daly, “tutto quello che dovete fare è configurare un cluster e, a questo punto, tutta la manutenzione, l’applicazione di patch, i backup e lo scaling vengono gestiti automaticamente per voi.” Come per le offerte function-as-a-service pagate solo il tempo di elaborazione effettivamente utilizzato e le risorse vengono utilizzate solo in base alle esigenze per soddisfare la domanda.

I tre principali provider serverless offrono ciascuno i propri database serverless: Amazon ha Aurora Serverless e DynamoDB, Microsoft ha Azure Cosmos DB e Google ha Cloud Firestore. Questi non sono comunque gli unici database disponibili.

Serverless computing e Kubernetes

I container aiutano a potenziare la tecnologia serverless, ma tutto il carico di gestione è gestito dal fornitore e quindi invisibile all’utente. Si è soliti considerare il serverless computing come un modo per ottenere molti dei vantaggi dei microservizi containerizzati senza doversi occupare della loro complessità e si sta persino iniziando a parlare di un mondo post-container.

In verità, container e serverless computing quasi certamente coesisteranno per molti anni a venire, e infatti le funzioni serverless possono esistere nella stessa applicazione come microservizi containerizzati. Anche Kubernetes, la piattaforma di orchestrazione di container più diffusa, può gestire un’infrastruttura serverless. Infatti, con Kubernetes, potete integrare diversi tipi di servizi su un singolo cluster.

Serverless offline

Potreste infine trovare la prospettiva di iniziare con il serverless computing un po’ intimidatoria, dal momento che dovrete legarvi a un fornitore anche solo per vedere come funziona il tutto. In realtà ci sono diversi modi per eseguire codice serverless offline sul proprio hardware locale. Ad esempio, AWS SAM fornisce una funzionalità locale che consente di testare il codice Lambda offline. E se state usando il framework Serverless, date un’occhiata a serverless-offline, un plug-in che consente di eseguire codice localmente. Buona sperimentazione!