Why Starting a New Project with Microservices Is Usually a Bad Idea – Monoliths Are Your Friend

Ideal Microservices

Arnold Galovics argues that starting a brand‑new project with microservices is usually a mistake, because the overhead outweighs the promised benefits.

Perceived Advantages

Fault isolation – failure of one service does not bring down the whole system.

Avoiding vendor lock‑in – each service can be written in a different language or stack.

Easier to understand – smaller services are simpler to grasp.

Faster deployments – services can be released independently.

Scalability – individual services can be scaled horizontally.

In practice these advantages are hard to achieve; they require substantial infrastructure, tooling, and cultural discipline.

Real‑world Infrastructure Costs

Running microservices typically involves a load balancer, multiple compute instances, several databases, a message broker (e.g., Kafka), CI/CD pipelines (Jenkins), logging (Kibana), monitoring (Prometheus), and distributed tracing (Jaeger/Zipkin), all of which increase operational complexity and cost.

Cultural and Organizational Challenges

Teams often underestimate the effort needed to design, implement, and maintain dozens of services. Feature development that touches many services can take weeks instead of days, and coordination overhead can slow delivery.

Modular Monolith as an Alternative

A well‑structured monolith that is modularized from the start can provide many of the same benefits without the heavy operational burden of microservices.

Conclusion

Choosing between microservices and a modular monolith should be a balanced decision based on team size, product timeline, and willingness to invest in infrastructure and culture.