Containers: A Fundamental Shift in How Software Is Delivered

Container and Docker technologies represent one of the most consequential shifts in modern IT infrastructure — a move away from heavyweight, monolithic machine-centric deployments toward lightweight, application-centric systems. Where traditional virtualization abstracts hardware, containers abstract the operating environment itself, letting developers ship code with all its dependencies in a single, portable unit.

This shift is being accelerated by several converging forces:

• Growing demand for automated, scalable, distributed infrastructure
• Faster application development cycles driven by CI/CD pipelines
• The rise of open-source ecosystems that have moved into commercial adoption
• Programming languages and frameworks that reduce the effort required to build and ship software
• An industry-wide push toward performance, reliability, and developer experience over raw hardware compatibility

At its core, a container solves a deceptively hard problem: how do you get software to run reliably and consistently when moved from one computing environment to another? Containers answer that by packaging the application code, runtime, system libraries, and configuration together into a single isolated unit.

How Containers Work

Containers share the host operating system kernel but isolate the application’s process space using Linux kernel features such as namespaces and control groups (cgroups). This makes them dramatically lighter than virtual machines: a container starts in seconds rather than minutes, and many containers can run on the same host with minimal overhead.

A container image bundles your application code together with its runtime dependencies — libraries, environment variables, configuration files, and anything else the app needs to run. That image can be version-controlled, stored in a registry, and deployed identically across a developer’s laptop, a staging server, or a production Kubernetes cluster. This reproducibility is the foundation of modern CI/CD workflows.

When combined with a service-oriented or microservices architecture, containers create clear boundaries between components. Each service can be developed, tested, scaled, and replaced independently, reducing coupling and accelerating iteration.

Why Containers Support Agile Engineering

Effortless Host Operations

Unlike traditional virtualization, where each virtual machine (VM) runs its own full OS, containers execute application processes in isolation from the host OS without requiring that OS to have application-specific software installed. This keeps the host lean and makes it straightforward to apply security patches and OS updates without worrying about breaking application dependencies.

Platform Independence

A container image carries everything the application needs to run: code, runtime, libraries, and configuration. This portability means the same container image can run on a developer’s local machine, a bare-metal server, a private cloud VM, or a public cloud instance — without modification. The phrase “works on my machine” effectively becomes irrelevant when the machine itself is packaged with the code.

Developer and Operations Productivity

Containers create a clean separation of concerns. Developers focus on application logic and declare dependencies in a Dockerfile or equivalent specification. Operations engineers take that image and handle deployment, scaling, and management — without needing to understand every nuance of the application’s internal dependencies. This separation reduces friction between development and operations teams, which is a central goal of DevOps practice.

Fault Isolation and Security Boundaries

Because containers run in isolated process spaces, a crash or compromise in one container does not automatically propagate to others running on the same host. If a container serving one microservice fails, the remaining containers continue operating unaffected. Similarly, a security breach contained within one container’s namespace limits the blast radius of an attack — though this is not a substitute for proper network policies, image scanning, and least-privilege configurations.

Code Reuse Through Images and Layers

Container images are built in layers, and base images can be shared across many applications. A team maintaining a hardened, patched base image can distribute it to all their application teams, who extend it with application-specific layers. Public registries such as Docker Hub provide community and vendor-maintained images that developers can pull as a starting point, reducing boilerplate and accelerating setup.

Linux Distributions Purpose-Built for Container Hosting

General-purpose Linux distributions include many packages and services that are unnecessary — and represent unnecessary attack surface — on a system whose sole job is running containers. Several distributions have been created specifically as minimal container hosts:

• Fedora CoreOS / Red Hat CoreOS: The successor to Container Linux and Project Atomic Host. Red Hat CoreOS is the worker node OS for OpenShift. Fedora CoreOS is the community upstream. Both use transactional updates for atomic OS upgrades, minimizing the risk of a broken update leaving nodes in an inconsistent state.
• Container Linux (formerly CoreOS Linux): One of the first minimal OSes designed from the ground up for running containers. CoreOS the company was acquired by Red Hat, and development has continued in the CoreOS lineage under Red Hat and Fedora projects.
• Ubuntu Core: A minimal, snap-based Ubuntu variant designed for IoT devices and large-scale cloud container deployments. It uses snaps for all system components, enabling transactional, rollback-capable updates.
• RancherOS: A minimalist Linux distribution where the entire OS runs as Docker containers — the system Docker runs infrastructure services, and a user Docker runs application containers. Note that RancherOS has been deprecated in favor of more modern Rancher offerings such as k3OS and Elemental.
• VMware Photon OS: A minimal Linux container host optimized for VMware platforms, including vSphere and VMware Cloud Foundation. It is maintained by VMware and is well-suited for teams operating in VMware-centric infrastructure environments.

