In preparation for the upcoming DevOps Enterprise Summit in London, InfoQ sat down with Damon Edwards, co-founder at Rundeck, Inc, and discussed the benefits and implementation of "Self-Service Operations".
Edwards discussed that "Self-Service Operations" is all about enabling developers and operators to define operational procedures that can be provided "as a service" across an organisation. At first glance, the Self-Service Operations design pattern appears basic: operations tasks are made available to others as automated buttons or APIs. However, Self-Service Operations is actually a fundamental shift in how you think about automated procedures.
With Self-Service Operations, companies are dividing up the essential components of automation and shifting them to areas of the organization where labor capacity is best utilized and the organization can be the most agile.The ROI benefits of Self-Service Operations include: decrease in interrupts due to problematic or incorrect handoffs, decrease in time to market, and increase in organizational capacity.
Edwards concluded the interview by stating that although technical competence is vital, ultimately what really makes the difference between success and failure with Self-Service Operations and DevOps is always going to be the organizational change. The full transcript of the interview can be found below, and more details on the talk from Damon Edwards and John Willis, "Better, Faster, Cheaper: What Does it Mean for Ops?", can be found on the DevOps Enterprise Summit (DOES) London website.
InfoQ: Welcome to InfoQ, Damon! Could you share the executive summary for your DOES London 17 talk please, and what attendees can expect to take away from the session?
Damon Edwards: Last year, John Willis and I gave a talk called "Better, Faster, Cheaper: How?" about techniques used by high-performing companies to go faster with higher quality and lower costs. It was well received and DevOps.com even voted it the best DevOps presentation of the year.
So, of course we have to do a follow-up this year. This year we are drilling in to look at how these techniques are transforming Operations. John will be discussing how infrastructure is changing, specifically the transformative impact of containerization and immutable infrastructure design patterns. I will be discussing how Operations organizations are changing how they work and how they are structured. I'll be focusing in an interesting design pattern that is coming to be known as "Self-Service Operations".
InfoQ: In your experience, what's the biggest change an existing in-house enterprise sysadmin/ops team has to make to move to a "Self-Service Operations" way of working?
Edwards: At first glance, the Self-Service Operations design pattern seems fairly basic — you take operations tasks and make them available to others as automated buttons or APIs. However, If you look deeper, you'll see that there is more to it than that. Self-Service Operations is really a fundamental shift in how you think about automated procedures.
An automated procedure has three essential parts: the definition of the automated procedure, the ability to execute that automated procedure, and the control over the security/management policies governing that automated procedure. Traditionally, each of these parts seemed indivisible and lived within Operations (and often within the same team). With Self-Service Operations, companies are dividing up these essential parts and shifting them to areas of the organization where labor capacity is best utilized and the organization can be the most agile.
For example, in traditional organizations, it is almost heresy to suggest that Developers can define operational procedures then later Operations can vet it and give the ability to execute it back to the same Developers or to a different team. Self-Service Operations challenges that.
InfoQ: What type of metrics/KPIs should an organisation be tracking before and during any migration towards self-service operations? What is the 'one metric that matters' that indicates an organisation has been successful?
Edwards: If you want "one metric that matters" I'd recommend going with the classic DevOps metric of lead time. That could be leadtime in a delivery context or lead time in resolving an incident. Lead time is what matters to the business so stay focused on that above all.
However, beneath that, the ROI benefits of Self-Service Operations depend on where you sit in the organization. The ROI benefits to operational support teams include: decrease in time to respond to incidents, decrease in errors and rework, increase in total support volume the team can take on, decrease in waiting for response from escalations, and increase in operational support tasks that can be handled by other teams.
The ROI benefits to teams outside of operations support teams include: decrease in number of escalations, decrease in time waiting for operations tasks to be performed, decrease in interrupts due to problematic or incorrect handoffs. The ROI benefits at an organizational level include: decrease in total support costs, decrease in time to market, increase in organizational capacity.
InfoQ: What do self-service platforms like Rundeck provide over and above an operations team using an existing tool to trigger services/jobs, such as Jenkins or cron?
Edwards: Jenkins and cron are at two different ends of the spectrum so you need to consider them separately.
First, Jenkins and Rundeck work well together. In fact, Jenkins is one of the most popular integrations for Rundeck. Jenkins is a fundamentally a build tool designed for developers and build engineers. Rundeck is built from the ground up to be an orchestration and scheduling tool for operations. For example, the way Rundeck knows about your infrastructure, the ACL policies, the output formatting, and the scheduler features are all designed for the needs of enterprise operations.
Cron is a simple scheduling utility that runs on individual servers. Rundeck can be a centralized simple scheduler, but more often than not your scheduling needs are going to include things like workflows, error handling, notifications, access control, throttling, etc.. This is what is commonly considered "Enterprise Job Scheduling" or Enterprise Workload Automation". While it's common to hear about people using Rundeck to consolidate local schedulers like Cron, the more popular scheduler use of Rundeck is to replace legacy Enterprise Job Schedulers like Control-M, Autosys, Tidal, or UC4.
InfoQ: In summary, how relevant do you believe DevOps is to enterprise organisations looking to move faster? In your experience, what is more important in a typical enterprise space: the need for organisational change, or technological change?
Edwards: DevOps is extremely relevant. Enterprises are complex things and there is no silver bullet. You are going to need a variety of techniques to get things moving. The DevOps community is great because it contains a rich collection of practitioner-tested techniques. Simply take the lessons that the DevOps community has proven to work and apply them to your own company.
If you need a more formal definition, I can't recommend enough The Phoenix Project and its companion, The DevOps Handbook. As far as the question of organizational change versus technological change, they go hand-in-hand but ultimately what really makes the difference between success and failure is always going to be the organizational change. By organizational change I'm referring to how people see, organize around, and act on the work that needs to get done in order to deliver value to the business.
Tools can help to change behaviors, but, if you don't ultimately affect organizational change then you are just going to recreate the same old problems in your new tools. Focus primarily on the organizational change and the tools become easy. Focus primarily on the tools and you are going to have an uphill battle against the organizational issues.
InfoQ: Many thanks for your time today, Damon. Is there anything else you would like to share with InfoQ readers?
Edwards: Thank you for interviewing me. The only thing I would add is that if you work for an enterprise and have a technical leadership role — anything from team leader to senior executive — I think you would greatly benefit from the DevOps Enterprise Summit conferences. There is one in San Francisco and London each year. It's a great place to interact directly with your peers from some of the world's largest enterprises, as they openly and candidly discuss how they are identifying and solving their DevOps problems.
However, don't just take my word for it. Watch the videos from previous years if you have any doubt to the quality of the speakers and attendees.
The DevOps Enterprise Summit London conference runs June 5-6th at the QE II Conference Centre. Additional details can be found at the IT Revolution Events website.