Do you want to migrate from VM to Container?

Containerizing your application is as simple as writing scripts and steps. However, if you have existing systems/applications and you’re trying to migrate them to containers, it may not be working well as you expect.

Some cloud or virtual machine service providers provide containerization as a service, for instance, https://aws.amazon.com/app2container/.

In theory, to containerize your existing application, there will be strategical high-level steps below.

Strategical high-level steps for containerizing the existing application

1. Preparation: Check if you can decompose your application functions into different parts. And identify any dependencies & difficulties with doing containerize technically.
2. Requirement: Break down your applications, do an architectural assessment, and confirm any organizational policies and design patterns.
3. Container Design: The microservices’ structure may bring more complex designs to your applications, so you should understand how it will be scaleable and what dependencies between services. Plus, the containerized environment is definitely different from what you originally have, you should think about how you do set up the monitoring system and secure environments.
4. Containerizing
5. Testing & Verification

How do you determine whether your application can go in containerized env or not?

First, easy determination, if your application is stateless, it will be easy to move the application to the container. The stateless means in the application the server/application doesn’t hold (store) final status. For instance, those are the API gateway, processing the data (input-output), and backend system without the database.

In many forums, database containerization is quite debatable, the right question will be “can we containerize the database?” not “should we”. (Good article you can refer to https://www.rtinsights.com/container-boom-should-databases-be-containerized/ and https://www3.dbmaestro.com/blog/the-pros-and-cons-of-database-containerization)

Secondly, you can ask whether your service requires very specialized resources like principal DBA. This means your application is heavily relying on certain resources, and the very high-cost resources can’t be co-located in multiple microservices teams. (Otherwise, it’s too expensive structure tobe)

Lastly, your org structure (application) is flexible enough and well-distributed? If there are 100 developers, 2 QE, 3 BA, how do you expect to have the separate teams per the microservice? Do you really expect the exact same structure to manage your changed application?

How to Break down your applications

Here are some common principles on breaking applications for containerization.

• Independently run by others.
• This is not a puzzle game, more pieces don’t mean better structure.
• It needs to reflect your LOB (line of business); your company doesn’t want to invest in the thing spending a lot of money but a very short return.