Digital Transformation Is a Journey, Not a Destination

For banks and financial institutions, digital transformation is less a discrete project and more an ongoing evolution. Every organisation starts from a different point, and the barriers to progress are significant: institutional inertia, entrenched organisational structures, and gaps in knowledge of modern technologies like microservices, containers, and CI/CD pipelines.

Understanding why these barriers exist — and how microservices can help overcome them — is the first step toward meaningful, sustainable change.

Why Bank Technology Is Rooted in the Past

The technology infrastructure of most established banks is a product of their history. Banks grew organically along product lines — from cash and cheques to increasingly complex financial instruments — and their IT systems grew alongside them. Core banking platforms were originally designed to support physical products distributed through branch networks, and they reflect the analogue world in which they were built.

Over the decades, new channels were layered on top: telephone banking, ATMs, connected trading systems, and eventually internet and mobile banking. Each channel typically acquired its own dedicated support team, reinforcing a siloed culture that makes coordinated, cross-functional change extremely difficult. The cumulative result is a deeply conservative engineering culture that gravitates toward incremental, low-risk changes rather than first-principles architectural thinking.

The Skills Gap: A Real Barrier to Microservices Adoption

Microservices architecture is not a plug-and-play solution. Implementing it effectively requires engineers with specific skills: distributed systems design, API gateway management, container orchestration (Kubernetes, Docker), service mesh configuration, observability tooling, and DevSecOps practices. This talent pool is limited, and much of it is absorbed by technology companies that offer more competitive compensation and a stronger engineering culture than traditional financial institutions.

Banks face a compounding challenge: they need engineers who understand both modern distributed systems and complex financial domain logic. This combination is rare, and building such a team takes time and sustained investment.

Greenfield Digital Banks: A Partial Solution

Many incumbent banks have responded to these challenges by launching separate digital or direct banks on greenfield infrastructure — either as new brands or wholly owned subsidiaries. This approach buys time and delivers faster customer-facing improvements, but it has a significant limitation: greenfield digital banks rarely offer the full product depth of a traditional bank. As customer expectations rise, this product gap can become a competitive liability rather than an advantage.

Why Standing Still Is Not an Option

Banks face competitive pressure from multiple directions simultaneously:

• Traditional competitors who are further along their digital transformation journey.
• FinTechs offering targeted, API-first financial products with low overhead and high UX quality.
• Big Tech platforms — companies like Amazon, Google, and Apple — whose potential moves into retail financial services represent an existential threat to banks still running on legacy stacks.

Organisations that have not modernised their delivery capability will find it nearly impossible to respond quickly to any of these threats. The question is not whether to adopt microservices, but how to do so without disrupting existing customers or destabilising production systems.

How Continuous Delivery Changes the Software Model

Tech giants such as Amazon and Google have demonstrated that software delivery is a continuous process, not a periodic event. These organisations make thousands of production deployments per day. Each release is small, well-tested, and independently deployable — making rollbacks straightforward and blast radius manageable when issues arise.

Microservices architecture makes this model achievable for other organisations by decomposing a monolithic application into independently deployable services. Each service:

• Has a clearly defined, bounded responsibility.
• Exposes a versioned API contract.
• Can be deployed, scaled, and updated independently of other services.
• Can be owned end-to-end by a small, cross-functional product team.

The result is a dramatically shorter feedback loop between engineering and business value: features reach customers faster, defects are caught earlier, and the platform becomes more stable over time — not less stable, as the traditional view of frequent releases would suggest.

DevOps as a Business Function, Not an IT Silo

Agile principles and continuous delivery are not purely technical concerns. They represent a cultural shift: engineering teams move from being a cost centre within an IT department to being embedded in the business as a driver of commercial outcomes.

In a mature microservices organisation, a DevOps team:

• Works directly with product owners and business stakeholders to define and prioritise delivery.
• Owns the full lifecycle of a service — from design through operation.
• Uses tooling for version control, automated testing, deployment pipelines, and observability to enforce safety at speed.
• Ships to production with zero downtime using techniques such as blue-green deployments, canary releases, and feature flags.

This model fundamentally contradicts the traditional assumption that frequent releases and platform stability are in tension. With the right architecture and tooling, they are complementary.

The Compounding Benefits of a Microservices Architecture

Once the initial investment in decomposition and tooling is made, microservices create a compounding cycle of benefits:

• Reduced coupling: Services have fewer dependencies on one another, so changes in one area do not cascade unpredictably into others.
• Independent scaling: High-traffic services can be scaled horizontally without scaling the entire application.
• Faster innovation: New capabilities — including AI-driven personalisation and real-time analytics — can be integrated as discrete services without rebuilding core systems.
• Improved resilience: A failure in one service does not necessarily bring down the entire platform, provided services are designed with circuit breakers and graceful degradation in mind.
• Talent attraction: Engineers prefer working on modern, well-structured codebases with clear ownership and frequent deployments.

The ability to incorporate technologies such as machine learning models for customer behaviour analysis, fraud detection, or personalised product recommendations becomes significantly more practical when these capabilities can be delivered as independently deployable services.

Migration Strategy: Timing and Prioritisation Matter

A full big-bang migration from monolith to microservices is rarely advisable, and for most banks it is not feasible. A more pragmatic approach involves:

1. Identifying bounded contexts within the existing monolith — areas of functionality with clear domain boundaries that can be extracted as services.
2. Prioritising by business value — targeting the domains where faster, more frequent releases will have the greatest commercial impact.
3. Applying the Strangler Fig pattern — incrementally routing traffic to new microservices while the monolith shrinks over time, rather than replacing it wholesale.
4. Building delivery infrastructure in parallel — CI/CD pipelines, container orchestration, observability, and API gateway configuration must be in place before microservices can be deployed safely at scale.

The migration timeline will differ for every institution. Not every application is a good candidate for microservices decomposition, and forcing the pattern onto the wrong problem can create unnecessary complexity. The goal is to identify where microservices deliver genuine business value, not to adopt the architecture as an end in itself.

Preserving What Makes the Bank Unique

Technology transformation must not erase what differentiates one bank from another. Product richness, relationship history, regulatory expertise, and brand trust are competitive assets that have been built over decades. A well-executed microservices migration builds on these strengths, exposing them through modern channels and APIs, rather than replacing them with generic commodity components.

Critically, changes must be made in a way that is invisible to customers. Downtime, degraded functionality, or data inconsistency during migration will erode the trust that the transformation is intended to protect. Zero-downtime deployment strategies, thorough automated testing, and robust rollback procedures are non-negotiable requirements.

Key Takeaways

• Legacy banking infrastructure is the product of decades of organic growth, and it was never designed for the pace of change that modern markets demand.
• Microservices architecture, combined with continuous delivery and DevOps practices, enables banks to ship smaller, safer changes far more frequently.
• The skills required to execute this transition are scarce; building the right team is as important as choosing the right technology.
• A phased migration strategy — using patterns like Strangler Fig and starting with high-value bounded contexts — reduces risk and demonstrates early business value.
• The end goal is not just technical modernisation: it is a more agile, customer-centric organisation capable of anticipating and responding to market change.

