Cosa significa Serverless? Confronto con SaaS, IaaS e PaaS

Registrazione workshop

Speaker

Niccolò Olivieri Achille
Niccolò Olivieri AchilleSenior Software Engineer

Dettagli dell’evento

Immagina un mondo in cui non ti devi più preoccupare dei server, dei sistemi operativi e della scalabilità. Un mondo dove puoi utilizzare la tua applicazione un milione di volte (letteralmente) prima di iniziare a pagare l’infrastruttura. Tutto questo (e molto altro ancora, nuovi problemi compresi) è il serverless.

Slide

Qui  sotto puoi trovare la trascrizione del video. Non si tratta di un articolo redatto e corretto, quindi potresti trovare errori e costrutti poco “carini”. Speriamo comunque che ti possa essere utile 🙂

Cosa significa Serverless? Confronto con SaaS, IaaS e PaaS

Ciao a tutti allora oggi vediamo di parlare un attimino di cos’è serverless? Cosa vuol dire? Cosa significa serverless? Vi dico già che non è fare tutto lato cloud, alla fine andremo a vedere anche un’applicazione che ho fatto per dimostrare banalmente cos’è il serverless, non vedremo codice, a meno che non vogliate andare sul repository che non è però interessante al fine di questo workshop.

Mi presento per chi non mi dovesse conoscere: sono in ThinkOpen, faccio il developer di Node.js, nella mia vita lavorativa ho fatto un po di tutto, ma mai sviluppo (è la prima volta che lo faccio praticamente), ho fatto tante cose che potete vedere là dentro: da php a front end, a PM, a molte cose in cloud soprattutto su Amazon AWS.
Ultimamente mi sto anche interessando a tutte le implementazioni di chatbot con un progetto che stiamo seguendo con ThinkOpen e con Reply, recentissimamente anche Blockchain e appunto serverless.

Serverless vuol dire che non ci sono server: la primissima definizione di serverless è stata data da un tal Mike Roberts e l’ha data con due sfumature diverse. La prima molto più approssimativa ovvero: “nella mia applicazione io non uso codice lato server, la mia applicazione si basa solo su codice di terze parti per il il server”, dopodiché è stata smorzata un pochino dicendo “ci può anche essere del codice fatto da me l’importante è che questo codice non risieda su un server come tutti noi lo conosciamo, ma risieda su qualcosa dato da un qualsiasi vendor, che ci viene scatenato da eventi e che soprattutto è effimero”.

Noi non avremo mai informazioni su dove stiamo eseguendo il nostro codice, il nostro codice può essere eseguito (come effettivamente è) in una server farm di cui però non conosciamo il sistema operativo, non conosciamo se è un server, un container, un cellulare. Non sappiamo niente di questo server e non dobbiamo e vogliamo sapere niente di questo server proprio perché come ha detto il CTO di Amazon, quando ha presentato tutta l’architettura di Amazon di AWS: “Nessun server è più facile da mantenere che nessun server”. Per cui noi non vogliamo avere i problemi di manutenzione dei server, non vogliamo dover aggiornare i sistemi operativi, ottimizzarli, metterli in rete, non vogliamo nulla di tutto questo. Avremo molti altri problemi ma questi problemi legati ai server non li vogliamo avere e soprattutto non vogliamo avere a che fare con i sistemisti. Serverless è il modello di esecuzione dove il vendor allocca delle risorse nelle macchine e ce le mette a disposizione.

Perché si va sul serverless e che benefici mi da rispetto a un server tradizionale?

Innanzitutto costa molto di meno: molto perché un server noi lo paghiamo di giorno, di notte, durante le pause pranzo, durante le vacanze, lo paghiamo sempre. Il serverless se nessuno invoca l’applicazione, non lo si paga.

grafico mostra i picchi di visite su un sito web

