1. Cloud
2. Programmazione
3. Serverless

di Alessandro Davanzo

Per architettura serverless si intende un nuovo paradigma informatico che permette all’utilizzatore di sviluppare soluzioni e servizi senza che ci si debba occupare dell’implementazione dell’architettura server necessaria per l’erogazione dei servizi stessi.
In poche parole è qualcosa che permette di sviluppare applicazioni e servizi di vario genere (vedremo in seguito quali possono essere) prescindendo dal substrato hardware, ossia dai server e dalle architetture di rete che sarebbero necessari.

In questo tutorial verrà esteso il concetto spiegando che cos’è l’architettura serverless e paragonandola, per maggiore chiarezza, ad altre soluzioni che negli anni si sono avvicendate nel mondo dell’informatica e dell’IT.

Da server locale a serverless

Che cosa significa Serverless? Il concetto nasce dal poter eseguire applicazioni senza avere fisicamente un hardware correlato, ovvero lavorare a un livello di astrazione talmente alto che il provider che offre il servizio mette a disposizione un’interfaccia nella quale si sviluppano le applicazioni senza sapere né preoccuparsi di cosa sta dietro, ovvero di quale hardware ha il provider stesso.

Per arrivare a capire che cos’è il Serverless dobbiamo capire da cosa nasce questo concetto; ebbene, il primo passo che ha portato verso questa soluzione è il cloud, che ha permesso di realizzare applicazioni e servizi senza né avere fisicamente dei server, né preoccuparci di qual è l’hardware su cui girano.
Nel Cloud, grazie a delle macchine virtuali configurabili per soddisfare i requisiti delle applicazioni è possibile delocalizzare queste ultime ed eseguirle senza disporre fisicamente e localmente l’hardware. Quindi il Cloud ha permesso di trasformare quello che prima era una componente fisica in una componente logica, giacché l’hardware non è più presso il cliente ma tutto delocalizzato nel provider.

Il secondo passo che ha portato al Serverless è lo IAAS, ossia l’Infrastructure As A Service, che corrisponde all’implementazione di un’infrastruttura informatica virtualizzata; né lo IAAS né il Cloud sono, però, Serverless.
L’immagine seguente schematizza il concetto di IAAS implementato in un’infrastruttura messa a disposizione da un provider, nel quale l’utente può crearsi una o più macchine virtuali eseguite grazie a un hypervisor che gira su un sistema operativo host.

L’adozione delle macchine virtuali apporta benefici come una migliore gestione delle risorse e inoltre:

• una macchina fisica può essere divisa in più macchine virtuali;
• il sistema è più facile da scalare;
• l’utilizzo delle VM nel cloud apporta elasticità rapida e modello Pay as you go (immagine seguente).

L’adozione delle macchine virtuali non è, comunque, sempre conveniente, perché implica delle limitazioni perché ogni Virtual Machine richiede:

• allocazione di CPU;
• memoria di storage;
• RAM;
• un intero sistema operativo guest.

Inoltre va considerato che più macchine virtuali si mettono in esecuzione, di più risorse si ha bisogno e che un sistema operativo sulle macchine virtuali significa più consumo di risorse; inoltre la portabilità dell'applicazione, sebbene sia facilitata, non è garantita.

Un’estensione del concetto di macchina virtuale è il Container, che sostanzialmente nasce dalla considerazione che non ha senso virtualizzare un’intera macchina, quando si può virtualizzare solamente una piccola parte di essa. Ecco, il container in un certo senso fa questo. Il container:

• standardizza il deployment del software;
• permette l’isolamento delle applicazioni;
• condivide il kernel del sistema operativo;
• rende l’applicazione non più difficile da scalare.

Il container permette di impacchettare l’applicazione con tutto ciò di cui necessita: per esempio le librerie, le dipendenze, gli strumenti di sistema e tutto quello che si può installare in un server. L’impacchettamento dà allo sviluppatore la certezza che l’applicazione venga eseguita in qualsiasi server, giacché prescinde dai requisiti di sistema perché nel container si trova tutto l’occorrente all’esecuzione: è come avere una valigia degli attrezzi completa per eseguire un lavoro, che quindi prescinde dall’avere l’occorrente sul posto.

