Che cos'è il serverless? Il serverless computing spiegato in modo semplice

Il serverless è un modo di eseguire codice in cui non configuri né gestisci alcun server. Affidi il tuo codice a un fornitore cloud, che lo esegue solo quando qualcosa lo attiva (una richiesta web, un file caricato, una notifica di pagamento) e poi si ferma. Di solito paghi il tempo in cui il tuo codice gira effettivamente, non una macchina ferma in attesa.

Perché il serverless conta quando crei con l'AI

Quando crei un'app con l'AI e guardi le opzioni di hosting o il codice, incontrerai « funzioni serverless », « funzioni edge » o « cloud functions ». Molte piattaforme di hosting le offrono, e alcuni builder AI distribuiscono i backend in questo modo. Capire il modello ti aiuta con tre domande pratiche:

• Costo. La tua app costerà denaro quando nessuno la usa?
• Velocità. Perché la prima richiesta dopo un periodo di calma è più lenta?
• Limiti. Perché un'attività lunga, come generare un grande report o elaborare un video, è andata in timeout?

Aiuta anche sapere cosa il serverless non è: non è l'assenza di un backend. Hai ancora codice lato server; semplicemente qualcun altro gestisce le macchine. Per le basi, vedi cos'è un server.

Un'analogia quotidiana

Un server tradizionale è come possedere un'auto. È sempre lì, pronta a partire all'istante, ma la paghi, tra assicurazione, parcheggio e manutenzione, che tu la usi o no.

Il serverless è come chiamare un taxi. Paghi solo le corse che fai, e se in cento hanno bisogno di un passaggio nello stesso momento, arrivano cento taxi. Però l'auto può mettere un po' di tempo ad arrivare (un cold start), ogni corsa ha una durata massima, e l'autista non si ricorda di te dalla corsa precedente (le funzioni sono stateless, senza stato).

Come funzionano le funzioni serverless

In una forma molto diffusa, chiamata functions as a service:

1. Scrivi una funzione, cioè un piccolo pezzo di codice che gestisce un tipo di evento, come « gestisci un POST su /api/bookings ».
2. La distribuisci. Il fornitore la memorizza e la collega a un trigger: un URL, una pianificazione, un nuovo file in archiviazione, un messaggio in una coda.
3. Arriva un evento. Il fornitore avvia una copia della tua funzione (o riutilizza una già calda), la esegue e restituisce il risultato.
4. Scala da solo. Se arrivano mille richieste insieme, il fornitore esegue molte copie in parallelo, fino ai limiti del tuo account.
5. Diventa inattiva. Quando il traffico si ferma, le copie vengono spente. Senza nulla in esecuzione, non paghi nulla per il calcolo.

Una piccola funzione serverless in JavaScript potrebbe somigliare a questa:

export default async function handler(request) {
  const { name } = await request.json();
  return Response.json({ message: `Ciao, ${name}` });
}

Non c'è codice per avviare un server, aprire una porta o mantenere un processo in esecuzione. È la piattaforma a occuparsi di tutto questo.

« Serverless » viene usato anche in modo più ampio per altri servizi gestiti che si scalano automaticamente e si pagano in base all'uso, come i database serverless, che vanno in pausa quando sono inattivi.

Termini chiave

Un esempio pratico: un piccolo sito di prenotazioni

Il sito di prenotazioni di uno studio di yoga riceve un picco di visite ogni domenica sera, quando viene pubblicato il nuovo calendario, e pochissimo nel resto della settimana.

• Con un server sempre acceso, lo studio paga una macchina 24 ore su 24, dimensionata per il picco di domenica sera, e per lo più inattiva il resto del tempo.
• Con funzioni serverless, GET /api/classes e POST /api/bookings sono funzioni. Il picco della domenica avvia automaticamente molte copie; un martedì mattina tranquillo non gira quasi nulla e la bolletta è vicina a zero.

Anche i compromessi si fanno sentire. La prima persona che apre il sito il martedì mattina potrebbe aspettare un attimo in più per un cold start. Il database deve gestire molte connessioni brevi provenienti da molte copie di funzioni, il che può richiedere un pooler di connessioni. E se lo studio in seguito vorrà un'attività « genera il PDF annuale delle presenze di tutti », potrebbe superare il limite di tempo della funzione e dover girare altrove.

Quando il serverless funziona, e quando no

Idee sbagliate comuni

• « Serverless significa nessun backend. » Significa nessun server da gestire. Scrivi e proteggi ancora codice backend.
• « Il serverless costa sempre meno. » È economico a volumi bassi, ma il prezzo per richiesta può salire molto con volumi alti e costanti.
• « Il serverless scala all'infinito. » Le piattaforme hanno limiti di concorrenza, e il tuo database può diventare il collo di bottiglia molto prima delle funzioni.
• « I file salvati in una funzione ci saranno la prossima volta. » L'archiviazione locale è temporanea. Usa un database o uno storage di file.
• « Scale-to-zero è la stessa cosa di serverless. » Sono collegati ma non identici. Alcune piattaforme eseguono la tua app come un normale server che va in sospensione quando è inattivo e si risveglia alla richiesta successiva: risparmi simili e un ritardo simile alla prima richiesta, ma senza i limiti di tempo per singola richiesta tipici delle funzioni.

Cosa chiedere al tuo builder AI

• « Questo backend girerà come funzioni serverless, come server sempre attivo o come server che va in sospensione? Cosa significa per il costo? »
• « Alcune attività probabilmente supereranno il limite di tempo della piattaforma? In tal caso, come le gestiamo? »
• « Conserva tutto ciò che deve persistere nel database o nello storage dei file, non in memoria o in file locali. »
• « Come vanno gestite le connessioni al database se girano molte copie contemporaneamente? »
• « Quanto ritardo c'è sulla prima richiesta dopo che l'app è stata inattiva? »

Come Mythex ospita le app

Mythex non descrive il proprio hosting come funzioni serverless. Quando pubblichi, la tua app gira come un'app web o un container normale che Mythex gestisce per te: non c'è alcun hosting da configurare. È scale-to-zero: le app pubblicate e i loro database vanno in sospensione quando sono inattivi e si risvegliano alla visita successiva; un'app in sospensione non costa nulla in calcolo, e le macchine extra partono solo quando il traffico è intenso (il piano Pro ne consente fino a 3 per servizio). Il database Postgres collegato va anch'esso in sospensione dopo 5 minuti di inattività e viene fatturato per il tempo in cui è rimasto sveglio. Quindi ottieni gran parte del vantaggio « paghi quello che usi », con lo stesso tipo di ritardo alla prima richiesta dopo un periodo di calma. Vedi limiti di hosting nella documentazione e le nostre guide su cos'è il web hosting e come ridurre i costi di hosting.

Domande