Is DevOps promising too much? If it was as easy as some vendors make it, why are clients struggling with materialising the benefits stipulated? Simply put there are three main reasons: a) Lack of common definition b) Lack of standard implementation approach and c) One size does not fit all.
As mentioned earlier DevOps is not a new concept, but the efforts to harmonize several aspects of the entire Development-to-Operation process mark the beginning of a new era. Gartner refers to DevOps as, “…IT service delivery approach rooted in agile philosophy with an emphasis on business outcomes, not business orthodoxy”. (Gartner, Seven Steps to Start Your DevOps Initiative, 16 September 2014, G00270249, Ronni J. Colville ).
Many vendors and market analysts emphasize on ‘agility’, which connects development with operations to address the above mentioned issues. Agility is a critical element to:
Aid error diagnosis
Remove the siloed setup
Eliminate the narrow-mindedness
Deal with the rate of application change
To some, DevOps is a panacea for all ills; for others, it is a marketing gimmick, similar to the Emperor’s new clothes. . However, the truth lies somewhere in the middle. Traditionally we have been focusing too much on the process of delivering the actual solution, designed to create a change. However to bring out the intended change we need to focus on tools, processes, and people, while ensuring the stability of our service delivery. DevOps makes an attempt to reduce inefficiencies by addressing the impact of development changes (new or existing) on three factors: Tools, Processes, and People.
However, the DevOps concept has not attained full maturity. Gartner summarised the reasons in the following (again,  ) :
The lack of a standard definition for DevOps has created confusion for infrastructure and operations (I&O) leaders, trying to adopt this philosophy
There is no standardized or simplified approach regarding the adoption of DevOps by an enterprise I&O leader, causing confusion about how and where to start
Each DevOps implementation is unique and every customer requires a customized approach
Activities are underway to address the lack of a standard definition (first challenge). The Open Group has announced a new Forum IT4IT (http://www.opengroup.org/IT4IT
) during its London Conference in October 2014 which attempts to standardize an IT4IT related framework.
Next to these issues – lack of definition, standard approach and one size does not fit all – DevOps faces implementation challenges. During coding and testing functional and non-functional areas, the IT department needs to ensure that the changes are accurately implemented and that the new capabilities comply with business requirements. Development cannot be carried out in a live environment. Hence new and separate environments (pre-production and non-production environments) are needed to allow developers to write new or change an existing code (or change application configurations for COTS products). This also enables to test both functional and non-functional aspects of the end product.
Four main challenges are typically prevalent in this scenario:
1) Complex Pre-production/On-production build and run
For sophisticated application landscapes with complex integration setups, creating, setting up, and deploying a new environment is costly and prone to errors. Generally servers, storage, network as well as application environments are built and configured in a semi-automatic fashion. At best, different teams are responsible for deploying new servers and applications. Considering the huge cycle time from requisition to receipt of a new environment, the entire process seems to be fraught with inefficiencies. At times, in absence of dedicated teams, a single resource manages the entire show, which adds to inefficiency. Moreover, managing the consistency of the environment configuration introduces a complexity and the risk of failures adds to probabilities of lower quality of deliverables. At times, in light of cost considerations, some of the key functional teams like security and compliance may not participate during the environment build. This may impact the live deployment of code.
2) Error prevention and diagnosis
As a result of the complex challenges (mentioned above) moving/promoting code to the live environment involves risks and may give rise to outages. With higher manual intervention, the risks of errors and outages multiply. Many a time, such errors aren’t caught instantly and may have an impact on other processes, for instance, testing of an application change. In this case, the tester would most probably assume that the error is due to the change and would request the developer to fix the issue. The developer would typically use a development environment to write and “unit test” his change. Now, as his environment differs slightly from the test environment no error is reported, i.e. ‘it works for me’. Root cause analysis in this case will ultimately results in valuable resources being spent on diagnosis of why the change works in development environment but not in the test environment.
3) Wall of confusion
Developers, on one hand, are incentivised to maximise ‘change’ – writing new code or enhancing the existing one, while, on the other, operations personnel are encouraged to minimize change. (in order to maintain KPIs and SLAs ). Further, both the groups operate in diverse organizations within a firm and may have different budgets. Typically, developers work within a project delivery organization (assisted by project), whereas operations staff work within support organization (assisted by technology). Location of both the resources in physically different areas adds to the problem. Developers often perceive operations staff as ‘innovation blockers’, while operations staff see developers as those who don’t understand the importance of stability. Both the groups are critical for the long-term sustainability of the business – to decrease outages and minimize expenditure. To achieve this, a close collaboration among both the groups is crucial.
4) Rate of change versus Stability
Different applications cause different rates of change versus stability. Gartner’s ‘Pace-Layered Application Strategy’ outlines a way to categorize applications into:
Systems of record (typically ERP-type applications)
Systems of differentiation (typically business-specific applications, often COTS applications with customization)
Systems of innovation (typically new web-based, agile-development-focused applications)
What is needed to overcome these barriers? I will cover this in Part 3…Thanks for reaading