Orchestration: The Missing Piece

Running a single container on a single host is straightforward. Running hundreds of containers across dozens of hosts — with health checks, rolling updates, service discovery, load balancing, and secrets management — is an entirely different challenge. That is the problem container orchestration platforms solve.

Kubernetes has become the dominant container orchestration system. It handles scheduling containers onto nodes, restarting failed containers, scaling workloads up or down, exposing services to internal and external traffic, and managing configuration and secrets. Docker Swarm is a simpler alternative suitable for smaller deployments. Managed Kubernetes offerings from major cloud providers — EKS, GKE, AKS — reduce the operational burden of running the control plane.

Adopting containers without an orchestration strategy works at small scale but becomes operationally unsustainable as the number of services and hosts grows. Planning for orchestration early is a prerequisite for a production-ready container strategy.

Key Takeaways

• Containers package code and all its dependencies into a portable, reproducible unit, solving the “works on my machine” problem.
• They are lighter and faster than VMs because they share the host kernel rather than emulating full hardware stacks.
• Containers improve developer productivity, enable clear DevOps role separation, and provide fault isolation between services.
• Minimal Linux distributions such as Fedora CoreOS, Ubuntu Core, and Photon OS are designed to reduce attack surface and operational overhead on container hosts.
• Container orchestration — most commonly Kubernetes — is essential for managing containerized workloads at production scale.
• A microservices architecture amplifies the benefits of containers by allowing independent development, deployment, and scaling of each service.

Container technology continues to evolve rapidly. The ecosystem now includes not just runtime and orchestration tooling but also service meshes, eBPF-based networking and observability, WebAssembly as a complementary runtime, and confidential computing extensions that bring hardware-level isolation to containers. Teams that invest in understanding the fundamentals — image construction, networking, storage, and orchestration — will be well-positioned to adopt these advances as they mature.

Background: BlueWave Solar and Its Software Challenge

BlueWave Solar is a community solar developer and servicer that acquires land, builds solar farms, and manages subscriptions for customers who would not otherwise have direct access to solar power. At the time of this case study, the company served more than 3,000 subscribers across Massachusetts and New York, drawing on approximately 135 megawatts of solar capacity.

Core business functions — billing, customer acquisition, customer service, and subscription management — all ran on the Salesforce platform. According to Jeff Battles, Senior Director of Product Management, Salesforce enabled BlueWave to iterate and grow quickly in its early stages. However, as the organization matured, gaps in the development and deployment workflow began to create friction.

The Problem: Monthly Releases and Unmanaged Configuration Changes

Before adopting a dedicated DevOps toolchain, BlueWave released software on a monthly cadence. Each release involved a significant accumulation of changes, a complex deployment event, and reactive troubleshooting afterward.

“There was a lot of complexity going into our production environment at once.”

— Jeff Battles, Senior Director of Product Management, BlueWave Solar

A key pain point was the split between code and configuration. BlueWave tracked source code changes in GitHub, but Salesforce configuration and low-code development changes were not managed there. This created blind spots: configuration drift between developer sandboxes was difficult to detect, and there was little visibility into what was changing on the configuration side of the platform.

The team also lacked a clear process for managing development environments across team members, making it harder to collaborate without overwriting each other’s work.

Evaluating DevOps Tooling for Salesforce

BlueWave evaluated several Salesforce DevOps platforms before making a decision. Alternatives considered included Flosum and Gearset. The team ultimately selected Copado for several reasons:

