Si fa presto a dire serverless
•
1 like•901 views
Our Experience with Function as a Service architetture (aka Serverless)
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Si fa presto a dire serverless
Similar to Si fa presto a dire serverless (20)
Recently uploaded
Recently uploaded (20)
Si fa presto a dire serverless
- 1. Nome Speaker @twitter Si fa presto a dire Serverless Daniel Depaoli @dedaniel_xp Alessio Coser @AlessioCoser
- 2. Si fa presto a dire Serverless What we are going to talk about? 1. Introduction to Serverless 2. Our Dev Experience 3. Our Ops Experience
- 3. Si fa presto a dire Serverless What is Serverless?
- 4. Si fa presto a dire Serverless What is Serverless?
- 5. Si fa presto a dire Serverless Function as a Service
- 6. Si fa presto a dire Serverless What is a Function? Custom code that’s run in an ephemeral context.
- 7. Si fa presto a dire Serverless What is a Function? Custom code that’s run in an ephemeral context. ● The code/application that we want to execute ● The Service we provide to our users ● Responds to events
- 8. Si fa presto a dire Serverless What is a Function? ● Created only to run your code and then destroyed ● Has no state or persistence ● It’s still a server! Custom code that’s run in an ephemeral context.
- 9. Si fa presto a dire Serverless What is a Function?
- 10. Si fa presto a dire Serverless Functions Application Runtime Operating System Virtualization Hardware IaaS Customer Managed Unit of scale Customer Managed Abstract by vendor
- 11. Si fa presto a dire Serverless Functions Application Runtime Operating System Virtualization Hardware Functions Application Runtime Operating System Virtualization Hardware IaaS PaaS Customer Managed Unit of scale Customer Managed Abstract by vendor
- 12. Si fa presto a dire Serverless Functions Application Runtime Operating System Virtualization Hardware Functions Application Runtime Operating System Virtualization Hardware Functions Application Runtime Operating System Virtualization Hardware IaaS PaaS FaaS Customer Managed Unit of scale Customer Managed Abstract by vendor
- 13. ● No infrastructure maintenance ● Built-in automatic scaling ● Only pay for the execution time ● No persistence, no state ● Limited execution time ● Fully integrated with cloud provider’s services Si fa presto a dire Serverless Main features
- 14. Si fa presto a dire Serverless Cloud-Computing Providers ● Amazon AWS Lambda ● Google Cloud Functions ● Azure Functions
- 15. Si fa presto a dire Serverless Runtimes ● NODE.JS ● JAVA ● PYTHON ● More
- 16. Nome Speaker @twitter Our Dev experience Si fa presto a dire Serverless
- 18. Our Dev experiences PhotoVogue
- 19. An online photography platform ● Allows upcoming photographers to showcase their work. ● Each picture that’s submitted is carefully reviewed by Vogue Italia’s editorial staff. Our Dev experiences PhotoVogue
- 20. ● ~ 400,000 photos ● ~ 130,000 photographers ● ~ 3,000 uploaded images each day An online photography platform Our Dev experiences PhotoVogue
- 21. Our Dev experiences PhotoVogue ● Application that scales ● No state or sessions ● No long running scripts ● Upload and resize of photos in parallel How FaaS applies to the domain
- 22. Upload and resize feature Our Dev experiences PhotoVogue FaaS EVENT S3 UPLOAD RESIZED IMAGES AWS
- 23. Benefits Our Dev experiences PhotoVogue
- 24. Zero downtime deployment Our Dev experiences PhotoVogue
- 25. > 1 deploy per day Our Dev experiences PhotoVogue
- 26. Autoscaling Our Dev experiences PhotoVogue
- 27. Average of ~ 650 invocation/minute Our Dev experiences PhotoVogue
- 28. Maximum peaks > 1500 invocation/minute Our Dev experiences PhotoVogue
- 29. (as long as an entire AWS region does not crash) [image] Our Dev experiences PhotoVogue No downtime
- 30. Challenges Our Dev experiences PhotoVogue
- 31. Vendor lock-in Our Dev experiences PhotoVogue
- 32. Decouple business logic from the cloud platform Our Dev experiences PhotoVogue
- 33. Use a Framework like Serverless Our Dev experiences PhotoVogue
- 34. Dependencies Our Dev experiences PhotoVogue
- 35. Very common problem: You have two distinct functionalities, and they share some of their code Our Dev experiences PhotoVogue
- 36. 1st solution: Create a single function which responds to two different events Our Dev experiences PhotoVogue
- 37. Easy to update No dependencies to manage Big function Violates Single Responsibility Principle Our Dev experiences PhotoVogue
- 38. 2nd solution: Create two different functions with the same code Our Dev experiences PhotoVogue
- 39. Common parts are easier to share No dependencies to manage Deploy takes longer Unnecessary dependencies are also shared Must deploy each function to update common code Our Dev experiences PhotoVogue
- 40. 3rd solution: Create two different functions with an external shared dependency (es: git, npm) Our Dev experiences PhotoVogue
- 41. No duplicated code Can use different versions of dependency Startup time increases You have to manage an external library Our Dev experiences PhotoVogue
- 42. 4th solution: Create two different functions that will invoke a third one (containing the shared behaviour) Our Dev experiences PhotoVogue
- 43. No duplicated code Can use different versions of common function Execution time increases Additional point of failure Our Dev experiences PhotoVogue
- 44. There isn’t a perfect solution Our Dev experiences PhotoVogue
- 45. Nome Speaker @twitter Our Ops experiences Si fa presto a dire Serverless
- 46. Our Ops experiences Disaster Recovery and Testing
- 47. A Disaster Recovery implementation Our Ops experiences Disaster Recovery and Testing
- 48. Our Ops experiences Disaster Recovery and Testing AWS does not provide a DR solution
- 49. 1. Backup a. Every night create VMs snapshot b. Move snapshots to another AWS region Our Ops experiences Disaster Recovery and Testing Our implementation with FaaS
- 50. 2. Recovery a. Activate the new environment in alternative region with lastest snapshots 3. Test a. Check services and send notification Our Ops experiences Disaster Recovery and Testing Our implementation with FaaS
- 51. Our Ops experiences Interaction with infrastructure
- 52. Sometimes we need to schedule a task Our Ops experiences Interaction with infrastructure
- 53. Our Ops experiences Interaction with infrastructure Load Balancer Instance InstanceInstance task Master ● Lambda direct SSH connection to instance ● Triggering or doing particular tasks
- 54. ● Check Backup S3 ● Dump DB ● Clean EFS ● Etc. Our Ops experiences Interaction with infrastructure Some example:
- 55. Our Ops experiences Operations and monitoring
- 56. Simulating user browsing session Our Ops experiences Monitoring
- 57. Our Ops experiences Monitoring
- 58. Integration with versioning system hosting service Our Ops experiences CI/CD
- 59. Benefits Our Ops experiences Monitoring
- 60. No third party tools Our Ops experiences
- 61. No instances for just one task Our Ops experiences
- 62. Our Ops experiences Trigger one shot action
- 63. Fully integrated with other AWS services Our Ops experiences
- 64. Conclusions
- 65. FaaS - when? Conclusions ● You need to simplify operational tasks ● Your app needs to scale ● Your domain logic is event based ● You need to process a large quantity of data
- 66. ● You want some form of control over the infrastructure ● You have to maintain some state into the app ● Your functions take a long time to run FaaS - when not? Conclusions
- 67. Nome Speaker @twitter Thanks! PS: We are hiring -> www.xpeppers.com/carriere
- 68. Nome Speaker @twitter Questions? PS: We are hiring -> www.xpeppers.com/carriere
Editor's Notes
- 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.
- 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.
- 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.
- 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.
- 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...
- 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...
- 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.
- Quindi per evitare fraintendimenti a noi piace chiamarlo Function as a Service.
- !!! 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)
- Iniziamo con un caso in cui abbiamo applicato un’architettura FaaS ...
- 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.
- 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.
- 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.
- 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.
- 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.
- Durante lo sviluppo abbiamo trovato sia dei benefici che delle sfide da affrontare nell’adozione di questa soluzione.
- 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
- 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à.
- 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. ---
- Le sfide più importanti che abbiamo dovuto affrontare
- 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.
- 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.
- 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
- 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)
- 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)
- 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.
- 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.
- 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
- 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
- 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)
- 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)
- Bisogna tenere conto di cosa è più importante per te (performance, qualità, point of failure).
- cosa è il disaster recovery: In caso un datacenter/region/multidatacenter falliscano, si garantisce la continuità del servizio
- Sempre acceso, sempre spento?
- Sempre acceso, sempre spento?
- Risparmio su piu fronti No 3 party NO instance