The ideas and principles guiding DevOps are noble. Bridging the gap between development and operations in IT has been of immense benefit. DevOps has helped us create dynamic, fortified, and functional systems, characterized by adaptability second to none, with a clear outcome: the improvement of service delivery. Emphasizing collaboration and cooperation between the two often opposing groups is guaranteed to bolster quality of products, as each will be a result of an intricate blend of ingenious ideas.
The marriage of operations and software development has eased the delivery process. However, although DevOps has been innovative and successful, there are some underlying shortcomings; some so major they might render DevOps redundant in the near future. Let's examine some of these pitfalls.
Niche Approach
The integration of development and operations is limited with regard to its areas of application. It is highly likely that its impact will be considerably watered down in the future, in light of conventional core operations. It goes against organizational culture; which advocates for the separation of responsibilities, bringing together these two essential functions into one complex methodology. Furthermore, the way in which the vast majority interprets the concept is a major problem, exposing its applicability to a host of risks. DevOps, with regards to system development, advocates for the refining of the ITIL set of practices, with a view to the creation of superior systems. Two schools of thought exist: one proposing means and ways of interacting with a DevOps agenda, and the hoi polloi, with misguided postulations of an end to ITIL with the advent of DevOps. This poses a new front for the manifestation of conflict, with those advocating for a strict top-down structure of development, pitted against those proposing a baseline oriented structure.
DevOps has evolved into a globally accepted approach, with considerable beneficial implications across all societies and enterprises. It complements business processes perfectly, leading to a wealth of efficiency. In an attempt to mold development and operations into a double-edged sword, so to speak, proponents have lost sight of the most essential principle in business processes; getting an idea from conception to a point where it actually makes money. An intricate blend of ideas, individuals and skill is required in every step of the ALM process for it to be successful. The reduction of detrimental tendencies such as duplication of efforts and loss of direction is essential for the slightest success to be achieved. A myopic approach to achieving any of the objectives will basically result in a group of individuals wandering away from the organizational targets. As a result, it calls for explicit control at all levels of business, encompassing the system development life-cycle, application life-cycle management, and all business processes.
ITIL
The dawn of this concept has had major implications on information systems management. Revolutionizing the skill with its elaborate set of practices, it is concerned with the development of a customer service oriented system. Basically, it is perceived as being skewed towards the development part of the process. With this perspective in mind, the dawn of DevOps signaled the departure from ITIL. The misconception has played a large role in downplaying the effectiveness of the agenda, presenting a dilemma to individuals, who consider it as an irrefutable invention.
Shortcomings of Configuration Management
A brainchild of the ITIL movement is configuration management, which has been another avenue for the improvement of information technology management. CMDBs have been instrumental in the creation of a seamless means of storing data on relationships and interconnections between configuration items across all levels. Facilitating rapid response to faults and failures, easier compliance auditing, and effective change management have resulted from these capabilities. However, the rapidly advancing developments in data management, heralded by cloud technology, are bound to make the CMDB redundant. This is because of a host of reasons, which include the following:
- The creation of an entirely new class of data as a result of virtualization, accompanied with increasingly new interrelationships between configuration items. Individual unit testing for infrastructure will therefore become increasingly difficult.
- The rate of creation of new information is too fast. At some point in time, innovative platforms such as Puppet and Chef will be rendered ineffective, as data creation rates increase.
- The rapidly changing information environment (at a rate faster than the CMDB capacity). The necessity of an updated database will become increasingly difficult to meet, and configuration drift will become a tough nut to crack.
- The relatively limited scope of operation of configuration management will lead to its subsequent irrelevance, with the advent of other vital statistics such as Infrastructure and Application Performance.
With subsequent upward spirals in the utility of information, storage of entire upgrade histories, financial information, performance profiles, and configuration data in one repository is definitely not the cleverest of strategies. Indeed, IT is in a state of constant evolution, with information in a constant state of change. Application Life-cycle Management (ALM) is increasingly becoming a leaner and more rapid process, and as such, failure of the Configuration Management Database (CMDB) to keep abreast with the mercurial environment will spell disaster for any organization.
Inadequate Automation
The marriage of development and organization calls for increased interaction between the two factions. It stresses the importance of an automated development system, underpinned on the weaknesses of human errors and inadequacies. With this in mind, software such as UpGuard, that allows for situation specific testing is preferred to basic applications. UpGuard also accommodates collaboration between all sectors involved, making testing a responsibility of all stakeholders. The effects of this turn up in the form of robust, yet adaptable and elegant systems.
The environment is in constant evolution, with the capacity of data exponentially increasing. Presently, the systems available may seem adequate, if not perfect, for the situation. However, they are every bit as susceptible to change, just like all other systems, and efforts should be placed on attempts to be at a vantage point when changes come knocking. It is safe to say that these novel ideas, packed to the brim with efficiencies and good will be considered archaic in the imminent future. Be prepared to say goodbye to DevOps and CMDB, as they are sure to be abandoned in favor of new and improved counterparts in the face of a future IT revolution.
Follow UpGuard on Twitter.
