3 ms·
A lot of the engineering that goes into microservices infrastructure is explicitly to allow heterogeneous application stacks. Paying all those costs in exchange
by closeparen 6y ago
A lot of the engineering that goes into microservices infrastructure is explicitly to allow heterogeneous application stacks. Paying all those costs in exchange for benefits you won’t use is just a different kind of bad engineering.
You definitely want standardization for truly undifferentiated concerns but it can go overboard. If you’re going to use the same application framework in every service, you may not need to separate services at all.
- vinay_ys 6y agoIn most situations, micro-services are for organizing domain-specific functional concerns into decoupled teams/services so that functional domain changes can be done rapidly without risking rippling or inter-locking changes across the systems. The technical stack layer-cake is usually same for all the micro-services – that allows it to be 'micro' and yet be economical. You want less than 20% of your engineering force to be responsible for operating this technical layer-cake while the 80% of the engineering workforce to be productive on actually solving the functional domain problems of your business. What you are referring to is the old-school SOA where each SOA service could be built by completely different companies using different stack and deployed in different environments and yet interact. This is applicable in financial/banking ecosystems (say real-time payment systems across banks/payment-networks).