Un errore comune, quando si parla di serverless, è quello di pensare che esso voglia dire solo Lambda Function o Azure Function. Questi sono servizi Function as a Service (FaaS) e sono certamente servizi serverless, ma il termine serverless apre le porte di un mondo molto più vasto.

In ogni caso, se questi vocaboli vi sono nuovi, non temete, perché in questo articolo partiremo dalle radici di serverless: scopriremo di cosa si tratta, cosa si può fare, i suoi vantaggi e svantaggi e cercheremo di sciogliere un po’ di dubbi.

Cos’è - e cosa non è - Serverless

Andiamo dritti al sodo: serverless è un modello di Cloud Computing in cui l’approvvigionamento e la manutenzione dei server è delegata ad un cloud provider. A differenza di quel che il nome suggerisce, quindi, serverless non vuol dire davvero “senza server”. In realtà i server ci sono, solo che non li compriamo, non li installiamo, non li gestiamo. Dunque, i server spariscono dai nostri pensieri.

Un ruolo centrale è quello del cloud provider, che ci offre i servizi serverless e che gestisce l’infrastruttura fisica al posto nostro. In questo articolo faremo riferimento ai public cloud provider, tra cui spiccano i nomi di Amazon AWS e Microsoft Azure.

I servizi serverless messi a disposizione sono pre-confezionati, ma configurabili, e permettono un’alta produttività. Quando li utilizziamo, il provider allocherà per conto nostro le risorse necessarie, per il tempo necessario. I costi sono proporzionali all’effort richiesto al provider. Quindi, se non utilizziamo risorse, allora non abbiamo spese.

Due proprietà fondamentali

Serverless rappresenta una delle più alte espressioni del Cloud Computing di oggi, da cui possiamo beneficiare di due importanti proprietà: la scalabilità e la disponibilità. Prima di scendere nei dettagli di serverless è importante comprendere questi concetti. Per farlo, immedesimiamoci nei gestori di un e-commerce.

Scalabilità

Ci saranno periodi dell’anno in cui il traffico sarà basso e il nostro sistema non avrà problemi a gestire tutte le richieste. In altri periodi, ad esempio durante il BlackFriday, gli sconti succulenti potrebbero attirare più visitatori del solito. La scalabilità è la proprietà che ci permette di sostenere la richiesta crescente e magari improvvisa di risorse. Nelle sue forme più sofisticate, essa permette di allocare e deallocare componenti infrastrutturali (es: macchine virtuali) a seconda delle necessità in modo automatico.

Disponibilità

Il nostro e-commerce è ciò che genera il guadagno, perciò non possiamo permettere che ci siano dei down. Eppure, server e reti falliscono continuamente per miriadi di ragioni che non dipendono necessariamente da noi. La disponibilità è la proprietà che permette di avere un’alta probabilità che il nostro servizio sia operativo. Una tecnica basilare consiste nel replicare le applicazioni su più server, in modo che, se uno di essi dovesse andare giù, ce ne sia un altro che permette al servizio di essere ancora fruibile. Ciò riguarda anche i dati, che sono replicati su più server in modo da evitare perdite di informazioni.

Cosa possiamo fare

Function as a Service

Sebbene serverless non sia soltanto FaaS, quest’ultimo rappresenta uno dei modelli più interessanti per il computing. Consiste nell’eseguire del codice on-demand, senza dover gestire server (installazione, configurazione, aggiornamento, patching, ecc). Le risorse necessarie all’esecuzione sono allocate a run-time, per il tempo necessario, e questo consente di adottare un modello di prezzi pay-per-use.

Object Storage

Servizio di storage che consente di salvare qualunque tipo di file in un archivio virtuale, senza dover gestire server o sistemi operativi. Semplicemente inviamo file nel cloud, un’operazione che sembra banale, ma che dietro le quinte nasconde un’infrastruttura ad alte performance, scalabile, affidabile e durevole (AWS S3 ha una durabilità a 119’s, ossia del 99,999999999%, fenomenale).

Static Site Hosting

