In most situations, micro-services are for organizing domain-specific functional concerns into decoupled teams/services so that functional domain changes can be

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