From DevOps to DevSecOps: A Decade of Evolution

The DevOps methodology has roots stretching back to roughly 2009, when Patrick Debois coined the term by naming a Belgian software conference “devopsdays.” In the years since, DevOps has become the dominant engineering culture for organizations seeking to accelerate delivery and improve product quality. As the practice matured, a natural—and necessary—evolution emerged: DevSecOps, the intentional integration of security practices throughout the entire DevOps lifecycle.

Rather than treating security as a gate at the end of the pipeline, DevSecOps embeds security thinking into every phase: planning, development, testing, deployment, and operations. The goal is to eliminate the old model where security was a separate team that reviewed software only at release time, replacing it with shared ownership across the entire engineering organization.

Security Is Not an Afterthought—It’s “Job Zero”

One of the most important points raised at DOES18 was a concern about the very name “DevSecOps.” Ilkka Turunen, Head of Solutions Architecture at Sonatype, voiced a widely felt tension:

“I’ve never been crazy about the term DevSecOps, because it’s like ‘Sec’ is an afterthought. You know, we were squeezing it in between Dev and Ops, the last kid that got on the bus, and we’re like, go on, just sit in there. For all of us, security is the first priority, the top job—’job zero,’ we sometimes call it. And therefore, for DevOps, it actually understands that security is key, and is the first thing that you do.”

— Ilkka Turunen, Sonatype

The term “job zero” is a useful mental model: before you write a single line of code or define a pipeline stage, security considerations should already be in play. This includes threat modeling during design, dependency scanning during development, and automated policy enforcement at build time.

GDPR and Privacy by Design

The GDPR regulation, which came into full effect in May 2018—shortly before the DOES18 London event—gave the DevSecOps conversation additional urgency. Turunen noted that GDPR moves well beyond data portability and breach notification requirements. Its broader principle of “privacy by design” requires that data protection be architected into systems from the outset, not retrofitted afterward.

For DevOps teams, this translates into concrete engineering decisions:

• Encrypting sensitive data at rest and in transit by default
• Minimizing data collection to only what is strictly necessary
• Implementing access controls and audit logging as infrastructure-as-code
• Running automated compliance checks as part of CI/CD pipelines

Privacy by design is not a checkbox; it is a cultural and architectural commitment that aligns directly with the DevSecOps philosophy.

Making Security Everyone’s Responsibility

A central challenge in DevSecOps adoption is cultural: how do you build an organization where every engineer thinks of themselves as a security practitioner? Turunen drew a parallel to how testing evolved over the past decade:

“So if you think about testing 10 years ago, it was literally people running from test execution plans, and gradually they changed from that to becoming writers of tests, people that write the automatic-execution, help people, help the floor become more efficient at testing for themselves. Teaching them unit testing, all these other frameworks. So I feel like we’re at the brink of a similar kind of change. I think it’s a mixture of both incentives and psychology, and just changing roles.”

— Ilkka Turunen, Sonatype

The analogy is instructive. Testing was once a specialized, siloed function. The shift-left testing movement brought it into the hands of developers, supported by tooling (unit test frameworks, CI integration, code coverage reporting) that made it practical. DevSecOps is following the same arc:

• Security training for developers — secure coding practices, OWASP Top 10 awareness, threat modeling basics
• Security tooling integrated into developer workflows — SAST, DAST, SCA tools running in IDEs and CI pipelines
• Clear feedback loops — surfacing security findings at the point in the workflow where developers can act on them immediately
• Incentive alignment — measuring and rewarding secure engineering behavior, not just shipping velocity

Security as a Subset of Good Engineering

Zane Lackey, founder of Signal Sciences, offered perhaps the clearest framing of the DevSecOps philosophy:

“The best way I’ve ever seen, like the highest performing organizations view it, is security is a subset of good engineering. In the way that resiliency is, reliability is, quality is, performance is, is a subset of good engineering.”

— Zane Lackey, Signal Sciences

This framing removes the adversarial dynamic that often exists between security and engineering teams. When security is understood as an engineering quality—on par with performance, reliability, and maintainability—it stops being an external audit function and becomes an intrinsic property of the software being built.

Practically, this means:

• Security requirements are written alongside functional requirements in user stories
• Secure defaults are baked into internal libraries and platform services
• Security findings are treated with the same severity as bugs and performance regressions
• Architecture reviews include threat modeling as a standard component

The Role of Cloud Providers and Machine Learning in Security

Margo Cronin, Senior Solution Architect at AWS, highlighted the growing role of cloud-native security services and machine learning in automating security at scale:

“You now have services that can scan your landscape and say do you know these large files contain client identifying data, do you know you have keys there? And then you have services where you can then change that behavior automatically. But I think that’s where we’re going to see cloud service providers become a lot more active. You know, using machine learning to harden your production landscape before you actually even go to the security operators.”

— Margo Cronin, AWS

Cloud providers now offer a broad portfolio of security services that DevOps teams can integrate directly into their pipelines and infrastructure. Common categories include:

• Data classification and discovery — automatically identifying sensitive data (PII, credentials, keys) stored in cloud resources
• Threat detection — continuously monitoring API calls, network flows, and account behavior for anomalies
• Configuration compliance — continuously evaluating cloud resource configurations against security benchmarks and organizational policies
• Automated remediation — triggering automated responses (quarantining resources, revoking credentials) when violations are detected

The promise Cronin describes—using machine learning to harden production environments proactively rather than reactively—reflects the broader direction of cloud security tooling, which increasingly operates continuously rather than on a scheduled audit basis.

Key Takeaways for DevOps Teams Adopting DevSecOps

The discussion at DOES18 surfaces several actionable principles for engineering organizations looking to mature their DevSecOps practice:

1. Reframe security as “job zero” — position it as the first concern, not a final gate.
2. Embed security tooling in the developer experience — SAST, SCA, secrets scanning, and IaC policy checks should run in CI/CD, not in a separate security pipeline.
3. Build the cultural change incrementally — mirror the path testing took: start with training, add tooling, measure outcomes, adjust incentives.
4. Treat security as an engineering quality attribute — give it the same weight as reliability, performance, and code quality in design and review processes.
5. Leverage cloud-native security services — use continuous compliance, data classification, and threat detection capabilities offered by your cloud provider to achieve security at scale.
6. Design for compliance from day one — regulations like GDPR require privacy and security to be architected in, not bolted on.

Further Viewing

The full DOES18 panel discussion, along with Margo Cronin’s presentation on “Security Automation at Scale” and Zane Lackey’s presentation on “How You Can Use DevOps to Make You More Secure,” were made available on DevOps TV following the event. Search the DevOps Enterprise Summit archive or the IT Revolution YouTube channel for these sessions.

