You are here

You've heard the benefits of containers, now understand the challenges

public://pictures/davidl.jpg
David Linthicum, Chief Cloud Strategy Officer, Deloitte Consulting

Using containers in the cloud makes portability simple and easy. At least, that's the story being told to the cloud application development masses who want to quickly adopt containers. But there's another side to this story.

It takes some knowledge of the processes and enabling technology to make cloud-to-cloud migration using containers a lower-effort and lower-risk affair. Also, the required skills and best practices aren't as pervasive as they should be. Enterprises are struggling to catch up.

Here's how to use containers with heterogeneous cloud migration in mind, including how to define the proper processes, the right tools, and what you can expect in terms of real-world results.

[ Digital transformation can be a costly failure without proper controls. Find out how IT4IT value streams can help in this Webinar. ]

The good ...and the bad

Docker set the early standard in container software. Its dozen or so rivals include Warden, LXD, and CoreOS, according to research firm IDC. Many container vendors are refining competing versions of container orchestration software, the layer of programming that helps containers knit themselves together to form business solutions. Kubernetes is the early front-runner in the container orchestration software arena.

We don't want to get too far in the weeds here, since so many other sources are available that describe the inner workings of containers. In short, containers break up apps into smaller packages of code, each bundled with all the basic system software that apps need to operate independently of whichever server plays host.

Cloud portability is the selling point: containers typically mean that programmers won't have to rewrite the code for each new operating system and cloud platform. What's more, applications continue to evolve their focus from the narrow, such as a desktop PC, to the wide, such as a cloud that can serve millions of users on a wide variety of mobile and stationary devices. Using containers allows those applications to scale, as well as setting a clear path between source and target platforms. Moving containers from one cloud provider to another is as simple as downloading them onto the new servers.

Sound good? You bet. But, with all the upsides, there are a few downsides to consider as well. It's time to put aside the novelty of containers for now, and focus on the limitations and impediments related to using containers in public and private clouds.

[ Looking to bring innovation into your enterprise? Learn from others' Enterprise Service Management (ESM) implementations—and get recommendations for deployment. ]

Container security boundaries introduce risks

Containers have security-related limitations when it comes to security, and you need to understand those limitations before you build applications that use them. For the most part, security admins inside of enterprises don't yet "get" containers, and they need to understand them more fully before you make use of this technology.

Containers in the cloud don't have the same security boundaries as virtual machines (VMs). If hackers find a weak point in the underlying operating system, they can exploit that weakness to gain access to the containers as well. Of course, they can also do the reverse—exploit the container and gain access to the underlying server. Either way, your container is compromised, including a container or containers that you move from on-premise to cloud, or cloud to cloud.

Another problem with containers is the container creation process. If an organization creates its own container, it will only be as secure as that organization's state of security. If the existing staff is clueless about container security, chances are the containers they create won't live up to the security levels that may be required to port container-based applications to public or private cloud security standards. Moreover, if the organization leverages containers from public repositories, they're trusting that the containers were created with security in mind at the point of origin. If you want to leverage containers from public repositories, you should look for those are signed by the Docker Content Trust system to ensure that you're downloading a legitimate container.

In terms of security, containers may also be weaker because they share an OS kernel and components. They also require a deep level of authorization (usually root access in Linux environments) in order to run in the first place. Thus, attacks have a much greater potential to carry down into an underlying OS and over into other containers.

We've yet to see major breaches, but as hackers become smarter and more knowledgeable about using containers, these sorts of attacks will become commonplace, and most organizations are ill-prepared. So, in the pursuit of cloud portability using containers, we could very well be making our containerized applications more vulnerable.

Some applications aren't suited to containers

Not all applications are right for containers. Indeed, containers may make simple applications more complex. Building and deploying applications that use containers might feel cool, but it could be a waste of time.

When looking at containers in the cloud, think about the types of applications you're looking to create, and whether you need to use containers to support portability. Keep in mind that containers are very good at microservices-type application development and deployment, because you can link containers together to form a cohesive application. The idea is to scale the application through distribution, and only launch container instances for the part of the application that needs to support the increased processing load.

The issue, however, is that all applications won't benefit from containerization. Some cloud applications should be designed to be monolithic. For example, if they don't need to scale, then breaking them up into a series of containers will only make the application more complex, and could even hinder portability, considering the number of moving parts that have to be bundled together. In these cases, containers place limitations on the workloads, and they may even place limitations on the ability to port the application from cloud to cloud or on-premise to cloud. Organizations are still playing with different uses for containers. As businesses progress through more projects, best practices will continue to emerge.

Sometimes you need VMs, not containers

When considering portability, you should consider containers, but also think about the tradeoffs beween using containers versus VMs. VMs are self-contained. Each VM includes a unique operating system (OS), drivers, and application components. You can also migrate VMs to any other system, as long as a compatible hypervisor is available.

Containers are a different animal. They run on top of the physical OS, sharing much of the underlying OS kernel, along with many libraries and binaries. Thus, they're a bit more coupled to the OS, considering the number of dependencies that most container developers will build into the containerized applications. These dependencies can limit portability between clouds. For instance, Linux containers under Docker can't run on current versions of Windows Server.

It's easy to create a container mess in the cloud

Another issue in moving containers to the cloud is the huge mess they can make. Containers can be launched at a rapid rate, which is the advantage of using them. However, it's also possible to consume more cloud resources than needed without understanding that you're doing so.

You should always have an orderly shutdown of containers no longer in use, but as developers launch container-based applications, some forget to go back later to scale the number of containers, and the resources remain locked until they do so. In the public cloud space, this could cost you as much as $50,000 per month for cloud-based resources that deliver no benefit to the business.

Paving a path forward

The path to cloud portability will be paved by containers—that much is clear. But containers are no panacea for cloud portability. There are limitations when it comes to security, application types, deployment, and so on. Fortunately, all major public and private cloud providers are container friendly. With each release of cloud services, cloud developers gain more reasons to leverage containers for portable application development in the cloud.

In addition to the tips above, consider these best practices before you embark on building new applications or move existing applications to containers:

  • Test, test, test. The only way you're going to learn if containers will work for you is to build test applications. That means replicating real-world use, including containerization of real workloads. Learn all you can before you go to production.
  • Consider the architecture. Using containers in the cloud means more architecture and planning than ever before. The ability to limit dependencies, scale efficiently, and replicate soundly will pay huge dividends as you deploy the application. This includes the management of resources used, application performance, reliability, and portability.
  • Know your limitations. Try out a few applications. See how difficult it is to build or rebuild applications for containers and how portability really works. You'll find that containers have positives and negatives, just like any other technology.

The question isn't whether or not containers are in your future; it's clear that they are. The question is how to best make use of the technology. Most people use containers for portability and to protect themselves from cloud computing vendor lock-in. As long as you understand that nothing's perfect, and that there's a lot to learn, you'll do just fine.

[ Get Report: The Top 20 Continuous Application Performance Management Companies ]