WTF is Cloud Native? Even the experts don't completely agree. In our continuing series 3 Questions, Cloud Native influencers tackle a trio of queries about this mysterious movement. This month's answers were supplied by Holly Cummins and David McKay.
To me, Cloud Native is about being written for the cloud, and taking full advantage of the cloud. A lot of that has to do with scalability and elasticity and state management; if you're Cloud Native, you can be scaled up and down at will and you can pop up in a new cloud without ill effects.
You should also be taking advantage of the release cadence that cloud enables; if you don't have to press software to a CD, why would you want to limit your releases to once every six months? There are a lot of definitions of Cloud Native floating around, and I get really excited about some of them because I just don't agree.
Sometimes Cloud Native is treated as a synonym for microservices, but as a concept, Cloud Native emerged in 2010. Microservices (the kind that are distributed on a network) wouldn't become a thing until a year later, in 2011. And Docker? It's hard to remember life before Docker, but it didn't come along until 2013.
The reason I worry about treating Cloud Native as just the same as microservices, or, worse yet, just the same as Kubernetes or smart service meshes or another technology, isn't because those technologies are bad—they're brilliant, and they've transformed our industry. But we can put too much reliance on our tools, and forget to update all the other stuff. You can't buy Cloud Native, or install it from GitHub.
Taking advantage of the cloud means some fundamental changes in developer habits, and it also needs fundamental changes in management habits. Complex release procedures and release boards with lots of paperwork just don't make sense in a cloud context, and they're a horrible fit with a microservices architecture.
Before they can get the most out of the cloud, organisations need to change their approach to quality and they need to develop deep automation skills. Waterfall-style, manual QA no longer makes sense in a fast environment like cloud. Once those fundamentals are in place, then the higher level cloud value can be unlocked.
The Cloud Native Computing Foundation [CNCF] Cloud Native Landscape is both a problem and an unsolved mystery.
To be fair, the picture itself is not the problem, just a representation of it; the CNCF have created a valuable articulation of what is legitimately an extremely complex landscape. That complexity is great, in some ways. The fact that there are so many different distinct logos on the landscape shows what a vibrant ecosystem is emerging around Cloud Native, how much energy there is in the community, and how much inventiveness. It's like a Cambrian explosion of cloud tech.
Where the problem is is on the consumer side. How does someone identify which pieces they need for their use case and select between overlapping offerings? How do they install and manage it all?
The wonderful thing about the cloud was the way it freed us from infrastructure concerns, but what we see in the CNCF landscape is a lot of infrastructure concerns. If we're not careful, we risk being dragged down into focusing on the infrastructure, rather than the value that we can add on top.
Managed services are so good! If you want to go fast, they can be such an accelerator. I'm lazy, so I love them. Managed Kubernetes is a great start, but then for most use cases I'm also a fan of managed caches, managed databases, managed AI ... They're quick to get going with, and they take care of a whole bunch of hassle around storage, security, backups, and administration.
Cloud Native is a set of disciplines/design decisions that provide a horizontally scalable system that is resilient and redundant to service availability and ephemeral compute. A few examples are: delivery through immutable artefacts, environmental awareness and configuration, and instrumentation.
State. I see developers taking on all these new architectures and technologies like microservices, service mesh, containers, Kubernetes, and even new database tech like CockroachDB, dgraph, and Fauna, which is great. But what they're not doing is changing the way they architect and build our applications at the data layer itself.
CQRS and Event Sourcing are not new ideas, but the adoption (IME) is extremely low. Understandably, it's not easy to do and there are many problems in this space (mostly tooling) that need solved. But I think for us to reach the next level of Cloud Native, this is the major chasm we need to cross.
Simplicity.
Cloud Native allows humans to work on simple services. Complexity is pushed to the infrastructure layer, where tooling (Kubernetes, Linkerd, Dapr) can be applied. Humans shouldn't need to build retry logic, exponential backoff, mTLS, and distributed transactions. Of course, humans still need to build that tooling; but for most teams they shouldn't need that expertise or to spend time thinking about it.
Cloud Native enables teams to focus on their own domain, the business logic and USP of their organisation that drives value and profit.