The Real Problem: Culture, Not Tools

When organizations ask how to start with DevOps, the instinct is often to reach for tools — adopt containers, migrate to the cloud, stand up a CI/CD pipeline. But according to Eric Schoonover and Robert Duffy, co-founders of the consultancy Sodo (Ship On Day One), that instinct misses the deeper issue.

Duffy, who brings experience from Amazon and Time magazine, and Schoonover, who has worked at Microsoft, Netflix, and the U.S. Department of Defense’s Digital Service, argue that the cultural transformation is the hard part — and the part most organizations underestimate.

“A lot of companies are still doing engineering delivery like 1800s manufacturing was done. It’s a craft-based system, parsing work out to different teams. We want to help non-tech companies think about the cultural transformation. It’s not just about moving to the cloud and installing Docker.”

— Robert Duffy, co-founder, Sodo

Notably, Duffy points out that neither he nor Schoonover used the term “DevOps” during their time at Amazon and Netflix. The practices were simply how software engineering was done. That framing is useful: DevOps is not a product you install, but a set of behaviors and capabilities that high-performing teams exhibit naturally.

Small Plans Work Best: The 15-Capability Framework

To create a repeatable starting point, Duffy and Schoonover interviewed approximately 150 high-performing software development teams, documenting observations and patterns. From that research, they distilled their findings into 15 capabilities, each broken into four stages of maturity.

The goal of this structure is deliberate: avoid overwhelming the organization. Instead of presenting a sweeping transformation roadmap, the framework identifies the highest-priority items and sequences them so that early wins build credibility with business stakeholders.

“We try to get to a small set of very actionable items that we helped select that justify the ROI calculations and case studies. We help companies recognize the size of the problem and attack it in small identified chunks to gain credibility with the business.”

— Robert Duffy, co-founder, Sodo

This approach mirrors advice found throughout DevOps literature: start with a value stream mapping exercise, identify bottlenecks, pick one constraint to improve, and demonstrate measurable progress before expanding scope. The specifics of Sodo’s 15 capabilities were not publicly detailed in the original source, but the principle — narrow focus, visible momentum — is well-established in DevOps practice.

Key Principles for Starting a DevOps Transformation

Whether you engage external consultants or pursue transformation internally, the following principles reflect what high-performing teams consistently do:

• Start with culture, then process, then tools. Technology is the easiest part to change. Organizational habits and incentive structures are the hard part.
• Identify your value stream. Understand how work flows from idea to production, and where it gets stuck. This surfaces the highest-leverage improvement opportunities.
• Pick small, visible wins first. Early successes build trust with leadership and reduce resistance from skeptical engineers. Don’t attempt to transform everything at once.
• Make CI/CD a baseline expectation. Continuous integration and continuous delivery pipelines are not optional extras — they are the foundation that enables everything else, including fast feedback and safe deployments.
• Treat legacy systems as a continuum. Not every system is equally amenable to DevOps practices. Some will adopt CI/CD quickly; others, particularly those involving custom hardware or highly regulated environments, require more time and creative approaches. Acknowledge this spectrum explicitly rather than pretending all workloads are equal.
• Ship something. The discipline of getting working software out the door — even incrementally — creates real feedback loops and real learning. “Something shipped out the door is really what we preach,” Duffy said.

DevOps in Non-Traditional Environments: The Legacy and Defense Context

One of the more instructive aspects of the Sodo case study involves a defense contractor — an environment about as far from a Silicon Valley startup as possible. A senior engineering manager at that organization described the challenge plainly: the organization wanted a consistent software delivery process across all systems, but the range of environments was enormous, from straightforward web applications to custom hardware with deeply embedded software.

“We want to look at software development as a continuum. But at one spectrum, we have the low-hanging fruit that it’s easy to see how to make changes to, and on the other spectrum we have custom hardware and software that is not low-hanging fruit. We want to have the same kind of systems in place for both so that we can have CI and CD running. That’s the area we’re a little concerned about.”

— Senior engineering manager, defense contractor (anonymous)

This is a real and common challenge. Organizations in aerospace, defense, financial services, healthcare, and manufacturing all face legacy systems that resist easy automation. The practical answer is not to exclude those systems from DevOps thinking, but to apply the same principles at whatever pace and with whatever constraints the system imposes — while capturing quick wins on the more flexible parts of the portfolio.

The same manager noted that the Sodo team’s willingness to work alongside engineers — rather than simply diagnosing problems and leaving — was a key factor in acceptance. Engineers, who are often skeptical of outside consultants, responded positively precisely because the consultants did not arrive claiming to have all the answers.

The Role of External Help: When Consultants Make Sense

Bringing in external consultants to help start a DevOps transformation is not the only option, but it is a legitimate one — particularly for organizations where internal advocates lack the organizational authority or cross-functional visibility to drive change on their own.

The value a good DevOps consultancy brings is not primarily technical knowledge (your engineers likely already know what CI/CD pipelines and infrastructure-as-code are). The value is in:

• Providing an outside perspective that internal politics cannot easily dismiss
• Translating engineering improvements into business ROI language that resonates with executives
• Offering a structured, repeatable approach that prevents the team from getting lost in tool debates
• Creating accountability and momentum through regular check-ins and visible milestones

The Sodo team explicitly declined to simply deliver projects for clients. Their stated focus was on teaching organizations how to sustain DevOps practices independently — which is the right model. A transformation that depends indefinitely on external consultants is not a transformation.

Patience and Momentum Are Both Required

Duffy’s framing of “patience is important, but so is momentum” captures a genuine tension in DevOps transformations. Moving too fast burns out teams and produces fragile systems. Moving too slowly allows organizational inertia to kill the initiative before it gains traction.

The practical resolution is to run a short, focused pilot — a single team, a single service, a single pipeline — and make that work well before expanding. Document what changed, measure the outcome, and use that story to justify the next step. This is the pattern that works in organizations of all sizes and industries.

DevOps is not a destination you reach; it is a direction you move in. The question of how to start matters less than the decision to start — and the discipline to keep going.

Original reporting by TechTarget. This article summarizes and expands on the source material for a DevOps engineering audience.

1. You Can Start Slowly

Jeffrey Hammond, vice president and principal analyst, Forrester Research

“It’s easy to get started on the road to DevOps improvement by asking a very simple question: ‘If we changed one line of code in this application, how long would it take to get it into production using our normal processes and tools?’ Once you get that answer, ask: ‘Why? What’s the first easiest thing we can change to shorten this cycle?’ Then repeat that question each time to remove a roadblock, automate a manual process, or change a tool. The journey of 1,000 miles begins with a single step.”

Hammond’s approach is deliberately low-risk. You do not need a transformation programme, a new org chart, or executive sponsorship to ask one diagnostic question. Measuring your current lead time — even informally — creates a baseline that makes every improvement visible and defensible.

2. Technology Is Your Friend

Matthew Heusser, managing consultant, Excelon Development