Il grafico che vedete rappresenta le sessioni web viste nei giorni di un sito a caso: capite bene che io per tenere quei picchi devo avere una struttura che, non vi dico che me li tiene sempre, però che almeno un 50 per cento me lo tiene sempre. Arrivo quindi a pagare il 50 per cento di più di quello che consumo effettivamente, con il serverless invece pago esattamente quello che uso, non pago un euro in più. Poi ovvio devo essere dopo bravo io a creare un’applicazione che sfrutta il serverless appieno, non posso fare cose che rimangono attive o che aspettano, cambia completamente il modo di ragionare. Ma di questo ne parleremo dopo. Dopo di che ovviamente serverless non vuol dire che noi non usiamo server, vuol dire che usiamo degli spazi su server di cui non sappiamo niente, di cui non ce ne frega niente e che sappiamo che da un secondo all’altro potrebbero essere dall’altra parte del mondo a nostra insaputa.

Quali sono i contro?

Tantissimi. Il debug: noi non dobbiamo più debuggare su un server ma dobbiamo debuggare su n° server che finita l’esecuzione vengono eliminati per cui, seguono tutte delle problematiche che fino ad adesso non esistevano. Se adesso devi debuggare la tua applicazione, vai sul server, guardi che cosa ha loggato o guardi come è la CPU, guardi qualcosa, ti inventi qualcosa e magari riesce a capire cosa sta andando e cosa non sta andando sulla tua applicazione. Qui invece, non abbiamo un server su cui salire: il nostro codice è messo su dei repository, non abbiamo neanche l’applicazione attiva, non sappiamo cosa sta succedendo. Noi siamo stateless: mentre prima potevamo salvare delle variabili di sessioni, delle variabili globali sul nostro server, ora non abbiamo un server e per cui tutte le volte dobbiamo ricalcolare tutto oppure passarci lo stato in cui è l’utente di volta in volta.
Abbiamo dei problemi enormi di performance: mentre prima, arriva la richiesta, il server risponde alla nostra richiesta; adesso dobbiamo far ripartire il server tutte le volte che arriva una richiesta. Per cui un php almeno fino alla versione 5 se non era compilato non era nulla, partiva e averlo serverless o averlo con server cambia poco. Pensiamo a un nodeJS, o per chi non conosce a un java, che comunque deve mettere in moto una virtual machine, deve mettere in moto molti processi accessori; questi processi hanno un costo di start up magari non indifferente, magari all’inizio la nostra applicazione va a prendersi tutte le configurazioni da un database quindi ad ogni richiesta dobbiamo andare a fare tutte le richieste al database. Sono delle problematiche non indifferenti.
Dopo di che adesso avendo a che fare non più con server ma con strutture molto più piccole (avremo a che fare dopo con le funzioni) noi scateneremo delle funzioni non più un server o delle chiamate.
Questo vuol dire che avremo la funzione che va sul database, un’altra funzione che impacchetta il messaggio, un’altra funzione che va su un API esterna; tutte queste funzioni devono parlare tra di loro, perchè tutte queste funzioni magari non sono più sullo stesso server, magari sono su server differenti, magari sono sul layer differenti, magari dobbiamo andare a parlare quattro volte con un database che prima è da una parte, poi dall’altra parte, poi da un’altra parte ancora.

Dopo di che cambiamo, come abbiamo detto prima, completamente il modo di ragionare. Noi siamo abituati a, non indico fare delle applicazioni monolitiche, facciamo anche ad avere tanti layer, uno per la logica di business e uno per la logica di presentazione, adesso non solo abbiamo tanti layer applicativi abbiamo anche tanti layer all’interno della stessa applicazione. Perché a questo punto se il codice che va a pescare dal database noi lo riutilizziamo otto volte, quello lo isoliamo in una funzione e tutte le altre funzioni vanno a richiamare quella funzione lì.
Per cui ha un qualcosa che cambia completamente il nostro modo di ragionare, cambia completamente il modo con cui noi andiamo a eseguire anche semplici operazioni e dopo nell’applicazione che ho creato vedremo in pratica questi modi diversi.

Quindi perché si sta cercando in tutti i modi passare al serverless?

Per i soldi! Costano molto di meno, molto molto molto di meno; facevano vedere delle comparative e si arriva a spendere intorno al 5 per cento di quanto non si spenderebbe per un server.
Non il 5 per cento in meno, ma il 95 per cento in meno e sono bei numeri ma soprattutto perché in questo modo stai liberando delle farm di server inutili.
Facciamo un attimino di chiarezza su tutte le tipologie di cloud noi quando diciamo cloud, a parte le nuvolette, intendiamo tante cose, troppe cose.