Con riferimento all’immagine precedente, la macchina virtuale utilizza uno stack dove alla base c’è l’hardware (Infrastructure) sopra il sistema operativo Host (quello che gira realmente sull’hardware) un Hypervisor che serve a far eseguire le macchine virtuali. Sopra abbiamo il complesso della macchina virtuale, ossia il sistema operativo guest (quello della macchina virtuale), sopra i binari e le librerie occorrenti all’esecuzione e in cima l’applicazione. Ciò implica che tutte le macchine virtuali in esecuzione fanno uso di un kernel separato e unico.
Guardiamo adesso lo stack del container, che ha i primi due livelli uguali ma nel terzo abbiamo il motore Docker che avvia i container; sopra abbiamo ancora librerie e binari necessari all’esecuzione delle applicazioni e le applicazioni stesse. La differenza sostanziale è che i container, a differenza delle VM, condividono il kernel (immagine seguente).

L’efficienza dei container è dovuta al fatto che essi vengono gestiti come processi isolati tra loro all’interno del sistema operativo host; altro vantaggio è che i container non sono vincolati ad alcuna infrastruttura hardware, quindi i container sono una forma di virtualizzazione a livello di sistema operativo.
I container costituiscono un’alternativa alla virtualizzazione e presentano un comportamento analogo a quello delle VM relativamente all’isolamento delle risorse del sistema e ai benefici dell’assegnazione delle risorse; l’utilizzo dei container può quindi essere considerato “figlio” della virtualizzazione.
Tuttavia, diversamente dalle VM, i container sfruttano un altro approccio che consente loro di essere più efficienti e più trasportabili. Queste caratteristiche intrinseche del sistema a container portano ad alcuni vantaggi:

• possiamo avere tantissimi container sul nostro PC per avere a portata di mano un ambiente di deployment o test adatto a ciascuna applicazione in sviluppo;
• le attività di testing in cloud sono meno costose, perché se si “testa” un’applicazione su un server cloud pubblico si paga in funzione del tempo di utilizzo delle risorse computazionali, quindi siccome con un container si utilizzano sempre le stesse risorse computazionali il costo scende;
• invece di obbligare gli sviluppatori a installare e configurare servizi per disporre della piattaforma necessaria alle proprie applicazioni, è meno oneroso e più rapido avviare ed eseguire con piccoli script i pochi container che ospitano le applicazioni.

Il più importante vantaggio offerto dal sistema a container è la portabilità. Inoltre il formato consente l’esecuzione su diversi host perché con la standardizzazione dei container, i workload possono essere facilmente spostati dove vengono eseguiti, evitando anche i lock-in dovuti alle peculiarità delle piattaforme dei singoli provider.

Un esempio di soluzione per la creazione di container è Docker, ma i container sono qualcosa che risale a molto tempo fa e sono nati in casa Linux.

I container rappresentano quindi una forma di astrazione più elevata delle macchine virtuali, ma non sono ancora un’architettura Serverless, in quanto quando si sviluppano più applicazioni su una macchina virtuale, come ad esempio una in PHP, una in Apache e una in MySPL e ad esempio si utilizza Ngnix come load balancer, bisogna sviluppare tre container ed occorre tenere conto della rete che lavora per questi container. Inoltre i container vanno personalizzati in base alle nostre esigenze, quindi si parte da un’immagine base, ma per avere determinate funzionalità bisognerà eseguire dei comandi per abilitare le librerie occorrenti.

Ma allora, cosa significa Serverless? Ebbene, questo paradigma si spiega con un acronimo: FaaS, che significa Function as a Service.
FaaS è una delle tecnologie che possono essere considerate serverless.
In pratica è lo sviluppo di singole funzioni che vengono eseguite al verificarsi di determinati eventi. Si basa sulle Function: per esempio si scrive uno script in un determinato linguaggio e lo si manda in esecuzione, quindi dal provider si va a inserire lo script, che viene eseguito senza curarsi di hardware, linguaggi, ambienti, librerie presenti e lo script viene eseguito al verificarsi di determinati eventi. L’immagine seguente propone un esempio di architettura totalmente serverless.

