Progettato nativamente per architetture di microservizi, il serverless è adatto per gestire applicazioni web, backend o IoT. Amazon Web Services ha aperto il mercato del cloud serverless con Lambda alla fine del 2014. Da allora ha notevolmente arricchito la sua offerta applicando l’etichetta serverless a un gran numero di servizi e arrivando a offrire infrastrutture serverless al 100%.
Con Api Gateway, Aws ha offerto in primo luogo un servizio proxy Api gestito, che consente di creare, gestire e monitorare Api (che danno accesso a dati, applicazioni o servizi Aws come EC2). In termini di database, il fornitore ha iniziato a passare alla sua soluzione NoSQL, DynamoDB, in modalità serverless.
Lo scorso novembre ha allargato lo spettro ai database relazionali svelando Aurora Serveless, una versione senza server della sua soluzione compatibile MySQL e PostgreSQL. Parallelamente, ha lanciato Fargate. Progettato per Amazon Ecs (Elastic container service) e Eks (Elastic container service for Kubernetes), questo servizio offre l’esecuzione di container senza dover gestire server o cluster. Per avviare un’applicazione tramite Fargate, è sufficiente pacchettizzarla in un livello contenitore, specificarne i requisiti di Cpu e di memoria e definire la politica di rete e di identificazione. Infine, Amazon commercializza Greengrass, un servizio progettato per eseguire le funzioni Lambda il più vicino possibile agli oggetti collegati.
Per accelerare l’adozione serverless, Aws ha presentato un Serverless application repository (Sam) su GitHub lo scorso febbraio, attraverso il quale i suoi clienti possono condividere le loro applicazioni senza server. Aws ha inoltre ampliato il numero di lingue supportate dalla sua offerta Lambda. Dopo Java, Python, JavaScript, Node.js e C#, ora è il turno di Go e .Net Core 2.0 a essere supportati dall’ambiente. Inoltre, vi è una serie di strumenti di sviluppo. Ad esempio, Cloud9 fornisce un ambiente per il test e il debug delle funzioni Lambda. CodeDeploy permette, attraverso un sistema di alias, di confrontare le prestazioni delle diverse versioni di una funzione Lambda. E X-Ray gestisce il debug di applicazioni distribuite, basate su un’architettura micro-service.
Serverless, la risposta di Microsoft
In versione stabile dal novembre 2016, Azure Functions offre un approccio paragonabile a quello di Amazon Lambda, compreso il prezzo. Il servizio Microsoft FaaS permette di attivare funzioni relative a servizi Azure (Cosmos DB, Storage, Event Grid, Mobile Apps, Notification Hubs…) o di terze parti (webhook GitHub, messaggi Sms Twilio). Fornisce un’ampia gamma di modelli per l’implementazione di diversi scenari. HttpTrigger attiva, per esempio, l’esecuzione del codice in seguito a una richiesta Http. QueueTrigger risponde ai messaggi che arrivano nella coda di archiviazione di Azure mentre EventHubTrigger reagisce agli eventi inviati da Azure Event Hub da un sito web, un’applicazione o un oggetto connesso.
Azure Functions supporta C#, F# e JavaScript ma anche Python, Php, Bash, Batch e PowerShell. Microsoft ha annunciato nel mese di settembre il supporto per Net Core 2.0 e, il mese successivo, Java. Attraverso un plugin Maven, uno sviluppatore può codificare e debuggare le funzioni Azure localmente da ambienti di sviluppo Eclipse, IntelliJ o Visual Studio Code (Ide). Nell’ultima versione (15.6), rilasciata all’inizio di marzo, Visual Studio 2017 supporta anche Azure Functions.
La gestione dei diritti di accesso è supportata da Azure Active Directory o dal servizio di identificazione gestito da OAuth. Azure Application Insights fornisce l’analisi e la supervisione delle funzioni. Infine, Azure Stack offre la possibilità di un cloud hosting misto pubblico, privato o ibrido.
E quella di Google
Varato da Google in versione alfa nel febbraio 2016, Cloud Functions è andato un anno più tardi in versione beta dove è ancora come spesso è successo per i servizi di Mountain View. Sulla base del principio FaaS, l’offerta serverless di Google può attivare funzioni in risposta agli eventi registrati sul suo cloud (Google Cloud Platform), come l’importazione di file su Cloud Storage, un messaggio in arrivo, i dati inviati da un oggetto collegato a Cloud Pub/Sub, o una modifica apportata a un log in Stackdriver Logging.
Tramite una richiesta Http, le Funzioni cloud possono rispondere a eventi provenienti da sistemi di terze parti come GitHub, Slack o Stripe. Gli sviluppatori di applicazioni mobili possono anche utilizzare le funzioni Cloud direttamente da Firebase, la piattaforma mobile di Google Cloud Platform. Le Funzioni Cloud reagiscono in particolare agli eventi derivati dai dati di Firebase Analytics.
Le funzioni Cloud sono codificate in JavaScript. L’esecuzione di quest’ultimo è supportata da un ambiente Node.js standard. A partire dall’acquisizione di Apigee da parte di Google nel settembre 2016, Google Cloud Functions è dotato di un servizio simile all’Amazon Api Gateway per dichiarare le risorse Rest e le funzioni associate. Il gran numero di offerte di lavoro pubblicate intorno ad Apigee illustra l’interesse di Google per questa tecnologia. Infine, il gigante di Mountain View offre uno strumento (chiamato Cloud functions emulator) per testare le funzioni serverless a livello locale prima che vengano implementate.
