Cos'è l'hosting serverless

Cos'è il serverless computing

Il serverless computing è un modello di cloud computing in cui il provider gestisce automaticamente l'infrastruttura server mentre tu ti concentri unicamente sul codice. Nonostante il nome, i server esistono ancora, ma non devi configurarli, mantenerli, aggiornarli o scalarli. Di tutto questo si occupa il provider, mentre tu scrivi funzioni che vengono eseguite in risposta a eventi. Paghi solo il tempo di esecuzione del codice, non un server in attesa di richieste.

Il concetto di serverless è nato dall'evoluzione del cloud computing. Dai server fisici siamo passati alle macchine virtuali, poi ai container e infine alle funzioni serverless. Ogni passaggio ha astratto sempre più infrastruttura dagli sviluppatori, permettendo loro di concentrarsi sulla logica di business. AWS Lambda, lanciato nel 2014, è stato il primo servizio serverless commerciale e ha dato il via a una rivoluzione nel modo di concepire l'hosting.

Come funziona il serverless

Functions as a Service (FaaS)

FaaS è il cuore dell'architettura serverless. Scrivi una funzione che esegue un compito specifico, per esempio elaborare un'immagine, inviare un'email o creare un PDF. Quella funzione viene impacchettata e caricata sulla piattaforma serverless. Quando si verifica un evento che attiva la tua funzione, come una richiesta HTTP, il caricamento di un file o un messaggio in una coda, la piattaforma avvia automaticamente un'istanza della tua funzione, la esegue e restituisce il risultato. Dopo l'esecuzione l'istanza si spegne. Se arrivano 1.000 richieste contemporaneamente, la piattaforma avvia 1.000 istanze in parallelo.

Backend as a Service (BaaS)

La componente BaaS del serverless fornisce servizi backend già pronti come database, autenticazione, archiviazione file e notifiche push sotto forma di servizi gestiti. Firebase di Google è il BaaS più diffuso e offre realtime database, autenticazione, cloud storage e hosting in un unico pacchetto. AWS Amplify combina le funzioni Lambda con il database DynamoDB, l'autenticazione Cognito e l'archiviazione S3. Supabase è un'alternativa open source a Firebase con un database PostgreSQL. Il BaaS elimina la necessità di scrivere codice backend standard per le operazioni più comuni.

Architettura event-driven

Le applicazioni serverless sono per natura event-driven, il che significa che il codice viene eseguito solo quando si verifica un evento specifico. Gli eventi possono essere richieste HTTP degli utenti, modifiche nel database, il caricamento di un file nello storage, un orario pianificato come un cron job, un messaggio in una coda di messaggi o dati di un sensore IoT. Questa architettura è naturalmente efficiente perché le risorse vengono consumate solo quando c'è lavoro da fare. Nel modello tradizionale il server è sempre in esecuzione e consuma risorse anche quando non c'è traffico.

Vantaggi del serverless

Scaling automatico

Le piattaforme serverless scalano automaticamente il tuo codice da zero a milioni di richieste senza alcuna configurazione. Non è necessario impostare regole di auto-scaling, definire un numero minimo e massimo di istanze o preoccuparsi di un load balancer. Se il tuo sito ha 10 visitatori a mezzanotte e 10.000 durante il picco del pomeriggio, il serverless si adatta automaticamente. Questo è particolarmente utile per le applicazioni con traffico imprevedibile, come i siti e-commerce durante i saldi o le campagne virali sui social media.

Pagamento a consumo

L'hosting tradizionale addebita un prezzo mensile fisso indipendentemente dal fatto che il server giri all'1 o al 100 percento della capacità. Il serverless addebita solo il tempo di esecuzione del codice, di solito in millisecondi, più il numero di invocazioni delle funzioni. AWS Lambda, per esempio, offre un milione di invocazioni gratuite al mese e 400.000 GB-secondi di tempo di calcolo gratuito. Per un piccolo sito con 50.000 richieste al mese, l'hosting serverless può essere praticamente gratuito. È ideale per startup e progetti in fase iniziale dove il budget va controllato con attenzione.

Manutenzione zero

Non devi preoccuparti di aggiornare il sistema operativo, installare patch di sicurezza, configurare il web server, gestire i certificati SSL o monitorare l'hardware. Il provider si occupa dell'intera infrastruttura, inclusi sicurezza, ridondanza e backup. Questo libera tempo del tuo team per il lavoro sul prodotto invece che sull'infrastruttura. Per un piccolo team o uno sviluppatore solitario è un enorme vantaggio, perché elimina la necessità di competenze DevOps.

Svantaggi del serverless

Il problema del cold start