Saas

Innanzitutto c’è SaaS che sta per software as a service, l’esempio più banale di SaaS: salesforce, gmail, tutta la suite google, la suite icloud, i vari CMS, office 365.
Questi applicativi sono tutti SaaS: software as a service. Un vendor ci mette a disposizione un software noi ci colleghiamo a internet e accediamo a questo software. Pensate a gmail e alla mail aziendale, voi non avete più outlook installato sulla vostra macchina con un server da qualche parte in uno scantinato, è tutto in cloud: voi accedete a gmail e potete mandare email da qualsiasi parte, in qualsiasi modo, assolutamente come volete, questo è il SaaS, questo è il primo step: un sito internet che mette a disposizione delle funzionalità non “atomiche”.

IaaS

Dopodiché si passa a IaaS (Infrastructure as a Service): amazon, azure, google cloud è tutto infrastructure as a service, ovvero tu chiedi ad amazon una macchina virtuale, dopo se è lento 30 secondi tu hai la tua macchina virtuale con installato il sistema operativo; chiedi un database dopo un minuto tu hai un database pronto. Perfetto questo è infrastructure as a service, il vendor ti mette a disposizione un’infrastruttura ovviamente virtuale, in base a quello che decidi. Di esempi ne abbiamo detti, è un qualcosa che viene appena dopo il software as a service, cioè noi abbiamo un’infrastruttura tutto quello che facciamo con l’infrastruttura è affar nostro.

PaaS

Dopodiché si passa al PaaS (Platform as a service). Il platform as a service vedetelo come un duale dell’infrastructure as a services, però da un punto di vista più applicativo; per cui tu adesso non avrai più bisogno di una macchina virtuale ma richiederai un web server; non chiederei più una macchina ubuntu o un database oracle, chiederai una tabella di un database, chiederai un web server, un application server, chiederai un pezzo di software e potrai fare del dei collegamenti; esattamente come nell’infrastructure as a service si fanno link tra macchine, qui fai link tra pezzi di software per cui dici questo Application Server deve poter accedere a questo database.

Serverless: backend as a service

Adesso entriamo nella parte interessante: nel serverless. Vi ricordate che prima vi ho detto che l’originale definizione di serverless era divisa in due parti: la prima è backend as a service per cui la mia applicazione si basa sul backend di qualcun altro , ne esistono tantissime. Facebook se ci pensate vi mette a disposizione la login, ma “login social” non è nient’altro che un API fornita da Facebook per poter non avere tu tutta un’infrastruttura di login, la gestisce completamente lui e sempre lui ti dà la garanzia che l’utente se supera la login di facebook allora è loggato nel modo corretto. Altro esempio è Firebase, se voi avete mai dovuto mandare una notifica push a un’applicazione l’avete di sicuramente mandata con Firebase; firebase ti dice ok perfetto, mi gestisco io tutta la complessità di comunicare con apple e google tu devi solo interfacciarti con me, mandare a me la notifica e poi me la gestisco e smisto io.

Serverless: function as a service

Questo come dicevamo è il primo step del serverless, il vero step, quello che interessa di più a noi è sono le function as a service, per cui noi facciamo codice, questo codice lo mettiamo in una funzione richiamabile tramite eventi e possiamo utilizzare questa funzione in tutti i modi e con tutti gli eventi che vogliamo, l’importante è la firma della funzione, noi sappiamo che dobbiamo presentarci a questa funzione in una determinata maniera e questa funzione farà esattamente quello che gli diremo.

Funzioni e eventi Amazon Web Services

