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.

DevOps vs. Waterfall: Understanding the Gap

Waterfall software development was first described in 1956 and remains in active use today, largely because of the volume of legacy software that IT departments continue to support. The methodology earns its name from the way work flows in a single direction — downward through discrete phases: requirements, design, programming, testing, and implementation. Each phase completes before the next begins.

DevOps takes a fundamentally different approach. Rather than moving through sequential phases, DevOps collapses development, operations, and quality assurance into a continuous, iterative loop. Teams can work across multiple concerns simultaneously, enabling much faster time-to-market for software changes and new features.

Despite this promise, DevOps adoption is not straightforward. Many organizations struggle to fully transition because they attempt to apply DevOps tooling without making the deeper cultural and organizational changes the methodology requires. DevOps also demands continuous testing — something that becomes more challenging the faster code changes are shipped.

Why DevOps Adoptions Fail

Two of the most common reasons DevOps implementations fall short are organizational resistance and inadequate testing practices.

• Organizational structure: Traditional IT departments organized around silos — development, operations, infrastructure, networks, database administration, and QA — are poorly suited to DevOps. When teams remain isolated, the collaboration that DevOps depends on simply doesn’t happen.
• Inadequate testing: DevOps requires continuous testing because code is continuously changing. Developers across all methodologies tend to deprioritize testing under deadline pressure, but in a fast-moving DevOps environment, skipping or shortcutting tests creates compounding risk with every release cycle.

The following five strategies address these failure modes directly and can help your organization keep pace with DevOps without sacrificing the quality standards that made structured methodologies like Waterfall so durable.

1. Focus on Time-to-Market Automation

DevOps is built around speed. If your team is expected to develop, test, and deploy applications in near-continuous cycles, manual processes will quickly become bottlenecks. Automation is not optional — it is the foundation that makes DevOps velocity possible.

Several categories of automation tooling are directly relevant here:

• Rapid prototyping tools allow developers to build and iterate on application interfaces quickly, enabling early user feedback before heavy investment in backend logic.
• Environment provisioning tools automate the creation of virtual operating system instances for testing, ensuring that tests run against consistent, reproducible environments.
• Cross-device and cross-platform test automation tools validate application behavior across a wide range of devices and form factors, replicating the conditions real end users will encounter.

“What we want to replicate is what end users do. With automation, we can test 60% to 90% of applications, although there are still manual parts of business operations that can’t be tested by automation.”

Shoeb Jared, CTO, Worksoft

The goal of automation in a DevOps context is not to replace human judgment but to handle repetitive, high-volume testing tasks so that engineers can focus their attention on complex scenarios that genuinely require manual review.

2. Get the Right DevOps Teams in Place

Team structure is arguably the most critical success factor in DevOps adoption. DevOps does not function well when IT remains organized into traditional departmental silos. Because development, operations, infrastructure, networking, database management, and QA activities all occur concurrently in a DevOps workflow, the team responsible for a given application must include people with all of these competencies.

Importantly, this interdisciplinary team should also include representatives from the end-user community. End users bring domain knowledge and real-world usage patterns that purely technical team members often lack.

Beyond structure, the people you recruit into DevOps roles matter. Effective DevOps team members tend to be:

• Comfortable working across functional boundaries
• Collaborative and communicative by default
• Willing to take shared ownership of outcomes, not just individual tasks

If your team retains traditional departmental boundaries — even informally — you are likely to encounter the same coordination friction that causes many DevOps initiatives to stall.

3. Demand Quality Testing

Resistance to thorough testing is not unique to DevOps — it is a persistent challenge across all software development methodologies. Developers focused on delivering features often view QA processes as obstacles, particularly when deadlines loom. In a Waterfall context, this tension is managed by placing testing as a distinct phase with its own timeline. In DevOps, where testing must happen continuously, the discipline required is significantly greater.

Modern DevOps testing tools support automated validation across a broad range of test types:

• Field-level input validation
• UI and ergonomic testing
• Database and system routine access testing
• Stress and load testing
• Integration testing across services
• Multi-device compatibility testing

However, automation cannot cover every scenario. Complex middleware interactions and intricate database access patterns often require manual testing by experienced engineers. The DevOps team lead must determine the appropriate mix of automated and manual testing for each application, and enforce that standard consistently across release cycles.

4. Insist on Documentation

Documentation is the other discipline that developers routinely resist, and it is another area where DevOps environments are particularly vulnerable. The speed of continuous delivery makes it easy to defer documentation indefinitely — until a maintenance issue surfaces that nobody can diagnose because the original intent of the code was never recorded.

Automation tools can help here too. Log capture tools and alerting systems can be combined with test scripts to produce baseline documentation artifacts. But automated tools rarely produce the high-level narrative documentation that describes an application’s overall purpose, its key workflows, and its integration dependencies. That kind of documentation is essential when a maintenance engineer — who may not have been involved in the original build — needs to understand the system well enough to fix or extend it.

The same “black box” problem that plagues legacy Waterfall applications — undocumented logic that only the original author understood — appears just as readily in DevOps environments when documentation is treated as an afterthought. Establishing documentation standards and enforcing them as part of the definition of done is essential.

5. Use DevOps for Internal Applications Before Customer-Facing Systems

