The five-minute CIO: Randy Shoup, ex-Google and eBay DevOps director

30 Oct 201545 Shares

Share on FacebookTweet about this on TwitterShare on LinkedInShare on Google+Pin on PinterestShare on RedditEmail this to someone

Randy Shoup, CTO, Randy Shoup Consulting

Share on FacebookTweet about this on TwitterShare on LinkedInShare on Google+Pin on PinterestShare on RedditEmail this to someone

“DevOps isn’t just for unicorns. A lot of large enterprises like banks are moving swiftly in this direction,” explained Randy Shoup, former engineering director of DevOps at Google and chief architect at eBay.

DevOps is a mantra for product development in Silicon Valley but this fusion of software development, quality testing and operations when it comes to deploying web products and apps is spreading throughout the entire digital ecosystem.

Randy Shoup, former engineering director DevOps at Google and chief architect at eBay and currently CTO of Randy Shoup Consulting, was one of the forerunners of the DevOps revolution and last week was a keynote speaker at the ISACA Annual Conference.

Shoup believes DevOps is no longer just for internet unicorns. Today, many large enterprises are transitioning from the slow and siloed traditional IT approach to modern DevOps practices, and getting substantial improvements in agility, velocity, scalability and efficiency.

But he warns that this transition is not without its challenges and pitfalls.

DevOps seems like a luxury of big Silicon Valley companies. Is it filtering out to the general business landscape?

There are a ton of large enterprises from banks to insurance companies that are adopting a bunch of these practices. These are all big companies like Capital One, Bank of America, Target, ING, all these large traditional enterprises are adopting these practices. DevOps is not just unicorns.

Describe your journey to DevOps.

It was living it, honestly. I was at eBay for six-and-a-half years and eBay, despite being an e-commerce company, for most of the time operated as a traditional enterprise IT shop. And the contrast was there was this very siloed separation between the development side and the operational side. But when I went to Google, those teams worked very fluidly and closely together and that more than anything opened my eyes to what happens when you form teams that have end-to-end responsibility for the application and the service they are building.

To me, the organisational and cultural aspects are actually what’s most powerful and organisationally when we form teams there aren’t these silos that hand-off from dev, to quality to ops, but rather we have a single team that’s across all those disciplines that works end-to-end.

This is where things move so much faster and the quality goes up tremendously.

How does DevOps help with product development?

What you do when you create an end-to-end team is you give that team ownership. Rather than having a feature or an app where we divide ownership between people that write the code, the people that make sure it works correctly, the people who make sure it works quickly and the people that operate it day-to-day, we have now divided that responsibility and who is responsible, who owns the application?

The DevOps philosophy is you that put ownership of a product or service in one team and that team owns it end-to-end from design to development to deployment to retirement. The classic idea is the development team is done when they have finished writing the code. The modern approach is the development team is done when the service is retired.

Do DevOps teams stick together after a product is retired? Developers are like hen’s teeth, do they get consumed by the war for talent?

The answer is, it depends. Sometimes the team will stay together and work on something else and other times the right thing to do is to disperse the team and deploy resources against other priorities. I don’t think there is one right answer to that, but one key is we want a healthy ecosystem of services and applications and it’s not going to be static, there’s going to be ebb and flow and evolutionary approach where some ideas are going to work and some aren’t.

The other aspect to DevOps is that failure is not a problem. We should accept and expect and embrace when things don’t work and do it better the next time.

In the war for talent, how do you best deploy talented developers among DevOps teams and is DevOps driving the trend towards acquihiring of companies and their staff?

Globally, there is a huge premium on talented engineers, so interestingly to me team cohesion is just as important as the rock star levels of the individual engineers.

Just like in soccer, teams that have the individual players are great but you have the teams that play really well together and fluidly that’s a huge advantage as well. It’s less about dispensing these rock stars and more about finding teams that work well together and giving them interesting work to do.

It is hard to find that winning combination but when you do that’s when you want to keep them together. Part of the argument behind acqui-hiring is this team has been technically successful but maybe not market successful and keeping those individuals together and giving them the next set of challenges is a great way to use that talent.

There are individuals that are incredibly good but the success of a Google or an Amazon or Apple is less about the individuals and more about finding those teams that overall can be productive and successful.

I think in terms of acquisitions the overall hit rate is well below 50pc. Overall, where you would say ‘this was a successful acquisition’ was half the time, certainly that was the experience at eBay. More often than not it doesn’ t work out but when it does it is really huge.

With hardware entering the fray in a bigger way than before, things are going to get more complex. How do you see DevOps transforming to meet this new challenge?

The same principles can apply to developing mobile applications or even embedded devices. One of the main tricks is to reduce the cycle time, how often, how rapidly we can add features and release new code and that’s very hard when you are building a piece of silicon.

But the techniques that are starting to become widely used for embedded devices are to build a simulator and you release very rapidly and often to the simulator and then when you feel comfortable you send it to the lab and you burn silicon.

That is analogous to mobile devices, when you build an application for Apple or Google, it takes a while to be approved. Whereas a website can be updated hundreds of times a day. That is harder to do with a mobile device, but you still get a lot of the benefits of that rapid development by releasing locally to a simulator for rapid continuous delivery.

What are your predictions for the future of DevOps?

There are fewer and fewer places where the objections ‘I can’t do DevOps’ will fly.

We are seeing large enterprises doing these continuous deliveries in organisational and cultural practices.

We are seeing hardware companies do this stuff and several auto companies like Tesla and GM are great at this.

There are an amazing amount of companies where you wouldn’t have thought it was possible to do these practices that are moving seriously into DevOps.

Editor John Kennedy is an award-winning technology journalist.

editorial@siliconrepublic.com