Becoming a cloud native ... genuinely! Exploring the cloud beyond containers and microservices Uwe Friedrichsen – codecentric AG) – 2012-2022

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

"I write microservices and run them in containers using Kubernetes. Therefore, I am a cloud native!"

Yeah!

At least that is what the CNCF* keeps telling us ... * Cloud Native Computing Foundation

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

So, we are done here?

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

Let us dig deeper ...

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)

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

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

What can we learn from it?

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

You need to leverage the public cloud to experience the cloud revolution

Cloud revolution?

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

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

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

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

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

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

This is what I mean with (public) cloud revolution

This is where the novel options come from

This is not possible with a private cloud

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

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

But that means vendor lock-In!

So what?

You want lock-in!

You should just do your homework first

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)

But with OSS I do not have lock-in!

Really?

Every decision for a tool, product, platform, library, framework, programming language, etc. means “lock-in”

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.

You (hopefully) deliberately choose lock-in to reduce efforts, costs and risks based on using the chosen solution

And it always means effort and risk if you need to migrate away from the chosen solution

This is also true if you choose an OSS solution

But we could maintain the OSS solution ourselves if needed!

Really?

Have you ever seen that happen?

Have you considered what that would mean in practice?

It will not happen

But OSS is for free!

Is it?

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

For production use, you will need the commercial version of the product because the OSS version typically lacks critical production features

To be clear: This is a perfectly legit practice. But it should not be confused with “free”

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

And even if the software is actually “for free”, using it still costs a lot of money

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

OSS never is “for free”

To be clear: There is nothing wrong with using OSS solutions. But please do the math and do not fall for strawman arguments.

Okay, I see

Back to cloud ...

Quick reminder ...

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

You need to leverage the public cloud to experience the cloud revolution

How can we become cloud natives?

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

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!

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!

Understand cloud security • Different from traditional on-premises security • Provides lots of fine-grained options • Steep learning curve • Essential for building dependable solutions

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

Is everything golden?

Of course not

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

Shouldn’t I rather wait and observe?

You could wait until the dust has settled, the teething troubles have been overcome and everything works nicely

But then others who started early will have an unassailable lead

Competitive advantage is shaped in the realm of early adopters, not in the realm of late followers

Hence, dive in now, learn the options of the public cloud ...

... learn how to leverage its potential ...

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

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

... and experience the cloud revolution!

Wrap-up

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

Yeah!

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