Explore the trade-offs between microservices and VMs, and how Kubernetes can help modernise your deployment strategy. Learn about scaling, resilience, and automation for complex systems.
We often get asked the same handful of questions when reviewing system architectures - especially from teams wrestling with legacy infrastructure or planning a rebuild:
These aren’t just technical decisions but strategic ones. And there’s no single right answer. Architecture choices depend on your team, your product, and your constraints. So, here’s a breakdown of how we approach some of the most common questions - based on real conversations and real problems we’ve solved.
Microservices promise modularity and scalability. But they also come with complexity. You’re no longer just building an app - you’re building an ecosystem of services, each with its own deployments, data sources, logs, and failure modes. All servers themselves go down. Therefore by isolating each process into its own server-like container you are increasing the overall complexity and likelyhood of failure - however once seperate each individual component can have its own failover control.
For teams looking to modernise deployments and move towards a microservices architecture, Kubernetes is often part of the conversation. It’s a powerful container orchestration tool that helps manage scaling, resilience, and automation across services. If you’re new to Kubernetes or want to understand its role in modern deployment strategies, we explored it in more detail in an earlier blog: Kubernetes: A Deployment Voyage.
Sometimes, keeping things on full EC2 instances (or similar VMs) is a conscious decision, not a technical gap. It can offer:
That said, VMs come with drawbacks. Scaling is blunt (you scale the whole VM, not just the bit under pressure), and updates can be slower and more brittle. We often recommend starting simple with a vm and scale vertically (upgrading the server) until scaling horizontally - but designing with separation in mind, so it’s easier to move to microservices later if needed.
The other less talked about but arguably more important part of micro service architecture is the fact that each microservice is its own project - that can be maintained by its own team.
Microservices can deliver an increased benefitt to isolate different teams working on seperate parts of the application independantly.
For some strange reason on one hand people ask for microservice architecture but then get confused there are seperate database instances.
If you go down the microservice route then preferably each service should work independantly and be fault tollerant to other services going down.
Often you tend to have one database to rule them all but then you have a single point of failure.
It’s tempting to stick everything into one server instance with multiple schemas. Cheaper, easier to manage, and familiar.
For example use one instance on RDS (Relational database service on AWS) or something.
Multiple DB servers can offer real advantages:
We’ve seen setups where one DB handles transactional data, another handles analytics workloads, and a third supports internal tooling. It’s not always clean or pretty, but it often reflects business realities.
Again it really depends on the stage you are at the scale that the project requires, the type of data. The simpler a system the better.
One document we reviewed recently mentioned deploying via Bitbucket with “manual execution by New Icon.” That raised flags—because it contradicts what we’d already discussed: full infrastructure-as-code (IaC) and deployment automation.
By manual it meant manual agreement to initiate the automated deployment sequence on acceptance/signoff on a staging site! Not for a developer to manually log on to a server and start deploying the code.
We’ve also seen plans that casually drop in “an AI model” without explaining where it’s running or why. Hosting AI on an EC2 instance might be fine - if it’s a custom model you need to train and control.
The key is being clear on what the AI is doing, who owns it, and how it integrates with the rest of the system.
Architectural choices are full of trade-offs. Microservices aren’t automatically better than monoliths. More databases don’t always mean more problems. But what does matter is clarity, consistency, and alignment between your technical choices and your business goals.
At New Icon, we’ve reviewed many architecture diagrams. The best ones are honest about what they’re optimising for. Whether that’s speed of delivery, system resilience, cost control, global scale - or all three.
Subscribe to get our best content. No spam, ever. Unsubscribe at any time.
Send us a message for more information about how we can help you