I started at my new company at the beginning of last year. The reason I changed jobs was already explained in a previous article.
Calm Before the Storm
When I first joined, I spent time getting familiar with the system, new colleagues, new projects, and the company culture.
In real life, I’m quite an introverted person. But at work… not really 😄
Whenever I don’t understand something, I ask immediately so I don’t get blocked.
Luckily, after about one month, I had already integrated quite well with the project and the team.
That’s when the tasks mentioned during my recruitment process started to arrive.
What Did the System Look Like at That Time?
At that moment, the backend system had around 10 small microservices written with Spring Boot.
The system used RabbitMQ to send events between services.
When we needed to update a service, all services were dockerized and deployed together using AWS Elastic Beanstalk.
Each deployment caused about 4–5 minutes of downtime.
Because of that, deployments were usually done during low-traffic periods, except for urgent hotfixes.
My First Assigned Task
The CTO gave me a task:
With your AWS experience, find another way to deploy services individually without interrupting the system.
Use Kubernetes if necessary.
For experienced engineers, this might sound easy.
But for me at that moment, it wasn’t.
Before that, I was mostly a backend developer. My DevOps experience was limited to small personal projects, never real production systems.
What Did I Actually Have?
I had the AWS Certified Solutions Architect – Associate certificate.
Other than that… not much.
I spend a lot of time reading tech blogs and watching tutorials on YouTube.
I also want to thank Viet Tran for his AWS tutorial videos, and Nguyen Van Manh for sharing many DevOps insights.
One mindset that stuck with me from his talks was:
Don’t make things complicated.
A pipeline only has two important stages: build and deploy.
Everything else is secondary.
The AWS explanations and advice from Viet Tran also helped me understand which services to choose and how to approach the problem.
Let’s Start
Now I was standing in front of three options for deploying Docker containers on Amazon Web Services:
- Amazon EKS
- Amazon ECS
- Amazon EC2
EC2
I quickly rejected this option.
Using EC2 with docker-compose or docker-swarm would require a lot of effort to deploy and maintain.
Maybe it could be the cheapest option, but for someone with limited DevOps experience like me, it felt risky.
Actually, the existing Beanstalk deployment was already similar to this model.
Beanstalk created ECS clusters and deployed services on EC2 instances.
EKS
Even though I had no Kubernetes experience, I believe I could learn it if I had enough time.
After all, AWS already manages the hardest parts.
Using EKS would also look great on my CV and allow me to explore Kubernetes more deeply.
But this was clearly a trade-off.
If you only have a small number of services, using EKS can feel like using a huge knife just to kill a fly.
It’s powerful, but maybe too complex.
Managing Kubernetes properly also requires someone with solid experience. Otherwise, you might spend all day debugging infrastructure issues.
And the cost isn’t small either.
Even if you do nothing, maintaining a cluster already costs around $100 per month 😄
ECS Fargate
In the end, I chose AWS Fargate with ECS.
It’s an AWS-native service and already provides everything I needed:
- Load balancer
- Auto scaling
- Rolling updates
- Blue-green deployments
It’s lightweight and serverless.
Basically, I let AWS handle most of the infrastructure and focus on developing the application instead 😄
The cost was reasonable and the service was very beginner-friendly.
After about three weeks, I managed to bring the system to production.
Of course, there were still adjustments later, but overall it integrated quite smoothly with our real project.
Today
Today the ECS infrastructure is still running well and fits the company’s needs.
I believe choosing ECS was a reasonable decision.
Sometimes it’s not about choosing the most powerful technology.
It’s about choosing what fits the situation best.
I sometimes wonder what would have happened if I had chosen EKS.
Maybe everything would still work fine.
But every time I looked at the AWS bill, I might get a little shocked 😄
(If you enjoy these kinds of engineering stories, you can subscribe or visit my blog to receive the next ones.)
Connect me on LinkedIn :D
Top comments (0)