Si fa presto a dire serverless

Editor's Notes

• #3: Ultimamente si sente molto parlare di Serverless, ma secondo noi è un termine ambiguo che non lega molto con quello che in realtà si vuole comunicare perché ha assunto diversi significati. Serverless, come lo intendiamo noi non significa che non esistono server e tutto il codice viene eseguito come per magia. Si intende invece la possibilità di non dover gestire l’intera infrastruttura, perchè lo farà la piattaforma a cui ci appoggiamo. Per cui ci troviamo più a nostro agio a parlare di un’architettura Function as a Service (FaaS). Abbiamo quindi provato a dare una definizione il più semplice possibile.
• #4: Ultimamente si sente molto parlare di Serverless, ma secondo noi è un termine ambiguo che non lega molto con quello che in realtà si vuole comunicare perché ha assunto diversi significati. Serverless, come lo intendiamo noi non significa che non esistono server e tutto il codice viene eseguito come per magia. Si intende invece la possibilità di non dover gestire l’intera infrastruttura, perchè lo farà la piattaforma a cui ci appoggiamo. Per cui ci troviamo più a nostro agio a parlare di un’architettura Function as a Service (FaaS). Abbiamo quindi provato a dare una definizione il più semplice possibile.
• #5: Ultimamente si sente molto parlare di Serverless, ma secondo noi è un termine ambiguo che non lega molto con quello che in realtà si vuole comunicare perché ha assunto diversi significati. Serverless, come lo intendiamo noi non significa che non esistono server e tutto il codice viene eseguito come per magia. Si intende invece la possibilità di non dover gestire l’intera infrastruttura, perchè lo farà la piattaforma a cui ci appoggiamo. Per cui ci troviamo più a nostro agio a parlare di un’architettura Function as a Service (FaaS). Abbiamo quindi provato a dare una definizione il più semplice possibile.
• #6: Ultimamente si sente molto parlare di Serverless, ma secondo noi è un termine ambiguo che non lega molto con quello che in realtà si vuole comunicare perché ha assunto diversi significati. Serverless, come lo intendiamo noi non significa che non esistono server e tutto il codice viene eseguito come per magia. Si intende invece la possibilità di non dover gestire l’intera infrastruttura, perchè lo farà la piattaforma a cui ci appoggiamo. Per cui ci troviamo più a nostro agio a parlare di un’architettura Function as a Service (FaaS). Abbiamo quindi provato a dare una definizione il più semplice possibile.
• #7: Custom code è il codice applicativo che vogliamo eseguire, è il servizio che vogliamo erogare agli utenti, ai clienti. Il nostro codice viene eseguito a seguito di un evento specifico scatenato sulla piattaforma, ad esempio AWS ha molti eventi configurabili tra cui un evento S3, DynamoDB, SNS, CloudWatch eccetera...
• #8: Custom code è il codice applicativo che vogliamo eseguire, è il servizio che vogliamo erogare agli utenti, ai clienti. Il nostro codice viene eseguito a seguito di un evento specifico scatenato sulla piattaforma, ad esempio AWS ha molti eventi configurabili tra cui API Gateway, S3 eccetera...
• #9: Codice che viene eseguito in un contesto effimero. E’ un contesto di esecuzione che dura poco tempo, possiamo dire che viene creato per eseguire il nostro codice e, una volta completata l’esecuzione, viene distrutto. Di conseguenza non è possibile avere stato o persistenza all’interno del nostro codice, come la gestione di sessioni eccetera. Viene comunque eseguito all’interno di un server del nostro cloud provider.
• #10: Quindi per evitare fraintendimenti a noi piace chiamarlo Function as a Service.
• #14: !!! NB: Alcuni di questi valgono solo per AWS Lambda !!!! _________________________________________ cambiare i punti relativi solo ad AWS (limite in futuro può essere ritoccato) Modello di pagamento?? (verificare google cloud e azure)
• #18: Iniziamo con un caso in cui abbiamo applicato un’architettura FaaS ...
• #19: Abbiamo sviluppato le API backend di questa piattaforma online di fotografia in cui gli aspiranti fotografi posso mostrare il loro lavoro. Ogni foto caricata viene verificata dallo staff di Vogue Italia che eventualmente ne permette la pubblicazione sulla piattaforma.
• #20: Abbiamo sviluppato le API backend di questa piattaforma online di fotografia in cui gli aspiranti fotografi posso mostrare il loro lavoro. Ogni foto caricata viene verificata dallo staff di Vogue Italia che eventualmente ne permette la pubblicazione sulla piattaforma.
• #21: Questa piattaforma attualmente permette la gestione di circa 400.000 foto da parte di oltre 130.000 fotografi. Lo staff di Vogue Italia deve verificare ogni giorno circa 3.000 immagini.
• #22: L’applicazione ha bisogno di scalare molto e spesso perché deve riuscire a sopportare intensi picchi di richieste in diverse fasce orarie. Il servizio di caricamento è aperto solamente alcuni giorni a settimana. State - sessions on possiamo essere sicuri di salvare qualcosa nella nostra funzione e ritrovarlo alla chiamata successiva, quindi per queste funzionalità ci appoggiamo ai servizi del cloud provider oppure a servizi esterni. Non abbiamo bisogno di gestire processi o applicazioni di lunga durata quindi ci basta il limite di 5 minuti imposto da AWS. Applicazione web deve essere veloce. Alcune funzionalità devono rispondere ad un evento specifico ed effettuare varie operazioni. Prendiamo come esempio l’upload dei file da parte dei fotografi.
• #23: Questo è un esempio di come funziona la gestione degli upload di foto all’interno della nostra applicazione. Un fotografo fa un upload di una fotografia sullo Storage System nel nostro caso S3. Una volta completato l’upload, S3 scatena un evento che invoca le nostre Funzioni. In questo caso specifico le nostre funzioni si occupano di validare il formato ed eventualmente, ridimensionare in diverse dimensioni la fotografia e salva i suoi riferimenti in un database associandola all’utente. La funzione vive solo per il tempo di ridimensionamento dell’immagine. Questo ci permette un notevole risparmio sia di risorse che di tempo perché queste azioni vengono scalate orizzontalmente in modo naturale dall’architettura FaaS eseguendo i processi di ridimensionamento della foto in parallelo.
• #24: Durante lo sviluppo abbiamo trovato sia dei benefici che delle sfide da affrontare nell’adozione di questa soluzione.
• #25: Non abbiamo downtime durante il deploy. Per descrivere bene questo vantaggio è necessario capire come funziona il processo di deploy delle funzioni su AWS. Ogni funzione viene deployata singolarmente, ed è un semplice upload. Insieme al codice della funzione vengono impacchettate tutte le dipendenze richieste. Il pacchetto, poi, viene caricato sul cloud provider che si occupa di rendere disponibile la funzione all’interno dell’infrastruttura. In AWS ogni upload crea una nuova versione della funzione, in questo modo è possibile taggare le varie versioni con ad esempio “PRODUCTION”, “STAGING”, per poter utilizzare una versione specifica per ogni ambiente. -- sistemare -- Carichi funzione mentre la carichi non è pubblicata, come atto finale vai a taggare la versione con un etichetta in modo da rendere disponibile la funzione tramite un’etichetta specifica. (questo garantisce lo zero downtime) facile tornare indietro
• #26: Con FaaS siamo consapevoli di aggiornare una singola funzionalità senza intaccare altre parti dell’applicazione, di conseguenza siamo riusciti ad incrementare il numero di deploy effettuati al mese, questo ci ha permesso di avere feedback più rapidi sulle nuove funzionalità.
• #27: In base alle richieste il cloud provider gestisce autonomamente l’eventuale creazione di nuovi container in maniera totalmente trasparente. Quindi potrebbe scalare orizzontalmente qualora ce ne fosse la necessità duplicando la singola funzione in un nuovo container. ---
• #31: Le sfide più importanti che abbiamo dovuto affrontare
• #32: codice agnostico dal contesto in cui viene eseguito (es: aws invece che google cloud) Cerchiamo di diminuire il vendor lockin ma siamo consapevoli che rimane comunque abbastanza forte.
• #33: Il codice dovrebbe essere agnostico dal contesto in cui viene eseguito (es: aws invece che google cloud) Quindi abbiamo cercato di astrarre il codice che dipende dai servizi del cloud provider disaccoppiando la logica di business dalla piattaforma. In questo modo se si dovesse sostituire un servizio o passare ad un altro provider si dovrebbero riscrivere solo gli adattori verso il nuovo cloud provider.
• #34: Abbiamo utilizzato il framework Serverless che con le ultime versioni è compatibile anche con Azure Functions. HELPS IN DRIVING YOUR DEVELOPMENT ON A CLEAR PATH, HIDING ALL THE WORK NEEDED TO CONFIGURE, WIRE AND UPLOAD A LAMBDA TO AWS RUN/TEST AWS LAMBDA FUNCTIONS LOCALLY, OR REMOTELY AUTO-DEPLOYS, VERSIONS & ALIASES LAMBDA FUNCTIONS AND API ENDPOINTS INTERACTIVE CLI DASHBOARD TO EASILY SELECT AND DEPLOY FUNCTIONS AND ENDPOINTS
• #37: PRO Facile aggiornarle in un colpo solo Non è necessario gestire dipendenze CONS: Rendi la funzione più grossa Viola il principio di singola responsabilità (Rischi di rompere una funzionalità toccandone un’altra)
• #38: PRO Facile aggiornarle in un colpo solo Non è necessario gestire dipendenze CONS: Rendi la funzione più grossa Viola il principio di singola responsabilità (Rischi di rompere una funzionalità toccandone un’altra)
• #39: PRO Facile condividere delle parti dell’applicazione Non è necessario gestire dipendenze CONS: Aumenta il tempo di deploy Se una delle due ha delle dipendenze grosse, queste vengono caricate inutilmente anche sull’altra Devi gestire il possibile disallineamento del codice delle diverse funzioni a meno che ad ogni modifica non fai il deploy di tutte le functions.
• #40: PRO Facile condividere delle parti dell’applicazione Non è necessario gestire dipendenze CONS: Aumenta il tempo di deploy Se una delle due ha delle dipendenze grosse, queste vengono caricate inutilmente anche sull’altra Devi gestire il possibile disallineamento del codice delle diverse funzioni a meno che ad ogni modifica non fai il deploy di tutte le functions.
• #41: PRO: Zero duplicazione del codice La dipendenza è esterna ed è possibile gestirla semplicemente con le sue versioni CONS: Aumenta il tempo di startup del container E’ necessario gestire esternamente una libreria
• #42: PRO: Zero duplicazione del codice La dipendenza è esterna ed è possibile gestirla semplicemente con le sue versioni CONS: Aumenta il tempo di startup del container E’ necessario gestire esternamente una libreria
• #43: PRO: Non hai duplicazione, non hai dipendenze da codice condiviso Possibile gestire le versione della lambda(dipendenza) utilizzando i tag in fase di deploy ed esplicitando la versione desiderata. CONS: Aumenta il tempo di esecuzione a causa della chiamata ad una differente funzione Un point of failure aggiuntivo rende più difficile capire esattamente dove si trova il problema (e comunicare se c’è un fallimento) Se le chiamate sono sincrone si raddoppia il costo di esecuzione(risolvere facendo chiamate asincrone con utilizzando per esempio delle code)
• #44: PRO: Non hai duplicazione, non hai dipendenze da codice condiviso Possibile gestire le versione della lambda(dipendenza) utilizzando i tag in fase di deploy ed esplicitando la versione desiderata. CONS: Aumenta il tempo di esecuzione a causa della chiamata ad una differente funzione Un point of failure aggiuntivo rende più difficile capire esattamente dove si trova il problema (e comunicare se c’è un fallimento) Se le chiamate sono sincrone si raddoppia il costo di esecuzione(risolvere facendo chiamate asincrone con utilizzando per esempio delle code)
• #45: Bisogna tenere conto di cosa è più importante per te (performance, qualità, point of failure).
• #48: cosa è il disaster recovery: In caso un datacenter/region/multidatacenter falliscano, si garantisce la continuità del servizio
• #50: Sempre acceso, sempre spento?
• #51: Sempre acceso, sempre spento?
• #62: Risparmio su piu fronti No 3 party NO instance