4 ms·

> In my experience, monoliths are universally bad in every imaginable way. I just imagined a different way. Monoliths can do transactionally consistent stuff.

bedobi 6y ago
For sure, that's a factor that should be taken into account when deciding what to split and how. But monoliths always have completely unrelated things bunched up in a single codebase, storage etc etc etc. Eg, in our case, there's simply no reason why we should have a single monolith service that has both our b2b partners user profiles and, I don't know, internal staff vacation hours? They have nothing to do with each other, have vastly different load profiles, tolerance for failure etc etc.
nine_k 6y ago
Now you have a good rule of thumb for splitting services: stuff that must belong to a single transaction should live in the same service. This is how you e.g. can split a bank transaction service from a bank balance-telling service, with different requirements for scaling, latency, SLAs, deployment schedules, etc. You can deploy a change to the balance-telling service and then roll it back if it exhibits a problem, all without touching transaction proceeding in any way. These abilities are worth something if you're a big enough. But this is not a starting point for a new side project. You start with a monolith.
- tluyben2 6y ago
  > You start with a monolith. I think that is the HN syndrome; people start projects like they will be larger than facebook even though the project will probably never launch and if it does, get more than 10 users. Yet it runs all services aws has to offer and has 100 microservices and the little company(‘s investors) are paying through the nose in both dev time and hosting while a raw php script on a $1/mo vps would’ve been sufficient to validate the idea and get to ramen profitability and (far) beyond. Like someone said in another thread; focus on your market and acquisition channels first, build great stuff (much) later.
  - nine_k 6y ago
    I remember that eBay seriously rewrote their backend three times — not because they kept doing it wrong, but because they grew. An architecture that fits well for a small company is inadequate for a large company, and vice versa.
    - collyw 6y ago
      I bet there are orders of magnitude more cases where a ton of time and effort has been put into scalable architecture when it wasn't needed. Ebay is a serious outlier when it comes to scale of software, most people aren't going to serve anywhere near as many customers.
  - zimpenfish 6y ago
    I've been through a couple of iterations of "MONOLITH BAD!" where none of the issues were monolith related but instead database design and usage. Also an iteration of "MICROSERVICES GOOD!" where there are more microservices than entire company employees (not just devs) and yeah, it's a bad idea at this scale.
- ryanbrunner 6y ago
  I know it's a simple example, but wouldn't the balance of an account be critically important to be part of a transaction. Otherwise, how could you manage two simultaneous withdrawals if the transaction processing service isn't able to put a lock on reading the balance until it's complete?
  - nine_k 6y ago
    The teller can show a slightly stale, eventually consistent balance figure, depending on its use. This would allow for massively better read performance, which is important when reads occur many times more often than writes. Instead of a balance of a checking account, think about the karma balance of a reddit post, where this approach more emphatically belongs.
