Welcome to the second episode of the DevHops Podcast! This week we’re speaking with analyst Mike Kavis, and Skytap Galactic Head of product marketing Jason English. Let’s get started—we hope you enjoy the show!
Noel: Hello everyone and welcome to the second episode of the Skytap DevHops podcast. This is the show where ideas about enterprise software development flow freely. I am your moderator and host Noel Wurst, the editor in chief of the Skytap blog, our in-house journalist, and the person behind most of our social media presence online.
Before we get started I should point out that all of the ideas expressed on this show are those of myself and our guests and not necessarily that of Skytap as a whole.
Today we are excited to have Mike Kavis, VP and principal architect for Cloud Technology Partners, as well as an analyst and blogger at Forbes and DevOps.com. Mike is the author of Architecting the Cloud: Design Decisions for Cloud Computing Service Models.
Mike’s also served in a number of technical roles such as CTO, chief architect, and VP positions with over 25 years of experience in software development and architecture, and is a pioneer in cloud computing, as well as the former CTO of the startup M-Dot Network which won the 2010 Amazon AWS Global Startup Challenge. Thanks for joining us today Mike.
Mike: Man, that’s a lot of stuff.
Noel: It was!
Mike: It just means I’ve been around for too long.
Noel: Ha! Also joining us this week again is our own galactic head of Product Marketing, Jason English. Jason is a software industry veteran, blogger, commentator, and the co-author of Service Virtualization: Reality is Overrated. He was formerly the VP of marketing and employee number three at ITKO, and he ran the DevOps agenda when that firm was acquired by CA.
Jason also has additional experience in supply chain software, interactive agencies, and game design, and is up for any new paradigm, beer, or music that he can experiment with. Jason, how are you?
Jason: I am excellent, Noel.
Noel: Good. Speaking of experimenting with beer we are doing that today and we’ll try to do so on most of these episodes when we’re recording them at a reasonable beer drinking hour. Jason was smart enough to name this podcast the “DevHops” Podcast, which we believed would give us the freedom to enjoy a tasty beverage while we record these. I have a bottle of Old Rasputin Imperial Stout; it comes from North Coast Brewing Company. I know it’s been around for a while and is quite well-known, but this is the first time I’ll be having it, so I’m excited about that.
Mike and Jason, what is in your glass?
Jason: I have an Old Chub Nitro from Oscar Blues brewery in Colorado. The nitro adds an extra amount of bubbliness to this ale that just you can’t duplicate.
Mike: I have an Irish Red from a dear friend of mine Greg Rapp who was actually the architect of that solution on the Amazon challenge. I think he got so sick of ones and zeros he started making beers and now he has Rapp Brewing Company down here in south Florida with about 21
beers on tap. He’s an old German guy, makes an incredible beer, so I’m an Irish Red guy.
Noel: Very cool. Everyone listening, stick around toward the end of the show as we make our way through these bottles, we’ll give a review of what each of us were drinking today. If there’s ever a beer that you’d love to hear our opinion of send us some or just drop us a line on Twitter and recommend something that we might enjoy.
I think that those who are listening would probably like for us to get started so let’s do just that.
Mike, with you being the guest, if you would give us your quick definition of DevOps. Then Jason, if you’ll let Mike know whether that interpretation falls in line with how you see it, or let him know how different yours is.
Mike: DevOps is about as well defined as big data and Internet of things and cloud computing. It means a lot of things to a lot of people.
I like to put it in the context of, it’s a movement or a way of delivering software that focuses on collaboration and it results of quality, reliability, and speed to market. Traditionally, agile has been all about speed to market, but it’s usually at the expense of things like architecture, and operations, and security. It’s like, “build code and get it out of the door.”
DevOps tries to fix all that, and basically deliver what the customer wants at high quality, high reliability.
Jason: Yeah, that’s definitely very close to how I would look at it. I always look at it as basically a journey toward industrialization of the software development delivery process.
I look at it from the old supply chain terms of, “how can we continually improve the process and have these checks and balances and how people collaborate into push better quality out of the door with more efficiency all the time.” Everybody has their own definition but I think they’re pretty close.
Mike: Yeah, so right now I’m seeing on Twitter, biz DevOps, security DevOps, this DevOps and I kind of throw up in my mouth when I hear those things. Because it’s about all of that, right?
Jason: Right.
Mike: It’s not someone thought, “Hey, we did something with security so now we created this new thing called sector DevOps.” I’m like, “Oh, okay, whatever.”
Noel: Do you think that some of that confusing nature makes it almost leave a bad taste in people’s mouths like you were just saying, like you all the sudden you’re hearing these other versions of it already springing up. One thing that Jason brought up was a lot of times it’s the vendors that have been responsible for trying to promote these concepts as something that can just be solved with a tool or in some out of the box solution.
Mike: Yeah, that’s part of it. Another part of it is I deal mostly with large enterprises and their world is a lot different than a lot of the web companies who’ve really mastered this stuff. They’re already negative.
They’re like, “That’s great, but this isn’t in that bridge or this isn’t for that company or this company,” because they’re mired in mainframes and old SAP systems and 26 versions of this and that, so a lot of them are know there’s no silver bullet, so they’re just negative in general because their world is a tough place.
Jason: I mean I think a lot of that creates the skepticism. Vendors basically trying to take ownership of something or saying they have a tool, and that’s software companies as well as service providers saying that they have the ultimate process for delivering DevOps, and it’s just not going to happen that easily, so that’s why especially bigger companies that have legacy apps, they just have a jaundiced eye for a new term and you can’t blame them.
Noel: Do you think another issue is like you were saying, Jason, as far as connecting it back at these other approaches around all the automotive industry and electronics and consumer goods. Do you think that the fact that it’s being related to something like that, which if you haven’t been developing software that way, it might be really hard to grasp how you could take something from the 80s and 90s which are now 30 almost 40 years ago and then connect it to something as innovative as software.
It’s really hard to make that connection, that something that old could still be relevant and really effective today?
Jason: Right, well it’s hard to tell basically technology geniuses, that they’re actually way behind the curve. They are in the aspect of DevOps if you look at it from the point of view of what we’ve already done with supply chain optimization or other industries where they have this total quality control, it runs through the whole process.
People who make software they think, “Well, we’re inventing this stuff,” and it’s too esoteric to apply some kind of industrial process to it. I mean this is software.” It’s really, it’s a lack of discipline that gives us that opinion that we can get away with basically knowing what the right end-solution is without actually validating these things and collaborating with how it’s going to get delivered into production.
I mean that’s basically how I think this is occurring. A lot of people think, “Well, software is way too important to do the same things as an automotive company would do,” when really it’s behind in a lot of ways.
For more on how efficient software development and DevOps closely resembles the automotive and industrial industries, check out Jason English’s review of The Phoenix Project (or read the book yourself, it’s fantastic!)
Noel: Mike, Are there any industries or companies where you go in, or Jason, where you’ve looked at a specific industry, where based on whatever existing cultures or arrangements they have where DevOps is maybe not what they need right now?
Mike: If there’s a culture that’s resistant to change, and they’re not doing anything near agile—it’s going to be a challenge. It’s going to be hard. I had a discussion with a client the other day and they outsource all the development, so really what they do is manage systems and they’re arguing, “Oh DevOps is not for us.” My point is I have seen mainframe companies take a DevOps approach.
The challenge is people sometimes associate DevOps with “deploy 10 times a day.” How many times you deploy has nothing to do with it. It’s really about being iterative, being fast, proving overall customer experience, all those things. As long as you’re not defining DevOps as, “I need to deploy all the time,” there’s really no reason why it can’t be used.
Now the flipside of that is if someone is in a waterfall or even an agile shop is not “doing” DevOps and they’re having success, real good success, then don’t change.
Jason: Yeah, that’s a good idea. I mean why try to fix something that isn’t broken is one part of the model. I think a lot of it has to do with the management’s attitude toward the development and operations themselves.
If there’s a mentality where they’re going to share some responsibility and ownership in making these changes happen as opposed to basically not being partners in that process.
I think, Mike, you would probably have more examples of this. But it’s basically it’s from the top down there has to be some kind of incentive that they establish, and a willingness to join in the result join the responsibility for the outcomes of that improvement.
Mike: I’d seen some success when it’s not top down but it doesn’t scale, right? A team or two will have broad success, but it doesn’t translate into company-wide. If you want it company-wide it definitely has to be top down. Then you’re talking about HR involved as well, as you mentioned, incentives, change in behavior, training programs, hiring, all that type of stuff.
Noel: Do you think that this is more of a situation, and It may just be that it’s equal, but do you think it’s more of a situation where you need the business executives to think more like technologists and looking at it from that perspective? Or is it more your technologists, your devs who need to start looking at the situation more like the business executives?
If it is fairly equal, and both sides need to do the same, is there one side that either of you have seen as harder to convince, or maybe it is a little more slow going and adopting that new mindset?
Mike: That’s an interesting question. When we say a business needs to think I think they need to understand the process, and appreciate the process, and share some ownership of the end deliverables.
For example, I always preach to customers that the product owner needs to own things like quality and reliability. Because what I’ve seen in my entire life, and I joke around and I’m five foot five, I’d say, “I used to be six foot five when I started in IT and now I’m beaten down to five foot five.”
But the product owners have always been incented to shove features out, and that, as far as quality that was QA’s responsibility, and security was a security-gauged responsibly, so they could get you all that if it doesn’t work.
What will happen is the architects will raise all these IT tasks at the forefront that we need to do but the product owners say, “I’ve got to deliver features” but they’d never get done because they don’t own it. From the business side, we’re delivering services now, service is always on.
Part of the requirements for a service are now technical requirements. It has to run right. It can’t just be delivered, it has to run, it has to run good, it has to have quality and reliability. So there has to be shared accountability. The product owners have to have some of those IT metrics.
On a flip side the business really needs to understand the customer and the customer experience and the business problem. Too often, the IT side is all about the tools. They spend all this time doing all this magical stuff with tools and the customer is sitting there saying, “Well what about our feature.” It’s kind of both.
Jason: Yeah, I mean sometimes it seems like we’re dealing with what I used to call, “the sins of our agile fathers.” It’s basically where you have this idea, and it’s a great idea, the whole agile development methodology, but if you’re convinced that developers already know everything that they need to know about how the software should work, then that’s where we run into trouble.
We need a lot more awareness in the technology shop of, “Am I delivering something that’s going to add value to the end product?” That’s how requirements are prioritized. The more you can improve on that side, the more you can report back to the business side and at least give them some predictability as to what they’re going to get.
Mike: The other thing I’d add there is another big piece of being iterative. This isn’t necessarily DevOps. This is part of agile as well, but the old model is I’m going to give you a bunch of requirements and we’re not done until they’re all delivered. That’s why there’s always delays. We get 90% of it is done but we don’t get the last 10% done, so we start cramming stuff and taking shortcuts.
Both business and IT need to get in this mindset that we’re going to take our best effort to deliver these many user stories, but when it comes to the end of our sprint, we’re going to have some of them done, maybe more, maybe less, but we’re going to have something done that’s deliverable.
That could be daily. It could be weekly. It could be biweekly, whatever your iteration is. But we’ve got to get away from, “you have to have everything done” to building this trust around, “we’re going to get something of value done each time.”
Sometimes it will be more than you want, sometimes less, but we’ll get it the next time. Keep progressing to that as opposed to having work that’s done, but siting on the shelf waiting for more work.
Noel: Let’s assume that a company has decided that DevOps is right for them. Mike, maybe they call you in. They’ve got the support from the top down executive level. What’s a next move for them as far as who owns it, who takes charge, you’re going to hire or make someone a DevOps engineer—how do you get that ball rolling?
Mike: I usually start with what problem you’re trying to solve, because sometimes DevOps to them means, “I’m using Chef”, and sometimes it means, “I’m doing continuous integration”, and sometimes it just means, “I’m a DevOps engineer.” What does that mean?
We actually had a customer call us and say, “We want DevOps.” When we went in there and started asking the why question, what they really wanted was, “how do we become a SaaS company?” That’s a lot bigger question than how do we become DevOps. To me, the first step is, “what problem are you trying to solve?” and then we go from there.
Noel: As far as making someone into a DevOps engineer or building a DevOps team, is that something that … I mean again I guess it depends on who’s already there, but does that usually require having to add headcount, because I can see where there would be maybe a hesitation?
Or should there be people who can again be shown the business value if they’re a technical person or vice versa and start to build up that, “hey this is a great way to start thinking and to start working”?
Mike: I’ve seen it both ways. There’s one large financial institution that we’re working with that’s very top down and they’re building a very extensive internal DevOps certification.
A lot of people sneeze at the word certification, but they’re bringing in people and training them basically on agile, on organizational change management, on security in the cloud, I mean through the whole gamut and getting people through that.
So, they’re not so much building a team. Or at lot of the times, what’s happening is people are building what I call “platform teams, “so they’re putting a bunch of engineers around their cloud and they’re building guardrails around the cloud.
For example, one client is using, I won’t name, but a certain private cloud technology. But they just don’t want everyone to go willy-nilly on it, so they create a platform team who’s putting standard, secure blueprints on it and creating higher level APIs so the developers can just build on top of it.
They have another team that’s building the whole CICD pipeline and they’re saying, “If you’re going to use our cloud, you’re going to use this pipeline.” That’s where I don’t usually see that type leadership. Usually it’s more grassroots where there’s a team that’s been playing with all these tools and are trying to take it to the next level.
It’s a depends answer. It depends on the organization. Sometimes they need people from the outside because they’re just too set in their ways. Sometimes it’s a mix. Some companies are aggressively trying to grow the talent inside because they feel it’s a competitive advantage.
Jason: Yeah, obviously you’re not going to go on the street and find somebody who’s been doing DevOps for 5 or 10 years in their resume.
Mike: Although those resumes are out there.
Jason: Oh, I’m sure they are. I’m sure they do all that stuff in IOT and whatever other buzzwords fit in there. That’s part of it.
You have to come to terms with who you are. If you’re a company that hasn’t really promoted that and looked for that in the past you can try to cultivate it from within, but you might have to bring in a different type of manager or team for that sort of activity.
Part of the challenge is also how much do you centralize or control the environment in which they work? This is where Skytap is always interested, because we talk about DevOps environments.
But if you have this very centralized idea of control, that this is going to be your specific environment, and provisioning is controlled by a very central group, and the processes are done in a slow way, through a trouble ticket system and it takes weeks…then that’s going to obviously hinder everybody’s ability to become more agile if they’re not getting what they need, and the resources they need either.
Mike: That’s a good point. I’ve seen in a lot of engagements where there’s a development team who’s done a fantastic job of turning requirements around and having code ready to go to production within a day or two.
They have an operations team that has done a great job of creating standard blueprints and thy’re able to provision environments with a push of a button, but it all sits there and waits for this ticket to get blessed and go through the rubber stamp CAB review every Thursday. Sometimes they miss that Thursday and have to go to next Thursday. It’s like all this is for naught.
What people forget is when they’re transforming they have to transform operations. They get into big philosophical debates on Twitter whether ITIL is good or not. I’ve actually worked with companies who make ITIL agile. That’s kind of our tagline.
We go in there and modernize their processes and make things so certain use cases things can be auto-approved and certain information is flowing through logs and monitoring solutions, so everything is not a rubber stamp, wait a week for approval, but people seem to forget the operation side of it sometimes.
Noel: I don’t think we can get through the entire podcast without mentioning “cloud” at all. Mike, surprisingly you’re actually the only one who’s even said the word cloud. Jason and I have somehow managed to not even mention it.
Do you think that it’s the level of comfort within the enterprise with public cloud resources, do you think that as that comfort is increasing and fears about security are maybe decreasing slightly, do you think that has assisted or enabled DevOps to succeed as much as it has at this point, the fact that cloud is something that enables these kinds of deliverables that DevOps brings?
Mike: I don’t know if it’s just public cloud, it’s just cloud in general. There’s a lot of lifting and shifting going on where you lift your app and move over, but there’s a lot of new greenfield or modernization, and it’s requiring us to rethink how we build applications.
While we’re doing that, let’s take advantage of things like DevOps. I think because there’s this expectation that IT can now deliver so much faster because we’d have the cloud, and we don’t have to do all this IT plumbing stuff that it opens the door for us to explore new methodologies. Maybe in the past we’d been working on the same system for 15 years and we’re like, “yeah screw it, I’m just going to keep doing this.”
Jason: Yeah, that’s certainly a point. I think it’s because we’re used to having cloud come into our everyday lives. So many of the services we depend on appear in some cloud based form, and I think companies become more comfortable with it overtime, whereas they might have said that’s just something we don’t do here, like four years ago.
Mike: The challenges, especially with mobile, and with everybody being an Internet company, now you have to have a website, you have to have a mobile app. As soon as you’re doing web and mobile, that stuff has to change by design.
Customers expect that stuff to be fresh. We’re no longer just doing back office apps and recycling them every 6 to 12 months. The world has changed for us and we need to deliver much more faster, so this is driving it.
I also heard someone say a week or two ago, which I thought was a really good point, is nobody wants to go work at a place anymore where it takes six months to get infrastructure. I mean there’s so many companies that are starting to do this right that the companies that stay the old way, how are they going to attract and retain the best talent?
Why would I want to work where it takes me six months to get a server. I can go over here and I can crank out stuff. That was a very eye opening lightbulb moment when I heard and it’s very true.
Jason: Especially for technical people who want to innovate—I’ve heard that a lot, too. They say, “Why did you come here?” “Well, at my last job it started turning into a thing where I tried to get the infrastructure done for this. It took three months, and I just do threw up my hands because I can make the same money somewhere else.”
Noel: Well, that is everything that I had for today, but we did promise a beer recap. I just finished my first Old Rasputin Russian Imperial Stout and I can say that it was almost dangerously easy to drink. I didn’t even realize it was gone. But it was quite enjoyable. Jason, how was your Oscar Blues Old Chub?
Jason: Old Chub Nitro, basically it’s the big version of the Old Chub and it’s got the nitro inside it, so it’s got a much heavier, creamier taste to it. It’s almost like chocolate milk, like when you get a really good Guinness. It’s really weird but it’s great.
Noel: That sounds awesome. Mike how was the Rapps?
Mike: Well I’ve been talking the whole time so I’m going to chug my beer now, but if you’re ever down in the Florida Seminole, St. Pete area go to Rapp Brewing Company. There’s a huge microbrewery scene down here. It’s been written in lots of magazines. Check it out. They’ve got twenty-something beers on tap. Amazing, amazing stuff.
Noel: Cool. That is about all for today’s edition of DevHops brought to you by Skytap. If you enjoyed this content please let us know on Twitter, subscribe to the Skytap blog or subscribe to the Skytap DevHops Podcast on SoundCloud.
Mike anywhere you want to suggest that readers follow you?
Mike: Yeah, I write on Forbes, but go to cloudtp.com which is where I work with Cloud Technology Partners. We have tremendous amount of content. There’s Dave Linthicum there and myself. We have webcasts, podcasts, blogs, a lot of good stuff there, and a weekly summary of all that stuff.
Jason: Thanks Mike, really appreciate it. It’s great talking to you again.
Noel: That is it folks. Keep your head in the clouds and your DevOps fresh. I’m Noel Wurst for Skytap.