DevOps is, by design, a fluid and experimental approach to software development. Applications evolve rapidly, interfaces change frequently, and the continuous cycle of updates can introduce instability even with good testing practices in place.

For this reason, it is prudent to begin DevOps adoption with internal-facing applications rather than customer-facing systems. Internal users are more tolerant of change and disruption, and issues that arise can be addressed without the reputational and commercial consequences of a degraded customer experience.

Once your team has established reliable DevOps practices — stable pipelines, consistent test coverage, predictable release cadences — expanding to customer-facing applications becomes a more manageable risk. Starting with internal tools gives teams the space to mature their processes before the stakes are highest.

Summary

DevOps offers real advantages over sequential methodologies: faster delivery, tighter feedback loops, and greater responsiveness to changing requirements. But realizing those advantages requires deliberate investment in automation, team structure, testing discipline, documentation, and a thoughtful rollout strategy. The organizations that succeed with DevOps are those that treat it as a cultural and organizational transformation — not simply a tooling upgrade.

• Automate aggressively to support continuous delivery velocity.
• Build genuinely interdisciplinary teams that span development, operations, and end-user representation.
• Enforce continuous testing standards — automated where possible, manual where necessary.
• Treat documentation as a required output, not an optional extra.
• Start DevOps adoption on internal applications before expanding to customer-facing systems.

The Reality of Legacy in Most Organisations

Unless you are working in a greenfield startup, your organisation almost certainly runs legacy systems that represent significant capital investment and underpin core business processes. Transforming those systems carries substantial risk and cost — and the appetite to do so is rarely strong enough to justify the disruption.

Modern cloud-native applications built with containerised microservices are not a natural fit with legacy systems developed using older, inflexible technologies and hosted in on-premises environments. But bridging that gap is exactly what most development teams are asked to do.

High-scale technology companies such as Google, Amazon, and eBay continuously re-engineer their entire processing pipeline and invest heavily in keeping their systems current. However, most organisations operate at a very different scale and with a fraction of those budgets. The lessons from those engineering giants are worth studying, but they are solving a different problem. Not every organisation needs — or can afford — the same approach.

A common pattern that has emerged is for organisations to adopt DevOps selectively: applying it to customer-facing services where speed and agility deliver the most immediate business value, while leaving back-office and core processing systems largely untouched. The customer-facing DevOps layer can respond quickly to new promotions, competitive pricing changes, or product launches. But it will almost always need to call into those legacy systems to complete a transaction.

Greenfield vs. Brownfield Development

In software development, a greenfield project is one with no existing constraints — you design and build from scratch. A brownfield project, by contrast, requires you to build around or on top of what already exists. The term is borrowed from urban development, where new construction often takes place on land previously used for industry.

Most DevOps transformations take place in a brownfield context. Legacy components impose data definitions, business rules, and integration contracts on any new development. If a system is too risky or expensive to replace, it is typically the system that defines how the business actually holds and processes its most important data. Failing to understand that reality early leads to a painful integration phase later.

Adopting a Hybrid Approach

When one or more DevOps squads are tasked with delivering a service where a significant portion of the functionality is provided by existing legacy components, the first priority is to understand the constraints those legacy components impose.

This is harder than it sounds. Legacy systems are often retained precisely because nobody fully understands them. Knowledge is concentrated in a small, experienced support team. Documentation is typically incomplete, outdated, or both. Do not assume otherwise.

A realistic hybrid approach acknowledges these constraints and builds process around them. The following sections outline the key areas to address.

Produce an End-to-End Architecture

Before writing significant new code, map the integration points between the components your team controls and the legacy components you do not. Treat those integration points as third-party APIs — but with considerably more complexity than a typical external API. These are the systems the organisation was too afraid to touch. They will require deeper investigation and more careful handling.

A practical example illustrates the risk well. Suppose a registration process requires a date field. Your new service applies a straightforward business rule to that field. But what if the legacy system has been silently accepting a default placeholder date for years — because a contact centre team found it easier to enter a fixed value to avoid an obscure validation error? When your new service enforces the rule properly for the first time, you may discover thousands of existing customer records that do not conform to the rule you thought was already being applied. The integration breaks on day one for a large percentage of real users.

This kind of hidden behaviour is common in legacy systems. Exploratory testing on the legacy components — combined with working closely with the support teams who know them — is essential to surface these issues before they reach production.

Document the End-to-End Journey

Agile rightly emphasises collaboration over documentation, but the complexity of legacy integration demands that constraints are captured clearly and shared across all development squads. If a behaviour is a constraint imposed by the legacy system, it is not negotiable — it must be understood and designed around.

Consider a short architectural sprint at the start of the programme to investigate legacy behaviour, document integration contracts, and identify risks. This upfront investment reduces surprises during development and testing. Any constraint discovered and documented early is far cheaper to manage than one found during user acceptance testing or, worse, in live service.

Once the behaviours and constraints of the legacy components are understood, that knowledge should be shared explicitly with all squads contributing to the service — not assumed to be common knowledge.

Account for Data Latency Across the Service

Many legacy systems use batch processing strategies to optimise performance: updates are queued during the day and processed during overnight batch windows. This creates data latency that can be invisible to a newly developed service designed around real-time interactions.

