I disagree with big chunks of this article, however think it’s interesting to discuss. I have no watched the talk yet so I’m only responding to this article.
Specifically:
Stateless Services Are Wasteful
Depends, it certainly is good use of developer time if you can push the semantics of your distribution to the database. Also, if a user does not have a long session, but perhaps does one or two queries and then goes away for awhile then stateless is about right.
Stateful Services Are Easier To Program
I heavily disagree with this claim. Specifically, it is easier if you only consider the success paths where everything goes right. But that isn’t the world we program in and the reality things are failing, rather often. A simple network partition create a lot of questions about the state.
To use Orleans as an example, which the speaker refers to. Orleans has some complications when it comes to idempotence. Orleans does not guarantee that the same virtual actor will not have multiple instantiations at the same time even if there is only supposed to be on. This is a consequence of Orleans being eventually consistent. That little bit of semantics means you need a lot of complexity around actors that are supposed to be have strongly consistent semantics but don’t actually and you’re not going to feel it until something bad happens. Now your data is possibly corrupt on top of whatever other bad things happened.
Statefulness leads to more highly available and stronger consistency models.
I don’t see why this would be true. It might have equal availability but I don’t see why it would be more available. Availability and consistency are opposed to each other, as well, to some degree. In order to make a stateful application more available and stronger consistency than a the semantics of the application itself are going to have to be more complicated which means it will not be easier to program than a stateless one. Of course, it depends on what problem you’re solving exactly, but I think this claim is suspect.
Sticky connections give clients an easier model to reason about. Instead of worrying about data being pulled into lots of different machines and having to worry about concurrency, you just have the client talking to the same server, which is easier to think about and is a big help when programming distributed systems.
I’m not sure why clients should even be aware of who they are talking to. In a stateless application, a client talks to anyone an it’s happy. Being stateful has lead to more complicated clients, IME. Looking at the DataStax Java Driver for Cassandra, it is incredibly complicated because it tracks who to talk to for different pieces of data. On top of that, stickiness in the face of failure adds complications. Where does the connection get rebalanced to? What happens when the machine comes back? What if the machine is flappy, will connections jump back and forth?
That being said, I think if someone has a framework like Orleans behind them, doing a lot of these things becomes easier, especially if you have a problem that benefits from statefullness.
I disagree with big chunks of this article, however think it’s interesting to discuss. I have no watched the talk yet so I’m only responding to this article.
Specifically:
Depends, it certainly is good use of developer time if you can push the semantics of your distribution to the database. Also, if a user does not have a long session, but perhaps does one or two queries and then goes away for awhile then stateless is about right.
I heavily disagree with this claim. Specifically, it is easier if you only consider the success paths where everything goes right. But that isn’t the world we program in and the reality things are failing, rather often. A simple network partition create a lot of questions about the state.
To use Orleans as an example, which the speaker refers to. Orleans has some complications when it comes to idempotence. Orleans does not guarantee that the same virtual actor will not have multiple instantiations at the same time even if there is only supposed to be on. This is a consequence of Orleans being eventually consistent. That little bit of semantics means you need a lot of complexity around actors that are supposed to be have strongly consistent semantics but don’t actually and you’re not going to feel it until something bad happens. Now your data is possibly corrupt on top of whatever other bad things happened.
I don’t see why this would be true. It might have equal availability but I don’t see why it would be more available. Availability and consistency are opposed to each other, as well, to some degree. In order to make a stateful application more available and stronger consistency than a the semantics of the application itself are going to have to be more complicated which means it will not be easier to program than a stateless one. Of course, it depends on what problem you’re solving exactly, but I think this claim is suspect.
I’m not sure why clients should even be aware of who they are talking to. In a stateless application, a client talks to anyone an it’s happy. Being stateful has lead to more complicated clients, IME. Looking at the DataStax Java Driver for Cassandra, it is incredibly complicated because it tracks who to talk to for different pieces of data. On top of that, stickiness in the face of failure adds complications. Where does the connection get rebalanced to? What happens when the machine comes back? What if the machine is flappy, will connections jump back and forth?
That being said, I think if someone has a framework like Orleans behind them, doing a lot of these things becomes easier, especially if you have a problem that benefits from statefullness.