Why Containers Caught On So Quickly

Containerisation technologies existed before Docker, but Docker was the tool that made them genuinely accessible at the command line. That accessibility opened up the benefits of containers to mainstream developers, who quickly discovered how containers could simplify dependency management and eliminate the classic “but it works on my machine” problem.

By packaging an application and its dependencies into a container image, teams can reproduce exactly the same environment on a developer laptop as in production. From there, the community began exploring how well containers fit with microservices architectures and CI/CD pipelines, making it faster and more reliable to build and ship code. That speed of delivery is something virtually every organisation wants from its software teams.

Tips for Starting Your Container Journey

Containers can touch every stage of the software lifecycle — development, continuous delivery, orchestration, security, and site reliability engineering. The breadth of the technology can make adoption feel overwhelming. Rice’s advice: you do not have to do everything at once.

Start by anchoring the effort to a clear business goal. For most organisations, the strategic driver is increasing deployment speed. Containers are most valuable when teams are already working with agile methodologies and shipping code frequently through a CI/CD pipeline.

The path to containerisation looks different in every company — and even in different teams within the same company:

• Bottom-up adoption: Individual development teams bring containers into their local workflow to make their own lives easier. Container usage then grows organically across the organisation.
• Top-down platform adoption: A platform team builds an orchestrated cluster and offers it to the rest of the business. Software teams are then invited to migrate their workloads into containers so they can run on the shared cluster.

Both approaches are valid. Conference talks, meetups, and case study presentations are a rich source of real-world experience from teams who have been through the journey. Interactive learning platforms such as Katacoda (now archived into the Killercoda platform) offer hands-on Docker and Kubernetes labs that are well suited to engineers just starting out.

Overcoming the Typical Challenges of Container Adoption

Getting Security Leadership On Board

One of the most common blockers is persuading the CISO that containerised deployments are safe. Security leads often ask whether shipping code more frequently increases the organisation’s risk profile. The counter-argument is straightforward: continuous delivery means shipping small, incremental changes. Each individual update carries little additional risk compared to the previous one, and automated controls such as container image scanning can detect known vulnerabilities in dependencies before they reach production.

Microservices also make security reasoning easier. It is far simpler to define and enforce what a small, focused microservice should be able to access — which files, which user IDs, which network endpoints — than it is to reason about access controls across a large monolithic codebase. Container-native security tools can apply those policies at the level of individual containers.

Convincing Technical Leadership

CTOs and engineering directors need confidence that containerised processes can produce well-tested, production-quality software. The case to make is both technical — faster, more reliable delivery pipelines — and cultural: containers and CI/CD encourage an agile mindset and continuous improvement. That said, containers are not universally the right choice. Organisations with heavily plan-driven, waterfall delivery processes may find that the cultural shift required is too significant to tackle alongside the technical one.

Progress in Container Security

Container security has matured considerably since the early concerns about shared kernel namespaces and container escape. Improvements in the Linux kernel — such as user namespace support — directly addressed some of those initial concerns. Rice points to the ShellShock vulnerability as a useful illustration of how containerisation can actually improve a security posture:

Most microservices don’t need a shell, so you can run them in containers that don’t include the shell. In the event of another ShellShock being discovered, you would still have to worry about patching the host, but you wouldn’t need to change those microservice containers at all. That means less testing and less risk when the patch is applied.

By stripping container images down to only the dependencies a service actually needs, teams reduce the attack surface of each workload. Dedicated container security platforms (such as Aqua Security, where Rice worked at the time of this interview) have helped enterprises build robust security policies for containerised deployments, and Docker’s Enterprise Edition introduced formal testing and certification processes as evidence of that growing maturity.

How Skill Sets Need to Evolve

Containers tend to simplify the developer experience, but they introduce a significant learning curve on the operations side. Key areas where thinking must shift include:

• Orchestration: In an orchestrated cluster, you do not control which node runs which workload. Operations teams must move from managing individual machines to reasoning about the cluster as a whole.
• Observability: Monitoring, distributed tracing, alerting, and diagnostics tooling is evolving rapidly to handle the dynamic, ephemeral nature of containerised workloads. Traditional host-centric monitoring approaches do not translate directly.
• Infrastructure as code: Container-native infrastructure is more automated, less proprietary, and more collaborative than traditional server provisioning. Teams need to adopt infrastructure-as-code practices alongside container adoption.

Where Containers Are Headed

At the time of this interview (2017), Rice observed that the community was moving from experimentation to running containers seriously in production. Container fundamentals were already stabilising, but significant room remained for tooling improvements in CI/CD, monitoring, diagnostics, and programmable infrastructure.

The broader trajectory she described — containers moving from early-adopter curiosity to mainstream infrastructure — has since proven accurate. Kubernetes has become the dominant orchestration platform, observability tooling has matured substantially, and container security has evolved from an afterthought into a dedicated discipline. The foundational advice in this interview — start with a clear business goal, address security concerns with evidence, and invest in team skills — remains relevant for organisations still navigating their container adoption today.

Originally published April 2017. Source: sys-con.com / AppDynamics. Interview subject: Liz Rice, then at Aqua Security.