Consider a scenario where a customer completes an application through a mobile application. The new service confirms success immediately to the customer. But the actual provisioning of that service on the legacy back end is dependent on an overnight batch job. If the batch fails or is delayed, the customer experience and the downstream state diverge. This latency must be accounted for explicitly in service design, in the user experience, and in the testing strategy.

Overnight batch cycles also place hard constraints on end-to-end automated testing. Tests that depend on legacy state changes may take hours to complete a single cycle, making them impractical for continuous integration pipelines.

Testing, Automation, and Continuous Testing in a Hybrid Environment

Testing an end-to-end service composed of modern microservices and legacy components is one of the most technically demanding aspects of this type of programme. The two halves of the service have fundamentally different testing characteristics.

The modern DevOps-developed components can typically be tested through automated unit, integration, and contract tests, and continuously validated within a CI/CD pipeline with relatively little friction.

Legacy components introduce constraints at multiple levels:

• Environments: Legacy test environments are typically shared across multiple development and support teams. Availability windows are limited and coordination is required.
• Test data: Data in legacy test environments is often difficult to set up, slow to refresh, and shared — meaning one team’s test can corrupt another team’s data state.
• Batch dependencies: As described above, state changes in legacy systems may only take effect after an overnight run, making rapid test iteration impossible for certain scenarios.
• Fragility: Legacy systems may have undocumented behaviours that cause intermittent test failures, generating false negatives that erode confidence in the test suite.

A risk-based testing strategy is necessary. Consider stubbing or virtualising the legacy component for the purposes of automated testing of the modern layer. This allows your CI/CD pipeline to continue functioning without a live dependency on a fragile shared environment. Dedicated end-to-end integration testing against the actual legacy system can then be scheduled less frequently, in a controlled manner, with acceptance that it will be slower and harder to maintain.

No approach will be perfect. The goal is to identify and agree on an honest, risk-based testing strategy that all stakeholders understand — rather than attempting to apply a continuous testing model uniformly across components that cannot support it.

Key Principles for DevOps and Legacy Integration

• Invest in discovery early. Run an architectural spike or discovery sprint before main development begins to understand legacy behaviour, data contracts, and constraints.
• Treat legacy systems as complex third-party APIs. Define the integration boundary clearly. Do not assume the legacy system will behave as the documentation (if any exists) suggests.
• Work directly with legacy support teams. Their domain knowledge is irreplaceable. Build a working relationship with them from the start of the programme.
• Use exploratory testing on legacy components. Automated tests cannot discover what you do not already know. Manual exploratory sessions on legacy systems surface hidden rules and behaviours.
• Design for latency. If the legacy system uses batch processing, the service design and the user experience must accommodate delays in state propagation.
• Document constraints explicitly. Constraints imposed by legacy systems are not up for discussion. Write them down and share them across all squads.
• Apply a risk-based testing strategy. Continuous end-to-end testing against live legacy environments is rarely achievable. Stub where you can, integrate where you must, and be explicit about what is and is not covered.

Conclusion

Building new DevOps-driven services that integrate with legacy components is a common, difficult, and often underestimated challenge. Each integration is unique — the constraints you will encounter depend on your specific legacy systems, your organisation’s risk tolerance, and the nature of the service being delivered.

The teams that handle this most effectively are those that invest in understanding the legacy estate before they begin building, document what they discover, share that knowledge across squads, and apply a realistic testing strategy that accounts for the fundamental differences between modern and legacy components. Doing the hard work upfront will not eliminate all the difficulties — but it will significantly reduce the number of surprises, and greatly improve the chances of a successful delivery.

DevOps Is Not a Silver Bullet — But It’s Not Hype Either

The term “DevOps” has been applied to so many tools, job titles, and organizational restructurings that its original intent is easy to lose. At its core, DevOps is a methodology that bridges the historically separate worlds of software development and IT operations. It promotes automation, continuous monitoring, and shared accountability to shorten delivery cycles without sacrificing stability.

That last part matters. DevOps is not a license to ship faster at any cost. Used correctly, it is a framework that helps teams catch problems early, reduce the blast radius of failures, and build feedback loops that improve quality over time. Used incorrectly — or adopted in name only — it can accelerate the pace at which problems reach production.

Understanding the Development Side of the Equation

Developers occupy a unique position in any organization. They are not simply typing code — they are designing systems that directly affect how a business operates and how customers experience it. Application development is a creative and technical discipline simultaneously, and the people who do it well are usually driven by an intrinsic desire to build and iterate.

In modern IT, the application layer has become the primary competitive surface. Infrastructure and operating systems are increasingly abstracted away by cloud platforms and containers. This shift places development teams at the center of business strategy in a way that was less true a decade ago — and it raises the stakes for every release.

Change Is the Developer’s Default — and That’s a Risk

Developers are change-oriented by nature. Their job is to modify, extend, and improve applications continuously. This is exactly what the business needs — right up until it isn’t.

Uncontrolled or poorly coordinated change is one of the leading causes of application instability. The failures that result — crashes, degraded performance, data integrity issues — are rarely intentional, but their impact on end users and business operations can be severe. Change, without governance, becomes a source of risk.

This is the tension that DevOps must resolve. Development teams need the autonomy and velocity to do their best work. Operations teams need the stability and predictability to keep services running reliably. DevOps methodology does not eliminate this tension — it creates structured ways to manage it.

