The state of container technology in 2017 is strong. Indeed, the success of application containers in the enterprise should come as no surprise, given the current adoption trends and all of the hype around the technology. According to a 451 Research study completed in May of last year, 14% of IT organizations surveyed were leveraging Docker containers in production, while nearly 31% were piloting or evaluating application containers. But are containers living up to the hype? And how should you be responding right now?
If yours is like most enterprises, you’ve already made an investment. Enterprises went on to spend $762 million on application container technologies in 2016, and that spending is accelerating: By 2020, application container revenue growth will reach $2.7 billion, according to 451 Research, an expansion that represents a 40% compound annual growth rate.
The container space in a nutshell.
What’s important to know is that containers can be separated into two buckets: the primitive container runtime, which is the basic building block of containers that determines how the containers will be defined, and the container tools that perform higher-level functions such as container management and orchestration, which are needed for large-scale container deployments.
Container runtimes include those from Docker, the 800-pound gorilla in this space, as well as CoreOS’ rckt and Ubunto’s LXC. The orchestration layers are also household names now, with the bigger players including Google’s Kubernetes, Apache Mesos, and Docker’s Swarm. Plus, hundreds of startups offer add-ons for Docker that handle such things as data management, security, and monitoring. The biggest difference from the state of containers last year is that the container ecosystem is more robust.
The industry has also coalesced around the Open Container Initiative’s (OCI) container runtime standard. The focus now is on moving up the stack to address such things as container management.
While containers may not be living up to all of the hyperbole out there, the capabilities have evolved—and you need to be taking full advantage.
5 container actions for 2017
So what is one to do in 2017 when it comes to adopting and optimizing the use of containers in the enterprise? Here are the five actions every organization should be taking now to either get ready for containers or to push its existing container strategy forward.
Action 1: Define which applications you can successfully move to containers.
The problem for most enterprises when it comes to considering how to use containers is that they have no idea what apps they should containerize. This is where the hype around containers gets separated from the reality. Many developers understand that application containers are the way to go, but in many organizations, neither developers not IT operations managers have a clue as to how they should be used in enterprise development practices.
The answer is to focus on your application patterns and determine which applications are a fit for containers. Legacy applications seem like low-hanging fruit for development shops, but they are unlikely to be a fit for containers.
There are two key considerations for determining when existing applications are compatible with containers:
- The data and the application must be loosely coupled. Application logic that’s bound to the data is difficult to decouple in a way that will work with the distributed nature of containers. For instance, you must place the application in one container and the data in another, or perhaps in the native platform and not within containers. If your applications can’t be easily decoupled from the data, they can’t be containerized.
- You must be able to break apart the application. That is, you need to separate the application components so that each runs within its own container instance. If you can’t do that easily, then the components won’t be a fit with containers. You can run all sorts of larger monolithic applications within containers—even legacy ERP software. But understand that, by doing so, you’re not taking advantage of the distributed capabilities of containers, and so you won’t derive value from using them.
In contrast, applications that will work within containers include those that leverage a decoupled architecture and more service-oriented apps.
While a few applications will fit the requirements defined above, net new applications that can be purpose-built for containers will provide you with the greatest chances of success.
Action 2: Define the management and orchestration layers.
This should be your focus for containerization projects, given that the runtime layer has been standardized. Plenty of other articles has been written about the ins and outs of container orchestration. However, the elevator pitch on orchestration engines is that they offer scheduling and container cluster management and enable containers to scale—something that the runtime layers by themselves can’t do.
Orchestration layers such as Google’s Kubernetes, Docker’s Swarm, and Apache Mesos each have their own pluses and minuses. Generally speaking, the consensus is to go with Kubernetes, either directly from Google or by using a derivative product hosted in the cloud. Then again, you may need the extra horsepower that Mesos offers, or you might want to use the Docker brand exclusively in your stack. It’s impossible to provide a single recommendation since you need to factor your unique requirements into your decision. In the final analysis, the technology that others use may not be the right choice.
Also consider the cloud-based alternatives. The Amazon EC2 Container Service (ECS) is a container management service that supports Docker containers, and you can run your applications on a managed cluster of Amazon EC2 instances.
Microsoft’s Azure Container Service optimizes the configuration of popular open-source tools and technologies specifically for Azure. You can use Mesos, Kubernetes, or Docker Swarm.
Think of it this way: AWS provides you with a single native service, while Microsoft offers a buffet of open-source solutions. All cloud-based alternatives have proved themselves in implementations, so it’s just a matter of figuring out which best meets your needs.
But you may not need to restrict yourself to one choice. It’s common for enterprises to leverage two or three different container orchestration tools around a single container runtime.
Action 3: Define your container security.
Container security is about reducing the attack surface, which means preventing code with vulnerabilities from getting into your containers in the first place. However, containers have specific structures and methods of operation that require specific types of services, including security.
For example, the underlying shared kernel architecture for your containers needs security services before you can secure the host. That means maintaining standard container configurations and profiles—which makes securing containers more complicated than most people realize.
Many people compare container security to that of virtual machine environments, where a hypervisor provides most of the control. With containers, however, security is more primitive, because anything that has access to the kernel root account can see all of the containers that share the kernel. Security staff can harden the kernels and hosts, but the approaches and technologies are not as mature, nor as repeatable, as most other state-of-the-art security approaches and tools.
The native Docker runtime has made significant improvements over the last year, including the ability to invoke out-of-the-box Seccomp (secure computing mode) profiles. These container profiles can disable 52 system calls by default. But you still have 313 system calls on x64 machines. Do the math; that leaves 261 system calls still open for attack.
The good news is that many upcoming tools work with containers. So, despite all of these vulnerabilities and the lack of security of many of the native container runtimes, you can cobble together an effective security strategy.
Start by defining your security requirements, and then fit the technology to them.
Action 4: Define your container DevOps story.
Once you’ve adopted containers, chances are you will quickly move to DevOps tools and processes. That said, many enterprise software development organizations have not integrated containers into their DevOps strategy. Specifically, most haven’t assembled the configuration and testing tools needed to create the automation layer needed to bring containers from idea to production in less than a day.
This, of course, means that a bunch of stuff is happening in the background, including continuous integration, continuous testing, and continuous deployment. While this simplifies and speeds the development processes, selecting the right tools to make this work well for all parts of the processes is still more art than science.
Action 5: Define your containers business case…again
Most organizations that have moved to containers first considered the business case, or perhaps defined one. But this year, I urge you to revisit the business case. Here’s why.
Most organizations that brag about positive ROI numbers for containers have overstated the value of portability. While containers do give you the ability to move applications that exist within containers, most of those applications will never move off of their current hosts.
Containers simply provide an abstraction layer for applications. Those abstraction layers make your apps more portable, but they also bring complexity, and thus additional costs. If you’ve containerized apps that never move, the value of portability that containerization enabled will never be realized.
Sometimes the benefits you’ll get from using containers are just not there to justify the cost of moving to them.
Set your direction, then move forward with containers.
When considering containers for your applications, you’ll find the best uses where practicality meets function, and you need a clear understanding of what’s needed to get you where you need to go. Containers are all the rage right now but remember: Using the technology is not mandatory. Containers come with tradeoffs, just like any other technology.
Understanding those tradeoffs will be key to your successful application of container technology. Take the five actions described above to define your needs. Only with solid definitions can you find the best route to successfully integrating containers into your enterprise.