Microservices: MonolithFirst?

Question

I've been researching microservice architectures trying to get a high level overview of all the pros and cons, whens and whys, etc. A lot of the information I'm reading/watching is coming from ThoughtWorks (Martin Fowler, Neal Ford, et al).

Most of Martin Fowler's work on the subject is a few years old, when Microservices (as a household name in programming, if not in general practice) was still young, thus I take much of it with a grain of salt.

One thing in particular is this:

As I hear stories about teams using a microservices architecture, I've noticed a common pattern.

• Almost all the successful microservice stories have started with a monolith that got too big and was broken up
• Almost all the cases where I've heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble.

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

(ref: https://martinfowler.com/bliki/MonolithFirst.html - emphasis theirs)

Now, 3 years later and with microservices a more ubiquitous term, is it generally agreeable that a new system is typically better served by having larger(-than-microservice-but-smaller-than-monolith) service chunks to start with, and making them more granular as part of an evolutionary measure?

Or, is there a norm to begin a project from scratch with a granular microservice architecture, in contrast to the statements above?

Seems like a sane general approach, but curious of the community's thoughts.

Answer 1

If your company has been doing microservices for a while, some pieces might already be built and you simply need to incorporate them. Likely examples might be authentication as a service or storing blob data. In that case, you've already defined the boundaries and you are reusing code in a new application. That's a good thing.

For new code where you are unsure of where the boundary needs to be, build it up in one service. If you keep it modular, you can split off microservices from it as necessary. Particularly as you find pieces of your service that need to scale differently than the rest.

The benefit of microservices is that you can add instances to scale the work being done on demand. If some of your work comes in bursts, it might make sense to seperate that off into it's own microservice.

In general:

• If you already have microservices built, reuse them
• If you are building something new, make the idea work first
• As you are building, try to keep things modular so some services can easily be broken out
• As you are building, if part of your service needs to be able to scale on demand at a different rate, separate that into it's own service

All too often, we hear useful guidelines from smart people with good reputations like Martin Fowler, and then turn it into a hard doctrine that can't be swayed from in any way.

You have to take statements like that in the spirit of how they are meant. Martin Fowler is trying to save people from paralysis by analysis and tell them to build something that works first. You can always break it apart later, when you know more about how your application really works.

Answer 2

The most immediately valuable benefits of microservices can be achieved by simple code modularization. You can isolate groups of features into modules using whatever module system you have (maven, npm, nuget, whatever). Each module can serve a single purpose, sit it's own repo, use it's own DB schema, manage it's own config, have it's own feature backlog and release schedule. They can still be deployed together onto a monolith. This is a very manageable amount of overhead and gives some good benefits. The bigger overhead comes from separating deployments which is only really valuable once you have enough scale to necessitate it. If your code is already modular, then it's going to be an easier migration when the time comes.

Answer 3

In my opinion, it can be beneficial to develop a monolith first (or better: to develop parts of your application as a monolith).

There are cases when you are unsure about the domain and the boundaries of your problem (e.g. I build a ship management site, do I need a ship service AND a fleet service, or is a ship service sufficient?), and in such cases a monolith can be easier to develop.

You should stop doing this if you need to bring different technologies into the mix (e.g. your existing parts are written in C#, but your new problem requires machine learning, with is best done with Python), have a good understanding about the domains in your project or your monolith threatens to galvanize, e.g. everybody just builds this monolith and squashes the notion of separate services.

Answer 4

I'm pretty sure there have been a couple of question on this exact article by MF.

My take on it is this:

A Monolith with problems of maintenance or scaleability is improved by breaking it down into micro services. Such a project will almost always be 'successful' as even breaking down a small section can result in measurable gains and you can draw a line under it when you are happy.

Whether your half monolith + a message queue and a couple of worker processes counts as 'Microservice Architecture' is an argument to have down the pub, but you will definitely be calling it that when you talk about the project.

On the other hand, any new project regardless of the architecture chosen runs the risk of not meeting expectations, so naturally you would expect a lower success rate. Plus if you have started out aiming to make the whole thing 'Best Practice Microservice Architecture' from the ground up then you may be venturing into new technologies and the harder bits of microservices.

Also we have to remember that MF writes from a big OOP perspective. He is naturally sceptical of a more modern distributed approach.

In this day and age I would expect any large business solution to incorporate an element of microservices and only a fool would recommend you make one giant monolith application unless you are distributing a single desktop style application.

Answer 5

In my (vast) experience I've witnessed many more projects fail because of people problems than technology problems. Unfortunately, people don't like failing and so tend to misreport the reasons for the failure and blame the technology.

In my domain, finance, most new projects follow microservice architectures these days, and it does seem to be a winning architecture from a TCO (total cost of ownership) perspective. These projects do not seem to be failing that often, and when they do the reasons given don't often list the application architecture as the issue.