Si tratta di una caratteristica che usa l’object storage come hosting di un’applicazione frontend, ad esempio in React. Non è necessario gestire webserver o sistemi operativi, pensare all’affidabilità o alla scalabilità. Carichiamo semplicemente l’applicazione. È inoltre possibile abbinare un servizio di CDN (es: AWS CloudFront) per ottimizzare tempi e costi. Una soluzione che a seconda dei casi può essere non solo l’ideale, ma anche gratuita. Sembra troppo bello per essere vero, ma è così.

Database non relazionale

Tipologia di servizio che permette di avere un NoSql performante, scalabile, affidabile, senza avere un’infrastruttura da gestire. Tuttavia, ci sono delle nozioni riguardo all’infrastruttura interna che è importante conoscere per poter progettare le collection nel modo corretto.

Integrazione di servizi

Esistono molte tipologie di servizio per supportare la comunicazione asincrona, come service bus, message queue, event stream. Queste soluzioni si basano su un’infrastruttura ridondante e ad alte performance e quindi è possibile costruire applicazioni altamente scalabili e affidabili.

Tanto, tanto altro

Appartengono alla categoria serverless molti servizi fully-managed che consentono di coprire numerosissimi casi d’uso. Possiamo addestrare modelli di Machine Learning o flussi ETL clusterizzati, ma senza gestire davvero un cluster. Possiamo utilizzare servizi di gestione, autenticazione e autorizzazione scalabili su milioni di utenti, ancora una volta senza gestire un’infrastruttura, e così via.

Vantaggi

Abbattimento della TCO

Possiamo abbattere o addirittura azzerare le spese derivanti dal possesso (Total Cost of Ownership). Non abbiamo spese di acquisto, né costi fissi. Vengono meno i costi delle licenze e di manutenzione dell’hardware. Grazie alla scalabilità automatica e cucita sulle necessità reali, nessun abbiamo costi di over-provisioning.

Focus sul prodotto

Serverless offre l’opportunità di concentrare le energie dell’azienda su ciò che porta valore, ossia ciò che permette al business di progredire.

Basso Time-to-market

Non dobbiamo occuparci della gestione delle risorse e ci affidiamo ai servizi gestiti del provider, per cui l’effort per l’approvvigionamento, ma anche per l’auditing di sicurezza e pen-test che di solito precedono un go-live, sono attività di gran lunga più snelle.

Alta scalabilità, flessibilità e alta disponibilità

L’infrastruttura è in grado di espandersi e contrarsi automaticamente per accogliere qualsiasi portata di elaborazione. Inoltre, applicazioni e dati sono replicati su più server, su più reti, in più datacenter e in più zone di disponibilità per evitare downtime.

Sicuro by design e by default

Il provider provvede alla sicurezza dell’infrastruttura fisica, della virtualizzazione, dei sistemi operativi. Il cliente ha comunque delle responsabilità, ma applicare le buone pratiche è semplice, perché generalmente si tratta di una semplice configurazione testuale.

Costi basati sul consumo

I costi sono relativi alle risorse che la nostra applicazione richiede. Perciò, nessun consumo vuol dire nessun costo. Inoltre, il provider può sfruttare l’economia di scala per tenere i prezzi bassi.

Green

In Orbyta sappiamo bene quanto l’argomento sia ampio e delicato; perciò, siamo consapevoli del fatto che non potremo essere esaustivi in così poche righe.

A differenza di altri modelli, in serverless l’over-provisioning è bassissimo. Da un lato, questo vuol dire che il provider può condensare più applicazioni su un minor numero di macchine fisiche. Dall’altro vuol dire che, essendo il consumo di energia giustificato da una necessità reale, gli sprechi sono minori.

Si prendano in esame i due grafici, che riguardano un’applicazione non-serverless e una serverless. La parte evidenziata in rosso rappresenta l’over-provisioning, ovvero l’allocazione in eccesso e che quindi si può interpretare come spreco e come occupazione delle risorse del server. Come si può osservare, nel caso di serverless l’over-provisioning è molto più contenuto.

Svantaggi

Observability

