The state of container-based cloud development

Most applications are stateful. Stateful is when streaming services remember where you left off in a movie even if you switch devices, or mobile applications store users’ preferences or recently opened files. For application-level cases, it’s the ability to recover from a session interruption, putting the users back to the place they left off, without loss of data.

We come from a stateful world. Stateful applications remember things about states, which is durable across sessions. The state data is stored within some nonvolatile mechanism, such as physical storage, including databases. 

Enter containers, with new challenges and opportunities regarding state retention. In the world of containers, we are taught to be stateless. In container design, including courses I’ve taught, the idea is that a container emerges as an instance, does what it’s programmed to do, and goes away without maintaining state.

If indeed it works on data from some external source, it’s handed the data by another process or service, returning the data to another process before being removed from memory. Still, no state maintained. 

The core issues are that containers, as invented years ago, just could not save state information. There was no notion of persistent storage, so maintaining state was impossible. We were taught early on that containers were for operations that did not require state retention.

Some people still argue the need for stateless when building container-based applications, contending that it’s the cleanest approach, and that thinking stateful means thinking in outmoded ways.

Copyright © 2020 IDG Communications, Inc.

Source link