Abbiamo finito l’introduzione ora iniziamo a parlare di funzioni e soprattutto iniziamo a parlare di Amazon. I provider grandi sono Amazon, Google, Microsoft e Azure, noi parleremo di Amazon non tanto perché sia meglio degli altri ma perché è quella che conosco meglio e soprattutto perchè è stata la prima ad entrare ed è proprio quella con molte più feature degli altri.
Come dicevamo le nostre funzioni sono scatenabili da eventi, ma cos’è un evento?
Amazon ci mette a disposizione 15 tipologie diverse di eventi, non ve le dico tutte anche perché alcune a stento so cosa sono visto che continuano uscire tipo una ogni due settimane. Fondamentalmente voi fate l’upload di un file e boom: amazon s3 scatena un evento, la vostra funzione riceve l’evento e si comporta di conseguenza.
Ad esempio: voi fate un applicazione che deve fare il rendering di un video. Caricate il video su Amazon s3, l’evento da impasto il nome del video che dovete renderizzare o manipolare e la vostra funzione fa tutto il rendering, dopodiché muore. In questo modo voi normalmente avreste dovuto avere un server che doveva anche fare il rendering video (doveva avere tutta la logica applicativa e le librerie per fare il rendering), in questo modo la vostra applicazione fa solo l’applicazione, tutte le librerie per il rendering sono da un’altra parte, da qualche parte nel cloud e faranno sempre e solo questo. Per cui in un’ottica di limitare i costi e soprattutto di avere l’infrastruttura più performante possibile, voi potete dire ok perfetto questa funzione anziché metterla su una macchina normale mettimela su una macchina che al posto delle CPU ha le GPU e per cui il rendering video me lo fa molto più velocemente; la pagherò di più ma almeno so che il rendering di questo video anziché arrivarmi in due minuti mi arriva in 10 secondi, per cui riesco ad avere non proprio un hardware però un’infrastruttura dedicata a quello che svolge questa particolare funzione.

Altre cose che possono venire in mente: Amazon SES è il servizio di amazon di invio di email, voi impostate una casella email che faccia da bot, tutte le mail che arrivano fanno partire una funzione, questa funzione aggiunge il ticket agira, crea una nuova cosa, manda altre mail, fa partire un deploy; grazie a una semplicissima funzione voi vi mettete in ascolto e fate qualcosa fate del codice.
E’ nell’ultima riga ma è sicuramente il più utilizzato Amazon API gateway: esponete i vostri end point, esponete le vostre API e appena un utente contatta un’API, parte la funzione che esegue il codice di quel pezzo di applicazione, di quelle API e vi restituisce il risultato.

Questi sono gli eventi di Amazon poi ce ne sono molti altri, se volete poi ci andiamo più nello specifico, però questo è il nuovo modo di ragionare, il nuovo modo di dire ok perfetto io non vado più a fare una applicazione che fa tutto questo o comunque pezzi di applicazione che vengono richiamati da tante parti; ho le API che mi prende la lista di utenti? in quella funzione io avrò solamente il punto che va sul database e solamente il punto che dal database me lo mette in un jason, in xml, in quello che vogliamo e me lo stampa a schermo, basta, tutto il resto non mi interessa; quella funzione sarà “atomica” per fare questa singola funzionalità.
A questo punto cambia anche tutto il modo di fare il deploy, perché noi non stiamo più mandando il nostro codice su un server, le cose qui iniziano ad essere leggermente diverse. Innanzitutto abbiamo la possibilità di interfacciarci con tanti vendor: abbiamo Amazon, abbiamo Google, abbiamo Microsoft e domani ne avremo altri duemila; sta venendo fuori IBM con “Lumix” se non mi sbaglio; ogni vendor ha le sue API, ogni vendor ha i suoi prodotti che magari al 90 per cento sono uguali ma magari hanno un 10 per cento di diversità.
Magari c’è un prodotto di Amazon che fa una certa cosa, lo stesso prodotto di Google fa quella cosa tranne magari un pezzettino. Come ci si fa muovere in tutto questo?

Freamework “Serverless”