In essa vedete un applicativo in cui tutte le parti come l’hosting, il database, l’invio dei messaggi, l’esecuzione delle macchine back-end ecc sono tutti servizi serverless.

Serverless: provider e tecnologie

Diamo un rapido sguardo ai provider in grado di supportare il serverless e che sono essenzialmente:

• Amazon Web Service;
• Google Cloud;
• Microsoft Azure.

Oltre a questi va menzionata Apache OpenWhisk, che non è un provider ma piuttosto una piattaforma cloud open source serverless che esegue funzioni in risposta a eventi di qualsiasi dimensione; nello specifico è erogata dal Cloud di IBM e serve a sviluppare applicazioni FaaS. Si tratta, nello specifico, di una piattaforma FaaS platform totalmente basata su Cloud, che va ad eseguire funzionalità in risposta a determinati eventi. Il gestore del servizio infatti più impostare delle regole che possono essere attivate ed eseguite a seguito di specifici eventi. Con Apache OpenWhisk è possibile creare delle regole e delle azioni, testarle, connetterle con altre azioni ed eseguire il debug di queste ultime.

Una delle caratteristiche chiave di Apache OpenWhisk è la sua natura Serverless, perché il suo network non è centrato su dei server ma viene dislocato tra i vari utenti e il lavoro di gestione del network viene eseguito dagli stessi utilizzatori, risparmiando a team di sviluppo i costi dei server e il lavoro di manutenzione di questi ultimi.

Lo schema architetturale adottato da Apache OpenWhisk è molto simile a quello di AWS Lambda e Azure Function, anche se differisce nella terminologia; in esso abbiamo:

• Action: sono le funzioni che possono essere definite e richiamate all’interno del sistema
• Event source: sorgenti generiche di eventi, i quali possono essere iniettati nel sistema
• Trigger: quando si verifica un determinato evento il trigger associato a quella classe di eventi scatta
• Rule: è la regola che permette di associare un trigger ad un action. In questo modo quando scatta il trigger viene richiamata la corrispondente action.

Le funzioni, ovvero gli script, possono essere realizzate in JavaScript, Swift, Python, Java, PHP, Docker ecc.

Passiamo ora alle piattaforme vere e proprie, riepilogando nella tabella seguente quanto attiene ad Amazon Web Service.

AWS Lambda	consente di eseguire codice senza dover effettuare il provisioning né gestire server
Amazon API Gateway	creazione, pubblicazione, manutenzione, monitoraggio e protezione delle API
Amazon S3	soluzione di storage per oggetti sicura, durevole e altamente scalabile
Amazon DynamoDB	servizio di database NoSQL veloce e flessibile pensato per tutte le applicazioni che richiedono una latenza costante non superiore a una decina di millisecondi
Amazon SNS	servizio di messaggistica PUB/SUB completamente gestito
Amazon SQS	servizio di accodamento completamente gestito che semplifica la separazione e la scalabilità di microservizi
Amazon Kinesis	piattaforma per lo streaming di dati in AWS che offre servizi avanzati per semplificare il caricamento e l'analisi di flussi di dati
Amazon Athena	servizio di query interattivo che semplifica l’analisi di dati in Amazon S3 tramite SQL standard

La tabella seguente riepiloga, invece, le definizioni e gli strumenti inerenti alla piattaforma del provider Google Cloud.

La tabella che segue riporta i servizi e le funzionalità rese disponibili dalla piattaforma Cloud di
Microsoft Azure.