“Usually, putting a basic CI harness in place and an automated deploy system is relatively easy. It’s the people, culture, and risk-management pieces that are hard.”

Heusser’s point is frequently validated in practice. Tools such as Jenkins, GitLab CI, GitHub Actions, or CircleCI can be configured to run a build and test suite within hours. Automated deployment to a staging environment adds a day or two of work at most. These wins are concrete, measurable, and do not require anyone to change their professional identity — which is why teams reach for tooling first.

3. DevOps Can Be an Easy Sell to Management

Torsten Volk, senior analyst, Enterprise Management Associates

“The perspective of freeing up a large share of the approximately 30% of developers and operators absorbed by constant release preparations makes it at least easy for management to motivate staff to adopt DevOps. Additional motivation for both operators and developers is that they get to work with leading-edge technologies that will look good on their résumés, and that their entire group will become much closer to the business.”

The business case for DevOps tends to write itself once you quantify release overhead. Automating repetitive release work frees engineering time for feature development. That argument resonates with finance and leadership alike, giving teams an easier path to budget and organisational support.

Note: The “approximately 30%” figure quoted by Volk is an analyst estimate, not a universally verified benchmark. Your organisation’s overhead will vary depending on release cadence, team size, and existing automation maturity.

4. Is the DevOps Process Really That Hard?

Theresa Neate, test consultant and quality analyst

“I beg to differ that everyone says or even thinks that the DevOps process is hard. But if anything is ‘easier’ than the rest, it is likely the tooling — that includes all forms of automation. Tooling is one of the first things teams implement when doing transformations to the DevOps way of life, because it is not only more visible than some other changes, but also because technology solutions are mostly easier than process and people solutions. As DevOps is, in reality, ‘Agile infrastructure,’ I do need to remind readers that this Agile tenet still holds true: ‘Individuals and interactions over processes and tools.’ So yes, the tools might be easier, but we still need to address processes and especially individuals and interactions in our DevOps transformations.”

Neate’s pushback is worth taking seriously. Teams that treat DevOps as a tooling exercise — installing a CI server and calling it done — often stall once they hit the first cross-team coordination problem. The Agile Manifesto’s emphasis on people over tools applies just as much in an infrastructure context as in software development.

5. Easy to Begin, Hard to Continue

Bob Reselman, developer, system architect, and columnist

“Yes, agreeing to commit to working and growing in the DevOps paradigm is pretty easy. Actually doing the ongoing work required to meet the commitment is a lot harder, particularly as external forces pressure teams to incur technical debt in order to meet short-term goals and quarterly profits.”

Reselman identifies one of the most common failure modes: DevOps enthusiasm fades under delivery pressure. When a deadline looms, the manual workaround feels faster than maintaining the pipeline. Over time, those shortcuts accumulate into the same fragile, hand-cranked release process that DevOps was meant to replace. Sustaining DevOps practices requires deliberate investment — protected time for pipeline maintenance, blameless post-mortems, and a culture that treats automation as a first-class deliverable.

6. The Cloud Lowers the Entry Barrier

Gordon Haff, technology evangelist, Red Hat

“Technology is easy. It’s people who are hard. Integrated container-as-a-service and platform-as-a-service cloud services may not give you something tailored to your exact production requirements out of the box. But they can give you a surprisingly easy on-ramp to development environments, build tools, monitoring, and other tooling that’s ideal for DevOps workflows and cloud-native app development. You can fine-tune later, but get started surprisingly quickly.”

Managed cloud platforms — whether that means AWS CodePipeline, Azure DevOps, Google Cloud Build, or an OpenShift cluster — package up the infrastructure concerns that used to consume weeks of setup time. Teams can have a working CI/CD loop and ephemeral environments running in a day. That speed of experimentation removes one of the most common excuses for not starting.

7. Win Hearts and Minds First

Rob Lambert, owner and founder, Cultivated Management

“DevOps is essentially bringing together people from potentially different teams, with different skills, to enable a more seamless and friction-free delivery of value to production. At a technical level, it’s often a challenge, but not something a group of like-minded, talented people cannot solve. The technical challenge, for some people, can be reasonably straightforward and really engaging. One of the hardest aspects of DevOps can be influencing hearts and minds about this new change, especially in environments where the roles of dev and ops have traditionally been separate. Of course, if you don’t have hearts and minds to influence around a new change, then the journey will be all the smoother and, in some cases, reasonably easy.”

Lambert’s observation reframes the difficulty: in a greenfield team, or one with no entrenched silos, DevOps can feel almost natural. The hard cases are organisations with long-standing cultural divisions between development and operations — where each side has different incentives, metrics, and professional identities. In those environments, no tool will substitute for patient, sustained work on relationships and shared goals.

Key Takeaways

• Start with a diagnostic question. Measure how long it takes to push one line of code to production today, then remove the first obstacle.
• The tooling is genuinely the easy part. A basic CI pipeline and automated deployment can be operational within days using modern managed services or open-source tooling.
• Sell the business case with time savings. Quantify how much engineering time is currently consumed by manual release work and use that to justify the investment.
• Don’t mistake tooling for transformation. Automation without culture change addresses symptoms, not causes.
• Plan for sustainability, not just launch. Protect time for pipeline maintenance and resist the pressure to take manual shortcuts under deadline pressure.
• Cloud platforms dramatically lower the barrier to entry. Use managed CI/CD and container platforms to get a working DevOps loop running quickly, then customise as you learn.
• Invest in people as much as pipelines. The hardest and most durable work in a DevOps transformation is cultural — shared ownership, psychological safety, and cross-functional collaboration.

Original expert perspectives sourced from TechTarget. Analyst roles and affiliations reflect the original publication date of April 2018.

Why Scaling DevOps in Large Organizations Is Harder Than It Looks

For small teams, adopting DevOps is often straightforward: fewer stakeholders, tighter feedback loops, and development and operations skills that may already sit in the same room — or the same person. The cultural shift happens organically because the distance between intent and action is short.

Large enterprises face a fundamentally different challenge. Complex delivery programs, entrenched organizational structures, separate reporting lines for development and operations, and risk-averse governance processes all create friction. Plenty of organizations have launched DevOps transformation programs and stalled — or failed outright.

Yet the upside is real: faster, more reliable software delivery, reduced deployment risk, and shorter feedback cycles between engineering and the business. The question is how to get there at scale without repeating common mistakes.

Start With Your Bright Spots

In almost every large organization, at least one team finds a way to make DevOps work on its own — often on a greenfield project, led by a progressive engineering manager, with the freedom to choose its own tools and ways of working. These teams are your proof of concept.

The temptation is to simply copy what that team did and roll it out broadly. This rarely works cleanly. Context matters enormously: the team’s composition, the nature of the project, the support they received, and the constraints they didn’t face. Replicating outcomes requires understanding the underlying conditions, not just the practices.

With that in mind, here are four key lessons drawn from DevOps success stories that genuinely translate to enterprise scale.

