Hacker News Reader

Comment by lmm | Hacker News Reader

I once worked for a company that was sunk by a microservice-first architecture. The "architect" in charge was a big Fowler fan who would quote him to justify every decision. Every developer knew the architecture was wrong (and many said so - but the architect had the authority to overrule them, which is maybe the real problem).

I guess it's good to finally see some acknowledgement, but this is too late for that particular organization. Beware of hyped architecture bandwagons?

View on HN

Any specifics you can share about why the architecture was so obviously wrong? This is a really interesting topic for me!

It really slowed down development because it made the feedback loops really long - you might have to start up five different JVMs, which would each take a while to register itself with Hazelcast before you could start the next that depended on it, before you could test your change. The service boundaries we had initially come up with weren't always correct (as you'd expect really), but it was a massive effort to refactor something across a service boundary, because each component was released and versioned separately.

Maybe there are ways to work in such an environment, but if so we didn't find them and no-one had the experience to know them.

My company has had similar issues with code modules. The full app was rarely in a working state because the various modules were in a constant state of flux (module A requires module B from branch X, not master, and module C needs to be attached with this temporary script until the API migration is completed, etc).

We ended up merging some of the modules together just to get our agility back.

> because each component was released and versioned separately.

For SOA a mono-repo with synchronized releases is a huge help.

In one commit you can refactor a shared module and update all apps that depend on it. And you know when you deploy to staging or prod that all machines got the latest code

Agreed. Keeping things in the same source tree is an advantage that a lot of people don't consider. It's worked very well for Linux and other large projects that have many separate components that benefit from being maintained in a single place.

At what scale? At Google we had to version everything within a commit, i.e. files that were pushed to different binaries had to make sure they were backwards- and forwards-compatible with the previous version. Your code had to work even if it was talking to another server that was stuck on the previous commit, or even several releases back.

The reason is that when you have 1000s of machines, the push will fail for some. Either the machine will be offline and out of service when the new version is released, or its network connection may be down, or a cosmic ray may flip a bit and make the process crash when installing, triggering a rollback. Particularly when handling user data, you need to code defensively around these and not assume that the server you're talking to has the same code you just wrote in your commit.

Obviously these problems don't manifest when you're pushing to 1-3 machines, but if your deployment is that small, why not run it all in-process with a monolithic app anyway?

Great point. Different scale needs different things for sure. Even at the scale that I've found this successful in you still have to consider that backward/forward compatibility, albeit at a much coarser grain.

None of that sounds unsurmountable or inherent to microservice architectures. What's hard about starting five JVMs? Why did it take "a while" to register with Hazelcast? Why would you expect to initially come up with bad service boundaries, and why is switching two services you've refactored at once difficult?

I think that none of these are problems inherent to microservice architecture, but to someone learning by designing such a system for the first time.

If you want a classic case study on this. Just look into the history of linux.

I was thinking exactly the same!

Was what Fowler said before really pro-microservice first or was your architect just misinterpreting him?

(honest question)

I think this how most major religions start.

From an article Fowler wrote on March 25th 2014 - Microservices [http://martinfowler.com/articles/microservices.html]

"Despite these positive experiences, however, we aren't arguing that we are certain that microservices are the future direction for software architectures. While our experiences so far are positive compared to monolithic applications, we're conscious of the fact that not enough time has passed for us to make a full judgement."

It is pretty clear the architect in question appears to have misinterpreted how proven Fowler believed microservices architectures were at the time.

Thank you.

> a big Fowler fan

Martin or Chad?

I am wondering the same thing. Interestingly enough, Martin Fowler wrote the article.

Thanks. Someone downvoted me because presumably they thought I was being snarky or something, but it's a legitimate question, they both talk a lot about microservices in a very compelling way.

I'm guessing he/she meant Chad Fowler. Chad's way of thinking about microservices is more radical, and more likely to cause havok if someone who doesn't know what the tradeoffs are blindly follows everything he says.

Reply on news.ycombinator.com