• Native Salesforce integration: Copado runs inside the Salesforce platform itself, giving it a familiar interface and reducing the overhead of learning a separate toolchain.
• GitHub compatibility: Copado integrated with BlueWave’s existing GitHub repositories, extending version control to cover configuration changes alongside custom code.
• Sandbox back-deployment: The platform allowed developers to back-deploy one developer’s changes into another developer’s sandbox, reducing merge conflicts and environment drift.
• Support for citizen development: Copado’s workflow made it practical for non-technical staff trained on Salesforce to make low-code or no-code changes, with the dedicated tech team reviewing and promoting those changes to production.

What Changed After Adopting Copado

BlueWave adopted Copado in late 2018. The results reported by Battles were significant:

• Deployment frequency: Releases moved from monthly to several times per day.
• Change size: Smaller, incremental changes replaced large, risky batch releases.
• Feedback loops: Faster deployments meant issues were identified and resolved much sooner.
• Citizen development: Business-side staff could contribute changes within the Salesforce environment, freeing the core engineering team to focus on higher-complexity work.

The shift toward smaller, more frequent deployments is consistent with well-established DevOps principles. Reducing batch size lowers deployment risk, shortens the feedback loop, and makes rollback or remediation simpler when issues do arise.

Citizen Development and the Role of Low-Code in DevOps

One notable outcome of BlueWave’s adoption of Copado was unlocking a more structured citizen development workflow. Citizen developers are employees outside the core IT organization who build or modify applications — often because they are closest to the business problem being solved.

“Oftentimes, those people are closer to the business problem that they are facing.”

— Jeff Battles, Senior Director of Product Management, BlueWave Solar

By routing citizen developer changes through a governed review and deployment process, BlueWave captured the speed and domain knowledge of business users while maintaining the oversight of the engineering team. This is an increasingly important pattern as low-code platforms become more capable and more widely adopted within enterprises.

Broader Context: DevOps for Salesforce Ecosystems

Andrew Leigh, Senior Vice President of Marketing and Alliances at Copado, noted that while Salesforce is a widely used platform for digital transformation, purpose-built DevOps tooling for it was slow to emerge. Standard software engineering DevOps tools are often designed around code repositories and build pipelines that do not map neatly onto Salesforce’s metadata-driven configuration model.

Leigh identified visibility and governance as growing priorities for organizations undertaking large-scale digital transformation — not just automation of CI/CD pipelines. As transformations grow in scope, leadership needs insight into what is changing, who is making changes, and whether those changes align with broader organizational goals.

“Technology itself is not enough.”

— Andrew Leigh, SVP Marketing and Alliances, Copado

Key Takeaways for DevOps Teams on Salesforce

BlueWave Solar’s experience surfaces several practical lessons for engineering and platform teams managing Salesforce-based applications:

1. Treat configuration as code. Salesforce configuration changes carry the same risk as code changes. Version-controlling them in GitHub (or equivalent) gives you audit trails, rollback capability, and conflict detection.
2. Reduce deployment batch size. Monthly releases accumulate risk. Moving to smaller, more frequent deployments reduces the blast radius of any single change and accelerates feedback.
3. Manage sandbox environments deliberately. Without tooling to synchronize developer sandboxes, environment drift becomes a hidden source of deployment failures.
4. Build governance into citizen development workflows. Allowing business users to contribute changes is valuable, but only with a review and promotion process that ensures quality and consistency.
5. Match your DevOps toolchain to your platform. Generic CI/CD tools may not handle Salesforce metadata well. Evaluating platform-native or platform-aware tools can reduce integration friction significantly.

BlueWave Solar’s transition from monthly to multiple-daily deployments is a concrete illustration of how adopting DevOps practices — even on a platform like Salesforce that is often treated as configuration-only — can produce measurable improvements in delivery speed and software quality.

Cloud Computing Comes of Age

The term cloud computing emerged as a buzzword in the early 2000s, but it has since matured into a foundational pillar of enterprise IT strategy. According to Gartner figures cited in the original source, the worldwide public cloud service market was projected to reach $331.2 billion by 2022, growing at a compound annual growth rate (CAGR) of 12.6% from 2018.

Two factors consistently drive cloud adoption at the enterprise level: agility and cost efficiency. Cloud infrastructure allows organisations to respond faster to shifting market conditions and evolving customer expectations, while freeing IT leaders to focus on data-backed strategy rather than reactive infrastructure management.

