Search for a command to run...
Pushing back on the 'microservices everything' trend. When monoliths work, when to split, and why pragmatic architecture beats dogma.
Senior Freelancer & Technical Lead
Working as a Golang developer since 2020. Working as a mobile developer since 2013.
Focussed on architecture, testability and clean code. Open minded & product driven. Based in Rhede, available world-wide
No comments yet. Be the first to comment.
How to implement comprehensive software supply chain tracking using Open Component Model that captures dependencies, deployment artifacts, signatures, and version constraints across distributed systems.
A practical framework for evaluating and migrating from deprecated ingress controllers to Gateway API or Envoy Gateway, including risk assessment and zero-downtime migration patterns.
How modern software supply chains use component models to track dependencies, artifacts, and metadata across distributed systems, moving beyond traditional SBOMs to comprehensive delivery tracking.
How to implement comprehensive software supply chain tracking using the Open Component Model that captures dependencies, deployment artifacts, configurations, and runtime bindings across multi-repository environments.
Master React performance optimization through systematic profiling, efficient rendering patterns, and smart bundle splitting strategies for production applications. Learn practical techniques that actually move the performance needle.
Somewhere around 2015, the software industry collectively decided that monoliths were bad. Legacy. Technical debt personified. If you weren't breaking your application into dozens of independently deployable services communicating over HTTP and message queues, you were doing it wrong.
A decade later, I'm watching companies migrate back to monoliths. Amazon famously moved their Prime Video monitoring from microservices to a monolith and cut costs by 90%. Shopify runs one of the largest e-commerce platforms in the world on a monolithic Rails app. Basecamp has been a monolith since day one.
What happened? Reality happened.
Microservices aren't free. They come with a tax that every team pays, whether they acknowledge it or not:
When your function call becomes an HTTP request, you inherit an entire category of problems that didn't exist before:
# A "simple" user profile request in microservices land:
Client → API Gateway → Auth Service → User Service → Profile Service
→ Preferences Service
→ Avatar Service (→ CDN)
← Aggregate response
# In a monolith:
Client → App → database query → response
# Same result. One has 6 network hops. One has zero.
The moment you split your application across multiple services, you're building a distributed system. That means dealing with:
Each microservice needs:
Five microservices means five of everything. Twenty microservices means twenty of everything. And a platform team to manage the platform that manages the services.
I've seen 8-person teams running 30+ microservices. They spent more time on infrastructure than on features. That's not engineering — that's self-inflicted operational pain.
A well-structured monolith is a perfectly valid architecture for most applications. Here's when it's the right call:
Your team is small. If you have fewer than 20 engineers, the coordination overhead of microservices likely outweighs the benefits. A monolith lets everyone work in the same codebase, deploy together, and debug together.
Your domain is cohesive. If your services would constantly be calling each other, you don't have independent services — you have a distributed monolith. That's the worst of both worlds.
You're still figuring out your domain. Microservice boundaries are extremely hard to get right. If you split too early, you'll spend years refactoring service boundaries. A monolith lets you move fast and refactor freely until you understand where the real boundaries are.
Your data model is relational. If your services share a lot of data and you'd end up duplicating it across service databases or making constant cross-service queries, a single database with a monolith is simpler and more consistent.
The key word is well-structured. A monolith doesn't have to be a big ball of mud. You can have clean architecture inside a single deployable:
/cmd
/server # Entry point
/internal
/user # User domain
/handler.go # HTTP handlers
/service.go # Business logic
/repository.go # Data access
/billing # Billing domain
/handler.go
/service.go
/repository.go
/notification # Notification domain
/handler.go
/service.go
/repository.go
/pkg
/middleware # Shared middleware
/database # Database utilities
Each domain module has clear boundaries. Dependencies flow inward. Modules communicate through well-defined interfaces. You get 80% of the modularity benefits of microservices with none of the distributed systems tax.
This is what I call a "modular monolith," and it's the architecture I recommend for most projects we work on.
There are legitimate reasons to extract a service. But they should be driven by real constraints, not architectural fashion:
Your image processing burns 10x the CPU of your API? That's a real reason to split it out. You can scale the image processor independently without over-provisioning your API servers.
Your main app is a Go HTTP server, but your ML model needs Python with GPU access? Different deployment targets are a valid reason for separate services.
You have 100+ engineers and teams are stepping on each other's toes with conflicting deployments? Service boundaries aligned with team boundaries make sense — but only at that scale.
A bug in your payment processing should not take down your product catalog. If a component's failure would cascade to unrelated functionality, extracting it provides genuine value.
PCI DSS requires your payment handling to be in a separate, audited environment? That's a hard requirement, not a preference.
Before splitting anything, ask yourself:
If you pass all four checks, go ahead and extract. If not, keep it in the monolith and revisit later.
Here's what I actually recommend to most clients:
This isn't sexy. It won't get you speaking slots at KubeCon. But it works. It ships features. It lets small teams move fast. And it doesn't require a platform team just to keep the lights on.
The monolith isn't the enemy. Poorly structured code is the enemy. And you can write poorly structured code in a monolith or across 50 microservices. At least with the monolith, you only have to debug it in one place.
Build the simplest thing that works. Split when you must, not when you can. And never let an architecture diagram on a conference slide dictate your engineering decisions.
Pragmatism beats dogma. Every time.