Lesson 1: Don’t Force DevOps as a Concept

Mandating DevOps from the top down — telling teams they will “do DevOps” without explaining why or giving them agency — is one of the most reliable ways to generate resistance and cynicism. Engineers in particular tend to respond poorly to cultural labels imposed without context.

A more effective approach is to show teams how DevOps practices make their day-to-day work better: fewer late-night incidents, faster feedback on pull requests, less time waiting on manual approvals. Frame the conversation around outcomes that matter to the team, not around the transformation program itself.

It is also worth acknowledging that not every team member will be equally interested in learning new practices immediately. Creating space for people to move at different speeds — while still moving forward — is more sustainable than an all-or-nothing rollout. Atlassian, for example, publicly documents team health check and alignment techniques (referred to as the Team Playbook) as one way to surface where a team actually is before prescribing where they need to go.

Lesson 2: Learn DevOps by Practicing It, Not Studying It

Workshops, certifications, and reading lists have their place, but they are not sufficient to change how engineers work. Mindset shifts follow behavioral change — not the other way around. Teams that practice DevOps, make mistakes in a safe environment, and iterate on what they learn build lasting habits. Teams that attend a two-day class and return to the same workflow do not.

One approach described in the source material comes from a large telecommunications company: structured programs where teams applied DevOps practices to their own real work through a guided series of sprints on a compressed timescale. The goal was to give teams direct experience of working differently — faster feedback loops, automated testing, cross-functional collaboration — so they could internalize what the change actually feels like before scaling it.

Practical elements worth including in such programs:

• Running a small feature through a full CI/CD pipeline the team builds themselves
• Conducting a blameless post-incident review on a recent real incident
• Pairing developers with on-call engineers for a rotation
• Measuring and discussing deployment frequency and lead time before and after

Lesson 3: Treat DevOps Adoption as a Journey, Not a Destination

Teams that aim for full DevOps maturity in a single leap almost always get lost or burned out. DevOps adoption is iterative — much like the software development practices it promotes.

Providing teams with a clear, graduated maturity model helps in several ways. It allows teams to accurately assess where they are today, set a realistic next milestone rather than aiming for the theoretical end state, and measure progress over time. It also reduces the anxiety that comes from being compared to a high-performing team that has had years to develop its practices.

The source material references a Fortune 100 insurance company that distributed a practical guide to help teams self-assess, plan incremental improvements, and choose from a curated set of supported tools. Whether you use a formal maturity model, a lightweight checklist, or a tool like the DORA Four Key Metrics (deployment frequency, lead time for changes, mean time to restore, change failure rate) as benchmarks, the principle is the same: give teams a map before you ask them to navigate.

Lesson 4: Build a Common Collaboration Layer Across Teams

Cultural change and tooling are not separate concerns — they reinforce each other. As DevOps practices spread across an organization, a shared toolchain and common collaboration layer become strategically valuable.

Individual teams working on mobile apps, web services, and back-end systems will have unique pipeline requirements. But nearly all of them share the same fundamental activities: planning work, tracking issues, reviewing code, running tests, deploying software, and monitoring in production. Standardizing on a common platform for these activities — even if specialized tools differ at the edges — delivers compounding benefits:

• Onboarding speed: New teams and new engineers can start contributing faster when the baseline tooling is familiar.
• Engineer mobility: Moving people between teams is less disruptive when workflows and tooling are consistent.
• Cross-functional visibility: Security, compliance, portfolio management, and operations teams can interface with fewer systems and use shared language, reducing coordination overhead.
• Economies of scale: Licensing, support, and integration costs fall when the tool sprawl is managed centrally.

The success patterns from one high-performing team become transferable when the infrastructure that enabled them is available to others. At that point, DevOps stops being the property of a single team and starts being an organizational capability.

Putting It Together: From Isolated Wins to Organizational Capability

The four lessons above share a common thread: sustainable DevOps transformation is grown, not installed. It requires respecting team autonomy, creating genuine practice opportunities, setting realistic milestones, and building shared infrastructure that makes good practices the path of least resistance.

When this works, the effect is cumulative. Engineering teams ship faster and more reliably. Other business functions — product, security, compliance — gain visibility and confidence. The feedback loop between engineering and business outcomes shortens. That is when the core promise of DevOps — not just faster deploys, but better organizational alignment around software delivery — becomes tangible.

The hardest part is not understanding what DevOps success looks like. The hardest part is being patient and deliberate enough to build it in a way that lasts.

The Four Stages of DevOps Maturity

This model has many parallels to how I see large organizations embracing DevOps over the course of last several years. The following stages are not based on scientific analysis or modeling, but rather on how I have seen organizations mature as they progress through the learning curve.

Stage 1 – DevOps Denial and Misinterpretation

At the Unconscious Incompetence stage, the lack of understanding of what DevOps is and what its business benefits are causes organizations to deny the usefulness of DevOps and write it off as a kind of fad or bad marketing term. Some call this resistance to change, but it’s really a lack of understanding of the core value proposition. The same people who complain about painful deployments, excessive on-call support issues, constant firefighting and poor work-life balance defend this way of life over the DevOps way, because they simply don’t understand what DevOps is and how it will improve their current state.

They think of DevOps as operators having to learn how to code, or developers eliminating operation jobs, so they fight it with all their might. In reality, DevOps came about from operators partnering with developers to improve the deployments, stability, reliability and their quality of life.

Kishore Jalleda, Sr. Director of Production Engineering at Yahoo describes DevOps best in this slide.

Kishore Jalleda

Figure 2: A Definition of DevOps

At stage one, this message is lost, and organizations proceed with a “business as usual” attitude, waiting for this shiny object to pass in the night like many buzzwords before. The age-old silo operating model lives on.

Figure 3: Anti-pattern – Dev and Ops Silos

Stage 2 – Automation for the Sake of Automation

The Conscious Incompetence stage is usually present in the first 12 to 18 months of an organization’s DevOps journey. Many organizations grab onto the automation aspects of DevOps and start madly writing Chef scripts to automate everything and anything. Although some value is derived from these efforts (automated builds, automated infrastructure), much of this work is still being performed in silos, with limited to no improvement in collaboration between groups. Three common anti-patterns are implemented in stage 2.

Anti-pattern 1 – The DevOps Silo

http://web.devopstopologies.com/

Figure 4: Anti-pattern – DevOps Silo

What is the best way to fix your silo problem? Create a new silo called DevOps, and hire a bunch of DevOps Engineers (see my No you are not a DevOps Engineer rant). Welcome to your new bottleneck. In this model, a new element of separation is inserted between Dev and Ops and a “build it and they will come” mindset leads to more shadow IT as the Dev’s needs continue to go unmet.

Anti-pattern 2 – Dev Don’t Need No Stinkin’ Ops

http://web.devopstopologies.com/

Figure 5: Anti-pattern – Dev/No Ops

