Over the last couple of years, I have noticed that the shiny new paradigm of DevOps has started to have lose its lustre, it seems to be showing signs of tarnish and rust spots. When DevOps exploded onto the scene as the great new answer to everybody’s problems. We all thought that we could just merge the disparate processes of Developers and Operational staff, in a great big melting pot, and like a 1960’s hippie commune everything would automagically improve and become nirvana. It would have been nice, but politics and money have got in the way. The politics of ITSM with ITIL and DevOps with Agile and juxtaposed conflicting ethos, and the money in the form a tooling that took the path of least resistance to profit.
So is DevOps a Broken promise?
DevOps as a principle has its history founded in the Agile movement and first started to gain serious interest in 2010 with the release of the Phoenix Project, as is a popular methodology in the software development and IT industry. Its aims are laudable; the integration and automation of the work of software development (Dev) and IT operations (Ops) as a means to improve and shorten the systems development life cycle.
However, some experts are now arguing that DevOps is falling apart this as a main part because it appears to focus only on the Dev side of the equation, not the equally important operational side; Which I call the (Big)DEV(little)ops. It is claimed that DevOps has failed to deliver on its promise of faster, better, and cheaper software delivery, and that it has created new problems for IT operations.
In this article, I will examine some of the challenges and limitations of DevOps from an operational perspective and suggest some possible ways to overcome them.
How did we get here in the trough of depression? It is a long and painful story of broken initiatives, it involves vested interests and reluctance to change, it is a story of protectionism, it is also a story of over promising and under achievement. This is not a slur on those that are working as DevOps engineers (more on that later) but a lack of understanding of what was needed. Many companies have paid lip-service to this very disruptive paradigm. Jumping in without actually understanding the operational changes to a business that are required to successfully implement DevOps. Companies have attacked the DevOps revolution from a technical perspective, rather than a business process, tied to implement it piecemeal as a tactical solution rather than a strategic, top to bottom business process transformation project.
The Challenges of DevOps for Ops
One of the main challenges of DevOps for Ops is that it requires a significant shift in culture, mindset, and skills. DevOps advocates for a collaborative and cross-functional approach to software delivery, where developers and operators share ownership, responsibility, and accountability for the entire software lifecycle.
However, this is easier said than done. Many organizations still have siloed teams, processes, and tools that create barriers and conflicts between Dev and Ops. For example, developers may prioritize speed and innovation over stability and reliability, while operators may prefer predictability and control over change and risk.
Moreover, DevOps demands a high level of technical competence and automation from both Dev and Ops. Developers are expected to write code that is testable, deployable, scalable, and secure, while operators are expected to manage complex and dynamic environments that support continuous integration and delivery (CI/CD).
However, not all developers have the skills or the interest to do Ops tasks, such as provisioning infrastructure, configuring networks, monitoring performance, troubleshooting issues, etc. Similarly, not all operators have the skills or the interest to do Dev tasks, such as writing code, testing features, deploying applications, etc.
The Limitations of DevOps for Ops
One of the biggest challenges for DevOps with Operational people is also its greatest benefit, its agility. This hits the reinforced concrete wall that is ITSM (IT Service Management) and their adherance to their legacy framework ITIL 3. ITIL3 and DevOps are often seen as incompatible and conflicting approaches to IT service delivery. The main reasons being:
- ITIL 3 is prescriptive and rigid, while DevOps is adaptive and flexible. ITIL 3 defines a set of processes and roles that must be followed and adhered to, regardless of the context or situation. DevOps encourages experimentation and innovation, allowing teams to choose the tools and methods that work best for them.
- ITI L3 is focused on stability and control, while DevOps is focused on speed and agility. ITIL 3 aims to minimize risks and errors by enforcing strict change management and governance procedures. DevOps aims to accelerate feedback loops and learning cycles by enabling frequent and small changes that can be easily rolled back or fixed.
- ITIL 3 is siloed and hierarchical, while DevOps is collaborative and cross-functional. ITIL 3 creates boundaries and handoffs between different teams and functions, such as development, testing, operations, security, etc. DevOps breaks down these barriers and fosters a culture of shared responsibility and ownership for the entire software lifecycle.
In fact you could almost say that ITIL 3 is the antithesis of DevOps.
Another challenge of DevOps for Ops is that it has some inherent limitations that may hinder its effectiveness and efficiency. DevOps is not a silver bullet that can solve all the problems of software delivery. It has some trade-offs and constraints that need to be considered and addressed. This is where the overpromising and underdelivering comes in. DevOps is a journey not a quick fix, it is most definitely NOT painless. Processes need to alter Change Control needs to become more flexible to promote rapid change, communication paths need to flatten between teams, Silos pulled down and collaboration across functions improved, what I call Box communication needs to be avoided and team members be franchised with decision making capabilities. This terrifies middle management who see their reason to be disappearing down a plughole. This need not be the case, but the fear is great in many.
Communication needs to be outside the box.Another major limitation of DevOps is that it can create a false sense of security and quality. Yes your code is idempotent and your results will be understandable, but the fact that DevOps relies heavily on automation to speed up and streamline the software delivery process leads to it becoming a crutch. Automation is not a substitute for human judgment and expertise. Automation can also introduce new errors and vulnerabilities that may go unnoticed or unaddressed because the code is not revisited and updated or checked every time a deployment is carried out.
Further, DevOps increase the complexity and cost of software delivery. DevOps done properly requires a high level of coordination and communication between Dev and Ops teams, as well as between different tools and platforms. This can create additional overhead and challenges for managing dependencies, compatibility, integration, etc. Unfortunately, DevOps is rarely done properly, and these issues are only magnified due at best, to a lack proper collaboration and at worst active stone-walling between still active silos.
Finally, and more worrying is that DevOps can also create new sources of technical debt and legacy issues. DevOps encourages frequent changes and updates to software products and services. However, this can also lead to accumulation of unused or outdated code, configurations, data, etc., that may affect performance, security, maintainability, etc.
The Future of DevOps for Ops
So now that it seems that I have just pulled DevOps out the front door and shot it in the head, what can be done to improve DevOps and not just for Ops? How can we make sure that DevOps delivers on its promise of faster, better, and cheaper software delivery? How can we overcome the challenges and limitations of DevOps for Ops?
There is no definitive answer to these questions. However, I have some possible suggestions are:
- Adopt a balanced approach to DevOps: Originally DevOps was a concept of partnership between two equals, there is no doubt that the pendulum has swung too far to the Development side of the equation; this is not helped by the fact that tooling like ansible, Terraform, and pipeline management products are heavily focused on developers. The Companies that build these tools could introduce “OpsRel” to work with operational teams aiding them on their journey in the same manner that “DevRels work with developers.
- ITIL 4 will be a friend: released in 2019. It is designed to be more agile, flexible, and collaborative than its predecessor. It also recognizes the value and importance of DevOps as a way of delivering IT services in the digital age. ITIL 4 introduces some key changes and concepts that aim to align ITSM with DevOps principles and practices. Some of these are:
- The four dimensions model: This model describes four aspects that need to be considered for any IT service: organizations and people, information and technology, partners and suppliers, and value streams and processes. This model encourages a holistic and systemic view of IT service delivery, rather than a narrow and linear one.
- The service value system: This system describes how various components and activities work together to enable value creation for customers and stakeholders. It consists of six elements: guiding principles, governance, service value chain, practices, continual improvement, and feedback loops. This system emphasizes the importance of co-creation, collaboration, automation, feedback, and improvement for delivering value.
- The service value chain: This chain is a set of interconnected activities that enable the delivery of value outcomes. It consists of six activities: plan, improve, engage, design and transition, obtain/build, deliver and support. These activities can be adapted and combined in different ways to suit different scenarios and objectives. This chain supports a flexible and iterative approach to service delivery, rather than a fixed and sequential one.
- The guiding principles: These principles are a set of recommendations that can guide decisions and actions in any context or situation. They are derived from various sources, including Agile, Lean, DevOps, etc. They are: focus on value; start where you are; progress iteratively with feedback; collaborate and promote visibility; think and work holistically; keep it simple and practical; optimize and automate. These principles align with the core values and principles of DevOps.
Summary
To sum up DevOps should not be seen as a one-size-fits-all solution or a binary choice between Dev or Ops. Rather, it should be seen as a spectrum or a continuum that can be adapted to different contexts and needs. Depending on the nature and scope of the software project or product. This is a lot more difficult to achieve to do, than it is to say, ITIL4 goes a long way to solving some of the more intractable differences in the mindsets of Developers and Operational staff
What do you think? Do you agree or disagree with my opinions? Do you have any other opinions or predictions on what the future of DevOps or even DevSecOps will be? I would love to hear your thoughts in the comments section below.
