Is Cloud Native the new Linux?

The CloudNativeCon + KubeCon North Europe 2017 in Berlin was sold out with 1500 participants. I learned really a lot about Kubernetes and the other new and shiny tools that start to become main stream.

To get an introduction into Cloud Native, watch Alexis Richardson in the keynote on "What is Cloud Native and Why Should I care" (slides, video at 12:27). He explained the goal of the Cloud Native Computing Foundation (CNCF) as avoiding cloud lock-in, which is much more to the point than the official charter (which talks about "the adoption of a new computing paradigm"). Alexis chairs the Technical Oversight Committee (TOC) of the CNCF. The Foundation is "projects first", set up similar to the Linux Foundation and already sponsors various Open Source projects.

Linux Lock-In

His remarks got me to think about the question, especially in comparison with Linux. To me it seems that modern IT in the data center already has a pretty strong "lock-in" with Linux. It seems like most public servers on the Internet already run Linux. So what is bad with this lock-in with Linux? Apparently nothing much really. But do we really have a lock-in with Linux or actually with a specific Linux distribution? I know very few people who changed their distro, say from Red Hat to Debian. If Red Hat becomes to expensive then people switch to free CentOS instead, but don't want to (or afford to) change all their tooling and system setup.

So even though Linux is - at its core - always Linux, in practice there is a big difference between running an application on Debian, Red Hat, SUSE, Gentoo, Archlinux or others. There are even relevant differences between closely related distributions like Debian and Ubuntu or between Red Hat and CentOS.

So while we talk about the freedom of choice with Linux we very seldom make use of it. When dealing with commercial software on Linux we also don't require from our software vendors to support "our" Linux stack. Instead, we typically accept the Linux distro a software vendor prescribes and feel happy that Linux is supported whatsoever.

Cloud Platforms

So far the cloud landscape is indeed very different from the Linux landscape. With cloud vendors today , we have completely different and totally incompatible ecosystems. Code written for one cloud, e.g. Amazon AWS, actually does not work at all on another cloud, e.g. Google GCP. I mean here the code that deals with cloud features like deployment automation or that uses cloud services like object storage. Of course the code that runs your own application is always the same, except for the parts interfacing with the cloud platform.

All Linux distributions will give you the exactly same PostgreSQL database as relational database or the exactly same Redis as key-value store. Clouds on the other hand give you different and incompatible implementations of similar concepts, for example AWS DynamoDB and Google Cloud Datastore. That would be as if every Linux distribution would ship a different and incompatible database.

With public clouds we - maybe for the first time - come to a situation where it is possible to build complex and very advanced IT environments without building and operating all of the building blocks on our own. It is a fact that many companies move from self-hosted data centers into the public cloud in order to benefit from the ready services found there. Cloud providers easily out-innovate everybody else with regard to infrastructure automation and service reliability while offering pay-per-use models that avoid costly upfront investments or long commitments.

Cloud Lock-In

However, anyone using a public cloud nowadays will face a very tough choice: Use all the features and services that the cloud provider offers or restrict oneself to the common functions found in every public cloud. One comes with a fairly deep technological buy-in while the other comes with a promise of easily replacing the cloud vendor with another one.

I don't think that this hope holds true. In my opinion the effort spent on operational automation, monitoring and other peripheral topics leads to a similar deep buy-in with any given cloud vendor. Switching to another vendor will be a disruptive operation that companies will underwrite only in case of real need, just like switching Linux distributions.

The same holds true for an environment that utilises all possible services of a cloud vendor. Switching platforms will be costly, painful and only done based on real need. I think that the difference in "lock-in" between using all cloud services and using only basic infrastructure services is only a gradual one and not a difference in principle. Whenever we use any kind of public - or even private - cloud platform there is a smaller or most likely larger amount of lock-in involved.

Cloud Native

If Cloud Native hopes to break the cloud lock-in then the goal must be to develop advanced services that become a factual standard for cloud services. Once enough vendors pick up on those services public and private clouds will indeed be as portable and compatible as Linux distributions.

So far Cloud Native is focused mostly on basic infrastructure software and not on advanced services. My hope is that over time this will change and that there will be a standard environment with advanced services, similar to how the Linux and Open Source world gives us a very rich tool chest for almost every problem.

Furthermore, I am not worried about the technical lock-in with today's large cloud vendors like Amazon or Google. While their back-end software is proprietary, the interfaces are public or even Open Source and they don't prescribe us with which OS or client to use their services. This is much more than we ever had with traditional commercial vendors who forced us to use outdated software in order to be "supported".

Embracing Change

If we understand the development of our IT environments as an iterative process then it becomes clear that we can always build the next environment on the next cloud platform and migrate our existing environments if there is a real benefit or return of investment. And if there is none then we can simply keep running it as it is. With the current fashion to build micro services each environment is in any case much smaller than the systems we built 10 or 20 years ago. Therefore the cost of lock-in and of a migration is equally much smaller compared to a migration of an entire data center.

In today's fast paced and competitive world the savings and benefits of quickly developing new environments with advanced services outweighs the risk of lock-in, especially as we know that every migration will make our systems better.