Faster, cheaper, and better: A story of breaking a monolith
1–10 of 48 posts
Re: Faster, cheaper, and better: A story of breaking a monolith
#2Interesting article, though I wish there were more details on why this was cheaper, and where the hundreds of thousands of dollars saved annually came from.
Re: Faster, cheaper, and better: A story of breaking a monolith
#3Interesting article, though I wish there were more details on why this was cheaper, and where the hundreds of thousands of dollars saved annually came from.
Mainly saved in infrastructure costs: Elasticsearch and Kubernetes resources.
Re: Faster, cheaper, and better: A story of breaking a monolith
#4“Faster, cheaper, better” is a trigger phrase for Australians, given that it was the three word slogan used by the Liberal Party to whitewash their sabotage of our national Communications infrastructure.
I was wondering when the author would get to the punch line, but they just kept solving problems not creating them.
Re: Faster, cheaper, and better: A story of breaking a monolith
#5Interesting article, though I wish there were more details on why this was cheaper, and where the hundreds of thousands of dollars saved annually came from.
Mainly saved in infrastructure costs: Elasticsearch and Kubernetes resources.
Also from Fair here.
A lot of the cost savings were because we could decrease the size of our elasticsearch cluster. This was mostly due to the flattening of the elasticsearch document schema, which improved performance dramatically but also allowed us to run significantly fewer ES nodes.
Re: Faster, cheaper, and better: A story of breaking a monolith
#6Great article! Bookmarked for some upcoming discussions ;) Thanks
Re: Faster, cheaper, and better: A story of breaking a monolith
#7It 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 work of splitting out the service.
Re: Faster, cheaper, and better: A story of breaking a monolith
#8It 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 don't disagree.
Micro-services to us roughly translate to k8/kubernetes deployments. By splitting the monolith into separate deployments we had more granularity in responding to web traffic vs inventory processing pipeline traffic.
In our case we did happen to have a new repository for it, but the same could have been achieved with better separation of concerns and refactoring within a monorepo/monolith.
But if you are already separating concerns to that level (e.g. only some parts of a service's code base are allowed to talk to X data store and other parts are only allowed to talk to Y data store), then why not break them out into separate services.
You get follow on benefits of the service separation including different teams can worry about fewer moving parts and can more easily work independently. Having well defined service boundaries implies properly versioned APIs. This is in stark contrast to having implicit APIs internal to a single service that often result from object oriented access patterns.
Re: Faster, cheaper, and better: A story of breaking a monolith
#9It 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...
Re: Faster, cheaper, and better: A story of breaking a monolith
#10It 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 is so much faster after the breakout!".