Some of the best tools in our industry were designed to work with monoliths. The most productive frameworks across every language often assume an integrated, simple codebase.
The IDE. Jump to definition. Backend MVC frameworks. Forms that don't make you tear your hair out. Continuous delivery and integration. Platforms as a service. Metrics gathering. Alerting tools.
A limitless treasure trove of tools that work wonderfully with monoliths is out there. How can we call ourselves software "engineers" if we reject the best tools available?
You can already move fast with a monolith with almost any language. That's because it's the default.
And the list goes on...The results of microservices have been made clear- for small teams, they are a disaster. Modern software development is already too complex- understanding just one piece of the stack is a challenge for the best developers.
Breaking business logic out across codebases is not the answer- doing so creates more overhead, more failure methods, and more headaches. While this might work at FAANG, most projects are not of that scale.
To move forward, we must regress- we must reject the combinatorial explosion of complexity, embrace a well-integrated backend, and once again create codebases where we can move fast and fix things.
"There are a lot of reasons to migrate to micro-services. I’ve heard cases for more agility, for scaling your teams, for performance, to give you a more resilient service. The reality we’ve invested decades into development practices and tooling around monoliths that are still maturing."
A story of how Segment (congrats on the purchase!) went from their original monolith to microservices, but wound up migrating back due to complexity anyways.
"The decision in 2017 to move back to a monolith considered all the trade-offs, including being comfortable with losing the benefits of microservices. The resulting architecture, named Centrifuge, is able to handle billions of messages per day sent to dozens of public APIs."
In this article Martin advocates for starting new projects with monoliths, even if you expect to grow huge. Having a product and revenue makes refactoring a lot easier, after all.
"This pattern has led many of my colleagues to argue that you shouldn't start a new project with microservices, even if you're sure your application will be big enough to make it worthwhile."
All hail the mighty monolith! How monoliths really are the best choice for small teams, and how to learn to love them.
"Where things go astray is when people look at, say, Amazon or Google or whoever else might be commanding a fleet of services, and think, hey it works for The Most Successful, I’m sure it’ll work for me too. Bzzzzzzzzt!! Wrong!"
"Having a single, non-distributed codebase can be a huge advantage when starting out with a new system. It allows you to more easily reason about your code, allows you to more easily test your code, and it allows you to move quickly and change quickly without having to worry about orchestration between services, distributed monitoring, keeping your services in sync, eventual consistency, all of the things you’ll run into with microservices."
Don't spend your innovation tokens building a complex, distributed system. All your tokens will be gone before you even ship your MVP.
Keep it simple- choose Boring Technology!
Build your monolith right- decouple what needs to be decoupled but keep cognitive load low.
Using a queue can enforce good boundaries inside a monolith and keep it maintainable for years to come.
An exploration of misconceptions about complexity and a call for simpler programming.
"Simplicity is a choice. We have a culture of complexity. Avoid tools (languages, constructs, etc.) that generate complex outputs. Simple != easy. Look for complexity and avoid it."
The solution to the problems plauging software development is not microservices. Deploying bad code on top of bad infrastructure is not how you fix modern software engineering.
"Monoliths are the future. Because the problem people are trying to solve with microservices doesn’t really line up with reality. Just to be honest - and I’ve done this before, gone from microservices to monoliths and back again; both directions."
They literally built Ruby on Rails; the framework that revolutionized monolith web development.
My name's Maddie, I'm an advocate for simplicity and believe developers can regain control of app development.
As a developer lead, I have to suppress complexity in the codebases I work with to keep my team productive. But I believe industry trends push us towards software that's harder to develop, not easier. Technology should make our lives easier.
All that being said, I (certainly hope) am less opinionated when spoken with about software engineering. This website is written tongue-in-cheek; you can find a more serious tone on my website (and sure, more about me, but frankly, who cares?). And if you've written something rad about monoliths, let me know, please?
And yes- there are cases where microservices rule.