What Are the 7 Pillars of DevOps in the AI Era? A Practical Breakdown

Search for the pillars of DevOps and the results disagree on how many there are, and on what each one is called. The same author, Marc Hornbeek, has published a seven-pillar list and a nine-pillar one. That’s awkward when an interviewer or an appraisal form expects one clean answer. It gets worse with the follow-up, because DevOps in the AI era has changed which of those pillars carries the most weight, and a memorised list won’t help you defend a view on that.

What are the 7 pillars of DevOps?

The 7 pillars of DevOps are collaborative culture, continuous integration, continuous testing, continuous delivery, infrastructure as code, monitoring and feedback, and built-in security. No standards body publishes an official list, so wording varies by source. Each of the seven maps to a pillar in Marc Hornbeek’s DevOps framework and to a capability in Google Cloud’s DORA catalog.

That makes the list a synthesis, and it helps to know what it was built from. In an August 2016 post, Marc Hornbeek described seven areas that Trace3 called “The Seven Pillars of DevOps”. His book Engineering DevOps later organised the field into nine pillars: leadership, collaborative culture, design for DevOps, continuous integration, continuous testing, elastic infrastructure, continuous monitoring, continuous security and continuous delivery. The seven used here fold leadership into culture, treat architecture (his design for DevOps) as a precondition for continuous delivery, and name the infrastructure pillar after its practice. DORA, the research programme Google Cloud runs, maintains a capability catalog drawn from its research, and every pillar below has at least one matching entry there.

Collaborative culture is hard to test with a definition, so it tends to arrive as a story question. “Tell me about an incident you were part of” is one, and a blameless answer that ends with a changed alert or a new test says more than any definition.

Continuous integration and continuous testing only work as a pair. Merging to main several times a day without an automated suite you trust just moves broken code around faster.

Continuous delivery is often confused with continuous deployment. DORA separates them: continuous delivery is the ability to release changes on demand, quickly and safely, while continuous deployment means pushing every change to production as soon as possible. DORA notes that continuous deployment suits web services but can’t be applied to firmware or mobile apps, and continuous delivery applies to all of them.

Infrastructure as code is what makes the other pillars repeatable. DORA’s guidance on flexible infrastructure describes configuration checked into version control and applied through an automated mechanism, which gives every environment change a log and an audit trail. If you work with Kubernetes, the guide to Kubernetes cluster architecture covers the control plane that this code ends up driving, and Ansible architecture and inventory covers the configuration-management side.

Monitoring and feedback includes measuring delivery itself. DORA’s guide to its software delivery metrics describes a shift “from the original four keys to the current five-metric model”. Three of the five measure throughput: change lead time, deployment frequency and failed deployment recovery time. Two measure instability: change fail rate and deployment rework rate. Failed deployment recovery time replaced the older MTTR measure.

Built-in security has a pillar model of its own, the six pillars of DevSecOps, which get their own section further down this page.

What are the 7 C’s of DevOps, and how do they differ from the pillars?

The 7 C’s of DevOps are continuous development, continuous integration, continuous testing, continuous deployment, continuous monitoring, continuous feedback and continuous operations. The C’s name activities that run continuously through the delivery loop. The pillars of DevOps name capabilities an organisation must sustain, including culture and security, which none of the seven C’s covers by name.

“The 7 phases of DevOps” usually means the same list. roadmap.sh, for example, describes “the 7 key phases of the DevOps lifecycle, also known as the 7 C’s of DevOps”. Tool vendors use other names again. Atlassian’s DevOps tools guide gives seven phases in one list, then organises the same page under eight headings: Discover, Plan, Build, Test, Deploy, Operate, Observe and Continuous Feedback. If one company’s page can hold two counts, you shouldn’t expect an interviewer’s list to match yours word for word.

Tap to enlarge

Three other frameworks get mixed into the same conversation, and it’s worth being able to name each one.

• CALMS stands for Culture, Automation, Lean, Measurement and Sharing. Atlassian attributes the acronym to Jez Humble, co-author of The DevOps Handbook, and describes it as a way to assess an organisation’s readiness for DevOps and measure progress during a transformation.
• The Three Ways, set out by Gene Kim in a 2012 IT Revolution article, are Flow/Systems Thinking, Amplify Feedback Loops, and a Culture of Continual Experimentation and Learning. They’re principles, and the pillars read more like an implementation checklist for them.
• The AWS Well-Architected Framework also has pillars, six of them: operational excellence, security, reliability, performance efficiency, cost optimization and sustainability. They describe how to architect a cloud workload, so they answer a different question from the pillars of DevOps.

When someone asks you for “the pillars” in a meeting, the safest move is to name your framework and its source in one sentence before listing anything. Answering a CALMS question with the 7 C’s sounds like you memorised the wrong list, even when you understand both.

What are the core phases of the DevOps lifecycle, and where does AI fit into each one?

A practical version of the DevOps lifecycle runs plan, build, test, deploy, operate, observe and feedback, then loops back to planning. AI now assists in every phase, from drafting code to correlating alerts. Google Cloud’s 2025 DORA report linked AI adoption to higher delivery throughput and lower delivery stability, so every phase needs stronger checks as AI speeds it up.

That report, State of AI-assisted Software Development, was announced on 24 September 2025 and draws on survey responses from nearly 5,000 technology professionals. 90% of respondents reported using AI at work, and 30% reported little or no trust in AI-generated code. DORA explains the stability drop this way: “Without robust control systems, like strong automated testing, mature version control practices, and fast feedback loops, an increase in change volume leads to instability.”

Tap to enlarge

