1) Org Silos & Slow Flow From Idea → Prod

Symptoms: “Throw-over-the-wall” handoffs, long lead time, many approvals, unclear ownership, ops drowning in tickets.
Root causes: Functional silos, unclear boundaries, local optimizations (team KPIs) that fight global flow, change-aversion culture.

What to do

• Team Topology: Product-aligned, cross-functional “you build it, you run it” teams. Create a platform team that offers paved roads (golden paths).
• Flow Practices: Trunk-based development, small batch sizes, WIP limits, value stream mapping (find big queues & cut wait time).
• Policy-by-Default: Default-approve low-risk changes (risk-based change mgmt) when automated checks pass.
• Governance via Metrics: Run the org on DORA metrics: Lead Time, Deployment Frequency, Change Failure Rate, MTTR.

Tech enablers: Backstage (IDP), feature flags, branch protection, CODEOWNERS, reusable pipeline templates, golden repos/templates.

KPIs:

• Lead time (PR opened → prod) < 1 day for majority of changes
• Deployment frequency daily or more per service
• CFR < 15%; MTTR < 1 hour for sev2

Anti-patterns: CABs that approve everything manually; ticket-driven ops for every deploy; environment “ownership ping-pong”.

2) CI/CD at Scale: Flaky, Slow, Unreliable Pipelines

Symptoms: 40–90 min pipelines, frequent flaky tests, long-lived branches, release day drama.
Root causes: Bloated stages, non-hermetic builds, shared mutable environments, lack of test strategy.

What to do

• Pipeline Architecture
  • Make builds hermetic & cacheable (deterministic deps, lockfiles, remote build cache).
  • Split into fast fail stages (lint/typecheck/unit) before slow ones (integration, e2e).
  • Parallelize & shard tests; quarantine flaky tests with automatic deflake jobs.
• Test Strategy (Pyramid + Contracts)
  • Pyramid: unit (many), integration (some), e2e (few).
  • Add consumer-driven contract tests for microservices; shift many e2e checks into contracts.
• Ephemeral Environments
  • Spin preview environments per PR (K8s namespace/Helm or Terraform workspace) seeded with minimal test data.
• Quality Gates
  • Static analysis (style, lint, security), coverage deltas, performance budgets, SBOM and image scans as PR gates.
• Release Strategies
  • Progressive delivery: canary, blue/green, auto-rollback on SLO/SLA signals.

Tech enablers: GitHub Actions/GitLab CI/Tekton; Artifactory/ECR/GCR; Argo Rollouts/Flagger; Pact for contracts; SonarQube; Testcontainers.

KPIs:

• Median pipeline time < 10–15 min for PR checks
• Flaky test rate < 1%; time-to-fix flaky < 48h
• >95% PRs get a preview environment

Anti-patterns: Everything is an end-to-end test; shared QA env bottleneck; manual smoke tests on prod.

3) Software Supply Chain & Cloud Security (DevSecOps)

Symptoms: Secrets in repos, surprise CVEs, unknown provenance of images, drift in policies across clusters.
Root causes: Late security gates, unpinned deps, opaque build steps, manual exceptions.

What to do

• Shift-Left Security
  • SAST & SCA on PRs; container & IaC scans (Terraform/K8s) before merge.
  • Pin dependencies, enforce renovation (Renovate/Dependabot) with risk-tiered auto-merge.
• Provenance & Integrity
  • Build SBOM (CycloneDX/Syft) per artifact; sign images & attestations (cosign/sigstore, in-toto).
  • Aim for SLSA Level 3 practices: isolated builders, tamper-evident provenance, policy on verified signatures at deploy.
• Policy-as-Code
  • Admission control with OPA Gatekeeper or Kyverno for baseline: disallow :latest, require non-root, resource limits, required labels, only-signed images.
• Secrets & Identity
  • Centralized secrets mgmt (Vault/Secrets Manager), short-lived creds, IRSA/Workload Identity, no long-lived keys in CI.
• Runtime Guardrails
  • Pod Security Standards, minimal base images, read-only FS, network policies, egress control.

KPIs:

• % images signed & verified in prod = 100%
• Mean time to remediate critical vulns < 7 days
• Policy violations per deploy trend ↓ month over month

Anti-patterns: Security as a final gate; blanket whitelists; unscanned base images; secrets sprinkled in env vars & git.

4) Environment Drift & Configuration Chaos (Infra & App Config)

Symptoms: “Works in staging, fails in prod”, hand-edited clusters, mystery configs, emergency shell fixes.
Root causes: Manual changes, unversioned infra, mixed responsibilities, mutable long-lived envs.

What to do

• Everything-as-Code
  • Infra via Terraform/Pulumi; K8s via Helm/Kustomize; no manual kubectl apply to prod.
• GitOps for Deploy
  • Argo CD/Flux watches a single source of truth; changes are pull-requested, reviewed, and auto-applied.
  • Promotion via tags/branches (dev → uat → prod) with the same manifests and only value overrides.
• Modules & Reusability
  • Terraform and Helm modules with versioning; a registry of “golden” modules (VPC, EKS, DB, Kafka topics).
• Drift Detection
  • terraform plan in CI; Argo diff policies; alerts on out-of-band changes; periodic reconciliation reports.
• Config Hygiene
  • Strict resource requests/limits; config schema checks; feature flags for behavior, not environment forks.

Tech enablers: Terraform Cloud/Atlantis; Argo CD/Flux; Helmfile; ConfTest/OPA; Feature flag platforms.

KPIs:

• % infra/app changes via PR = 100%
• Config drift incidents → 0
• Mean time from merge to deploy minutes, not hours

Anti-patterns: Long-lived snowflake environments; divergent Helm charts per env; “quick fix on prod” shell sessions.

5) Observability, Reliability & Cost (SRE + FinOps)

Symptoms: Alert fatigue, slow incident detection, unknown blast radius, runaway cloud bills.
Root causes: Tool sprawl, metric overload, logs without sampling, no SLOs, ambiguous ownership, no cost guardrails.

What to do

• Observability First
  • Standardize on OpenTelemetry for traces/metrics/logs; propagate trace IDs end-to-end.
  • SLOs + Error Budgets per service (user-centric). Alert on symptoms, not causes (e.g., elevated 5xx & latency).
• Incident Ops
  • Runbooks & auto-remediation (known failure signatures → actions), practiced on-call, postmortems with actionable follow-ups.
  • Progressive delivery hooks to auto-roll back on SLO breaches.
• FinOps
  • Cost allocation tags everywhere; dashboards of $/txn, $/service.
  • K8s rightsizing (requests/limits), autoscaling (HPA/VPA/Karpenter), spot where safe, storage lifecycle policies, log sampling & tiering.
• Capacity & Resilience
  • Chaos experiments on critical paths (retry/backoff/timeouts), circuit breakers, bulkheads, multi-AZ as default.

Tech enablers: OTel, Prometheus/Tempo/Loki or vendor suite; incident tooling (pager/runbook); Karpenter; cost tools (native & 3rd-party).

KPIs:

• MTTR < 30–60 min; alert acknowledgement < 5 min
• Alert noise: actionable alerts > 80%
• Cost per request stable/↓ while traffic ↑ (efficiency trend)

Anti-patterns: Alerting on every low-level metric; 90-day log hoarding; infinite cardinality labels; no trace sampling.

A Reference Delivery Flow (Put It Together)

1. Developer opens PR → fast PR checks (lint, unit, SAST/SCA, IaC scan)
2. Build hermetic artifact → produce SBOM → sign image + provenance
3. Spin preview environment → run integration/contract tests
4. On merge, publish version & update GitOps repo (env overlays)
5. Argo CD syncs → progressive delivery (canary) gated by SLOs/health
6. OTel traces + metrics feed autoscaling & rollback logic
7. Post-deploy verification + auto-change record
8. Cost & reliability scorecards roll up weekly

30 / 60 / 90 Day Rollout

First 30 days (Foundations)

• Pick 1–3 “lighthouse” services.
• Introduce trunk-based dev on those repos; enable PR checks and preview envs.
• Baseline DORA metrics; create SLOs for at least 1 user journey.
• Start SBOM + image signing; gate deploys on signatures in non-prod.
• Terraform plan in CI; Argo CD for one environment.

Days 31–60 (Scale the Paved Road)

• Expand GitOps to all envs of lighthouse services; DRY Helm/TF modules.
• Add contract tests; quarantine & deflake.
• Enforce policy-as-code (Kyverno/Gatekeeper) cluster-wide.
• Incident runbooks, paging, and error budgets enforced; begin progressive delivery.

Days 61–90 (Org & Economics)

• Roll paved road org-wide; codify golden repo templates.
• FinOps tagging, request/limit hygiene; introduce Karpenter/VPA where fit.
• Sign & verify all prod images; SLSA-3 style provenance for critical pipelines.
• Quarterly VSM (value stream map) review; tie OKRs to DORA & SLOs.

Quick Wins (This Week)

• Turn on branch protection + required PR checks for one critical service.
• Add SBOM generation + image signing to that pipeline.
• Enable preview environments for PRs.
• Create 1 SLO (latency & 5xx) and alert only on budget burn.
• Add OPA/Kyverno policies: block :latest, enforce non-root, require limits.

Tooling Examples (pick equivalents you already use)

• CI/CD: GitHub Actions / GitLab / Tekton
• GitOps: Argo CD / Flux
• Progressive delivery: Argo Rollouts / Flagger
• Security: SonarQube, Trivy/Grype, cosign/sigstore, OPA/Kyverno, Renovate/Dependabot
• Testing: Jest/JUnit + Pact + Testcontainers
• Obs: OpenTelemetry, Prometheus, Tempo/Jaeger, Loki, Datadog/New Relic
• Infra: Terraform, Helm/Kustomize, Karpenter, External Secrets/Vault
• Platform/DevEx: Backstage, golden templates

Self-Assessment Checklist

• DORA metrics visible per service; lead time < 1 day for most changes
• Every deploy is GitOps-driven; no manual edits in prod
• SBOM + signed images; deploys verify signatures
• SLOs exist for top user journeys; alerts map to them
• Preview envs for PRs; pipeline median < 15 min
• Policy-as-code enforces baseline security in clusters
• Cost per txn monitored; autoscaling and rightsizing in place

DevOps is a transformative approach that helps organizations streamline their software development and IT operations. By fostering collaboration, automation, and continuous improvement, DevOps aims to accelerate software delivery while maintaining high standards of quality and reliability. However, implementing DevOps is not without its challenges. Organizations often face obstacles ranging from cultural resistance and skill gaps to tool integration and security concerns.

