TAGS:

Barriers To Kubernetes

Michael Levan

If you’re a system administrator or Infrastructure Engineer that has:

  • Managed upgrades for large-scale systems
  • Managed high availability and horizontal scaling
  • Deployed binaries on Linux or Windows VMs
  • Deployed virtualization and bare-metal environments

Kubernetes is going to be a major upgrade for you, how you deploy, and how you manage services. Kubernetes truly does make engineers’ lives easier. That said, Kubernetes and containerization as a whole can be incredibly complex for engineers to learn and organizations to adopt.

It Can Be Complex

If you’re new to engineering or just graduated and want to jump into a tech role, Kubernetes will be the platform that haunts your dreams. You’re constantly reading the latest blogs, you’re ready to get a new job, but Kubernetes is in your way. You see it everywhere, you try to get it deployed, and you have zero idea how it works.

Where Kubernetes shines is what it abstracts away from us. The two biggest abstractions are scaling and deployments. If you’ve ever been in a situation where you had to scale multiple VM’s across clusters, or even across data centers, it’s not a walk in the park. Kubernetes does all that for you automatically.

The same thing goes for deployments. If you’re used to taking 3-4 binaries, pushing them out on multiple VMs, running the binaries, and ensuring that the application comes up, it’s not difficult, just cumbersome. Kubernetes removes that need for you so you can deploy containerized applications with a single command (and have multiple instances of that app running).

Is Kubernetes complex? Yes. Is it hard? Absolutely. Does it make your life easier if you already have a background in IT? 100%.

It’s A Commitment

Kubernetes is a complete re-think for deployments. You’ll often see information declaring that Kubernetes isn’t doing anything new at the “hardware” level, and that’s true. Networks are still networks. Infrastructure is still infrastructure. Storage is still storage. However, Kubernetes did change the way we think about deployments and is making container orchestration mainstream.

When change occurs, commitment is born. It’s the same thing as any platform we use. When ESXi became popular, engineers had to focus on ESXi. When the cloud came out, engineers had to focus on the cloud. Engineers often say that they don’t like the commitment needed for Kubernetes, but the commitment piece has been a requirement since the beginning of computing.

Given the commitment required to understand and implement containers and container orchestration, you have to decide if this is where you want to invest your time and effort. Is your organization heading down this path? Are there other avenues that interest you more? How might such an investment in time and learning affect your career in the long run?  Kubernetes is a big job, much like implementing ESXi.

Time, dedication, and engineers need to be dedicated to the cause.

Teams Might Not Be Ready

Take a look at the team you’re on. What are their backgrounds? What technologies have they worked with? Do they write code (config or app code)? Do they understand the cloud? Have they been working in a datac enter for the past twenty years and haven’t really touched the latest and greatest? Are they more sysadmins than developers?

A lot of organizations will take one or two people on of a team and say “You’re doing Kubernetes now” as if it’s that easy. Because of that, and the overall lack of understanding from management in those situations, you as the engineer must make the decision to confirm if the team is ready to implement something like Kubernetes.

Oftentimes, engineers get wrapped up in the latest and greatest, and that’s perfectly fine. If you love what you do and find the technology interesting, that’s great. However, you must take a step back and ask yourself important questions like “Is my team and this business ready for Kubernetes?”. If you can’t support it or don’t have enough people to support it, you have to think of alternate options.

Kubernetes Alternatives And On-Ramps

Throughout this blog post, you’ve learned when you should and when you shouldn’t implement Kubernetes. To reiterate, Kubernetes makes engineer’s lives easier depending on their background, environment complexity, and what platform they truly need to implement to satisfy business needs.

If you’re not ready for Kubernetes, there are other options available that are great, work well, and can get the job done. Please note that the list below is not an exhaustive list of every single alternative to Kubernetes. The list below is to give you an idea of where to begin when thinking of alternatives.

Nomad

HashiCorp Nomad is perhaps the biggest Kubernetes competitor at the moment. Nomad is an orchestration platform that schedules workloads, much like Kubernetes. The biggest difference, and quite frankly, where Nomad outshines Kubernetes, is its ability to orchestrate containerized and noncontainerized workloads.

Nomad is a great and viable solution, but it has a long way to go. Not because it’s not good or not because it doesn’t work in production, but because the third-party tools/platforms that have been developed around Kubernetes aren’t there for Nomad. However, if you’re deep into the HashiCorp ecosystem, Nomad may be the perfect fit.

ECS

AWS Elastic Container Service (ECS) is pretty much “Kubernetes Lite”. It does everything that Kubernetes does to schedule, self-heal, and orchestrate containerized applications. The biggest difference is that it’s way easier to set up and configure than Kubernetes.

However, ECS runs on AWS only. If you don’t use AWS, you can’t use ECS. If you don’t use AWS but are thinking about switching to AWS specifically so you can use ECS, you should see what other options you have at your disposal.

GCP Cloud Run

Cloud Run is pretty similar to ECS in the sense that it schedules, orchestrates, and heals containerized workloads without needing Kubernetes. Cloud Run is slightly easier than ECS as it’s a bit more straightforward to configure and set up. GCP also has a way to migrate virtualized applications to container applications, which makes it a huge plus.

The same rules apply as with ECS. Cloud Run is only available on GCP, so if you’re on GCP, great. If you’re not on GCP, see what other options are available.

About Michael Levan: Michael Levan is a seasoned engineer and consultant in the Kubernetes space who spends his time working with startups and enterprises around the globe on Kubernetes and cloud-native projects. He also performs technical research, creates real-world, project-focused content, and coaches engineers on how to cognitively embark on their engineering journey. He is a DevOps pro, HashiCorp Ambassador, AWS Community Builder, and loves helping the tech community by public speaking internationally, blogging, and authoring tech books.