“Kubernetes vs AWS ECS” for Application Developers

Should I learn Kubernetes or Amazon ECS? As an Application Developer, how much of it should I learn or know?

I have encountered this question from various developers in application teams that I have collaborated with.

In this article, I’ll break down some of the factors that can help you decide if you should start learning ECS or Kubernetes. If you decide to start learning Kubernetes, take a look at the following course: Kubernetes on AWS: Hands-on Get Started.

Before jumping into your Kubernetes/ECS journey, you should be prepared for it. Meaning that you should,

• Have some experience building container images. Start with Docker.
• Know how to write Dockerfile and what goes in Dockerfile.
• Know how to publish docker images to registries such as DockerHub or AWS ECR.
• Have some experience running your application locally as a container using Docker or with Docker Compose. Many developers use Kubernetes for local development setup.
• Know how to use some of the Container/Docker features such as Volumes, Overriding the container command, Port mapping, etc.

It should be noted that going through some Docker tutorials or free youtube tutorials may not be sufficient. In my experience of working with many application teams, I learned that it takes time for developers to get comfortable with using Docker, even in the development environment. After you learn the basics of Docker, Dockerfile, and build images, make sure to use Docker on a regular basis.

If there isn’t a container environment to practice at your work, explore all your options to get your local development setup for containers. Even if your current company doesn’t use any container-orchestrated environments (Kubernetes or ECS, or Nomad), I encourage developers to set up Docker for their local development environment. Introduce it to the rest of your team members and learn together.

Now back to the original question — as an Application Developer, whether I should learn ECS or Kubernetes, and how much?

Obviously, the best would be to start learning what your company already uses, provided there is an opportunity and that your company uses either Kubernetes or AWS ECS. Try getting into one of those projects or teams that use either ECS or Kubernetes.

If there is no such opportunity at your job/work, you probably want to understand the team & org structure and the level of role & responsibility or limitation set to the application teams.

An ideal team structure & Boundaries

Whether the company use ECS (AWS in general) or Kubernetes (on AWS, on-premise, GCP or Azure etc.), there will likely be a team or multiple teams betwen the Application Engineering Team and the rest of the Cloud Infrastructure. Companies name such teams differently and here are a few commonly seen names — DevOps/Platform Engineering, Cloud Enablement, Builder Team, etc. For the sake of this article, let’s name that team as Platform Team.

The core responsibilities or purpose of that team is to provide a set of self-service tools, and in some cases provide service, for the application team so that the application team can manage the build, deploy and ops part of the services on their own with ease. The efficiency of those teams vary from company to company.

Such a team structure setup is bound to limit the scope, role and access for the application development teams , to the application platforms (ECS or Kubernetes). The Patform Team will solve for setting up the infrastructure, work with other infra/networking related team or engineers, create an abstraction layer by either building tools (CLI, API, Web based tools) and/or by configuring the tools that are useful to improve the efficiency and productivity of the application engineering teams. As an application developer (or team), you will likely be expected to know the details & specifics of what you need for your application to run and not worry about configuring ECS or Kubernetes.

With that in mind, let’s try to understand some of the expectations from application teams, in such a team structure.

Manage CI-CD Pipelines

Use the CI-CD tools to manage the build & deployment needs of your applications or micro-services. While for ECS, most end up using AWS services, for the most part, the CI-CD tools don’t vary much between Kubernetes & ECS. However, most that use Kubernetes tend to take the GitOps route.

As an Application Developer (or team), you take the maximum ownership of writing pipeline code & deployments and more often using the standard templates provided by the Platform Team. The templates will simplify the effort and do not require you to know a whole lot about all the configuration attributes. In Kubernetes, you’ll either use Kubernetes manifest files, use Helm chart, etc. And with ECS, the templated input will go through either some kind of YAML/JSON input or CloudFormation template, etc.

Know your application’s resource requirements

As an Application Developer (or team), you should understand the memory, CPU, or resource requirements of the application very well. When you create/edit CI-CD code, you are expected to keep the cost-optimized and know the resource requirement specifics. Regardless of ECS or Kubernetes, one should know the containers’ resource requirements.

Incident Response Readiness

From the point of view of incident response & mitigation etc, even though you don’t make any changes to the internals of the application platform, you’re expected to know its working knowledge of the application platform and some constructs. For example, you should know the lifecycle of how containers run and how services, networking, and load balancing work in the application platform. Most of the introduction courses, to an extent, cover those common topics. More you know the better at handling incidents and production outage situations.

Use the observability/monitoring tools. It is more important for the application teams to know to effectively use such tools. The observability tools can be common and may not vary much, between ECS and Kubernetes.

Summary

It may sound as if there is no difference and one can pick either AWS ECS or Kubernetes. In my opinion, both are great and one should learn both to know the real advantages of one over the other. But as an Application Developer, you would want to start with either and eventually learn the other.

The one big difference during the learning stage is the local development setup for learning. With Kubernetes, you can spin up a cluster on your local machine whereas for the ECS you’ll need AWS. If you use AWS, this may not be a challenge. In the local K8S setup, you will be able to explore most of what you’re expected to know about the application platform (K8S) as an application developer.

However, in some companies, depending on the scale and/or other factors, their org and team structure may be completely different. Besides, if you are expected to own most or all of the Platform Engineering responsibilities and do stuff like Infrastructure coding and administration etc, I would pick AWS ECS over Kubernetes. Or the other option is Kubernetes on AWS EKS. That is because you don’t want to own the responsibilities of dealing with a self-managed Kubernetes cluster on any cloud which is a lot of ongoing work. Moreover, creating, managing, and administering a self-managed K8S will require a dedicated team and skillset.

To conclude, I would say, learn both ECS and Kubernetes but start with Kubernetes and set up your local Kubernetes.

Take a look this course “Kubernetes on AWS: Hands-on Get Started For Developers and DevOps Engineers” when you’re ready to learn Kubernetes. It is a content packed course in which you’ll learn creating Kubernetes cluster on AWS EKS using Terraform (infrastructure coding tool), deploying multiple micro-services, creating RDS MySQL using Terraform, LoadBalancing & Routing of services, Config & Secret management, etc.