In this post, we will explore the top challenges faced during DevOps implementation and highlight key features and strategies to overcome these hurdles.

1. Cultural Resistance and Organizational Change

Major Features:

• Resistance to Change:
  • One of the biggest challenges in DevOps adoption is overcoming cultural resistance. Traditional organizational structures, where development and operations teams work in silos, can be difficult to change. Employees may resist new practices due to fear of the unknown, concerns about job security, or a reluctance to change established workflows.
• Misalignment of Teams:
  • DevOps requires collaboration between development, operations, security, and other teams. However, aligning different teams with common goals can be difficult if there is a history of siloed work environments. Misalignment can lead to inefficiencies and delays in the implementation of DevOps processes.
• Lack of DevOps Mindset:
  • Successful DevOps implementation depends on a shift in mindset, from focusing on individual team goals to prioritizing business objectives, collaboration, and continuous improvement. Without a DevOps-centric mindset, organizations may struggle to achieve the intended outcomes of faster software delivery and higher quality.
• Solution:
  • Overcoming cultural resistance requires strong leadership, clear communication, and continuous education. Leadership should emphasize the benefits of DevOps, including improved collaboration and accelerated delivery. Training and workshops can also help employees embrace the DevOps culture and encourage buy-in.

2. Skill Gaps and Talent Shortage

Major Features:

• Lack of DevOps Expertise:
  • Many organizations face challenges finding qualified DevOps professionals who possess the necessary technical and soft skills. DevOps requires a unique blend of skills, including programming, automation, system administration, cloud computing, and security, which makes it difficult to find professionals who can effectively implement and manage DevOps practices.
• Continuous Learning and Adaptation:
  • DevOps tools and practices evolve rapidly, requiring professionals to stay up-to-date with new technologies and methodologies. Organizations must invest in continuous learning and upskilling to ensure that their teams can keep pace with emerging trends.
• Cross-Disciplinary Knowledge:
  • DevOps engineers must have knowledge of both development and operations, which means a broad skill set across programming languages, infrastructure management, automation tools, and cloud platforms. This makes it challenging for organizations to find individuals with the right mix of skills.
• Solution:
  • To address skill gaps, organizations should invest in training programs, certifications, and workshops to upskill their existing workforce. Additionally, promoting cross-functional collaboration and mentoring programs can help build a strong DevOps culture and reduce reliance on external hires.

3. Tool Integration and Complexity

Major Features:

• Managing Multiple Tools:
  • DevOps involves the use of various tools for tasks such as version control, CI/CD, automation, monitoring, and security. However, integrating these tools into a cohesive workflow can be challenging, especially when tools don’t easily communicate with each other.
• Tool Sprawl:
  • With so many available DevOps tools, organizations may struggle to manage tool sprawl, where multiple tools are used for similar purposes. This can lead to inefficiencies, confusion, and difficulty in maintaining consistency across teams.
• Tool Compatibility:
  • The compatibility of tools can also be an issue, particularly when integrating legacy tools with newer DevOps platforms. Ensuring that all tools work seamlessly together is essential for creating an efficient DevOps pipeline.
• Solution:
  • Adopting an integrated DevOps platform that combines multiple functionalities (e.g., GitLab, Jenkins, or Azure DevOps) can help streamline the process and reduce the complexity of managing multiple tools. Standardizing on a set of tools and ensuring that they are well-integrated can help reduce friction and improve collaboration.

4. Security and Compliance Concerns (DevSecOps)

Major Features:

• Integrating Security into DevOps:
  • One of the biggest challenges in DevOps is ensuring that security is not compromised during rapid development cycles. In traditional development environments, security often becomes an afterthought, but DevOps demands that security is embedded throughout the software development lifecycle (SDLC), also known as DevSecOps.
• Balancing Speed and Security:
  • DevOps emphasizes continuous delivery and rapid releases, but security measures must not be neglected. This balance between speed and security is often a difficult challenge, as integrating security checks into fast-moving pipelines can slow down development.
• Compliance and Regulatory Requirements:
  • Organizations must comply with industry regulations such as GDPR, HIPAA, and PCI-DSS. Integrating these compliance requirements into the DevOps pipeline requires careful planning and the use of automated tools to ensure adherence to legal and security standards.
• Solution:
  • Adopting a shift-left security approach, where security is addressed early in the development cycle, is key to overcoming these challenges. Tools like SonarQube, Snyk, and OWASP ZAP can automate security testing and vulnerability scanning within the CI/CD pipeline. Regular audits and ongoing training for security best practices will also help mitigate security risks.

5. Scalability and Infrastructure Management

Major Features:

• Managing Complex and Distributed Systems:
  • As organizations scale their applications and infrastructure, managing complex, distributed systems becomes increasingly difficult. DevOps must account for scaling infrastructure automatically to meet demand without impacting performance or availability.
• Automated Infrastructure Provisioning:
  • DevOps requires infrastructure to be provisioned, configured, and managed automatically. However, automating infrastructure tasks at scale presents challenges in ensuring consistency, compliance, and security across environments.
• Cost Management:
  • Scaling infrastructure can result in increased costs, especially when working with cloud platforms. Managing costs while ensuring scalability requires careful planning and monitoring of resources.
• Solution:
  • Infrastructure as Code (IaC) tools like Terraform and CloudFormation help automate infrastructure provisioning and management, ensuring that systems can scale seamlessly. DevOps teams should also implement cloud cost management tools to monitor and optimize resource usage.

6. Monitoring and Continuous Improvement

Major Features:

• Real-Time Monitoring:
  • Continuous monitoring of applications and infrastructure is essential for detecting issues early, but achieving real-time monitoring at scale can be difficult. Without proper monitoring, issues may go unnoticed until they affect end users.
• Data Overload:
  • As systems scale, the amount of data generated by monitoring tools increases. This data can become overwhelming, making it difficult for teams to quickly identify critical issues.
• Continuous Improvement:
  • DevOps relies on the principle of continuous improvement, but organizations can struggle with setting up systems to collect and analyze feedback effectively. Without actionable insights, teams may miss opportunities for optimization.
• Solution:
  • Implementing centralized logging and monitoring systems (e.g., Prometheus, Grafana, ELK Stack) provides a unified view of system performance. Additionally, leveraging automated tools to analyze performance data and provide feedback can help drive continuous improvement across the DevOps pipeline.

Overcoming DevOps Implementation Challenges

While DevOps offers significant benefits, organizations must be prepared to face various challenges during its implementation. From overcoming cultural resistance and addressing skill gaps to managing tool integration and ensuring security, each challenge requires a strategic approach and commitment from leadership. By adopting best practices, investing in training, and leveraging the right tools, organizations can successfully implement DevOps and unlock its full potential.

With the right strategies and a proactive approach, these challenges can be turned into opportunities for improvement, resulting in faster software delivery, higher-quality applications, and better collaboration between development and operations teams.

DevOps is a transformative approach to software development and IT operations that emphasizes collaboration, automation, and continuous improvement. However, adopting and implementing DevOps can be a complex and challenging journey for many organizations. From resistance to change and cultural issues to technical hurdles and tool integration, there are several challenges that teams face when adopting DevOps practices.

In this post, we will explore some of the major challenges that organizations face when implementing DevOps, along with their key features and practical solutions for overcoming them.

1. Cultural and Organizational Resistance

Major Features:

• Resistance to Change:
  • One of the primary challenges of DevOps adoption is overcoming resistance to change within the organization. Traditional siloed structures, where development and operations teams work independently, are often deeply ingrained, making it difficult for teams to collaborate effectively.
• Lack of Collaboration Between Teams:
  • DevOps relies heavily on strong collaboration between development, operations, and other departments such as quality assurance and security. In many organizations, these teams are siloed and reluctant to change their long-established workflows, leading to delays in adoption.
• Misalignment of Goals and Objectives:
  • Development teams may be focused on feature delivery, while operations teams may be focused on system stability and performance. These misaligned objectives can cause friction and hinder the success of DevOps implementation.
• Solution:
  • Addressing cultural resistance requires a strong leadership commitment to change, along with training programs and workshops to educate teams about the benefits of DevOps. Emphasizing the shared goals of improved software delivery speed and quality can help align different teams and foster collaboration.

2. Lack of Skilled DevOps Professionals

Major Features:

• Skill Gaps in DevOps Tools and Practices:
  • DevOps requires a combination of technical skills, including expertise in continuous integration, continuous deployment (CI/CD), automation, cloud infrastructure, and containerization. Many organizations struggle to find professionals with the necessary skill set to effectively implement DevOps practices.
• Limited Training Opportunities:
  • Despite the growing popularity of DevOps, there is still a shortage of formal training programs and certifications that provide comprehensive DevOps education. This creates a gap in the talent pool and increases the difficulty of hiring skilled DevOps professionals.
• Overwhelming Scope of Responsibilities:
  • DevOps engineers often wear multiple hats, managing everything from automation to monitoring and troubleshooting. The broad scope of responsibilities can make it difficult to keep up with industry changes and adopt new tools and practices quickly.
• Solution:
  • Organizations can address the skills gap by offering internal training programs, encouraging certifications, and collaborating with educational institutions to create DevOps-focused courses. Leveraging DevOps platforms with built-in automation features can also ease the burden on teams by reducing the need for extensive manual intervention.

3. Tool Integration and Complexity

Major Features:

• Managing Multiple Tools:
  • DevOps involves the use of various tools for version control, CI/CD, automation, containerization, and monitoring. However, integrating these tools into a unified workflow can be challenging, especially when tools don’t easily communicate with each other.
• Tool Overload:
  • With so many tools available in the DevOps ecosystem, choosing the right set of tools and ensuring they work well together can be overwhelming. Teams may experience difficulty in managing tool sprawl, resulting in inefficiencies and confusion.
• Continuous Tool Updates:
  • DevOps tools are continuously evolving, and keeping up with regular updates, new features, and best practices can be time-consuming. This constant change makes it challenging to maintain a stable and secure development environment.
• Solution:
  • Adopting a standardized set of DevOps tools that are well-integrated can simplify the implementation process. Many platforms like GitLab, Jenkins, and CircleCI offer integrated solutions that streamline workflows and reduce the need for manual configuration.

4. Security and Compliance Challenges

Major Features:

• Integrating Security into the DevOps Pipeline (DevSecOps):
  • DevOps requires the integration of security throughout the entire software development lifecycle. However, many organizations struggle to incorporate security checks and practices into their CI/CD pipelines without slowing down the development process.
