DevOps Meets ITIL: The View from the Ground

2025-01-18 Henrik Jess
DevOps ITIL Culture Infrastructure Team Collaboration

50+ applications migrated. 10+ cross-functional teams coordinated. One persistent headache: explaining why we can't always wait three weeks for change approval when production needs a fix.

I've been running infrastructure since 1994—back when "DevOps" meant one person doing everything because there was no other choice. These days I work with ITIL-governed organizations while maintaining DevOps principles, and I've learned something critical: the framework war is a distraction from the actual problem.

The challenge isn't frameworks—it's translation. We're solving the same problems with different vocabularies, and nobody's bothering to learn the other language.

Building bridges between DevOps and ITIL

What We're Actually Talking About

Before diving into the conflict, let's be clear about what these frameworks actually are:

ITIL (Information Technology Infrastructure Library) is a framework for IT service management widely adopted across enterprise organizations, government agencies, and large corporations. It provides processes, procedures, and best practices—think change management, incident response, service catalogs, and configuration databases. ITIL's strength is organizational alignment, ensuring IT operations are structured, documented, and aligned with business needs. When you've got 20+ IT staff across multiple countries supporting critical infrastructure, ITIL provides the shared language and processes that prevent chaos. It answers: "How do we manage IT services reliably and predictably across large organizations?"

DevOps is a culture and set of practices that emerged in the late 2000s, emphasizing collaboration between development and operations teams. It prioritizes automation, continuous delivery, infrastructure as code, and rapid iteration. DevOps focuses on speed, feedback loops, and breaking down silos between teams that build software and teams that run it. When you're deploying updates 20 times a day and can't afford to wait three weeks for a change approval, DevOps practices keep you moving fast without breaking things. It answers: "How do we deliver value to users faster while maintaining reliability?"

On paper, they're complementary. In practice, they often clash because practitioners focus on different goals: ITIL teams prioritize stability and governance. DevOps teams prioritize speed and automation. Both want reliable systems that deliver value—they just disagree on how to get there.

The Real Friction Point

Here's what the ITIL-DevOps conflict actually looks like on the ground:

What ITSM hears when DevOps talks:

What DevOps hears when ITSM talks:

The actual disconnect? Neither side explains how their approach manages risk and delivers value. ITSM thinks DevOps is chaos. DevOps thinks ITIL is obstruction. Both are wrong.

Two perspectives working toward one goal

What 30 Years of Infrastructure Taught Me

Running production infrastructure since 1994 required both approaches—I just didn't call them that.

The ITIL parts I was doing without knowing:

The DevOps parts that came naturally:

The point? Both frameworks formalized what experienced operators already knew. The conflict comes when people follow frameworks instead of understanding principles.

Where ITIL Gets DevOps Wrong

ITIL practitioners often misunderstand what DevOps automation actually provides.

Myth: DevOps means no oversight

Reality: DevOps automation is oversight—it's just programmatic instead of manual.

# This Kubernetes deployment has more controls than most CAB meetings
apiVersion: apps/v1
kind: Deployment
metadata:
  name: production-api
spec:
  replicas: 3                    # Minimum availability
  strategy:
    type: RollingUpdate          # Zero-downtime deployment
    rollingUpdate:
      maxUnavailable: 1          # Never take down >1 pod
      maxSurge: 1                # Controlled rollout pace
  template:
    spec:
      containers:

      - name: api
        image: registry.i80.dk/api:v2.3.1  # Immutable, versioned
        resources:
          limits:
            cpu: 500m             # Resource caps prevent runaway processes
            memory: 512Mi
        livenessProbe:            # Automatic health monitoring
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 30
        readinessProbe:           # Traffic only to healthy pods
          httpGet:
            path: /ready
            port: 8080

Every line is a control. Every setting is documented. Every change is tracked in Git. The difference? It's enforced automatically instead of manually verified.

When ITSM teams see "automated deployment," they imagine cowboy changes. What's actually happening:

This isn't less governance—it's consistent governance. Manual processes drift. Automated controls don't.

Automation transforms into governance documentation

Where DevOps Gets ITIL Wrong

DevOps teams often dismiss ITIL without understanding what it's actually solving.

Myth: ITIL is just bureaucracy

Reality: ITIL solves coordination problems automation can't fix.

Here's where I learned this the hard way: migrating 50+ applications to Kubernetes for an organization with compliance requirements.

Pure DevOps approach would be:

  1. Containerize everything
  2. Deploy to Kubernetes
  3. Monitor and iterate

Sounds efficient. Ignores reality.

What ITIL practices actually addressed:

Service catalog management - Stakeholders needed to know which services were migrating when. "Check the Kubernetes dashboard" isn't an answer for finance teams planning budgets.

Change enablement - Not because we needed permission, but because coordinating database migrations, DNS updates, and user communication across departments requires structure.

Incident management - When things break at 2am, a documented escalation path beats "hope someone sees the Slack message."

Configuration management - Auditors don't accept "it's in Git somewhere" as proof of compliance. They want CMDB entries with ownership, dependencies, and approval trails.

