Serverless per le applicazioni: architettura in pratica

Comprendere serverless è una cosa. Implementarlo bene è un'altra cosa. Molte persone che abbracciarono il concetto scoprirono, strada facendo, che la facilità promessa era accompagnata da decisioni difficili di cui nessuno aveva parlato.

La distanza tra il serverless delle diapositive e il serverless del codice di produzione è il punto in cui i team vengono danneggiati. Non perché la tecnologia sia pessima, ma perché richiede un modo di pensare che pochi sviluppano prima di trovarsi già nei guai.

Questo testo è per coloro che hanno deciso di creare con serverless e vogliono farlo bene. Parliamo delle reali decisioni progettuali, delle insidie che compaiono nell'implementazione e della disciplina che separa un'architettura solida da un insieme di funzioni difficili da mantenere.

L'ingannevole facilità dell'inizio

Serverless ha un inizio seducente. In pochi minuti carichi la tua prima funzione, lei risponde e sembra che tutto sarà così semplice. È lì che sta la trappola.

Il problema non è scrivere una funzione. Significa scrivere cinquanta funzioni che dialogano tra loro, condividono la logica, dipendono dai dati e devono essere comprese da un team sei mesi dopo. La complessità non scompare con serverless. Cambia sede, lascia le infrastrutture e passa all’architettura.

Coloro che non se ne rendono conto costruiscono quello che viene chiamato un “monolite distribuito”: tutti gli svantaggi di un sistema distribuito, senza nessuno dei vantaggi di una progettazione ponderata. È il peggiore di tutti i mondi ed è più comune di quanto si possa pensare.

La tesi: il serverless richiede più design, non meno

Ecco la mia posizione centrale. Il serverless non rinuncia all’architettura, ne richiede di più.

Quando gestisci i server, parte della disciplina è imposta dall'infrastruttura. Sei costretto a pensare a come sono organizzati i pezzi. Serverless rimuove questa imposizione e restituisce la totale libertà. E la libertà senza disciplina diventa caos.

Pertanto, implementare serverless bene è un esercizio di progettazione consapevole. È necessario decidere, di proposito, come dividere le responsabilità, come comunicano le funzioni, dove vive lo Stato e come tutto rimane comprensibile. Coloro che trattano il serverless come “codice serverless veloce” raccolgono debiti tecnici a velocità record.

Decisioni progettuali che definiscono il risultato

Granularità: quanto piccola dovrebbe essere ciascuna funzione

La prima decisione difficile è la dimensione. Funzioni troppo piccole moltiplicano la complessità della comunicazione. Le funzioni troppo grandi perdono i vantaggi della modularità e della scalabilità indipendente.

Una buona regola pratica è organizzare i ruoli attorno a chiare responsabilità aziendali, non a operazioni banali. Ogni funzione deve fare qualcosa di coeso e comprensibile. Resistere alla tentazione di frammentare tutto in micropezzi, la seduzione dell'“estremamente granulare” sfocia solitamente nell'ingovernabilità.

Stato: dove risiedono effettivamente i dati

Le funzioni serverless sono, per natura, stateless. Nascono, giustiziano e muoiono. Ciò significa che tutti gli stati devono vivere al di fuori di essi, in database, cache, negozi.

Questo è uno dei più grandi cambiamenti di mentalità. Non è possibile tenere nulla in memoria tra una corsa e l'altra. Ogni persistenza è esplicita ed esterna. Progettarlo bene, scegliendo gli archivi giusti per ogni tipo di dati, è ciò che distingue un'applicazione affidabile da una piena di comportamenti imprevedibili.

Comunicazione: come i pezzi parlano tra loro

In una vera architettura serverless, le funzioni devono interagire. La decisione su come comunicano, in modo sincrono, in attesa di una risposta, o in modo asincrono, tramite eventi e code, determina l’intera robustezza del sistema.

La comunicazione asincrona, tramite eventi, tende a portare più resilienza: se una parte fallisce, il messaggio attende. Ma aggiunge complessità al monitoraggio. La comunicazione sincrona è più semplice da comprendere, ma crea accoppiamenti e propaga i guasti. Questa scelta non è di secondaria importanza tecnica, è strutturale.

Un esempio di implementazione consapevole

Immagina di creare il backend di un'app di consegna utilizzando serverless. Il flusso di un ordine prevede diverse fasi: convalida, addebito, notifica al ristorante, tracciabilità della consegna.

L'implementazione ingenua creerebbe una funzione gigantesca che tenta di orchestrare tutto in modo sincrono. Risultato: lento, fragile e impossibile da eseguire il debug. Se la notifica fallisce, l'intera richiesta si blocca.

L’attuazione consapevole separa le responsabilità. Una funzione riceve e valida la richiesta, registrandola. Ciò emette un evento che attiva in modo indipendente la fatturazione, la notifica e il monitoraggio. Ogni parte fallisce e si riprende da sola. Lo stato dell'ordine risiede in un database, accessibile a tutti.

La differenza tra i due non è la tecnologia. È la cura progettuale posta prima di scrivere la prima riga.

Le insidie dell'implementazione

La prima trappola è il debug. Quando qualcosa va storto in un sistema suddiviso in decine di funzioni ed eventi, trovarne la causa è difficile. Senza un corretto monitoraggio fin dall'inizio, rimarrai cieco. Investire nell’osservabilità non è un optional, è una condizione per la sopravvivenza.

La seconda è l'esplosione della configurazione. Ogni funzione ha i suoi permessi, le sue variabili, i suoi trigger. Su larga scala, la gestione manuale di questa situazione diventa fonte di errori. Trattare l’infrastruttura come codice, con versione e automatizzata, smette di essere un perfezionamento e diventa una necessità.

Il terzo è l'illusione dell'isolamento. Le funzioni sembrano indipendenti, ma condividono banche, code e limiti del provider. Una funzione mal gestita può influenzare le altre. Pensare a queste dipendenze invisibili fa parte del lavoro.

La disciplina è la vera infrastruttura

Ciò che ho scoperto, in pratica, è che serverless non elimina il duro lavoro, lo sostituisce. Smetti di occuparti delle macchine e inizi a occuparti di design, comunicazione e stato. Per coloro che affrontano questo problema con disciplina, il risultato è potente: sistemi flessibili, scalabili ed economici.

Per chi la considera una scorciatoia, il risultato è un groviglio che nessuno capisce e nessuno vuole mantenere. La tecnologia è la stessa. Ciò che cambia è il rigore di chi lo brandisce.

Senza server non è più facile. È diverso. E la differenza si vince con il design, non con la fretta.

Se stai implementando un'architettura serverlesse vuoi evitare le classiche trappole, vale la pena cambiare idea. Ho altri articoli sul blog sul concetto di serverless, casi d'uso e operazioni quotidiane che completano questa visione di implementazione.