12 Mar 2018, 18:17

Don't panic!

Kubernetes is hard

If you’ve been hearing a lot about Kubernetes, and maybe read some things about it, or even tried to get started running something in Kubernetes, you may be feeling a little dispirited, confused, overwhelmed, puzzled, and possibly suffering the early symptoms of imposter syndrome. Well, don’t worry: it’s not just you.

Here’s the shocking truth that conference talks, promotional material, corporate press releases, and those other blogs won’t tell you:

Kubernetes is hard.

Of course, everyone who’s enthusiastic about Kubernetes wants to tell you how easy it is. “You can learn Kubernetes in a day!” Well, that would be quite a day. While Kubernetes is powerful and useful, it’s not necessarily so easy to get your head around, especially at first. It involves a lot of puzzling jargon and technical terms which don’t mean much to the newbie:

  • Pod
  • StatefulSet
  • PersistentVolumeClaim
  • Custom Resource Definition
  • Ingress
  • Deployment
  • Horizontal Pod Autoscaler

… and so on. If you feel depressed and angry at the amount of new things Kubernetes requires you to learn, then we can absolutely relate to that. We’ve been through some of the same emotions on our Kubernetes journey, which is by no means complete, but the point of this blog is to hammer a few signposts into the swamp to help others feeling similarly lost.

It’s not just about Kubernetes

Like any promising new technology, Kubernetes attracts people with a certain evangelical fervor, who want to tell you that it will do everything and solve all problems. But we know that’s silly. It would be equally wrong, however, to conclude that Kubernetes is all hype, and it will soon fade away like a hundred other bits of tech which were the Next Big Thing once.

Kubernetes is actually a really useful tool, but no single tool can do everything on its own. There are a lot of new, or relatively new, concepts swirling around which are all vaguely connected, including:

  • Containers
  • Devops
  • Cloud
  • Infrastructure as code
  • Automation
  • Continuous deployment
  • Microservices

Going cloud native

We think a good term which describes and groups all these related concepts together is cloud native. That is, cloud native applications tend to run in the cloud (obviously), using containers (possibly), structured as co-operating microservices (increasingly), using resources described in code and managed by automation (ideally), and continuously deployed (for some value of ‘continuously’).

Of course, ‘cloud native’ means different things to different people, on a spectrum from completely ‘serverless’ infrastructures (which we would rather describe as ‘functions-as-a-service’, or FaaS) to completely self-hosted environments using no third-party services at all, except perhaps the public cloud. However, we think when we talk about cloud native devops you will know what we mean.

If you’ve been in the tech industry for a while and are used to, let’s call it traditional IT operations, cloud native means not just a new stack, but a fundamental shift in the way we think about building and running applications on the Internet. On the other hand, if you’re new to the whole thing, you don’t have anything to unlearn, but you may not be sure just where to start. Well, we can help. It’s not as intimidating as it seems, especially when you realize that there’s a lot you simply don’t need to know.

Come for the ride

Over the next few months we’ll be posting tips, thoughts, ideas, techniques, questions, and code examples, which you may find useful when learning about devops in the cloud native world. We hope you’ll join in the discussion, and be part of this journey. Start by following cloudnatived on Twitter!