DevOps Q&A with Kevin Parker

This is an interview with Kevin Parker (@kevinparkerusa) about DevOps

How do you see agile affecting application development and delivery?
The biggest impact is that application development teams are using agile to speed up their delivery of software changes and updates. This makes the developers happy as they can get through requests faster. However, releasing that software out to the organisation is different: small teams are responsible for their own releases, while larger organisations have dedicated staff that handle getting software out to the business.

Whatever size you are, the increasing number of releases will have an impact on the overall process. One customer I spoke to recently has taken up agile, and gone from 50 releases per year up to 350. That is a huge increase. While the amount of code might be smaller, the change procedure will be the same, and that puts pressure on the overall application delivery process and the staff who release the software. This introduces the risk of there being undiscovered errors in the release. And that might mean production outages.

There is a very good reason why developers should care about release management: delivery of software that works is how the business judges that application development has been successful. If that release goes poorly, then the users will complain and the perception of IT will be affected.

Release management is key going forward. Automating this process should save you time as well as ensuring that all the good work that your application development function does is recognised.

How do you see web applications changing, and development for these environments changing as well?
More and more applications are shifting over to being web-based services, simply because this makes them available wherever users happen to be. For application delivery, this does make them more complicated, as the number of moving parts that are involved in getting data across to a user goes up. Web-based applications have numerous layers of technology that are highly interdependent and this leads to complex configuration management issues.

For developers, getting their applications updated when they cross over many different architectures, technologies, methodologies and geographies means that they have to be conscious of how all these interactions work. This means that testing, auditing and tracking changes is becoming more important, because if a service goes down, it can be more difficult to find where that problem came from during the development process.

Web applications need to be developed using agile methods and we must invest in looking at continuous improvement throughout the application delivery function. Because services have to be available online all the time, downtime becomes a more difficult issue to manage. At the same time, releases are coming through more frequently. This will pull application delivery and release management in two directions and needs to be managed in conversation with the business.

What does the future hold for DevOps?
Web services are hosted within businesses on many different servers – physical or virtualised – or can be put into the cloud. So there will be potentially more platforms to think about within the organisation – everything from Windows and Linux servers, through to mainframes and cloud-based services as well as handheld and embedded software on other devices. For operations, changes in these environments represent opportunities for things to go wrong, and managing these risk events is a big issue for them.

To reduce the impact of this, automating release management can help. Getting software updates deployed across these new platforms, irrespective of what that platform happens to be, is the main aim for both developers and operations. Instead of having this completed manually, automating the job stops errors creeping in.

The gap between developers and operations – DevOps – represents an opportunity for things to go wrong if the processes that should be followed are not clear. Getting the right workflow in place is therefore an essential part of planning application development going forward. Bringing developers and operations staff together to discuss the whole process is a good first step to solving the problems that can exist.

How will this affect the operations side as well?
I think the biggest issue will be one of collaboration – rather than being adversaries on either side of the gap, dev and ops should be seen as part of the whole route that application development and delivery has to take. Having this wider overview of the processes that should be in place can help both sides to see that they are being more productive.

This collaboration should come as part of the wider business process that exists around application delivery. For the business owners that are involved in requesting new applications or updates to existing software assets, being able to see where their requests are in the process is very useful to them. Converting what is going on in the world of software delivery into tangible business benefit is where I see the world of DevOps going in future.

For developers looking at managing applications across their life-cycle, DevOps represents an opportunity to get more of an insight into what the business really wants from them. As timescales are coming down for software projects to be delivered, this will be essential.

The other area that will change around this is how developers and operations integrate into IT service management. ITSM involves how the organisation runs its processes and manages delivery of IT services out to users. For most companies, their view of ITSM begins and ends at the service desk, but it actually covers much more than that. In the future, there will be greater collaboration around the provisioning of resources to support a service across operations and the business unit, particularly as these applications become hosted on virtual servers or in the cloud. For developers, knowing that this level of flexibility and management is needed will have an impact both on how they put their applications together, and how they include that ability to scale to meet requirements.