Breaking up with Kubernetes (a cloud love story)
A passionate and moving love story (kinda) of our Cloud team and the exit of their beloved Kubernetes. Or the less cheesy summary: the reasons why we stopped using Kubernetes and migrated to more serverless technologies like AWS ECS Fargate thanks to less overhead, less complexity and better integration between AWS services.
A few years ago, our cloud team needed a way to manage containerised applications for one of our clients at scale. They obviously had heard of Kubernetes and were drawn to its cloud-agnostic capabilities and vast toolset. Plus, with a name that means "helmsman" or "pilot" in Greek, how could they not be in good hands?
Challenges with Kubernetes
However, as the project grew bigger and the team gained more in-depth knowledge about AWS, they began to explore other ways of managing the infrastructure. The grass is always greener on the other side, right?
After a while, they found that Kubernetes imposed a cognitive overhead on the team and required a lot of setup and configuration. Also, they had to manage the mix of Lambda functions, Elastic Container Service (ECS), and EKS, which made deployment and observability more challenging. For new team members, this was an extra complexity on top of the cloud provider.
Flirting with AWS ECS
Another reason they decided to shift towards ECS Fargate was the tight integration with other AWS services. This provided a smoother integration between services on networking, security, and policy levels. The move towards more cloud-native services created more visibility on the infrastructure-as-a-code level and reduced the translation between Kubernetes-specific functionality and AWS concepts.
Finally, Kubernetes had a less robust track record on AWS. While it is possible to run Kubernetes on AWS, the integration between Kubernetes (EKS) and underlying services became too complex to handle and required some maintenance like migration to a newer version of Kubernetes. A single cluster didn't fit into the loosely coupled event-driven architecture.
The Migration to ECS Fargate
After careful consideration, the cloud team decided to move to AWS Elastic Container Service (ECS) Fargate over the course of six months while still keeping up with their daily tasks for the client. They moved each service individually to reduce risk and gradually shifted their critical services to avoid disruption to users. This approach was the safest but did require some cleanup after the migration.
Now that all of the team's services are migrated, they couldn't be happier. The amount of tools they need on a daily basis has reduced, and they don't have to think about updating their cluster anymore. All of the containers are in one place, and they already know their way around AWS ECS.
Picking the right tools for the job
In conclusion, the breakup with Kubernetes and the move towards ECS Fargate highlight the importance of choosing the right technology for the team, infrastructure, and client. By choosing a more manageable technology and better integrated with other services, they can now focus more on shipping features instead of maintaining a cluster.
Want to know how we managed the switch from Kubernetes to ECS Fargate?
You can find out here.
