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.

I particularly appreciate several aspects of Amazon EKS. Firstly, its status as a native AWS service is a significant advantage, enabling seamless integration with other AWS services. This includes critical solutions like Identity and Access Management (IAM) and CloudWatch, among others. From a security standpoint, a key benefit is that AWS EKS supports Fargate, which allows for serverless containers. To my knowledge, this capability is not offered by all other similar cloud-native products. Furthermore, the support system for AWS EKS is commendable. When I was in the UK, the AWS community was highly supportive, assisting with any issues we encountered. Beyond the community, AWS itself had strong partners in the UK, with whom we worked very closely. Any questions or design-related inquiries we had were met with quick responses from the support team or the community. I also distinctly recall the documentation being exceptionally good and detailed, which was incredibly helpful during our design and implementation phases. I found it to be more comprehensive and detailed than other documentation at the time. For our specific project, which was a large-scale case study in the UK for AWS, we benefited from dedicated AWS teams working directly with us. This led to an unparalleled customer support and service experience, which I would rate 10 out of 10 for our particular situation. It's important to note that this high level of support, including access to a team of AWS CTOs, who provided their expertise and guidance for critical design decisions, may have been unique to our prominently highlighted project. This hands-on, senior-executive level support was invaluable.

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.

While my overall experience was highly positive, there are a few areas where I believe the product could improve. The first point of concern pertains to the control plane cost. Unlike some of its competitors the control plane in Amazon EKS is not free. Although I do not recall the exact cost structure, there is a distinct cost associated with it, which is a consideration that other solutions may not present. Secondly, at the time of our project, AWS EKS was not entirely in sync with the latest Kubernetes versions. I believe this issue has likely been addressed and improved upon in recent years, but it was a point of disparity back then. Finally, the integration process with external CI/CD tools required a significant amount of manual effort. If an organization was using CI/CD tools outside of the Amazon ecosystem, the integration aspect demanded considerable attention and meticulous design work to ensure proper functionality.