I Defend the Monolith Because I’ve Seen Production
Recently, while chatting with a teammate, the question came: “Why are you still using a monolith?” That question carries with it a bias against the monolith — common in our industry — at a time when microservices have been declared the winner. But my nearly 20 years of field experience, especially when meeting the realities of production, taught me something different. That day I turned to my friend and said “Because I’ve seen production.” That short answer summed up years of accumulated practical knowledge.
The brutal realities of production are very different from theoretical architecture debates. Every error, every performance problem, every deployment crisis you see there shows you the real value of a technology or architectural approach. The allure of microservices is obvious; scalability, technology diversity, independent deployments and many more. But these advantages come at a cost, and that cost isn’t always worth paying. Even managing more than 13 Docker containers on my own VPS, I sometimes see how fragile the system can be. If one of them misbehaves, the others can drop into swap fast. That’s why I’m always after simpler, more manageable solutions.
Microservices Promises vs. Reality
When I first heard about the microservices architecture, I said “this is it!” It was as if it were a magic wand to solve all the complexity. Different services, different languages, different databases… Each scaled on its own; one failing wouldn’t directly affect the others. It sounded perfect for big e-commerce sites and financial platforms. But once I actually got into it, I saw how deeply interconnected those “independent” services really were.
A small change in one service can cause unexpected behavior in another. Debugging in distributed systems is far harder than debugging a single monolithic app. Topics like network latency, inter-service communication issues and distributed transaction management make development quite complex. Even building the AI content pipeline I use on my blog, getting inter-service communication right ate serious time. Even a tiny detail like a slash in tags could trigger weird errors like publishDate becoming a quoted string. While dealing with those “AI quirks,” I can’t help thinking how much more relaxing a simpler system would be.
The Overlooked Power of the Monolith
So why is the monolith still valid? First, it lowers operational complexity. One deployment package, one codebase, one database (usually). That’s a huge relief, especially for someone like me who manages their own server. While automating my CI/CD pipeline with GitHub Actions, managing a single monolithic structure is far easier than coordinating pipelines across dozens of different services. Just running my own self-hosted runner on a VPS to avoid blowing through the GitHub Actions quota is its own optimization. The monolith makes those optimizations simpler.
Building my blog with Astro, managing everything inside a single project structure makes things much easier. In this stack — Node.js, SQLite, Nginx and systemd — running 13+ Docker containers on the same server is already a balancing act. I don’t want to pile microservices’ extra weight on top of that complexity. The monolith speeds up the development loop. When I want to add a new feature, instead of coordinating different services, I can change my own codebase directly. That’s a huge advantage, especially in projects where I want to prototype quickly.
Making the Monolith Better
Using a monolith doesn’t mean falling behind. On the contrary, there are smarter ways to use the monolith. For example, applying the modularization principle makes the codebase more manageable. That also makes it easier to split out services later if needed. The disk-fill problems I had on my own VPS (33 GB build cache, 23 GB unused images) showed how critical good disk management and a cleanup strategy are. The same applies to monolithic projects: keeping unnecessary dependencies and old code clean improves performance and manageability.
When my Astro build eats 2.5 GB of RAM and the system reaches 7.6 GB — running into OOM (Out Of Memory) scenarios — I always try to optimize overall resource usage. Similar situations happen with the monolith. In-app resource optimizations, using efficient algorithms and avoiding unnecessary memory consumption can significantly improve a monolith’s performance. From my experience, no matter how complex an application gets, with good engineering and careful optimization it can stay manageable.
Conclusion: Pragmatism or Theory?
In the end, when I say “I defend the monolith because I’ve seen production,” I’m speaking with the confidence of having experienced what works and what causes pain in practice. As tempting as the beauty microservices offers may be, operational complexity, debugging difficulty and the additional load of distributed systems are factors you must always weigh. In my own projects — especially in this blog built with Astro — simplicity and manageability have always been priorities for me.
While preparing this blog post, I had to deal with some of the AI’s oddities. Imagine if I had to deal with such issues across an ecosystem of dozens of services in a microservices setup — how much harder things would get. Every project has its own dynamics, of course. For large and complex systems, microservices can be unavoidable. But my philosophy is always to start with the simplest solution and only add complexity when truly necessary. Have you had production experiences that pushed you toward specific architectural choices? Share them in the comments — let’s discuss.