Con un framework o libreria (non si è ancora capito bene cosa sia) che si chiama “Serverless”, che gestisce tutto il deploy, lei si interfaccia con i vendor, non al cento per cento perché non riescono a star dietro a tutte le novità dei vendor (pur avendo avuto un giro di finanziamenti credo di 5 milioni di dollari). Non riesco a star dietro a tutto, ci provano, al momento riescono a star dietro alle cose diciamo più importanti, le cose più grosse e mettono un layer, di mi vien da dire per banalizzare, per semplificare, le API dei nostri vendor.
Questa era la parte diciamo teorica, adesso vi faccio vedere l’applicazione. L’applicazione è banalissima ed è online in questo momento, per cui dopo se volete potete vederla, vi ripeto è banale però ha dentro tanti pezzi, proprio farvi capire come si deve cambiare mentalità, come tutto quello che avete fatto fino adesso non dico che va cancellato ma poco ci manca.

Descrizione applicazione sviluppata per il workshop

schema architetturale applicazione serverless

Questa è la mappa architetturale della nostra applicazione che non è nient’altro che una pagina statica che espone due cose: la lista degli iscritti a questo workshop (che poi non è vero perché è la lista degli iscritti all’evento facebook del workshop) e un modo per votare con un bel pollicino gli iscritti; dopodiché ha una funzionalità, previa autenticazione, che mostra una configurazione, e solo dopo aver essersi loggati mostra un popup.
Questa applicazione utilizza anche le API di Telegram,di un bot di Telegram per ricevere istruzioni e per aggiornare sullo stato di alcune funzionalità, sullo stato soprattutto dell’applicazione stessa.
Per cui banalmente manda un messaggio quando: viene deployata, se c’è un errore, se c’è una funzione che ci sta mettendo tanto tempo ad essere eseguita. Questo è quello che fa l’applicazione.

Dopo aver elencato tutti i servizi utilizzati da Amazon, andiamo a vedere cosa succede un pochino nel dettaglio.
Il nostro utente come si comporta: questi richiede al DNS di Amazon che si chiama Root 53, l’indirizzo per accedere alla nostra applicazione, dopodichè l’applicazione può andare sul bot a scrivere o direttamente sulle API, un servizio che risponde in jason oppure su di un cloudfront che non è nient’altro che una cdm che espone la nostra pagina statica e tutti gli assi.
Partiamo dalla cosa semplice la cdm andrà a chiedere al servizio di storage il filesystem virtuale di amazon s3 i file da servire e dopo di che li casha e li manda all’utente. Successivamente l’altro entry point e le API Gateway per cui le nostre API che scatenano una funzione lambda, esempio: ho bisogno della lista degli utenti? parte la funzione lambda ( le definizioni su Amazon si chiamano lambda function) che ha in carico la gestione della lista degli utenti, accederà al database Dynamo db, scriverà i log cloud watch e dopo di che restituirà l’elenco in questo caso degli utenti, come vi ho detto prima però esistono delle API che possono essere raggiunte solo previa autenticazione. A questo punto cosa succede?
In un flusso normale, in un’applicazione normale, la nostra applicazione riceve l’API e la manda al codice che deve verificare la login dopodiché questo continua e va in tutto il resto del codice, qui succede bene o male la stessa cosa, solo che succede in due posti completamente diversi: il nostro API Gateway riceve la richiesta, sa che quella richiesta e autenticata, la invia alla funzione lambda che controlla la login (quest’ultima e andrà su facebook per verificare che sia andato a buon fine) e restituisce sempre a queste API Gateway true o false, l’utente è autenticato? si perfetto a questo punto le API Gateway va a richiamare la blanda function ad hoc, se l’utente non dovesse risultare loggato le lambda function a valle non vengono neanche preso in considerazione;
Questo cosa ci permette? non solo di separare completamente la logica dei due punti ma ci permette ad esempio di cachare la funzione di autorizzazione. Noi sappiamo che un utente che è loggato adesso su facebook tra 5 minuti di sicuro sarà ancora loggato, non sto a ricontrollare tutte le volte, per cui posso dire di controllare la parte di autorizzazione ogni 5 minuti, anche perché in quel caso io devo: far partire la funzione, andare su Facebook, aspettare che risponda (poi essendo Facebook ci mette poco a rispondere) però comunque io sto pagando. Quindi se riesco a mettere una cache, anche di 5 minuti, sono soldi risparmiati sono tanti soldi risparmiati.
Dopodiché andiamo avanti nel flusso, le flotte di funzioni lambda possono accedere al database e possono scrivere i log. Però aspetta un attimo, facciamo che tutti i log che mi arrivano io li vado a scrivere su un servizio di terze parti: Log DNA.
Perché sono servizi di terze parti? Perché il servizio amazon per la gestione dei log costa una tanto, al momento infatti Amazon non fornisce un servizio a basso costo per la gestione dei log, perché loro si basano sul fatto che se vuoi gestire dei log, allora vuol dire che gestisci un’applicazione molto ben strutturata e quindi te lo fa pagare, soprattutto perché ti danno Elastic Search che non è male per gestire i log e per cui noi lo mandiamo da un’altra parte, in un servizio che se non vuoi fare cose stellari è gratis.
Quindi ogni log che viene scritto dalle nostre applicazioni viene preso da un’altra funzione che è in ascolto sull’evento scrittura log, la quale prima manda il log sul nostro servizio di terze parti, dopo di che si occupa di un minimo di logica, ad esempio, il log che mi è arrivato ha un errore? Si, lo mando in una coda dei messaggi di telegram.
Tra i log c’è anche un messaggio di start e di finish delle nostre applicazioni e delle nostre funzioni, facciamo ad esempio che io faccio una differenza tra start e finish e che se una funzione abbia una durata più di 2 secondi si scatena un errore e anche in questo caso lo vado a mandare su telegram, ma come faccio a mandarlo su Telegram?
Normalmente invocherei la funzione che lo manda su telegram, ma in questo caso no, perché? Perchè lo metto in una coda dove ci sarà una funzione lambda in ascolto su questa coda che, tutto quello che arriva nella coda, lo manda su telegram. Questa funzione però non sa niente di quello che le è arrivato,da dove sono arrivati questi messaggi, semplicemente prende quello che c’è e lo manda perché tutto si basa su eventi.

