You have heard of the term DevOps before right? What exactly is it? It’s a buzzword, alright! But, why has it gained popularity in the past few years. What makes it special? You are about to find out in this post.
Now the Literal Meaning…
DevOps is a combination of two words – development and operations. When these two areas of IT are amalgamated, you literally get DevOps. There is a whole lot more to it than meets the eye!
DevOps is just not a nomenclature to refer to the development and the operations in a single vein. It is a change in organizational culture, transformation of processes, and leveraging on technology to speed up software development.
Let’s Dig Deeper
Software development activities and operational activities are seen as two sides of a coin – they cannot work together, yet, both are critical to software services. The areas of development and operations have a different set of priorities, which is fine, but, they often conflict when they are required to work together – say when a new software release is to be deployed. This conflict eventually affects the customer.
In today’s scheme of things, where everything has to be done as of yesterday, where speed is king, where time to market plays a pivotal role in making or breaking businesses’ successes, conflicts arising out of two parts of IT are no longer acceptable. Having two governing bodies, working with two unlike mindsets is proving difficult. So, there was a dire need to unify the two areas. Thus, DevOps was born, where the development and the operations were brought together, given a set of common objectives that puts delivering on the customer’s expectations as the focus.
The development team is tasked with bringing out new features and fix identified defects in software. All this to be done quickly, and in an agile manner. The operations teams are the sentries and guards for ensuring stability of the IT systems, including the software that is mounted on the infrastructure. Along with stability, they have to ensure that the IT services are available and are secure at all times.
You might ask – ‘it looks like the priorities are sorted out for each of the teams, why is there a conflict then?’
Let’s say that the software development team has prepared a new release package, and has handed it over to the operations for deployment. The production software version is a stable one, with a good amount of security and availability features on it. The operations team is wary of the new release, not certain how stable the new release would be. They are unsure how it impacts the availability and security aspects of the software as well. In other words, they don’t trust the development team to have conducted due diligence before promoting the release.
In a different scenario, the development teams require multiple environments for coding and perform various tests. These environments need to mimic the production environment to ensure that the software that works in the pre-production environments have a greater chance of working as expected in the production environment. The environment creation falls under the operations, and the development team are the consumers. Considering the timelines in the agile world, where sprints run between two and three weeks, environments have to be created fairly quickly. So, there is a dependence on the operations team to build environments as and when they need it. What the development teams don’t think about is whether the operations have sufficient staff available to carry out the environment provisioning activities. Operations might be engaged in major incidents or working on other deployments. The point being, there is no visibility for the development team on the operational activities, which leads to further conflicting situations.
In such situations, where there is trust deficit, the disconnect between the two teams leads to further probing, unnecessary delays, dilly-dallying and eventually, the business suffers. Of course, there are change management processes and change advisory boards, and the operations are stakeholders for all changes.
DevOps – the Solution
DevOps brings the two teams together. It creates synergy through collaboration. The practice aims to cut down the silos which is identified as one of the prime reasons for lack of communication, visibility and trust.
Bringing the two entities together, and asking them to work together is not as easy as it seems. It requires a change in the organizational culture, and organizational change management must be involved.
DevOps does not stop at the integration of Dev and Ops. The practice aims to automate repetitive activities across the software development and operations lifecycle. To automate, tools are needed, and hence the practice leverages heavily on technology wherever it can be applied.
Last but not the least, DevOps runs on processes. The project management and service management processes must be aligned, rejigged and transformed to fit the needs of the new ways of working. ITIL will still be relevant, but the aspects of the service provider, customer and other stakeholders will drastically change.
DevOps is a practice that is yet to be standardized. I doubt if it can be standardized at all like the way service management was standardized through ITIL. Every organization runs DevOps in a different way. Their principles vary depending on their software products, priorities and culture. This in my opinion makes it an interesting and evergreen prospect for years to come.
[…] organizations have started taking steps to do away with ITIL framework without due diligence from a DevOps […]