AIOps is the name for the operate and observe rows. IBM defines it as the application of AI capabilities to IT operations, and lists anomaly detection, root cause analysis and event correlation among the jobs machine learning does there. It adds no eighth pillar. AIOps runs on the telemetry the monitoring and feedback pillar produces, so it can only be as good as that data, and DORA’s AI Capabilities Model lists healthy data ecosystems among the seven capabilities that amplify AI’s benefits. The same dependency shows up in course sequencing: in the DevOps with AI Masters Program, the AI module follows the monitoring, logging and observability module.

For what AI agents actually do inside a pipeline and what breaks in practice, see AIOps in DevOps. Agentic DevOps looks at whether agents can run the delivery lifecycle end to end, and the AI-native SDLC explains why planning, testing, governance and deployment became the slow stages once code generation sped up.

What are the six pillars of DevSecOps, and how does security fit into the broader DevOps framework?

The six pillars of DevSecOps, from the Cloud Security Alliance working with SAFECode, are collective responsibility, collaboration and integration, pragmatic implementation, bridging compliance and development, automation, and measure, monitor, report and action. Within the broader DevOps framework, security is the seventh pillar and a property every other pillar must carry.

The list comes from a published paper series. CSA released the first paper, The Six Pillars of DevSecOps: Automation, on 7 July 2020, produced by its DevSecOps Working Group in collaboration with SAFECode.

Security fits the wider framework in two ways at once. It’s a pillar with its own practices, and it’s a property of the other six: a CI stage that scans dependencies, infrastructure code reviewed like any other change, monitoring that feeds incident response. DORA calls this capability pervasive security and describes it as shifting security concerns earlier in the lifecycle. For the hands-on side, including secrets management and image scanning, see security in the pipeline.

Tap to enlarge

AI adds new material to at least two of the six pillars. Under pragmatic implementation, a pipeline that includes an LLM feature or an agent faces threats the OWASP Top 10 for LLM Applications 2025 names directly, including LLM01:2025 Prompt Injection, LLM03:2025 Supply Chain and LLM06:2025 Excessive Agency. Under bridging compliance and development, the supply chain you have to account for now includes models and datasets as well as packages. NIST SP 800-204D, published in February 2024, covers the software side with strategies for integrating supply chain security into DevSecOps CI/CD pipelines.

For teams in India, two CERT-In documents turn DevSecOps pillars into specific obligations and guidance:

1. CERT-In’s Directions of 28 April 2022, issued under section 70B(6) of the IT Act, require service providers, intermediaries, data centres, body corporates and government organisations to report the incident types listed in the directions to CERT-In within 6 hours of noticing them. The same directions require logs of all ICT systems to be kept securely for a rolling 180 days within Indian jurisdiction. That’s the measure, monitor, report and action pillar with a deadline attached. For example, a log pipeline that keeps two weeks of data leaves a covered organisation short of the requirement.
2. CERT-In’s Technical Guidelines on SBOM, QBOM & CBOM, AIBOM and HBOM (Version 2.0, dated 9 July 2025) define an AI Bill of Materials as a list of the components used to build, train and deploy AI models, including hardware, software, frameworks and data sources. The guidelines encourage SBOMs as standard practice, particularly for government, public sector, essential services, and software export and services organisations. This is where bridging compliance and development meets the AI supply chain.

How is AI changing which DevOps pillar matters most for career growth in 2026?

The 2025 DORA findings point career value toward the DevOps pillars that keep fast change safe: continuous testing, monitoring and feedback, and built-in security, delivered through infrastructure as code and internal platforms. DORA links AI adoption to lower delivery stability and attributes that to weak testing, version control and feedback loops, which makes those control pillars hard to automate away.

The platform part comes from the same report. DORA found that 90% of organisations have adopted at least one platform, and reported a direct correlation between a high-quality internal platform and an organisation’s ability to get value from AI. For a DevOps engineer, that turns the infrastructure-as-code pillar into platform engineering: building the paved route an AI-generated change travels from pull request to production, with tests, policy checks and rollback built in.

If you’re choosing one pillar to go deep on this year, the strongest case is for monitoring and feedback. It’s where AI-driven instability becomes visible in production. AIOps runs on its data. And it lets you put numbers on your impact with DORA’s five delivery metrics. Security makes a close second if you work in banking, telecom, government or any organisation covered by CERT-In’s incident-reporting directions.

Writing the first draft of a pipeline file, a Terraform module or a Helm chart is getting cheaper. That’s an inference, not a measured finding. It does fit DORA’s picture of near-universal AI use alongside 30% of respondents reporting little or no trust in AI-generated code. Teams generate this material quickly and still need someone who can tell whether it will survive production.

What that looks like depends on the conversation you’re preparing for.

• In a DevOps engineer interview, be ready to give your service’s change fail rate and failed deployment recovery time, or to explain honestly why your team doesn’t measure them yet. Then walk through one incident where monitoring caught a bad change, or missed it, and what you changed afterwards.
• As a systems architect, expect a design question with AI in the path: how does a change nobody typed by hand get to production safely? Answer in pillar terms first (tests, version control, small batches, policy as code, rollback) and bring in tool names after.
• For an IT manager or director in an appraisal or team-lead discussion, the questions move up a level. Does the team have what DORA calls a clear and communicated AI stance, meaning people know which AI tools are permitted and how? Could you meet a 6-hour CERT-In reporting window tonight? Do you know which third-party and AI components are in what you ship?

For how responsibilities widen at each career stage, see the DevOps career roadmap. For the engineering skills AI is repricing across software roles generally, see AI skills for software engineers.

Frequently asked questions