Author: Michael Neale, cofounder, CloudBees - www.michaelneale.net (Twitter)
Reading time: 1 coffee.
Back in 2013, many developers had their world changed when Solomon Hykes introduced Docker to the world. It wasn’t long before Dockerfiles made their way into source code repos alongside apps, describing how to build their apps and how to run them. Docker made container technology (which had been around for some time) suddenly accessible and understandable to millions overnight.
Meanwhile (and in fact even for years before), a bunch of work was being done in the area of cluster scheduling. These systems (such as Google’s Borg , Mesos, Cloud Foundry and more) had the concept of containers deep in them, but their focus was on the heavy lifting around rolling apps out, updates, services and more. The aim of all this was to make it faster to ship apps, create new apps and generally accelerate the pace of development. These systems didn’t get the attention that Docker received, leading many to scratch their heads as to why. Docker also put their hat in the ring with Swarm quite early on.
It is now 2018 and it is clear, given all the major cloud companies have announced complete and enthusiastic support for Kubernetes (K8S) (Cloud Foundry and Docker have also pledged support in various forms), that Kubernetes is about to become a whole lot more important as a platform for developers.
Those unlucky enough to remember the 90s (and early 2000s) may see some parallels here. In the 90s it seemed that every vendor had a middleware or server platform, and developers had whiplash from jumping from one thing to the next. In time, the industry rallied around things like JavaEE (Sun, Oracle, Red Hat, IBM) and even in the later decade, productive tools like Ruby On Rails brought along Rack, Python with WSGI. In all cases, when some suitable agreement or standard happened, adoption by developers and companies exploded in popularity. Developers learned to embrace these platforms as a standard and build their apps with this in mind.
So it is with Kubernetes. What was once a really hard to spell and pronounce name, is now a platform for developers to build for, deploy on and embrace. There should be less fear that time invested learning it will be wasted when you move to the next platform. Kubernetes is not just an ops or runtime only concern, but can be embraced as a development platform.
It is also a rich vein for nautical puns, (e.g. the excellent Helm package manager) and we know naming things is hard so expect more pun-tastic names around the theme (the name Kubernetes means helmsman - from Greek).
My own introduction to Kubernetes was in late 2015. I was leaving a Taylor Swift concert in Sydney and stuck in the carpark, so I jumped on a call with James Strachan (now working on next gen Kubernetes stuff at CloudBees) where he was raving about Kubernetes as a platform for developers, showing all the things he could do with it. James has a fairly good run rate for picking and starting successful open source software (see: Groovy - a top 20 programming language, and ActiveMQ which is now a first class service via Amazon for example) so I took what he said seriously. However I couldn’t quite work out why *I* should care. Containers were where I lived and I was mostly happy there.
Later on as the thriving community for Kubernetes grew under the CNCF , I started noting that people were using it not just for hello world demos. I started hearing talk about stateful services, disk, databases (things that are typically not given a huge amount of thought in clustered computing, or at least not as much excitement) - all things I am interested in.
What tipped the balance for me in realizing the importance of this as a *developer* platform was the power of things like Deployments . I was able to describe things like:
minReadySeconds: 5
strategy:
# indicate which strategy we want for rolling update
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 1In a declarative yaml file, and tell Kubernetes (via the lovely kubectl command line) to “do the thing”. Kubernetes configuration is declarative in the sense that you described the “desired state” of things, and it works out how to get there. I caved in and installed “minikube” and was able to see rolling updates with liveness and readiness checks keeping the cluster in a desired healthy state. This was once “heavy lifting” and sometimes even a differentiator for platforms, but was now just part of the fabric of Kubernetes, essentially for free.
So as a developer what do you need to know or learn? Perhaps not a lot to start with, ease into it. Good practices in building server apps like health/liveness/readiness checks (see this ) still apply (readiness means that the app has actually started ok, liveness means it is still healthy). Getting some appreciation for the Kubernetes concepts (Kubernetes has wonderful docs, great blogs and more) is well worthwhile.
For many Kubernetes doesn’t have to change how you build a server side app (much less than platforms in the past have asked of you), but as you get to know the concepts, you may see ways to make your work easier by building on them. Kubernetes is quite extensible (as you can see) and to me it is fascinating to see things like serverless/FaaS built on top of it - there is going to be a lot more innovation and tools around Kubernetes appearing this year (an acceleration as the big cloud vendors embrace it).
At CloudBees we have a keen interest in making Kubernetes a major platform for deployments, and as a platform to build upon. I am thrilled that we have just released CloudBees Jenkins Enterprise running natively on Kubernetes.