Pick up stateless software precepts for modern app design
Change and state are complex interrelated concepts that shape how an application performs its tasks. Learn the meaning of state, mutability and change as they relate to app design.
State, and the concept of change, profoundly affect the way in which a development team architects and codes an application.
Immutable and stateless software design enable developers to craft resilient, highly scalable code objects. While the two concepts offer similar benefits, they are quite different, and IT professionals must avoid confusing or conflating these ideas.
Start with state
Most traditional software runs on stateful code, which relies on data from previous events to process current actions or transactions. Imagine an application that needs to perform a mathematical process on data the stateful code relies on, or on information contained in the code. That code must enter a certain state -- i.e., the data must be initialized -- before the computer can invoke the mathematical process. If the stateful code crashes or the application restarts, it can lose the results of the process; stateful code carries a risk of data loss.
By comparison, stateless software code does not rely on past operations, actions or transactions to carry out its purpose. The software performs each operation as if for the first time. In the aforementioned mathematical process, if the application receives data from another function, that code would be stateless because it does not need to impose a certain state before the mathematical process starts. If the stateless software crashes or unexpectedly restarts, the process simply repeats and there is no data loss. One quintessential example of stateless operation is HTTP, in which each request does not depend on previous requests. If a request fails or returns an error, the request simply repeats.
The importance of change
Modern software design largely relies on the creation and management of software objects, which are combinations of functions, variables and data structures.
The software often instances, or refers to, objects as part of its design. A mutable change occurs when an object is instanced in a way that can be altered; when the object is instanced in a way that cannot be altered, that instance is immutable. One example of an immutable object is a string of text that returns an error message.
How state and change relate
The semantics make it difficult for software designers and developers to easily parse these two terms. Generally, a stateless object is immutable because there is nothing within it that can be changed. A stateless object or application simply manages interactions.
Ultimately, stateless objects are immutable, but that which is immutable is not necessarily stateless.
Comparatively, a stateful object can be a mutable or immutable object. In the latter case, that stateful object can still be made immutable, even though data can define an underlying state.
Ultimately, stateless objects are immutable, but that which is immutable is not necessarily stateless.
Stateless software design is gaining popularity. Increasingly, enterprises are shifting to resilient, scalable and modular architectures, such as microservices deployed in containers. In this model, if a microservice fails, load balancing can ensure continued operation, or the microservice can restart with no loss of transactions or data.