The Mistake: Using DevOps Only to Go Faster

One of the most common misapplications of DevOps is using it primarily as justification for increasing release frequency without addressing the underlying quality and control practices that make frequent releases safe.

Development teams generally do not need to be encouraged to move faster — that motivation is usually already present. What they often need is help understanding the downstream consequences of that speed: how a breaking change in a shared service cascades into an operations incident, how an under-tested deployment at 4 PM on a Friday generates weekend outages, and how poor observability makes root-cause analysis slow and painful.

A mature DevOps implementation redirects the conversation from speed alone toward the harder topics: change control, release quality gates, automated testing coverage, rollback strategies, and on-call accountability shared between Dev and Ops.

Shared Ownership: The Core Principle

DevOps succeeds when development and operations teams stop treating each other as obstacles and start treating the full software delivery lifecycle as a shared responsibility. This requires more than goodwill — it requires structural changes to how teams are measured and rewarded.

Consider the incentive structures in many organizations:

• Development teams are rewarded for shipping features quickly.
• Operations teams are rewarded for maintaining uptime and stability.
• These goals are structurally in conflict, which produces organizational friction regardless of how many DevOps tools you deploy.

A DevOps-aligned organization redefines success metrics to reflect shared outcomes: deployment frequency, mean time to recovery (MTTR), change failure rate, and customer-facing availability. When Dev and Ops are measured against the same outcomes, they begin to collaborate rather than optimize against each other.

Practical Steps Toward Genuine DevOps Adoption

Organizational change of this kind does not happen by issuing a mandate. Leaders who announce a “DevOps transformation” and then return to business as usual will find teams reverting to old behaviors within months. Sustainable adoption requires ongoing reinforcement, visible management commitment, and honest reckoning with failure.

• Help developers understand operational impact. Give development teams visibility into how their releases affect infrastructure load, error rates, and customer experience. Dashboards shared across both teams create a common picture of reality.
• Establish lightweight change governance. Automated testing pipelines, peer code review, and deployment approval workflows are not bureaucratic obstacles — they are the guardrails that make frequent releases sustainable.
• Create shared on-call accountability. When developers are part of the on-call rotation for services they own, the incentive to write observable, resilient code increases significantly.
• Align incentives to shared outcomes. Review how teams are evaluated. Speed metrics without quality counterweights will always push toward instability.
• Treat failures as learning opportunities. Blameless post-mortems, documented and shared across teams, build psychological safety and improve systems over time.

Surviving the Valleys

Every DevOps journey will encounter setbacks. Deployments will fail. Teams will resist change. Old habits will reassert themselves under pressure. The organizations that realize the long-term benefits of DevOps are those that treat these moments as expected parts of the journey rather than evidence that the approach is broken.

Resilience — both technical and organizational — is the real output of a mature DevOps practice. The goal is not a team that never fails, but a team that detects failures fast, recovers quickly, learns systematically, and ships the next release with more confidence than the last.

That outcome is worth the difficulty of getting there.

Agile and DevOps: Complementary, Not Competing

A common misconception is that adopting DevOps means abandoning Agile. In practice, many high-performing teams use both together. Agile governs how software is developed—emphasising iterative delivery, responsiveness to change, and close collaboration within development teams. DevOps extends that philosophy to include the operations side of the house, closing the gap between writing code and running it reliably in production.

“Agile practices and DevOps are not mutually exclusive practices, and they are frequently used together to achieve continuous deployment of features to users. The key is using feature branching that is only merged in after a successful completion of comprehensive automated tests.”

David Lee, COO, Kastling Group

Marty Puranik, CEO of Atlantic.Net, frames the distinction clearly: Agile is primarily about producing software efficiently, often software that was historically packaged and sold. DevOps, by contrast, is about keeping that software running continuously in production—the SaaS operating model—which introduces its own set of ongoing responsibilities.

The Cultural Shift Is the Hard Part

Most practitioners who have lived through this transition will tell you that technology is the easy part. Culture is harder. Historically, development teams owned code up to the point of deployment, and operations teams owned everything after. DevOps asks both sides to share responsibility across the entire application lifecycle.

“Organizations that used to separate development and operations will now ask that the teams share the responsibility across the entire application process. Developers will be responsible not only for providing the code but also for following that code to completion. The same is true for operations.”

Lindsey Havens, Senior Marketing Manager, PhishLabs

Common values around ownership and accountability are central to a DevOps culture. Without them, tooling investments will deliver only marginal gains. Leadership needs to make the expectations explicit and support teams through the discomfort of changing deeply ingrained working habits.

Practical Steps for MSPs Moving from Agile to DevOps

1. Start Small and Iterate

The breadth of change involved in a DevOps adoption makes it tempting to plan a large, organisation-wide rollout. Resist that temptation. A pilot program with a small, dedicated team is far more likely to succeed and will generate the proof points needed to scale the approach across the wider organisation.

“For MSPs, a progressive IT motto should be: start small and iterate. DevOps comes with a fundamental shift in culture, process, skill sets and technologies. Using a small, core team to introduce the new working paradigm is essential. By focusing on delivering something of business value—small in scope and within the team’s control—it will empower the team to make decisions in real time.”

Jason McDonald, President, Contino

A solid, scalable IT architecture is foundational here. Starting small forces the team to focus on that foundation rather than trying to solve every problem at once. Once the foundation is in place, growth is organic and controlled.

