Disposability, parity, logs, and admin
Factors IX–XII — fast startup/shutdown, dev/prod parity, logs as event streams, and one-off admin tasks.
IX. Disposability
Processes start quickly and shut down gracefully on SIGTERM. They are disposable — crash and relocate cheaply. Long startup and ignored signals make deployments and autoscaling painful.
X. Dev/prod parity
Keep development, staging, and production as similar as practical: same backing service types, same artifact, continuous deploy so gaps stay small. “SQLite in dev, Oracle in prod” is a classic parity failure.
Containers and compose/K8s help; they do not fix wildly different topologies or config mechanisms.
XI. Logs
Treat logs as event streams on stdout/stderr. The platform ships and aggregates them. Do not manage log files inside the app (rotation, proprietary agents as the only path) unless the platform requires a special case.
Structure logs for search; include correlation ids.
XII. Admin processes
Run one-off admin/management tasks as one-off processes in the same release environment against the same codebase and config — migrations, consoles, scripts — not unversioned SSH rituals.
Senior practice today
- K8s Jobs/CronJobs for XII; preStop and readiness for IX
- Parity is a gradient: same shape and artifact matter more than identical replica counts