Converted a monolith to microservices? Did you quantify the savings?

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.

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

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.