The companies/stacks Fowler encounters are generally in a problematic state. Thoughtworks, like other consulting companies, is generally hired when things are already going wrong. If they are hired to assess a broken monolith stack, the refactoring to microservices is naturally going to yield positive results, and it's easy to come to the conclusion that microservices are an improvement when refactoring from a monolith stack. When they are hired to assess a broken microservices stack, it's easy to come to the conclusion that starting with microservices is broken. What they don't usually see is the hundreds of instances of microservices (and monoliths) working as intended, as there is typically no need to call in a very expensive consultant in those cases. How many times in the case of badly-organized Microservices was the solution to migrate to a single monolith? I imagine the solution is more often to re-organize the services. If that's true, then one cannot say that microservices-first fails -- just that badly-organized microservices-first fails.
Starting with microservices first, especially in a small team of developers (but more than 1), helps things move much quicker than it did with everyone sharing responsibility for the same codebase. Organizational structure tends to reflect its products' structure. Microservices requires that the splitting of responsibilities between teams or developers roughly matches the split of responsibilities among services. Otherwise, you're just working on micro-monoliths.
An actual study needs to be performed before deciding on a "Right Approach" as this piece does.
FWIW, my experience matches Fowler's claims perfectly. Designing a microservices architecture is harder than a monolithic one because it is much harder to refactor when you find that you've made mistakes. And you always make mistakes. Therefore there is real value in prototyping a monolithic system, no matter what you plan on winding up with.
Furthermore services versus monolithic is hardly a new debate. I would suggest reading and understanding Linus' comments on microkernels versus monolithic kernels at http://yarchive.net/comp/microkernels.html. Pretty much everything he says applies to microservices versus a monolithic stack. With the exception that microservices allows one to parallelize complex stuff across multiple machines for better scalability. So it is the only real option for some use cases.
This. The key thing missing from Fowler's blog post is context. If you are a small team/company then microservices is probably not sensible unless you are highly skilled - the overhead is too high and the benefits less too.
If you are a bigger organisation though, with lots of teams, microservices are required to decouple teams and enable agility/exploration in products and services.
Lastly, it's easy to advocate the monolith ('only to start') when you're a consultant, as you've left by the time it becomes a problem. Or, you get called in down the line when it's all gone pete tong because the monolith 'prototype' has become a monster.
Note, I've spent the last two years working on microservices (which has involved a big learning curve but now yielding benefits) and also old monoliths (that have sucked up so much time it's unbelievable).
Fowler does admit to having little data on successful microservice-first companies. If anyone disagrees here, why not post some examples of it actually working out?
I think that starting with a microservice architecure in a small team will incur high initial costs, especially if the team follows modern development approaches like continuous integration/deployment. Moving a monolith through a testing pipeline can be challenging, but moving a microservice architecture is even more challenging, especially in the beginning, until you learn how to manage a distributed system. Thats not to say its wrong to do so, but the initial costs should be taken into account.
I think you touched on something that really has recently (last few years) made micro services possible for everyone - tooling. All of the CI/CD tools have matured to a point where they are somewhat easy to use and setup. They are also improving everyday. Docker, Ansible, Kubernetes, cloud servers etc... all are very accessible and possible for regular dev to setup and use.
>> How many times in the case of badly-organized Microservices was the solution to migrate to a single monolith?
All the time. Except it's usually not a migration or refactoring. Instead it's a quick rewrite on a different stack. Or an outright product acquisition where the acquired IP is a monolith.
>Organizational structure tends to reflect its products' structure.
This seems to me to be the real reason why you can achieve some measure of success with this pattern: you can align your architecture with your corporate political set up.
If there is dysfunction across team boundaries where trust and cooperation is low, you can help deal with that by creating a 'contract' across that organizational layer in the form of an API end point.
Nonetheless, there's no reason why that contract must be in the form of a networked API end point.
> An actual study needs to be performed before deciding on a "Right Approach" as this piece does.
I wouldn't say this piece decides on a "Right Approach" at all, especially if you read the last two paragraphs, in which he says he doesn't feel like he has enough information to make a decision about it. Which is essentially the point you made.
Though it's fair to say the title and intro _feel_ like they're leaning toward making the point that you reacted to.
Starting with microservices first, especially in a small team of developers (but more than 1), helps things move much quicker than it did with everyone sharing responsibility for the same codebase. Organizational structure tends to reflect its products' structure. Microservices requires that the splitting of responsibilities between teams or developers roughly matches the split of responsibilities among services. Otherwise, you're just working on micro-monoliths.
An actual study needs to be performed before deciding on a "Right Approach" as this piece does.