In this model, development teams script away the ops team and provision all of their own infrastructure as code. After all, infrastructure provisioning is their biggest bottleneck. The downside to this approach is that Devs are not experts at networking, security, compliance, support and many other capabilities that have been provided for them by various shared service groups. So although the Dev groups can now move much faster, they drastically increase risks for their company that can have catastrophic consequences.

Anti-pattern 3 – Rebranding Sysadmins as DevOps Engineers

http://web.devopstopologies.com/

Figure 6: Anti-pattern – DevOps Engineers

In this model, nothing really changes other than the sysadmins’ titles and resumes. All of the bottlenecks that keep work from flowing left to right remain, but some really cool scripts get built. Often, too many scripts are built, and now Ops is buried in script hell trying to manage thousands of lines of scripts, sometimes not checked into a repository. This “build it and they will come” approach often either backfires or just creates new bottlenecks. The Ops team often sees efficiency in their day-to-day tasks, but at the expense of newly wasted time in the Dev’s day-to-day tasks.

This may all sound like doom and gloom, but you have to start somewhere. A lot of learning occurs in this stage. Both Dev and Ops get familiar with the tooling and start to have a better understanding of each other’s needs. Some processes are improved, but usually those improvements are departmental and not system-wide.

Stage 3 – Collaboration and Reorganization

The Conscious Competence stage usually exists from years two to four. At this stage, the organization understands that DevOps is more than engineers and scripts, and is all about improving the entire software development lifecycle (SDLC), from business idea inception to business idea running in production.

By the time a company has entered stage 3, they have had pockets of success from grassroots efforts within the company. (Note: sometimes success is driven top-down, but more often than not a grassroots effort starts the journey.) Certain products or services within the portfolio have seen massive benefits from early DevOps efforts, and management has taken notice. Now the organization is open to doing the really hard stuff–people and process change.

At stage 3, collaboration expands beyond Dev and Ops to security, legal, compliance, audit and all those other bottleneck areas for Dev. In fact, the pattern we see from stage 3 to 4 is the shifting left of bottlenecks. First it was infrastructure. Then QA (automated testing in the pipeline). Then security (security scans in the pipeline, security and controls baked into the infrastructure, etc.).

In stage 3 we see the birth of platforms. Whether companies are using public or private cloud, or no clouds at all, platform teams build a layer of enterprise guard rails on top of the infrastructure layer, and provide self-service capabilities for the Dev teams. These platforms take the requirements from GRC (governance, risk, compliance), security, etc., and provide APIs and abstractions so that the Dev teams can inherit these controls and policies as they consume the platform services. This operating model often looks like this:

http://web.devopstopologies.com/

Figure 8: Platform as a Service (PaaS) Operating Model

In this model the Ops team is responsible for providing and operating the platform, and the developers are responsible for operating their applications, which are built on top of the enterprise guard rails. In stage 3 we finally get to “you build it, you run it.”

As organizations mature through Stage 3, we see improved collaboration across departments, and value stream mapping exercises being performed to aid in process improvement activities. A learning organization begins to emerge, and activities like blameless post mortems, gameday exercises, adoption of lean concepts, and others take root.

Stage 4 – A High Performing Organization

At the Unconscious Competence stage, organizations have the ability to deploy multiple times a day with certainty and minimal risk. Removing bottlenecks becomes a way of life. What I saw over and over at DOES17 were large organizations shifting everything left. In stage 3 we saw QA and security shifting left. In stage 4 we see Ops, GRC, and even tier 1 through tier 3 support shifting to the business units (BUs).

Each BU becomes a self-sufficient organization with full stack teams (squads) made up of experts across all the necessary technology and process domains. The classic security, Ops and GRC teams still exist, but their role is to establish policy and standards, not implement them. The BUs implement them in the way that’s optimal for their products or services.

Summary

DevOps is real, and is not a fad or another fancy buzzword. As companies move through the stages of learning, each stage provides more business value to the company. The speed at which business moves is increasing exponentially, and the companies that can deploy at the prevailing speed of business will win. As we look at the technologies that are driving the future–such as AI, machine learning, block chain and IoT–the companies that have entered Stage 4 maturity will be able to bring solutions using these technologies faster than their competition, creating even more separation in marketplace. My advice is to either embrace DevOps and start transforming your organization, or go out of business.

I attended my first DevOps Enterprise Summit (DOES17) in San Francisco this week and watched speakers from large enterprises like Capital One, Disney, Nike, CSG, and more share the lessons learned from their multiyear DevOps transformations. Most of these companies have been working on their transformations from three to five or more years, and have reached a level of maturity where the business value of DevOps is very easy to see and measure.

Like any new technology, methodology, process or paradigm shift, DevOps transformations go through various stages of maturity. Two years ago I wrote a post called The Four Stages of Cloud Competence and referenced Noel Burch’s four stages of learning to describe how enterprises were adopting (or not adopting) cloud computing.

cloudtp.com

Figure 1: Burch’s Learning Model – Four Stages of Competence

1. Unconscious Incompetence

Individuals do  not understand or know how to do something and do not necessarily recognize the deficit. They may even deny the usefulness of the skill. Before moving on to the next stage, individuals must recognize their own incompetence, and the value of the new skill. The length of time individuals spend in this stage depends on the strength of their stimulus to learn.

2. Conscious Incompetence

Though individuals do not understand or know how to do something, they do recognize the deficit, as well as the value of a new skill in addressing the deficit. At this stage, making mistakes can be integral to the learning process.

3. Conscious Competence

Individuals understand or know how to do something. However, demonstrating the skill or knowledge requires concentration. It may be broken down into steps, and there is heavy conscious involvement in executing the new skill.

4. Unconscious Competence

Individuals have had so much practice with a skill that it becomes second nature and can be easily done. As a result, the skill can be performed while executing another task. Individuals may be able to teach it to others, depending upon how and when it was learned.

The Four Stages of DevOps Maturity

This model has many parallels to how I see large organizations embracing DevOps over the course of last several years. The following stages are not based on scientific analysis or modeling, but rather on how I have seen organizations mature as they progress through the learning curve.

Stage 1 – DevOps Denial and Misinterpretation

At the Unconscious Incompetence stage, the lack of understanding of what DevOps is and what its business benefits are causes organizations to deny the usefulness of DevOps and write it off as a kind of fad or bad marketing term. Some call this resistance to change, but it’s really a lack of understanding of the core value proposition. The same people who complain about painful deployments, excessive on-call support issues, constant firefighting and poor work-life balance defend this way of life over the DevOps way, because they simply don’t understand what DevOps is and how it will improve their current state.

They think of DevOps as operators having to learn how to code, or developers eliminating operation jobs, so they fight it with all their might. In reality, DevOps came about from operators partnering with developers to improve the deployments, stability, reliability and their quality of life.

Kishore Jalleda, Sr. Director of Production Engineering at Yahoo describes DevOps best in this slide.

Kishore Jalleda

Figure 2: A Definition of DevOps

