O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

Si fa presto a dire serverless

5.612 visualizações

Publicada em

La nostra esperienza nell'uso dell'architettura Function as a Service (Serverless)

  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Si fa presto a dire serverless

  1. 1. Nome Speaker @twitter Si fa presto a dire Serverless Daniel Depaoli @dedaniel_xp Alessio Coser @AlessioCoser
  2. 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. 3. Si fa presto a dire Serverless What is Serverless?
  4. 4. Si fa presto a dire Serverless What is Serverless?
  5. 5. Si fa presto a dire Serverless Function as a Service
  6. 6. Si fa presto a dire Serverless What is a Function? Custom code that’s run in an ephemeral context.
  7. 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. 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. 9. Si fa presto a dire Serverless What is a Function?
  10. 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. 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. 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. 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. 14. Si fa presto a dire Serverless Cloud-Computing Providers ● Amazon AWS Lambda ● Google Cloud Functions ● Azure Functions
  15. 15. Si fa presto a dire Serverless Runtimes ● NODE.JS ● JAVA ● PYTHON ● More
  16. 16. Nome Speaker @twitter Our Dev experience Si fa presto a dire Serverless
  17. 17. Our Dev experiences aws.amazon.com/solutions/case-studies/photovogue
  18. 18. Our Dev experiences PhotoVogue
  19. 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. 20. ● ~ 400,000 photos ● ~ 130,000 photographers ● ~ 3,000 uploaded images each day An online photography platform Our Dev experiences PhotoVogue
  21. 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. 22. Upload and resize feature Our Dev experiences PhotoVogue FaaS EVENT S3 UPLOAD RESIZED IMAGES AWS
  23. 23. Benefits Our Dev experiences PhotoVogue
  24. 24. Zero downtime deployment Our Dev experiences PhotoVogue
  25. 25. > 1 deploy per day Our Dev experiences PhotoVogue
  26. 26. Autoscaling Our Dev experiences PhotoVogue
  27. 27. Average of ~ 650 invocation/minute Our Dev experiences PhotoVogue
  28. 28. Maximum peaks > 1500 invocation/minute Our Dev experiences PhotoVogue
  29. 29. (as long as an entire AWS region does not crash) [image] Our Dev experiences PhotoVogue No downtime
  30. 30. Challenges Our Dev experiences PhotoVogue
  31. 31. Vendor lock-in Our Dev experiences PhotoVogue
  32. 32. Decouple business logic from the cloud platform Our Dev experiences PhotoVogue
  33. 33. Use a Framework like Serverless Our Dev experiences PhotoVogue
  34. 34. Dependencies Our Dev experiences PhotoVogue
  35. 35. Very common problem: You have two distinct functionalities, and they share some of their code Our Dev experiences PhotoVogue
  36. 36. 1st solution: Create a single function which responds to two different events Our Dev experiences PhotoVogue
  37. 37. Easy to update No dependencies to manage Big function Violates Single Responsibility Principle Our Dev experiences PhotoVogue
  38. 38. 2nd solution: Create two different functions with the same code Our Dev experiences PhotoVogue
  39. 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. 40. 3rd solution: Create two different functions with an external shared dependency (es: git, npm) Our Dev experiences PhotoVogue
  41. 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. 42. 4th solution: Create two different functions that will invoke a third one (containing the shared behaviour) Our Dev experiences PhotoVogue
  43. 43. No duplicated code Can use different versions of common function Execution time increases Additional point of failure Our Dev experiences PhotoVogue
  44. 44. There isn’t a perfect solution Our Dev experiences PhotoVogue
  45. 45. Nome Speaker @twitter Our Ops experiences Si fa presto a dire Serverless
  46. 46. Our Ops experiences Disaster Recovery and Testing
  47. 47. A Disaster Recovery implementation Our Ops experiences Disaster Recovery and Testing
  48. 48. Our Ops experiences Disaster Recovery and Testing AWS does not provide a DR solution
  49. 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. 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. 51. Our Ops experiences Interaction with infrastructure
  52. 52. Sometimes we need to schedule a task Our Ops experiences Interaction with infrastructure
  53. 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. 54. ● Check Backup S3 ● Dump DB ● Clean EFS ● Etc. Our Ops experiences Interaction with infrastructure Some example:
  55. 55. Our Ops experiences Operations and monitoring
  56. 56. Simulating user browsing session Our Ops experiences Monitoring
  57. 57. Our Ops experiences Monitoring
  58. 58. Integration with versioning system hosting service Our Ops experiences CI/CD
  59. 59. Benefits Our Ops experiences Monitoring
  60. 60. No third party tools Our Ops experiences
  61. 61. No instances for just one task Our Ops experiences
  62. 62. Our Ops experiences Trigger one shot action
  63. 63. Fully integrated with other AWS services Our Ops experiences
  64. 64. Conclusions
  65. 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. 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. 67. Nome Speaker @twitter Thanks! PS: We are hiring -> www.xpeppers.com/carriere
  68. 68. Nome Speaker @twitter Questions? PS: We are hiring -> www.xpeppers.com/carriere
  69. 69. www.xpeppers.com /xpepperssrl@xpeppers

×