Stop Making Monoliths

Martin Fowler and James Lewis recently published an excellent article on microservices, which describes a new approach to architecting large enterprise systems, by composing them out of many independently deployable services, rather than producing a "monolith", which is usually one giant application that must be deployed/installed in one hit, and usually runs as a single process.

What's wrong with monoliths?

The trouble with monoliths is they become increasingly complex and unwieldy as the project grows larger. Despite our best intentions they usually become very tightly coupled, meaning components cannot be replaced or reused. Performance also becomes an issue, and there is no easy way to scale this approach other than to buy a more powerful server.

Why do we build them?

So why do we keep making monoliths? Two reasons. The first is simply because we can. I wrote a while ago about the fact that the vast increase in computing power has enabled us to build applications that are bigger than they ought to be.

The second reason is because it is the path of least resistance. It's far easier to put new code into the existing service, than to create a new service, which will require us to set up a new build and deployment process. So with a microservice architecture, you have to make it really easy to create a new service, or developers will end up bloating the existing services with additional features. Once the friction of creating new services is eliminated, you can begin to migrate away from your monolithic architecture.

What are the benefits of microservices over monoliths?

What benefits do microservices give over a monolithic architecture? Let me briefly mention two.

First microservices gives us real decoupling. Components in microservice architectures are actually replaceable rather than theoretically replaceable. The service boundary forces a radical decoupling of parts of our application, that is hard to enforce in a monolithic codebase, as it is too easy to circumvent (deliberately or unintentionally).

Second, it gives freedom to adopt new technology. Monoliths typically have to be built with one programming language, one database access technology, one dependency injection framework etc. It makes it easy to get stuck on legacy technology. But a microservice architecture allows you to incrementally improve your application to make use of better technologies, tools and practices.

There are plenty more benefits (not least the implications for scalability). But I'm hoping to blog more about other aspects of microservices, so I'll save them for next time.