I worked on several migration projects from SOAP services to microservices back in 2007-2010. We have done a lot of mistakes by following the hype instead of doing what was best for us. (a thread)
We assumed sizing things small without understanding their impact on the organization and operation was the best practice. We had little experience operating a large number of services and didn't quite understand what will scale and what won't scale.
protobuf and similar were not available back then. And we didn't have resources to designate a single RPC standard for the entire organization. It was patches of things everywhere. Some were RESTful endpoints, other teams invented their own JSON-RPC and binary-RPC protocols.
It was a mess. There was not an easy way to discover the existing services. There was no easy way to discover what's available from the services. The client story was quite depressing too. Most teams were using Java (and some did C++ and C#) and built their half baked solutions.
I said there was no consensus on the RPC protocol, right? Some were too smart and started add message queues in between services!!! So they redesigned the overall system and converted a bunch of stuff from sync to async for the convenience of MQ libraries. What a facepalm.
There was absolutely no visibility into the critical path. We were grepping a bunch of logs here and there to see why things fail and why they succeed. It was easily the top catastrophe I've ever seen in my career yet almost everyone was assuming this is how you do microservices.
Then, each team discovered the joy of ownership and how much authority opportunities there are. Microservices started to become very small. We created more work by adding more complexity and created "more jobs" by building a system that was 10x more complex. What a total win!
