Containers sound so simple. We know what the word means: It’s something that you use to hold stuff. Just do a Google image search: The top visual explainer is a shipping container.
This translates reasonably well to a software context: A container is still essentially something that we put stuff in; in this case, the “stuff” is an application’s code as well as everything that code needs to run properly.
Simple enough, right?
Software containers can nonetheless be a bit challenging to explain, particularly if the audience isn’t technical and doesn’t understand certain fundamentals about how software gets built and operated.
[ Read also: What's a Linux container? ]
So we asked several experts to take a stab at explaining containers in the plainest possible terms. Their definitions will give you a solid basis for explaining containers to others, whether your audience is technical or not.
Gordon Haff and William Henry, technology evangelists, Red Hat:
Haff and Henry offer a good container primer in their eBook, From Pots and Vats to Programs and Apps: How Software Learned to Package Itself. The book certainly gets technical at times, yet Haff and Henry ultimately define containers in wonderfully straightforward fashion, relying little on terms that require a software development or systems administration background. You don’t even need to know what an operating system is, for example. Here’s how they explain containers:
“Imagine you’re developing an application. You do your work on a laptop and your environment has a specific configuration. Other developers may have slightly different configurations. The application you’re developing relies on that configuration and assumes specific files are present.
Meanwhile, your business has test and production environments which are standardized and have their own configurations and their own sets of supporting files.
You want to emulate those environments locally as closely as possible, but without the work of recreating the server environments manually. So, how do you make your app work across these environments, pass quality assurance, and get your app deployed without massive headaches, rewriting, and break-fixing?
The answer: Containers. The container that holds your application also holds the necessary configurations (and files) so that you can move it from development, to test, to production – without nasty side effects.”
Ed Featherston, VP and principal cloud architect at Cloud Technology Partners:
Like Haff and Henry, Featherston says it often helps to explain the historical context for containers, including the virtualization boom. Think of this as the “why.” For example, for all of virtualization’s benefits, it came with costs, both literal and figurative. As Featherston has written: “Containers try and find a balance between isolating the applications virtually without requiring the overhead and licensing issues of bringing along virtual hardware and a guest OS that virtual machines require.”
Eva Tuczai, engagement & product Manager, advanced engineering, Turbonomic:
“Containers solve the packaging problem of how to quickly build and deploy applications. They’re akin to virtual machines, but with two notable differences: they’re lightweight and spun up in seconds; and they move reliably from one environment to another (what works on the developer’s computer will work the same in dev/test and production).”
“In the digital era, applications are the business – speed and innovation are creating winners and losers across all industries. The beauty of containers, and why organizations are moving in this direction, is that they dramatically speed-up development.”
[ Related read: 5 Kubernetes success tips: Start smart. ]
Amir Jerbi, CTO and co-founder at Aqua Security:
“Containers are a way for developers to easily package and deliver applications, and for operations to easily run them anywhere in seconds, with no installation or setup necessary. They enable this by embedding all the code needed in the container and using a process called a container engine to run the containers atop an operating system such as Linux or Windows. Containers also make it easy to implement microservices architectures, and when used in such environments they also make the application very easy to scale up or down, because every component can be run on-demand, even for a few seconds or minutes, and then be shut down equally rapidly.”
[ Read also: Microservices and containers: 6 things to know at start time. ]
Colby Dyess, director of cloud marketing at Tufin:
“Containers are similar to virtual machines, with two key differences. First, virtual machines package application code and an entire operating system. Containers package merely the code and the essential libraries required to run the code. Second, virtual machines provide an abstraction layer above the hardware, so a running instance can execute on any server. By contrast, a container is abstracted away from the underlying operating environment, enabling it to be run just about anywhere; servers, laptops, private cloud, public cloud, etc. These two characteristics free developers to focus on application development, knowing their apps will behave consistently regardless of where they’re deployed.”
[ Need to explain Kubernetes, too? Get our Kubernetes glossary cheat sheet for IT and business leaders. ]
