I tried to write about containers, but realized I needed to understand images, Docker, and Kubernetes first
“Everything should be made as simple as possible, but not simpler.”
That famous Einstein quote stands true today as we’re inundated with complicated technology. As a result we sometimes oversimplify concepts in an effort to explain them, though it can often blur their real meaning.
This is a problem I ran into last week when I wrote a blog about software containers. When I started, I thought I had a pretty good understanding of what containers were. But when I tried to actually write out the definition of a container, I couldn’t seem to find the right words, and each explanation I found online was different. The complicated definitions were too long and too technical. The simple ones used familiar words, but I didn’t know what those words really meant in this context.
At first, I was just going to include those terms in my own definition—if so many different companies are repeating them, everyone else must know what they mean, right?
That’s not always the case. We sometimes assume that everyone else knows more than us, when a lot of people actually have the same questions, but are too afraid to ask. There’s also often a knowledge gap between technical teams who deeply understand technology and the individuals who make decisions at companies.
If I’m not totally familiar with a concept, there’s a good chance that I’m not the only one. If you’re like me and aren’t quite sure about how this works, follow along as I walk through the steps I took to understand containers, starting with a few of the definitions:
- Microsoft Azure: Containers are “a standard package of software [that] bundles an application’s code together with the related configuration files and libraries, and with the dependencies required for the app to run.”
- IBM: “Containers are executable units of software in which application code is packaged, along with its libraries and dependencies, in common ways so that it can be run anywhere, whether it be on desktop, traditional IT, or the cloud.”
- Docker: “A container is a standard unit of software that packages up code and all its dependencies so the application runs quickly and reliably from one computing environment to another.”
After reading these, my questions were: What is a unit of software? What do we mean by dependencies?
A unit of software is a piece of code—it’s the smallest piece of code that can be reused and tested. But what does that mean? Who is testing code and why?
Developers test code to make sure it performs as expected. So a unit of software is the smallest piece of code that serves a purpose (i.e., it isn’t just a bunch of letters and symbols that don’t connect or do anything); for example, it could be a function, procedure, or object.
A dependency is one unit of software that another unit of software needs to run correctly—for example, files or programs that your application needs to work.
After learning this, I came up with my own definition:
A container is a small piece of code that holds together all of the data and files needed to run an application.
So, why do we use containers?
Containers make it easier to package and transport applications. With containers, developers don’t have to manually move code from one location to another or worry about whether the app will work in different environments, because all the dependencies are packaged alongside the application in the container.
Images are more like notebooks than pictures
Creating and using containers historically required a lot of manual code writing and specialized expertise until the software platform Docker was introduced in 2013. Docker created a standardized image, which made containers much easier to create and distribute.
When I heard the term image, I thought we were literally talking about a picture. But a container image is more like a template. For example, take a specific brand and type of notebook, like a legal pad. All of the legal pads on the shelf at a store are the same but once you buy a legal pad and start writing in it, it’s different.
Images are static files that you can’t change. In the digital world, we don’t need a shelf of images; instead, we download a copy of the original image. Then we are free to customize it.
So when Docker created a standardized image, this made containers accessible to a lot more people. They created a library of container images called Docker Hub, where users could find the image that best fit their needs, and then duplicate and customize it to create an application, instead of starting from scratch each time.
Taking containers to the next level
Kubernetes, a container orchestration software, took this a step further by making it possible to create and manage apps that use hundreds of containers. It automates deploying, managing, and scaling containerized applications.
That brings us to where we are today. Organizations are using containers to deliver applications quickly. If companies offer many applications, they often use Kubernetes to help manage and scale them.
A recent survey from Canonical found that the top two technology goals of the teams adopting Kubernetes are to (1) improve maintenance, monitoring, and automation and (2) modernize infrastructure.
A few experts who commented on the survey broke down what they think these goals really mean.
“We want a modern standard way of running software that works in every way,” James Strachan at CloudBees said.
Kelsey Hightower, principal developer and GCP advocate said that “with Kubernetes, you almost collapsed 25 different tools into one. This is what people mean when they say ‘modern infrastructure.’”
So what organizations really want today is a standard, reliable way to run applications using as few tools as possible. Teams don’t want to find, test, and understand more technologies, they want to find the most simple and effective tools to do their work.
A large attack surface makes a great target
Having a tool like Kubernetes is ideal because it can do so much, but it’s also why it’s hard to secure, making it an attractive target for bad actors. In the 2022 State of Kubernetes Security Report, 94% of respondents said that they experienced a security issue related to Kubernetes or containers in the past year, and misconfigurations and exposures were the cause of most of those security incidents.
What can you do about it?
Knowing what’s in your cloud and what you’re using to manage it is key to protecting your environment. If you know which tools you’re using, and what you’re using them for, you can more effectively identify which ones attackers will target and how they will try to get there.
If you’re looking for more ways to prevent attackers from compromising your containers, check out our blog with practical tips for securing Kubernetes.
