Docker, Kubernetes and AWS: Getting to Production

Deployment tooling attracts more enthusiasm than almost anything else in engineering, and it is where small teams most often buy complexity they will never use. The useful way to read this stack is as three separate decisions that are frequently treated as one.

Docker: adopt it immediately

Containers solve a problem every team has: the application ran on a laptop and failed on the server. A container ships the PHP version, the extensions, the system libraries and the configuration together, so the artefact you tested is the artefact that runs. It also means a new developer is productive in one command instead of a day of setup, and CI can test against exactly what production uses.

This benefit does not depend on scale. A single application on a single server is still better off containerised.

# Multi-stage: dependencies resolved in a build image,
# only the runtime and the app land in the final image.
FROM composer:2 AS vendor
WORKDIR /app
COPY composer.json composer.lock ./
RUN composer install --no-dev --optimize-autoloader --no-scripts

FROM php:8.3-fpm-alpine
RUN docker-php-ext-install pdo_mysql opcache
WORKDIR /var/www
COPY --from=vendor /app/vendor ./vendor
COPY . .
USER www-data
CMD ["php-fpm"]

Kubernetes: a real answer to a problem you may not have

Kubernetes is genuinely excellent at what it does. It keeps a declared number of copies of a service running, replaces them when they fail, rolls out new versions gradually, and scales them against load, across a fleet of machines. If you run many services with traffic that swings hard, it pays for itself.

It also needs someone who understands it. Ingress, storage classes, secrets, resource limits and cluster upgrades are a job, not a setting. For one application serving predictable traffic, a managed container service or two well-configured servers behind a load balancer will be more reliable, because it will be understood by the people running it.

"Complexity you cannot debug at 2am is not resilience. It is a second outage waiting behind the first."

AWS, and the parts worth paying for

The cloud services worth buying early are the ones where failure is expensive and unglamorous. Managed databases with automated backups and point-in-time recovery are the clearest example: restoring a database at 3am is not a skill worth developing in-house. Object storage for uploads, a CDN in front of static assets, and managed certificates fall in the same category.

NGINX still sits in front of most of what we deploy, terminating TLS, serving static files and passing everything else to the application. It is unfashionable, well documented and almost never the thing that breaks.

A deployment path that scales with you

Containerise from the first week. Put the build and the tests in CI so every merge produces a tested image. Deploy that image to something simple, and instrument it well enough to know when it is struggling. Move to orchestration when the load, the number of services or the release cadence actually demands it, and not before, because every layer you add is a layer someone has to keep running.