Amazon Elastic Kubernetes Service (Amazon EKS)

What I most appreciate about Amazon EKS is its unparalleled flexibility and efficiency in container and pod management. As an end user and a key participant in the decision-making and implementation processes, I have personally experienced the benefits of EKS, particularly when compared to our previous use of other products for pod management. One of the primary advantages I find with EKS is the flexible options it provides for nodes. We can choose between self-managed nodes, or managed nodes, and multiple other configurations, which offers the adaptability necessary for diverse operational requirements. This flexibility is a significant improvement over the more static pod management we encountered with other solutions, which struggled to cope with sudden, substantial increases in load, leading to user queuing experiences. The fact that EKS is a managed version of Kubernetes is a crucial factor that aligns perfectly with our organizational strategy. Having prior experience with non-managed Kubernetes implementations, the Amazon-managed service significantly reduces the operational heavy lifting outside of the developers' context. This allows our development teams to concentrate on business logic rather than infrastructure complexities. A highly valued aspect of EKS is its seamless integration with other AWS services. Given our extensive reliance on the AWS ecosystem, it was paramount for us to have easy access to networking components such as Virtual Private Clouds (VPCs), load balancers, and security groups. This integration is essential for our environment, where thousands of servers are running and interacting with new pods managed by EKS. The plug and play nature of EKS, particularly its integration with the Kubernetes Role-Based Access Control (RBAC) system, allows us to manage identities and access permissions directly via Amazon, eliminating the need to depend on external vendors for IAM roles and permissions. This design was a main reason why we selected and started using EKS. Furthermore, EKS demonstrates significant cost optimization and technology innovation. Through our internal Proof of Concept (POC), where we ran the same service on EKS and our previous Amazon product in parallel across different regions, we were able to showcase compelling results. We meticulously monitored parameters such as monitoring cost, efficiency, response time of services, and the overall cost of AWS services. These comparisons clearly demonstrated the superior performance and cost-effectiveness of EKS, facilitating its adoption across multiple teams within the organization. For example, we aim to reduce infrastructure cost for the same load from, say, $1000 on ECS to $700 on EKS. The scalability and capacity to handle burst loads are also features I greatly appreciate. EKS ensures that our infrastructure remains capable of handling all requests even when the load increases substantially. Once the architectural decisions for deployment are made and our base templates (AMIs) are sorted, the system scales with minimal manual intervention. For instance, if a service requires handling more load, we simply update the configuration (YAML file) to increase the maximum number of pods from, say, 1 to 1000 replicas, and EKS automatically spins up the necessary instances without manual deployments. This ensures high availability and responsiveness during peak demands.

I like how easy it is to setup. It is very user friendly and configurable to the way I want it.

The main feature we found a key advantage is the easy scalability of the system. We introduced the autoscaling feature to face peak request of some worker nodes, thus optimising the provisioning of resources, avoiding over-provisioning just needed in peak periods. The second feature we appreciated is the integration with other AWS services. We particularly used the integration with CloudWatch, which allowed us to setup an observability layer with relatively low effort. Another important integration we found of maximum impact is the one with IAM. We can manage fine-grained permissions for the dev-ops team, and automate the handling of certificates through the ACM service A third advantage we found important is the reduction of administration overhead. You don't have to perform complex operations to upgrade or secure the control plane, We could easily manage the upgrade of kubernetes version with minimal disruption.

My primary point of concern, leading to a slightly lower rating for service and support, revolves around the support costs associated with legacy AMI versions. While the service and product capabilities are excellent, a challenge arises when an AMI (base template) is upgraded. If our services are still running on older versions, such as those from version 1.27 while the current is 1.32, we incur additional support costs for these legacy versions. My preference would be for Amazon to continue supporting these older versions without additional charges, especially since we are already paying for the base infrastructure costs. This aspect is the sole reason why I rate service and support slightly less. It means that to avoid these extra costs, we are compelled to upgrade our AMI versions, which, while beneficial for staying current, adds a layer of operational management that could be streamlined.

I dislike the time it takes for each node to spawn. We use docker images and it would be great to have spawn time faster.

All the advantages you have come at a price! Compared to on-prem installation, for small scale applications you face higher costs. Of course this is balanced by the advantages described above. So even though this is something I would like improved (lower costs), taking into account TCO, with some complex production environments the cost is compensated by the tranquillity the AWS environment can offer. A second thing I didn't like much in my experience is the somewhat complex setup of the network environment The main disadvantage, but it is implicit when you choose such a solution, is the dependency on AWS for the release cycle of the upgrades, and in general the portability of the solution you deploy to other environments, so you must plan your setup carefully if you plan to use it in other environments.