Hacker News Reader

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

OT: what does "it's all gone pete tong" mean?

rhyming slang for "wrong"

Rhyming slang - "it's all gone wrong"

"It's all gone a bit wrong", but normally in a dramatic way.

http://en.wikipedia.org/wiki/It%27s_All_Gone_Pete_Tong

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?

To me it sounded like he was writing to the people who are trying microservices because it's the hot new thing they read about on some popular blog.

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.