top of page

You don't need EKS

Writer's picture: Yogesh JadhavYogesh Jadhav

Ask any architect, how they want to deploy their application. Majority of them will respond - Containerize and deploy it in Kubernetes. Well, they are not wrong but they are not right either. To understand it better, what does a containerized application require?






- An ecosystem to manage lifecycle.

- Provision resources.

- Security controls.

- Enable service discovery

- Integration with cloud ecosystem - Load balancers, storage, logging



In the AWS ecosystem, most enterprises prefer Enterprise Kubernetes Service (EKS). And why they shouldn't. EKS offers lots of benefits like managed Kubernetes cluster, integrated control pane inside AWS Management console, out-of-box integration with AWS components like IAM roles, security groups, etc. It's not easy to build all of this on your own. Hence it makes sense to leverage what's offered as a black-box and not try to solve a problem that ideally shouldn't be your problem in the first step. If your application requires Kubernetes (read the statement twice), your first preference should be to use it as a managed service. But here comes the real truth, most applications require only Container Orchestrator Engine to schedule the pods, attach the storage, provision the nodes, enable service discovery, integrate with Load balancer, enable performance insights, simple and intelligent scaling capabilities, enable logging and monitoring.



If this is what you all need, then EKS may not be an ideal choice for you. And I say this because



- EKS comes with a $75 bill per month for a Cluster. (Whether you deploy pods or not you have to pay that)

- Worker nodes are charged separately based on the pod requirements.

- Installation of additional controllers to talk to the ecosystem (Load balancer, EBS, EFS).

- Additional controllers consume resources on the provisioned worker node which ideally should have been allocated for your application node.



If not EKS, then what? AWS has done a brilliant job in building its own container service - ECS. It has all the capabilities that most of the application requires. One might argue that ECS resource pricing is much higher (per vcpu and memory) than regular nodes. While that is true, ECS offers a brilliant option to provision EC2 instances instead of using a FARGATE engine (serverless). ECS comes with


- No charges for cluster.

- Pay only for underlying resources. Further optimize cost by provisioning EC2 instances instead of FARGATE and also enjoy reserved instance pricing.

- Out of box integration with the AWS ecosystem.

- Rich control pane to monitor overall application health.

- Customize container configuration as per your application needs.

- Scale brilliantly. There are tons of options to choose from.



Sit down and check where your company is bleeding money. Your application may be using the cloud services it may not need at all.

0 views0 comments

Recent Posts

See All

Comments


bottom of page