Understanding the Need for Business Agility

Business agility is not a one-size-fits-all requirement. The urgency and scope of agility vary significantly between departments and functions within the same organisation.

Consider a retailer aiming to double revenue through an e-commerce channel. In this scenario, improving customer experience becomes a critical priority—far more pressing than incremental changes to product management workflows. Recognising where agility delivers the greatest return prevents organisations from attempting a costly, uniform cloud transformation across the entire IT landscape when budget and capacity are limited.

The first step, therefore, is a deliberate assessment: which parts of the business genuinely require agility, and in what timeframe? This prioritisation shapes every subsequent technology and architecture decision.

Building Agility: A Process-First Approach

Many organisations make the mistake of leading with technology. A more sustainable approach starts with process redesign before selecting tools or platforms.

Refine and Reimagine Processes for a Digital-Native World

Established organisations with complex, legacy systems must reimagine their business processes before attempting to migrate or modernise at scale. Useful techniques include:

• Continuous feedback loops from user groups to surface friction points early
• Design thinking workshops to generate and validate ideas for efficiency improvements
• Guided practices and instant simulation to reduce decision latency
• Iterative prototyping to test process changes before full implementation

A practical example: food delivery aggregators do not rely on order history alone when generating recommendations. They factor in delivery location, order type, time of day, and user behaviour patterns. Investing in a real-time digital data platform that enables on-the-fly analysis and personalisation allows organisations to increase customer wallet share—a capability that process redesign makes possible long before a single line of new code is written.

Select Technologies That Match the Redesigned Processes

Once processes have been restructured, the technology choices follow more naturally. Depending on the business domain and scale requirements, the modern cloud-native stack may include:

• Microservices for decomposing tightly coupled monolithic applications
• Containers and orchestration (e.g., Kubernetes) for portability and scalability
• Platform-as-a-Service (PaaS) to reduce infrastructure management overhead
• Stream processing for real-time data pipelines
• Mobile-first APIs for customer-facing applications
• AI/ML and cognitive services for intelligent automation and recommendations
• IoT and Blockchain where supply chain transparency or device integration is required

Technology selection should be driven by the specific agility goals identified earlier—not by vendor marketing or industry trends alone.

Creating a Modern IT Landscape

The transition to a cloud-ready IT landscape typically happens along two parallel tracks:

1. Building new applications using cloud-native patterns from the outset
2. Decomposing existing monolithic applications by business domain into independently deployable microservices

Decomposition is particularly valuable for large, incumbent systems that cannot be replaced in a single migration. Breaking a monolith apart by business function allows teams to migrate and modernise incrementally, reducing risk while progressively adopting adaptive cloud architecture.

Regardless of the approach, applications operating in an interconnected business ecosystem should expose their capabilities through platform-agnostic APIs. Vendor and technology neutrality ensures that no single architectural decision locks the organisation into a dependency that limits future agility.

Scaling IT Delivery Capabilities

Technology transformation only delivers value when the people operating the systems have the skills—and the culture—to use them effectively. Scaling IT delivery capabilities requires investment in two areas:

Technical Upskilling

Engineering teams need hands-on exposure to cloud-native tooling, container orchestration, CI/CD pipelines, infrastructure-as-code, and observability practices. Formal training programmes, internal guilds, and incremental project ownership are all effective vehicles for building these skills organically.

Cultural Transformation

Technical skills alone are insufficient. Agile working practices, a tolerance for calculated risk, exploratory thinking, and psychological safety to experiment and fail fast are equally important. Organisations may choose to develop these capabilities internally or partner with an IT service provider experienced in cloud-native transformation—not only for technology expertise, but to act as a catalyst for cultural change within the IT organisation.

Key Takeaways for DevOps and Platform Teams

• Prioritise before you migrate. Map agility needs to specific business functions before committing to a broad cloud programme.
• Start with process, not platforms. Poorly designed processes migrated to the cloud remain poorly designed—just more expensive.
• Decompose incrementally. Microservices and cloud-native architectures are a journey, not a big-bang cutover.
• Build for interoperability. Platform-agnostic APIs protect long-term architectural flexibility.
• Invest in people as much as infrastructure. Upskilling and cultural change determine whether cloud investment translates into real business agility.