I was involved in a merger with the platform I architected on one side, and a platform that does the same thing on the other side. We were told the company wan

I was involved in a merger with the platform I architected on one side, and a platform that does the same thing on the other side. We were told the company wanted one platform. I do everything I can to follow KISS. These are important enterprise systems that drive the entire company. I went with a front-end framework in TypeScript, C# APIs, and a relational SQL DB as the gist of it. It turned out great ... performant, reliable and the users were reporting positive feedback (this one was a recent upgrade from an older system). The other side had the same number of users, but had over 100 PHP microservices, Docker containers, queuing frameworks, and all sorts of additional technologies in the mix. It had 5 times the number of engineers on it, but was at the end of the day was functionally equivilant and had the same volume of traffic. When comparing the up-time, it was clear the microservices architecture was the main source of pain. They weren't even comparable. We are always talking about whether we're at "5 nines", and the other system was having major outages every other week. You could argue that it was a poorly architected system, and that microservices weren't the root cause, but that really wasn't the case. The entire system was based around the microservices, and they weren't working as promised. What originally was seen as separation of logic and concerns and everything else that microservices offer eventually over time became a tangled, inter-dependant system of services that were very high in bandwidth, slow in performance, difficult to maintain and bad in reliability. This isn't the first time I've seen this. I've worked with microservice architectures in other companies, and I haven't yet seen it "done right", or at least how I understand it. It always comes across as great in principle but bad in practice.