skip to Main Content
Will EKS Simplify Your Migration To Kubernetes On AWS?

Will EKS Simplify Your Migration To Kubernetes On AWS?

Back in the day

More than a year ago, setting up a Kubernetes cluster on AWS wasn’t an easy task.

Here’s a quick recap of the things you needed to set up an HA Kubernetes cluster on AWS:

  1. Setting up AWS resources: VPC, autoscaling groups, ELB, DNS
  2. Automating etcd installation and backups
  3. Choosing and configuring the network driver
  4. Writing puppet code to deploy different Kubernetes components

This is only a partial list off the top of my head, but I hope you get the overall picture — setting up a Kubernetes cluster would allocate a big chunk out of your overall Kubernetes migration project.

Today, there are tools like kops that automate most of the tasks mentioned above and can help you spin HA Kubernetes clusters on AWS. Kops specifically is pretty mature and seems like it has been getting a lot of development attention recently.

Managed Kubernetes For AWS

If you want to avoid setting up your own Kubernetes cluster on AWS, there are a few commercial options available like Stackpoint.

Toward the end of last year, AWS announced that it accepts beta testers for its own managed Kubernetes service, called EKS.

I’m not a cloud analyst, so I won’t even try to dive into the strategic implications of this announcement. However, I’ll ask another question, which is much more relevant to the job we’ve been doing with clients: “Will EKS dramatically reduce the time needed to migrate a company to Kubernetes running on AWS?

Typical Steps Of A Kubernetes Project

During the past two years I’ve done multiple Kubernetes migration projects in which we took a working production environment and migrated it to run on a Kubernetes cluster.

To answer the question I’ve mentioned above, let’s take a look at the tasks we usually need to perform to migrate an existing environment to Kubernetes:

1. Set up one or multiple Kubernetes clusters

As I mentioned, with tools like kops it’s relatively an easy job now, especially if you already know Kubernetes internals to a good extent which will help you make the right decisions early on, like which networking driver to use.

2. Dockerization

If you aren’t using Docker already and deploying your applications in some other way, it may take a few days to create appropriate Docker images for all your services.

3. Adjustments to deployment and build automation

To be honest, I would say that this part takes roughly a half of the project’s time!

Why? Because usually you uncover a lot hacks or assumptions about the deployment environment that you need to overcome first.

There could be some hard-coded Jenkins jobs that do some parts of a deployment or are triggered to do specific post-deployment tasks.

Also, Jenkins can be one hell of a mess that you don’t even want to touch. So it might make more sense to start a separate Jenkins instance that will take care of the new Kubernetes environment.

If Jenkins isn’t involved, there can be a set of deployment scripts, let’s say in Python, that accumulated so much unused legacy code that even the people who use it daily don’t fully understand what it does!

Eventually we need to map the existing deployment process and translate it to the way things will be done in the Kubernetes world.

4. Creation of the Kubernetes manifests

Usually creating these manifests is done as part of the previous step, but I wanted to separate it to its own category.

Most of the time this process is pretty easy, but it can become increasingly complicated depending on the number of services you want to deploy and how well they map to the 12-factor app manifesto.

If you have a bunch of stateless services, a simple template with envsub could be enough.

However, if you have dozens of services with complex relationships that affect the deployment, we might need to use the heavy guns of Kubernetes deployment: Helm.

5. Monitoring & Logging

The complexity of this stage depends on the tools you currently use and the breadth of monitoring coverage you have.

If you use CloudWatch to monitor and graph a few built-in AWS metrics, you might need to implement and switch to a new set of monitoring tools that integrate with Kubernetes.

Other monitoring tools like Datadog might need fewer adjustments, but you still need to perform several steps to forward the new metrics.

6. Training & Handover

If after the migration to Kubernetes your development team can’t operate the day-to-day tasks themselves, you’re missing out on one of the core benefits of Kubernetes.

Unfortunately, despite Kubernetes’ growing popularity these days, it takes time to teach its main concepts. The documentation isn’t the best, and it takes time for the team to learn how to work with Kubernetes efficiently. I’ve written before about what’s difficult for beginners to learn in Kubernetes, so you may want to take a look to get a fuller picture.


Does EKS really simplify migration to Kubernetes if you’re running on AWS? From all the tasks I’ve mentioned above, setting up a Kubernetes cluster on AWS will take approximately 10% of the migration project.

That doesn’t include maintenance, which also depends on the cluster’s size and environment’s complexity.

But to answer the question I’ve asked at the beginning of this article — EKS will probably reduce some time related to cluster setup, and maybe even related to monitoring and logging in the future. Since much of the migration project’s complexity is related to existing infrastructure, I feel that migrating to Kubernetes on AWS will continue to be challenging all the way through 2018!

Leonid Mirsky

I help startups successfully implement Kubernetes and Docker!

I've been working with Kubernetes since version 1.1 and have 15+ years of experience within the IT industry. A more in-depth overview of my professional journey can be found at my LinkedIn page.

Back To Top