deleted 6y ago
[deleted]
enigmo 6y ago
microservices can too, just most databases don't support this without an additional service layer. fwiw Spanner does.
dragonwriter 6y ago
> Monoliths can do transactionally consistent stuff. So can microservices, both internal to the service (via simple transactions) and between services (via distributed transactions, e.g., 2PC), though a good service design minimizes the need for the latter and is mostly guided by consistency boundaries as to where to draw service boundaries.) (It's true that there are naive microservices architectures pursued that are essentially normalized relational designs with a one-service-per-table rule, but that's just bad—and usually cargo-cult—design.
- chousuke 6y ago
  Sure you can do transactions across services. Do you really want to deal with the problem of distributed consensus though? If software especially built to deal with it often gets it wrong (as I think Jepsen tests have frequently demonstrated), what are the chances your team is going to succeed and not build a distributed monolith instead? I suppose in the end it depends on if you want to trade the hard problem of managing a monolith for possibly a much harder problem. I find that for these discussions, the definition of a microservice is too nebulous. Personally I think that if you have "state" that crosses service boundaries (ie. a fault in either service causes the loss of that aggregate state) you have instead built a distributed monolith.
jayd16 6y ago
I've seen monoliths screw this up. All it takes is some abstractions, maybe an ORM. Suddenly the novice programmer is too far away to notice they're running multiple queries outside a transaction without a simple way to fix it. In fact, I think its quite common.

bedobi 6y ago

For sure, that's a factor that should be taken into account when deciding what to split and how. But monoliths always have completely unrelated things bunched up in a single codebase, storage etc etc etc. Eg, in our case, there's simply no reason why we should have a single monolith service that has both our b2b partners user profiles and, I don't know, internal staff vacation hours? They have nothing to do with each other, have vastly different load profiles, tolerance for failure etc etc.

nine_k 6y ago

Now you have a good rule of thumb for splitting services: stuff that must belong to a single transaction should live in the same service. This is how you e.g. can split a bank transaction service from a bank balance-telling service, with different requirements for scaling, latency, SLAs, deployment schedules, etc. You can deploy a change to the balance-telling service and then roll it back if it exhibits a problem, all without touching transaction proceeding in any way. These abilities are worth something if you're a big enough. But this is not a starting point for a new side project. You start with a monolith.

tluyben2 6y ago
> You start with a monolith. I think that is the HN syndrome; people start projects like they will be larger than facebook even though the project will probably never launch and if it does, get more than 10 users. Yet it runs all services aws has to offer and has 100 microservices and the little company(‘s investors) are paying through the nose in both dev time and hosting while a raw php script on a $1/mo vps would’ve been sufficient to validate the idea and get to ramen profitability and (far) beyond. Like someone said in another thread; focus on your market and acquisition channels first, build great stuff (much) later.
- nine_k 6y ago
  I remember that eBay seriously rewrote their backend three times — not because they kept doing it wrong, but because they grew. An architecture that fits well for a small company is inadequate for a large company, and vice versa.
  - collyw 6y ago
    I bet there are orders of magnitude more cases where a ton of time and effort has been put into scalable architecture when it wasn't needed. Ebay is a serious outlier when it comes to scale of software, most people aren't going to serve anywhere near as many customers.
- zimpenfish 6y ago
  I've been through a couple of iterations of "MONOLITH BAD!" where none of the issues were monolith related but instead database design and usage. Also an iteration of "MICROSERVICES GOOD!" where there are more microservices than entire company employees (not just devs) and yeah, it's a bad idea at this scale.
ryanbrunner 6y ago
I know it's a simple example, but wouldn't the balance of an account be critically important to be part of a transaction. Otherwise, how could you manage two simultaneous withdrawals if the transaction processing service isn't able to put a lock on reading the balance until it's complete?
- nine_k 6y ago
  The teller can show a slightly stale, eventually consistent balance figure, depending on its use. This would allow for massively better read performance, which is important when reads occur many times more often than writes. Instead of a balance of a checking account, think about the karma balance of a reddit post, where this approach more emphatically belongs.

deleted 6y ago

[deleted]

enigmo 6y ago

microservices can too, just most databases don't support this without an additional service layer. fwiw Spanner does.

dragonwriter 6y ago

> Monoliths can do transactionally consistent stuff. So can microservices, both internal to the service (via simple transactions) and between services (via distributed transactions, e.g., 2PC), though a good service design minimizes the need for the latter and is mostly guided by consistency boundaries as to where to draw service boundaries.) (It's true that there are naive microservices architectures pursued that are essentially normalized relational designs with a one-service-per-table rule, but that's just bad—and usually cargo-cult—design.

chousuke 6y ago
Sure you can do transactions across services. Do you really want to deal with the problem of distributed consensus though? If software especially built to deal with it often gets it wrong (as I think Jepsen tests have frequently demonstrated), what are the chances your team is going to succeed and not build a distributed monolith instead? I suppose in the end it depends on if you want to trade the hard problem of managing a monolith for possibly a much harder problem. I find that for these discussions, the definition of a microservice is too nebulous. Personally I think that if you have "state" that crosses service boundaries (ie. a fault in either service causes the loss of that aggregate state) you have instead built a distributed monolith.

jayd16 6y ago

I've seen monoliths screw this up. All it takes is some abstractions, maybe an ORM. Suddenly the novice programmer is too far away to notice they're running multiple queries outside a transaction without a simple way to fix it. In fact, I think its quite common.