Sebbene la gestione dei server sia assente, serverless non vuol dire NoOps. Le operations non scompaiono, anzi, sono fondamentali per quanto riguarda l’osservabilità, la monitorabilità, le reti, il debugging, il deployment. Queste, tuttavia, sono problematiche costanti nei sistemi distribuiti, perciò dobbiamo semplicemente imparare ad affrontarle.

Lock-In

Utilizzando i servizi di un vendor, indubbiamente dipendiamo da esso. Questo potrebbe portare non poche difficoltà nel caso in cui volessimo migrare ad un altro cloud provider. Il nostro consiglio è quello di scrivere codice nel modo più opportuno, in particolare separando bene la logica di integrazione dalla logica di dominio. In tal modo la logica di business sarebbe preservata e non compromessa in caso di migrazione.

Sviluppo in locale

I servizi del provider sono sul cloud, perciò non c’è molto che possiamo fare per eseguire del codice completamente in locale. Esistono dei tool di emulazione, ma ad essere onesti non sempre funzionano bene e non sempre implementano le feature di cui abbiamo bisogno.Quello che possiamo consigliare è di scrivere test unitari, idealmente in TDD: in questo modo potrete testare localmente la business logic e ridurre il numero di deployment non necessari.

Testability

Lavorando su sistemi distribuiti, dove le integrazioni asincrone la fanno da padrone, testare non è la cosa più semplice. È fondamentale implementare una buona strategia di integration/e2e testing, che può consistere nel costruire ambienti di testing, magari temporanei. Ricordate che con serverless si paga in base al consumo e che molti provider offrono margini di utilizzo gratuiti, perciò tale infrastruttura avrebbe praticamente costo nullo.

Costi?

Ammettiamolo, non sapere a quanto ammonterà la spesa a fine mese potrebbe essere destabilizzante. Inoltre, il modello di prezzi pay-per-use sembra affascinante quando i flussi di elaborazione sono sporadici, ma come la mettiamo con le applicazioni più avide di risorse? La fattura a fine mese potrebbe farci chiedere se non sarebbe stato meglio avere tre server sempre attivi, ma la verità è che in quest’ultimo caso ci sono molti più costi nascosti di cui tener conto: amministrazione e gestione di server e reti, TCO altissima, debito tecnico accumulato, audit di sicurezza lunghi e complessi, velocità di innovazione più bassa. Sicuri che ne valga la pena?

Obiezioni ricorrenti

Serverless, come tutte le novità, porta con sé un certo scetticismo. L’obiezione ricorrente è che la comunicazione event-driven è complessa e spesso basterebbe un semplicissimo server: in fondo l’applicazione su cui lavoriamo non ha la complessità di Spotify.

Questi sono degli appunti legittimi, guai a non mettere mai in dubbio gli strumenti che adottiamo! Dal nostro punto di vista, però, ci sono altre domande che è necessario porsi: siamo pronti a sacrificare la scalabilità dell’applicazione? Siamo pronti a rischiare dei down? Siamo pronti a rischiare la perdita di dati? Siamo pronti ad immolarci della configurazione, gestione e manutenzione dei server, siano essi virtuali o fisici?

Non c’è motivo per cui serverless debba essere una soluzione adatta solo a grandi progetti enterprise. Anzi, il fatto che permetta di delegare task complessi, ma che non portano valore al business, come la gestione dei server, e il fatto che il modello di prezzi sia abbastanza democratico da adattarsi alle tasche di tutti fanno di serverless una soluzione non solo adatta, ma ideale per molte startup e PMI. Vuol dire avere l’opportunità di costruire dal giorno 1un’architettura senza costi, che permette di porre tutte le energie sulla crescita e che è già sicura, scalabile e affidabile by design, senza futuri rework.

Conclusioni

Non è detto che serverless vada bene per ogni caso d’uso, ma dati gli enormi vantaggi che queste soluzioni possono portare, è bene imparare a pensare serverless first, senza essere necessariamente serverless only.

Vogliamo concludere con una perla estrapolata dal blog del grande software developer Martin Fowler:

“lo sviluppo software è una disciplina recente e oggi stiamo ancora imparando a farlo in modo efficiente”.

‍