At stage one, this message is lost, and organizations proceed with a “business as usual” attitude, waiting for this shiny object to pass in the night like many buzzwords before. The age-old silo operating model lives on.

Figure 3: Anti-pattern – Dev and Ops Silos

Stage 2 – Automation for the Sake of Automation

The Conscious Incompetence stage is usually present in the first 12 to 18 months of an organization’s DevOps journey. Many organizations grab onto the automation aspects of DevOps and start madly writing Chef scripts to automate everything and anything. Although some value is derived from these efforts (automated builds, automated infrastructure), much of this work is still being performed in silos, with limited to no improvement in collaboration between groups. Three common anti-patterns are implemented in stage 2.

Anti-pattern 1 – The DevOps Silo

http://web.devopstopologies.com/

Figure 4: Anti-pattern – DevOps Silo

What is the best way to fix your silo problem? Create a new silo called DevOps, and hire a bunch of DevOps Engineers (see my No you are not a DevOps Engineer rant). Welcome to your new bottleneck. In this model, a new element of separation is inserted between Dev and Ops and a “build it and they will come” mindset leads to more shadow IT as the Dev’s needs continue to go unmet.

Anti-pattern 2 – Dev Don’t Need No Stinkin’ Ops

http://web.devopstopologies.com/

Figure 5: Anti-pattern – Dev/No Ops

In this model, development teams script away the ops team and provision all of their own infrastructure as code. After all, infrastructure provisioning is their biggest bottleneck. The downside to this approach is that Devs are not experts at networking, security, compliance, support and many other capabilities that have been provided for them by various shared service groups. So although the Dev groups can now move much faster, they drastically increase risks for their company that can have catastrophic consequences.

Anti-pattern 3 – Rebranding Sysadmins as DevOps Engineers

http://web.devopstopologies.com/

Figure 6: Anti-pattern – DevOps Engineers

In this model, nothing really changes other than the sysadmins’ titles and resumes. All of the bottlenecks that keep work from flowing left to right remain, but some really cool scripts get built. Often, too many scripts are built, and now Ops is buried in script hell trying to manage thousands of lines of scripts, sometimes not checked into a repository. This “build it and they will come” approach often either backfires or just creates new bottlenecks. The Ops team often sees efficiency in their day-to-day tasks, but at the expense of newly wasted time in the Dev’s day-to-day tasks.

This may all sound like doom and gloom, but you have to start somewhere. A lot of learning occurs in this stage. Both Dev and Ops get familiar with the tooling and start to have a better understanding of each other’s needs. Some processes are improved, but usually those improvements are departmental and not system-wide.

Stage 3 – Collaboration and Reorganization

The Conscious Competence stage usually exists from years two to four. At this stage, the organization understands that DevOps is more than engineers and scripts, and is all about improving the entire software development lifecycle (SDLC), from business idea inception to business idea running in production.

Gene Kim

Figure 7- Gene Kim’s Definition of DevOps

By the time a company has entered stage 3, they have had pockets of success from grassroots efforts within the company. (Note: sometimes success is driven top-down, but more often than not a grassroots effort starts the journey.) Certain products or services within the portfolio have seen massive benefits from early DevOps efforts, and management has taken notice. Now the organization is open to doing the really hard stuff–people and process change.

At stage 3, collaboration expands beyond Dev and Ops to security, legal, compliance, audit and all those other bottleneck areas for Dev. In fact, the pattern we see from stage 3 to 4 is the shifting left of bottlenecks. First it was infrastructure. Then QA (automated testing in the pipeline). Then security (security scans in the pipeline, security and controls baked into the infrastructure, etc.).

In stage 3 we see the birth of platforms. Whether companies are using public or private cloud, or no clouds at all, platform teams build a layer of enterprise guard rails on top of the infrastructure layer, and provide self-service capabilities for the Dev teams. These platforms take the requirements from GRC (governance, risk, compliance), security, etc., and provide APIs and abstractions so that the Dev teams can inherit these controls and policies as they consume the platform services. This operating model often looks like this:

http://web.devopstopologies.com/

Figure 8: Platform as a Service (PaaS) Operating Model

In this model the Ops team is responsible for providing and operating the platform, and the developers are responsible for operating their applications, which are built on top of the enterprise guard rails. In stage 3 we finally get to “you build it, you run it.”

As organizations mature through Stage 3, we see improved collaboration across departments, and value stream mapping exercises being performed to aid in process improvement activities. A learning organization begins to emerge, and activities like blameless post mortems, gameday exercises, adoption of lean concepts, and others take root.

Stage 4 – A High Performing Organization

At the Unconscious Competence stage, organizations have the ability to deploy multiple times a day with certainty and minimal risk. Removing bottlenecks becomes a way of life. What I saw over and over at DOES17 were large organizations shifting everything left. In stage 3 we saw QA and security shifting left. In stage 4 we see Ops, GRC, and even tier 1 through tier 3 support shifting to the business units (BUs).

Each BU becomes a self-sufficient organization with full stack teams (squads) made up of experts across all the necessary technology and process domains. The classic security, Ops and GRC teams still exist, but their role is to establish policy and standards, not implement them. The BUs implement them in the way that’s optimal for their products or services.

This was best explained by CSG International’s Scott Prugh and Erica Morrison as they compared their old way of thinking to their new way of thinking.

After CSG removed infrastructure as their biggest bottleneck, they went after the next biggest bottleneck, which was organizational structures. The slide below shows how they adopted the T-Shaped management model, where one person owns both the development and operations of the product within the BU.

This transformation took a while to perfect. Once things were operating smoothly, they moved on to the next biggest bottleneck: process. The next slide shows how they moved the responsibility of implementing and monitoring security and GRC to the BUs within the T-shaped teams.

The next bottleneck on their list is tier 1 through tier 3 support. I am looking forward to hearing their presentation next year, and learning about their experiences shifting that process left to the BUs.

Capital One now has over 300 products that are being deployed up to 50 times a day, up from 20 products last year. Yes, you heard that right. A financial institution running on the public cloud (AWS) is changing compliant software multiple times a day across 300 product lines. If they were my competition, I would be shaking in my boots. Many financial institutions require 50 meetings to deploy 1 piece of code. These folks are deploying tens of thousands of times a day across their portfolio. And this is not Facebook, Twitter or Amazon. This is a bank!

If you haven’t figured it out yet, companies like Capital One, who are in Stage 4 of DevOps maturity are also advanced in their digital transformation, because of the velocity with which the can deploy software. For example, Capital One introduced banking via Alexa in 2016, shortly after Alexa became available as a viable production-quality device. Most companies had not even considered what a device like Alexa could do for their customers when Capital One had already deployed it.

Companies like Nike and others gave us examples of how they responded to urgent business requests within a week, which they previously would not have been able to deliver on because of the limitations of their legacy operating model.

Summary