Quando una funzione serverless non viene usata per un po', la piattaforma ne spegne l'istanza per risparmiare risorse. La richiesta successiva deve avviare una nuova istanza, il che introduce una latenza aggiuntiva nota come cold start. Un cold start può durare da 100 millisecondi per le funzioni Node.js fino a diversi secondi per le funzioni Java o C#. Per le applicazioni che richiedono tempi di risposta costantemente bassi, il cold start è un problema significativo. Le soluzioni includono la provisioned concurrency, che mantiene le istanze "calde", ma questo elimina il vantaggio del pagamento a consumo.

Vendor lock-in

Ogni provider cloud ha il proprio ecosistema serverless con API, strumenti e servizi specifici. Un'applicazione scritta per AWS Lambda usa API Gateway, DynamoDB e S3, che non hanno equivalenti diretti su Google Cloud o Azure. La migrazione verso un altro provider richiede una riscrittura significativa del codice. Framework come Serverless Framework o Terraform cercano di astrarre le differenze tra i provider, ma una portabilità completa è irrealistica, perché esistono differenze fondamentali nei servizi e nelle API.

Limiti di esecuzione

Le funzioni serverless hanno limiti sulla durata di esecuzione, sulla memoria e sulla dimensione del pacchetto. AWS Lambda ha una durata massima di 15 minuti per esecuzione, 10 GB di memoria e 250 MB per il pacchetto di deployment. Questo significa che le operazioni a lunga durata, come l'elaborazione di grandi file video, il machine learning complesso o l'elaborazione batch dei dati, non sono adatte al serverless. Il debug e il monitoraggio sono più complessi perché non hai accesso al server: usi strumenti cloud-native come CloudWatch o X-Ray.

Quando usare il serverless

Casi d'uso ideali

• Backend API: le API REST o GraphQL con traffico imprevedibile sono candidati perfetti perché scalano automaticamente e non costano nulla quando non ci sono richieste.
• Elaborazione di eventi: l'elaborazione di eventi come il caricamento di immagini, l'invio di email, la generazione di report o l'elaborazione di webhook.
• Attività pianificate: cron job che vengono eseguiti periodicamente, come la pulizia del database, la generazione di report giornalieri o la sincronizzazione dei dati.
• Chatbot: rispondere alle richieste degli utenti dove il traffico è imprevedibile e sporadico.
• Backend IoT: l'elaborazione dei dati dei sensori dove il numero di dispositivi può variare da 10 a 10.000.

Quando evitare il serverless

Il serverless non è ideale per le applicazioni con traffico costantemente elevato, perché sotto carico continuo un server fisso diventa più conveniente. Le applicazioni che richiedono processi a lunga durata, come il rendering video, le connessioni websocket o lo streaming, non rientrano nei limiti delle funzioni serverless. Le applicazioni con requisiti specifici di sistema operativo, hardware o software non disponibili sulla piattaforma serverless richiedono un hosting tradizionale. Le applicazioni legacy che mantengono uno stato tra le richieste sono difficili da migrare perché le funzioni serverless sono per natura stateless.

Serverless vs hosting tradizionale

Confronto per un piccolo sito

Per un piccolo sito con 10.000-50.000 visite al mese, un piano di shared hosting costa da 3 a 10 euro al mese e offre costi prevedibili, semplicità e supporto per PHP, WordPress ed email. Il serverless può essere gratuito o costare meno di 1 euro al mese per lo stesso traffico, ma richiede competenze tecniche per la configurazione e non supporta le piattaforme CMS tradizionali. Per i proprietari di piccoli siti che usano WordPress, l'hosting tradizionale è la scelta più pratica.

Confronto per una grande applicazione

Per una grande applicazione con milioni di richieste al giorno, un hosting avanzato con risorse dedicate costa da 50 a 500 euro al mese ma richiede un team DevOps per la gestione. Il serverless scala automaticamente senza intervento, ma i costi possono crescere rapidamente sotto un carico elevato e costante. Un approccio ibrido in cui il traffico di base è gestito da un server tradizionale mentre il serverless assorbe i picchi è spesso la soluzione ottimale, che combina la prevedibilità dei costi con l'elasticità dello scaling. In BeoHosting offriamo piani di hosting tradizionali ottimizzati per WordPress e applicazioni web con costi prevedibili e supporto tecnico completo, una soluzione più pratica dell'architettura serverless per la maggior parte degli utenti.

Conclusione

L'hosting serverless rappresenta un'evoluzione del cloud computing che elimina le preoccupazioni legate all'infrastruttura e consente di concentrarsi su codice e logica di business. Scaling automatico, pagamento a consumo e manutenzione zero sono vantaggi potenti per i casi d'uso giusti. Tuttavia, il problema del cold start, il vendor lock-in e i limiti di esecuzione rendono il serverless inadatto a tutti i tipi di applicazione. Comprendere i pro e i contro ti aiuta a prendere una decisione informata su se il serverless o l'hosting tradizionale si adatti meglio alle tue esigenze.