I think we don't learn and codify standards from our mistakes in software engineering in the same way we have learnt in civil, mechanical or electrical engineering. I guess it could be because we think the consequences in software mistakes are not as serious/permanent as they are in those other engineering fields.
Also the speed of innovation/change has been super fast compared to those other fields. But I doubt if we can keep up this pace of innovation for much longer without the software engineering process becoming the bottleneck.
I came across a startup of 50 people in which there were 4-5 different application stacks for server-side micro services – each team had decided to go their own way and there were no standard end to end observability and release management tooling and they were struggling to debug a latency issue – which itself was happening because they didn't have proper parallelization of RPCs and didn't have proper timeouts, isolation etc. This problem of not following well-understood design patterns, or keep stumbling into known anti-patterns (and worse yet failing to recognize them as such even after repeated punishing failures/outages) – I've seen various versions of this at different sized companies (from multi-million to multi-billion $$ ones).
And in each case, all decision makers didn't know/have standardized terminology to talk about things, what should have been easy conversations were seemingly unnecessarily hard about what's good design pattern vs anti-patterns etc. I can't help but think that this is uniquely a software engineering discipline problem.
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.
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).
Also the speed of innovation/change has been super fast compared to those other fields. But I doubt if we can keep up this pace of innovation for much longer without the software engineering process becoming the bottleneck.
I came across a startup of 50 people in which there were 4-5 different application stacks for server-side micro services – each team had decided to go their own way and there were no standard end to end observability and release management tooling and they were struggling to debug a latency issue – which itself was happening because they didn't have proper parallelization of RPCs and didn't have proper timeouts, isolation etc. This problem of not following well-understood design patterns, or keep stumbling into known anti-patterns (and worse yet failing to recognize them as such even after repeated punishing failures/outages) – I've seen various versions of this at different sized companies (from multi-million to multi-billion $$ ones).
And in each case, all decision makers didn't know/have standardized terminology to talk about things, what should have been easy conversations were seemingly unnecessarily hard about what's good design pattern vs anti-patterns etc. I can't help but think that this is uniquely a software engineering discipline problem.