• Ensuring Compliance:
  • Compliance requirements, such as GDPR, HIPAA, and PCI DSS, often mandate strict controls over data handling, security, and privacy. Ensuring that DevOps workflows remain compliant while maintaining speed and flexibility can be a major challenge.
• Managing Secrets and Sensitive Data:
  • Handling sensitive data and secrets (e.g., API keys, passwords, encryption keys) securely is a challenge in DevOps. The use of multiple automation tools and cloud platforms increases the complexity of managing and storing secrets safely.
• Solution:
  • Adopting DevSecOps practices, which integrate security into every stage of the DevOps pipeline, can help. Automating security testing (e.g., static and dynamic application security testing) and using tools for secret management (e.g., HashiCorp Vault) can mitigate security risks while maintaining agility.

5. Scalability and Infrastructure Management

Major Features:

• Scaling Applications and Infrastructure:
  • As organizations grow, the complexity of managing infrastructure at scale increases. DevOps often requires teams to support large-scale applications and distributed systems, which may include managing thousands of virtual machines, containers, or microservices.
• Managing Hybrid and Multi-Cloud Environments:
  • Many organizations use hybrid or multi-cloud environments, which add complexity to infrastructure management. Integrating on-premise and cloud systems, ensuring consistency, and scaling infrastructure dynamically can become overwhelming without the right tools and processes.
• Cost Optimization:
  • Managing infrastructure at scale while controlling costs is a key challenge in DevOps. Without proper cost management practices, organizations may overspend on cloud resources, leading to inefficiencies and budget overruns.
• Solution:
  • Adopting Infrastructure as Code (IaC) tools like Terraform, AWS CloudFormation, or Azure Resource Manager can help automate infrastructure management and ensure that environments are scalable and consistent. Cloud-native tools like Kubernetes can assist in orchestrating and scaling containerized applications.

6. Performance Monitoring and Continuous Improvement

Major Features:

• Real-Time Monitoring of Applications:
  • Monitoring performance in real time is critical for DevOps success, but continuously tracking the health of distributed systems, microservices, and cloud environments can be challenging. Identifying bottlenecks, issues, and failures requires constant vigilance and automated alerting.
• Feedback Loops:
  • DevOps relies on continuous feedback from both automated testing and real-world user interactions. Gathering and analyzing feedback efficiently, then acting on it quickly, is essential for ensuring that systems evolve and improve over time.
• Balancing Speed with Quality:
  • While DevOps encourages faster release cycles, there’s always the challenge of balancing speed with quality. Ensuring that new code is well-tested and does not introduce regressions or performance issues is a key consideration.
• Solution:
  • Leveraging monitoring tools like Prometheus, Grafana, and New Relic provides real-time insights into application performance. Implementing Continuous Improvement (CI) practices, based on performance data and user feedback, ensures that products continue to evolve in response to user needs and business goals.

Overcoming the Challenges of DevOps

While implementing DevOps offers significant benefits in terms of faster software delivery, improved collaboration, and greater efficiency, the journey is fraught with challenges. Overcoming these challenges—whether related to culture, skill gaps, tool integration, security, scalability, or performance monitoring—requires a strategic approach, strong leadership, and continuous investment in training and tools.

By addressing these challenges head-on and adopting best practices, organizations can unlock the full potential of DevOps and achieve greater success in their software development and operations. Fostering collaboration, automating processes, and ensuring continuous improvement are key to building a sustainable and efficient DevOps pipeline.

Despite having a combined market cap of about $5.5 trillion and being the core of the greatest growth market the tech industry has ever known, the Cloud Wars Top 10 vendors each face significant challenges in 2021.

Whether those challenges are from other Cloud Wars Top 10 competitors, from feisty upstarts like Snowflake, or driven by the need to evolve and transform at breathtaking speed while continuing to support tens of thousands of business customers across the globe, they will make for some fascinating outcomes in 2021.

In our recent Cloud Wars Top 10 Special Report: Which Cloud Vendors Will Thrive in 2021?, we devoted considerable attention to the range of threats looming for the Cloud Wars Top 10: #1 Microsoft, #2 Amazon, #3 Salesforce, #4 Google Cloud, #5 SAP, #6 Oracle, #7 IBM, #8 Workday, #9 ServiceNow, and #10 Adobe.

Here’s a quick overview of each with links to the detailed analyses in our Special Report.

#1 Microsoft
Three big challenges: Azure reliability, balancing enormous aspirations for SaaS and IaaS, and keeping Satya Nadella—perhaps the world’s top CEO—happy and motivated and challenged. Check out our in-depth exploration of those 3 challenges.

#2 Amazon
Three biggest challenges for Andy Jassy and Jeff Bezos: competing with customers, reliability, and multi-cloud management. Get the full story on the major challenges facing AWS.

#3 Salesforce
The biggest challenges facing Benioff & Co.: will Marc Benioff move from platforms to politics? Can Salesforce continue to stay 2 steps ahead of SAP and Oracle? Get the full story on the biggest obstacles for Salesforce on its road to $50 billion.

#4 Google Cloud
Hey, even the hottest major cloud vendor in the world is not free from challenges. And while Google has a market cap of about $1.2 trillion, both Microsoft and Amazon can not only match but exceed that financial muscle. Will parent Alphabet continue to invest at the astonishing rates needed to compete with its larger rivals? Here’s our view.

#5 SAP
For 40 years, SAP has helped huge global corporations run complex operations, and now SAP is itself in the final phases of overhauling how it runs itself. Can it do in the cloud what it was able to do in traditional computing? We vote yes.

#6 Oracle
Larry Ellison has chosen to compete head-on with companies whose market caps are anywhere from about 8X as large as his (Microsoft and Amazon) to about 6X as large (Google). Can Ellison defy the laws of physics? Hey—he’s done it before.

#7 IBM
Red Hat is a big part of the cloud solution for IBM but, if overplayed, Red Hat also becomes the problem. IBM seems to want to say that it’s cloud future is all about Red Hat, but that’s not enough—the whole company has to go all-in on the cloud! Here’s our take on what IBM needs to do to become a big-time player in the cloud.

#8 Workday
Workday has been hugely successful with its focus on HCM and Financials—but as the world moves rapidly to all digital business all the time, will that be enough to keep up with the full end-to-end offerings of competitors SAP and Oracle?

#9 ServiceNow
Bizarre but true: ServiceNow has been wildly successful in part because it’s doing things no other major cloud vendor has chosen to do or, at least so far, is able to do. That won’t last—will the competition come from Google Cloud?

#10 Adobe
In the wickedly competitive CX segment of the market, Adobe has a great consumer brand but only spotty enterprise credibility. And ongoing problems with part of its Experience Cloud has dragged growth rates into single digits—and in the Cloud Wars, that’s a losing position.

Final Thoughts
In calmer times, each of these 10 world-class companies could no doubt assess these challenges, map out a solid plan to overcome them, and begin to execute and adapt. But these times are anything but calm, and the relentless pace of change, innovation and disruption are requiring companies to blast through challenges at the same time they are driving unprecedented levels of innovation.

We’ll be watching closely in 2021 to see which of the Cloud Wars Top 10 are up to the challenge.

NITI Aayog along with AWS has established a Frontier Technologies Cloud Innovation Center (CIC) to help address societal challenges through digital innovation. This will be the first AWS CIC in India, the 12th around the world, and the first AWS CIC that will address societal challenges at a national level. Other countries which has a CIC are Australia, Bahrain, Canada, France, Germany, South Korea, and United States.

The press briefing was attended by Max Peterson, Vice President – International Sales, Worldwide Public Sector, Amazon Web Services, Inc., Anna Roy, Senior Adviser, NITI Aayog, Rahul Sharma, Regional Head, AISPL Public Sector, AWS India and South Asia, among others.

The AWS Cloud Innovation Centers Global Program provides an opportunity for government agencies, nonprofits, and education institutions, to collaborate on pressing challenges, apply design thinking methodology, test new ideas, and access technology expertise from AWS.

“We are seeing public sector organizations around the world use cloud technology to innovate in a fast and agile manner, address problems at scale, and transform public services for citizens,” said Peterson in the press briefing. He further added that the CIC program is designed to be a catalyst for innovation in the public sector. “We are excited to collaborate with NITI Aayog, and support its public sector mission in India,” he added.

“Through the CIC program, we have the opportunity to experiment with the latest technology and access world-class innovation expertise that will help us advance citizen services, and better understand how frontier technologies can address the unique needs of our country,” said Roy. She hopes that the NITI Aayog CIC with AWS will bring together government stakeholders, startups, and local organizations in India to innovate and create new approaches to solving problems.

The cloud innovation center will allow collaboration with local leaders, including subject matter experts at the state and district level, to solve critical societal challenges. It will allow local enterprises, startups, researchers and universities to experiment and build prototypes on AWS Cloud and contribute along with the global CIC community dedicated to accelerating societal innovation.

“We are deeply committed to help public sector organizations in India achieve transformational economic and societal impact, and look forward to sharing our global experiences to accelerate digital innovation in the country,” said Rahul Sharma.

Despite its well-documented benefits, many organisations treat DevOps adoption as a burden rather than an opportunity. Implementation is rarely straightforward, and the challenges are real. Understanding those challenges before you begin is the first step toward overcoming them.

“DevOps is not a goal, but a never-ending process of continual improvement.”

— Jez Humble, co-author of Continuous Delivery

What Is DevOps?

DevOps emerged from the recognition that traditional software delivery models — where developers write code and then “throw it over the wall” to operations to deploy and maintain — produce slow release cycles, poor quality, and organisational friction. By breaking down those silos, DevOps teams can:

• Release software more frequently and with greater confidence
• Detect and resolve defects faster through continuous testing and monitoring
• Share responsibility for both delivery speed and system reliability
• Build a feedback culture that drives continuous improvement

DevOps is closely associated with practices such as continuous integration (CI), continuous delivery (CD), infrastructure as code (IaC), automated testing, and blameless post-mortems. Tools like Git, Jenkins, Docker, Kubernetes, Terraform, and Prometheus are commonly used to operationalise these practices — but the tools are secondary to the cultural and organisational changes required.

Common DevOps Implementation Challenges

Organisations of every size encounter obstacles when adopting DevOps. The following are the most frequently cited challenges, along with practical guidance on how to address each one.

1. The Development vs. Operations Divide

The foundational tension in any DevOps adoption is the historical gap between developers and operations engineers. Developers are incentivised to ship new features quickly and are comfortable with change. Operations teams are incentivised to keep systems stable and are wary of untested deployments. These differing objectives — and the mutual distrust that often accompanies them — are the root cause of many delivery failures.

