Originally published March 2017. The predictions below reflect the DevOps landscape at the time and are presented here with updated context where relevant.
DevOps Moves from Experiment to Standard Practice
By early 2017, DevOps had crossed the line from experimental to essential. A survey of Gartner Research Circle members conducted in 2016 found that 38% of respondents were already using DevOps practices, with a further 35% planning to implement them in the following year. That meant more than 70% of the IT market was actively engaging with DevOps — a dramatic shift from just a few years earlier when it was largely confined to web-scale companies and startups.
Alongside broader adoption came a wave of venture capital investment in DevOps tooling companies, and IT budget owners began treating DevOps capability as a requirement rather than a nice-to-have. The challenge was no longer whether to adopt DevOps, but how to do it well — at scale, securely, and without accumulating technical debt in the toolchain itself.
With that backdrop, five changes were emerging that would define what mature DevOps actually looked like in practice. These themes remain highly relevant today.
Change 1: Continuous Updating Becomes the Baseline
When every company effectively becomes a software company — whether they sell retail goods, financial products, or healthcare services — the cadence of software delivery becomes a direct competitive variable. Quarterly or monthly release cycles were already too slow for many markets by 2017; the expectation had shifted to continuous or near-continuous delivery.
This pressure meant that CI/CD pipelines were no longer optional infrastructure. Teams needed to be able to merge, test, and deploy code multiple times per day without manual hand-offs causing bottlenecks. The organisations that thrived were those that treated their delivery pipeline as a product in its own right — instrumenting it, improving it, and removing friction systematically.
Key enablers of continuous updating in 2017 included:
- Automated build and test pipelines (Jenkins, Travis CI, CircleCI)
- Feature flags to decouple deployment from release
- Trunk-based development to reduce long-lived branch complexity
- Deployment automation tied to version control events
Change 2: Reliable, Language-Agnostic Tooling
Most real-world engineering organisations do not operate with a single programming language or a single technology stack. A typical enterprise in 2017 might have Java services, Python scripts, JavaScript frontends, and Go microservices all in production simultaneously. DevOps tooling that only served one language or runtime was a liability, not an asset.
The market responded by pushing platforms toward language-agnostic design — tools that could instrument, test, package, and deploy artefacts regardless of the underlying runtime. Containerisation, particularly Docker (which had gone mainstream by 2016), played a major role here: by packaging an application and its dependencies together, containers made the deployment target largely agnostic to language choice.
Beyond language support, enterprises also demanded high availability from their DevOps infrastructure itself. A pipeline that goes down takes engineering productivity with it. The expectation shifted from “reliable enough” to “highly available and clustered” — the same bar applied to production services was now applied to the tools that build and ship them.
Change 3: Hybrid Infrastructure Becomes the Default
The binary debate of “cloud versus on-premises” had largely resolved itself by 2017: most enterprises were running both, and DevOps tooling had to work seamlessly across both environments. Hybrid infrastructure models — where some workloads run in private data centres and others in public cloud — became the dominant architecture for large organisations.
This created both opportunity and complexity. On the opportunity side, teams could burst workloads to the cloud for CI test parallelism while keeping regulated data on-premises. On the complexity side, pipelines needed to handle differing network topologies, credential models, and deployment targets transparently.
Infrastructure-as-code tools — Terraform, Ansible, Chef, Puppet — gained significant traction precisely because they allowed teams to describe infrastructure intent in version-controlled files that could target multiple providers. The pipeline that provisions a staging environment in AWS could, with minor configuration changes, provision the same environment on-premises.
Change 4: Security Gets Embedded in the Pipeline (DevSecOps)
Faster release cycles create a real security risk if security checks are applied only at the end of the development cycle — or worse, only in response to incidents. The 2017 shift was a growing recognition that security scanning had to move left: into the CI pipeline, into the code review process, and into the dependency management workflow.
Three specific areas drew attention:
- Dependency vulnerabilities: Open-source libraries are the majority of most application codebases. Tools that scan dependency manifests against known vulnerability databases (such as the CVE list) became standard CI pipeline components.
- Outdated packages: Even non-vulnerable packages that are significantly out of date represent operational risk. Automated dependency update tools began to emerge as a category.
- Licence compliance: As open-source adoption grew, so did legal exposure from incompatible licences. Automated licence scanning became part of the release gate for many organisations.
This shift is now widely referred to as DevSecOps — the practice of treating security as a shared responsibility embedded throughout the software development lifecycle, rather than a gate applied by a separate security team at the end.
Change 5: Scalability Without Penalty
By 2017, many organisations were moving past proof-of-concept DevOps initiatives. Teams that had piloted a toolchain with a handful of developers now needed to roll it out across hundreds of engineers, dozens of teams, and multiple business units. The question was whether their chosen tools could scale with them — technically and commercially.
On the technical side, this meant that CI/CD servers, artefact repositories, and monitoring systems needed to handle significantly higher load. Distributed, horizontally scalable architectures for these tools became a hard requirement rather than a premium feature.
On the commercial side, organisations scrutinised vendor pricing models carefully. Tools with per-seat or per-build pricing that penalised growth created a perverse incentive: the better your DevOps practice, the higher your tooling bill. The market shifted toward pricing models that rewarded adoption rather than punishing scale.
Practically, this means evaluating DevOps tooling not just on current team size but on what the cost and operational burden looks like at 5x or 10x current scale before committing.
What These Changes Tell Us Now
Looking back from the present, all five of these 2017 predictions proved accurate — and in most cases, the trends accelerated further than the original analysis anticipated. Continuous delivery is now table stakes. Container-native, hybrid-ready toolchains are the norm. DevSecOps has become a recognised discipline with its own tooling ecosystem. And scalability is a first-order requirement in any serious DevOps platform evaluation.
If you are evaluating or evolving your DevOps practice today, these five dimensions — delivery velocity, tool reliability, infrastructure flexibility, embedded security, and scalable architecture — remain the right axes on which to assess your current state and identify gaps.