Microservices or Full VMs? Pros, Cons, and Common Architecture Mistakes

We often get asked the same handful of questions when reviewing system architectures - especially from teams wrestling with legacy infrastructure or planning a rebuild:

• Why are full virtual machines being used instead of microservices?
• Why split the database across multiple servers?
• Why is the deployment process manual, when it could be automated?

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 vs VMs: What's the trade-off?

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.

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:

• Simplicity: One server, one environment, one place to look when something goes wrong.
• Predictability: Fewer moving parts, especially if the team isn’t yet ready to manage container orchestration, service discovery, and autoscaling groups.

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 - maybe with containers - but designing with separation in mind, so it’s easier to move to microservices later if needed.

Why are there three database servers instead of one?

It’s tempting to stick everything into one RDS instance with multiple schemas. Cheaper, easier to manage, and familiar.

But multiple DB servers can offer real advantages:

• Separation of concerns: Different data types, ownership boundaries, or SLAs.
• Security: Tighter controls around sensitive data, reducing blast radius.
• Performance: Easier to scale individual data domains independently.

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.

Manual deployments, Bitbucket pipelines, and IaC conflicts

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 automation via Azure DevOps.

Manual deployments introduce risk. They don’t scale. And they often lack proper logging or rollback.

In cases like this, it’s usually just a miscommunication. But it highlights a bigger issue: when your docs, your diagrams, and your reality don’t match, it’s a sign your system is growing in ways your process hasn’t caught up with. Standardising on tools like ADO helps keep deployments predictable and secure.

Security, scaling, and resilience: what’s missing?

Other red flags we often see include:

• Open TCP ports without F5 or WAF layers: If you're exposing port 443 to the world, where’s your traffic control? F5 (or an equivalent) should be the gatekeeper.
• No queuing system: If one service goes down, what happens to the rest? Message queues (like SQS, RabbitMQ, or Azure Service Bus) are crucial for decoupling and failure tolerance.
• Encryption as a maybe: If your data “might need to be encrypted at rest,” that’s already a problem. If you’re storing sensitive information in RDS, encryption at rest isn’t optional—it’s standard practice.
• Confusion around VPNs and APIs: If everything is API-driven, why is a VPN mentioned for user authentication? Is it legacy thinking, or does it reflect deeper integration concerns?

These aren’t theoretical problems. They’re the kinds of things that break during a security audit, or cause an outage at the worst possible time.

And what about AI?

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. But often, you’re better off using a managed service like Azure OpenAI or SageMaker. It’s faster, more secure, and less of a maintenance burden.

The key is being clear on what the AI is doing, who owns it, and how it integrates with the rest of the system.

Conclusion: there are no perfect systems

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 - or all three.