DevOps does not ask either team to abandon its expertise. Instead, it asks both to share accountability for outcomes. Practically, this means:

• Developers taking responsibility for the operability of their code (logging, alerting, runbooks)
• Operations engineers participating in sprint planning and design reviews
• Joint on-call rotations that give developers visibility into production behaviour
• Shared dashboards and metrics that make system health transparent to everyone

2. Cultural Change

DevOps is, before anything else, a cultural shift. It requires people to collaborate across boundaries they may have spent years maintaining, to accept blame-free retrospectives, and to trust colleagues from different disciplines. This is often harder than adopting any new tool or pipeline.

Cultural change cannot be mandated from above and completed in a quarter. Effective approaches include:

• Starting small: Identify a willing pilot team and build visible success before rolling out more broadly.
• Growing internal champions: Individuals who have experienced DevOps benefits firsthand are far more persuasive than external consultants or management mandates.
• Investing in training: Skills gaps in CI/CD pipelines, cloud infrastructure, or automated testing will undermine even the most enthusiastic teams.
• Celebrating learning from failure: Blameless post-mortems signal that the organisation values improvement over punishment.

3. Toolchain Complexity

The DevOps ecosystem offers a vast and growing selection of open-source and commercial tools. While this is ultimately an advantage, it creates a real challenge during adoption: teams can easily become overwhelmed by tool choices, or accumulate tools that overlap in function and create integration headaches.

More dangerous than choosing the wrong tool is deploying a tool nobody has been trained to use. An untrained team using a CI/CD platform incorrectly can introduce security vulnerabilities, break deployment pipelines, or create infrastructure drift. Key principles for toolchain decisions:

• Prioritise tools your team can actually use and support, not just the most popular options.
• Standardise on a core toolchain before expanding it.
• Treat tool training as a mandatory investment, not an optional extra.
• Evaluate security implications — particularly around secrets management, access controls, and supply chain integrity — before adoption.

4. Legacy Systems and Technical Debt

Many organisations carry significant legacy infrastructure: monolithic applications, on-premises systems built on older architectures, and tightly coupled dependencies that predate modern API design. These systems are often incompatible with the automation-first, containerised, cloud-native approaches that DevOps pipelines assume.

Attempting to bolt modern tooling onto an unchanged legacy estate rarely produces good results. Instead, organisations should:

• Assess which legacy systems can realistically be modernised, strangled (incrementally replaced), or encapsulated behind APIs.
• Prioritise the systems that most constrain delivery speed.
• Accept that some legacy systems will need significant investment before full DevOps practices apply to them.
• Avoid creating two-tier IT estates where new projects run on modern pipelines but critical legacy systems are excluded — this limits the overall impact of DevOps adoption.

5. Process and Workflow Changes

DevOps does not prescribe a single delivery process. There is no universal framework that applies to every organisation, and DevOps does not come with predefined KPIs. This flexibility is a strength, but it can also feel like a vacuum to teams accustomed to rigid waterfall or ITIL-based processes.

The transition from heavyweight change-approval processes to lightweight, automated deployment pipelines requires genuine procedural change. Audit trails, change records, and approval gates still exist in mature DevOps environments — they are simply automated, faster, and evidence-based rather than manual and bureaucratic. Teams navigating this transition should:

• Map existing processes before replacing them — understand why controls exist before removing them.
• Collaborate with security and compliance stakeholders early, not after pipelines are built.
• Allow teams some autonomy in choosing their workflow, within agreed quality and security guardrails.

6. Resistance to Change

Individual resistance is one of the most underestimated obstacles in DevOps adoption. People build skills, habits, and professional identities around specific ways of working. A mandate to change all of that — especially if the rationale is poorly communicated — naturally generates anxiety and pushback.

A common misconception is that DevOps automation will eliminate jobs. In practice, automation shifts the work rather than eliminating it: routine manual tasks are replaced by higher-value activities like pipeline engineering, reliability work, and capacity planning. Addressing resistance effectively requires:

• Transparent communication about what is changing and why.
• Gradual rollout — piloting DevOps on a bounded project reduces risk and gives hesitant team members time to observe results.
• Investing in upskilling so that people feel equipped, not sidelined.
• Acknowledging that some roles will evolve, and providing a credible path for individuals to grow into those new roles.

7. Lack of a Unified Organisational Vision

DevOps adoption fails when different parts of the business pull in different directions. A common failure mode is treating DevOps as a purely technical initiative owned by engineering, while business units, product managers, and security teams continue to operate with conflicting priorities and separate metrics.

Successful DevOps transformations are driven by a shared vision that spans engineering, operations, security, and the business. This means:

• Leadership alignment on what DevOps success looks like — and agreement on metrics such as deployment frequency, lead time for changes, mean time to restore (MTTR), and change failure rate.
• Issues being resolved collectively, not in silos — a production incident is not just an operations problem.
• Cross-functional teams that include security (DevSecOps) and product stakeholders, not just developers and engineers.

Measuring DevOps Success

One practical way to align teams around a shared vision is to adopt well-established DevOps metrics. The DORA (DevOps Research and Assessment) research programme has identified four key metrics — deployment frequency, lead time for changes, change failure rate, and time to restore service — as reliable indicators of software delivery performance. Using shared metrics removes ambiguity about what improvement looks like and creates a basis for honest, data-driven conversations.

Conclusion

DevOps is not a product you can buy or a project you can complete. It is an ongoing discipline that requires sustained investment in culture, tooling, processes, and people. The challenges outlined above are real, but none of them are insurmountable. Organisations that have successfully adopted DevOps consistently report shorter release cycles, higher deployment reliability, faster incident recovery, and greater team satisfaction.

The path forward is pragmatic: start with a willing team, demonstrate measurable results, invest in training and tooling, and build from there. DevOps is, as Jez Humble observed, a never-ending process of continual improvement — and that is precisely what makes it worth the effort.

Despite the enthusiasm, large-scale DevOps adoption remains slow for many organizations. The reason is not usually a lack of tooling—it is that DevOps is fundamentally about people, culture, and process, not just CI/CD pipelines or container orchestration platforms. Understanding where adoption most often breaks down is the first step toward a successful transformation.

1. Breaking Deep-Rooted Cultural Habits

The most frequently cited obstacle to DevOps adoption is not technical—it is cultural. Development and operations teams have historically operated in separate silos, with different goals, incentives, and definitions of success. Developers are often rewarded for shipping features quickly; operations teams are measured on system stability. These competing priorities create friction that no tool can resolve on its own.

True DevOps transformation requires dismantling those silos and replacing them with a shared sense of ownership over the entire software delivery lifecycle. That shift rarely happens from the bottom up. Leadership commitment is essential: executives and engineering managers must visibly champion the change, remove structural barriers, and create psychological safety for teams experimenting with new ways of working.

• Start with shared goals. Align development and operations around a common outcome—such as mean time to recovery, deployment frequency, or customer satisfaction—rather than separate departmental KPIs.
• Make wins visible. Motivation builds when team members can see concrete, measurable improvements. Celebrate early successes publicly.
• Invest in psychological safety. Teams will not experiment or report failures honestly if they fear blame. Blameless post-mortems and a culture of learning are foundational DevOps practices.
• Budget for training. Culture shifts require skill development. Engineers who have always worked in silos need time and support to learn collaborative practices.

Resistance to change is normal and should be expected. The goal is not to eliminate resistance immediately but to understand its source—fear, uncertainty, or genuine concern about unintended consequences—and address it directly.

2. Redesigning Established Processes for Efficiency

Many organizations have well-documented processes built up over years. Those processes feel familiar and safe, even when they are slow or wasteful. Adopting DevOps means scrutinizing every step of the software delivery workflow and honestly assessing whether it adds value or simply exists because it always has.

A practical starting point is value-stream mapping: drawing out every stage of your delivery pipeline from code commit to production deployment, identifying where work queues up, where handoffs cause delays, and where manual approvals introduce bottlenecks. Common sources of waste include:

• Long-lived feature branches that delay integration and increase merge conflicts
• Manual testing gates that create release backlogs
• Approval chains that do not correspond to meaningful risk controls
• Siloed monitoring where only one team can see production health
• Deployment scripts owned by a single person or team, creating single points of failure

A critical risk during process redesign is that individual departments opt out, assuming that DevOps is someone else’s problem—usually the platform or tooling team. In practice, effective DevOps requires active participation from product management, QA, security, and operations, not just software developers. Each stakeholder group needs to understand how their workflows connect to the overall delivery pipeline and where they can contribute to reducing friction.

Process change should be incremental. Attempting to overhaul every workflow simultaneously is a recipe for chaos. Pick one delivery pipeline, instrument it, improve it, measure the outcome, and then use those learnings to guide the next change.

3. Avoiding DevOps Adoption for Its Own Sake

DevOps carries significant industry momentum, which creates its own risk: organizations adopting it because it is fashionable rather than because they have identified a specific problem it will solve. Implementing Kubernetes, deploying a GitOps workflow, or standing up a new CI platform without a clear connection to a business objective is expensive, disruptive, and unlikely to deliver lasting value.

The typical pattern unfolds like this: a development team runs a successful DevOps pilot. Deployment frequency increases, lead time drops, and morale improves. Leadership, encouraged by these results, mandates a rapid rollout across the entire organization. The problem is that other departments—security, finance systems, embedded software, or regulatory-compliance-sensitive areas—have materially different constraints, risk profiles, and delivery cadences. Applying a one-size-fits-all DevOps template without adaptation often creates more problems than it solves.

Before expanding any DevOps initiative, ask these questions:

• What specific outcome are we trying to improve? Define it in measurable terms before choosing an approach.
• What are the unique constraints of this team or system? Compliance requirements, hardware dependencies, or staffing gaps may require a tailored implementation.
• Do we have the organizational capacity to support this change right now? A failed rollout caused by resource overextension can set back trust in DevOps more broadly.
• Are we solving a real customer problem? DevOps practices should ultimately connect back to faster, more reliable delivery of value to end users.

Incremental, intentional adoption beats a rushed enterprise-wide transformation every time. Move fast where the conditions are right, move carefully where they are not, and continually reassess as you learn.

Key Takeaways

DevOps adoption challenges are rarely about technology. The three most persistent obstacles—cultural inertia, entrenched inefficient processes, and adoption without clear purpose—are organizational in nature and require organizational solutions. A successful DevOps journey demands strong leadership, honest process analysis, and a clear connection between practices and business outcomes. Start with clarity about what you are trying to achieve, move incrementally, measure everything, and keep customer needs at the center of every decision.

