3 ms·

Agreed. I once worked on a project which was a microservices based system for managing various types of infrastructure. Progress was painfully slow. There was

Agreed. I once worked on a project which was a microservices based system for managing various types of infrastructure. Progress was painfully slow. There was a separate testing client that was used for a lot of the demos. The demos on the 'real system' would fail so often that somebody came up with the idea to just take a lot of the code from the microservices and drop it straight alongside the testing client, as a monolith. It was so much more stable that after becoming the default way to demo, it became the default way to use the tool. 5 years on and I believe it's still running that way. In this case microservices were massive over engineering.

35fbe7d3d5b9 6y ago
> In this case microservices were massive over engineering. They often are. Well-meaning engineers and architects seem to reach for them while forgetting that microservices are about scaling your organization, not your software. There are very few technical deficiencies in a monolith that are solved by microservices. Indeed, they typically bring technical hurdles: distributed systems are hard to reason through and IPC over the network introduces latency. And you need a very strong ops team to implement them without major headaches. But where they really start to shine is when regression testing takes ~days and your development cycles are screeching to a halt because you've got too many in flight features and not enough runway to land them. What takes real skill is recognizing which of your monoliths should be grown and which ones need to be sliced down the middle.