So perfettamente che comunque non è che le applicazioni normali, passatemi il termine, hanno una logica tanto differente qui però abbiamo l’esasperazione della nostra logica per cui le code esistono anche nelle applicazioni non serverless, la sottoscrizione di una coda da parte di un metodo, da parte di un’applicazione, esistono anche nelle applicazioni non serverless, qui però è la base. Ovvero qui si ragiona solo ad eventi non c’è più il “già che faccio questa cosa, ne faccio anche un’altra”, perché sto perdendo tempo e sto perdendo soldi. Per cui avrò qualcuno di dedicato, esempio: devo interrogare un API che magari risponde di 30 secondi non ci penso neanche a lasciare la mia funzione in ascolto 30 secondi. Mando quello che devo, poi qualche altra funzione avrà la premura di rispondere. Poi come viene implementato questo sul client è un altro discorso, però noi nel frattempo stiamo risparmiando sul server perché non stiamo tenendo il server impegnato in ascolto di un qualcosa che chissà quando arriverà.
Come vi dicevo anche il deploy però cambia leggermente. Tutta l’applicazione è fatta come vi dicevo in node, non tanto perché node sia più bello, ma perché node innanzitutto si presta molto alla logica ad eventi essendo lui stesso ad eventi, per cui ha tutta una serie di costrutti di base del linguaggio che si adattano molto facilmente a questa nuova logica.
Dopodiché è un linguaggio molto snello, molto veloce e single tred per cui a maggior ragione è molto più semplice per un provider inserirti su un container con un processore dedicato piuttosto che su un’applicazione multi tred, sulla quale poi loro devono impazzire per capire quante risorse allocare

Il deploy quindi avviene in due fasi diverse: prima viene deployata la parte dinamica, quindi tutta la parte sopra di lambda function e di API, dopo in un secondo momento viene deployata la parte sopra, la parte statica che in questo caso è formata da una pagina web, due javascript e un css.
Quindi tutto questo deploy viene organizzato dal framework Serverless e viene fatto sempre su Amazon, noi potremmo farlo in locale è molto più carino e pulito farlo fare anche questo ad amazon, per cui noi facciamo un push sul nostro bel repository github e due minuti dopo, abbiamo tutto online.

