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 ...

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/