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.

5 Answers 5


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.


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.

  • Sounds like a a healthy does of general coding best practice mixed with a slight bit of improved codebase management, but falls short of the "don't have to update the whole monolith on a minor service update" path, which is where I expect microservices tend to shine. In any case, good advice, thanks.
    – jleach
    Commented Apr 22, 2018 at 20:09
  • 1
    Completely agree with the answer. A well built and correctly modularized monolith provides most (though not all) benefits that microservices have. On the other hand, microservices have some pretty big issues of their own. Commented Apr 23, 2018 at 12:10
  • @jleach One quality of good modularization is independent deployability. If you have to recompile and redeploy your whole monolith in order to do a minor module update, you are doing something wrong. Commented Apr 23, 2018 at 12:18
  • 2
    This is a good approach. Don't build a microservice for the sake of doing microservice. Microservice architecture should be used to solve problems, but they also come with a set of its own problems, so if you're not ready/aware of those tradeoffs, you should be really careful about developing microservice from the ground up.
    – Lie Ryan
    Commented Apr 23, 2018 at 13:48
  • 1
    @MilosMrdovic, even with with module approach, you can still gain some efficiency in deployment since you don't need to retest your entire monolith, only the module you're updating. If your module passes all quality gates, you can build it and ship it. Then your monolith just needs to update it's dependency version and redeploy. You won't need to rebuild any other modules.
    – jiggy
    Commented Apr 23, 2018 at 15:24

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.

  • 1
    “and in such cases a microservice can be easier to develop” – did you mean to talk about monoliths there?
    – amon
    Commented Apr 23, 2018 at 12:14
  • @amon Thank you, I have corrected the sentence - my son did interrupt me 34235 times so I was confused ;) Commented Apr 23, 2018 at 12:40
  • While I agree with your first sentence, I think you should consider that even your monolith should already be "modular-like" inside, otherwise you just won't be able to separate anything without having everything falling.
    – Walfrat
    Commented Apr 23, 2018 at 13:32
  • @Walfrat I tend to agree, but the temptation to reuse existing code is much greater (and less easily squashed) in a monolith. E.g. "oh look, somebody defined an WidgetId, I will just reuse that for my FormId": Also, you cannot easily use another language / db for a project, which really fosters the "everybody must use common tools" thinking Commented Apr 23, 2018 at 13:57

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.

  • Thanks. If MF tends to be slightly biased, is there someone whose work I can study on the opposite side to help gain depth of perspective?
    – jleach
    Commented Apr 22, 2018 at 20:11
  • I would not recommend 'web celebs' as a learning resource. Its ok for a few anecdotes and a fun talk, but in my experience its the detail that makes all the difference between success and failure.
    – Ewan
    Commented Apr 22, 2018 at 20:20

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.

  • Microservices actually solve a lot of organizational problems. If each service has an owner, then you know how to choke when something doesn't work.
    – jiggy
    Commented Apr 23, 2018 at 0:43
  • @jiggy: if the code is well modularized, you don't necessarily need to split it into multiple services to know who to choke.
    – Lie Ryan
    Commented Apr 23, 2018 at 13:41
  • @Ryan, if someone thinks that microservices and modularization are synonymous then they have missed the point entirely. Commented Apr 23, 2018 at 14:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.