I started my current role at the beginning of last year. I’ve already shared the “why” behind my job change in a previous post, but today I want to talk about the first big challenge I faced once I sat down at the desk.
Calm Before the Storm
When I first joined, I spent my days getting familiar with the systems, my new colleagues, and the culture.
In “real life,” I’m actually quite an introverted person. But at work? Not really 😄. Whenever I don’t understand something, I ask immediately. I refuse to let myself stay blocked.
Luckily, within a month, I felt well-integrated with the team. That’s exactly when the high-stakes tasks I’d been promised during recruitment started to land on my plate.
What Did the System Look Like at That Time?
At that time, the backend system was a collection of about 10 small microservices written in Spring Boot.
Communication: We used RabbitMQ to pass events between services.
Deployment: Everything was dockerized and deployed together using AWS Elastic Beanstalk.
The Pain Point: Every single deployment caused about 4–5 minutes of downtime.
Because of that gap, we were stuck deploying only during low-traffic periods—unless there was an urgent hotfix that couldn’t wait.
The Mission
The boss handed me a specific challenge:
“With your AWS experience, find a way to deploy services individually without interrupting the system. Use Kubernetes if you have to.”
For a seasoned DevOps engineer, this might sound like a Tuesday. For me? It was daunting. My background was primarily in backend development; my DevOps experience was limited to small personal projects, never a living production system.
What was in my toolkit?
An AWS Certified Solutions Architect – Associate certificate.
A lot of time spent on tech blogs and YouTube.
...That’s about it.
I want to give a huge shout-out to Viet Tran for his AWS tutorials and Nguyen Van Manh for his DevOps insights. One specific mindset from Manh’s talks stuck with me:
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.
The Great Deployment Debate
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.
It took about three weeks to bring the system to production. There were adjustments along the way, of course, but the integration was smooth.
Today
Today, that ECS infrastructure is still running perfectly. I’m convinced it was the right call.
Sometimes, being a good engineer isn't about choosing the most "powerful" or "trendy" technology; it’s about choosing what fits the situation best.
I still wonder what would have happened if I’d gone the EKS route. Maybe it would have worked fine—but I have a feeling every time I looked at the AWS bill, I’d get a little bit of a heart attack 😄.
(If you enjoy these kinds of engineering stories, you can subscribe to receive the next ones.)