3 ms·
This is absolutely right in my experience. Microservices are all about scaling development agility in exchange for increased technical overhead. In many cases
by owenmarshall 7y ago
This is absolutely right in my experience.
Microservices are all about scaling development agility in exchange for increased technical overhead.
In many cases this tradeoff is atrocious. If you can say "we can easily take on (large feature XXX) and deliver that", microservices are all pain and no gain.
Where they really start feeling good is when your "two week sprints" turn into about two days of available dev work because the remaining time is spent regression testing your changes and trying to keep the build from breaking because of tests you didn't touch failing (spooky action at a distance is real and it hurts). A clear API contract that both sides of the fence can develop against means that you can keep making progress.
At least until it's time to integrate against the real world, not your mock ;-)
- bhburke 7y agoI think there are plenty of examples of monolithic architectures that also have huge technical overhead, builds breaking for unrelated changes, huge amounts of regression testing, not to mention the build times... Microservices can be a great pattern to deliver quickly _and_ maintain high availability/low technical overhead, that's their point. I think the problem arises when developers try to over-optimize or over-engineer a system, or they want to get promoted so they write a new service, ending up with huge entangled webs like in the sketch. Individuals and interactions over processes and tools, every time
- owenmarshall 7y ago> I think there are plenty of examples of monolithic architectures that also have huge technical overhead, builds breaking for unrelated changes, huge amounts of regression testing, not to mention the build times... Yes – I was talking about those same monolithic architectures in that comment ;-)