Content area
Full text
Application container technology, like Docker Engine, provides standards based packaging and runtime management of the underlying application components.
Containers are fast to deploy and make efficient use of system resources. Using containers, developers get application portability and programmable image management. The operations team get standard runtime units of deployment and management.
However, with all the known benefits of application containers there is a common misperception that containers are ephemeral and so are only good for stateless microservices-style applications. And that it's not possible to containerize stateful applications. Let's dive in and see if this holds up:
Understanding application state
Application state is simply data needed by application components to do their job i.e. perform a task. All applications have state Software programming architectural patterns, paradigms and languages, essentially describe how to manage application behaviors (tasks, operations, etc.) and state (data).
Even microservices style applications have state! In a microservices style architecture, each service can have multiple instances and each service instance is designed to be stateless. What that means, is that a service instance does not store any data across operations. Hence being stateless, simply means that any service instance can retrieve all application state required to execute a behavior, from somewhere else. This is an important architectural constraint of microservices style applications, as it enables resiliency, elasticity, and allows any available service instance to execute any task.
Typically, application state is stored in a database, a cache, a file, or some other form of storage. And, any change in application state that needs to be remembered across operations must be written back to storage.
So, all applications have state, but an application component can be stateless if it cleanly separates behaviors from data, and can fetch data required to perform any behavior. But this seems like simply passing the problem to something else - how does the other component manage the state? That depends on the type of state we're discussing.
To answer that, let's consider the five types of state an application may have, and how we can deal with each one of these to containerize the application:
1.
Persistent state
2.
Configuration state
3.
Session state
4.
Connection state
5.
Cluster state
Containerization and persistent state
Persistent application state needs to...