As a longtime proponent of continuous delivery and fast deployment schedules, Shridhar Mittal has advocated for DevOps operational patterns since before the DevOps moniker was even coined. It was a philosophy that stemmed from what he and his colleagues at what was then Interactive TKO saw happening in response to the service-oriented architecture movement: many organizations were slowing down their releases as opposed speeding them up, which was the whole “promise” of SOA, he says.
“So we started a whole company around how do you change your development processes to get speed with quality in this new world of distributed architectures,” he explains.
Since iTKO’s acquisition by CA Technologies in 2011, Mittal has used his current role as general manager of application delivery at the company to focus his efforts on evangelizing DevOps cultural shifts within the enterprise. He believes that DevOps is on the brink of revolutionizing the way IT departments function and in addition to his anecdotal evidence from frequent talks with IT leaders, he points to a recent survey CA conducted together with IDG for evidence. According to technology decision-makers, while only 7 percent of organizations have already adopted DevOps practices with enterprise-wide scope, it is gaining traction. Another 39 percent report that they’ve either implemented DevOps principles with limited scope or are in the process of adopting DevOps. And another 28 percent are either planning on implementing or are evaluating DevOps.
staging-devopsy.kinsta.cloud recently spoke with Mittal to discuss the mainstream uptake of DevOps, the biggest transition challenges and the attitudes about IT job performance in a new era of cooperation.
staging-devopsy.kinsta.cloud: Why do you believe that DevOps is gaining so much traction today?
Mittal: I think the whole promise of DevOps is around better customer experience. Better quality for the customer, but in a much, much faster way than you could do it before. To me, that is ultimate goal.
Ever since the whole consumerization of IT, everyone uses the web and everyone uses mobile devices, and there is no buffer in between the application and the end consumer now. Previously to that you used to have, in the call center, you had people who are using applications and the consumer never actually interacted with the application.
So if it sucked, its internal people that had to deal with that–it wasn’t the consumer. Now, you cannot afford to have your customers have a bad experience because then you are going to lose business. One of our case studies is the .com part of a very large company–one of the Fortune 100. They had done a study that showed that for every one second delay in the response in the website dropped the conversion rate of sending someone to the next step of purchasing. It dropped significantly for every second.
Think about it. If you’re doing a big marketing event, you’re sending hundreds of thousands of people to your website, and just because your website doesn’t respond properly, you lose that many more potential customers.
That’s the kind of value that we’re talking about right now. Take a simple example, say there’s the launch of a phone and the telecomm company wants to release it at the same time the manufacturer is releasing it and the systems are not connected in time. They would end up losing hundreds of millions if not billions of dollars of business because they didn’t release it at the same time, and one of the competitors actually released on time.
These are the kinds of the hundreds of millions worth of value we’re talking about. In the past, people thought about it as, maybe if I can get three percent or four percent more efficiency I can save x numbers of millions. But what I think they’ll really be looking for now is the ability to grow their business much faster.
staging-devopsy.kinsta.cloud: How can organizations start meeting the challenge of transitioning to DevOps?
Mittal: Start small and then build up to the big There are at least three different on-ramps we talk about to get to DevOps. One is, just start with the development side of the word and decouple the development teams from each other so that they can do their things faster and still be able to deliver things on a higher quality. That’s using things like server virtualization and API testing. The second on-ramp is just improving your environment management, the release management capability. People today are spending tens or hundreds of man-hours creating and maintaining these environments then tearing them down and then bringing them up again.
So figure out how automate that process where you can take so many man-days of work and bring it down to something that can be handled by one person and can be done as a self-service in a matter of minutes as opposed to taking days weeks or months to happen.
And then the third on-ramp is to put more automated testing processes in place, for instances doing performance testing. Trying to do it in-house today is becoming more and more difficult because there’s never enough infrastructure internally to be able to handle simulating these tens of thousands and hundreds of thousands of people coming to your web site. It’s just not possible. So figure out ways to leverage cloud-based automated testing capabilities to support that.
There are many different on-ramps and people can start from one or another and then start building to much bigger things. Start small and eventually expand to put it across the enterprise.
It is also important to get the trust built between developers and operations through better visibility. The classic scenario is, the developers just want to write code, release it, then they want to go back to writing code again. Operations want to slow things down because all they care about is a stable environment. If I could get devs to have visibility and ownership and be measured on how the products are actually behaving in production and, same thing with ops, if I could give them visibility to what’s in the pipeline, what’s coming out, why is this coming out, what is the business case and how this impacts your business, they’ll all start feeling an ownership for the whole process.
staging-devopsy.kinsta.cloud: That brings up an important question: how critical is it to change job performance metrics in both development and operations in order to make DevOps work?
Mittal: I think it’s very important. I think it’s not something that has to be done from the get-go but I think somewhere after you have done the first couple of projects and some of the people have started buying into DevOps, that’s when you have to fundamentally change the culture of the company. In my mind, that’s contracted behavior—and it’s not because people are coin-operated.
I’m not saying this in a bad way. To me, people look at the way they’re comped as a way of understanding what their direction is. What are they being asked to do?
So if they are not getting measured on quality, to them, that means “Just make sure that you just get things out as fast as possible and then if you have to roll back, then you have to roll back.” And if you’re not getting measured on constant speed, then that’s like being told by the executives that, “All I want you to do is have a stable environment; I don’t care as much about getting new stuff out there.”
So there has to be changes in the comp structure, how people are rewarded, to really change the culture of a company.
staging-devopsy.kinsta.cloud: What other things need to be done on the line-of-business executive leadership side of the house to make DevOps work?
Mittal: I think that the business side needs to be the driver to a large extent, because the business needs to say why something is important. If supply of IT capabilities is much less than demand, that means there has to be some kind of prioritization of work. And who’s making that determination? Who is doing the prioritization? To me, without a business context, you can’t be doing direct prioritization.
I think the business has to be very involved in helping IT understand a prioritized list of what needs to get done. They don’t say how it needs to get done, they just need to say, “This is more important than this, and this is the impact to our business of that.”