2. Choose Tools That Support the Process—Not the Other Way Around

Both Agile and DevOps have rich tooling ecosystems, but experienced practitioners caution against letting tool selection drive process decisions. The tool should serve the process, not define it.

“A favourite tool of agile is the Kanban board, which is literally made of notecards and tape. But it accomplishes the goal of visualising work-in-progress—a key component of an efficient agile process.”

Ned Bellavance, Director of Cloud Solutions, Anexinet

For teams that do want a reference stack, tools commonly mentioned in DevOps contexts include:

• Issue and project tracking: Jira, Azure DevOps (formerly Visual Studio Team Services)
• Continuous integration: TeamCity, Jenkins, GitHub Actions
• Continuous delivery: Octopus Deploy, Spinnaker
• Infrastructure as code: Terraform, Ansible, PowerShell DSC

The right answer for any given organisation will depend on its existing investments, team skills, and the cloud platforms it targets. Adopting an entirely new toolchain simultaneously with a cultural change is a recipe for overload—where possible, extend existing tools before replacing them.

Security Cannot Be an Afterthought

One of the most significant risks in moving from Agile to DevOps is carrying forward legacy security habits that were designed for slower release cycles. In an Agile context, security is often treated as another user story to be prioritised in the backlog. In a continuous deployment pipeline, that model breaks down—there is no natural gate at which security reviews can occur if releases are happening multiple times per day.

“Hackers also use DevOps methods in their attacks, so organisations must develop and implement approaches that act with the same rapidity of DevOps, while also integrating security throughout each stage of the development and deployment lifecycle.”

John Martinez, VP of Customer Solutions, Evident.io

The answer is DevSecOps: embedding security controls directly into the pipeline so they run automatically at every stage. Practical examples include:

• Static application security testing (SAST) integrated into the CI build step to catch vulnerabilities in code before it is merged.
• Infrastructure-as-code scanning to verify that cloud resource configurations are secure before deployment.
• Continuous compliance monitoring of running cloud environments to detect configuration drift against defined security baselines.
• Automated secrets management to prevent credentials from being baked into container images or configuration files.

“Choose effective tools and automate their use. Include security to earn the moniker DevSecOps. For example, include a security check to make sure that your infrastructure as code is secure.”

Josh Rosenthal, Co-founder, CloudSploit

Security must be part of the fabric of the product, present and accounted for at every stage of the DevOps lifecycle, not bolted on at the end.

Compliance in Cloud Environments

For cloud companies and MSPs serving regulated industries, compliance adds another dimension to the Agile-to-DevOps transition. Security and compliance requirements need to be encoded into the pipeline itself—automated checks that verify infrastructure and application configurations meet the required standards before anything reaches production. Clear metrics on transition timelines and integration guidelines help teams move with confidence rather than hesitation.

Establishing compliance as code—expressing regulatory controls as testable, version-controlled policies—aligns well with a DevOps operating model and removes the manual verification bottlenecks that slow down continuous delivery.

Key Takeaways

• Agile and DevOps are complementary. DevOps extends Agile principles from development into operations and production.
• Culture change is the primary challenge. Shared ownership and accountability across dev and ops teams must be established deliberately.
• Start with a pilot. A small, focused team reduces risk and creates the evidence base needed to scale adoption.
• Let process drive tool selection. Tools should serve the workflow, not define it.
• Shift security left. Integrate automated security and compliance checks into every stage of the pipeline from day one.
• Onboard developers properly. New working practices—feature branching, automated testing gates, shared on-call responsibility—need to be part of the standard onboarding process, not discovered after the fact.

Because DevOps has no single formal framework, the definition of progress can differ between organizations. That said, a core set of metrics and key performance indicators (KPIs) applies broadly across DevOps implementations. Tracking these consistently gives teams an objective basis for continuous improvement conversations.

Why DevOps Metrics Matter

Effective measurement and monitoring are the foundation of a productive DevOps program. Metrics serve three practical purposes:

• Visibility: They expose how processes and pipelines actually behave, not how teams assume they behave.
• Accountability: Shared, objective numbers reduce finger-pointing between development, operations, and security teams.
• Direction: Trend data reveals whether changes to process, tooling, or team structure are having the intended effect.

The nine metrics below cover the full software delivery lifecycle—from code commit to production performance—and are commonly cited in DevOps literature as the most actionable starting points.

1. Deployment Frequency

Deployment frequency measures how often code is released to production. It is a direct indicator of how quickly new features, bug fixes, and improvements reach end users. A healthy DevOps pipeline should show a stable or increasing deployment frequency over time.

A sudden drop or erratic trend is a warning sign. It typically points to a bottleneck somewhere in the pipeline—slow code reviews, fragile automated tests, manual approval gates, or inadequate test coverage that forces teams to batch changes rather than ship incrementally.

2. Change Lead Time

Change lead time measures the elapsed time from when a change—such as a bug fix or new feature—is first committed to when it reaches production. This metric captures the full journey through code review, testing, staging, and release approval.

Long lead times usually indicate process inefficiency: manual handoffs, environment provisioning delays, or approval workflows that do not scale. Use this metric as a starting point to map your pipeline and identify which stages introduce the most delay. Reducing lead time directly improves an organization’s ability to respond to user feedback and market conditions.

