4 ms·

Microservices move tranasactional concerns out of the database and between service boundaries. If you ever need to transactionally write data to two different m

Microservices move tranasactional concerns out of the database and between service boundaries. If you ever need to transactionally write data to two different microservices, you need to roll your own rollbacks. And unless you store this rollback state in a reliable datastore, there's no going back. The tooling to do this properly, as far as my research goes, does not currently exist. I much prefer horizontally scaling a big old monolith backed by a sharding database like CockroachDb or Cassandra. Same scalability and you get to keep some ACID semantics. Concerns about code size are overblown. Facebook's mobile app is utterly massive and it still runs mostly okay even on weak devices. The maximum practical code size for a monolithic server side app will probably never be reached. We're talking maybe 100 million LoC before you run into real problems, especially if you use a VM lanuage like Java or C# where hot and cold code can be dynamically swapped out and code is stored in a very space-efficient fashion When you reach the scale where the codebase size is an issue you've probably already several rewrites to deal with such massive traffic volume.

scarface74 8y ago
Facebook's mobile app is utterly massive and it still runs mostly okay even on weak devices. I agree with your comments but this is a bad example. The Facebook app is horrible to use on high end devices. The mobile website is much more performant and has most of the core functionality. The app is actually worse in one way - they chose to use the iOS WebView that doesn’t support the native ad blocking framework. So when you click on an external page, it’s usually horrible - bacause modern web.
jpalomaki 8y ago
And let’s face it - you are never going to get your own rollback logic right. There will be simply too many edge cases to worry and test.
- throwaway83628 8y ago
  Yes. That's why I'm amazed there isn't some Zookeeper ish system out there for supporting microservices. The fact is that microservice tooling is in it's infancy, and shouldn't be used in production unless you're willing to roll your own everything. I worked at a place that tried to use microservices+event sourcing+CQRS, predictably a massive disaster. I still think the monolith+distributed database will win out . I've never heard of a time when horizontal scaling was a problem not related to the databse

scarface74 8y ago

Facebook's mobile app is utterly massive and it still runs mostly okay even on weak devices. I agree with your comments but this is a bad example. The Facebook app is horrible to use on high end devices. The mobile website is much more performant and has most of the core functionality. The app is actually worse in one way - they chose to use the iOS WebView that doesn’t support the native ad blocking framework. So when you click on an external page, it’s usually horrible - bacause modern web.

jpalomaki 8y ago

And let’s face it - you are never going to get your own rollback logic right. There will be simply too many edge cases to worry and test.

throwaway83628 8y ago
Yes. That's why I'm amazed there isn't some Zookeeper ish system out there for supporting microservices. The fact is that microservice tooling is in it's infancy, and shouldn't be used in production unless you're willing to roll your own everything. I worked at a place that tried to use microservices+event sourcing+CQRS, predictably a massive disaster. I still think the monolith+distributed database will win out . I've never heard of a time when horizontal scaling was a problem not related to the databse