Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Becoming a cloud native ... genuinely!

Becoming a cloud native ... genuinely!

This slide deck discusses the novel options, public cloud gives us in 2022. I start by differentiating it from the widespread microservices-containers-Kubernetes "cloud native" definition. I provide a few examples where I compare "cloud native" and actually leveraging the potentials of the public cloud in terms of costs and time-to-market.

Then I continue by showing, how public cloud evolved from a bit of on-demand compute and storage in 2007 to a disruptive game changer in 2022 that offers novel options that did not exist before and do only exist in the public cloud. As any public cloud discussion (at least in Germany where I live) tends to trigger lots of "yes, but ..." discussions, I rebut the most popular ones.

At the end, I complete the talk with a few recommendations and a look at the darker sides of the public cloud (of course, not everything is golden).

As always, the voice track is missing. Still, I hope the slides give you some ideas to ponder ...

Uwe Friedrichsen

October 08, 2022
Tweet

More Decks by Uwe Friedrichsen

Other Decks in Technology

Transcript

  1. Becoming a cloud native ... genuinely! Exploring the cloud beyond

    containers and microservices Uwe Friedrichsen – codecentric AG) – 2012-2022
  2. Uwe Friedrichsen Works @ codecentric https://twitter.com/ufried https://www.speakerdeck.com/ufried https://ufried.com/

  3. "I write microservices and run them in containers using Kubernetes.

    Therefore, I am a cloud native!"
  4. Yeah!

  5. At least that is what the CNCF* keeps telling us

    ... * Cloud Native Computing Foundation
  6. Cloud Native Computing Foundation (“CNCF”) Charter (Excerpt) 1. Mission of

    the Cloud Native Computing Foundation. The Foundation’s mission is to make cloud native computing ubiquitous. The CNCF Cloud Native Definition v1.0 says: Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach. These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil. The Cloud Native Computing Foundation seeks to drive adoption of this paradigm by fostering and sustaining an ecosystem of open source, vendor-neutral projects. We democratize state-of-the-art patterns to make these innovations accessible for everyone. https://github.com/cncf/foundation/blob/main/charter.md
  7. So, we are done here?

  8. And they lived happily ever after ... The End ?

  9. Let us dig deeper ...

  10. Small e-commerce site A bit cloud native approach • Team

    of 7-12 developers for 12+ months • Several container instances • Testing, hardening, monitoring, compliance (PCI-DSS) • 3-5 developers after launch for maintenance and improvements, updating infrastructure,... Upfront costs: > 1 Mio. € Time2Market: > 12 months Runtime costs: > 500.000 € p.a. Actual cloud native approach • Shopify • Team of 2 consultants for 2 weeks • 1 consultant after launch for 5-10 days p.a. Upfront costs: < 30.000 € Time2Market: 2 weeks Runtime costs: < 20.000 € p.a. (incl. Shopify fees)
  11. Full blown eCommerce platform A bit cloud native approach •

    Team of 50+ developers for 2+ years • Dozens of container and VM instances • Testing, hardening, monitoring, compliance (PCI-DSS) • 20+ developers after launch Upfront costs: > 15 Mio. € Time2Market: > 2 years Runtime costs: > 5 Mio. € p.a. Actual cloud native approach • commercetools • Team of 10 developers for 9 months • 3 developers after launch Upfront costs: ~ 1 Mio € Time2Market: 9 months Runtime costs: < 1 Mio € p.a. (commercetools : ~500.000 €/p.a.)
  12. ML/AI - Image Recognition A bit cloud native approach •

    Team of 2 data scientists for 3-6 months training data gathering, model search and training, tuning, ... • Team of 2-3 developers for 2-3 months building production version • 0,5 data scientists & 0,5 devs after launch for model adjustments, retraining, maintenance, ... • Costs for building data pipelines excluded Upfront costs: > 200.000 € (+ hardware) Time2Market: > 6 months Runtime costs: > 100.000 € p.a. Actual cloud native approach • AWS Rekognition Upfront costs: 0 € Time2Market: Immediate Runtime costs: < 10.000 € p.a. (10.000.000 Image p.a.)
  13. What can we learn from it?

  14. Public cloud gives you novel options regarding cycle times, time-to-market,

    innovation capabilities, flexibility, operations cost savings, scalability, dependability, even improved ecological footprint that did not exist before
  15. You need to leverage the public cloud to experience the

    cloud revolution
  16. Cloud revolution?

  17. Genesis Custom built Product (+ rental) Commodity (+ utility) Evolution

    Customer Invisible Value chain Visible Uncharted Industrialized Basic services Custom software solutions Standard software solutions Platform Infrastructure Data Center Binds all IT capacities available. No capacity to address higher-level or new customer needs Before Cloud (on-premises) Actual needs Basic needs Customer needs to break down actual needs to basic needs because services offered by supplier do not address actual needs
  18. Genesis Custom built Product (+ rental) Commodity (+ utility) Evolution

    Customer Invisible Value chain Visible Uncharted Industrialized Basic needs Basic services Custom software solutions Standard software solutions Platform Infrastructure Cloud compute Public cloud 2008 Frees IT capacity for higher-level functions Actual needs
  19. Genesis Custom built Product (+ rental) Commodity (+ utility) Evolution

    Customer Invisible Value chain Visible Uncharted Industrialized Basic needs Basic services Custom software solutions Standard software solutions Platform Cloud compute Public cloud 2011 IaaS Frees IT capacity for higher-level functions Actual needs
  20. Genesis Custom built Product (+ rental) Commodity (+ utility) Evolution

    Customer Invisible Value chain Visible Uncharted Industrialized Basic needs Basic services Custom software solutions Standard software solutions Cloud compute Public cloud 2014 PaaS Frees IT capacity for higher-level functions IaaS Actual needs
  21. Genesis Custom built Product (+ rental) Commodity (+ utility) Evolution

    Customer Invisible Value chain Visible Uncharted Industrialized Basic needs Cloud compute Public cloud 2017 Serverless Basic services Service integration Frees IT capacity for higher-level functions Actual needs IaaS PaaS
  22. Genesis Custom built Product (+ rental) Commodity (+ utility) Evolution

    Actual needs Customer Invisible Value chain Visible Uncharted Industrialized Supplier can occupy still uncharted business territory, e.g., by immediately addressing actual customer needs -> competitive advantage Cloud compute Higher level services Public cloud 2020+ IT capacity for rapid innovation available, attacking completely new business opportunities IaaS PaaS Serverless
  23. This is what I mean with (public) cloud revolution

  24. This is where the novel options come from

  25. This is not possible with a private cloud

  26. Genesis Custom built Product (+ rental) Commodity (+ utility) Evolution

    Customer Invisible Value chain Visible Uncharted Industrialized Basic services Custom software solutions Standard software solutions Platform Infrastructure Data Center Binds all IT capacities available. No capacity to address higher-level or new customer needs Before Cloud (on-premises) Actual needs Basic needs Customer needs to break down actual needs to basic needs because services offered by supplier do not address actual needs
  27. Genesis Custom built Product (+ rental) Commodity (+ utility) Evolution

    Customer Invisible Value chain Visible Uncharted Industrialized Basic needs Basic services Customer needs to break down actual needs to basic needs because services offered by supplier do not address actual needs Custom software solutions Standard software solutions Platform Infrastructure Data Center IT capacities still fully bound. No capacity to address higher-level or new customer needs Private cloud Actual needs
  28. But that means vendor lock-In!

  29. So what?

  30. You want lock-in!

  31. You should just do your homework first

  32. t Begin of usage of “lock-in” solution Expected usage duration

    Costs of running self-built solution Costs of running “lock-in” solution Exit costs and risks Economic decision margin TCO-based “lock-in” decision (simplified)
  33. But with OSS I do not have lock-in!

  34. Really?

  35. Every decision for a tool, product, platform, library, framework, programming

    language, etc. means “lock-in”
  36. Without any “lock-in”, you would sit with a plain computer

    without any software on it – no OS, nothing. You would need to develop all software from scratch.
  37. You (hopefully) deliberately choose lock-in to reduce efforts, costs and

    risks based on using the chosen solution
  38. And it always means effort and risk if you need

    to migrate away from the chosen solution
  39. This is also true if you choose an OSS solution

  40. But we could maintain the OSS solution ourselves if needed!

  41. Really?

  42. Have you ever seen that happen?

  43. Have you considered what that would mean in practice?

  44. It will not happen

  45. But OSS is for free!

  46. Is it?

  47. Most “OSS companies” these days are plain commercial companies that

    offer OSS variants of their products as “free samples” to push future sales of their commercial solutions
  48. For production use, you will need the commercial version of

    the product because the OSS version typically lacks critical production features
  49. To be clear: This is a perfectly legit practice. But

    it should not be confused with “free”
  50. BTW: Ever considered the ethical implications of expecting to use

    other people’s work for free to create something you make money with without giving back anything? This is what the typical “OSS first” strategy means in practice
  51. And even if the software is actually “for free”, using

    it still costs a lot of money
  52. Costs associated with OSS • License costs • Integration costs

    • Customization costs • Required features, commercial alternatives have built in • No new features “for free” with product upgrades • Maintenance costs (e.g., responding to CVEs quickly) • Operation costs (including personnel costs) • Training costs • Opportunity costs for longer T2M • ...
  53. OSS never is “for free”

  54. To be clear: There is nothing wrong with using OSS

    solutions. But please do the math and do not fall for strawman arguments.
  55. Okay, I see

  56. Back to cloud ...

  57. Quick reminder ...

  58. Public cloud gives you novel options regarding cycle times, time-to-market,

    innovation capabilities, flexibility, operations cost savings, scalability, dependability, even improved ecological footprint that did not exist before
  59. You need to leverage the public cloud to experience the

    cloud revolution
  60. How can we become cloud natives?

  61. Understand serverless • Managed services • Learn which (popular) managed

    services exist in your domain • Understand their capabilities and limitations • Function-as-a-Service (FaaS) • Learn how to use it as a universal integration layer • Understand the architectural paradigm and its implications • Understand its options and its limits
  62. Understand cloud native design • Which paradigm to use •

    Combining compute, storage and network options • Build vs. lease • Scaling up and down, availability, costs, ... • Much more than just microservices and containers!
  63. Understand cloud economy • Runtime cost efficiency is achieved differently

    • Simple “lift & shift” usually increases runtime costs • Different paradigms support different use cases best • Moving data around has a price tag • Think about auto-rightsizing • Consider all types of costs!
  64. Understand cloud security • Different from traditional on-premises security •

    Provides lots of fine-grained options • Steep learning curve • Essential for building dependable solutions
  65. Understand cloud sustainability • We want to minimize our ecological

    footprint! • Know the cloud provider’s guides to sustainability • Pick the right paradigm for the given use case • Watch for good server utilization • Do not forget downscaling • Balance performance, availability and sustainability
  66. Is everything golden?

  67. Of course not

  68. Issues and pitfalls • Many services to choose from –

    steep learning curve • Standard APIs still missing – lots of integration work • Services not always mature – DX can still be PITA • Costs can explode if you are not careful • Dominated by players from the USA and China • Geopolitical developments will shape access to public cloud
  69. Shouldn’t I rather wait and observe?

  70. You could wait until the dust has settled, the teething

    troubles have been overcome and everything works nicely
  71. But then others who started early will have an unassailable

    lead
  72. Competitive advantage is shaped in the realm of early adopters,

    not in the realm of late followers
  73. Hence, dive in now, learn the options of the public

    cloud ...
  74. ... learn how to leverage its potential ...

  75. ... know about the risks and pitfalls ...

  76. ... deal with lock-in risks in a grown-up way ...

  77. ... and experience the cloud revolution!

  78. Wrap-up

  79. Wrap-up • Cloud is much more than containers and microservices

    • Understand the cloud revolution • Understand what “lock-in” really means • Learn how to leverage the options the public cloud offerings • Understand the pitfalls and risks
  80. Yeah!

  81. Uwe Friedrichsen Works @ codecentric https://twitter.com/ufried https://www.speakerdeck.com/ufried https://ufried.com/