Skip to content

12 Factors That Will Change How You Achieve Operational Excellence


As a member of a product team you are constantly striving for operational excellence of your product. Yet, this pursuit often comes with its own set of challenges. You might find yourself wrestling with not only the complexities of deploying applications across diverse environments but also the broader goal of achieving peak operational efficiency. These aren’t just technical hurdles; they are critical obstacles on your path to excellence. There are 12 factors that will change how you achieve operational excellence. The 12 factors offer innovative solutions in the often turbulent world of software development and deployment.

The 12 factors are a collection of principles; They are also a comprehensive strategy for building applications that are not only scalable and adaptable but also designed for operational excellence. Imagine deploying with the confidence that comes from knowing your application and operational processes are optimized for success in any setting.

In this deep dive, we’re going to explore each of the twelve factors with practical, real-world examples. We’re not just addressing the technicalities but we’re focusing on how these principles can elevate your operational excellence. This journey is about empowering you with the tools and knowledge to enhance your operational workflow, making it as efficient and effective as possible. Get ready to transform your approach to DevOps, turning every challenge into a stepping stone towards operational excellence.

So let’s start

I. Codebase: One Codebase, Many Deployments

In-Depth: The codebase should be version controlled and singular for each project, but it can be deployed in multiple environments (development, testing, production). This approach is akin to a chef using the same recipe to create different versions of a dish for various events. Each deployment might have its own characteristics (like ingredients or presentation style), but the foundational recipe (codebase) remains constant.

II. Dependencies: Explicitly Declare and Isolate Dependencies

In-Depth: Your application should explicitly declare all dependencies, not assuming they are present in the deployment environment. This is similar to a mechanic listing all tools and parts needed for a car repair, ensuring they have everything required, rather than assuming the garage stocks them. This approach guarantees consistency across all environments, eliminating the “it works on my machine” problem.

III. Config: Store Config in the Environment

In-Depth: Configuration options (database URLs, credentials, etc.) should be stored in the environment, separate from the code. For example having different sets of clothes for various occasions (work, home, gym); the clothes change, but the person remains the same. This separation prevents sensitive data from being included in the codebase and allows the application to adapt to different environments seamlessly.

IV. Backing Services: Treat Backing Services as Attached Resources

In-Depth: All backing services, like databases or messaging systems, are treated as attached resources, which can be attached or detached to deployments without code changes. For example using removable storage drives on different computers; the drives (services) are interchangeable and independent of the computers (deployments).

V. Build, Release, Run: Strictly Separate Build and Run Stages

In-Depth: Separate out build, run and release stages. The build stage turns code into a build, which combines with the config to create a release. The run stage runs the app in the execution environment. For example scriptwriting (build), dress rehearsal (release), and opening night (run).

VI. Processes: Execute the App as One or More Stateless Processes

In-Depth: Execute the application as one or more stateless processes. Each process should be disposable, meaning it can start or stop at a moment’s notice. Taxis (processes) operate independent. For example adding or removing the number of taxis based on demand, and don’t retain information between trips (stateless).

VII. Port Binding: Export Services via Port Binding

In-Depth: Make services available to other services or the network through port binding. For example, assigning different boxes (ports) for different types of correspondence (services) in a mailroom in an office building, to organize everything

VIII. Concurrency: Scale Out via the Process Model

In-Depth: The application should scale out via the process model. For example, handle more web traffic by running more web processes. This can be likened to a restaurant increasing its serving capacity by adding more chefs (processes) in the kitchen.

IX. Disposability: Maximize Robustness with Fast Startup and Graceful Shutdown

In-Depth: Fast startup and graceful shutdown maximize robustness. Start applications rapidly and shut down gracefully, to scale quickly and without issues. For example LED lights which turn on/off instantly, providing immediate response to changes.

X. Dev/Prod Parity: Keep Development, Staging, and Production as Similar as Possible

In-Depth: The development, staging, and production environments should be as similar as possible. This minimizes issues during deployments and ensures consistency. It’s akin to an athlete training under conditions that closely mimic the actual competition environment, ensuring preparedness.

XI. Logs: Treat Logs as Event Streams

In-Depth: Treat logs as event streams, flowing out of the application, captured, and stored for analysis without the application’s direct involvement. This is like a surveillance system in a store; it continuously records activities (logs) without interfering with the day-to-day business operations.

XII. Admin Processes: Run Admin/Management Tasks as One-off Processes

In-Depth: Run administrative or management tasks as one-off processes. These might include database migrations or one-time scripts. Similar to performing routine maintenance on a vehicle; these tasks are essential for performance and longevity and done separate from the vehicle’s regular operation.

Real life Examples

Embracing the 12-factor methodology is adopting a set of guidelines. Its’s about cultivating a mindset that appreciates the nuances of modern software development. It’s a commitment to creating applications that are robust and scalable and adaptable to the ever-changing technological landscape.

As a seasoned team member, mastering these principles enables you to construct systems. These systems excel in operational efficiency, offer unparalleled user experiences, and stand resilient in the face of evolving demands. The 12 factor methodology isn’t just about building better software; it’s to change how you achieve operational excellence.

Embark on this journey with the 12-factor architecture to transform your applications and your approach to DevOps.

The 12-factor architecture serves as a set of guidelines to accommodate the needs of various projects and teams. While it is important to follow the principles of the 12 factor architecture, it is also important to be flexible and open to adapting the guidelines to fit the unique needs and constraints.

Real life applications built using the 12-factor architecture
  1. Heroku: is a cloud platform that was developed by the team that created the 12 factor architecture. It is designed to make it easy for developers to build, deploy, and scale web applications using the principles of the 12 factor architecture.
  2. Netflix: Netflix is a popular streaming service that has adopted the 12 factor architecture to build and deploy its applications. By following the principles of the 12 factor architecture, Netflix has been able to scale its operations and maintain a high level of availability for its users.
  3. Airbnb: Airbnb is a popular vacation rental platform that has adopted the 12 factor architecture to build and deploy its applications. By following the principles of the 12 factor architecture, Airbnb has been able to scale its operations and handle the high volume of traffic and transactions on its platform.
  4. Slack: Slack is a popular team collaboration and communication platform that has adopted the 12 factor architecture to build and deploy its applications. By following the principles of the 12 factor architecture, Slack has been able to scale its operations and provide a reliable service to its users.

These examples represent a few real-life applications built using the 12-factor architecture. Many organizations demand the adoption of the 12-factor architecture to transform their approach to achieving operational excellence


  1. Software Craftsmanship
  2. Value Stream Mapping
  3. 12 factor architecture according to RedHat

Join the conversation

Your email address will not be published. Required fields are marked *