Why loosely coupled state in public clouds is better

State retention has been debated in the world of development for years. Moreover, we are always looking for ways to do it better with fewer resources.

The use of public clouds basically changes the consumption model for storage, compute, databases, and development, but does not change the need to maintain state. Traditional approaches to state retention have worked just fine in the cloud, but are there more efficient ways to maintain state, perhaps even across applications?

Stateful applications are able to remember things about state, which is durable across sessions. For application-level use cases, it’s the capability of recovering from a session interruption, putting the users back where they left off without loss of data. The value is the applications are aware of state, and state is durable across patterns of interaction, either by humans or machine.

Some public cloud providers, such as AWS, have features that deal with state specifically. AWS provides the cloud-native service Step Functions, which is based on state machines and tasks and is designed to work with the AWS Lambda serverless development systems. Using Step Functions, a task is a state in a workflow or a single unit of work that another AWS service performs. This ensures that your application runs in order and as expected.

Other services in other clouds do similar things. Some are based on traditional development approaches; some are bound to a specific service such as Step Functions. You can find many PhD dissertations on state retention techniques and technology, as well as numerous articles on the best way to keep track of state, from Cobol to Node.JS. 

I’ve been finding that most mechanisms leveraged to maintain state are more tightly than loosely coupled. The trend is to move to a state retention approach and mechanism that are more loosely coupled, meaning that there is only a limited dependency between the applications that need to maintain state and the mechanism that actually does state retention.

In the cloud, loosely coupled state retention becomes important for a few reasons:

• If you’re building custom state retention mechanisms in each application, you’re typically reinventing the wheel every time.
• Applications that maintain their own state tightly coupled typically leverage more resources and thus push a larger cloud bill at the end of the month.
• There is an emerging need to retain state between applications, considering that many applications work together now, either intra- or intercloud.

The good news is that loosely coupled state retention is actually easy to do, considering that we’re taking a few new approaches. First, the state retention will occur outside of the application itself. Second, although applications are dependent on state retention mechanisms to function properly (at least in a stateful mode), they are not tightly coupled. 

How do you do this? A few options include leveraging some type of database or other storage device that’s able to provide full rollback and roll-forward recovery, or maintaining state using a data-oriented service or microservice accessible from any applications that need state. This means that you’ll be able to maintain state between applications, as well as store session data for transactional or analytical use later.

Of course, depending on what tools you’re developing with or the platform you’re deploying on, they may already have these types of loosely coupled and share-state retention mechanisms that you can use. Or you can look for a third-party product.

The point I’m attempting to make is that when building and/or deploying applications to the public clouds, decoupled state retention is a best practice. It doesn’t take a great deal of effort, it will make your applications much more useful, and it will reduce cloud costs.