When to use containers in the cloud, and when not to
Containers are the newest trend in software. They provide developers with a way to package an application and its dependencies inside a “software container” that can run on almost any machine.
In fact, portability is really the main selling point for this technology. The greatest benefit for developers is the ability to write applications that exist in containers, and then move those containers from cloud platform to cloud platform without having to rewrite the applications.
Use of containers has taken off in the past few years. During his keynote address at DockerCon, an industry event that took place in June, Docker CEO Ben Golub noted that there are currently 460,000 “Dockerized” applications, representing growth of 3,100% over the past two years. Indeed, Docker is supported by a large and fast-growing community of contributors and users. For example, there are currently 125,000 Docker Meetup members worldwide.
However, the rapid growth and adoption of a technology does not mean it’s right for your enterprise. There are advantages and disadvantages to any technology or technology standard, and containers are no exception. Looking specifically at cloud-based use of containers, it’s worth examining where containers are a fit, where they are not, and the value they can bring to your enterprise.
The value of containers
A key advantage to containers is their ability to make your applications portable. This advantage comes at a price, however: the cost of rewriting portions or all of your applications to take advantage of containers, as well as the risk involved with moving to any new technology.
Another important consideration is timing. While containers may not fit your strategy now, they may fit two years from now. Of course, by that time the technology will be generations ahead, and you’ll have the advantage of learning from the successes and failures of early adopters.
You should also understand that containers are really an ecosystem, not a single standard. While many people use the Docker brand name, it’s more correct to call them what they are: containers or container technology, and various products created specifically for containers.
The core question is the viability of this ecosystem as a possible “platform” for existing and new applications. Here are a number of reasons why you might want to leverage container technology:
- Portable deployment of applications. By using containers, you’re abstracted from the complexities of the underlying platform.
- An emphasis on business value rather than technology. With containers, you focus on the functionality of the application, not the platform the application runs on.
- The ability to reuse services that may span many applications.
- Shareability. There is a service on the open Internet where you can obtain existing containers that you can use as is or modify for a specific need.
- The ability to track changes and do revision control at the container level.
- A growing ecosystem of tools for containers.
Do you need portability?
Portability should be front and center in terms of how you're looking to leverage containers. It can bring great value to the average development manager, CTO, CIO, or IT leader facing a massive migration to public clouds run by the likes of Amazon Web Services, IBM, Google, and Microsoft. Sometimes you'll use just one of those providers, sometimes two, and sometimes all four.
As you modify applications to take better advantage of features that are found in individual public clouds, you do so at the expense of portability. For example, you typically can’t take full advantage of a public cloud platform's native features if you write apps that can run on most other public clouds. Conversely, if you fully leverage the features of the host cloud, you give up portability.
Containers promise portability nirvana for cloud-based platforms. However, you'll want to consider the disadvantages of containers for both existing and new applications. These include:
- Lack of support for “traditional” programming languages. If your systems are 20-plus years old and don’t use today’s popular programming languages, you’ll find that moving to containers is a bit difficult. Oftentimes, there is no language analog for containers. If that’s the case, containers are not for you. If your application is written in Fortran or Cobol, containers are likely not a fit.
- Complexity of leveraging data. If your applications are tightly coupled to their data, containers can be problematic. While you can certainly do data management from and within containers, it’s a complex process to set up, even for net new applications. If you’re “containerizing” an existing system, moving to containers will require major surgery that may not pass a cost-risk analysis.
Finding the right fit
So, when do containers fit, and when do they not? Here are five guidelines to consider:
- Containers may be unnecessary if your applications aren't likely to move from cloud to cloud.
- If your apps require a significant rewrite to leverage containers, the cost of moving to containers could outweigh any benefits.
- Containers may not be a good fit if your apps are tightly coupled to their data, or if data management is a key focus of your application.
- If you’re moving applications from legacy systems, you will probably find there are no language analogs within today's containers.
- If your application requirements fall beyond the abilities of containers—such as needing direct access to an IoT device that can be reached only through a native platform—then you should not leverage containers.
The path to containers is not a slam-dunk. That said, enterprise IT departments have a tendency to chase the latest shiny objects, and containers are rather shiny these days. Without a good dose of realistic expectations, many will find that the benefits they expected to find are not there at all.
Containers: Lessons for leaders
- A major advantage of containers is their ability to make your applications portable.
- Containers provide you with the ability to reuse services that may span many applications.
- If your applications are tightly coupled to their data, containers can be problematic.
- Containers may be unnecessary if your applications are unlikely to move from cloud to cloud.