Amazon ECS and EKS Best Practices

As enterprises move to digital transformation, they’re adopting container platforms to deploy their applications. Nucleus Research reports a 150 percent year-over-year growth of Amazon Container Services, highlighting the mass adoption of containerization.

Containers provide a way to package applications to run in multiple environments. They enable you to streamline application development for only functional applications. Containers take care of any adaptations needed from the environment. 

Using containers also allows you to develop applications that can run on a variety of platforms, whether cloud or virtual, iOS or Android, and so on. Without changing the code, containers provide applications with the ability to run on an ever-changing platform ecosystem. 

While containerization provides opportunities to streamline deployment, it must work with the runtime landscape like any other part of the architecture. Before beginning the containerization process, there are several questions to ask:

• Where should I start? 
• What should I containerize? 
• What platform should I use to orchestrate my containers? 
  

In this article, we’ll explore some best practices for starting with Amazon Elastic Container Services (ECS) and Amazon Elastic Kubernetes Services (EKS). We’ll also go over some guidelines to help you determine which Amazon service will suit your needs best, and highlight strategies for optimizing your container investments.

Getting Started

To start, let’s consider why we need a container in the first place. 

Containers are lightweight packages that contain both application code and what it depends on to run in each environment. These dependencies may include programming language runtime models, libraries, and operating systems. The container allows you to separate the application logic from the environment in which applications run. 

When to Containerize

There are a few characteristics that make an application a good candidate for containerization. For example, say you have an application that you update and deploy frequently. In this case, using a container would allow you to make changes and add features to the application’s code, rather than having to adapt to the environment. 

If you anticipate increased demand for an application over time, deploying more containers creates more application availability. Similarly, you can decrease application instances at non-peak hours, freeing up resources for other uses. 

It’s important to note that the application must be a single jar or binary file for containerization. In other words, the application must have modules that run independently of other modules. While containers can pass data to other containers, the applications they contain must operate independently. The modular nature of containers allows for application parts to use repeatable processes, be modularized in containers, and be reused. 

Additionally, the application needs to be stateless, meaning that the application within the container isn’t storing persistent data. The data must persist outside the container to be available even when removing a given container. 

When Not to Containerize

Some applications aren’t the best targets for containerization, and some application characteristics make them a lower priority. These include applications that will be running on a single server and depend on the server’s file system or Windows registry. 

Additionally, applications that run on specific hardware or esoteric systems are not good candidates for containerization. You should assign a lower priority for containerization to applications that you don’t frequently update, or those that don’t need the scaling features that containers provide.

Building the Deployment Pipeline

Deploying applications using containers means that you can focus on the application. The container removes the need to tailor each application to various runtime environments. This ease of deployment, while adding speed, also highlights the importance of other stages in the continuous integration continuous development (CI/CD) pipeline. 

One of these stages is testing code and keeping the committed version in a central repository. Automatically building and testing each application, and centrally storing the deployment version reduces the likelihood that you’ll containerize and deploy several instances of flawed applications. 

Since different teams may be using the CI/CD pipeline, it should support multiple simultaneous workflows. This feature allows teams to collaborate on a single application. Several tools are available to help you build out the CI/CD pipeline, like Jenkins, Circle, or Travis. A CI/CD tool should include version control, build tools, testing, and containerization ability. 

In addition to these capabilities, the pipeline should include creating containerized images and the ability to interact with the Elastic Container Registry (ECR). ECR is a container image registry service that allows customers to use a variety of containers and manage images. ECR provides a secure and reliable registry for your application’s images.

Because of the broad deployment of containers, security becomes paramount. A single vulnerability can create flaws in many deployments. The CI/CD pipeline should also include a container security scanner like Clair or Falco to avoid accidentally baking vulnerabilities into your container images.

ECS or EKS: Which One?

Two popular container services are Amazon Elastic Container Service (ECS) and Amazon Elastic Kubernetes Service (EKS). Let’s break down the differences between these two AWS services to help you determine which solution will align best with the applications you’re using. 

The primary difference between these two containers comes down to simplicity versus flexibility. ECS is the simpler of the two. ECS integrates with other AWS services like Elastic Load Balancing, Amazon Virtual Private Cloud (VPC), and AWS Identity and Access Management (IAM). The simplicity of ECS comes from the fact that the ECS solution already makes critical decisions in computing, networking, and security. ECS allows auto-scaling up or down, simplifying resource management. 

EKS provides greater flexibility. Though EKS doesn’t integrate with the AWS environment as quickly, it provides more options through access to comprehensive Kubernetes tooling from the open-source community. However, because of the number of choices available, EKS is more difficult to set up and manage than ECS. Additionally, though the AWS console can deploy EKS, its deployment is more complex and requires building pods. You’ll need to have some Kubernetes expertise to deploy and manage EKS. 

You’ll also want to consider expenses when deciding between ECS and EKS. While you essentially pay for the services consumed with ECS, EKS will cost about $74 each month for each cluster, in addition to services costs. 

If community support is significant to you too, you might want to consider the support available with each service. With EKS, you can leverage the help of the entire Kubernetes community. In contrast, ECS offers only the help of Amazon. 

Whether ECS, EKS, or a hybrid path, the service that’s best suited for your needs depends on the careful examination of your application and environment requirements. Keep in mind that while containerization simplifies deployment to various environments, it does not relieve you of designing a deployment strategy that suits unique needs.

Building Observability into a Containerized Solution

Observability refers to the ability to collect information from logs, traces, metrics, and service management in real-time and correlate it with the performance of applications, hardware, and teams. 

Observability is critical in dynamic environments to determine if deployments are working as planned. By selecting the process for collecting and analyzing your container environment early in the containerization lifecycle, you can establish consistent measurement methods. 

Ignoring observability will lead to a disjointed set of data sources, techniques, and analytics that require integration in the future. With EKS, it’s essential to include observability of your Kubernetes clusters into the plan as well. 

Creating an observability system is no small task. AWS native observability tools like Amazon CloudWatch and AWS X-Ray are two options to help with this process. There are also several third-party application performance monitoring (APM) tools that you might consider, as well as open-source ones like Open Telemetry and Prometheus. 

For a deeper discussion of how to learn more about observability and monitoring, check out this blog. 

Next Steps

Containers are an efficient way of deploying applications in multiple environments without retooling the code to adapt to environmental differences. Containers allow DevOps teams to focus on the functional application and not the runtime environment. The process of containerizing applications simplifies running disparate environments.

Containerizing an application architecture isn’t a plug-and-play task. Establishing a containerization program requires many decisions, such as what applications should or shouldn’t be in containers, what containers to use, and how you should network and secure them. 

Once you’ve created your containerization program, you need to be prepared to monitor the performance of the individual containers and the overall architecture. Additionally, you need to monitor the performance of the individual containers and the overall architecture. 

In the face of these complexities, it helps to have someone experienced in the choices your organization will face. By partnering with Mission, you’re taking a step towards getting the most out of your AWS and container investments. Learn more about our Containers Consulting Services today.