Da allora sono cambiate molte cose, ma alcuni concetti sono rimasti simili.
La grande novità, presente anche nel 2015, ma non così evoluta, è la presenza sul mercato di piattaforme che permettono di realizzare delle soluzioni completamente scalabili, senza installare nulla, ma solamente basando si servizi da acquistare e pagare a consumo.
Si parla quindi di architetture "Serverless". Questo non è da interpretare letteralmente come architetture che non hanno necessità di server, ma come architetture dove ci si concentra nell'utilizzo di servizi e non nell'installazione e configurazione di server.
Un tempo dovevo comperare un server, installare e configurare un database, aggiungere un bilanciatore etc. Oggi posso affittare un sistema di cache, un database, un sistema di autenticazione e far parlare fra di loro questi servizi servizi, riducendo di molto il tempo di sviluppo.
Probabilmente i costi saranno più alti di una soluzione completamente sviluppata in casa, ma ci sono da considerare parecchi aspetti, come l'affidabilità, la scalabilità, il numero inferiore di persone necessarie a configurare e monitorare il sistema e così via.
Diventa così complicato fare subito i conti di quanto potrebbe costare la soluzione serverless completamente in cloud o gestita on premise.
Per questi motivi, probabilmente la soluzione serverless che nasce in cloud è la più indicata per una startup o per un progetto che deve partire ed arrivare a un POC o a un MVP, mentre la soluzione on premise potrebbe essere quella indicata nel momento in cui si dovesse entrare in aziende già strutturate, nelle quali i costi di datacenter sono già a bilancio ed aggiungere altre soluzioni da monitorare non alza di molto l'asticella dei costi.
Al netto di questo, vediamo quali sono i passi da compiere per realizzare una architettura serverless.
Come si costruisce un'architettura serverless?
Proviamo a spiegarlo partendo da questa immagine e usando i servizi AWS come termine di paragone:
Il primo passo è sicuramente quello di costruire una interfaccia WEB.
Nel 2020 le soluzioni sono sicuramente molte. Quelle che vanno per la maggiore sono:
* Angular
* React
* Vue
* Svelte
I primi due progetti nascono da aziende come Google e Facebook, e godono del supporto di grandi comunità, i successivi due sono invece progetti partiti da "one man band": programmatori forti delle esperienze fatte con i due framework precedenti, che hanno voluto creare qualcosa di nuovo e semplice da utilizzare.
Se vogliamo guardare il mercato, c'è sicuramente un orientamento verso Angular, ma nessuno ci vieta di considerare altre soluzioni, magari più leggere come Svelte, o magari anche fuori da questa lista.
In generale l'orientamento rimane quello di delegare parte dell'elaborazione e della reattività dei programmi ai browser, che hanno raggiunto ormai un ottimo livello di stabilità e una certa concentrazione verso un consolidato numero di funzionalità, sufficienti per la realizzazione di moltissime applicazioni.
Dove mettiamo la nostra applicazione?
Al netto di qualsiasi scelta vanga fatta, in una architettura "tradizionale" i sorgenti delle applicazioni sarebbero inseriti all'interno di un server (normalmente Apache o Nginx).
Questo tipo di server sono però pensati per architetture dinamiche. Per velocizzare la fruizione dei contenuti l'orientamento comune è ormai quello di usare delle CDN nelle quali inserire i dati statici. Questo tipo di approccio permette di avere dei server distribuiti a livello geografico e di poter diminuire la distanza fra chi richiede un contenuto e chi lo mette a disposizione.
Nel caso di AWS questa funzionalità è messa a disposizione da CloudFront.
Ora che abbiamo l'applicazione online, possiamo iniziare a pensare alle sue funzionalità.
Come costruiamo i nostri servizi?
Per fare questo ci sono almeno due scuole di pensiero: l'utilizzo di servizi REST o GraphQL. In entrambi i casi si tratta di servizi, server side, invocati da un backend o da un frontend, in grado di occuparti dell'esposizione dei dati e della business logic applicativa.
Dato che si tratta di meccanismi standard, generalmente stateless, davanti a questi servizi vengono messi degli Api Gateway in grado di orchestrare e gestire API da fonti diverse, dando un unico endpoint di ingresso.
Questo approccio permette di cambiare le API di backend, senza alterare la parte di frontend, e di distribuire meglio il carico al cambiare dell'utilizzo delle singole API.
Ci sono varie soluzioni che permettono la gestione di un API Gateway, nel caso di AWS una delle strade indicate è quella dell'uso di funzioni lambda. Si tratta di funzioni in grado di ricevere un evento e restituire un risultato, scalate in automatico da AWS ed in grado di utilizzare risorse esterne: database, storage etc.
Cosa abbiamo ottenuto?
Facciamo quindi un'ipotesi di una semplice applicazione serverless, in grado di scalare in automatico, in base al crescere del traffico dei nostri servizi, mettendosi nei panni di programmatore Pinco Pallino qualsiasi.
Senza soffermarci sull'ordine delle cose, vediamo quali sono i passi che dovremo compiere per portare online l'applicazione.
- Creazione delle funzioni in grado supportare il nostro business e dei relativi test e modellazione dei dati tramite un database (p.e. RDS)
- Rilascio delle funzione come Lambda e creazione delle relative API tramite API Gateway
- Realizzazione del frontend tramite Angular
- Rilascio applicazione su CloudFront
A questo punto, se gli utilizzatori dovessero aumentare, il frontend scalerà grazie all'uso delle CDN, il backend grazie all'uso di Lambda e il database grazie al servizio che ci espone le sue API.
Nessun server, sistema di cache, web server e database installato, solo molta configurazione fra servizi e business logic.
Per un esempio vi rimando a questa WepApp Serverless fornita da Amazon.
Conclusioni
Oggi realizzare applicazioni basandosi totalmente su servizi è possibile, non in tutti i casi, ma in molti contesti si.
Quando conviene farlo? Forse non c'è una risposta sola a questa domanda, sicuramente la soluzione è da analizzare, per capire quale sia il fornitore migliore di servizi da utilizzare, o quale sia la soluzione migliore da installare on premise, ma escludere a priori questa scelta per paura di costi o di predominio della propria architettura, potrebbe essere un errore da pagarsi più avanti in ottica di scalabilità e stabilità delle proprie soluzioni.