Moving from VMs to a container-based enterprise architecture

As businesses continue to modernise their server estate and move towards a cloud-native architecture, one of the biggest challenges they face is what to do with their core business applications that cannot easily be re-hosted without significant risk and disruption. 

Enterprises previously virtualised their server estates, allowing them to run existing applications on modern hardware. If they needed an additional server, they could have one up and running in a few clicks. And, if it broke, they just deleted it and started again. 

Virtual servers evolved into cloud servers, where companies rented virtual machines (VMs), and we are now at a point where enterprises are moving to a container-based environment. 

Unlike VMs, containers share the underlying operating system (OS) and kernel, which means a single OS environment can support multiple containers. Put simply, containers can be seen as virtualisation at the process (or application) level, rather than at the OS level.

The question I am often asked is how best to migrate applications from a VM environment to containers? This is a very important topic, as every customer is trying to build a Kubernetes environment, and the ways to do it can seem complex. However, there is a range of methods, tools and best practice available for them to use. 

The first thing customers looking to containerise their VM stack should do is create a clear migration plan – breaking the migration into steps, beginning with the most stable applications first, for example their website, and leaving the more complex applications until the container stack is more mature.  

Then it is a case of looking at the best way to move from VMs to containers. There are currently three main ways to do this. The first is to use what is called ‘lift and shift’, which involves moving the entire application from a VM and running it in a single container, without making any changes to the application. 

This is the fastest way to move to a container-based environment, as the container is configured in much the same way as the VM. This method doesn’t deliver the full benefits of a container-based environment, as it is simply moving a configuration from a VM to a container. However, using “refactoring” – the second method of migration – can help.  

Refactoring is where you change the code and structure of an application without changing its features or functions. This is done by creating smaller processes that can be deployed in separate containers, without altering the business logic. This allows enterprises to deliver real benefits from using a container-based environment, while the application will be easier to maintain and more scalable for future needs. 

The final approach is “rearchitecting”, which is where an application is completely rewritten, and where enterprises can make the shift from objects to microservices – from a unified app to a complex structure of services that work together. Microservices give complete control over an application and how it is deployed, which offers enterprises a way to really “turbocharge” applications.  

In our experience, these migrations can be done with existing teams. However, they will need to get to grips with the new container technology to understand how the different architecture works, which may require additional support from the likes of site reliability engineers.

Migrating to a container-based environment may present challenges, but if done correctly, it will deliver more reliable and scalable applications, as well as support the enterprise more effectively and efficiently, while reducing costs.

Lei Zhang is tech lead and engineering manager of Alibaba’s Cloud Native Application Management System, Alibaba Cloud Intelligence and a member of the technical oversight committee at the Cloud Native Computing Foundation.