Hacker News Reader

Comment by socialist_coder | Hacker News Reader

Totally.

It does seem like they had a good reason for splitting out search though: "We needed to release search updates independently and changes were frequent."

But yeah, I'm not sure why they are attributing the perf gains to the microservices. Very curious...

View on HN

The performance gains of the API were not the by-product of cutting into micro-services. Basically this article is about "We had some issues with the monolith, we cut it into micro-services and also did these other changes along the way that saved us money and gave us performance boost. Changes that we could have done in the monolith but they were less risky and easier to do in the micro-service in comparison to doing them in the monolith."

It's titled faster, cheaper, better:... microservices, implying they were all due to splitting into microservices. But as usual it turns out refactoring was the saviour and microservices achieved jack-squat apart from having something nice to put on his CV.

Lol, Mirco-service architecture is a vehicle that can make it easier to achieve those goals. It is not a black or white solution. There are pros and cons.

Did they explain what was stopping them from releasing search updates quickly from a stable branch of the monolith? Not that I disagree with the approach, deployment units are the best place to put application boundaries, but it doesn't seem like a good enough reason to re architect an application.

Looking for some buzzy headline maybe ?

So far it has worked I guess!

Reply on news.ycombinator.com