3. Change Success Rate (and Change Failure Rate)

Shipping fast is only valuable if changes land correctly. The change failure rate measures the percentage of production deployments that result in a degraded service, rollback, or emergency fix. Conversely, the change success rate is the complement: the percentage of deployments that complete without incident.

A high change failure rate degrades end-user experience and consumes engineering capacity on reactive work—troubleshooting and hotfixes—rather than planned improvements. Teams should instrument their CI/CD pipelines to automatically tag deployments as successful or failed based on defined criteria such as error rate thresholds, rollback events, or incident ticket creation.

4. Mean Time to Detection (MTTD)

Mean time to detection measures how long it takes to identify that a problem exists after it has occurred. A low change failure rate is less meaningful if problems go unnoticed for days or weeks. For example, an MTTD of thirty days means an issue causing elevated failure rates could persist for a full month before the team is even aware of it.

MTTD should decrease over time as observability practices mature—better logging, distributed tracing, and alerting all contribute to faster detection. A rising MTTD is also a security concern: the longer an attacker or a vulnerability goes undetected, the greater the potential blast radius.

5. Mean Time to Recovery (MTTR)

Mean time to recovery measures how long it takes to restore service after a failure is detected. MTTR should be kept as low as possible. DevOps organizations reduce MTTR by favouring frequent, small, incremental releases: when a problem occurs in a small change, isolating its root cause is far simpler than debugging a large, complex release bundle.

Invest in runbooks, automated rollback mechanisms, and feature flags to reduce recovery time. Teams that can recover quickly from failures build resilience into their systems and reduce the pressure that discourages frequent deployments.

6. Feature Prioritization and Utilization

Engineering effort spent on features that users do not adopt is waste. Feature utilization metrics—such as click-through rates, feature activation rates, or session depth—reveal whether delivered work actually provides value to users.

If feature usage is low or declining, the team should revisit how requirements are gathered and prioritized. Closing the feedback loop between users, product management, and engineering is central to the BizDevOps approach. Tight feedback loops allow teams to iterate quickly toward features that genuinely meet user demand.

7. Rate of Security Test Passes

Security testing—including static analysis (SAST), dependency scanning, and dynamic vulnerability scanning—is often an afterthought in release pipelines. Integrating security checks into the CI/CD pipeline and tracking the pass rate over time is a core practice of DevSecOps.

A consistent pattern of failed security scans indicates that insecure coding practices or vulnerable dependencies are entering the codebase upstream. Catching these failures at build time is far less costly than discovering them in production. Monitoring this metric encourages teams to treat security as a shared responsibility rather than a gate managed solely by a separate security team.

8. Service Availability

Service availability—commonly expressed as a percentage of uptime over a given period—is a foundational SRE and DevOps metric. It reflects the reliability that end users and business stakeholders experience. Many organizations encode availability targets into service-level agreements (SLAs) or service-level objectives (SLOs), with common targets ranging from 99.9% to 99.999% depending on the criticality of the service.

Track availability continuously and correlate dips with deployment events, infrastructure changes, or traffic patterns. Availability data is most useful when it drives engineering decisions—for example, scheduling high-risk maintenance during low-traffic windows or triggering automatic failover when thresholds are breached.

9. Application Performance

Application performance metrics—CPU utilization, memory consumption, disk I/O, network latency, and response time—provide visibility into how the infrastructure layer behaves under real-world load. An unexpected surge in users can expose under-provisioned resources or architectural bottlenecks.

Equally important: performance degradation without a corresponding increase in traffic often signals a code regression introduced by a recent deployment. Correlating performance trends with deployment events makes it straightforward to identify whether a new release is responsible. Continuous performance monitoring—rather than periodic manual reviews—is essential for maintaining a good end-user experience at scale.

Putting the Metrics Together

No single metric tells the full story. A team with a high deployment frequency and a high change failure rate is not actually delivering value faster—it is delivering instability faster. The nine metrics above are most powerful when viewed together as a system:

• Speed indicators: Deployment frequency, change lead time
• Quality indicators: Change success/failure rate, rate of security test passes
• Resilience indicators: MTTD, MTTR, service availability
• Value indicators: Feature utilization
• Infrastructure health indicators: Application performance

Start by establishing baselines for each metric before making process changes. Then track trends over time—improvement is relative to your own starting point, not an industry benchmark. Review these metrics regularly in retrospectives to drive concrete, data-informed decisions about where to invest next.

Original topic sourced from searchitoperations.techtarget.com.

What Is DevSecOps and Why Did It Emerge?

DevOps was created out of a practical need: software developers and operations teams were working in silos, causing slow delivery cycles, miscommunication, and poor software quality. By bringing these two disciplines together under shared practices, tooling, and culture, DevOps dramatically improved the speed and reliability of software delivery.

But as DevOps adoption grew, a critical gap became apparent — security was being treated as an afterthought, bolted on at the end of the development cycle rather than embedded throughout it. Security reviews, compliance checks, and vulnerability assessments were often conducted only after a product was built, making remediation expensive, slow, and sometimes too late.

This tension gave rise to DevSecOps: a philosophy and set of practices that integrate security directly into the DevOps workflow. Instead of security being a gate that slows release cycles, it becomes a shared responsibility across development, operations, and security teams alike.

