3 ms·
Well.. just consider every "microservice" a separate company, exposing its own product/service. Also think about all the overhead that comes with it - product m
by jbverschoor 7y ago
Well.. just consider every "microservice" a separate company, exposing its own product/service. Also think about all the overhead that comes with it - product managers, finance, recruitment etc.
- crispyporkbites 7y agoIf all the services that the microservice needs are also services behind an API, what's the overhead? Something like: hire("developer", 10, "10x).addToPayroll().office("openplan", "wfh").enforceHRPolicies() Is all you need The best thing about this is that you can keep everything in change control and just rollback whenever you need to, or spin up new companies at will.
- pjc50 7y agoSee Coase and the "Theory of the Firm": https://en.wikipedia.org/wiki/Theory_of_the_firm https://en.wikipedia.org/wiki/Theory_of_the_firm Occasionally companies actually do this by fragmenting divisions into separate companies, such as outsourcing IT. It has a very broad range of outcomes, from saving to destroying the business.
- dmix 7y agoSo like monoliths vs microservices it's probably a balance between the two (leaning heavily in one direction). I've never understood why it needs to be either/or. Is it really that difficult to support a microservice deployment that only represents 50% or even 20-25% of the org/project?