From Supply Chain to Software: What Containers Actually Are and Why They Matter

A developer with a supply chain background explains how software containers work by drawing an analogy to standardized shipping containers. The post describes how Docker packages applications into consistent units that run identically across any environment, solving the problem of deployment inconsistencies.

Pipeline & Prompts | Byte size guides on DevOps, Cloud and AI When IBM acquired Red Hat, my world changed overnight. Suddenly everyone around me was talking about containers. Kubernetes. Pods. Orchestration. I was nodding along in meetings while internally having absolutely no idea what any of it meant. My background was in supply chain and logistics. I understood how physical goods moved around the world — warehouses, pallets, shipping routes. But containers in software? That meant nothing to me. Then a colleague sat down and said: "Think about shipping containers." And everything clicked. Before the 1950s, shipping goods around the world was chaotic. Every port loaded cargo differently. Every ship was packed differently. Moving goods from a truck to a ship to a train required repacking everything multiple times. It was slow, expensive, and things got damaged or lost constantly. Then someone invented the standardised shipping container — a metal box of a fixed size that could be loaded once and transferred directly between trucks, ships, and trains without ever being opened or repacked. It did not matter what was inside. The container worked the same way everywhere. Software containers work exactly the same way. Before containers, deploying an application was chaotic. It worked on the developer's laptop but broke on the test server. It ran fine in the test environment but crashed in production. Every environment was configured slightly differently — different operating system versions, different software libraries, different settings. Moving an application between environments meant repacking everything and hoping for the best. A software container packages your application and everything it needs to run — the code, the libraries, the settings, the dependencies — into a single standardised unit. It does not matter whether that container runs on your laptop, a test server, an AWS cloud instance, or a Kubernetes cluster. It behaves exactly the same way everywhere. That is the problem Docker solved. And that is why it changed everything. Docker is a platform that lets you build, run, and share containers. It is not the only container tool — which we will come back to — but it is the one that made containers mainstream and the one most tutorials and courses use as a starting point. When people in DevOps and Cloud talk about "containerising an application," they mean packaging it into a container image using Docker so it can run consistently anywhere. Image — A blueprint for your container. It contains everything your application needs to run, frozen at a point in time. Think of it like a template or a snapshot. Images are built once and reused many times. Container — A running instance of an image. You can run the same image as ten different containers simultaneously. Each one is isolated and independent. Dockerfile — A simple text file with instructions for building your image. Think of it as a recipe — step by step instructions for setting up your application's environment. Registry — A place to store and share images. Docker Hub is the most popular public registry. In Cloud environments you will use private registries like AWS ECR or Azure Container Registry. Here is a simple Dockerfile that packages a basic web application: Start from an official base image FROM node:18-alpine Set the working directory inside the container WORKDIR /app Copy your application files into the container COPY package .json ./ COPY . . Install dependencies RUN npm install Tell Docker which port the app runs on EXPOSE 3000 The command that runs when the container starts CMD "node", "server.js" In plain English this says: start with a lightweight Node.js environment, copy my application files in, install everything it needs, and run it on port 3000. To build and run it: Build the image and tag it with a name docker build -t my-app:v1 . Run it as a container docker run -p 3000:3000 my-app:v1 See all running containers docker ps Stop a container docker stop <container-id Here is something worth knowing early: Docker is not the only container tool, and in many enterprise environments it is not even the default anymore. Podman is a container tool that works almost identically to Docker — most commands are directly interchangeable — but with some important differences that matter in enterprise and Cloud environments: If you are using Podman, the commands throughout this article work exactly the same way. Just replace docker with podman : podman build -t my-app:v1 . podman run -p 3000:3000 my-app:v1 podman ps Same result, different tool. The concepts are identical. Learn one and you know both. Containers and CI/CD pipelines are a natural match. In a modern DevOps workflow, every time a developer pushes code to GitHub, the pipeline can automatically: Here is a simple GitHub Actions example that builds and pushes a Docker image: .github/workflows/build.yml name: Build and Push Container Image on: push: branches: - main jobs: build: runs-on: ubuntu-latest steps: - name: Checkout code uses: actions/checkout@v3 - name: Build Docker image run: docker build -t my-app:${{ github.sha }} . - name: Push to AWS ECR run: | aws ecr get-login-password | docker login --username AWS \ --password-stdin ${{ secrets.ECR REGISTRY }} docker push ${{ secrets.ECR REGISTRY }}/my-app:${{ github.sha }} Every push to main builds a fresh container image tagged with the exact commit SHA — so you always know exactly which version of your code is running in production. Running one or two containers on a single server is straightforward. But what happens when your application grows and you need to run hundreds of containers across dozens of servers? How do you manage them all, restart ones that crash, scale up during busy periods, and distribute traffic evenly? That is where Kubernetes comes in — and it is the natural next step after containers. Kubernetes is a platform that manages containers at scale. Rather than running containers manually, you tell Kubernetes what you want — "run ten copies of this container and keep them running" — and it takes care of the rest. In the real world, nobody runs Kubernetes themselves from scratch. The major cloud providers offer managed Kubernetes services so you get all the power without the complexity of managing the underlying infrastructure: EKS — Amazon Elastic Kubernetes Service AWS's managed Kubernetes offering and one of the most widely used in the industry. If your organisation runs on AWS, EKS is the natural choice. It integrates tightly with AWS services like IAM for security, ECR for container images, and CloudWatch for monitoring. AKS — Azure Kubernetes Service Microsoft Azure's managed Kubernetes offering. If your organisation is already invested in the Azure ecosystem, AKS is the most natural choice. It integrates tightly with Azure Active Directory, Azure Monitor, and Azure Container Registry. GKE — Google Kubernetes Engine Google's managed Kubernetes service — and arguably the most mature, since Kubernetes was originally created at Google. GKE is known for being easy to use and very well integrated with Google Cloud services. OpenShift — Red Hat's Kubernetes Platform OpenShift is Kubernetes with a lot of enterprise features built on top — enhanced security, a built in developer workflow, and deep integration with Red Hat tooling. If you came from a Red Hat environment like I did, you have probably already encountered OpenShift. It uses Podman under the hood and is widely used in large enterprises and regulated industries like banking and healthcare. All four ultimately run containers. The choice depends on your cloud provider, your organisation's existing tools, and your compliance requirements. Here is everything we covered today: ← Previous: Git: The Tool That Saves Your Code and Your Career https://dev.to/posts/git-the-tool-that-saves-your-code-and-your-career/ Now that you understand containers, it is time to go deeper into CI/CD pipelines — the automated systems that take your code from a Git commit all the way to a running container in production. Coming soon in Article 5. Found this useful? Share it with someone just starting their DevOps or Cloud journey and follow along for a new article every week.