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.

Copyright © 2021 IDG Communications, Inc.