Quindi molto semplicemente, l’applicazione viene prima compilata da un compilatore Babel, perché le lambda function non ci permettono di far girare la versione che vogliamo di Node, per cui per non correre rischi si fa passare tutto attraverso Babel, si fa passare tutto attraverso dei preset ad hoc per le lamba in modo che sappiamo che stiamo utilizzando solo e unicamente i costrutti accettati da lambda.
Dopo di che il framework Serverless si prende il compito di fare tutto il deploy e successivo al deploy noi eseguiamo due funzioni lambda: la prima funzione è subscribe to log, per cui noi dobbiamo dire a tutti i log che abbiamo, che si chiamano cloud watch, che tutte le volte che ricevono un log devono darli a questa funzione lambda che è quella che nella nostra infrastruttura gestisce i log e che poi li manda “all’interno dell’invia mail”.
Dopodiché abbiamo un’altra lambda function il registerEndPoint, quest’ultima prendere in input il nuovo endpoint che si è creato, che questo deploy ha creato e mandarlo a Telegram, perché telegram ha bisogno di un indirizzo statico dove inviare messaggi che arrivano.
La stessa famiglia di EndPoint viene passata alla compilazione statica della parte statica della nostra applicazione che poi viene buttata su, perché la parte statica è innanzitutto da tutt’altra parte rispetto alla parte dinamica, e soprattutto lei ha bisogno di un indirizzo di un url per contattare le APi e questo url glielo dobbiamo passare noi.
Per cui anche qui noi dobbiamo cambiare il nostro modo di ragionare, pensando che non è tutto all’interno della stessa applicazione, all’interno dello stesso url banalizzando, ma abbiamo url diversi che magari sono uno da una parte e uno dall’altro del mondo, è tutto gestito dinamicamente.

Cosa fa l’applicazione nel dettaglio? L’applicazione si occupa di queste attività: gestione autenticata delle configurazioni, gestione online degli utenti,import degli utenti in modo batch attivabile da bot far partire la funzione di scarpe e poi single page application per la votazione degli utenti e il retrieve autenticato di una configurazione.
Cos’altro fa? store dei log in cloud sui log di e-mail, rileva i malfunzionamenti e genera errori, errori che poi vengono mandati su Telegram. Questo è quello che fa l’applicazione.

Di cosa abbiamo bisogno per fare tutto questo? I dati non sono proprio aggiornatissimi perché oggi credo di aver aggiunto un altro paio di funzioni comunque sia ci sono: 10 funzioni lambda, list degli utenti, votazione degli utenti, il batch che importa gli utenti, dopodiché tre funzioni per la configurazione set, get e list (in cui il ho il get di tutte le mie configurazioni),autorizzazione su facebook, lander del messaggio di telegram, il dispatch del messaggio di telegram e il dispatch dei log, una coda sms, due tabelle DynamoDB (è il database non relazionale che mette a disposizione Amazon, se conoscete i database non relazionali, questo è leggermente diverso non pensate a un MongoDB, è un qualcosa di un pochino più complesso nel senso che ti permette di fare meno cose, o meglio più cose ma scrivendo molto più codice, infatti non si può fare una get semplice pura e semplice, bisogna specificare i dati si vogliono in uscita, è un pochino più complesso però nulla di stratosferico), dopodiché un bucket S3 che è quello che fa lo storage di tutti i nostri file statici. In più oltre a tutto questo per realizzare effettivamente la nostra applicazione abbiamo bisogno di uno stack di cloud formation, di altri bucket s3 e dei permessi ossia i ruoli, gli utenti, i gruppi tutto quello che comprendono i permessi.
Tutte queste ultime risorse vengono create in automatico dal framework Serverless, per cui noi non avremmo mai (o quasi) a che fare con tutte queste risorse accessorie che non servono direttamente alla nostra applicazione, perché farà tutto il framework in modo completamente trasparente.
A fine presentazione avete i link: un link statico, dei link dinamici (già cambiati per via di un’altro deploy) ,c’è un bot di Telegram e soprattutto c’è un repository di Ghitub.

[Segue una sezione dedicate alle domande del pubblico. Min: 43:40]

2018-06-26T10:44:19+00:00