Faster, cheaper, and better: A story of breaking a monolith

Post by seperman » Wed, Jul 17, 2019, 10:27 PM UTC

socialist_coder wrote: post #9

trishume wrote: post #7

It seems like most or all of the benefits listed in this post could have been achieved just as easily by changing code in their monolith. Like the ElasticSearch optimizations and the decoupling from the relational database. Similarly the benefits they do tie explicitly to microservices like scoped errors and tests can also be achieved in monoliths with simple filters on the errors and tests being run, without all the…

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

Post by seperman » Wed, Jul 17, 2019, 10:55 PM UTC

Marinlemaignan wrote: post #12

socialist_coder wrote: post #9

Earlier quoted context omitted.

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

Looking for some buzzy headline maybe ?

Post by mattmanser » Wed, Jul 17, 2019, 11:54 PM UTC

seperman wrote: post #11

socialist_coder wrote: post #9

Earlier quoted context omitted.

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

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 doin…

Post by gitgud » Thu, Jul 18, 2019, 12:19 AM UTC

seperman wrote: post #10

trishume wrote: post #7

It seems like most or all of the benefits listed in this post could have been achieved just as easily by changing code in their monolith. Like the ElasticSearch optimizations and the decoupling from the relational database. Similarly the benefits they do tie explicitly to microservices like scoped errors and tests can also be achieved in monoliths with simple filters on the errors and tests being run, without all the…

I do not disagree with your comment. As I mentioned in the article the main reasons to break into micro-services are: 1. Independent releases 2. Easier for on-boarding new engineers 3. Scale micro-services independently The rest of the article is about how to use the breakout opportunity to make major changes to the code and the data-structure. The goal is for the users of the service to have an aha moment of "Search…

Post by seperman » Thu, Jul 18, 2019, 12:31 AM UTC

mattmanser wrote: post #15

seperman wrote: post #11

Earlier quoted context omitted.

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 doin…

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.