Breaking Down DevOps: Misconceptions, Challenges, and the Future

DevOps, SRE, and platform engineering - three terms that get thrown around constantly, often interchangeably, despite having distinct roles and responsibilities. The engineering world has embraced DevOps as a label, but what does it really mean? More importantly, are companies truly adopting DevOps principles, or is it just a buzzword?

In conversations with DevOps engineers, platform managers, and heads of engineering, one theme keeps surfacing: confusion over definitions and implementations. While some teams claim to ‘do DevOps,’ what they really mean is they deploy to production. This misconception blurs the true intent behind DevOps, which is to foster collaboration between developers and operations, improve automation, and streamline workflows - not just push code live.

To explore this further, I sat down with Alistair Jordan , an industry veteran with 15 years of experience spanning operations, development, and consultancy. Having worked across various companies and roles, he has a unique perspective on what’s working in DevOps today, what’s not, and where the industry is heading.

The Core Issue: DevOps ≠ Engineering Quality

One of the biggest misconceptions about DevOps is that implementing it guarantees high engineering quality. The truth is, DevOps is about processes, collaboration, and automation - it doesn’t inherently measure or ensure the quality of the software being deployed. Organisations need to recognise that while DevOps can improve efficiency, it doesn’t replace strong engineering fundamentals.

The Rise of MLOps and AIOps

Beyond DevOps, new terms like MLOps and AIOps are emerging as machine learning and AI become an integral part of modern engineering. Engineers are increasingly retraining in AI-related fields, signalling a shift in how infrastructure and operations are managed. But what does this mean for the future of traditional DevOps roles? Is AI here to streamline operations, or does it introduce more complexity?

DevOps as a Responsibility, Not Just a Role

A common issue that Alistair highlighted is how DevOps is often seen as the sole responsibility of a ‘DevOps engineer’ rather than being integrated across the entire engineering function. Many companies hire DevOps engineers but fail to instil DevOps practices into the broader team.

For instance, CI/CD primarily benefits developers by ensuring that code is automatically built, tested, and verified before deployment. Rather than pushing code and hoping for the best, CI/CD provides immediate feedback, catching issues early and preventing technical debt from accumulating over time.

The misconception that deployments mean pushing code straight to production is another challenge. In reality, most deployments go into internal environments that replicate production, allowing for continuous testing before anything reaches the end user. This iterative approach - build, test, iterate, deploy - ensures stability and reliability.

The Common Misconceptions About DevOps

One of the most glaring misuses of DevOps is companies claiming they have adopted it when in reality, they are simply deploying to production without implementing the foundational practices that enable efficiency and reliability. Alistair has encountered numerous organisations that say they ‘do DevOps’ but fail to use industry-standard tooling or best practices. In some cases, legacy processes remain intact, merely rebranded under the DevOps label.

Another issue is how job titles have evolved. Roles like Systems Engineer, Infrastructure Engineer, and DevOps Engineer often describe similar responsibilities, but the naming has changed over time. Alistair noted that much of what he did as a Systems Engineer in 2013 was fundamentally the same as later DevOps roles, with the key difference being that older practices were more manual and infrastructure-heavy.

His early experiences working in data centres - physically handling server racks in secured, oxygen-controlled rooms - are a stark contrast to today’s cloud-driven environments. While the tools and methodologies have evolved, the fundamental principles of reliable infrastructure, automation, and continuous improvement remain the same.

The Balance Between Innovation and Practicality

One challenge in DevOps is managing the constant influx of new technologies. There’s always a temptation to adopt the latest tools, but that doesn’t always mean they’re better. Alistair emphasised that companies often jump to new technologies without fully considering whether they actually need them. Sometimes, optimising existing tools is far more effective than introducing new complexity.

For example, communication tools play a huge role in DevOps workflows. Alistair has found that platforms like Slack tend to be much more developer-friendly than Microsoft Teams due to better integrations and ease of use. However, these decisions are often made at a political level within organisations rather than being driven by practical engineering needs.

This extends to infrastructure choices as well. Kubernetes, once hailed as the ultimate solution for container orchestration, is now being reconsidered by some organisations due to its complexity and the high salaries required to maintain it. Many companies have spent years struggling with Kubernetes, only to find it too complicated and expensive to sustain. Some are now exploring alternative deployment tools, but the challenge remains - every alternative comes with its own trade-offs.

Alistair’s perspective? “Kubernetes has always been complicated. People assumed it would be simple and then realised the complexities. I’ve seen organisations abandon it after years of struggle, but the reality is, many alternatives just create new problems. At the end of the day, it’s often ‘better the devil you know.’”