DevOps is real, and is not a fad or another fancy buzzword. As companies move through the stages of learning, each stage provides more business value to the company. The speed at which business moves is increasing exponentially, and the companies that can deploy at the prevailing speed of business will win. As we look at the technologies that are driving the future–such as AI, machine learning, block chain and IoT–the companies that have entered Stage 4 maturity will be able to bring solutions using these technologies faster than their competition, creating even more separation in marketplace. My advice is to either embrace DevOps and start transforming your organization, or go out of business.

What Is DevOps in the Cloud?

Both DevOps and cloud computing are widely cited as essential to maintaining competitiveness and pursuing digital transformation. While DevOps focuses on improving collaboration, processes, and software delivery pipelines, cloud computing provides the underlying on-demand infrastructure and services those pipelines run on. Combining the two creates an environment where development and operations teams can move faster, experiment more freely, and deliver higher-quality software.

How Cloud DevOps Differs from On-Premises DevOps

On-premises DevOps is constrained by physical boundaries: fixed compute capacity, shared infrastructure, and a narrower choice of technologies. Cloud-based DevOps removes many of those constraints.

Mark Debney, head of DevOps at tech consultancy 6point6, explains it this way: “It also allows us to expand our view wider than just the servers or load balancers. In a cloud-based environment we can view our complete stack from top-level network elements down to a single package installed on a server as a discrete entity, all of which we can create, destroy, copy and modify with a simple click.”

Cloud-native DevOps also accelerates two foundational DevOps ideals:

• Everything as Code (EaC): Infrastructure, configuration, policies, and pipelines are all defined in version-controlled code files, making them reproducible and auditable.
• Immutable Infrastructure: Rather than patching running servers, new deployments replace old ones entirely, reducing configuration drift and increasing consistency.

Cloud platforms also connect teams to a broader ecosystem. As Debney notes: “We can leverage tools and ideas within the wider cloud community. We are no longer tied to our own internal set of infrastructure technology with its own unique quirks.”

Key Benefits of Combining DevOps and Cloud

Programmable, API-Driven Infrastructure

Public cloud platforms expose their capabilities through well-documented APIs. Tim Hynes, DevOps engineer at Rubrik, points out that this makes cloud a naturally programmable environment: “This enables us to take a modern, scalable approach to building applications and provides levels of flexibility and opportunity that are not available in traditional environments.” Because APIs are universally available across cloud services, automation becomes straightforward where it would otherwise require custom integration work.

Lower Capital Expenditure on Tooling

Richard Slater, principal consultant at Amido, argues that the financial model of cloud directly reduces one of the biggest barriers to DevOps adoption: upfront tooling costs.

“You need to invest in DevOps upfront to see a medium-to-long-term result… By adopting DevOps in the cloud, you can reduce the capital expenditure on DevOps tools by simply renting SaaS tools from the market – for example Datadog, Splunk, AppDynamics, New Relic, JIRA, Bamboo and CircleCI.”

Subscribing to SaaS-based tooling also shifts maintenance and upgrades to vendors, freeing engineering teams to focus on delivery rather than tool management.

Greater Flexibility and Scale

Cloud elasticity means teams can rapidly scale existing components for load testing, spin up parallel environments for feature branches, and tear down resources when they are no longer needed. This opens the door to testing and release strategies — such as blue/green deployments, canary releases, and chaos engineering — that are difficult or expensive to replicate on fixed on-premises hardware.

Making Cloud DevOps Adoption Succeed

Build Trust with Development Teams

Slater identifies a lack of organisational trust as one of the primary reasons agile and DevOps transformations fail: “Organisations wanting to adopt Agile, Cloud and DevOps must start to give trust to the individuals making decisions and writing code on the ground. To a certain extent this trust must be earned, but in many of today’s enterprises there is so much governance around technical delivery that it has the effect of slamming the brakes on any transformation.”

This does not mean abandoning governance entirely, but rather distinguishing between controls that genuinely reduce risk and bureaucratic processes that slow delivery without adding value.

Scale Adoption Gradually — No More Than 3x at a Time

Slater recommends a deliberate, incremental approach to expanding cloud DevOps across the organisation: “If you started with one project, next try another three projects, then nine and so on. Aim for the projects that deliver the most business value in the shortest time. Once you have ten projects under your belt, start looking at tackling some of the harder problems — these will be a lot easier now you have a critical mass of products, vendor agreements, suppliers, processes and people behind you.”

Scaling by a maximum factor of three at each step gives teams time to consolidate learnings before the next wave of expansion, reducing the risk of organisational overload.

Cloud DevOps Best Practices

1. End-to-End Traceability

Iskandar Najmuddin, specialist architect at Rackspace, identifies end-to-end traceability as a foundational DevOps practice for cloud environments. Traceability means being able to follow any change — from the initial commit that triggered it to the running workload it produced — so that bugs, incidents, and vulnerabilities can be investigated quickly.

“No one tool can solve this – as you build a pipeline of changes, the key is to ensure that the business injects metadata into it to help trace the steps.”

In practice, this means propagating a correlation ID or build reference through every stage of your CI/CD pipeline — from source control, through build artefacts, container images, deployment manifests, and into runtime logs and monitoring dashboards.

2. Shift Left on Testing and Security

Najmuddin describes Shift Left as the practice of finding and fixing defects, vulnerabilities, and misconfigurations as early in the development lifecycle as possible, rather than discovering them in production where remediation is most costly.

“Development is done on the left hand, and production is on the right. Businesses must identify and fix the problems on the left before they transition toward the right. This affects how businesses plan, design, write and apply code, as well as how they introduce any changes into the environment.”

Practically, Shift Left involves integrating automated unit tests, static code analysis, dependency vulnerability scanning, and infrastructure-as-code linting directly into pull request checks and build pipelines — so problems surface within minutes rather than weeks.

3. Keep Applications Small and Independently Deployable

Sasan Padidar, director of engineering and container security at Tenable, advocates for decomposing applications into small, independently deployable components: “Independent components of the application can be scaled separately. It also means that pieces of an application can be deployed faster because of the reduced complexity of the overall application.”

Padidar also recommends packaging all dependencies with each application at build time: “This means that applications are immutable units that can be deployed anywhere.” Container images are the dominant mechanism for achieving this today, but the principle applies equally to other packaging formats such as virtual machine images or self-contained binaries.

The Road Ahead: Containers, Orchestration, and Evolving Roles

Najmuddin anticipated growing adoption of containers alongside a consolidation of the container orchestration landscape — a prediction that has largely played out, with Kubernetes becoming the dominant platform across public cloud providers.

He also predicted that the “DevOps engineer” as a distinct job title would evolve: “The idea that DevOps is a distinct job or role in an organisation will also start to tail off. DevOps will become the default way to manage cloud environments, and the job titles will evolve to reflect this.”

Roles such as Site Reliability Engineer (SRE), Platform Engineer, and Cloud Engineer have emerged as common titles that embed DevOps principles without labelling them as such — consistent with this direction of travel.

Summary