Embracing Monoliths

It's time to embrace a simpler way of building applications. We must regain control of our software.

Go Back In Time

Keeping It Simple

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?

A Framework for Everyone

You can already move fast with a monolith with almost any language. That's because it's the default.

And the list goes on...

Why Go Back?

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.


Monolith success stories or microservice horror stories. They're all in here.

Give Me Back My Monolith

by Craig Kerstiens

"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."

To Microservices and Back Again

by Thomas Betts

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."

Monolith First

by Martin Fowler

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."

The Majestic Monolith

by DHH (Creator of Rails)

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!"

You're Not Building Microservices

by Justin Etheredge

"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."

Choose Boring Technology

by Dan McKinley

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!

Well Architected Monoliths are Okay

by Robert Northard

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.


Don't just take a bunch of words on a webpage for it.

Simple Made Easy

with Rich Hickey

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."

Monoliths Are the Future

with Kelsey Hightower

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."

Talks At Basecamp

with various speakers

They literally built Ruby on Rails; the framework that revolutionized monolith web development.

About the Site

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.