Originally informed by an article published on devops.com.

Because CSPs are independent business entities, data outsourcing is effectively a transfer of ultimate custody over that data. Even when providers publish strong security commitments and SLAs, the operational reality of shared, multi-tenant environments creates attack surfaces that differ fundamentally from traditional on-premises deployments.

Why Cloud Data Security Deserves Special Attention

Many data security principles—confidentiality, integrity, and availability—apply equally to on-premises and cloud environments. What changes in the cloud is the threat model. The openness of cloud APIs, multi-tenancy (multiple customers sharing the same underlying infrastructure), and reliance on the provider’s internal controls all introduce risks that traditional perimeter-based security models were not designed to handle.

Notable incidents from cloud computing’s early years—including service outages at major providers, exposed user data due to misconfigured storage, and vulnerabilities discovered in hypervisor software—illustrated that even market-leading providers can experience serious security failures. These events reinforced the need for defence-in-depth strategies that do not rely solely on a provider’s built-in protections.

The 4 Core Data Security Challenges

1. Data Generation and Ownership

In a traditional IT environment, the organisation that generates data typically owns and controls it end to end. When data is moved to the cloud, that ownership relationship becomes more complex. Questions arise around:

• Who legally owns the data once it resides on provider infrastructure?
• What data is collected by the provider as a by-product of operating the service (logs, telemetry, usage metadata)?
• How can owners assert their rights to restrict, export, or delete their data under regulations such as GDPR or CCPA?

Engineering teams should review their provider’s data processing agreements carefully and implement tagging, classification, and access-control policies at the point of data creation—not after the fact.

2. Data Transfer

Moving data into, out of, and between cloud services exposes it to interception and tampering if transmission is not properly secured. Within a private network, simple or no encryption may have been acceptable; across the public internet or between cloud regions, it is not.

Effective data-in-transit protection requires addressing two distinct properties:

• Confidentiality: Encrypting the data so that only authorised parties can read it (e.g., TLS 1.2 or higher for API traffic).
• Integrity: Ensuring the data has not been modified in transit (e.g., using authenticated encryption modes or cryptographic MACs).

Encryption alone is insufficient if integrity is not verified. A threat actor who cannot decrypt intercepted traffic may still be able to corrupt or replay it. Transport protocols and cipher suites should be chosen to provide both guarantees simultaneously.

3. Data Sharing

Cloud environments make it easy to share data broadly—across teams, partner organisations, and third-party services. That convenience increases the risk of data being shared beyond its intended scope. A data owner may grant access to one party, who then re-shares it with another party without the owner’s knowledge or consent.

Key controls for managing data sharing include:

• Attribute-based or role-based access control (ABAC/RBAC) that limits who can share data and under what conditions.
• Data-sharing agreements and audit logs that record every access and downstream distribution event.
• Usage restrictions embedded in the data itself where possible (for example, via Information Rights Management systems), so that protection travels with the data even when it leaves your direct control.
• Third-party risk assessments to verify that external parties maintain equivalent security standards before data is shared with them.

4. Data Storage

Data stored in cloud object stores, databases, or block storage faces the same classic security triad as data stored anywhere else: confidentiality, integrity, and availability. However, the cloud context introduces specific considerations:

• Confidentiality: Encryption at rest is now a baseline expectation. Teams should evaluate both the encryption algorithm (e.g., AES-256) and key management practices. Provider-managed keys are convenient but mean the provider can technically access your data; customer-managed keys (BYOK) give you greater control.
• Integrity: Cloud storage services typically provide checksums for stored objects, but teams should independently verify critical data has not been silently corrupted or tampered with, particularly for regulated workloads.
• Availability: Redundancy and replication across availability zones or regions protect against data loss due to hardware failure or localised outages. However, replication also means that a corrupted or accidentally deleted object can propagate. Versioning and point-in-time recovery capabilities should be enabled for critical datasets.

When selecting an encryption approach for large-scale data processing workloads, performance matters: symmetric encryption algorithms (such as AES) are generally far more computationally efficient than asymmetric algorithms and are the standard choice for bulk data encryption. Asymmetric algorithms are better suited to key exchange and authentication, not bulk data encryption.

Building a Defence-in-Depth Strategy

Addressing these four challenge areas in isolation is not enough. A mature cloud data security posture combines them into a layered strategy:

1. Classify data at creation and apply appropriate controls before it enters the cloud.
2. Enforce encrypted transmission on all paths—internal, external, and inter-service.
3. Implement least-privilege access and audit every data-sharing event.
4. Encrypt stored data with customer-managed keys where your risk profile requires it, and enable versioning and integrity verification.
5. Continuously monitor for misconfigurations, anomalous access patterns, and compliance drift using cloud-native security posture management (CSPM) tools.

Cloud providers offer increasingly sophisticated native security tooling, but the shared responsibility model means that securing your data remains your obligation. Understanding where provider responsibility ends and your own begins—and engineering accordingly—is the foundation of trustworthy cloud operations.

The Speed vs. Security Tension Is Real

At first glance, security and DevOps appear to operate on fundamentally different principles. Traditional security practices emphasize thoroughness and control — ensuring every change is reviewed, validated, and hardened before it reaches production. DevOps, by contrast, prioritizes velocity: shipping working software quickly and iterating based on real-world feedback.

The business pressure is real. Executive leadership increasingly expects development and operations teams to deliver continuously without slowing the organization down. When those expectations collide with underfunded or under-integrated security practices, something gives — and it is usually security.

Organizations regularly report cutting back on security reviews to meet urgent release deadlines, and a significant proportion of operations teams admit they do not consistently follow established security best practices. This isn’t a people problem — it’s a process and culture problem.

Why Bolted-On Security Fails in DevOps Environments

When security is treated as a gate at the end of the software delivery pipeline — a final checkpoint before production — it creates bottlenecks that frustrate both developers and security engineers. Vulnerabilities found late in the cycle are expensive and disruptive to fix. Teams under deadline pressure are tempted to ship anyway and “patch it later.”

This late-stage security model is fundamentally incompatible with continuous delivery. If your CI/CD pipeline can produce a deployable artifact in minutes, a security review that takes days becomes the slowest part of your entire workflow.

DevSecOps: Shifting Security Left

The answer isn’t to slow down DevOps — it’s to move security earlier and integrate it throughout the pipeline. This is the core idea behind DevSecOps: treating security as a shared responsibility across development, operations, and security teams, embedded into every stage of the software delivery lifecycle rather than appended at the end.

Shifting security left means catching vulnerabilities where they are cheapest to fix — in the developer’s IDE, in code review, in automated pipeline scans — rather than in production. The practical steps include:

• Static Application Security Testing (SAST): Automated tools analyze source code for known vulnerability patterns during development and as part of CI builds, giving developers immediate feedback without requiring a manual security review.
• Software Composition Analysis (SCA): Automatically identifies vulnerable open-source dependencies and libraries before they are shipped. Given that modern applications depend heavily on third-party packages, this is a critical control.
• Container image scanning: CI/CD pipelines that build container images should scan those images for OS-level and application-level vulnerabilities before they are pushed to a registry or deployed.
• Infrastructure as Code (IaC) scanning: Tools that review Terraform, CloudFormation, or Kubernetes manifests for misconfigurations catch cloud security issues before infrastructure is provisioned.
• Runtime protection: Security controls don’t stop at deployment. Runtime monitoring, anomaly detection, and workload protection ensure that what runs in production behaves as expected.

Automating Security Throughout the CI/CD Pipeline

Automation is what makes security sustainable at DevOps speed. Manual security reviews cannot scale to match continuous deployment cadences — but automated security gates can. A well-designed pipeline can enforce security policies automatically: failing a build if a critical vulnerability is detected in a dependency, blocking a container image with a known CVE from being promoted to production, or alerting on an IaC configuration that opens an overly permissive network rule.

The goal is to make the secure path the easy path. When security tooling is integrated directly into the developer workflow — surfacing findings in pull request comments, in the IDE, or in the same dashboards developers already use — compliance becomes a natural part of the development process rather than an external friction point.

Building a Security Mindset Across the DevOps Lifecycle

Tools alone aren’t enough. Successful DevSecOps programs also invest in culture and shared ownership. Key practices include:

• Threat modeling during design: Involving security engineers in architectural design discussions — before a line of code is written — is far more effective than retrofitting controls after the fact.
• Security champions: Embedding security-minded engineers within development teams creates a bridge between security expertise and day-to-day development work, without requiring every developer to become a security specialist.
• Shared security metrics: Including security KPIs — such as mean time to remediate vulnerabilities or the percentage of builds passing security gates — in team dashboards signals that security is a team responsibility, not just a security team problem.
• Blameless postmortems: When a security incident occurs, treating it as a learning opportunity rather than a blame exercise encourages teams to surface issues early and honestly.

Protecting the Cloud-Native Stack

Modern DevOps environments are almost always cloud-native, which introduces a distinct set of security considerations. Misconfigured cloud storage, overly permissive IAM roles, and unprotected API endpoints are consistently among the most exploited attack vectors in cloud environments.

Cloud Security Posture Management (CSPM) tools continuously audit cloud configurations against security benchmarks and compliance frameworks, flagging drift from secure baselines automatically. Combined with workload protection for containerized and serverless environments, these controls extend the DevSecOps model from the pipeline into production infrastructure.

Security and Speed Are Not Mutually Exclusive

The organizations that ship software fastest and most securely are not the ones that skip security — they’re the ones that have made security a structural part of how they build and operate software. When security is integrated into the pipeline rather than bolted onto the end of it, it stops being a blocker and starts being an enabler of confidence at deployment time.

The question for any engineering organization isn’t whether to have security — it’s whether your security practice is fast enough and integrated enough to keep up with your delivery cadence. For most teams, the answer lies in automation, cultural change, and a genuine commitment to shared ownership of security outcomes.

This article was updated and expanded from an original post published in May 2019, which referenced a webinar hosted by IT World Canada and Trend Micro on integrating security into DevOps pipelines. The original source was itworldcanada.com.

Overview: Why This Partnership Matters for DevOps

Venafi, a provider of machine identity protection, and GMO GlobalSign, a global Certificate Authority (CA) and identity security vendor, announced an expanded technology partnership and integration aimed squarely at the certificate management pain points that DevOps teams face daily. The integration connects Venafi Cloud with GlobalSign’s high-performance PKI solutions, enabling enterprises to issue, manage, and revoke trusted TLS certificates at scale across hybrid infrastructure, multiple clouds, and containerized environments.

