In a previous blog I asked the question - Is DevOps the next ITIL? The short answer is no! Read on to understand my reasoning and join in the discussion.
Physical and virtual domains
Are we losing sight of the fact that the virtual world simply does not exist without real computers, real disks, real routers, and real data centres? The AWS storage outage was caused by a planned change that led to the virtual world coming to a standstill as EC2 instances sat waiting for storage services to respond. Better change planning, better impact analysis, more thought, more understanding, and more prudence was needed. In my view ITIL must own these types of changes. ITIL must own the physical IT domain. Where infrastructure and applications can be managed as code, then DevOps must own the changes. DevOps must own the virtual IT domain.
DevOps teams can deploy 100's or 1000's of code changes a day. With everything deployed as code then incremental change is not only possible, it is a key DevOps practice. Deploying 1000's of times a day, backed up by automated testing gives DevOps teams the confidence to deploy directly into production almost at will. DevOps practices embrace a philosophy of fail fast and fail small. Those implementing physical infrastructure change do not have that luxury.
Teams planning changes to physical infrastructure must take the time to think and plan. Physical infrastructure change is not done incrementally. You cannot rollout half a firewall rule. You cannot install half a host or the first port of a router. Due to the infrequency of changes to physical infrastructure, testing is difficult and unfortunately becomes an error prone manual process. An added complication is that physical infrastructure cannot be guaranteed the same between environments, resulting in very low confidence in any pre-production testing (if any was actually done).
Communication as notifications as communication
Clear lines of demarcation are needed and IT teams need to agree on them. They need to define clear rules, but with the flexibility to work as needed to get to the right outcome. For ITIL processes this means managing physical infrastructure incidents, changes and customer requests. For DevOps practices this means using and managing virtual application environments.
All teams need to recognise that the change process for physical infrastructure is not slow or bureaucratic, but a process to ensure that infrequent, high-risk changes are completed successfully. Conversely all teams need to recognise that DevOps practices are not reckless and unmanaged. They are designed to enable features and functionality to get into the hands of customers when they need it - even if that means every minute of the day!
These lines of demarcation do of course converge at certain points and those interfaces need to be well managed. The key to this is communication, and the world of communication is changing fast. In his blog "The end of apps as we know them", Paul Adams, CEO of Intercom makes the case that notifications will be the primary way of interacting with apps. In a world where notifications are full experiences in and of themselves, a screen of app icons makes less and less sense.
Many DevOps tools are very developer focused - think Jenkins for managing the Build Pipeline. It is the notification of errors and how they are fixed that communication as notifications becomes vital. DevOps teams use tools like Slack and Intercom to communicate and resolve issues directly from the notification tool (using so called "Slack Hacks"). The point here is to respond to errors generated by automated testing, and quickly (as a team) resolve the error and push new code to the Pipeline, all via a notification system. You will note there is no incident logged, no SLA monitoring and no knowledge capture.
Measure twice, cut once
This therefore leads to a potential pitfall of DevOps, and that is visibility of development requests and measuring development and deployment success. Deploying at speed is one thing, but who decides what functionality should actually be deployed? What individuals want isn't necessarily what is best for an organisation. It is conceivable that DevOps teams could be deploying code on the whim of business units with no coordination or direction.
This is where governance is needed, but not the sort that stifles. Any measurement has to be done with respect to the system it is measuring and in this case it needs to be fast and automated. Collecting the number of failed and successful deployments needs to be at or near real-time to make the best decisions. The time saved in the collection and analysing of metrics can be put into making better decisions on what requests should get into the Build Pipeline in the first place. In a classic Business Intelligence approach, data is collected and automatically transformed into information. Business Value Dashboards need to be considered to ensure governance provides better decisions and visibility in the DevOps domain. In this respect DevOps can learn much from ITIL.
DevOps and ITIL
Carrying on from my earlier blog - DevOps is not the next ITIL, as I hope you are by now convinced! They are both needed to manage new and existing IT infrastructure. IT teams using ITIL processes or DevOps practices need to respect each other and understand how they need to work effectively together, to achieve the shared goal for the customer. Above all else, IT teams need to understand and respect each other’s domain.
It may be that IT teams adopt some DevOps practices, where it makes sense, to improve service delivery of legacy solutions. For example, there could be opportunities to automate system access and terminations, or system APIs could be used to create automated test scripts for changes. This is of course only being done to improve customer experiences until the new DevOps high speed train goes live and everyone gets invited to the legacy steam train shut down party!