There is a gap that exists between developers and operations in any enterprise dealing with complex and legacy system environments.
This schism more often than not causes conflict within an organization, with an inefficient flow of information being most culpable for this. It typically manifests itself as "knowledge gaps", or as worse repeated outages. Without dealing in platitudes, it always comes down to a single cause (from our experiences) — poor communication.
DevOps has arisen as a way to stem this issue, and when used in conjunction with continuous integration in development cycles, often fuses the lifecycle of Plan, Build, & Run together, into one seamless activity that cuts across the board.
Beginning your DevOps Transformation
The enhancement of DevOps has been proposed by individuals seeking to create and sustain ITIL implementations bordering on near perfection. This is because DevOps' main emphasis is on communication between the software developers and information technology, as well as the fostering the association between the two often opposing factions of the organization. The encouragement of collaboration responds to the obvious interdependence between development and operations, playing a large role in rapid production of products and services. It is not surprising that the approach is gaining popularity among software developers.
The ideas and concepts surrounding DevOps originated from the Agile Infrastructure Movement, and have been implemented at all levels of the Software Development Life Cycle. Its obvious success has led to its subsequent implementation in sister processes such as the Application Lifecycle Management. The fusion of DevOps and IT Infrastructure Library processes has had a remarkable impact on the software development process. It provides an all important means of evaluation, in the form of a blueprint based on measures, aptly named, Key Performance Indices. These have provided an ideal method of evaluating a system on all levels, from the design to the release and implementation phases. As a result, individual unit testing for infrastructure suitability, competence, and capability becomes a feasible undertaking.
A consequence of the ITIL's processes is the science of Configuration Management. This entails the application of a Configuration Management Database (CMDB), which is basically the core of the ITIL. It is billed as the single source of truth for all the information pertaining to the components of the information system in an organization.
The CMDB stores and manages software and information infrastructure, along with their associated dependencies and relationships.
It maps out a schema of the entire application and infrastructure for a company, and should provide unparalleled visibility of all components.
Unfortunately, more often than not, typical CMDB's are not as effective when it comes to maintenance. They are often left behind during change updates, are often bloated with information that is rarely used. More often than not, CMDB's are treated as static asset inventories of every possible item that "could" one day be important. Software vendors, realized this problem many years ago, and thus began the discovery wars: a push to automate the discovery of assets, their configurations, and have them automatically federate into this single source. Suddenly the CMDB was updated automatically, yet the sheer amount of information that a release or configuration manager had to sort through was tiresome, and again, the necessary view of picking and choosing which components were actually relevant became the norm.
For organizations attempting to introduce DevOps philosophies, integrating a SCM or DCVS tool can ease the integration of factional groups within an IT organization by simplifying change management to avoid service disruptions.
The process of error corrections/control and testing is repackaged into a simple procedure, with the added ability to precisely identify any defective components of the system, reducing repair time to a minimum.
The ramifications of this effect on the system efficiency are immensely advantageous. The implications for DevOps with this in mind are profoundly felt, particularly when dealing with legacy systems. Blueprinting a server with a configuration protection tool often reduces the condition broadly known as configuration drift.
The CMDB enables the analyst to examine all the data from the desired perspective, organizing the components into a clear and comprehensive layout. It enhances configuration management, with a view to controlling, specifying and working on configuration items and any effects to them in a systematic and detailed manner. The Information Technology Infrastructure Library doctrines document the specifications applied in this process, viewing the database as a vault of information on attributes, infrastructure, identities, relationships, and configuration states, emphasizing its role as its heart.
DevOps and Automation
The quest to providing a sustainable level of functionality is not an easy one. The implementation of a successful marriage between software development and operations entails the spending of considerable time and effort. This integration is plagued with unrivaled tedium, which could lead to inefficient implementation characterized by errors of various forms and effects. An error free system is every developer's desire, and as such, this end should be pursued at all costs. With this in mind, automation at all possible levels is key. It serves to create tests that are more complete, more detailed, and in perfect correlation with the DevOps doctrine of continuous improvement. Automation accommodates continuous integration and rapid iterations will increase agility in testing, in addition to increasing communication between teams.
Various platforms exist to support the DevOps agenda; from the architectural design, to the initial and release testing, and to the final rollout of system. Automation is a safeguard against the failure of a manually implemented system. Indeed, DevOps champions automation as part of its core mission. With this in mind, an examination of the various resources available is necessary.
DevOps and Puppet, Chef
Puppet is one of the household names when development of systems comes into perspective. The application of the declarative language plays a key role, extending beyond the coding and design of systems. The designers host various webinars and gatherings geared towards the enhancement of the language. This is in line with the DevOps agenda: fostering a collaborative culture between all technical teams. From this perspective, the achievement of other important aspects of the system, such as quality assurance, are achieved.
Another product of the open source movement is Chef, which is another ingenious tool with regard to configuration management. Chef will go a long way towards helping development teams overcome the shortcomings on their paths to the achievement of DevOps goals.
Another important addition to the automation process is UpGuard, which although being only acquirable by license, complements the DevOps movement perfectly. It is guaranteed to ensure compliance with audit standards, easing systems audits tremendously. It establishes a renowned means of testing, compatible with all systems, with all configurations possible, as well as a means to test the impacts of migrations. Moreover, it enables the relevant teams to define and run configuration tests with remarkable ease, and obtain detailed and standardized reports. Finally, UpGuard enables sharing and collaboration across teams which are in line with the DevOps agenda.
Indeed, the implementation of DevOps and the IT Infrastructure Library set of practices and procedures have had a great positive impact on how information is managed and presented to the community. The discovery of underlying inefficiencies in the initial processes has necessitated an overhaul of the inadequate procedures, which has led to the development of innovative strategies such as development operations integration.