Azure Functions	esperienza di calcolo basata su eventi che ti permette di eseguire il codice, scritto nel linguaggio di programmazione di tua scelta
Azure Storage	servizio di archiviazione durevole, a disponibilità elevata ed estremamente scalabile per le applicazioni cloud
Azure Cosmos DB	database disponibile a livello globale per la tua app senza server
Azure Active Directory	servizio di gestione dell'accesso e delle identità basato sul cloud
Event Grid	servizio di routing di eventi completamente gestito che abilita scenari di applicazioni avanzate
Service Bus	nfrastruttura di messaggistica completamente gestita che consente di creare soluzioni cloud distribuite e scalabili con connessioni tra ambienti cloud privati e pubblici.
Logic Apps	forniscono flussi di lavoro senza server che consentono agli sviluppatori di integrare facilmente i dati con le loro app
API Management	soluzioni chiavi in mano per creare, gestire, monitorare e proteggere le API a qualsiasi livello

Apache OpenWhisk

Facciamo un approfondimento su Apache OpenWhisk, perché si tratta di uno strumento molto interessante e soprattutto open. L’immagine seguente schematizza il funzionamento di Apache OpenWhisk, che poi è, sommariamente, lo stesso di tutti i provider che erogano servizi serverless.

Il primo elemento è Nginx che è un endpoint in grado di fornisce rapidamente contenuti statici con un utilizzo efficiente delle risorse di sistema; nginx utilizza un approccio asincrono basato su eventi nella gestione delle richieste e nel nostro caso è quello che riceve la richiesta, la quale può essere uno script da eseguire.
In sostanza l’utente richiama l’endpoint e in base alla rotta attraverso cui è instradato passa da Ngnix e questo “gira” la richiesta al controller, il quale attinge al proprio database (che è CouchDB) e in base alla rotta preleva l’informazione riguardante il tipo di operazione da eseguire in risposta alla richiesta dell’utente. Poi il controller invia l’informazione a kafka, che è un gestore delle code di eventi; kafka manda in esecuzione un container Docker che dipende dal tipo di operazione richiesta (allo scopo il provider dispone di macchine virtuali con tanti container quante sono le categorie di operazione che può eseguire). Il container esegue lo script e poi si arresta.

Questo metodo di funzionamento rivela una caratteristica delle tecnologie serverless, ossia che sono di tipo stateless, nel senso che permettono di eseguire funzioni che iniziano e finiscono, ovvero che non sono persistenti. Per comprendere il concetto ipotizziamo di voler sviluppare un applicativo php: quando l’utente si autentica crea una sessione php e da qui siamo in grado di capire che l’utente è in sessione; ciò richiede una macchina che mantenga questa sessione, ma con l’architettura serverless appena vista non è possibile, in quanto il container esegue l’operazione e poi “termina” perché il container è isolato e vive per conto proprio.

Quindi con le tecnologie serverless non è possibile mantenere aperta una sessione php, perché all’interno del container un’informazione persistente come quella richiesta dal mantenimento di una sessione php aperta non può vivere, in quanto i dati corrispondenti verrebbero persi col venire meno del container, una volta che questo ha stabilito la connessione relativa alla sessione. Questo comportamento è riconducibile alla natura della tecnologia serverless, che nasce per eseguire un compito singolo al verificarsi di un evento.

Per riuscire a mantenere aperta una sessione php occorre che il container vada a salvare i dati corrispondenti in un database esterno; quindi richiamiamo il container, questo stabilisce la connessione e salva i dati in un database esterni, poi termina lo script.

Serverless: dove si usa

Diamo ora uno sguardo ai principali casi di utilizzo delle tecnologie serverless, che sono essenzialmente questi:

• back-end e applicazioni web;
• sviluppo di API;
• elaborazione dati;
• automazioni.

Il primo caso è, ad esempio, la richiesta di esecuzione di applicazioni come l’inserimento di ordini, elaborazione di immagini, operazioni matematiche e contabili; in generale si tratta delle funzioni disponibili nelle tabelle mostrate in precedenza, come quelle di AWS Lambda e comunque le function rese disponibili dal provider cui ci si affida. AWS Lambda è molto interessante perché consente di eseguire codice senza dover effettuare il provisioning né gestire server, pagando in base alle operazioni richieste. Una volta caricato il codice, Lambda si prende carico delle azioni necessarie per eseguirlo e ricalibrarne le risorse con la massima disponibilità. Puoi configurare il codice in modo che venga attivato automaticamente da altri servizi AWS oppure che venga richiamato direttamente da un qualsiasi app web o mobile, come nel baso mostrato nell’immagine seguente, che schematizza l’utilizzo di AWS Lambda in un’applicazione di mobile back-end.

