DevOps- Road ahead

In the concluding article of the DevOps series, I outline the future areas of development and why the eventual adoption of the DevOps approach may not deliver the original business case projections.

DevOps is beneficial and a lot of organisations are currently undertaking the journey – the trend and the pace of adoption is widespread. Interestingly, going by the emerging uptake of cloud technologies, micro services and a shift towards containerisation (e.g. Kubernetes) - DevOps compliance will be even more necessary and vital in the coming years in order for firms to be competitive in the marketplace.

But even after ten years since the DevOps journey started, there continue to be hoops to jump.

The present reality for many organizations is that they face multiple interdependent supply chains and value streams which are deployed across hybrid and multi-cloud environments. These are developed and deployed by distributed IT teams using a variety of technology stacks that get in the way of effective, efficient software delivery. The complexity of managing these multiple, concurrent supply chains and value streams as well as the software development practitioners themselves, creates the polar opposite of agility.

Even today, not only are businesses unable to qualify and quantify where and how value is delivered, they are also unable to properly determine where to make tactical and strategic investments that could address the inefficiencies in their software delivery processes as a whole. To complicate matters even further, ‘Software sprawl’ is rampant within organisations and hinders data-driven decision making. Firms continue to struggle with the reality of multiple technology stacks, across multiple generations of technologies, negatively impacting collaboration. To make matters more complex, there has been a proliferation of tools and platforms with a lack of interoperability and lack of clarity on how to best use them or whether they are fit for purpose. These differences make it difficult for developers to find the right integrations that work for their environments, leading to wasted time and effort.

 Sometimes, I feel the creative solutions fostered by the pace of new technologies tend to become a self-defeating construct in that they force organisations to keep adopting newer and newer ‘stuff’ for the fear of losing out. All this even before they get a realistic chance to fix their older problems!

Enter forth the arcane world of DevOps business case benefits and why they are so off!

Organisations continue to grapple with their inability to break down the costs of delivering software, the inability to quantify the monetary impact of software delivery delays, and the inability to trace the cost of defects. Businesses are investing in software delivery without a clear understanding of where value is being added or subtracted. Without this information, it is impossible to properly determine the benefits and/or drawbacks of past or future investments.

Exploring the subject of business case variance further, let us consider some additional dimensions.

Spend on rolling out DevOps change management includes the cost of training employees, the cost of acquiring new tools that conform to the new methodology, as well as the cost of losing employees who are not accepting of the change and replacing them with similarly skilled employees. Finally, once change is implemented, productivity inevitably goes down until the team gets comfortable and skilled at executing under the new processes. All this impacts the eventual benefits expected from DevOps.

Once DevOps processes are adopted, they must be applied to all the applications within the organisation. After all that is the whole point to get the wider benefits from DevOps!

Applications moving to DevOps are said to be on-boarded (where the original build, deploy, test and release automation is created). Successfully on-boarding an application requires education of the sponsoring executives, training of the impacted developers and testers, and coordination with the change and release managers. In addition, there is a pure people cost for on-boarding applications to the DevOps process. For example, typical DevOps engineers can on-board five applications a week. Onboarding a large number of application components can consume many engineers over an extended period of time. So more cost outflows to deal with!

In addition, DevOps fosters continuous improvement and as a result, application development methods continuously evolve and may adopt new technology components. Collection of meta data about the behaviour of application components is no small task, requiring frequent follow-ups and action items to reach completion. This data collection and analysis may result in significant changes that require revisiting the DevOps automation to adapt to these ongoing revisions and updates.

Let us now consider the Bi-Modal Infrastructure Costs. This is the cost incurred to run concurrently with old and new IT infrastructure whist implementing DevOps. Costs are lower for developing new applications that can be designed specifically for a more agile DevOps friendly environment. For existing applications however, the cost to move into a DevOps process can be significantly higher. In addition, the cost of working with existing infrastructure is very high. Infrastructure cost for new applications is often cloud based (whether public or private) and the cost is incurred “on-demand”. Infrastructure cost for pre-existing applications is often datacentre-based and fixed. Existing applications must be re-factored over time to fully benefit from DevOps and this application re-factoring cost can be very high.

Let us now turn our attention to the upcoming focus areas for organisations on their DevOps journey.

 With the number of microservices rising to the hundreds (or even thousands) for some enterprises; maintaining consistent release strategies across the board is becoming a nightmare. If the goal is to replicate a unique Continuous Integration and Continuous Delivery (CI/CD) pipeline per microservice, then enhanced pipeline automation and configuration management are going to be top focus areas in the coming years for IT teams.

Traditional CI/CD platforms are not suited for modern development workflows to support the transition and adoption of cloud technologies. Slow speed, unreliability, scalability limitations and security risks as common hang-ups among many of the current CI/CD tools. DevOps tooling market will have to continue to iterate fast to resolve these issues for organisations in the times ahead.

Another focus area relates to standards. Presently there are very few standards in the CI/CD space. This makes it very difficult to define what good looks like! We can expect ongoing traction in this important area of DevOps.

Aspects like integrating Security within the DevOps way of working (sometimes referred to as DevSecOps) are increasingly taking a sharper focus as organisations imbibe the IoT and Cloud computing approaches on their Digital evolution journey.

A final emerging flavour for firms on their DevOps journey that I would like to highlight is the use of Artificial Intelligence (AI) and Machine Learning (ML) aspects on the large data-sets that surround the whole lifecycle to identify patterns to make the whole approach ‘self-healing’ and ‘self-driving’.

 In conclusion, my discussions with companies who have matured their DevOps practices such as Netflix, Amazon and others, suggests that this process can take over 5 years. These organisations are at the top end of having achieved DevOps maturity and they have managed to be where they are based on fast decision making, disciplined implementation and low legacy factors to deal with. The key message here is that most organisations who are on the DevOps journey will struggle to replicate the successes of the top-end brands owing to factors outlined in the article and the benefits will take time to materialise. Even a good implementation may only yield circa 50%-60% of original business case value. But despite all of that, DevOps is the right goal to pursue. As my ex-colleagues in Toyota say, as long as the direction is right, concerns about the pace are just that!