+

Search Tips  |   Advanced Search

DevOps architecture

Run and scale the practices of the IBM Garage Method for Cloud to accelerate the your enterprise application's lifecycle.

DevOps reference architecture

DevOps can look different from one enterprise to another, but some generalizations about architecture apply universally. Any DevOps architecture must include continuous planning, development, integration, deployment, operations, and learning. Continuous testing, security, and compliance must also have a constant presence. All of these elements must be represented in a pipeline that uses automation, an integrated toolchain, and governance.

As you can see in the DevOps constituent architectures, DevOps can be applied to many domains. The perennial favorite is the "DevOps for applications" architecture, which serves as the golden measure for this reference architecture. According to The Modern DevOps Manifesto, "everything is code", and so a near endless set of opportunities exists for pipelines: GitOps, ModelOps, DataOps, and others. DevOps is the root for these modern and relevant permutations.

The inner loop is a highly iterative process that can be run until the developer feels that the feature that they're coding is ready to be deployed into a larger shared environment with running code from other squad members and applications. Continuous development makes the inner loop fast and secure. Developers use curated, trusted enterprise assets, such as images, dependencies, default configs, and application starters, to jump-start their MVP. Through test-driven development, developers can see their working code frequently throughout the day.

The inner loop is often played out on a local workstation or in a ring-fenced sandbox environment where the executable code can't negatively affect other components or developers. The developer's goal is to merge working code into the environment with code from other developers. A pull request indicates that a developer thinks that the code is ready to join the MVP. When the squad leader merges the pull request, they're affirming that the code is ready and that it fulfills the user story.

A merge of source code is the origin event of pipeline automation. The outcome of a build is to transform source code changes into a secure, workable executable package that harmoniously coexists with other secure, workable executable packages. Depending on the enterprise, regulatory compliance, and business criticality of an application, a build can involve a vast array of static source code analysis, dynamic testing, unit testing, security testing, and contract testing to ensure that the appropriate amount of risk is mitigated and compliance is met. The output of a build is an immutable executable package that is ready to deploy into a shared runtime environment with other executable code.

Code wants to live in its runtime state. The immutable executable package that is generated from continuous integration undergoes more dynamic runtime testing to ensure that it is secure, robust, resilient, scalable, and that it can be managed in its runtime environment. In cases where configurations are stored apart from code, continuous deployment marries code to configuration and validates that they work together. Continuous deployment is often broken up into several hierarchical deployment environments that are known as a promotion path—development, test, and production—with varying degrees of testing. Testing can produce failures and violations that require source code changes, diverting the pipeline to go back to continuous development. Ultimately, the output of continuous deployment is a "live" product that reflects the MVP that the business commissioned.

Your MVP is deployed and running, but you're not done yet! Applications can't take care of themselves. Operations provides processes, tools, and the discipline of managing an application to ensure that the application meets expected and obligatory service levels. Although operations is at the end of the DevOps pipeline, it is critical that the plan and design setup start with continuous planning. In fact, continuous development must be influenced by continuous operations, in that application source code must be instrumented so that it can be managed after continuous delivery. Operations also ensures continuous compliance and runtime security intelligence.

How do people use your product? Gather implicit and explicit feedback from users and reflect their needs in the rank-ordered backlog. We can also learn about the product and features in its runtime state, such as how it behaves under certain load conditions and usage patterns, through a dashboard.

The value proposition of DevOps is to increase velocity and quality of delivery. As your pipeline matures, observe and trace significant pipeline events from planning to operations to measure where the pipeline might be slow or what defects are in production. A key output of continuous learning is the replenishment of user stories and work items in the product backlog, which takes you back to continuous planning.


See also