SST: il futuro del serverless su AWS

Trovare strumenti che coniughino semplicità, potenza e flessibilità nel mondo del cloud è tutt’altro che scontato. Oggi vogliamo condividere la nostra esperienza con SST (Serverless Stack), un framework open-source che ha cambiato profondamente il nostro approccio allo sviluppo serverless su AWS, permettendoci di costruire applicazioni cloud native con una velocità e un livello di controllo che non avevamo mai sperimentato con strumenti analoghi.

SST semplifica drasticamente lo sviluppo di applicazioni serverless su AWS, ma la sua caratteristica più distintiva non è la semplicità in sé, bensì il modo in cui riesce a preservarla senza rinunciare alla potenza. A differenza di strumenti come AWS SAM o del CDK grezzo, SST offre un livello di astrazione ben calibrato: espone costrutti di alto livello per le risorse più comuni, come API Gateway, DynamoDB, S3 e code SQS, mantenendo però pieno accesso alle configurazioni CDK sottostanti quando il progetto lo richiede. Questo equilibrio tra convenienza e controllo è esattamente ciò che manca alla maggior parte degli strumenti serverless disponibili.

La filosofia alla base di SST è chiara: eliminare il divario tra l’ambiente di sviluppo locale e quello di produzione cloud. La funzionalità Live Lambda Development è l’implementazione concreta di questa idea. Anziché ridistribuire le funzioni Lambda ogni volta che si apporta una modifica, SST intercetta le invocazioni in tempo reale e le instrada verso il codice in esecuzione sulla macchina locale dello sviluppatore, con i tempi di risposta di un normale server locale e i log accessibili direttamente nel terminale. I tempi di sviluppo nel nostro team si sono ridotti in modo significativo grazie a questa funzionalità, principalmente perché l’hot-reloading ci ha permesso di iterare su logiche complesse senza aspettare cicli di deploy che prima interrompevano il flusso di lavoro decine di volte al giorno.

HeroHubs ha adottato SST per alcuni progetti chiave e i risultati hanno superato le aspettative. L’onboarding dei nuovi collaboratori, che con altri framework richiedeva settimane di familiarizzazione con strumenti cloud spesso poco documentati, ora avviene in pochi giorni. Il codice di infrastruttura è scritto in TypeScript con pieno supporto ai tipi, il che significa che gli errori di configurazione vengono intercettati a compile time invece che durante un deploy fallito alle due di notte. I deployment basati su SST si sono dimostrati più affidabili e privi di sorprese, perché il sistema di ambienti distinti garantisce che ciò che funziona in locale funzioni anche in staging e produzione, riducendo drasticamente le sessioni di debug post-deploy che prima erano la norma.

Vantaggi

I vantaggi di SST si distribuiscono su più livelli. Sul piano tecnico, la configurazione type-safe dell’infrastruttura è uno degli aspetti più apprezzati: definire una API con i relativi handler Lambda, collegare una tabella DynamoDB e configurare i permessi IAM necessari richiede poche righe di TypeScript, e il compilatore verifica la coerenza di queste definizioni prima ancora che il codice arrivi su AWS. Questo riduce drasticamente la categoria di errori più costosi, quelli che si manifestano solo in ambiente cloud dopo un deploy. La possibilità di definire l’intera infrastruttura come codice ha inoltre reso possibile replicare rapidamente l’intera pipeline per nuovi clienti o casi d’uso, accelerando i tempi di implementazione e riducendo il rischio di errori di configurazione che con la console AWS sarebbero stati difficili da tracciare.

Sul piano economico, l’approccio pay-per-use del serverless ottimizzato da SST ha ridotto i costi operativi rispetto alle architetture a server dedicati. Le applicazioni scalano automaticamente in base al carico senza richiedere interventi manuali, e nei momenti di basso utilizzo il costo scende proporzionalmente, liberando budget per altre aree del progetto. La scalabilità non richiede di gestire bilanciatori di carico, gruppi di auto scaling o capacità riservate: tutto è gestito dall’infrastruttura AWS sottostante, con SST che si occupa di esporre queste capacità in modo coerente e testabile. Questo significa che il team può ragionare su costo e prestazioni allo stesso livello di astrazione in cui scrive il codice applicativo, senza dover passare da un modello mentale all’altro tra logica di business e configurazione dell’infrastruttura.

Ecosistema e curva di apprendimento

Chi si avvicina a SST per la prima volta trova una documentazione ben strutturata e una comunità attiva, cresciuta rapidamente intorno al progetto dopo la transizione dalla versione 2 alla versione Ion, che ha portato un’architettura ancora più orientata ai costrutti CDK nativi. I canali Discord del progetto sono tra i più reattivi nell’ecosistema serverless AWS, il che conta in pratica quando ci si trova di fronte a un comportamento inatteso in produzione.

La curva di apprendimento è reale, in particolare per chi non ha esperienza con il CDK o con TypeScript, ma è gestibile e si concentra nei primi giorni. Una volta superata questa fase iniziale, il framework diventa un moltiplicatore di produttività: ci ha permesso di dire sì a progetti che in passato avremmo rifiutato per questioni di tempistiche o complessità tecnica, perché la struttura che SST impone al codice di infrastruttura rende prevedibile anche ciò che in altri contesti sarebbe rimasto opaco.

La nostra esperienza conferma che il passaggio a SST non è solo un cambio di strumento, ma un cambiamento nel modo di concepire il rapporto tra codice applicativo e infrastruttura cloud. Le due cose vivono nello stesso repository, parlano lo stesso linguaggio e vengono testate con lo stesso rigore, e questa coerenza si traduce in meno sorprese e in una maggiore capacità di concentrarsi sulla logica di business che genera valore reale.