The Problem: Certificate Chaos in DevOps Environments

As organizations adopt DevOps practices, the number of machine identities—cryptographic keys and certificates used by services, containers, APIs, and devices—grows rapidly. Without centralized oversight, individual developers and teams tend to handle certificate procurement on their own, which leads to several compounding problems:

• Unauthorized CAs: Developers obtain certificates from CAs that haven’t been approved by the security team, bypassing policy controls.
• Self-signed and wildcard certificates: Teams reach for convenience over security, introducing weak credentials into production systems.
• Manual lifecycle management: Certificates expire unexpectedly, causing outages that are entirely avoidable with automation.
• Expanded attack surface: Errors and vulnerabilities introduced through ad hoc certificate practices accumulate in production, increasing organizational risk.

The result is an environment where security teams lack visibility and DevOps teams lack guardrails—a combination that creates both compliance gaps and operational fragility.

What the Venafi Cloud and GlobalSign Integration Provides

The combined solution embeds trusted certificate issuance directly into the tools and workflows developers already use, while giving security teams the policy enforcement and visibility they need. Key components include:

Out-of-the-Box Tool Integrations

Venafi Cloud ships with pre-built integrations for widely adopted DevOps toolchains, including:

• HashiCorp Terraform and HashiCorp Vault
• SaltStack and Ansible
• Docker
• Jetstack cert-manager (for Kubernetes environments)

These integrations allow certificates to be provisioned and renewed automatically as part of existing pipelines, without requiring developers to interact with PKI infrastructure directly.

Standard Interfaces and APIs

For teams that need custom integration, the solution exposes well-documented standard interfaces:

• REST API for programmatic certificate management
• VCert SDK (open source, available in Go and Python) for embedding certificate operations into custom tooling
• ACME protocol support for automated certificate issuance compatible with existing ACME clients

Eliminating In-House PKI Overhead

By using GlobalSign’s cloud-based PKI services, organizations avoid the cost and complexity of building and operating their own CA infrastructure. This includes ancillary services such as Online Certificate Status Protocol (OCSP) responders and Certificate Revocation Lists (CRL), which are required for a functioning PKI but are often underinvested in when managed in-house.

Key Benefits of the Integration

• High-speed issuance: Supports DevOps use cases requiring ultra-fast certificate delivery, with certificates issued in seconds.
• CI/CD pipeline integration: Policy-enforced certificate issuance can be embedded directly into continuous integration and delivery pipelines, with appropriate policies applied per environment.
• Outage prevention: Automated certificate lifecycle management eliminates the manual renewal errors that cause unplanned downtime.
• Improved security posture: Infrastructure is secured as it is provisioned, enabling consistent end-to-end HTTPS across environments.
• Regulatory compliance: The solution is designed to support compliance with PCI DSS, NIST guidelines, HIPAA, and other audit frameworks by enforcing standardized certificate policies.
• Unified visibility: Security teams gain complete visibility into which certificates are in use, where they were issued, and whether they comply with enterprise policy—without slowing down development teams.

What Industry Stakeholders Said

Kevin Bocek, Vice President of Security Strategy and Threat Intelligence at Venafi, described the integration as addressing a long-standing gap: “Venafi Cloud eliminates the machine identity risks that have plagued DevOps, hybrid and multi-cloud environments. DevOps teams get the fastest, easiest way to automate TLS certificates whether they’re using ready-to-use integrations or powerful APIs. And security teams are happy knowing trusted certificates are being used correctly because they have complete visibility.”

Nisarg Desai, Director of Product Management for IoT and DevOps at GlobalSign, emphasized the compliance angle: “By combining GlobalSign’s highly scalable PKI for DevOps solution with Venafi Cloud certificate policy management and enforcement, organizations are now able to improve security, boost productivity and comply with regulatory frameworks—such as PCI DSS, NIST, and HIPAA—with just a few lines of code.”

Practical Takeaways for DevOps and Security Teams

If your organization is running workloads across hybrid or multi-cloud infrastructure and certificate management is handled inconsistently across teams, this kind of integrated solution addresses real operational and security gaps. Specifically:

• If you are already using HashiCorp Vault or cert-manager for secrets and certificate management in Kubernetes, a Venafi Cloud integration can add policy enforcement and CA-level trust without replacing existing tooling.
• If your security team struggles with certificate visibility—not knowing what certificates exist, who issued them, or when they expire—centralized machine identity management is the appropriate solution category to evaluate.
• If building and maintaining an internal CA is consuming engineering resources without providing commensurate control, offloading to a managed PKI service like GlobalSign’s reduces operational overhead while improving auditability.

The ACME protocol support is particularly relevant for teams already familiar with Let’s Encrypt workflows, as it allows existing automation to be redirected toward an enterprise-grade CA with policy controls attached.

With its promises of lowering costs and fostering a more agile IT, cloud computing holds an almost magical allure for many companies today: They think moving an application or two to the cloud will solve all their problems, said Ed Featherston, vice president and principal architect at Cloud Technology Partners.

“Then they get the bill at the end of the month and go, ‘Oh my God, what happened?'” Featherston said at the recent Cloud Expo in New York. “The magic doesn’t happen by itself. You actually need to plan.”

In this SearchCIO video, filmed on the concourse of the Jacob K. Javits Convention Center, Featherston and two other cloud watchers discuss the biggest cloud computing challenges IT execs are dealing with today.

Sumit Sarkar sees another type of struggle. He’s a data evangelist at Progress, a vendor of data integration and data interoperability services. As organizations build cloud architecture, plugging in new technologies and services, “data is getting somewhat more abstracted,” or not immediately and easily available to analytics professionals, who need to slice and dice it.

“If I build these microservices, my data is behind these different APIs. What if I have a data science practice team? How do I make sure they have access to data to really bring business value?” Sarkar says. IT executives and their business counterparts have to keep that in mind as they’re “rearchitecting and refactoring all of their systems.”

Greg Bledsoe, managing consultant at Accenture, says companies moving to the cloud need to adopt new ways of working. Bledsoe helps companies make the transition to DevOps, the software development process that emphasizes frequent interaction and communication between development and operations teams.

Cloud computing, he says, makes experimenting cheap. “If it doesn’t work, throw it away. But companies are still managing their cloud infrastructure as if it were physical infrastructure.”

So someone on the business side might request a new tech project from IT, gets it, tries it out, but then it’s not quite right.

“Throw something back over the wall and have somebody hoist it back over the wall to you. This makes no sense for cloud,” Bledsoe says. “It’s totally a legacy artifact of our past management strategies that is completely unnecessary.”

What cloud computing challenges plague IT execs today?

Ed Featherston: The biggest struggle I’ve seen with clients in cloud is fully understanding what it is and what it isn’t for them — and what it’s going to provide them. The classic of, ‘If I go to the cloud, it’s going to solve all my problems.’

One of my favorite mantras is ‘No technology negates the need for good design and planning.’ Cloud is no exception. And the biggest challenge I see people having with cloud is if they don’t do that first. If they just say, ‘Oh, I’m just going to take this workload, I’m going to drop it in AWS [Amazon Web Services], I just log into the console, fire up a couple instances — boom, I’m off to the races.’ Then they get the bill at the end of the month and go, ‘Oh my God, what happened?’

The magic doesn’t happen by itself. You actually need to plan. You need to understand ‘What am I going to get out of it? Am I going to the cloud for cost savings?’ Then you better look really closely at it when you do that.

I was talking with somebody earlier about the fact that — you move your first application over and you say, ‘OK, why am I not saving any money?’ Well, because the servers that application was on still have five other applications on them. I still have to maintain them. I still have to pay for them. So, I’m paying for those servers still. Plus, now I’m paying Amazon or [Microsoft] Azure for that cloud instance that I just created, so I’m actually spending more money. You actually have to think that out if you’re going for the agility and being able to move faster. Do your development processes and operations processes support that capability?

Yes, cloud can make you very agile — if you have the processes in place to do it. If you’re still a standard, Waterfall development type of shop that has no concept of what development and operations are and tying them together, the cloud’s not going to make it go faster for you. If anything, it’s probably going to make it go slower if you’re not ready for that.

So those are the kinds of challenges I see clients having out there. It’s getting those expectations set. It’s part of why I enjoy being where I am at our company, because it’s one of the things we push really hard with the clients — of No, we’re not going to start with, Go to the cloud. We’re going to start with, What do you want from it? Let’s look at what you’ve got, let’s understand how we’re going to get there and what the stumbling blocks are — then, we start moving to the cloud.

Sumit Sarkar: What we’re seeing is there’s a lot of people who start — I don’t know if they’re buzzwords, but at the show in the morning we had a kickoff about cloud-native architectures, and there’s 12 attributes of them. And then there’s something — I think I heard the term cloud washed: You take an application, you stick it in the cloud, and you rebrand it as cloud.

But the thing is, in between, there’s a big mix of different levels. I think with the innovation that’s happening is that between a cloud-native architecture and something that’s cloud-washed, for example, there’s a whole lot of things happening in innovation.

So I’ve heard different people who are taking maybe some NoSQLtechnologies to supplement an ERP system. Some people are building out some microservices on top of existing databases if you have a distributed data architecture.

So, what’s happening is data is getting somewhat more abstracted as we have this spectrum of cloud-native and, let’s say, untraditional or the monoliths. So they decompose these things, data gets moved around, make it scalable. So, what’s happening is it’s causing a challenge for the analytics professionals. So, if you think about the people doing operations intelligence, that is the last thing sometimes people think about.

I encourage folks, the CxO people, to think about analytics as they’re rearchitecting and refactoring all of their systems. Think about it: If I build these microservices, my data is behind these different APIs. What if I have a data science practice team? How do I make sure they have access to data to really bring business value? Or I have this data engineering team who can really build these nice data repositories to get 360-degree intelligence. How do I make it easy for them to get the data?

So that’s what we’re seeing in the connectivity space is, How do you provide connectivity for those professionals to still access data as you’re refactoring these things in that big spectrum? So the CxO folks, they have these initiatives, and that’s something to really think about is, Don’t forget the data integration for analytics.

Greg Bledsoe: Because we’ve come from this legacy of managing physical infrastructure, and we’re used to managing physical infrastructure in a very tightly controlled way to protect our investment and control cost, we bring that same mindset to cloud.

This mindset does not really apply to cloud. You don’t have to pay for things when you’re not using them. The whole power of cloud and the reason that cloud empowers DevOps is because you’ve cheapened experimentation. It has become dirt-cheap to try something, and if it doesn’t work, throw it away.

