Most of the excitement and experimentation is a grassroots effort, and containers are being used within pockets of the enterprises. In many cases, management is aware of container technology but has not yet bought into an all-out container strategy. Some of the hesitation that I hear from C-level executives is that containers are not mature enough yet, containers have security gaps, there is a lack of skills and training, and they don’t want to give up their investment in VMs. The practitioners who are implementing containers see huge opportunities in agility, quality, portability, and manageability. So, how can we explain the value of containers to our bosses so we can get broader adoption of a technology that can solve a lot of business problems?
A Day in Your Boss’s Shoes
One of the challenges that engineers have in explaining why certain technologies add value is that they only explain it from their own viewpoint. A key to selling up is to understand what value statements resonate with the person you are selling to. A typical C-level IT person (CIO, CTO, Chief Architect, etc.) was a programmer in the ’70s, ’80s, or ’90s, but likely does not spend much time actually programming anymore. They have witnessed decades of evolution in technology solutions. They can count on their fingers and toes the number of times an engineer has brought them a new technology that was going to solve all of the world’s problems. They have seen the case tools, the BPM technologies, the business rules engines, the enterprise service buses, and a number of other great technology solutions that added value (sometimes) but fell well short of solving world hunger. So, there is a good chance that they may be skeptical. They may not have coded in a while, but many of them have written assembly language, can read hex code dumps, have written drivers, and did some hardcore development back in the day when not everything was abstracted like it is today. In other words, most of these folks are brilliant and have witnessed countless technology changes over the course of several decades. To sell to these folks, one most first understand what business drivers are important to them, how the new technology will impact the organization and its existing investments, and how it will help achieve the company’s (and IT’s) goals.
Selling the Value of Containers
To a developer or a systems administrator, the value of containers is very obvious. Developers are in high pursuit of agility. As developers implement continuous integration and continuous delivery, they require frequent on-demand environments. Two of the biggest bottlenecks for developers are long provisioning times and inconsistent environments. Containers play a huge role here. Containers can be provisioned in milliseconds, a great improvement over VMs, which take a few minutes. Manual provisioning can take hours to days to even months depending on the access to physical hardware and the processes in place to request a new machine (physical or virtual). Inconsistent environments (aka “environment hell”) is not only a huge time waster, but it also has a negative impact on quality. As developers move code from dev to QA to stage to prod, at each move they are often faced with countless defects caused by subtle differences in the configuration of the environments. This can lead to days or even weeks of unnecessary debugging, system configuration changes, and redeployments. Even worse is that when the code actually makes it to production, it is often being exposed to an environment that is different from the ones it was certified on, resulting in new issues that impact end users. This creates more defects, emergency changes, high maintenance, and unhappy customers. Using containers can help eliminate environment inconsistencies, which reduces a lot of waste and quality issues, resulting in improved agility and customer satisfaction.
When selling up, focus on bigger-picture value statements like increased agility, improved quality, and higher customer satisfaction. These are the things the C-level folks are usually measured on. Talking about how fast containers are, how few lines of code it takes, and how easy it is to use containers is nice, but your boss doesn’t lose sleep at night over a VM’s taking a few minutes to boot or over how many lines of code it takes to automate a VM. Bosses also don’t care how cool the technology is or how much you like using it.
Another area where containers add value is portability. Containers hide the complexity of the compute layer, the operating system, and the application stack. When configured properly, containers can be ported across different environments without requiring coding changes. For example, a workload could be moved in flight from an on-premises environment to a cloud environment in real time and be run without any changes to code or the container. This is very beneficial to companies trying to execute a hybrid cloud strategy and to companies whose customers run different endpoints. Containers allow us to abstract away the underlying infrastructure from the code so that code can be ported to different environments with minimal code and configurations. The next step for container technology is to abstract the network and storage layer as well, so that containers can be ported seamlessly across heterogeneous environments without having to reconfigure network and storage configurations.
Selling this concept to management requires more than saying that containers are portable. What does portability give us? How does portability help us meet our business or IT goals? Portability supports the following business and IT drivers:
- Enable hybrid cloud strategy: Containers can port seamlessly across multiple cloud endpoints
- Assist with compliance: Can help enforce usage of standard secure images
- Help avoid vendor lock-in: Stay away from proprietary images
Another advantage of containers is that containers are more lightweight than VMs and consume significantly fewer compute and memory resources. This results in better utilization of physical hardware, which results in cost savings and even cost avoidance (need less hardware). When selling up, simply saying that containers use fewer resources is not enough. The hardware sitting on the raised floor is already on the books. To sell this value statement, you need to do some math. Show current metrics of average server utilization. Show how moving to containers can improve those numbers. Model how the adoption of containers can change the current rate of procurement for physical or cloud-based compute resources.
I do want to add a disclaimer here. Containers are not a replacement for VMs. There are some use cases where containers make sense, there are others where VMs make sense, and there are still others where a combination of VMs and containers makes sense. I’ll save that for another post on another day. The key point here is not to sell containers as a replacement for VMs. Instead, containers are another great tool for the toolbox. Make sure the intended use cases are documented, so that when you sell up, you are not setting a perception that the current investment in VMs is going away.
Containers are taking the world by storm. As with any new technology, the more executive-level support there is, the better chance of success a company will have in embracing this technology. The best way to obtain this support is to sell the value of containers in terms that are relevant to the C-level IT leaders. Understand the IT and business drivers within an organization, and tailor your pitch to those drivers. Take your engineer hat off, and put your CTO hat on. How will container technology help the CTO sleep better at night? Remember, your bosses have seen just about every technology shift in the last few decades. They have seen a lot of hype that has never lived up to its billing. Although containers are probably overhyped right now, they are not a fad. It is critical that companies start crafting a container strategy before too many skunkworks container projects take root. Without a sound container strategy, implementing containers can do more harm than good. Like anything else, the technology is only as good as the way it is implemented. Happy selling.
This article originally appeared on The Virtualization Practice and has been reposted here with permission.