The difference? ITIL provides shared vocabulary and expectations across non-technical teams. DevOps tooling is brilliant for technical coordination. It's useless for explaining to Legal why yesterday's deployment meets data residency requirements.

The Translation Layer Nobody Builds

The real problem isn't ITIL vs. DevOps—it's that nobody maps them.

Here's what I've learned works:

Speak Business Language, Automate Technical Controls

What the business needs:

What DevOps provides (once translated):

Business Need DevOps Implementation ITIL Equivalent
Change approval Pull request reviews + automated policy gates Change Advisory Board
Service ownership CODEOWNERS file + on-call rotation Service owner in CMDB
Audit trail Git history + CI/CD logs + Kubernetes events Change log + incident records
Risk assessment Automated testing + gradual rollouts + monitoring Change risk analysis
Availability commitment SLOs defined in code + automated alerting Service Level Agreements

The magic trick? Use ITIL vocabulary in stakeholder communication. Use DevOps tooling in implementation.

Automate the ITIL Artifacts, Not the Decision Process

ITSM teams are right that documentation matters. DevOps teams are right that manual documentation is terrible.

The solution: Generate ITIL-compliant documentation automatically from DevOps tooling.

Example: Change management for Kubernetes deployments

# Automated change record creation
def create_change_record(deployment_manifest, git_commit):
    """
    Generate ITSM change ticket from Kubernetes deployment
    """
    return {
        'change_id': f"CHG-{git_commit[:8]}",
        'change_type': 'standard' if is_standard_change(deployment_manifest) else 'normal',
        'requested_by': get_git_author(git_commit),
        'approved_by': get_pr_approvers(git_commit),
        'implementation_date': deployment_manifest['metadata']['labels']['deploy-time'],
        'affected_services': get_service_dependencies(deployment_manifest),
        'rollback_plan': f"kubectl rollout undo deployment/{deployment_manifest['metadata']['name']}",
        'testing_evidence': get_pipeline_test_results(git_commit),
        'risk_level': calculate_risk(deployment_manifest),
        'audit_trail': f"https://github.com/company/k8s-manifests/commit/{git_commit}"
    }

Push this to your ITSM system's API. Suddenly, your CAB has complete records without anyone filing paperwork.

Benefits:

Define "Standard Changes" for DevOps Patterns

ITIL's concept of "standard changes" (pre-approved changes that follow documented patterns) is perfect for DevOps.

What I defined as standard changes:

Benefits:

The key: Collaborate on defining patterns upfront. Don't ask permission every time. Get pre-approval for categories.

Real-World Example: Azure-to-Kubernetes Migration

When I migrated 50+ applications from Azure VMs to Kubernetes, success required both frameworks.

DevOps practices that made it possible:

ITIL practices that made it successful:

The critical insight: DevOps got the technical work done. ITIL ensured the organization stayed aligned.

Trying to do this with only DevOps? Technical success, organizational chaos. Trying with only ITIL? Perfect documentation of failure to migrate.

Metrics That Actually Matter

Both DevOps and ITIL teams often measure the wrong things.

Vanity metrics nobody cares about:

Metrics that drive business value:

Notice something? These metrics require both frameworks.

You can't improve mean time to value without DevOps automation. You can't prove compliance without ITIL documentation. Both matter.

What I'd Tell Both Teams

To ITSM practitioners:

Stop treating DevOps automation as a threat. It's your opportunity to enforce governance consistently instead of hoping people follow procedures.

The shift:

You'll have better governance, not less. And you'll free up time to focus on actual risk management instead of paperwork.

To DevOps practitioners:

Stop dismissing ITIL as bureaucracy. It's solving coordination problems you'll eventually hit anyway.

The reality:

You're already doing ITIL practices—you just refuse to call them that. Embrace the vocabulary and suddenly you can communicate with the rest of the organization.

The Missing Ingredient: Mutual Respect

Everyone talks about culture, but it goes deeper than "get along."

ITSM teams bring:

DevOps teams bring:

Neither is complete without the other.

The best teams I've worked with recognize this. ITSM engineers learn Kubernetes basics. DevOps engineers attend CAB meetings. Both sides stop treating the other as obstacles and start treating each other as collaborators.

Key Takeaways

The goal isn't making DevOps teams follow ITIL or convincing ITIL teams to abandon process. It's recognizing that fast, reliable, compliant delivery requires both perspectives—and building bridges instead of walls.

After 30 years of infrastructure work and countless migrations, I've learned this: The best systems emerge when operators who understand risk collaborate with engineers who understand automation. That's not ITIL vs. DevOps. That's just good engineering.

About the author: Henrik Jess is a DevOps engineer with 30+ years of infrastructure experience, specializing in Kubernetes migrations and cloud-native architecture. He's run production infrastructure since 1994, evolving from bare-metal Unix servers through VMs to modern container orchestration. Three decades of operations taught him that infrastructure fundamentals remain constant—and that high uptime is earned through understanding failure, not claimed through statistics.

← Back to Articles ← Back to Home