But companies are still managing their cloud infrastructure as if it were physical infrastructure. And you have a DevOps team or someone that sets up cloud infrastructure for you, you put in a request, you put in ticket, and someone builds something, and a few days later you get a response with some things that are built. And then you start trying to use those and it’s not quite right; you do this again. Throw something back over the wall and have somebody hoist it back over the wall to you. This makes no sense for cloud. It’s totally a legacy artifact of our past management strategies that is completely unnecessary.

So there are mechanisms that you can use to protect your cost and investment without having to centrally manage these architectures — which is essentially the exact opposite of DevOps. It’s a DevOps team that’s another silo that doesn’t really collaborate to solve the problem. It just becomes another source of wait time, another source of wheel spinning and another source of invisibility to the other teams.

This is exactly how to do DevOps wrong. And a lot of people are trying to implement it this way because it fits in with what they understand. It fits in with what they know. Because they haven’t really understood yet that DevOps is a completely different way to manage everything from the infrastructure to the people.

The following 13 challenges represent the most common obstacles engineering and IT leaders encounter during cloud migrations. The insights below are drawn from practitioner perspectives originally published via Forbes Technology Council.

1. Getting the Architecture Right the First Time

Infrastructure-as-a-Service (IaaS) platforms such as AWS, Azure, and Google Cloud give you enormous flexibility — but that flexibility is a double-edged sword. There are dozens of ways to assemble cloud infrastructure, and many of them will work just well enough to hide problems until they become expensive. If your team lacks deep cloud architecture experience, consider starting with a Platform-as-a-Service (PaaS) offering such as Heroku or Google App Engine. PaaS platforms are opinionated by design, reducing the number of wrong turns available to you. Save IaaS for workloads where you genuinely need that level of control.

2. People and Processes, Not Just Technology

The most commonly underestimated cloud migration challenge is not technical — it is organisational. Moving to the cloud changes how teams provision resources, how incidents are handled, how costs are allocated, and how development workflows are structured. Without deliberate investment in retraining, new runbooks, and updated operational processes, organisations find that they have simply replicated their on-premises problems in a new environment. Cloud-native operations require genuinely different habits, and changing habits takes time. Larger enterprises with deeply embedded processes will face a longer transition than younger, leaner organisations.

3. Defining a Clear Strategy and Business Objectives

Cloud migration is not a goal in itself — it is a means to an end. Before any migration work begins, document the specific business objectives the migration is intended to serve: faster time to market, reduced capital expenditure, improved disaster recovery, greater geographic reach, or something else entirely. These objectives determine which workloads migrate first, which cloud model (public, private, hybrid, or multi-cloud) is appropriate, and how success will be measured. Migrations that begin without this clarity frequently stall mid-way as teams argue over priorities that should have been resolved before a single VM was moved.

4. Overcoming Psychological Barriers

Concerns about security, uptime, and support quality are legitimate, but they should be evaluated on evidence rather than assumption. Mainstream cloud providers invest significantly in physical security, redundant infrastructure, compliance certifications, and 24/7 support — often exceeding what a mid-sized organisation can afford to maintain independently. The appropriate response to these concerns is a structured vendor assessment: review SLAs, compliance documentation (SOC 2, ISO 27001, FedRAMP where applicable), incident history, and support tier options. Data-driven evaluation replaces anxiety with actionable decision criteria.

5. Managing Time, Cost, and Security During Migration

Data migration is slow. Transferring large datasets requires significant bandwidth, careful scheduling to avoid production impact, and substantial engineering time. Security concerns during the transition period are also real — data in flight between on-premises and cloud environments must be encrypted, and access controls must be reviewed and updated as workloads move. Plan the migration in phases, transfer data during low-traffic windows, use encrypted transfer services provided by your cloud vendor, and conduct a security review at each phase boundary rather than only at the end.

6. Avoiding Hype-Driven Over-Migration

Not every workload belongs in the cloud on day one, and not every workload belongs with the same provider. A common mistake is moving too much too quickly, driven by executive enthusiasm or vendor pressure rather than a sober workload assessment. Map each workload against its performance requirements, compliance constraints, latency sensitivity, and cost profile before assigning it a migration target. Migrate in priority order — typically starting with workloads that are least business-critical and easiest to move — so your team builds competence before tackling the systems your business depends on most.

7. Change Management Across the Organisation

Cloud migration is a significant organisational change event, not just a technical project. Treat it accordingly. Stakeholders across the business — finance (for new cost models), security, compliance, application owners, and end users — all need to understand what is changing, when, and what it means for them. Establish a clear communication plan, identify change champions within each affected team, and build feedback loops that surface problems early. Requirements gathered from stakeholders during the migration should translate into concrete, measurable outcomes rather than vague aspirations.

8. Assessing Your Physical Network Infrastructure

Greater dependence on cloud services means greater dependence on your internet connectivity. Before migrating business-critical workloads, audit your physical network infrastructure. Key questions include: Do you have access to multiple ISPs for redundancy? Is your total available bandwidth sufficient for the increased traffic cloud-hosted applications will generate? Are your network edge devices capable of handling the load? Do remote and mobile workers have reliable connectivity to cloud endpoints? Gaps in physical infrastructure can silently undermine even a technically excellent cloud migration.

9. Accurately Estimating Cloud Costs

Cloud pricing is granular and variable, which makes it genuinely difficult to estimate accurately before you have real usage data. Common mistakes include underestimating data egress costs, failing to account for idle resource charges, and not modelling how costs scale with usage growth. Use your cloud provider’s cost calculator, and complement it with real monitoring data from any workloads already running in the cloud. A practical approach is to migrate your least-used services first — this generates real cost data with low business risk, and those workloads are also where you are most likely to find immediate savings over on-premises equivalents.

10. Deciding How Much to Re-Architect

Cloud migration teams often face pressure from two opposing directions: those who want to refactor everything to be perfectly cloud-native before migrating, and those who want to lift-and-shift without changing a single line of code. Both extremes carry risk. A complete rewrite before migration delays the benefits of cloud and can consume more budget than the migration itself is worth. A pure lift-and-shift often means paying cloud prices for on-premises performance characteristics, missing the efficiency gains that cloud-native design enables. A pragmatic middle path is to migrate first and then iteratively modernise — get to the cloud quickly, then progressively refactor workloads to use managed services and cloud-native patterns as budget and capacity allow.

11. Translating Your Security Posture to the Cloud

Cloud providers operate on a shared responsibility model: the provider secures the underlying infrastructure, and the customer is responsible for securing everything built on top of it — data, access controls, application configuration, and network policies. Many organisations migrating for the first time assume the provider handles more than it does. Before migration, map your existing security controls to their cloud equivalents and identify gaps. Request and review third-party attestation reports such as SOC 2 Type II from your cloud provider. These reports describe both the controls the provider has in place and the complementary controls your organisation is expected to implement.

12. Lease vs. Own: Understanding the Long-Term Cost Model

For compute-intensive workloads, the economics of renting cloud capacity versus owning and financing hardware shift significantly depending on time horizon and utilisation rate. Variable cloud pricing is highly efficient for bursty or unpredictable workloads. For steady, predictable workloads running at high utilisation, reserved instances or committed use discounts substantially reduce costs — but they introduce multi-year financial commitments. For some very high-volume, stable workloads, on-premises or co-location may still be the more cost-effective option. Model both scenarios with realistic utilisation projections before committing.

13. Connecting Legacy Systems with Cloud Applications

Most organisations have systems of record — ERP, CRM, mainframe-based processing, or purpose-built databases — that were never designed to communicate with cloud-native applications. Integrating these systems with newer cloud services is frequently the most technically demanding part of a migration. In the short to medium term, hybrid integration approaches are often the only viable path: middleware, API gateways, and event streaming platforms (such as Apache Kafka or cloud-native equivalents) can bridge on-premises systems and cloud applications without requiring a full rewrite of the legacy system. Choose integration vendors and tools that explicitly support hybrid environments and have a credible roadmap for fully cloud-native operation.

Planning Your Cloud Migration

No two cloud migrations are identical, but the challenges above appear consistently across organisations of every size and sector. The common thread is that successful migrations combine technical rigour with organisational readiness: clear objectives, honest cost modelling, a security-first mindset, and a realistic phased plan that builds competence before tackling your most critical systems.

• Start with a workload inventory — classify each workload by criticality, cloud-readiness, and migration complexity.
• Define success metrics before migration begins, not after.
• Build cost monitoring in from day one — cloud cost surprises are almost always the result of insufficient observability.
• Treat security as a parallel workstream, not a post-migration checklist item.
• Invest in team training early — cloud-native operations require skills that most on-premises teams do not yet have.

Original insights sourced from Forbes Technology Council contributor perspectives.

The Myth That DevOps Is Only for Startups

Despite a growing list of large organisations successfully adopting DevOps practices, a stubborn misconception persists in the enterprise world: that continuous delivery and DevOps transformation are achievable only by technology-native companies like Google, Amazon, and Facebook—not by large, complex organisations with decades of legacy infrastructure and regulatory burden.

Gene Kim, co-author of The DevOps Handbook, pushes back hard on this view. Speaking to Computer Weekly ahead of the DevOps Enterprise Summit in London (June 2017), Kim pointed to regulated industries—public sector bodies and financial services firms—as some of the most compelling proof points that DevOps can work at enterprise scale.

“If HM Revenue and Customs can do it, if Zurich Insurance and organisations like Allianz can do it—which are all organisations that have a reputation for being conservative—it just gives us more evidence that it really can be done.”

— Gene Kim, co-author, The DevOps Handbook

Kim noted that before he can even begin making the case for DevOps, enterprise leaders often pre-empt the conversation with objections: security, compliance requirements, change management processes, and entrenched legacy code are the most common. Yet organisations operating under government regulation and statutory restriction have managed to overcome precisely these barriers.

Common Enterprise Objections to DevOps

Resistance to DevOps in large organisations typically clusters around a predictable set of concerns:

• Security and compliance: Regulated industries worry that the speed of continuous delivery conflicts with audit trails and change-approval processes.
• Legacy systems: Monolithic architectures and decades-old codebases are seen as incompatible with modern CI/CD pipelines.
• Organisational complexity: Large enterprises have more stakeholders, more silos, and more entrenched processes than startups.
• Cultural inertia: Changing how developers and operations teams collaborate requires sustained leadership commitment.

John Willis, then Director of Ecosystem Development at Docker and a fellow co-author of The DevOps Handbook, acknowledged that enterprise practitioners who have succeeded with DevOps are often treated by peers as exceptions rather than examples to follow.

