L'elaborazione serverless offre numerosi vantaggi agli sviluppatori Web, tra cui scalabilità, tempi di commercializzazione più rapidi e spese ridotte. Tuttavia, in alcuni casi questi vantaggi possono essere controbilanciati da altre preoccupazioni.
Dopo aver letto questo articolo sarai in grado di:
Argomenti correlati
Che significa serverless?
Serverless e container a confronto
Serverless e Javascript
Function as a Service (FaaS)
Come creare e distribuire app velocemente
Abbonati a theNET, il riepilogo mensile di Cloudflare sulle tematiche più discusse in Internet.
Copia link dell'articolo
L'elaborazione serverless offre numerosi vantaggi rispetto alle infrastrutture tradizionali basate su cloud o incentrate sui server. Per molti sviluppatori, le architetture serverless offrono maggiore scalabilità, maggiore flessibilità e tempi di rilascio più rapidi, il tutto a un costo ridotto. Grazie alle architetture serverless, gli sviluppatori non devono preoccuparsi dell'acquisto, del provisioning e della gestione dei server backend. Tuttavia, questo tipo di elaborazione non è una soluzione miracolosa per tutti gli sviluppatori di applicazioni Web.
L'elaborazione serverless è un'architettura in cui un fornitore fornisce servizi backend in base alle necessità. Per ulteriori informazioni sull'elaborazione serverless, consulta Cos'è l'elaborazione serverless?
Sebbene l'elaborazione "serverless" avvenga effettivamente su server, gli sviluppatori non devono mai avere a che fare con i server. Sono gestiti dal fornitore. Ciò può ridurre l'investimento necessario in DevOps, abbassando le spese e consentendo agli sviluppatori di creare ed espandere le proprie applicazioni senza essere vincolati dalla capacità del server.
Come in un piano telefonico con pagamento in base al consumo, agli sviluppatori viene addebitato solo ciò che utilizzano. Il codice viene eseguito solo quando le funzioni backend sono necessarie all'applicazione serverless e il codice viene automaticamente dimensionato verso l'alto in base alle esigenze. Il provisioning è dinamico, preciso e in tempo reale. Alcuni servizi sono così precisi che suddividono i loro addebiti in incrementi di 100 millisecondi. Al contrario, in un'architettura tradizionale "server-full", gli sviluppatori devono prevedere in anticipo quanta capacità del server avranno bisogno e poi acquistare tale capacità, indipendentemente dal fatto che decidano di utilizzarla o meno.
Immaginate se un ufficio postale potesse in qualche modo magicamente aggiungere e togliere furgoni per le consegne a piacimento, aumentando le dimensioni della sua flotta quando la quantità di posta aumenta (ad esempio, poco prima della festa della mamma) e riducendola nei periodi in cui sono necessarie meno consegne. Questo è essenzialmente ciò che le applicazioni serverless sono in grado di fare.
Le applicazioni create con un'infrastruttura serverless si dimensioneranno automaticamente man mano che la base di utenti cresce o aumenta l'utilizzo. Se una funzione deve essere eseguita in più istanze, i server del fornitore le avvieranno, eseguiranno e termineranno quando necessario, spesso utilizzando dei contenitori. La funzione si avvierà più rapidamente se è stata eseguita di recente: consultare la sezione "Le prestazioni potrebbero essere compromesse" di seguito. Di conseguenza, un'applicazione serverless sarà in grado di gestire un numero insolitamente elevato di richieste con la stessa efficacia con cui riesce a elaborare una singola richiesta da parte di un singolo utente. Un'applicazione strutturata tradizionalmente con una quantità fissa di spazio sul server può essere sopraffatta da un improvviso aumento dell'utilizzo.
Utilizzando un'infrastruttura serverless, non è necessario caricare codice sui server o effettuare alcuna configurazione backend per rilasciare una versione funzionante di un'applicazione. Gli sviluppatori possono caricare rapidamente frammenti di codice e rilasciare un nuovo prodotto. Possono caricare il codice tutto in una volta oppure una funzione alla volta, poiché l'applicazione non è un singolo stack monolitico ma piuttosto una raccolta di funzioni fornite dal fornitore.
Ciò consente inoltre di aggiornare, applicare patch, correggere o aggiungere rapidamente nuove funzionalità a un'applicazione. Non è necessario apportare modifiche all'intera applicazione; invece, gli sviluppatori possono aggiornare l'applicazione una funzione alla volta.
Poiché l'applicazione non è ospitata su un server di origine, il suo codice può essere eseguito da qualsiasi luogo. È quindi possibile, a seconda del fornitore utilizzato, eseguire le funzioni dell'applicazione su server vicini all'utente finale. Ciò riduce la latenza perché le richieste dell'utente non devono più viaggiare fino a un server di origine. Cloudflare Workers consente questo tipo di riduzione della latenza serverless.
È difficile replicare l'ambiente serverless per vedere come funzionerà effettivamente il codice una volta distribuito. Il debug è più complicato perché gli sviluppatori non hanno visibilità sui processi di backend e perché l'applicazione è suddivisa in funzioni separate e più piccole. Cloudflare Workers Playground è una sandbox che aiuta a ridurre l'attrito durante i test e il debug
Quando i fornitori gestiscono l'intero backend, potrebbe non essere possibile verificarne completamente la sicurezza, il che può rappresentare un problema soprattutto per le applicazioni che gestiscono dati personali o sensibili.
Poiché alle aziende non vengono assegnati server fisici distinti, i fornitori serverless spesso eseguono codice di diversi clienti su un singolo server in qualsiasi momento. Questa questione della condivisione dei macchinari con altre parti è nota come "multitenancy": si pensi a diverse aziende che cercano di affittare un unico ufficio e di lavorarci contemporaneamente. Il multitenancy può influire sulle prestazioni delle applicazioni e, se i server multitenancy non sono configurati correttamente, potrebbe causare l'esposizione dei dati. Il multitenancy ha un impatto minimo o nullo sulle reti che funzionano correttamente in modalità sandbox e dispongono di un'infrastruttura sufficientemente potente. Ad esempio, Cloudflare gestisce una rete da 15 Tbps con una capacità in eccesso sufficiente a mitigare il degrado del servizio e tutte le funzioni serverless ospitate da Cloudflare vengono eseguite nel proprio sandbox (tramite il motore Chrome V8).
Ciò limita i tipi di applicazioni che possono essere eseguite in modo economicamente conveniente in un'architettura serverless. Poiché i provider serverless addebitano un costo in base al tempo di esecuzione del codice, eseguire un'applicazione con processi di lunga durata in un'infrastruttura serverless potrebbe risultare più costoso rispetto a una tradizionale.
Poiché non è costantemente in esecuzione, il codice serverless potrebbe dover essere "avviato" quando viene utilizzato. Questo tempo di avvio potrebbe ridurre le prestazioni. Tuttavia, se una parte di codice viene utilizzata regolarmente, il fornitore serverless la manterrà pronta per essere attivata: una richiesta di questo codice pronto all'uso è chiamata "avvio a caldo". Una richiesta di codice che non viene utilizzata da un po' di tempo è invece chiamata "avvio a freddo".
Cloudflare Workers evita in gran parte il problema dell'avvio a freddo utilizzando il motore Chrome V8, che nella maggior parte dei casi è in grado di avviarsi ed eseguire il codice JavaScript in meno di 5 millisecondi. Se il codice è già in esecuzione, il tempo di risposta è inferiore a un millisecondo. Scopri di più sulle prestazioni delle diverse piattaforme serverless.
Consentire a un fornitore di fornire tutti i servizi backend per un'applicazione aumenta inevitabilmente la dipendenza da quel fornitore. Configurare un'architettura serverless con un unico fornitore può rendere difficile cambiare fornitore, se necessario, soprattutto perché ogni fornitore offre funzionalità e flussi di lavoro leggermente diversi. Cloudflare Workers è più facili da migrare perché è tutto scritto in JavaScript e basato sull'API dei worker di servizi ampiamente utilizzata.
Gli sviluppatori che desiderano ridurre i tempi di commercializzazione e creare applicazioni leggere e flessibili, che possono essere espanse o aggiornate rapidamente, possono trarre grandi vantaggi dal serverless computing.
Le architetture serverless ridurranno i costi delle applicazioni che vengono utilizzate in modo non uniforme, con periodi di picco alternati a periodi di traffico scarso o nullo. Per tali applicazioni, acquistare un server o un blocco di server costantemente in funzione e sempre disponibili, anche quando inutilizzati, può rappresentare uno spreco di risorse. Una configurazione serverless risponderà istantaneamente quando necessario e non incorrerà in costi quando è inattiva.
Inoltre, gli sviluppatori che desiderano avvicinare alcune o tutte le funzioni della loro applicazione agli utenti finali per ridurre la latenza, necessiteranno almeno di un'architettura parzialmente serverless, poiché ciò richiede lo spostamento di alcuni processi dal server di origine.
Ci sono casi in cui ha più senso, sia dal punto di vista dei costi che dal punto di vista dell'architettura del sistema, utilizzare server dedicati autogestiti o offerti come servizio. Ad esempio, applicazioni di grandi dimensioni con un carico di lavoro abbastanza costante e prevedibile possono richiedere una configurazione tradizionale e in questi casi la configurazione tradizionale è probabilmente meno costosa.
Inoltre, potrebbe risultare estremamente complicato migrare le applicazioni tradizionali su una nuova infrastruttura con un'architettura completamente diversa.
Cloudflare Workers è un prodotto che consente agli sviluppatori di scrivere funzioni JavaScript e distribuirle all'edge della rete Cloudflare, consentendo di eseguire il codice dell'applicazione in un'architettura serverless il più vicino possibile all'utente finale, riducendo al minimo la latenza e incarnando il principio secondo cui The Network is the Computer®.