This article is an independent editorial expansion of a topic originally summarised on techtarget.com. No proprietary data or paywalled content from that source has been reproduced.
DevOps Is Thriving — But the Hard Problems Remain
Nearly two decades after the term entered the industry lexicon, DevOps has moved well beyond buzzword status. The rise of SaaS delivery models, continuous integration and delivery pipelines, containerisation, and cloud-native infrastructure has made the DevOps philosophy not just relevant but foundational to how modern software is built and shipped.
Yet widespread adoption has brought its own complications. DevOps is no longer just a conversation for early adopters — it is the expected baseline for competitive engineering organisations. That means the challenges teams face today are less about convincing leadership to try DevOps and more about making it work at scale, across diverse teams, legacy environments, and increasingly complex applications.
Below are six of the most significant and persistent challenges DevOps teams encounter — along with practical approaches for addressing each one.
1. Agreeing on What “DevOps” Actually Means in Your Organisation
DevOps means different things to different organisations. For some it is primarily a cultural shift — breaking down silos between development and operations teams. For others it is a toolchain decision: CI/CD pipelines, infrastructure-as-code, and automated monitoring. Many organisations conflate DevOps with specific roles, creating “DevOps teams” that inadvertently become a new silo of their own.
Without a shared, explicit definition, teams pull in different directions. Developers may optimise for deployment velocity while operations engineers prioritise stability, and neither group has a common framework for resolving that tension.
Practical approach: Document your organisation’s specific definition of DevOps — what it means for team structure, ownership of pipelines, on-call responsibility, and release processes. Review and update that definition regularly as the organisation grows. Frameworks such as the DORA (DevOps Research and Assessment) metrics — deployment frequency, lead time for changes, change failure rate, and time to restore service — can provide a concrete, measurable foundation for that definition.
2. Selecting the Right Projects for a DevOps Approach
DevOps practices deliver the greatest return on investment for projects that involve frequent, iterative releases to production — web services, APIs, microservices, and SaaS products. They are less naturally suited to projects with long regulatory approval cycles, hardware-dependent deliverables, or fixed-scope contracts that define every requirement upfront.
Applying a full DevOps pipeline to a project that ships once a year adds overhead without proportional benefit. Conversely, running a high-velocity product on a slow, manual release process creates bottlenecks and risk.
Practical approach: Evaluate projects against a set of criteria before committing to a DevOps delivery model. Questions worth asking include: How frequently does the product need to change? How tolerant are end users of brief outages during deployments? Is the testing surface automatable? Portfolio management tooling can help engineering leaders visualise these variables and allocate pipeline investment where it will have the most impact.
3. Achieving Thorough, Fast, and Automated Testing
The promise of DevOps is faster, more reliable delivery. That promise collapses if quality assurance becomes the bottleneck. Shipping code quickly only to discover defects in production creates rework cycles, damages customer trust, and can make a “fast” pipeline slower in practice than a careful manual process.
Many teams underinvest in test automation early in their DevOps journey, treating it as something to retrofit later. That technical debt compounds quickly.
Practical approach: Build automated testing into the pipeline from the start rather than treating it as an afterthought. Aim for a layered strategy: fast unit tests run on every commit, integration tests run on every pull request merge, and end-to-end tests run before every production deployment. Invest in the human expertise — QA engineers with automation skills — needed to maintain that test suite. Automated tools alone are not sufficient without engineers who understand what to test and how to interpret failures.
4. Managing and Reducing Legacy System Debt
Legacy applications are one of the most concrete obstacles to DevOps adoption. They often have no automated test coverage, depend on manual deployment steps, run on infrastructure that cannot be easily containerised, and are maintained by a shrinking pool of engineers who understand how they actually work.
When a team is simultaneously running a modern CI/CD pipeline for new services and manually deploying legacy systems, operational complexity doubles. Incidents in legacy systems consume the same on-call bandwidth that should be improving newer services.
Practical approach: Legacy systems rarely disappear overnight, so plan for a phased approach. Options include: wrapping legacy systems behind APIs so they can be replaced incrementally (the strangler fig pattern); migrating users to newer replacement services over time; or creating explicit team boundaries so legacy maintenance does not block modern development work. Whichever path you choose, document the plan and give it a realistic timeline with clear milestones.
5. Supporting Increasingly Complex Applications
As businesses grow, so does the complexity of the software they need. Microservices architectures, distributed systems, multi-cloud deployments, and real-time data pipelines all introduce operational complexity that a simple CI/CD pipeline was not designed to handle on its own.
Distributed systems fail in non-obvious ways. Debugging a latency spike that crosses twelve services requires observability tooling, skilled engineers, and runbook discipline that many teams have not yet built.
Practical approach: Invest in observability — structured logging, distributed tracing, and metrics dashboards — before complexity makes incidents impossible to diagnose. Define and document service ownership clearly so that when something breaks, the right team is engaged immediately. Accept that complex applications require a proportionally larger investment in tooling, skilled staff, and incident response processes; this is a cost of doing business at scale, not a failure of DevOps methodology.
6. Building a Culture of Continuous Learning and Improvement
DevOps is not a destination — it is an ongoing practice. Teams that treat DevOps adoption as a one-time project and stop investing in it will find their pipelines and practices stagnate while the tooling landscape and industry expectations continue to evolve.
Blameless post-mortems, regular retrospectives, and dedicated time for experimentation are cultural investments that many organisations cut under delivery pressure. That pressure is understandable, but the result is a team that never improves and whose technical debt compounds year over year.
Practical approach: Schedule improvement work explicitly — it will not happen spontaneously alongside feature delivery. Set aside sprint capacity for reducing toil, improving pipelines, and addressing technical debt. Run blameless post-mortems after every significant incident and track the action items through to completion. Encourage engineers to share knowledge through internal talks, documentation, and cross-team collaboration. Budget for external training and conference attendance so the team stays current with evolving best practices.
Final Thoughts
None of these challenges are unique to any single organisation, and none of them are insurmountable. What they share is that they require deliberate investment — in tooling, in people, in process, and in the organisational will to keep improving. DevOps works. Getting the most out of it requires treating it as a discipline that demands the same rigor and continuous attention as the software it helps deliver.