From time to time, I have this discussion with friends and colleagues: Which should I use: ECS or Kubernetes(K8S)? Usually, I answer ECS.
I love ECS because I don’t have the burden to manager servers, node groups, observability (Have you tried to set up a full k8s cluster? It’s not simple) and K8S manifests with Helm. I like to keep things simple, and that is why I love to use ECS.
Questions that I have heard from my friends regarding my opinion:
K8S makes easier to make multi-cloud possible.
Yes, it does. But, do you REALLY need to have multi-cloud? 99% of the business that I know don’t need it. So, this would be a worry when we get to the point that we need to have multi-cloud.
Early optimization is the root of most of our future selves (or peers) problems.
K8S makes easier to have multi-region possible.
This one follows the same principle of the previous affirmative. I never implemented multi-region in AWS, but if I can imagine it correctly, it’s not that hard (or at least it shouldn’t). I can think that using K8S you would target another cluster on your CI/CD for deployment, but that can be made for ECS too. A central account for all ECR images, it’s the key to make multi-region for containers.
And before multi-cloud or multi-region, do you have resilience on your current infrastructure? Or you are doing it just because us-east-1 went down because of an incident, and you didn’t have a failover for it?
ECS is vendor lock-in.
Is it, though? Bear with me: You are building docker images that you are pushing to ECR, that you’ll need for K8S or ECS either way. For ECS, you just require a service and task definition (that I hope that you are using Terraform for it), and for K8S you require the manifest. And probably your K8S manifest repository could be in ECR. And then you have IAM, RDS or any other service that your applications may need. Of course, you can run your Postgres inside K8S, but you are adding (IMHO) unnecessary burden to your SRE or Platform teams to make that Postgres resilient and reliable. So, the vendor lock-in starts way before you use ECS.
AND since everything that we do for ECS or K8S is docker-based, it shouldn’t be that hard to move the task definition to a K8S manifest.
ECS gives me the ability to quick win. And I need quick wins. If I’m more worried about the underlying infrastructure than the application that I’m building and the value that I expect to deliver to my customer, something is very wrong. And at least in my bubble, most of the applications can run smoothly on ECS if proper configured. And that’s the same for K8S, but the operational burden is way higher than ECS. The key point here is:
ECS gives you the ability to focus your time on the work that
will deliver the most return to your clients.
One developer can manage ECS.
One developer can’t manage K8S.
The points that I have brought in here are valid worries from my peers. But those are worries from the point where your product is growing, and you need to add a few more perks to it to work smoothly (And maybe to attend some regulations depending on your product field). However, keep things simple. Overengineering is a problem, and today I blame my past self from some of the problems that arrived to my present self.
As a friend told me a while ago: You are not building the infrastructure or your product to attend your needs of the technologies that YOU want/needs to use, but you are building applications that should run for 10 years or more. That gave me a perspective that I didn’t have, and shift a bit the way that I think about the products and architectures that I build.
Final Thoughts
Kubernetes started to be this remarkable infrastructure for microservices, and everyone started to build their applications from scratch thinking on microservices, just because everyone is doing it. Because everyone is doing it, isn’t a valid argument to build your CRUD application as a microservice. And as Sam Newman says in Migrating Monolith to Microservices, if you don’t have a good reason to do this migration, you shouldn’t be doing it. And K8S is not synonymous of microservices.