Is stateless mode necessary before containerizing a monolithic application?

Question

In my team, we are maintaining a monolithic application that was started in 2003. It is written in Java and has seen several successive layers of technical changes, growing to a hefty 400k-line application.

Recent business strategies decided by the brass now require that we move to containers. The goal is mainly, if not solely, deployment across multiple platforms and cloud providers.

Since we have never done any similar migration, we went to a tech firm that is a partner of our chosen cloud provider.

They surveyed the application portfolio with our input, and they strongly suggested that we convert the application to a stateless mode. I can even say that they presented the statelessness of the application as a prerequisite for containerization.

As the manager of the development team, I fail to see why statelessness is such a hard requirement, when we know that there won't be any scaling up or down, but I must confess that my software architecture skills are no longer as sharp as they were, say two years ago.

Given that we can't suddenly stop from storing data in the application server sessions, I fear that we embark into a lot of changes to our legacy applications, including loss of functionality for our business users.

My question is why is "stateless" a requirement?

Answer 1

You seem to have most of the answers in your question.

The short answer to your question is "containerized application can be statefull". On the same note "You will not get many of the benefits of the containerization if your application is statefull".

As a manager, you should take a call and decide considering the cost and benefits.

Let's imagine your java (I presume web) application is statefull. And let's assume its maintaining the session data of the user in the application directly. Without using any thing like redis cache or persistence mechanism.

Now we could list various benefits of containerization and identify the benefits you will get for your statefull application.

Scale-ability: (no): As you already know, you will not be able to scale the application. If the first request (login) is served by instance A, the successive requests must be served by the same instance as state is only available in that instance.

Orchestration: (no): These days, it is fairly common to have many applications interacting with each other to meet the sophisticated business requirements. When you have fairly large number of containerized applications, you will find it difficult (expensive) to manage (monitor) these applications. A common solution for this problem is orchestration using tools like Kubernetes, Docker Swarm, etc... When you are managing applications by tools like kubernetes, the orchestration tool will take care of running the container, and it also has the ability to replace the container when it finds it unhealthy. This will not be possible in your case as you have a state in it and a newly spun up instance will not the state.

Isolation: (yes): One of the reasons for containerization is isolation. You want to build your application strapping all the dependencies that you need. This way you do not have much of difference between each deployment such as (dev, staging, production1, production2). This is a benefit you will be able to get while you containerize your statefull application.