In essa vedete che gli utenti da dispositivo mobile caricano l’interfaccia web (che è sul servizio serverless PS3), l’applicativo fa delle chiamate API passando dall’API Gateway, l’utente si autentica attraverso il servizio Cognito (anche questo è un serverless) il quale fa le richieste e richiama le API e queste API scatenano delle funzioni ben precise in base alla rotta, che sono tre funzioni Lambda:

• la Lambda 3 (identificata dal numero7) lancia un Search Engine che provvede a eseguire ricerche di dati su richiesta dell’utente e restituisce i dati alla Lambda Function 2;
• la Lambda Function 1 inserisce i dati all’interno di DynamoDB che è un servizio database noSQL e l’inserimento di dati in questo database scatena l’invio dei dati al Search Engine attraverso la Lambda Function 2;
• la Lambda Function 4 invia le notifiche agli altri utenti.

Le tecnologie serverless si prestano all’elaborazione di dati di vario genere, sempre su richiesta, ad esempio ricorrendo all’elaborazione di file in real-time supportata da AWS Lambda: l’immagine seguente schematizza tale funzione.

Nello specifico, il servizio permette di caricare delle immagini (per esempio per un servizio di e-commerce) e l’immissione delle immagini scatena tre eventi, ossia tre funzioni, ciascuna delle quali ha il compito di formattare differentemente i file immagine (per esempio con dimensioni/risoluzioni differenti o formati specifici) e poi di inviarli sia a un database (DynamoDB) per la mappatura, nonché reinserire l’immagine di partenza nell’S3 Amazon.

Per quanto riguarda l’automazione, la tecnologia serverless permette di automatizzare delle operazioni che normalmente si effettuano mediante server tradizionali. Per esempio se vogliamo che ogni ora uno script giri e faccia il push dei dati raw verso un database, con le tecnologie tradizionali si deve utilizzare un database, come ad esempio MySQL e ad esempio una macchina Linux in cui schedulare periodicamente un frame-job che ogni ora manda in esecuzione uno script il quale provvede a collegarsi al database MySQL e ad eseguire il push dei dati.
Con le tecnologie possiamo farlo senza bisogno di tutto questo.

L’immagine seguente schematizza un’applicazione di elaborazione di dati in streaming, come ad esempio quelli forniti da numerosi sensori e dispositivi per IoT e automazione massiva.

Qui l’evento scatenante è l’arrivo di stringhe di dati, prese in carico dalla funzione Event Ingestion, che poi li smista ad ulteriori Lambda Function:

• Lambda Function 1 invia i dati, a seconda della loro natura, ad Amazon CloudWatch (che permette di monitorare i dati ed eventuali loro soglie, nonché di generare alert al superamento di queste ultime) oppure al database DynamoDB;
• Lambda Function 2 invia i dati alla piattaforma Amazon S3.

Serverless: pro e contro

Analizziamo brevemente i vantaggi e i difetti del serverless: tra i pregi spiccano sicuramente i costi irrisori, derivanti sia dal fatto che la gran parte dei provider rende disponibili alcune operazioni e lo sviluppo di un certo numero di applicazioni in franchigia e che inoltre il servizio di paga ad evento, vale dire solo quando si utilizza; se non si richiede alcuna elaborazione, nulla è preteso dal provider.

Un altro fattore di merito è la scalabilità, dovuta al fatto che il provider gestisce in maniera flessibile le risorse, aumentandole o diminuendole in base alle necessità sia dell’utente, sia della richiesta ricevuta.

La facilità di implementazione è il terzo punto a favore ed è insita nella natura del servizio, che non richiede infrastrutture proprie e può contare su numerose funzioni già pronte, capaci di soddisfare la gran parte delle applicazioni odierne.

A fronte di tutto ciò, c’è un prezzo da pagare e non ci riferiamo a quello in denaro, bensì ad alcune limitazioni: una di queste è il Vendor Lock-in, ossia l’essere vincolati al provider; in prayica un’applicazione serverless nasce e muore in una piattaforma specifica e non può essere trasportata su quella di un altro provider.

