The task of keeping information can be very challenging and stateless computing paradigm suggests retaining no information. That’s why the stateless computing is on the rise. Being free of the state makes it easy to write, debug and test a program. The stateless computing paradigm can be applied or used in different layers of the software development. In this post, I will focus on the parts I’m familiar with and try to discuss why it’s advantageous to have no state. What’s the difference between stateless and stateful in a very simple example?
Stateless vs. Stateful
//stateful : the increment function keeps the state and refers an inner variable i
const increment = _ = (this.i = (this.i || 0) + 1);
//stateless: the increment function doesn't keep any state and just calculates the new value
const increment = (i) = i + 1;
Testing and Debugging
If you don’t have a state then the only thing that affects the return value of a procedure is its arguments. By feeding different arguments, you can test various behaviors of the procedure easily. If you validate the behavior correctly, you would be much more confident as you don’t change/keep the state at all.
If you encounter a bug, you can easily reproduce it by feeding the arguments that caused the bug. Once found out the issue, you can just add those arguments in the tests and verify expected behavior continuously.
Concurrency
The mutable state is the hardest part of concurrent programming. If you don’t have a state at all, you don’t need to worry about multiple threads changing the state of a shared value. Removing mutable state eliminates concepts like locks, barriers, and semaphores. Also, you don’t need to worry about race conditions and deadlocks anymore.
Scaling
If you don’t have any state, you can basically scale up and down as much as you want. Thus, you don’t need to have an active server at all. This brings us to another hot topic, serverless architectures. In the serverless world, you provide a function or set of functions as a service. Functions are called based on events. If you have 1m events, then you simply call functions 1m time. You don’t worry about the number of calls as you simply rely on the 3rd party platform. You only pay for the time you are using the 3rd party platform.
Consensus
If your application doesn’t have a state, then you probably don’t need consensus on anything. By getting rid of any distributed state, you are no longer concerned about distributed locks, the reliability of the components and distributed state machines. Again, you can discard a class of problems here. If one of your nodes goes down, you aren’t concerned because spinning up another one is just enough.
Operational Cost
Both in-house or 3rd party solutions can scale the needs of your service dramatically easily. The only thing is to add more computation power when it becomes necessary. The number of components needed for the service will decrease as well since we would throw away any component that’s used for keeping the state. Note that, the new stateless architecture might require a different strategy on keeping state.
Stateful world is still out there
We went over some of the advantages of stateless applications; however, we still need the state. This is where stateful backend services play their role. The most well-known stateful backend services are databases and file systems. In the era of cloud computing, both these services can be provided by a 3rd party platform. Thus, you don’t need to worry about the loss of data, recovery etc. On the other hand, if you host stateful service on your own, there is an operational cost of having them up and running. I won’t go into detail of weird scenarios that you need to tackle for a distributed stateful application but it’s interesting.
Fault-Tolerant Stateful
This is my own term. I guess there’s a much better wording for this but let me explain. A software is fault tolerant stateful if restart won’t have any effect on the system. The system should recreate the state with a fully stateful service. There shouldn’t be any loss or restart shouldn’t disturb the service. One example for this is in-memory data structures where these structures are saved into a database at critical points. When the application is restarted it can recreate the data structures from the database. If your application needs to keep state, the above mechanism helps to self-heal.
All in all, stateful applications are becoming popular for a reason. They are easy to reason, maintain and support. Stateless applications though require a stateful backend service but worrying a little less when developing helps a lot. In the case of stateful applications, there are many edge case scenarios to deal with. This happens too much if you actually implement the stateful service yourself. In consequence, coping with the state is tough. Dismissing the state simplifies the development lifecycle.