Royal Jain, the co-founder of startup CodeParrot, triggered a lively debate this month when he suggested that the rise of cloud-managed products and automated pipeline builders could make DevOps a thing of the past.
His view: tools like fully managed cloud databases, message queuing services like Amazon SQS and development workflow automation tools like Github Actions are making DevOps “less critical” and smart engineers should focus more on a deep understanding of observability, monitoring and alerting, as well as platform engineering – e.g. building stable development environments and infrastructure. “Data warehouse cost optimisation, secure networking are very much in demand,” he added.
It’s a viewpoint it might be easier to take a firmer viewpoint on, if “DevOps” implied a very discrete and narrowly bound set of skills.
It arguably doesn’t – as Red Hat notes, whilst “some organizations may hire professionals to ‘perform DevOps’ within their workflows, successful DevOps adoption depends on changes to culture and process…”
And many respondents to Jain’s post suggested that his view was misplaced: As Abishek Veeramala, a GitOps product lead at Red Hat put it: “There is a clear difference between DevOps, SRE and platform engineering. There are still challenges like GitOps-based deployments, declarative infrastructure setups, drift detections, Progressive Delivery which DevOps engineers are solving for companies" he added.
But Jain’s suggestion that DevOps may become as passé as the dedicated database administrator (sorry, DBAs); a role that slowly going out of fashion in a world of cloud-native applications running on DBaaS – certainly in smaller organisations or those moving heavily to the cloud – certainly started a conversation. Is DevOps going to become a relic of the past? The Stack put the view to some members of our network.
Is DevOps dead? Is this a meaningful question?
Dave Stokes, Technology Evangelist, Percona, agreed that the evolution of DevOps is changing what organisations want of an engineer; pointing amongst other areas to a need for understanding platform costs.
““DevOps streamlined the processes for developers while mostly ignoring the needs of the people who had to ‘keep the wheels on the wagon.’
“With the explosion of new applications being launched with the proliferation of new software products, the ability to keep the increasingly growing pile of technology running happily pas] stretched many to their capacities and beyond. There is a need to be able to integrate the new and updated with stability for the more mature applications.
“Platform engineering is certainly a big opportunity to deliver the kinds of services that cloud providers do, but without being tied to those providers. Using open source and Kubernetes, you can deliver self-service technology options for your developers to get started faster,” he mused.
Stokes added: “What do IT teams want to achieve? They want to make their lives easier with automation, and they are under more pressure to meet what the business wants as well. DevOps certainly helped in this, but everything evolves over time. The processes that were streamlined are still required but those processes too have evolved and may need attention or re-engineering to meet today’s needs. I think we’ll see more emphasis go back into data management, given all the interest in data and AI at present… [One of] the biggest challenges [for organisations meanwhile] is actually around cost. Does your team responsible for automating and improving these services understand the cost model around how things are used? Trying to make things more efficient can lead to you spending more around that area, simply because you have made the cost to use that service lower – the Jevons paradox.”
As for the demise of the DBA, he added: “There is still going to be a need for someone to write SQL. There is still going to be a need for someone to tune queries. There is still a need to restore data from backups.
“The needs will always be present and not all organizations can cleanly demark with are DBA-only, DevOps-only, or SRE-only. If the goal is to truly free the application developer, the underlying needs to be able to support this. However, the need for cost containment, auditing, and future-proofing the organization needs someone to take on these responsibilities which are outside of the purview of the developer. The ability to control the underlying infrastructure while empowering the developer. We require options like platform engineering to provide both.”
To Michael Isbitski, Director of Cybersecurity Strategy, Sysdig, DevOps has “always been a set of practices, at times an ideal to support digital transformation initiatives and build pipeline focus in order to speed delivery and satisfy business demand. DevOps as a role has been reinforced by relatively small companies with small teams that could do it all with the democratization of development tools and learnings, but this isn’t a particularly prudent or mature approach. In larger companies and enterprises, and to provide for better governance, it’s commonplace for tasks and accountability to be distributed amongst teams.
“A software engineer is likely focusing on application code, not infrastructure, though it's possible to control many aspects of a system with ‘as-code’ approaches. Implementation and operations of supporting systems are handled by separate network engineering, infrastructure & operations, and cloud engineering teams. However, the methods that these supporting teams use are likely far more automated and use appropriate as-code formats, sometimes referred to more simply as ‘DevOps-friendly.’” he said, adding that “I’m not convinced that site reliability engineering was ever the responsibility of developers (or DevOps engineers) if you hold strongly to the belief that it’s a distinct role.
“From my perspective, SRE responsibility often belongs to the teams that are responsible for Infrastructure & Operations (I&O), PlatformOps, or SecOps functions in the organization.”
What are your views on the future of DevOps? Does the rise of the Platform Engineer change how DevOps is approached? How are new toolings changing how developers, operations, platforms are set up? Is this even a meaningful debate to have? Let us know.
