Will Software Containers Solve Everything?

Software containers are in vogue and Docker is all the rage. It will revolutionize the way we work. It will solve world hunger. Well not quite, but given all the hype you could be forgiven for thinking this. The technology is not even particularly new — it has existed in various forms before, as far back as mainframes. However, the idea of separate workloads that are managed individually is relatively new in Linux, Unix, and Windows.

Reasons Why People Think Containers Will Solve Everything

Containers are not just the natural evolution of virtualization, and they are much more than lightweight virtual machines. The architectures of Google, Facebook, and most other leading web-scale companies have all been built around this capability, so it is not hard to see why people are looking at this and reaching the conclusion containers are an easy solution for all of software’s problems.

When an application is architected as container-based or built on a container platform such as Docker or Kubernetes, its components become extremely portable and can be dynamically moved from one machine to another. Furthermore, dynamic scaling – more computer power when you need it and less when you don’t — is “built-in” and is a major step forward. Updating deployment processes, application maintenance, and operations processes are all simplified and easier to work with when an application is containerized.

In comparison to virtual machines, containers are extremely lightweight, and you could run roughly 17 containers on the same hardware required for just one or two virtual machines. If, for instance, you have a container that’s running a print service and you want to scale it up to service more requests, it is extremely quick and straightforward; just a single command line and the new process is ready to take on workloads and all the wiring (disk/network, etc.) is already done. By contrast, a virtual machine requires a longer setup time. Each one runs an operating system of its own and needs to be configured for storage and networking, before an application can even be installed on it. It’s easy to see why containers are so appealing to so many.

Reasons Why Containers Won’t Solve Everything

Here is the first thing you need to know about containers: You can’t just take your existing applications, put them in a container and get all these wonderful benefits. It simply isn’t possible to take large legacy apps and make them portable at the drop of a hat. This is a somewhat naïve view often initially held by certain enterprises before they get a deeper look at the technology. Don’t think that you can always easily containerize all your applications. If you don’t redesign the architecture of your applications, the effects of containerization will be at best restricted, and at worst poorer than your existing capabilities. The fact is containerization is an application architecture in and of itself. If your applications aren’t architected for containers, you are going to have to rebuild/rearchitect them, sometimes from scratch.

The best advice I can give is that you need to look at your application portfolio as you are modernizing it, and as part of your digital transformation, consider what the containers comprise as they enter the ecosystem. It isn’t as simple as just taking an Oracle E-Business application and sticking it onto a container. It would still be an old app with a lot of complex processes, dependencies and scalability bottlenecks. For example, auto-scaling won’t work and deployment is still going to require the same complexity it always did. Ultimately, if you just think of, or treat, containers as VMs that’s what you’ll get and that’s nothing new!

If you want to reap the rewards, you are going to have to rearchitect and rewrite the applications. Despite the extensive workload and man-hours, it be may be worth the effort and cost because some modern-day requirements around agility, scalability and omni-channel delivery can only be met using this architecture. But you will need to design a completely new architecture for your application, address security deployment and build the teams to support it.

Enterprises are right to be looking at containerization and a lot of new development is going into it. However, if you are thinking about your entire ecosystem then break it down and analyze it on an application-by-application perspective, and build a roadmap which is in line with your digital transformation goals and business priorities. In each instance ask, would the application fit a redesign into container architecture and would that work? What are the benefits I will get from this?

So What Are We Trying to Say?

Containers are great and a lot of the hype is justified, especially given the advancements of container technology like Docker, Kubernetes, and others which make it so much more approachable to enterprises. Containers are also the most natural way to develop cloud-based applications.

However, the truth is containerization is no panacea, and there is probably going to be a world of containers and non-containers side by side for the foreseeable future. Therefore, you want to orchestrate a toolchain that includes them, but not at the expense of everything else.  It is also very important to remember that since containers are not about to replace all of our other existing infrastructure and architecture anytime soon, they are ultimately yet another layer that needs to be managed, integrated and maintained within the IT toolbox.