Altro limite è lo stateless già esposto, ossia il fatto che le operazioni richieste sortiscono ciascuna un solo effetto, quindi lo script viene eseguito e affinché determini azioni correlate dev’essere collegato a un altro.

I tempi di esecuzione sono più lunghi di applicazioni sviluppate con tecnologie tradizionali e sono affetti anche dallo stateless; altro fattore che rallenta l’esecuzione è la frequenza con cui uno script viene eseguito, nel senso che per ottimizzare le risorse di calcolo, i provider accantonano momentaneamente script eseguiti raramente e tengono pronti quelli di uso ricorrente, con la conseguenza che quando uno script “accantonato” quando viene richiesto, occorre un po’ più tempo affinché sia eseguito.

Creazione di un’applicazione serverless

In conclusione, per fissare i concetti vediamo sinteticamente come costruire un’applicazione serverless che si basa sostanzialmente su un’interfaccia web pubblica riportante due pulsanti -uno blu e uno rosso- cliccando sui quali, ogni volta si vanno a incrementare i dati sul conteggio dei clic contenuti in una tabella su database. Questa esercitazione verrà realizzata con Amazon AWS, facendo uso due Lambda Function, di DynamoDB, della piattaforma S3 che ci farà l’hosting per l’interfaccia web, il tutto secondo lo schema visibile nell’immagine seguente.

La piattaforma S3 ci permette di caricare codice file HTML CSS e JavaScript e comunque di fare hosting per del codice statico; non ci permette di caricare codice PHP, ma per il nostro esempio va più che bene.

L’interfaccia web è quella proposta nell’immagine seguente e il clic su ciascuno dei due pulsanti scatena una Lambda Function; ciascuna di queste fa la stessa funzione, ma scrive in una colonna differente della tabella nel database.

Per costruire questa applicazione si parte dall’ultimo blocco, ossia il database, che può essere creato molto semplicemente in Amazon AWS apreno la pagina web di AWS Services e andando a cercare la funzione DynamoDB che è già esistente, quindi c’è nulla da installare. È sufficiente andare nella casella di ricerca e digitale le prime lettere per veder apparire, nel menu a tendina, DynamoDB  (immagine seguente).

Selezioniamolo facendovi clic e accediamo alla schermata corrispondente, nella quale creiamo il nostro database cui punteranno le Lambda Function; la creazione si effettua cliccando, nel menu di sinistra della pagina, su Tabelle (Tables) e, al centro della sezione riepilogativa che mostra le tabelle esistenti, sul pulsante blu Create Table (immagine seguente).

Con il pulsante accediamo alla pagina di creazione della tabella, dove oltre al nome impostiamo la chiave principale (Primary Key) che sarà date, oltre al formato dei dati contenuti, che sarà numerico (Number) visto che vogliamo contare i clic relativi ai due pulsanti (immagine seguente).

Clicchiamo, in questa pagina, sul pulsante Create e procediamo con la creazione della tabella, quindi andremo a editarla aggiungendo le colonne di colore relative a blu e rosso. Quindi passiamo alla definizione delle due Lambda Function che popoleranno la tabella, ovvero le funzioni di inseguimento dei colori e di conteggio dei clic. Allo scopo ci affideremo al servizio Lambda, che andremo a cercare su AWS esattamente come fatto per Database, ossia nella casella di ricerca.
Trovata la voce Lambda nel menu a tendina, vi clicchiamo sopra e accediamo alla pagina Lambda, dalla quale, attraverso il menu a sinistra, clicchiamo su Function ed apriamo così la pagina omonima, all’interno della quale (in alto a destra, per l’esattezza) troviamo il pulsante Create Function: gli clicchiamo sopra e apriamo la pagina di creazione della nostra funzione (immagine seguente).

