| I love how Netflix is so open about their architecture, but I have one strong criticism. After trying to get Spinnaker running, which is like 10 services for a fairly straightforward application, and reading about how Netflix has Cron jobs running to 'clean up' data inconsistencies... I started to think Google has a better approach to scaling the code. Netflix is strong on eventual consistency, and making services as small as possible. Having tried to build something in that image, holy shit the issue of distributed transactions becomes a nightmare. We had to build error handling in everything to handle the failure of everything else. Maybe half our code was 'just in case' to deal with exploding failure scenario complexity during service call fanout. If your service calls out to two or more services that also do data updates, God help you. There's no call ordering or way to make sure both succeed or fail, so if one does you could easily end up in an invalid state. Contrast this to Google's approach. Maps is one service, Docs is one service. Their service boundaries are much larger so they can shove the complexity of consistency and rollbacks back into the DB where it belongs. And they avoid eventual consistency as much as possible. If Google can make these big 'monoliths' work at huge scale I don't see any advantage to 'microservices', it's just a bunch of pointless overhead. I think Netflix has had a little too much industry koolaid ... |
Distributed transactions are a sure sign that your service boundaries have been incorrectly drawn.