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