Serverless per applicazioni: architettura con esempi reali

Il serverless è facile da spiegare in astratto e difficile da visualizzare nella pratica. La maggior parte delle introduzioni parlano di funzioni, eventi e scalabilità automatica, che sono concetti corretti, ma non aiutano chi deve decidere se questo è adatto al problema in questione.

Il modo migliore per comprendere serverless è vedere dove brilla davvero. Quali problemi concreti risolve meglio delle alternative? Quali schemi si ripetono nelle architetture che funzionano.

Questo testo scambia la teoria con esempi. Diamo un'occhiata alle architetture reali, quelle che compaiono ogni giorno nei prodotti digitali, e capiamo perché serverless ha senso in ognuna di esse. Non per vendere la tecnologia, ma per farti riconoscere quando è la scelta giusta.

Lo schema alla base di quasi ogni buon utilizzo del serverless

Prima degli esempi, vale la pena notare una cosa. Le migliori applicazioni serverless condividono una caratteristica: sono attività che si svolgono in risposta a un evento e non è necessario che siano sempre in esecuzione.

Succede qualcosa, arriva un file, un utente fa clic, viene raggiunta un'ora, viene ricevuto un messaggio e una funzione si sveglia, fa il suo lavoro e va di nuovo a dormire. Paghi solo il momento dell'esecuzione. Non c'è nessuna macchina seduta ad aspettare.

Quando interiorizzi questo modello, inizi a vedere opportunità serverless ovunque. E inizia anche a riconoscere dove non è adatto.

Esempio 1: elaborazione del caricamento

Immagina un prodotto in cui gli utenti inviano immagini, documenti, foto del profilo, ricevute. Ogni caricamento deve essere elaborato: ridimensionato, convalidato, forse analizzato.

In un'architettura tradizionale, manterresti i server pronti per questa elaborazione, inattivi per la maggior parte del tempo e sovraccarichi durante i picchi. In serverless, il flusso è diverso. Il file arriva in memoria, questo evento attiva una funzione, la funzione elabora l'immagine e termina.

Se arrivano mille caricamenti simultanei, la piattaforma esegue mille esecuzioni in parallelo. Se non arriva nessuno, non paghi nulla. L'adattamento è perfetto perché il lavoro è basato sugli eventi e intermittente, esattamente il terreno in cui vince serverless.

Esempio 2: API con traffico irregolare

Pensa a un'API backend per un'applicazione con orari di punta ben definiti. Un'app per i trasporti utilizzata mattina e sera. Un sistema di pianificazione degli appuntamenti con scatti all'inizio del mese.

Mantenere i server dimensionati per i picchi significa pagare per la capacità inattiva nelle valli. Dimensionare per la valle significa non gestire la vetta. È un classico dilemma.

Una API serverlessrisolve questo problema in modo elegante. Ogni richiesta attiva un'esecuzione e la piattaforma si adatta in base al traffico. Al culmine, scala; nella valle, raccogli. Tieni traccia della curva di utilizzo effettiva invece di prevedere il caso peggiore. Per il traffico irregolare, questo è uno dei casi d’uso più convenienti.

Esempio 3: automazioni e attività pianificate

Molte organizzazioni vivono di piccole automazioni. Genera un rapporto ogni mattina. Invia promemoria in orari specifici. Sincronizzare periodicamente i dati tra i sistemi. Cancella i vecchi record.

Tradizionalmente, queste attività richiedevano un server sempre attivo solo per pochi minuti al giorno. Uno spreco. In serverless definisci il trigger, ad esempio un'ora, e la funzione viene eseguita solo in quel momento.

Per un’amministrazione municipale, ciò potrebbe significare consolidare i dati sui servizi ogni notte o attivare notifiche di imposte dovute senza mantenere un’infrastruttura dedicata. Attività amministrative che vengono eseguite da sole, costando solo i secondi che occupano.

Esempio 4: architettura basata sugli eventi tra servizi

L'esempio più sofisticato è anche il più potente. Le applicazioni moderne sono spesso costituite da più parti che devono reagire tra loro.

Viene effettuato un ordine. Ciò deve aggiornare l'inventario, avvisare il cliente, registrare la transazione e forse attivare la logistica. Invece di un sistema monolitico che fa tutto in modo accoppiato, ciascuna di queste reazioni può essere una funzione indipendente, innescata dall’evento “ordine effettuato”.

Questa architettura basata sugli eventi è naturalmente serverless. Ogni pezzo è piccolo, indipendente e si ridimensiona da solo. Se un componente fallisce, gli altri continuano. La flessibilità è enorme, anche se, come vedremo, comporta una sua complessità.

La tesi: serverless riguarda l'adattamento, non la superiorità

Ciò che questi esempi rivelano è la mia posizione centrale. Il serverless non è né migliore né peggiore delle architetture tradizionali. È diverso e il suo valore dipende interamente dalla sua aderenza al problema.

Laddove il lavoro è basato su eventi, intermittente e variabile, serverless è spesso una scelta eccellente. Laddove il lavoro è costante, prevedibile e sensibile alla latenza, altri approcci potrebbero rivelarsi migliori.

La maturità tecnica non sta nell'adottare serverless per la moda, ma nel riconoscere la forma del problema e scegliere lo strumento adatto. Gli esempi sopra riportati condividono una firma comune ed è questa firma che devi imparare a identificare.

Errori che compaiono nella pratica

Il primo errore è forzare serverless dove non si adatta. Le applicazioni con elaborazione lunga e continua, o che dipendono da una latenza costantemente bassa, soffrono dei limiti dell'approccio. L’adattamento forzato genera frustrazione e costi.

Il secondo è sottovalutare la complessità distribuita. Le architetture guidate dagli eventi, con decine di funzioni, possono diventare un groviglio difficile da comprendere ed eseguire il debug. Maggiore flessibilità significa più parti che comunicano tra loro e ciò richiede disciplina di progettazione.

Il terzo è ignorare i costi su scala estrema. Per volumi molto elevati e costanti, il modello pay-per-execution può rivelarsi più costoso delle macchine dedicate. Vale la pena fare i conti, non dare per scontato il risparmio.

Riconoscere lo schema è ciò che conta

Dopo questi esempi, la lezione pratica è semplice. Imparare a riconoscere il formato del problema che serverless risolve bene: eventi, intermittenza, variabilità, indipendenza tra le parti.

Quando vedi questo schema, la decisione diventa naturale. E quando non la vedi, ti risparmi il fastidio di adottare un'architettura che non corrisponde a ciò che devi fare.

Una buona architettura non significa scegliere la tecnologia più recente. È scegliere quello che si adatta al problema come un pezzo che manca da sempre.

Se stai progettando un'architettura e vuoi discutere su dove serverless si adatta davvero al tuo caso, vale la pena parlarne. Ho altri articoli sul blog sul serverless nella pratica e nella vita di tutti i giorni, con un focus sull'esecuzione e sul funzionamento, per chi ha già deciso di seguire questa strada.