5

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?

Improve this question
1
  • 2
    Did your partner tech firm say why the application should be made stateless? Any of us can guess, but surely the company that surveyed the application must have had some reason for the recommendation, and if you paid for their advice then they should definitely explain the reasoning.
    – Dan Wilson
    Oct 1, 2019 at 15:54

1 Answer 1

Reset to default
9

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.

Improve this answer
3
  • 1
    I really like this answer. The one thing I would add is you can do the stateless conversion incrementally. Making two or three services stateless that will benefit from it most, while the rest are stateful, is a lot better than having zero stateless services because you can't afford to convert all of them yet.
    – Karl Bielefeldt
    Oct 1, 2019 at 16:32
  • @Karl that is a very true statement. A divide and conquer approach that migrates each service over seamlessly would do it. You could even use a DNS switch to test out the stateless variant of each service in production and then rollback to the state fly version of the service should any unforeseen regression or degradation in performance arise.
    – A-Dubb
    Oct 1, 2019 at 20:29
  • I agree with @karl with his strategy to get the services to become state less. Doing all at once would be a strict no for most businesses
    – Nachiappan Kumarappan
    Oct 6, 2019 at 13:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.