Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

The Serverless Native Mindset

245 visualizaciones

Publicado el

In Serverless, as in software in general, the hardest part is always people.

Publicado en: Software
  • Sé el primero en comentar

The Serverless Native Mindset

  1. 1. The Hardest Part of Serverless: The Serverless Native Mindset AWS Community Day Boston, 2018-10-01 Ben Kehoe Cloud Robotics Research Scientist AWS Serverless Hero @ben11kehoe
  2. 2. 2@ben11kehoe 2015
  3. 3. 3@ben11kehoe
  4. 4. 4@ben11kehoe
  5. 5. 5@ben11kehoe
  6. 6. 6@ben11kehoe
  7. 7. 7 Going all-in on serverless: worth the trouble!
  8. 8. 8@ben11kehoe • We are a device company • We are a cloud-connected device company • We are not a cloud technology company • We are a cloud-enabled-features company • It’s not same thing iRobot’s business
  9. 9. 9 What do you do as a business?
  10. 10. 10@ben11kehoe • What do you do as a business? • What differentiates you? • For any work that is not a differentiator: ask why you’re doing it • Recursive: for any differentiating work, look for non-differentiating aspects, and ask why • You shouldn’t have to solve technology problems before you can solve your business problems Focusing on what you do
  11. 11. 11 Serverless is about focus
  12. 12. 12@ben11kehoe • Attention is limited; focus is a tradeoff • How can you pay less attention to undifferentiated heavy lifting? • Get someone else to do it • Use managed services How do we focus?
  13. 13. 13@ben11kehoe • Often equated with Lambda • This misses the bigger picture • And the smaller picture Understanding Serverless
  14. 14. 14@ben11kehoe Attachment is suffering (for compute)
  15. 15. 15@ben11kehoe Attachment is suffering (for compute)
  16. 16. 16@ben11kehoe • Managed services have been around forever • But business logic has to go somewhere… • Managed rules engines exist • But you can only get so far without actually coding something… • Ephemeral compute has enabled providers to manage code • Temporal: FaaS, streaming compute • Input: managed batch compute Why serverless compute isn’t just PaaS
  17. 17. 17@ben11kehoe • Use (and abuse) managed services wherever you can • “Service-full” • Glue it together with managed, ephemeral compute • FaaS is one example, but there are others Understanding Serverless
  18. 18. 18@ben11kehoe What: •Service-full + ephemeral compute • Not always F, not always aaS •Resources billed → resources used •Smaller, more abstract control plane Why: •Lower cost •Lower operations burden •Faster time to market •Focus on business value Serverless: more than just FaaS
  19. 19. 19 Use existing managed services in preference to building and/or hosting your own solution, even when those services don’t quite meet your requirements
  20. 20. 20 Serverless is masonry. FaaS is mortar. Buy your bricks.
  21. 21. 21@ben11kehoe • Attention is limited; focus is a tradeoff • How can you pay less atention to undifferentiated heavy lifting? • Get someone else to do it • Use managed services How do we focus?
  22. 22. 22@ben11kehoe • Conway says: your software architecture will match your organizational structure • Turning this around: what you want to do in software must be manifested in your organization Conway’s Law (not that Conway)
  23. 23. 23@ben11kehoe •Serverless is service-full •The dominant architectural pattern is usage of managed services •What does this mean for your organization? •The paradigm of outsourcing undifferentiated heavy lifting must be embraced by the culture Conway’s Corollary for Serverless
  24. 24. 24 Using managed services is an exercise in trust
  25. 25. 25@ben11kehoe • You only know what the provider tells you • Architecture • Security • Performance • Metrics • You can’t make changes to the service, you must accept that (today) it is what it is • You may not be able to remediate an provider’s outage With a managed service…
  26. 26. 26@ben11kehoe • Using a managed service, you can feel that you no longer own your own destiny • That is an uncomfortable feeling • Realize that you rely on many, many trusted providers to operate your business • Remember that trust is a journey This is scary!
  27. 27. 27@ben11kehoe • We are tinkerers • We like to know how things work • We like to own things Giving up control is hard for developers
  28. 28. 28@ben11kehoe “Not Invented Here”
  29. 29. 29@ben11kehoe “Profoundly Found Elsewhere” (P&G)
  30. 30. 30@ben11kehoe Serverless is minimalism
  31. 31. 31@ben11kehoe •Meaning of “serverless” •Kubernetes •Multi-cloud/vendor lock-in •SLAs Distractions
  32. 32. 32@ben11kehoe •It’s a terrible name. Nobody likes it, but we’re stuck with it, so get over it. •Like “cloud”, it is destined to be basically meaningless •Primary metric for the “serverlessness” of something: how managed is it? •Secondary metric: how closely does my bill match my usage? The meaning of “serverless”
  33. 33. 33@ben11kehoe • There are two kinds of servers • Infrastructure servers, like VMs • Application servers, like Node.js • You’re fully serverless only when both are managed • A container that is active when it’s not handling data is a server • A function that’s running on your infrastructure is not fully serverless Serverless sleight of hand
  34. 34. 34@ben11kehoe • Kubernetes on managed VMs is “serverless” for the k8s admins • But you have k8s admin to do • And management of whatever you’re running on k8s • Hosting FaaS on k8s: you have FaaS operations and maintenance to do • All of this is undifferentiated heavy lifting Let’s talk about Kubernetes
  35. 35. 35@ben11kehoe Multi-cloud
  36. 36. 36@ben11kehoe
  37. 37. 37@ben11kehoe
  38. 38. 38@ben11kehoe
  39. 39. 39@ben11kehoe
  40. 40. 40@ben11kehoe • Should an SLA make you feel more comfortable? • As a developer, no • An SLA is a financial guarantee, not a technical one • Essentially, it’s insurance, with the premium baked into the price What about SLAs?
  41. 41. 41 How do we adopt a serverless mindset?
  42. 42. 42@ben11kehoe
  43. 43. 43@ben11kehoe • Event-driven architectures are a natural fit for serverless architectures • Events are ephemeral by nature • Transition away from long-lived compute • Easier transition to serverless Events: a gateway drug for ephemeral compute
  44. 44. 44@ben11kehoe • Serverless requires both: • A level-headed assessment of risks • A full accounting of costs ̶ Developer time ̶ Operations bill ̶ Operations time • Your operations salaries should be in the same budget as your cloud bill Stay focused on Total Cost of Ownership
  45. 45. 45@ben11kehoe • Example: provider outages • What’s the impact? • What’s the likelihood? • What’s the cost of implementing a remediation strategy? • What’s the TCO for avoiding relying on a provider? Stay focused on Total Cost of Ownership
  46. 46. 46@ben11kehoe • Get developers connected to the business value they are creating • Team metrics should reflect this • Serverless helps developers move up the stack, closer to user-facing features • The hardest part: a culture that cares about features, not technology Encourage a focus on business value
  47. 47. 47@ben11kehoe Rube Goldberg machines
  48. 48. 48@ben11kehoe Building blocks
  49. 49. 49@ben11kehoe Making it work
  50. 50. 50@ben11kehoe • Serverless is extraordinarily powerful • The difference in operations between all serverless and mostly serverless is huge • Less so for development • What if you go all in? • It’s not easy, but it’s worth it Going all-in on serverless
  51. 51. 51@ben11kehoe
  52. 52. 52@ben11kehoe What: •Service-full + ephemeral compute • Not always F, not always aaS •Resources billed → resources used •Smaller, more abstract control plane Why: •Lower cost •Lower operations burden •Faster time to market •Focus on business value Summarizing Serverless
  53. 53. 53@ben11kehoe What: •Service-full + ephemeral compute • Not always F, not always aaS •Resources billed → resources used •Smaller, more abstract control plane Why: •Lower cost •Lower operations burden •Faster time to market •Focus on business value Summarizing Serverless
  54. 54. 54@ben11kehoe What: •Service-full + ephemeral compute • Not always F, not always aaS •Resources billed → resources used •Smaller, more abstract control plane Why: •Lower cost •Lower operations burden •Faster time to market •Focus on business value Summarizing Serverless
  55. 55. 55@ben11kehoe
  56. 56. 56 Serverless native: worth the trouble, and it will only get easier
  57. 57. Questions?

×