Finding a digital transformation roadmap with containers

What containers do — and what they don’t do

Containers are a building block for the infrastructure you need to deploy applications. They offer several key advantages over older forms of infrastructure, such as virtual machines (VMs).

The main advantages of containers include:

• They start faster. Containers usually take a few seconds to start; VMs can take minutes.
• They scale better. When you need to add capacity to your containerized application, you simply spin up more containers (or let your orchestration tools do this automatically for you). This enables faster and easier scalability than environments built with VMs, which take a long time to duplicate.
• They are ideal for microservices. A container does not need to host a complete application. It can host just one part of it — a microservice. Using containers, it is easy to deploy multiple microservices in order to compose a complete application.
• They provide environment parity. A Docker container environment has very few configuration variables. This means that you can move containers between different Docker host servers or clusters without worrying that environment variable differences will cause an unexpected problem for your application. No matter the underlying server hardware or type of host OS or whether your containerized application is running in a testing or production environment, you can have a high degree of confidence that it will perform predictably.
• They consume fewer resources. An application running in a container does not require an entire guest OS to host it. For this reason, containers have less overhead. You can run more containers on a single server than you could VMs.

But containers can’t do everything you need while building a digital transformation roadmap. Here are their main limitations:

• They are tied to specific OS families. Although Docker supports both Windows and Linux natively, a container created to run using Docker on a Linux host server can’t run on Windows, or vice versa. In this sense, containers are less portable than VMs. Using VMware, a Linux guest VM could run on either a Windows or Linux host server, or vice versa. (Some other virtualization platforms, like Kernel-based Virtual Machine, only work on Linux hosts, but they can host Windows guests.)
• They may require applications to be refactored or rewritten. In many cases, you can’t simply take an existing application and drop it into a container in the way that you could take an existing host server and turn it into a VM. Your apps often need to be modified to run in containers. The amount of modification required varies depending on how your apps are designed and how you want them to run using containers.
• They are not good for GUI applications. Although it is technically possible to use containers to run applications that require a graphical interface, this is not practical in most situations.

Integrating containers into digital transformation strategies

Containers are not a cure-all for your legacy infrastructure woes. They can help with a digital transformation roadmap in some ways, but they are not the right solution for every type of legacy application or environment that you want to modernize.

To evaluate whether containers can help improve a particular application, process or project within your organization, ask yourself these questions:

• Can Docker support your workload? In some cases, Docker doesn’t work with certain types of applications at all. If your application requires a graphical interface, for example, Docker probably can’t support it well, as noted above.
• Can my host infrastructure support containers? Docker runs natively on any modern Linux distribution, as well as on Windows 10 and Windows Server 2016. Docker does not support other host OSes, however. If your host infrastructure is composed of, say, servers running Solaris, don’t migrate to Docker yet. (Oracle says there are plans to bring Docker to Solaris, but support has not materialized yet.)
• Will you need to refactor or rebuild your app to work with containers? If your application is already broken into microservices, it should be easy to port it to a Docker environment with only basic refactoring. If, on the other hand, you have a complex, monolithic application, you may need to rewrite it entirely in order to run it effectively inside containers. If this is the case, be sure you have the resources for the rewrite before you commit yourself to Docker.
• Which types of resource usage do I want to optimize? Containers can help make more efficient use of your on-premises or cloud-based compute and memory resources. This is great if you need to overhaul a front-end app, for example. Containers are not very useful for optimizing storage resources, however. A database will consume about the same amount of disk space whether it runs inside containers or not.
• How will you set up and manage your container environment? There are basically two ways to do this: first, by installing and managing Docker yourself on on-premises hardware or in cloud-based virtual servers, and second, by using a containers as a service (CaaS) platform. In the first case, you need to make sure your organization has the requisite expertise. In the second, you should evaluate the strengths and limitations of the CaaS platform you wish to use. Most CaaS platforms in the public cloud require you to use specific tools that you may or may not want to add to your technology stack.
• Will Docker provide more efficiencies than the cloud when it comes to my digital transformation roadmap? For some types of workloads, you’ll achieve better results by moving to cloud-based services than by adopting Docker. For example, if you have compute-intensive services within your application, you may want to take advantage of a serverless computing platform (like Amazon Web Services Lambda) to run them in a high-performance, cost-efficient way. Docker won’t be as effective in optimizing workloads like this.