While many new services shared the spotlight, Amazon Elastic Container Service for Kubernetes stole the show at...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
last year's AWS re:Invent conference.
Even though containers have been around since the early days of Linux, Docker introduced the modern iteration of the technology. Today, a huge part of DevOps culture revolves around containers, and there are many different container orchestrator options to automate deployment.
But Kubernetes stands out in the container orchestrator crowd, and that is why Elastic Container Service for Kubernetes (EKS) resonated with so many cloud professionals -- even if Google Cloud Platform and Azure beat it to the punch.
Amazon EKS looks promising; it provides all the benefits of Kubernetes orchestration and reduces unnecessary management overhead. There are numerous AWS customers eagerly awaiting a move to EKS, but first, they should weigh all their options.
Kubernetes container orchestrators
Kubernetes is an open source platform that enables you to manage, scale and automate the deployment of containerized applications. It also provides portability, extensibility and self-healing, enabling you to scale containers seamlessly on the fly.
With Kubernetes, your containerized apps deploy in pods -- atomic units for deployment -- that provide shared resources for one or more closely related containers that run within the platform. For a group of pods that performs the same function, a service acts as both as an access point for your apps and a load balancer. Kubernetes also supports external resources, such as the F5 load balancer. The Kubernetes ecosystem deploys as a cluster with master and worker nodes, but the time it takes to deploy and manage is one of Kubernetes' greatest downsides.
EKS simplifies cluster management
Many AWS customers would gladly use Kubernetes, but that time-consuming cluster management process can be a turnoff. Amazon EKS simplifies this process and, as a result, appeals to developers who already use containers.
EKS runs three master nodes in three different availability zones, and it automatically replaces unhealthy nodes. The service automatically performs updates and patches -- like other AWS-managed services -- and you can manage the worker nodes on which your pods run. EKS will also support AWS Fargate in the future to automate some of these tasks.
EKS could reduce management overhead, costs
Unlike ECS, Amazon EKS is based on open source Kubernetes, and it doesn't rely on external services to boost its management features. For example, it can handle both internal load balancing using kube-proxy, as well as external using the Ingress controller. EKS also supports a range of non-native services and commands, such as Consul for service discovery, Supervisord for process monitoring and system control, and etcd as a key-value store.
For these reasons, Amazon EKS could make deployments and automation easier, and it could reduce maintenance headaches compared to ECS. If this is true, developers could use EKS without creating a huge operational overhead for operations. While AWS has not released EKS pricing details, these features could mean reduced spending compared to ECS as a container management service.
Migrate to EKS
The Amazon EKS release affects both users who rely on self-hosted Kubernetes and those who use Amazon Elastic Container Service (ECS). You can easily migrate existing Kubernetes workloads to EKS without any major modification. Amazon EKS uses open source Kubernetes, and all applications that run on Kubernetes are fully compatible with EKS. This also reduces vendor lock-in risks, since migration out of EKS is a simple process -- unless you rely heavily on other Amazon services.
During the launch presentation at re:Invent, the only necessary step to migrate an existing workload from self-hosted Kubernetes to EKS was to create a new cluster. This required only a few clicks in the AWS Management Console and about six minutes wait time for it to deploy. You must also retarget the kubectl command-line interface to use EKS instead of the self-hosted cluster.
How to ditch ECS for EKS
If you want to move from ECS to EKS, the process is slightly different. ECS is limited compared to EKS, but it offers seamless integration with other AWS-managed services, such as Virtual Private Cloud and Identity and Access Management, which makes it easy to quickly deploy your applications. With the addition of AWS Blox -- an open source scheduler that consumes event streams and tracks the state of an ECS cluster -- ECS is a viable container orchestrator. That's why ECS users face a difficult choice if they consider a move to EKS.
That said, EKS offers a mature syntax that enables you to define a complex infrastructure, which might be hard for ECS to replicate. EKS also offers much more flexible storage and load balancing than ECS, as well as logging, monitoring and health-checking features. All of this suggests that, over time, more customers might migrate to EKS.
Hybrid cloud deployments, where users want to run container clusters both on premises and on AWS, also factor into the decision. With ECS, there is no compatibility with Kubernetes, but with EKS, you can easily shift workloads between those two environments.
If you decide to migrate to EKS from ECS, it's not necessarily a simple process. ECS relies on JSON-based task definitions that specify container configurations, such as load balancers, Elastic Block Store volumes and CloudWatch metrics. While EKS integrates with other Amazon services, you must create configurations for your pods and services, because they're not compatible with ECS tasks. EKS gives users the option to use various Kubernetes features instead of Amazon services. While this makes the process more complex, it could reduce the overall cost of your container deployments.