Recentemente abbiamo voluto fare un esperimento: il porting di una web app tradizionale in un paradigma serverless. Avevamo diversi obiettivi in mente:
- Valutare lo sforzo, in termini di tempo e risorse, per un porting di piccole dimensioni verso un paradigma serverless
- Mantenere quanto più invariato possibile il codice della web app di partenza
- Sperimentare l’uso e l’integrazione degli strumenti serverless offerti da AWS (Amazon Web Services).
Generazione e setup iniziali con Amplify
Per prima cosa abbiamo generato una nuova applicazione e configurandola secondo le specifiche di AWS Amplify: il servizio che si sarebbe poi occupato del build e del deploy della nostra serverless application.
Dopo aver generato lo scheletro dell’applicazione utilizzando il framework prescelto (nel nostro caso Quasar per Vue3) abbiamo installato Amplify come pacchetto aggiuntivo del progetto:
$ quasar create serverless_test$ npm install -g @aws-amplify/cli
Forse inaspettatamente, questo passaggio è stato del tutto indolore. Amazon ha lavorato sodo per rendere l’integrazione dei suoi servizi quanto più veloce possibile con praticamente qualsiasi progetto e dopo aver seguito l’utilissimo wizard di configurazione di Amplify ci siamo ritrovati tra le mani un’applicazione già buildabile e deployabile su AWS senza ulteriori sforzi. Sfortunatamente, le cose si sarebbero complicate di lì a poco.
Dopo aver integrato Amplify col nostro progetto ci siamo dovuti occupare di configurare un apposito file YAML che specificasse, fase per fase, le regole di build dell’applicazione.
Come vediamo, ce la siamo cavata con sole 24 righe di codice. Tuttavia, nello scriverlo, ci siamo anche resi conto che un’applicazione più complessa ed estesa potrebbe richiedere uno sforzo potenzialmente intenso per strutturare correttamente queste configurazioni.
Una volta configurati i comandi di build ci siamo concentrati su un modulo naturalmente spinoso: authentication e login.
Per questo modulo, in linea con gli obiettivi che ci eravamo prefissati, e anche per non “mescolare” servizi di provider diversi, abbiamo deciso di svilupparlo sfruttando Cognito, il servizio di auth fornito da AWS.
Proprio come per l’integrazione di Amplify, anche quella di Cognito è stata relativamente semplice, ma la mancanza di supporto nativo per il framework di sviluppo da noi prescelto ci ha costretti a modificare alcuni file di configurazione di Quasar per rendere compatibile il processo di build dell’applicazione con i moduli di Amplify/UI.
Modifiche di questo tipo e di questa natura richiedono conoscenze estremamente avanzate, non solo di programmazione, ma anche riguardo al funzionamento “dietro le quinte” dei potenti framework di front end development a cui ci siamo abituati. Questo grosso ostacolo rende impossibile, senza interventi specifici e complessi, l’utilizzo di framework differenti da quelli con cui Amplify è nativamente compatibile (Vue, React, Angular).
Superato anche questo ostacolo ci siamo potuti dedicare alle API. Nessuna particolare novità o difficoltà qui: le API si scrivono sostanzialmente allo stesso modo di una web app tradizionale, e sarà poi Amplify a preoccuparsi di trasformarle in quelle che AWS chiama “lambda functions”, ossia delle FaaS che possono operare in regime serverless.
confronto tra un API tradizionale (sopra) e una serverless (sotto)
Conclusioni
L’intero porting ha richiesto circa 10 giorni lavorativi, compreso lo studio dei servizi serverless AWS e la loro implementazione.
- I vantaggi sono principalmente a livello operations (provisioning e gestione dei server, costi allineati all’uso reale).
- La complessità per gli sviluppatori aumenta, soprattutto se non utilizzano strumenti o framework previsti dal vendor.
- L’assenza di controllo delle logiche server-side rende difficile implementare le richieste più specifiche dei clienti (es: extra security layers).
- Si riduce il carico di lavoro per i sistemisti, in quanto il processo di provisioning, dimensionamento, e gestione dei server è del tutto demandato al vendor prescelto.
