What Are DevOps’ Eight Honors and Shames? Insights from Heroku’s 12‑Factor Manifesto

DevOps Eight Honors and Shames

Today I will discuss the eight "honors and shames" of DevOps and how they correspond to Heroku PaaS’s twelve‑factor manifesto.

DevOps has been popular for five or six years, but implementation is difficult due to varying business contexts and technology roadmaps.

Early technical partners often come from operations or low‑level development, creating tension between new technologies and legacy issues.

Business focus on users can marginalize technology, leading to poor architecture and limited growth.

Therefore, DevOps adoption must be driven top‑down with the courage to challenge tradition.

1. Honor Configurability, Shame Hard‑Coding

Developers know that separating code from variables leads to configuration files; operations should learn to separate software from configuration.

Example: our first version stored all hard parameters in upyun.cfg, allowing a single config function to transform text into a format usable by Nginx.

Using the same configuration for different back‑end software (e.g., swapping Nginx for HAProxy) only requires rewriting the config function.

Common local configuration formats include txt, ini, and cfg. Modern practice prefers YAML, etcd, or Consul for service discovery and registration.

2. Honor Redundancy, Shame Single Points of Failure

Redundancy is a key architectural focus.

Early designs used LVS+Keepalived+VRRP for load balancing and fault isolation; later we adopted OSPF and Quagga for equal‑cost routing.

Nginx can be combined with HAProxy or LVS for load balancing; MySQL can use master‑slave or MMM high‑availability solutions.

Message queues evolved from RabbitMQ to Redis and Kafka, with Kafka now running on a Mesos container platform.

Service discovery and registration can use Consul (Raft), etcd (CoreOS), or Zookeeper (Paxos), each with different algorithms.

Designing a no‑single‑point architecture involves:

Statelessness

No shared state

Loose coupling / asynchronous processing

Distributed / cluster collaboration

3. Honor Immediate Restartability, Shame Unmigratable Systems

Three aspects:

Transition from “Pet” to “Cow” mindset: treat servers as replaceable commodities rather than cherished pets.

OpenStack VM orchestration: virtualization enables storage and migration, though early implementations faced network bottlenecks.

Docker import/export: lightweight isolation and reuse, adopted since 2016 alongside Mesos.

4. Honor Whole‑Delivery, Shame Partial Delivery

Traditional provisioning requires hardware purchase, network setup, OS installation, and configuration, often resulting in only partial delivery.

OpenStack enables cloud compute, network, and storage to be built together for whole‑delivery.

In practice, cloud storage presents the most challenges, while compute and network are mature.

Network performance tests show 10 Gbps NICs achieving up to 9.7 Gbps with jumbo frames.

5. Honor Statelessness, Shame Stateful Services

Stateful services suffer from database, disk, and lock contention, hindering horizontal scaling.

Solutions include reliable middleware (RabbitMQ, etc.), public resource pools (cloud/elastic clusters), and compute‑driven storage (Ceph).

6. Honor Standardization, Shame Special‑Case Handling

Improvements:

Unified input/output via a common configuration file.

Unified process management using Python, YAML, and Ansible playbooks.

Abstracted low‑level design and reusable components, with scripts to automate repetitive tasks.

7. Honor Automation Tools, Shame Manual, Human‑Driven Operations

Early tools included Bash, sed, awk; later we moved to Ansible, Docker, and CDN‑accelerated package distribution.

Automation reduces manual effort, allowing the team to scale three‑fold without increasing headcount.

8. Honor Unattended Operations, Shame Human Intervention

Three pillars:

Automation with standardized, auditable processes.

Continuous monitoring using big‑data log analysis (ELK, Logstash, Heka) to track response codes and latency.

Performance visualization for quick insight.

Essence of DevOps

1. Elasticity

Resources must scale horizontally, support load balancing, and enable roll‑back via OpenStack or Docker.

2. Agnosticism

Abstracted templates hide hardware, OS, and network differences, allowing uniform service consumption.

3. Immutable Infrastructure

Stable base images reduce manual intervention, enabling rapid updates and consistent environments.

Heroku PaaS Twelve‑Factor Manifesto

Codebase: one codebase tracked in version control, deployed many times.

Explicit dependencies: declare all libraries and services.

Config in the environment: store configuration in environment variables.

Backing services as attached resources: treat databases, queues, etc., as external services.

Build, release, run: separate stages, often using Docker containers.

Stateless processes: no shared state, store data in backing services.

Port binding: expose services via ports.

Concurrency: scale via the process model.

Disposability: fast startup and graceful shutdown.

Dev/prod parity: keep development, staging, and production as similar as possible.

Logs as event streams: aggregate logs for analysis.

Admin processes: run one‑off tasks as separate processes.