Scriviamo quindi la prima delle nostre Lambda Function che si occupa di creare il colore relativo ai pulsanti dell’interfaccia web pubblica che vengono cliccati; l’immagine seguente ci propone la schermata di creazione della funzione, dove definiamo il nome da assegnarle, l’ambiente di esecuzione o linguaggio corrispondente allo script da eseguire (lo scegliamo cliccando sulla casella Runtime, allorché ci appare il menu a tendina che riporta gli ambienti supportati) che nel caso è quello predefinito, ossia Node.js 6.10, le eventuali regole predefinite o customizzabili eccetera (immagine seguente).

Notate che volendo creare una regola, oltre a definirne il nome nella casella Role name potete scegliere se crearla a partire da uno dei template elencati dal menu che si apre cliccando su Role; nel nostro caso scegliamo il template Simple Microservice Permissions perché consente alla nostra Lambda Function di operare su DynamoDB.
Definito il tutto, per creare la funzione clicchiamo sul pulsante arancione Create Function. Una volta che la Function è stata creata la vediamo nella schermata Functions già vista in precedenza, da cui possiamo editarla per scriverle all’interno il codice che dovrà eseguito, vale a dire lo cripto corrispondente. L’immagine seguente propone il codice che ci occorre.

In pratica lo script riceve in input la pressione del pulsante virtuale e va ad aggiornare la nostra tabella (Tablename); salvando il codice, torniamo alla schermata che riepiloga la funzione e riporta le Function con cui può funzionare, vale a dire Amazon CloudWatch Logs (immagine seguente).

In ogni momento potete verificare se la funzione creata sta lavorando, portandovi su Tables, cliccando sul nome della funzione stessa e verificando se già ci sono delle entry.

Passiamo ora a creare la seconda Function, che costruiremo in maniera analoga, ovvero scriviamo la Lambda Function che si occupa di leggere i dati relativi ai clic sui pulsanti; dunque, andiamo nella solita pagina Functions, clicchiamo sul pulsante Create e cerchiamo nella casella di ricerca il servizio Lambda, che andremo a cercare su AWS.
Accediamo alla pagina Lambda, dalla quale, attraverso il menu a sinistra, clicchiamo su Function ed apriamo così la pagina omonima, all’interno della quale (in alto a destra, per l’esattezza) troviamo il pulsante Create Function: gli clicchiamo sopra e apriamo la pagina di creazione della nostra funzione. Dalla schermata di creazione della funzione cui accediamo, definiamo il nome da assegnarle, l’ambiente di esecuzione o linguaggio corrispondente allo script da eseguire (lo scegliamo cliccando sulla casella Runtime, allorché ci appare il menu a tendina che riporta gli ambienti supportati) che nel caso è quello predefinito, ossia Node.js 6.10, le eventuali regole predefinite o customizzabili eccetera.

Definito il tutto, per creare la funzione clicchiamo sul pulsante arancione Create Function. Una volta che la Function è stata creata la vediamo nella schermata Functions già vista in precedenza, da cui possiamo editarla per scriverle all’interno il codice che dovrà eseguito, vale a dire lo cripto corrispondente. L’immagine seguente propone il codice che va inserito.

Scritto il nostro codice salviamo la funzione. Volendo possiamo testarla dalla pagina riepilogativa, come qualsiasi altra Function, compresa quella creata in precedenza.

Adesso bisogna andare a creare le API che ci permetterà di far funzionare il gateway per instradare le richieste provenienti dalla pagina web pubblica verso le due Function; al solito non dobbiamo installare alcunché perché troviamo tutto in Amazon AWS: basta andare nella sezione APIs e cliccare su Create new API. Nella pagina corrispondente impostiamo la prima API come mostrato nell’immagine seguente e le diamo il nome desiderato. Impostato tutto quello che serve, creiamo l’API con un clic sul pulsante azzurro Create API che troviamo in basso a destra nella pagina.

