Serverless non significa "senza server"
Il termine "serverless" e fuorviante: i server esistono, semplicemente non li gestisci tu. Il cloud provider (AWS, Google Cloud, Azure) si occupa di provisioning, scaling, patching e monitoring dell'infrastruttura. Tu deployi codice e paghi per esecuzione — niente VPS da mantenere, niente Apache da configurare, niente aggiornamenti di sicurezza del sistema operativo.
Per anni, PHP e stato escluso dal mondo serverless dominato da Node.js e Python. Bref ha cambiato le cose: e un runtime PHP open-source per AWS Lambda che permette di deployare applicazioni PHP — incluse applicazioni Laravel e Symfony — su infrastruttura serverless.
Come funziona Bref
Bref fornisce Lambda layers con il runtime PHP precompilato. Il tuo codice viene impacchettato e caricato su Lambda. Quando arriva una richiesta, Lambda avvia un'istanza del runtime, esegue il codice e restituisce il risultato. Se arrivano 1000 richieste simultanee, Lambda avvia 1000 istanze. Se non arrivano richieste per 15 minuti, le istanze vengono terminate. Paghi solo per il tempo di esecuzione effettivo.
Bref offre tre modalita:
- Web function: gestisce richieste HTTP tramite API Gateway. Adatta per applicazioni web complete.
- Event-driven function: risponde a eventi (SQS, S3, EventBridge). Adatta per job, processing, integrations.
- Console function: esegue comandi CLI (Artisan, Symfony Console). Adatta per cron job e task schedulati.
Vantaggi concreti
- Costo a consumo: paghi per millisecondo di esecuzione. Un'applicazione con poco traffico costa centesimi al mese. Un VPS costa 5-20 EUR/mese anche se non riceve traffico.
- Scaling automatico: da 0 a migliaia di istanze senza configurazione. Nessun capacity planning, nessun autoscaling group da configurare.
- Zero manutenzione server: niente aggiornamenti OS, niente patch di sicurezza, niente monitoring dell'infrastruttura.
- Deploy atomici: ogni deploy e una nuova versione della funzione. Rollback istantaneo alla versione precedente.
I limiti reali
- Cold start: la prima invocazione dopo un periodo di inattivita richiede 200-800ms per avviare il runtime PHP. Per applicazioni interattive con requisiti di latenza stretti, può essere un problema.
- Tempo massimo di esecuzione: Lambda ha un timeout di 15 minuti. Job di lunga durata non sono adatti.
-
Filesystem effimero:
/tmpha 512MB-10GB ma viene cancellato tra le invocazioni. File upload e processing richiedono S3. - Sessioni: senza filesystem persistente, le sessioni PHP devono usare DynamoDB, Redis o un altro store esterno.
- Vendor lock-in: il codice diventa dipendente da AWS. Migrare a un altro provider o a un VPS richiede lavoro.
Casi d'uso ideali per PHP serverless
- API con traffico variabile: un'API che ha picchi durante il giorno e zero traffico di notte. Paghi solo quando viene usata.
- Webhook e integrazioni: endpoint che ricevono callback da servizi esterni (Stripe, GitHub, Mailgun). Traffico imprevedibile e sporadico.
- Processing asincrono: generazione PDF, resize immagini, invio email batch. Event-driven, senza server dedicato.
- Cron job: task schedulati che girano per pochi secondi al giorno. Pagare un VPS 24/7 per 30 secondi di lavoro non ha senso.
Quando NON usare serverless
- Applicazioni con traffico costante: se il server e sempre occupato, un VPS dedicato costa meno di Lambda
- WebSocket e connessioni persistenti: Lambda non supporta connessioni long-lived
- Applicazioni con stato locale: file system, cache in-memory, sessioni PHP native non funzionano
- Team senza esperienza AWS: la curva di apprendimento di IAM, API Gateway, CloudFormation e reale
Serverless PHP con Bref non e la soluzione universale, ma per i casi d'uso giusti — traffico variabile, processing asincrono, cron job — offre un rapporto costo/semplicità che nessun VPS può eguagliare. Il futuro di PHP non e solo Apache su un server: e anche funzioni che si avviano in millisecondi e si spengono quando non servono.
Top comments (0)