The Core Idea: Security Baked In, Not Bolted On

The central promise of DevSecOps is that security controls are embedded at every phase of the software development lifecycle (SDLC), not just at the end. This means security considerations influence design decisions, code reviews, automated testing, infrastructure configuration, deployment, and ongoing monitoring.

In practice, this involves several key disciplines:

• Threat modeling during design: Identifying potential attack surfaces and security risks before a single line of code is written.
• Secure coding standards: Training developers to recognize and avoid common vulnerabilities such as those in the OWASP Top 10 (e.g., SQL injection, cross-site scripting).
• Static Application Security Testing (SAST): Automated scanning of source code for known vulnerability patterns as part of the CI/CD pipeline.
• Dynamic Application Security Testing (DAST): Testing running applications for vulnerabilities in a staging or test environment.
• Software Composition Analysis (SCA): Scanning third-party libraries and open-source dependencies for known CVEs.
• Configuration management: Using tools such as Ansible, Puppet, or Chef to enforce consistent, auditable, and secure infrastructure configurations.
• Secrets management: Ensuring API keys, credentials, and tokens are never stored in source code, using dedicated tools such as HashiCorp Vault or cloud-native secret stores.
• Continuous monitoring and log analysis: Aggregating logs from applications and infrastructure to detect anomalies and potential breaches in real time.
• Vulnerability assessments and penetration testing: Regular, structured efforts to identify weaknesses before attackers do.

Why DevSecOps Is Harder Than It Sounds

Adopting DevSecOps is not simply a matter of buying a security tool and dropping it into a CI/CD pipeline. The challenges are both technical and organizational.

Cultural Resistance

Developers are typically incentivized to ship features quickly. Security teams are often incentivized to minimize risk. These goals can feel contradictory, and without deliberate effort to align them — through shared metrics, shared accountability, and cross-functional collaboration — friction will persist.

Skill Gaps

Security engineering requires specialized knowledge that most software developers and operations engineers do not have by default. Building a DevSecOps capability requires either significant investment in training existing staff or hiring professionals who bridge both domains — sometimes called security champions within development teams.

Toolchain Complexity

A mature DevSecOps toolchain can involve dozens of integrated tools covering source control, CI/CD orchestration, container scanning, infrastructure-as-code validation, runtime protection, and more. Selecting, integrating, and maintaining these tools requires deliberate architectural planning.

How to Start Building a DevSecOps Practice

For organizations that are earlier in their DevSecOps journey, a phased approach is far more realistic than attempting a wholesale transformation all at once.

1. Assess your current state. Understand where security currently sits in your SDLC, who owns it, and where the biggest gaps and risks are.
2. Build internal alignment. Get development, operations, and security leadership to agree on shared goals and a shared definition of what “secure DevOps” means for your organization.
3. Start with quick wins. Integrate a SAST tool into your existing CI pipeline, enforce secrets scanning in pre-commit hooks, or introduce mandatory dependency scanning for third-party libraries. These steps deliver value without requiring a full organizational redesign.
4. Invest in education. Security awareness training for developers, and DevOps exposure for security engineers, helps bridge the cultural gap over time.
5. Automate incrementally. Automate security checks where they add the most value without creating excessive false positives that developers learn to ignore.
6. Measure and iterate. Track metrics such as mean time to remediate vulnerabilities, percentage of pipeline runs with security checks, and the ratio of security issues caught pre-production versus post-production.

Staying Current in a Fast-Moving Field

DevSecOps tooling and best practices evolve rapidly. Cloud-native environments, container orchestration platforms like Kubernetes, serverless architectures, and the expanding use of AI in software development all create new security considerations that practices and tooling must keep pace with.

Practitioners are encouraged to follow reputable sources such as the OWASP Foundation, NIST publications, and vendor-neutral DevSecOps communities to stay informed on emerging threats and recommended controls. Engaging with the vendor ecosystem is also important, as the tooling landscape — covering areas like cloud security posture management (CSPM), container security, and supply chain security — continues to mature at pace.

The Bottom Line

DevSecOps is not an optional enhancement for organizations delivering software at speed — it is a business necessity. Security failures are costly in terms of remediation effort, regulatory exposure, reputational damage, and customer trust. By integrating security into every phase of the development and delivery lifecycle, teams can move fast without inadvertently creating the conditions for a serious breach.

The path to a mature DevSecOps practice is neither short nor simple, but it is well-defined. Start with an honest assessment of where you are, build cross-functional alignment, automate what you can, and treat security as an engineering discipline — not a checkpoint.

The reason is often not the toolchain. It is the foundation beneath it.

Think of DevOps like building with LEGO. The bricks — your CI/CD pipelines, containers, monitoring agents, and collaboration tools — get all the attention. But without the right baseplate, the structure is unstable and hard to extend. In DevOps terms, that baseplate is a software-defined infrastructure (SDI) built on open source technologies.

The State of DevOps Adoption

DevOps adoption has grown steadily across the industry. Research from the mid-2010s showed adoption rates climbing year over year, and performance gaps between high-performing DevOps organisations and their peers became a recurring finding in annual industry surveys. Organisations that had deeply adopted DevOps practices consistently reported faster deployment frequencies, shorter lead times for changes, quicker recovery from incidents, and lower change failure rates compared to teams that had not.

