4 ms·
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
by socialist_coder 7y ago
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...
- seperman 7y agoThe 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."
- mattmanser 7y agoIt'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.
- seperman 7y agoLol, 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.
- Marinlemaignan 7y agoLooking for some buzzy headline maybe ?
- seperman 7y agoSo far it has worked I guess!
- flukus 7y agoDid 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.