Questa prima API servirà ad attivare la Function che gestisce il colore; una volta creata la prima API si costruisce la seconda in maniera analoga (la seconda API aggiornerà la tabella con il numero di clic).
A questo punto è stato creato il gruppo e dobbiamo definire cosa fanno le due API, che abbiamo chiamato get-color la prima e add-color la seconda; ciascuna delle API va associata ad un percorso, perché le richieste che si affacciano all’endpoint devono essere instradate in direzioni diverse, ovvero a Function differenti, in base all’URI.
Andiamo dunque nelle singole API e poi clicchiamo su Resources, quindi selezioniamo ciascuna API e indichiamo, tramite Actions, il metodo HTTP tramite il quale possono essere chiamate: nello specifico, dal menu a tendina che si apre cliccando su Actions clicchiamo su Create Method e poi impostiamo POST. A questo punto clicchiamo su POST e nella pagina /add-color – POST – Setup definiamo le azioni, ovvero in Integration type selezioniamo Lambda Function per indicare con che cosa dev’essere integrata l’esecuzione dell’API viene richiamata; come mostra l’immagine seguente, indichiamo di associare l’API a una Lambda Function e nella casella omonima in basso scriviamo quale funzione va associata.

Salviamo l’impostazione con un clic sul pulsante Save e ripetiamo per l’altra API, ossia get-color, quanto fatto per add-color, salvando alla fine; naturalmente la Lambda Function associata sarà quella corrispondente.
A questo punto abbiamo realizzato anche il blocco dell’API Gateway e delle Lambda Functions e non ci resta che creare la parte riguardante l’hosting su S3, quindi l’applicativo (è semplice perché consta di due sole pagine) che caricheremo su S3 affinché ci faccia l’hosting.
Allo scopo, sempre dalla piattaforma di Amazon AWS accediamo ad S3 (dal menu di sinistra della pagina principale di AWS) e clicchiamo sul pulsante Create bucket; una volta creato il bucket (contenitore) con il nome e le caratteristiche desiderati, lo troviamo nella pagina che riepiloga quelli esistenti. Qui clicchiamo su di esso e ci si apre la relativa pagina web composta da un certo numero di tab; per fare in modo che ci faccia l’hosting andiamo nelle sue proprietà (cliccando sulla tab Properties) e nel riquadro Static Website Hosting, che apriamo cliccandovi sopra, selezioniamo l’opzione Use this bucket to host a website (immagine seguente).

Compiliamo le caselle e in particolare index document, dove scriveremo il nome della pagina html pubblica, error document (se vogliamo specificare un documento da visualizzare agli utenti in caso di errore nell’accesso) e Redirection rules se intendiamo stabilire delle regole di dirottamento. Quindi clicchiamo sul pulsante Save per salvare l’impostazione e, tornati alla pagina del bucket, spostiamoci sulla tab Permissions, dove definiamo le Bucket Policy come mostrato nell’immagine seguente, allo scopo di rendere il bucket di tipo pubblico.

Salviamo con Save e torniamo alla pagina del bucket, dalla quale se ora clicchiamo nuovamente sulla tab Properties e poi su e sul riquadro Static Website Hosting, che una volta aperto si presenta come nell’immagine seguente.

In pratica ora all’Endpoint è stato assegnato un URL pubblico (evidenziato in blu), copiando il quale e incollandolo nella barra degli indirizzi del browser web visualizzeremo la pagina con i due pulsanti, tramite la quale andremo a interagire con la nostra applicazione serverless. In realtà l’URL dà accesso al bucket, però all’interno di quest’ultimo bisogna caricare l’applicativo, altrimenti il bucket risulterà vuoto e puntando all’URL non si otterrà altro che il canonico errore 404 (Not Found) perché non c’è contenuto.

Andiamo dunque a riempire questo bucket con il nostro applicativo: torniamo alla pagina riepilogativa del bucket e aprendo la tab Overviev clicchiamo sul pulsante Upload, quindi importiamo il file contenente l’applicativo che avremo opportunamente creato in precedenza. Seguiamo tutta la procedura e all’ultimo passaggio clicchiamo su Upload per mandare al bucket il codice corrispondente.

Torniamo alla pagina riepilogativa e creiamo, con un clic sul pulsante +Create Folder, una cartella nella quale inserire i css, quindi con Upload glieli inseriamo, con una procedura analoga a quella fatta sinora per gli HTML dell’applicativo.