However, a new ‘kid on the block’ is changing the way we approach the management and operation of our IT services, providing a more responsive and dynamic application environment and keeping our service managers awake at night. Mike Smith, CTO, Atos UK, reports.
What is DevOps anyway?
As the name suggests, DevOps is a combination of development and operations. It is a software development philosophy to encourage the communication, collaboration and integration between software developers and the operations environment. The objective of DevOps is to diminish the barriers between software development and IT operations; and it is used by organisations pursuing both continuous integration and continuous delivery.
We have seen many initiatives to increase efficiency, effectiveness and agility of organisations aimed at addressing the demand to reduce ‘time-to-market’ for applications and services. These initiatives include, for example, service-oriented architectures, industrialisation, software quality improvement, agile processes and lean, among others.
However, all of these initiatives are largely focused on the speed of development and most of them are the domain of the project team. They are instruments to assist in the development of applications, predictably and rapidly, and to eliminate errors and waste during the development process.
However, this is only half of the story. The application or new piece of functionality has to be made available to the users in production. This is where DevOps - managing code all the way into the production environment - makes the difference.
ITIL - from an operations perspective
The latest version the library (ITIL 2011 edition) has five volumes, of which volume four covers ‘operations’, describing the essential standard processes for efficiently managing IT services. However, it is actually volume three, service transition, where we see the most profound impact of DevOps - specifically in the areas of change management, release, deployment and monitoring.
In the well-managed and well-controlled IT environments we have experienced (and continue to experience) long release cycles; with perhaps just one or two major application releases per year. We store up a plethora of requirements and resulting changes. Then, in the landscape of development, test, pre-production, production, disaster recovery (and perhaps more) environments, we slowly test, prove and gradually roll out each release across the landscape over a period of time.
Change management and precise control over the configuration items help us understand the impact of what we are doing, and enable us to roll back in the event of an issue or manage situations using our other favourite processes from volume four - incident and problem management.
This managed release of new features is accompanied by planned service outages, something that IT has imposed on the business historically, but which is increasingly spurned.
We are also witnessing the development of a new paradigm in the IT services industry today: as customers seek to award smaller outsourcing contracts to multiple service providers we are seeing the emergence of service integration and management (SIAM), especially in the realm of UK government.
SIAM could be considered to be an evolution of ITIL in some respects; joining together the delivery of technology towers from different service providers, all managed and assured by a SIAM function that undertakes various ITIL processes (and more) across the whole landscape.
When worlds collide
The development process is focused on delivering new features faster; operations is focused on a manageable and stable production environment. During the development process, many concerns of different stakeholders are taken into account, but often the requirements of the operations stakeholder is forgotten.
One of the principles of DevOps is to involve operations in the development process and to involve developers in the operations environment. Or go even further, do away with the divide altogether and have a combined production team.
Joining these different roles and making both parties aware of their service focus and concerns lowers the barrier for dialogue. Developers will get to know the constraints of operations and are able to take into account these constraints during the development process.
And it goes further than that. When we discuss DevOps approaches we now also, from time to time, implement Kanban techniques to manage the workload of a continuous release train of small incremental changes, perhaps performing ten releases per day, delivering software and adding new features and functionality to address the demands of the business. This is a whole new way to deliver agility right into the production environment; exploiting automation technologies to give consistency, repeatability and efficiency.
Another area where we have a collision of these different types of management is when we have DevOps application deployments that are hosted on traditional shared hosting services. We need to marry the continuous and lightly-managed Kanban environment with the heavily ITIL change-managed network and hosting infrastructures.
In some ways the necessary rigidity of the network change environment will hamper the DevOps philosophy, so it may make more sense to move to a new type of software-defined architecture. Indeed some of the technologies that are enabling this new approach include software-defined-networks with OpenFlow, OpenStack and OpenShift.
Next Generation Service Management
Service management needs to evolve. The service manager (a role that may be executed by various roles in different organisations) is now not only responsible for the availability and performance of the production environment, but also for the development process and deliverables; not just reporting on availability and performance of a service against arbitrary KPIs (key performance indicators), but driving the rate of change and dexterity that is required to respond to business demands.
We can no longer rely on a monthly reporting regime and just attend a monthly service management meeting - it is a continuous interactive activity, marrying the daily demands of the business with the delivery of new functionality.
As with other agile development techniques a standard ‘waterfall’ approach is incompatible with DevOps and Kanban; we can’t just wrap old-world techniques around new approaches and expect them to work. The same applies to the typical CAB (change approval board), often held weekly on complex services or daily in busy environments.
This has to be replaced by automated testing, approval and release techniques. Hence most organisations will find themselves having to cope with a mixed DevOps and waterfall environment - at least for the next few years.
In such a dynamic environment product managers have their own preferences and these drive the development of any new piece of functionality. Quality assurance managers need to ensure functionality is not broken by new features, and special care needs to be taken to ensure configuration issues don’t affect other customers if there is a common code base.
The service desk, ticketing systems and service monitoring tools all rely on the information contained within a configuration management database (CMDB); if DevOps now begins to dynamically change the environment we need to ensure we capture this in the CMDB too.
We’re building the bridge
Using DevOps combined with open source tooling and GitHub repositories, can increase development agility all the way into production. Github, for the uninitiated, is a cloud-based software version control system with collaboration features, which helps to break down the barriers between the historically separate development (systems integration) and operations (managed services) organisations - and whilst there can be problems (we noted above that rapid development can lead to configuration management issues) the pros tend to outweigh the cons in the right circumstances and for the right services.
This DevOps approach also goes hand-in-hand with new dynamic infrastructures with automated provisioning for scalability - another transformation that we are seeing in the industry at the moment.
It’s an exciting time - what we’re doing right now is building the bridge between ITIL (and SIAM) and agile, maintaining control of the production environment whilst enabling the speed of delivery for new functionality, and therefore getting the best out of both worlds. I believe DevOps and ITIL will indeed become friends and we’ll see both playing together, though like all maturing friendships they’re bound to face a few hurdles along the way.
