When an application supports a business process that requires multiple steps to complete, every step needs to occur...
with an awareness of the overall process. This concept is known as context or state. And, to ensure that stateful apps can keep track of each step in a process, development teams need to enable state control -- a complicated endeavor that grows even more complex in cloud.
State control faces three challenges in cloud computing. First, the hosting locations for application components can vary, which means the performance of the connections that pass messages between those components also will vary.
Second, development teams can create copies of application components to process work in parallel, but each of these components has to separately maintain context. And third, an application component could fail, and if it can't be freely substituted for another component, resiliency will suffer.
While it's difficult to provide hard-and-fast recommendations on how to manage stateful apps in the cloud, there is one universal rule: Never save data within an application component as a program variable. If the component fails, that data is lost. And, if that component scales, the data might still be there, but the next processing event could be sent to the wrong hosting environment, where the data isn't available. For this reason, serverless platforms, like AWS Lambda, forbid internal data storage.
In addition to that rule, there are four broad ways to overcome state control challenges in cloud computing, all of which have their ups and downs.
Stateful load balancing
The first option is to use stateful load balancing to distribute application work. In this model, a load balancer maintains the state of a message within a sequence of messages.
There are probably a hundred or more stateful load-balancing products. However, since this approach presumes that your application components maintain state, don't use this technique for new applications. Instead, only retrofit older applications to support limited scalability and resilience.
Front-end state control
The second option is front-end state control. With this approach, the source of a message or an event within a transaction -- such as a graphical user interface (GUI) or mobile device -- maintains awareness of the overall transaction, as well as the place of each message in the sequence of that transaction. The source of the message also stores any intermediate results between processing stages. This way, each message contains everything that needs to be processed, so application components don't need any awareness of state.
The disadvantage of this approach is that it complicates the front-end GUI or mobile application that generates the messages in the first place, as it now needs to maintain state.
Back-end state control
The third method is back-end state control. In this approach, every application component that needs to be aware of where it is in a sequence of steps retrieves that information, and any intermediate data, from a database. This still means that the front-end message source has to identify a series of messages with a transaction ID or some unique code, but that's a simple addition.
The problem with back-end state control is that it can introduce significant processing delays while a component retrieves its state. The length of the delay varies, depending on where the component is in the cloud, relative to the database.
The fourth option to manage stateful apps in the cloud is through orchestration. Orchestration tools, such as AWS Step Functions, use a processing model to sequence steps and provide scheduling capabilities to ensure the completion of each step. These tools also store data from one step for use in another.
There are many approaches to orchestration as a means to state control, including distributed systems such as Amazon, Google and Microsoft and the tools they offer, as well as technologies like message buses and queues. The latter might not be as cloud-friendly as the former, but they do have the advantage of being applicable to both cloud and the data center.
Choose a management approach for stateful apps
How you overcome state control challenges in cloud computing should depend on your application. The big question you need to answer is how workloads arrive at your application components -- from which sources and in what context. Generally, developers design web and mobile applications with front-end processes based on web servers and representational state transfer. If teams can tune these environments to provide transaction IDs or sequence numbers to tie individual messages together, then the front-end state control mechanism is best.
If the front-end approach won't work because you have already written an application and cannot easily change it, consider the stateful load-balancing option. This method is particularly valuable if the applications are monolithic, rather than componentized, because you can apply it without making changes to the application.
For dynamic microservices and event-processing applications, the best strategy depends on the sources that feed your application components. Microservices that are shared among many applications have to rely on those applications to provide context or transaction IDs, which developers can then use to apply back-end state control. Just be careful that your state database is easily accessible from every hosting environment you use.
For event processing applications where front-end elements, such as a sensor, cannot provide context, orchestration is the only option.
Application design is an important overall consideration. Define your state control requirements in the development phase, or risk having no strategy when you deploy.