Docker and containers: benefits, operating costs and choosing a platform

Image, container and virtual machine

An application can work in testing but fail on a server because of a runtime version, missing library or unnoticed local setting. Containers reduce these differences by moving a traceable package through development, testing and production. They do not replace suitable architecture or accountable operations.

An image is the versioned application package and runtime files; a container is a running instance. Supply configuration and credentials separately and store persistent data independently. Linux containers share the runtime environment's kernel, while a virtual machine has a guest operating system. Containers often run inside VMs, so the approaches can complement each other.

'Identical everywhere' is too broad: processor architecture, operating system, permissions, external services and memory still influence behaviour. An image can be large and an application can start slowly while loading data. Measure the actual release improvement instead of assuming universally smaller or faster deployments.

Choose a platform for the situation

Docker documents Compose on a single production server with production-specific configuration. It is not limited to development, but does not by itself create a highly available multi-server environment.

Consider Kubernetes when independent releases, many workloads and automated placement solve recurring operational work. Restarting requires available capacity, data and dependencies. A low-interruption rollout needs sufficient running instances and versions compatible during the transition.

• Small internal portal and one team: a VM with Compose and documented deployment; accept the shared failure risk of one host.
• Public application with little platform staff: a managed container service; assess platform constraints, usage costs and data export.
• Several teams and independent services: orchestration, potentially Kubernetes; assign responsibility for cluster, network, policies and platform updates.

Example: a customer portal with a nightly import

Suppose the portal consists of a web application, database and import process released together by a small team. Build the application and importer as separate identifiable images while leaving the database on its well-managed existing platform. Reproducible application releases do not require migrating all data simultaneously.

Test the same images intended for production, with separate credentials and test data. Give the importer a measured memory limit so a large file cannot displace the portal unpredictably. Before extending to several hosts, explicitly prepare shared files, sessions and import state for that design.

Reproducible builds still require updates

Multi-stage builds separate build tooling from the runtime image. Fixed dependencies and an identifiable base image make a release reproducible, but also freeze the versions present at that time. Existing images do not automatically receive new packages. Schedule rebuilt, tested images.

Record image identifier, source revision, configuration changes and database migrations. A mutable tag such as latest is insufficient by itself. Keep secrets in the environment's credential management; baking them into an image spreads them with every download and complicates rotation.

Data and rollback are the harder parts

Restarting a container can replace the application process but cannot restore accidentally changed customer data. Persistent volumes and databases need tested backups. An older image is a valid rollback only if it understands the current schema; split changes into compatible stages where necessary.

Before selecting a platform, agree tolerable downtime, release support and holiday or sickness cover. Costs include registry, logs, monitoring, backups and staff time. A low-cost server with heavy manual support can cost more overall than a managed service.

Measure the pilot against an existing problem

Document who builds the application, manual release steps and differences between testing and production. Choose a bounded application with understood dependencies and manageable failure consequences. A critical undocumented core system is rarely the best place to learn a new operating platform simultaneously.

Set a verifiable objective: a second person can deploy an approved version into an empty test environment from the documentation. Measure hands-on effort, total time and manual corrections. Repeat with another release; one successfully started container is not sufficient evidence.

Test resources and faults realistically

Use a representative workload: concurrent logins, a search and the largest normal import. Observe response time, memory, CPU and free disk space. Limits help only when behaviour at the boundary is known; overly tight limits can cause incidents themselves.

In testing, exercise a restart, a temporarily unavailable dependency and a failed background job. Expect understandable errors, no silent duplicate work and logs identifying the release. The aim is a controlled failure process rather than collecting arbitrary fault scenarios.

The second release proves operability

Acceptance includes an image update and a small compatible data change. Check agreed user journeys before and after. Document when returning to the old image works and when new data first needs reconciliation; do not leave that decision until an outage.

Handover assigns base-image, host, runtime, registry and application maintenance, even if one supplier performs them all. Define image retention, log volume and growth alerts. Only when updates and deputy cover work should the pilot become a reusable standard.