Ask HN: Converted a monolith to microservices? Did you quantify the savings? | Hacker News Reader

Ask HN: Converted a monolith to microservices? Did you quantify the savings?

3 pointsjedberg8 comments

I was talking to a friend of mine who is a grad student and is working on a thesis about microservices. She asked me if I ever quantified the savings gained by going from monolith to microservices.

And I realized, I never had. I just assumed it would be better because it would allow for quicker deployments and smaller surfaces for bug triage.

And there are a ton of articles that talk about how microservices save you money over a monolith, but none include hard numbers. And I suspect a lot of companies made the move simply based on these articles.

So my question is, has anyone ever quantified the savings (or costs!) of using microservices vs a monolith?

View on HN

This is a pervasive problem in software engineering. It's very hard to find any numbers to prove whether any specific practice, or design, or architecture has any actual effect.

My employer started using microservice as a way to update technology. We didnt have time to rewrite the main app, but new features were written in microservices, and those services used new technology. The savings wasn't a number, it was quantified as pass/fail.

We needed to update tls and other security areas, customers would have sued us and/or left us otherwise. This was made possible by refactoring into microservices. We also did it for quicker deployments, again customers were seeing our competitors update a website with no down time, so if we didn't switch to microservices to increase our deploy time, we would have failed and lost customers. (This is a > 10 year code base for B2B enterprise software, so don't judge us too harshly on these short comings)

Quantified savings is a hard and confusing thing to track from a tech perspective, but a sales person stating how many licenses you're going to loose if you don't do x is pretty easy to track!

I think, one good way to go about answering this is to see if you can find articles, blogs talking about Netflix's engineering and how it evolved over time. They are a huge proponent of microservices and kind of popularised the concept.

IMO, mirco-services make a lot of sense for high number of users, B2C global products due to the challenges and huge complexity in terms of distributed systems, users, end cases and makes for a great use case.

For simpler B2B products with not a lot of complexity in terms of engineering. Mononlith, does just fine.

I worked at Netflix at the time and managed the transition, and wrote some of those blog posts. :)

Which is why I ask. We never quantified the savings, we just did it.

Just curious, how did you satisfy the needs of business analysts?

One issue I found with our company's micro service architecture is that each service only cares about what it needs to know. However BA needs to know a lot of data to do proper analysis. The end result is that those services have to connect to each other and I'm wondering if we should go for monolith from the beginning. Because bast amount id time is spent on grabbing data from different services and sometimes it's impossible so BA has to use very complex joins to combine the data from different services.

> And there are a ton of articles that talk about how microservices save you money over a monolith, but none include hard numbers.

Yeah, you can do that by collecting a ton of data related to development though. Breaking down sprints, correcting estimates, deriving cost from time per feature and salaries, comparing it over time across architectures; having to collect all these data from team members during development is way too tedious. It may hamper actual productivity just to produce a more accurate report that says "hey we saved money".

I'd bet there's a large co-relation between successful micro-service migrations and teams that don't squeeze metrics from every single action that each team member makes just to make more accurate reports.

Also, I have no data to back this up, as far as personal experience goes the reason why "hard numbers" are rare for "microservice vs. monolith savings" are because of 2 reasons:

1.) majority of software companies usually don't aim to put effort on collecting metrics for optimizing "savings"; they aim to collect metrics on growth/acquisition, churn rate, market share, customer service, etc. If a large organization wants to optimize savings they'd rather think of taxes, restructuring debt, moving server locations (cloud/baremetal) and other larger items. 2.) majority of software companies are not at that scale where it warrants a report with hard numbers.

Someone already mentioned it here, but Netflix has a lot of material on it, without the hard numbers of course. https://www.nginx.com/blog/adopting-microservices-at-netflix...

Usually development teams subconsciously quantify microservice migrations due to severe violations of DRY. Resolving DRY, opens you up to more business opportunities (both internal and external). A microservice allows you to move from just being an app, to being a platform. Customers and other teams in your company build on top of you. The move is not necessarily decided upon because it increases savings (this is also mentioned in that article from Netflix).

If 3-4 apps have a similar feature that needs building and maintaining, that feature warrants to be pulled out in it's own microservice.

I managed the transition from monolith to microservices at Netflix. :) That is why I was asking. Because I know we never quantified it with numbers and I was wondering if anyone else ever had.

My intuition is that most conversions from monolith to microservices have a negative ROI because they are driven by anticipation rather than need. Company spends massive amounts of people hours planning and executing the conversion, but the company dies before savings are realized.

Reply on news.ycombinator.com