Service State Management (Erl, Naserpour)
How can stateful cloud services be optimized to minimize runtime IT resource consumption?
ProblemA cloud service designed to place significant data into memory for prolonged periods can consume excessive amounts of runtime processing, thereby unreasonably taxing the overall cloud infrastructure and imposing additional usage costs on cloud consumers.
SolutionThe cloud service is designed to integrate with a state management system allowing it to defer state data at runtime, when necessary, so as to minimize its IT resource consumption.
ApplicationA state management system requires a cloud storage device capable of temporarily holding and releasing state data exchanged by the cloud service. The cloud service itself needs to be equipped with logic to determine when and how to release and retrieve state data.
MechanismsCloud Storage Device, Cloud Usage Monitor, Hypervisor, Pay-Per-Use Monitor, Resource Replication, State Management Database, Virtual Server
Compound PatternsBurst In, Burst Out to Private Cloud, Burst Out to Public Cloud, Elastic Environment, Infrastructure-as-a-Service (IaaS), Multitenant Environment, Platform-as-a-Service (PaaS), Private Cloud, Public Cloud, Resilient Environment, Software-as-a-Service (SaaS)
A cloud service may need to carry out functions that require prolonged processing across underlying IT resources or other cloud-based services that are invoked. While waiting for responses from IT resources or other cloud services, the primary cloud service may be unnecessarily consuming memory via the temporary storage of state data. The cloud service may also be storing RAM or CPU data, which represents memory consumed by the virtual server instance itself.
While retaining state data in memory, the cloud service is considered to be in a stateful condition. When stateful, the cloud service is actively consuming infrastructure-level resources that could otherwise be shared within the cloud. Furthermore, the cloud consumer may be charged usage fees for the on-going consumption of these resources.
The cloud service architecture is designed to incorporate the use of the state management database mechanism, a specialized repository used for the temporary deferral of state data. This solution applies to custom cloud services that automate business tasks, as well as cloud service products (such as those based on cloud delivery models) offered by cloud providers.
State information can be programmatically deferred by executing conditional logic within the cloud service, or it can be manually deferred by a cloud resource administrator using a usage and administration portal.
Figure 1 - A sample scenario in which cloud service state data is manually deferred and restored.
- The cloud consumer uses the usage and administration portal to request that the cloud service status be paused and deferred.
- The request is forwarded to an API-enabled system that interacts with the state management database mechanism.
- The system reads the service status.
- The system saves it to the state management database.
- The cloud consumer requests that the service to be reactivated via the usage and administration portal.
- The cloud consumer request is forwarded to the system.
- The system interacts with state management database to retrieve the status of the cloud service.
- The cloud service status is restored and cloud service activity resumes.
Note that resuming a paused cloud service may trigger a resource constraint, depending on long the state data was deferred and how the IT resources required by the stateful cloud service are managed while the cloud service is stateless.
NIST Reference Architecture Mapping
This pattern relates to the highlighted parts of the NIST reference architecture, as follows: