A while back, I was pulled into what sounded like a fairly standard cloud migration conversation. A client wanted to migrate their application to AWS, modernise their stack, and position themselves for growth.
On the surface, it sounded like nothing unusual.
As we began unpacking the details of the migration, they outlined their plan for the database. They wanted to take their MySQL database… and run it inside a container.
And that is when things got interesting.
I've worked on a lot of migrations over the years, and while this approach isn’t impossible, it stood out for a different reason. It was trying to solve a problem that didn't quite exist, while quietly ignoring several that very much did.
But before I explain why that pattern raised red flags, let me give you the full picture of what this client was actually trying to achieve.
Background
At the time of meeting the client, they were running a traditional monolithic application hosted with a local provider. The entire system – the frontend, backend, and database – all lived on a single virtual machine. While this setup initially worked, over time, the limitations became harder to ignore.
Performance issues started creeping in. Scaling was difficult. And even small changes required careful coordination across the entire system.
At the same time, the business was preparing to expand into a new market, one that would bring a significant increase in users and transaction volumes. Based on their projections, it was clear that their existing architecture wouldn’t hold up under the expected load.
So, they made a strategic shift. They would move towards a true microservices-based architecture and break down the monolith into smaller, independent services. This would allow them to scale individual components independently, deploy faster, and improve overall resilience.
The modernised system would consist of separate frontend, backend, caching, and database layers. Containers were chosen as the preferred deployment model. From an application perspective, this made perfect sense.
The Turning Point – the Database
As the conversation progressed, the client outlined their migration plan:
- Each service would run in its own container.
- The database would follow the same pattern, containerised and deployed alongside the rest of the services.
At first glance, the approach felt clean and consistent. Everything followed the same deployment model.
But it also raised an important question:
Should a database be treated the same way as stateless application services?
That question became the foundation for a much deeper discussion. Not just about how to migrate their MySQL database, but where and why it should be hosted in a particular way.
Why It Mattered
Databases are fundamentally different from most application services. Unlike stateless components, they are:
- Stateful by design
- Highly sensitive to latency and disk performance
- Dependent on consistent backup and recovery strategies
When you try to force a stateful workload into a pattern designed for stateless ephemeral systems, you run into several problems. And those problems don’t always show up immediately. They appear later, under load, during failures, or when you need to recover data quickly.
The decisions you make about how to host your database have long-term implications on its performance, reliability, and operational complexity. And in this case, getting it wrong could directly impact the client’s ability to scale into their new market.
What Comes Next
In the next post, I’ll start to break down 3 database hosting options we explored. Each option has its place - but they come with very different trade-offs.
Top comments (0)