“People say things like: ‘It’s different for my company. You don’t know how hard it is, and I do. I really do.'”

— John Willis, co-author, The DevOps Handbook

How Scaremongering Puts CIOs Off DevOps

Willis identified a second major barrier: the way DevOps is marketed and sold to enterprise decision-makers. Aggressive sales pitches and over-the-top evangelism have caused many CIOs to become understandably cynical about the entire movement.

“I’ve watched a lot of sales people over the years, on calls I’ve done, and they’ll go into enterprises and say—after just 10 minutes of meeting them—you’re doing it all wrong and you need to stop now and do it this way instead.”

— John Willis

Few experienced IT leaders respond well to that approach, especially when it is paired with doom-laden predictions about being overtaken by competitors. Willis described a pattern he has observed repeatedly: every two years or so, a new technology or practice is declared existentially important, and those who don’t adopt it immediately are positioned as dangerously behind.

“I spoke to a large financial organisation the other day and five years ago they were told they had to use Puppet. The world would be doomed if they didn’t go to Puppet. Then they started hearing that if you don’t do DevOps, you’re doomed, and then they’re told a year or so later that if you’re not doing Docker, you’re horrible and should be thrown in jail.”

— John Willis

The practical consequence is that CIOs develop a healthy—sometimes excessive—scepticism toward any new IT practice, even one with genuine, demonstrated value like DevOps. Willis’s advice: look past the hype cycle and focus on peer organisations that have made measurable progress.

Are You Ever “Done” With DevOps?

A question that surfaces frequently among enterprise IT leaders is whether there is a defined finish line for DevOps adoption. Kim argues this framing misunderstands what continuous delivery and continuous improvement actually mean—there is no completion state, because the goal is ongoing capability-building, not a one-time project.

That said, Kim is clear that progress is both measurable and rewarded. He pointed to specific organisations—Capital One in the US, ITV and Barclays in the UK—as examples of enterprises that, while not at 100% DevOps adoption, have made enough progress that the leaders championing those efforts are being given greater organisational authority as a result.

“My prediction is they will continue to be elevated to influence the practices in as much of the organisation as possible, and they can share their experiences about how to foster these initiatives without getting fired, or having it killed by the more conservative elements within the organisation.”

— Gene Kim

External Forces Beyond IT’s Control

Willis raised an important and often overlooked point: even organisations that execute a DevOps transformation correctly can be derailed by macro-economic forces entirely outside IT’s influence. A retailer that builds excellent CI/CD pipelines and a strong DevOps culture can still struggle if the retail sector itself is under structural pressure.

“I get this pain in my heart when I see a company that does everything right, but then they get off tilt—not because of anything they’ve done with IT, but because of the economics of the business they’re in.”

— John Willis

Kim echoed this with a widely cited example: no IT transformation could have saved Blockbuster from the structural disruption caused by streaming services. Technology capability is a necessary but not sufficient condition for surviving disruption.

“No amount of technology could have saved Blockbusters. Maybe they could have found a way out, but technology in and of itself could not have saved Blockbusters.”

— Gene Kim

Why DevOps Still Matters for Large Enterprises

Despite the caveats, Kim’s broader argument is that DevOps capability is increasingly table-stakes for any established enterprise that wants to remain competitive. Large brands in any industry vertical face a growing number of smaller, more agile competitors who can iterate faster and deliver value to customers more efficiently.

The practical implication for enterprise IT leaders:

• Treat DevOps as a long-term capability investment, not a project with an end date.
• Look to peer organisations in similarly regulated or complex environments for credible proof points.
• Be sceptical of vendor-driven scaremongering, but don’t let that scepticism prevent genuine modernisation.
• Measure progress, reward the people driving it, and expand successful practices incrementally across the organisation.
• Recognise that IT transformation improves competitive agility but cannot compensate for fundamental business model problems.

The organisations that have made DevOps work at enterprise scale—in regulated financial services, government, and broadcasting—demonstrate that the barriers most commonly cited are real but not insurmountable. The challenge is sustained leadership commitment and a willingness to learn from those who have already made the journey.

Why Scaling Agile Is Harder Than It Looks

Large enterprises face enormous pressure to deliver digital products faster. The instinctive response has been to scale Agile methods — investing in frameworks like SAFe (Scaled Agile Framework), sending teams through training, and procuring collaboration tooling. Yet these investments repeatedly fall short of expectations.

The reason is structural. Most Agile frameworks, training programmes, and tools are designed with the development team at the centre. They say comparatively little about the business constraints that surround those teams — and almost nothing about the fact that many of the stakeholders an Agile team depends on do not speak the language of sprints, user stories, and retrospectives.

Research analysing data from nearly 300 Agile teams over five years (attributed to CEB, now part of Gartner) identified three coordination challenges that must be solved for Agile to deliver measurable results at enterprise scale. Those challenges involve three critical partner groups: product owners, finance leaders, and adjacent delivery teams.

Challenge 1: Product Owners Are Made, Not Born

Digital ambition is common in large organisations. The practical ability to steer a digital initiative through an Agile delivery model is far less common. Most Agile interpretations set a low bar for what makes a good product owner: willingness to engage and some prior IT project exposure. In practice, these are table-stakes, not differentiators.

For Agile to scale, IT leaders need to deliberately develop three qualities in their product owners:

• Capability — Effective product owners need a strategic mindset, strong stakeholder management skills, and entrepreneurial leadership. The first two can be recruited or trained relatively easily. Entrepreneurial leadership — which demands genuine customer focus and comfort with innovative, sometimes ambiguous thinking — is harder to find and must often be cultivated deliberately through competency models and targeted development programmes.
• Clarity — Business enthusiasm for digital is not the same as knowing how to contribute inside an Agile project. Leading IT organisations provide product owners with detailed checklists that specify the activities, required stakeholder inputs, and deliverables expected at each stage. This removes ambiguity and makes quality product ownership repeatable regardless of individual experience level.
• Commitment — Product owners must sustain engagement across the full lifecycle of a product, not just at kick-off. The most effective way to build this commitment is through peer networks — communities of product owners across the enterprise who share best practices, provide coaching, and hold each other accountable.

The underlying insight is simple: great product ownership is an organisational capability that must be engineered, not a personal quality that can be assumed.

Challenge 2: Legacy Funding Processes Can Sink Even the Best Agile Teams

Traditional IT funding processes were designed for Waterfall delivery. Budgets are allocated annually to discrete projects with defined scope. Expenditure is tracked against a fixed plan. Change requests are expensive and slow.

Agile — particularly Agile at scale aimed at continuous delivery — operates on a fundamentally different rhythm. Work is iterative, scope evolves, and value is delivered incrementally rather than at a single go-live date. This makes conventional project-based funding a poor fit and a frequent source of friction.

Several alternative funding models are gaining traction in enterprises attempting to bridge this gap:

• Value-stream funding — Budget follows the flow of value to the customer rather than individual projects. Teams are funded to maintain and improve a product continuously.
• Team capacity-based funding — Stable, cross-functional teams are funded as a standing capability. Priorities and work items shift, but the team budget remains consistent.
• Venture capital (VC) style funding — Particularly useful for exploratory or proof-of-concept work, this model funds early-stage discovery cheaply and unlocks further investment only when hypotheses are validated.

Importantly, a wholesale overnight switch to Agile funding is neither necessary nor advisable. Experienced organisations run a portfolio of funding models, matching the approach to the nature of the work. A digital proof of concept benefits from a VC-style gate model; an established product line suits value-stream funding; a well-defined integration project may still be best served by conventional project funding. Running these models in parallel also serves an educational purpose — finance and business leaders learn firsthand why different approaches suit different contexts.

Challenge 3: Agile Must Operate in a Loosely Coupled Process Ecosystem

No enterprise runs purely on Agile. Infrastructure teams operate under ITIL. Security and compliance functions follow their own governance frameworks. Some programmes are still delivered using Waterfall methods — appropriately so. The ambition of making Agile universal is rarely realistic and rarely the right goal.

The more useful goal is interoperability: building Agile, Waterfall, ITIL, and other frameworks into a system where they can coexist and hand off to one another without destroying the value each creates. This is what architects mean when they speak of loosely coupled systems — and the principle applies equally to process ecosystems.

Achieving this requires Agile teams to look beyond the customer and take explicit responsibility for coordination. In practice, this means:

• Actively managing upstream and downstream dependencies with other teams and delivery programmes.
• Representing non-functional concerns — such as security, infrastructure readiness, or compliance requirements — as explicit items in the backlog (for example, as “security user stories”).
• Assigning coordination as a named, team-level responsibility rather than assuming it will happen informally.

The core problem is that Agile teams are trained to listen to the voice of the customer. Far fewer are trained to listen to the voice of coordination — the signals coming from adjacent teams, infrastructure, and governance functions whose work must align with the Agile team’s output. Leaders who make coordination a first-class concern prevent value from being eroded in the handoff zones between Agile and non-Agile parts of the organisation.

From Evangelism to Ambassadorship

When IT leaders set out to scale Agile, the instinct is often to evangelise — to win hearts and minds, promote Agile champions, and build a groundswell of enthusiasm. In a single team or a small organisation, this works. In a large enterprise with hundreds of business stakeholders who have no context for user stories, kanban boards, or sprint reviews, aggressive evangelism can backfire. It signals that Agile teams are speaking a private language and expect others to learn it.

Scaling Agile at enterprise level depends less on evangelism and more on ambassadorship — the practical ability to collaborate across boundaries, translate between different working models, and keep focus on business outcomes rather than methodological purity. This means:

• Meeting partners where they are, rather than insisting they adopt Agile vocabulary.
• Framing Agile practices in terms of business outcomes — faster time to market, reduced rework, earlier validation — rather than process compliance.
• Accepting that a portfolio of delivery methods will coexist, and that the measure of success is outcome quality, not adherence to any single framework.

The hard lesson many organisations have learned is that the outcome is what matters most. Agile is a means, not an end. Scaling it successfully requires solving the coordination, funding, and capability challenges that surround the development team — not just optimising what happens inside the team itself.

Key Takeaways

• Tools, training, and Agile frameworks are necessary but not sufficient for enterprise-scale Agile adoption.
• Effective product ownership must be deliberately built through capability development, role clarity, and peer support networks.
• Legacy annual project funding is structurally incompatible with continuous delivery; a portfolio of funding models is a practical transition path.
• Agile teams must own coordination with adjacent functions and frameworks, not just the voice of the customer.
• Ambassadorship — outcome-focused collaboration across boundaries — scales better than Agile evangelism in large organisations.