Despite this momentum, a significant portion of teams report that they are not realising the full benefits of their DevOps investment. In most cases, the bottleneck is infrastructure: it is either too rigid, too siloed, or too opaque to support the pace DevOps demands.

What Is Software-Defined Infrastructure?

Software-defined infrastructure (SDI) abstracts compute, storage, and networking resources from the underlying hardware and makes them programmable through software. Instead of manually provisioning servers or configuring network equipment, teams define infrastructure as code and interact with it through APIs and self-service interfaces.

When built on open source technologies — such as Linux, Kubernetes, Terraform, Ansible, OpenStack, or Prometheus — SDI gains additional qualities that align naturally with DevOps principles: transparency, community-driven innovation, vendor neutrality, and extensibility.

The Path to an Agile Business

The primary goal of a DevOps approach is to accelerate the entire application delivery lifecycle — from initial development through testing and into production. Achieving that goal requires infrastructure that can keep pace.

SDI supports this by providing:

• Self-service resource provisioning: Developers can request and receive compute, storage, or network resources on demand without waiting for a manual ticket queue to clear.
• Environment consistency: Standardised service definitions mean that applications built and tested in a development environment deploy predictably into staging and production, eliminating the classic “it works on my machine” failure mode.
• Access to modern primitives: Technologies like containers and serverless functions evolve quickly. An SDI built on open standards makes it straightforward to integrate these primitives as they mature, without rearchitecting the entire platform.

The result is an infrastructure that adapts to the team’s needs rather than forcing the team to adapt to infrastructure constraints.

Automation to Support Strategic Collaboration

Routine deployment and configuration tasks consume a disproportionate amount of engineering time. Patching, provisioning, scaling, and configuration drift remediation can absorb hours that would be better spent on product work.

Automation is the answer, and it is a core characteristic of well-designed SDI. Specific examples include:

• Immutable infrastructure patterns: Pre-hardened VM images or container templates are built once, tested, and deployed consistently — eliminating configuration drift between environments.
• Orchestration: Tools like Kubernetes or Nomad automatically schedule workloads, handle failures, and scale capacity in response to demand without human intervention.
• Infrastructure as Code (IaC): Platforms like Terraform or Pulumi let teams version-control their infrastructure definitions, apply peer review processes, and roll back changes just as they would application code.
• Auto-remediation: Monitoring and observability pipelines can trigger automated responses to known failure conditions, reducing mean time to recovery.

When infrastructure handles the repetitive work, engineers are freed to focus on collaboration, architecture decisions, and continuous improvement — which are the activities that actually advance a DevOps culture.

Visibility Down to the Base Level

A persistent challenge in DevOps adoption is insufficient visibility into the full delivery pipeline. When developers rely on a loosely coupled chain of services, understanding how each component behaves — and how failures propagate — is essential to maintaining delivery velocity.

Open source infrastructure tooling provides several visibility advantages:

• Transparency by design: The source code for open source tools is readable and auditable. Teams can understand exactly how their infrastructure components behave, not just what a vendor dashboard reports.
• Rich observability ecosystems: Open source projects like Prometheus, Grafana, Jaeger, and the OpenTelemetry project provide instrumentation, metrics, tracing, and dashboarding that can be tailored to specific team needs.
• CI/CD pipeline integration: Open source CI/CD tools integrate tightly with infrastructure monitoring, so deployment events, test results, and infrastructure health metrics can be correlated in a single view.

Continuous feedback across the entire pipeline — from code commit to production health — is what allows DevOps teams to iterate confidently and detect regressions early.

The Solution to Cultural Challenges

DevOps is not purely a technology initiative. It requires a cultural shift: breaking down silos between development, operations, and security teams, and establishing shared responsibility for the software delivery lifecycle.

A software-defined, open source infrastructure reinforces that culture in practical ways:

• Vendor neutrality: Teams are not locked into a single vendor’s roadmap or support model. They can adopt best-of-breed tools and swap components as their needs evolve.
• Shared tooling: When developers and operations engineers work with the same open infrastructure primitives, collaboration becomes more natural. Both groups can read, contribute to, and understand the platform they share.
• Community-driven innovation: Open source projects evolve through community contribution. Teams that participate in those communities gain early access to new capabilities and influence the direction of the tools they depend on.

The cultural values that make DevOps work — openness, shared ownership, and continuous improvement — are the same values that drive successful open source projects. Choosing an infrastructure model that embodies those values makes the cultural transition easier to sustain.

Key Takeaways

Before investing further in DevOps tooling, assess the infrastructure layer your tools sit on. A well-designed software-defined infrastructure built on open source technologies delivers four compounding advantages:

1. Agility: Self-service provisioning and environment consistency accelerate the application delivery lifecycle.
2. Efficiency: Automation and orchestration eliminate manual toil and free engineers for higher-value work.
3. Visibility: Open, instrumented infrastructure provides the observability data teams need to ship with confidence.
4. Cultural alignment: Vendor-neutral, collaborative tooling reinforces the shared ownership and openness that DevOps culture requires.

The LEGO analogy holds: no matter how sophisticated your bricks, a weak or mismatched baseplate limits what you can build. Get the foundation right, and the rest follows.

This article is based on original analysis published by itbrief.co.nz.