Adopting Kubernetes in an Enterprise is a daunting task. In this series of articles I am trying to give you an opinionated view on what you might need to consider when you are in the middle of rolling out Kubernetes within your organisation. Whether you are a developer or an IT operator, I am trying to address all your concerns, and if I am missing something, it would be great to learn from you in the comments. We are starting with an introduction into the history of Kubernetes (henceforth k8s), and why the adoption of k8s goes beyond simply running a single cluster on top of virtual machines. In later articles we will take an in-depth look into the different stakeholder areas, like the Developer Adoption Journey, the Platform Adoption Journey, the Migration and Modernization Journey, the Cultural Shift Journey, as well as Enterprise Automation Journeys. But let us start to explore a little bit about the history of Kubernetes.
When Kubernetes was announced in 2014 as an evolution of Google’s internal cluster management solution called BORG, nobody was able to foresee what would happen next. BORG was the cluster management solution of choice that orchestrated VM’s or other forms of containers. Kubernetes was betting on Docker Containers, as it provided a way to describe how a container should be run with a configuration file. One month after the announcement Microsoft, RedHat, IBM, Docker joined the Kubernetes community. At that time, it was a bet that Red Hat was taking, because Red Hat already had a Container Platform called OpenShift that was using its very own container management system. But it paid off big time, because Kubernetes has revolutionised the way we do IT today.
But not every IT Organisation was thinking about providing IT Services in a similar form that Google was trying to achieve with BORG or Kubernetes. Traditional IT Service Management followed a different approach. Being conformant with ITIL Requirements and making sure Services are stable. “Never touch a running System” has been a key concept in a lot of Enterprise IT Organisations. And as with every innovation, Kubernetes went through a technology Adoption Lifecycle. Some would argue that it is still in the middle of it. Now with more and more people wanting to adopt Kubernetes to become their default IT operating model, they realise that the traditional way to think about IT and how to provide IT Services is no longer applicable, when it comes to Kubernetes. You have to think about it in a very different way.
Kubernetes is to IT, what the car was to coachmen. If one just handed a car over to a coachman, and left him alone with it, he would have had a very hard time figuring it out. And if he couldn’t figure it out, he would most likely fall back to what he knew worked from the past.
And even today, you go to Driving School, to teach you how to drive a car. Nobody just gives you a manual and says, here is your car, you downloaded it from our website, the manual explains every technical detail about the car, and now go nuts, and figure it out yourself. And when you are lucky enough to get the car figured out, here is the Road Traffic Regulations so you can drive on the streets together with other cars. Because this would take a very long time, you have a teacher that helps you to learn how to use the car. He tells you which sequences you need to follow to move the car forward, he makes sure you are able to navigate in traffic, and that you know how to mitigate the risk of a breakdown of the car, because you run the engine too high or run out of fuel.
Kubernetes is just one piece of the puzzle, Public Clouds emerged with their own Kubernetes based solutions, AI/ML is the next innovation that needs to be adopted, and because the innovations happen faster and faster, people need a trusted advisor that can help them on their cloud native journey.
Kubernetes Adoption is a Journey on Multiple Levels
Adopting Kubernetes is hard. It is not a new Operating System, that you can simply operate with the traditional processes. It is a completely new way to think about IT Operations. This new way of thinking has brought forward many new ways to get things done. Kubernetes is an enabler for Enterprise Grade DevOps. Through its declarative configuration based on plain text files, it created a way for Ops teams to discover the benefits of adopting Developer Best practices like a Version Control System, Continuous Testing, etc. and so GitOps emerged.
So, if you have not already guessed, adopting Kubernetes is hard. You have to transform the way you provide IT Services on multiple levels. You have to stop thinking in atomic IT Services or departmental Silos, like Storage, Compute and Networking, that then runs on an Island in which developers and internal customers need to wire IT Services together (i.e. manual configuration of how an application connects to a database) and start developing a Platform Centric Mindset. This new way of platform thinking makes it possible to consume internal IT and Cloud Services transparently. As a developer I simply do not care where the storage, compute or the networking is coming from, it just has to work. As a developer I want a seamless self-service experience in which I can choose IT Services from a catalogue and integrate new Cloud Services with ease, so I can get my job done quickly. So in essence we need a Kubernetes platform that runs on any public or private cloud, and inside my internal IT whether it runs on x86 or Z or even ARM Architecture. This requires not only a rethinking of how to provide IT Services with as much automation as possible, because automation enables standardisation, and standardisation enables expected outcomes and service qualities that internal customers expect. But also a rethinking of how we deploy and operate applications at scale, and how we can migrate the existing application estate, so they can benefit from this new and accelerated way of working as well.
Conclusion
I hope this article gives a good overview about the history of k8s and why adopting it is rather complex and touches a lot more areas than simply installing a k8s cluster in the cloud or on-premise. Please feel free to leave comments, I am more than happy to answer them.
In my next article, I will explore more about Platform Requirements. What to consider north of the API – or rather applications running on top of it, and services interacting with an API of the platform – and south of the API – or rather considerations with regards to IT Service Automation.