Community post originally published on Medium by Noah Ispas
Kubernetes is taking over, isn’t it?
Almost everyone has heard of Kubernetes by now, and many organizations of all sizes are using it or at least considering using it in production. However, Kubernetes is more than just a technology for running containerized workloads. It can be a game changer for your DevOps culture. By design, it abstracts away the underlying infrastructure while allowing us to create or modify it if we wish.
Software engineers will no longer need to work with PaaS or IaaS.
Too provocative?
Maybe, but it’s not about putting Kubernetes on a throne and letting it be the hammer for all our nails. I am fully aware that Kubernetes, containers, and microservices may not be the solution for every problem and every organization. However, from what I’ve learned over the past few years of helping organizations become cloud-native, a lot of people struggle with implementing a DevOps culture.
I strongly believe that Kubernetes can help with this.
Kubernetes Is Here To Stay
No doubt, Kubernetes is not just a hype technology that will disappear again.
I remember when I started using it back when it was just donated to the CNCF in 2014. It was pretty much the only open-source technology for running containerized workloads back then. Today about half of the organizations that use containers are using Kubernetes to run them in production.
But there is more behind it than just operating containerized workloads.
Origins
I love to tell this story, and I first heard it from Nigel Poulton in one of his courses. However, this is the story of Kubernetes in a nutshell.
The rise of IT infrastructure virtualization (Infrastructure as a Service, or IaaS for short) was pioneered by Amazon almost 20 years ago, followed by Microsoft, IBM, Digital Ocean, and so on.
At the time, Amazon’s advantage was huge. Although Google now also offers on-demand infrastructure services, back then, Google was thinking about how it could use its expertise to outperform its competitors in this area.
Google also tried to think one step further and asked itself
How can we unify all cloud infrastructure, including bare metal, with a suitable abstraction?
This was a clever question, as it was already clear that each infrastructure provider would differ slightly in the details of their offerings (Functions being a good example).
The answer was Kubernetes.
Why? Because Kubernetes can run on every cloud provider and even on bare metal. Developers working with Kubernetes don’t need to worry or even know which infrastructure it is actually running.
The Rise
When I talk to people about Kubernetes, I like to tell them I think it is the number one platform for running software. Of course, you can tell I’m a fanboy — partly because I’m involved in this amazing community and love to contribute here and there — but let’s take a quick look at why Kubernetes really is a hammer on a lot of nails.
It all started with containers. Without containers, there would be no need for Kubernetes, right?
According to the CNCF’s 2022 survey, containers are now considered mainstream, with 44% of respondents saying they use containers for most or all production applications. Half of those using containers use Kubernetes to deploy at least some of them in production (64% end users and 49% non-end users).
You might say that these are just numbers and only represent a very specific area of software engineering happening in every region of the world. You might also say that Kubernetes is just not the right tool for a lot of people. You might be right in those statements.
But let’s consider this.
For many organizations, use cases, and contexts, Kubernetes is the right tool. And even if it’s not the right tool for the specific product you’re working on or the team/department you’re in, learning how to work with Kubernetes is something that’s very valuable.
And I’d like to underline this with an interesting fact from the aforementioned CNCF survey.
Kubernetes is increasingly being used not only to run application workloads but also for auxiliary workloads. This means security controls, service meshes, messaging systems, observability, and CICD tools. And surprisingly, the number of auxiliary workloads will outpace application workloads from 2021 to 2022. However, the number of auxiliary workloads increased by 211% year on year.
Kubernetes is more than a flagship tool that orchestrates containerized application workloads.
It is emerging as the operating system of the cloud
How to DevOps?
Perhaps you can already see where the journey is going. Since its inception, the DevOps movement has been trying to bridge the gap between developers and operators. And there are different ways of doing that.
I’ve seen developers become operators and vice versa, DevOps job titles and entire teams, and the newest kid on the block being platform engineers or teams. Whatever your solution, the underlying motivation is always to empower developers to build and run their own software.
You build it, you run it.
That is the DevOps mantra. And while I personally don’t like DevOps job titles or whole DevOps teams, I do like the idea of platform engineering. When I worked for this DevOps-focused company building data services for Cloud Foundry, my mental model of doing DevOps from a technical perspective was to have a platform. Like an internal PaaS (Heroku, Cloud Foundry, etc.).
This is nothing new. We’ve run multiple Cloud Foundry instances for many large, industry-leading customers, enabling their developers to build and run their software. The tricky part is balancing the limitations of platforms like Cloud Foundry with the flexibility a team of developers might need.
What if they need a new database, network or subnet, blob store, etc? They would still be dependent on the operations teams for those things. And what about support workloads? Things like security controls, CICD, or observability tools? These would probably also need to be deployed and maintained by operations.
A Scale of Options
Let’s summarise the situation so far. Containers are everywhere, and we have this powerful tool that can orchestrate them all at scale. And then, we have developers and operations, where we still want to reduce friction to deliver value quickly. But there are a lot of different ways to do that, each with its own pros and cons. There seems to be no one way.
That’s not necessarily a problem per se, but let’s take a minute to look at the implications of the different options.
- Operators could give developers access to the IaaS layer. This would give developers a lot of freedom and flexibility. But it would also mean they would need a lot of operational knowledge. And we should not forget the subtle differences between IaaS providers. Developers would need to know more than just one IaaS provider. But to be fair, in this scenario, the gap between developers and operations would be quite small, as developers could provide everything they need themselves. But do developers want to have this in-depth knowledge of operations, or are they capable of it? And are they allowed to? Think of all the governance and security constraints.
- Operators could introduce a common Platform as a Service for developers. Let’s say Cloud Foundry. It would abstract the underlying infrastructure for developers and give them some interfaces to run their applications (deploy, scale up and down, view logs, etc.). Developers would need almost no operational knowledge, but their flexibility would also be limited. But there would still be a small gap in case they needed a database, messaging service, CICD, or whatever.
Of course, these are not the only possibilities. I have indicated points on a scale of possibilities. There are completely different options on that scale and similar to the ones I have pointed out, but they differ only in detail. As always, the truth lies somewhere in the middle.
However, I would like to see a unified way, at least from a developer’s point of view. And I think Kubernetes could be that unification. It could be the platform that provides everything a developer needs in a unified way.
But wait a minute, Kubernetes is for running containerized workloads, right? So how do we deploy something at the infrastructure level with Kubernetes?
One Ring To Rule Them All
Over the past couple of years, we’ve seen new companies start up in the Kubernetes space that focuses on deploying and managing (multi/cloud) platforms for developers. Upbound is one such company that has created Crossplane, an open-source project that can be used to create what they call control planes.
A control plane is what you see when logging into your cloud provider account. It allows us to use Kubernetes as the platform we discussed earlier. A place where everything can be controlled, both applications and infrastructure, configurations, policies, and permissions. It allows self-service for developers, and the coolest thing is that with a single Crossplane installation, you can even provision infrastructure resources from different cloud providers, allowing for a true multi-cloud experience.
I’m a big fan of Crossplane because it runs on Kubernetes, so it leverages the capabilities of Kubernetes, such as self-healing and (auto)scaling. And guess what, the same goes for the infrastructure components deployed via Crossplane. Kubernetes will use its reconciliation mechanism to ensure everything is always in the desired state.
Isn’t that great?
Here is a small repository that contains a jumpstart on using Crossplane to provision Azure resources. I promise to do a follow-up article in the future that will take a deeper dive into Crossplane.
https://github.com/iamNoah1/crossplane-jump
Conclusion
About two years ago, I said that Kubernetes would take over, and I haven’t been proven wrong. The opposite is true. Everyone knows about Kubernetes, and many organisations are using it. However, Kubernetes is not the answer to every question or problem in software engineering.
But with Kubernetes and the help of tools like Crossplane, we can bridge the gap between developers and operations. The motivation for all things cloud-native has always been to improve time to market. But I have to say, introducing more silos through DevOps or platform people or teams doesn’t seem to be the way to go.
Abstracting the infrastructure through a powerful platform so developers can do everything to build and run their software feels more natural to me.
I hope you enjoyed the article, and I am super happy to get any feedback or hear your opinions on the topic.