STATEFUL Application Remediation — to be Cloud Native

Context:

While doing Application Modernization, if you are planning to make your application true cloud native, then just lift and shift is not the way. You should consider doing proper re-factoring/re-architecting your application to follow Twelve-Factor App principles to make your app true Cloud-Native.

Stateful vs Stateless application — quick refresher:

Just as a quick refresher ..

Challenge / Problem Statement:

Elastic cloud environments differ from traditional server configurations in that they have a variable number of servers based on traffic loads whereas traditional configurations had a fixed number of servers. When traffic volumes decline it is necessary to vaporize servers. In doing so, we would lose user sessions (essentially forcing a logout) unless we come up with a new strategy for session management.

Ideal target state:

In the modern day architecture, if the business use case supports, the ideal target state for any application should be stateless to become true cloud native running on any container platform or even in auto scaled EC2/VM platforms.

Sample reference diagram of using Token and cookie, making session stateless. Note: picture taken from “https://auth0.com
Reference deployment diagram of a typical stateless application.

Acceptable Target State: “Session/State Externalization”

During application cloud modernization, Many times it is not possible to rewrite the whole application, still the desired target state is pure cloud native app. In those cases we can follow a pattern called ”Session/State Externalization”, a.k.a “Distributed Session Management”.

  • Is coherent (consistent) across requests to multiple servers.
  • Survives server restarts and app deployments.
  • Doesn’t use local memory.
Sample deployment diagram of monolith stateful application with session externalization

Sample Code Snippet :

Code guide for AWS ElasticCache (Redis):

Short term workaround (but not recommended):

There could be scenarios due to complexity, timeline constraint, application knowledge gap, you are not able to make the Session/state management externalize, then below could be some short term work around, though not recommended as first option.

AWS EFS provisioner Architecture for k8s. note: pic taken from “https://www.padok.fr/
Sample architecture to use share EFS for state management across multiple pods

Conclusion :

To run a stateful application on a container platform, in the above sections we have discussed 3 options,

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Shankhabrata Chowdhury

Shankhabrata Chowdhury

Principal Architect — Digital Systems & Technology