Searching the Internet on how to build modern applications makes one thing obvious, Kubernetes is the hot 💩these days. Few technologies disrupted the space as much as Kubernetes. Docker maybe, commoditizing the usage of containers altogether.
If you don’t exactly know what Kubernetes is, the “Kubernetes in 10 minutes blog post gives a quick but extensive overview of the history, reasoning and functionality of Kubernetes.
Kubernetes comes in a lot of different flavors to us as developers or devops. Apart from the pure, rich taste of the original Kubernetes, there are many hosted services built on Kubernetes’ technologies to offer a more complete experience to customers and users. To name just a few of the big ones; GKE (Google Kubernetes Engine), Red Hat’s OpenShift platform, Amazon EKS (Elastic Container Service for Kubernetes), Microsoft’s AKS (Azure Kubernetes Service), and many many more.
Coming from this position it seems interesting, to say the least, to see that a lot developers still don’t seem to care too much, even if they’re building applications to run on any of those platforms.
Developers, developers, developers, …
I ran a very informal poll on Twitter asking developers about their thoughts on Kubernetes and if it is a sole Devops or infrastructure topic; about one-fourth answered with yes. That’s still a good three quarters of the respondents to admit that developers should know about Kubernetes (at least the bare minimum), however I personally feel that 25% is still too high.
I normally don’t like to seriously trash-talk people, however, I think we all know there’s always one colleague we’re working with, that refuses to learn anything new, rejects new ideas or technologies and just waits for retiring.
Frustration and sometimes some kind of resignation towards this person is the most common reaction. I doubt, however, that 75% of the participants are people like that.
So why would a developer think that there is no necessity to know about Kubernetes? Well my personal feeling is the given perception by people talking about container environments. It is often claimed that container platforms are almost invisible to the user; they’re black boxes with some magic ingredient; the silver bullet.
From my experience though, switching environments is never simple or even a care-free matter. Neither for the team to manage the infrastructure, nor for the developers that write the business application. I understand, we’d all love to think it to be true, but it almost never works.
The Silver Bullet Syndrome
As technical people, or maybe I should say as Homo Sapiens we love to think of things as the silver bullet – the one solution that brings a simple and easy salvation to (all of) our problems. It seems to be deeply rooted in our souls. But we’re not diving into a psychology session now.
A good friend of mine, Hadi Hariri, working at JetBrains, has an amazing talk about the Silver Bullet Syndrome and some history of changes throughout his career in the IT industry. I can highly recommend to watch it, it’s a lot of fun and you can find it here. BUT STOP! You can go and watch it only after you’ve finished reading 😉
Anyway, looking at Kubernetes, it seems to be the next silver bullet. Don’t get me wrong, I’m not saying Kubernetes is bad and that it shouldn’t be used. My point is, we need to understand, there are no magic black boxes, and anyone who has ever tried to set up a custom Kubernetes cluster, preferably on dedicated hardware outside of cloud providers, knows what I mean.
Obviously not every developer should go ahead and set up a Kubernetes cluster, not every developer has to feel the pain of what Devops feels every single day. As developers we have our own pains, like new frameworks, debugging really weird issues, new patterns or concepts of how to build applications. Especially the latter one is a constant struggle, as applications tend to get more scalable, distributed and polyglot.
Application Style Is Changing
But if Kubernetes is not a magic black box, what are the bits and pieces that developers should know about?
To answer that, I think we need to paddle back a bit and look at what kind of applications are developed for and deployed into Kubernetes.
As mentioned earlier, applications these days are mostly built with scalability in mind. Applications need to be used by more people to reach the critical mass of being meaningful to keep running. More people often means beefier servers (but that tends to get extremely expensive), or more servers. Servers in this case can be equated to service instances. It could be multiple instances on a single dedicated machine, on multiple VMs, using lots of containers – no matter how we scale, we have to make it efficient.
What Developers Need to Know About Kubernetes
Writing applications for scalability and availability should be as simple as deploying your service into Kubernetes. It is, however, not the magic black box we’d love to get.
In the next blog post I will show the 3 major reasons to why some basic, Kubernetes knowledge is important for developers that want or have to deploy their applications into a Kubernetes cluster.