Bridget Kromhout - An Orientation to the Latest in Operations

Andre Pino: You're listening to DevOps Radio, the podcast series that dives into what it takes to successfully develop, deliver, and deploy software in today's ever-changing business environment.This show is sponsored by CloudBees, the Enterprise Jenkins company and continuous delivery leader. Well, welcome, everyone. Today we're joined with Bridget Kromhout, principal technologist at Pivotal. Bridget, welcome.

Bridget Kromhout: Hi, Andre. Thank you. I'm glad to be here.

Andre: Bridget, in your role at Pivotal I know you hit the conference circuit pretty hard. Have you been anywhere interesting lately?

Bridget: I have actually. I just spoke at Agile India in Bangalore and the week before that I spoke at Scale Conf in Cape Town. So it's been a little of long haul flights lately. I'm looking forward to some U.S. base conferences coming up soon though. I think actually Saturday I leave for London. I have DevOps Days London and then Craft Conf in Budapest before I'm on the conference circuit for the U.S. for the summer.

Andre: Racking up those miles, huh?

Bridget: Well, what do they say? Frequent flier miles are basically gamification of poor life choices or something like that.

Andre: There you go. There you go.

Bridget: Airline status. It's a game you play and try to convince yourself that all those hours in coach were a good idea.

Andre: It's a self-fulfilling prophecy, isn't it? Now this isn't your first time on a podcast by any means. In fact, you're the co-host of Arrested DevOps, right?

Bridget: I am. I am indeed. We actually recorded an episode yesterday that was it was kind of like this. It was just one of us, myself speaking with Catherine Daniels from Etsy, who I'm sure since we're talking about dev ops here you're aware that Catherine Daniels and Jennifer Davis are writing a book, Effective DevOps, for O'Reilly Media. So we were talking about that and talking about speaking at conferences. But yeah. Co-hosting a podcast is a lot of fun.

Andre: Awesome.

Bridget: It's always a treat to guest on one and not have to prep the agenda.

Andre: Well, there you go. So you're well-known in the ops community. I have to ask, how did you get to where you are today and why are you so passionate about operations?

Bridget: Well, back to the possibly questionable life choices. My dad is a physician and I remember thinking as a kid, "Note to self, don't become a doctor." "You get paged in the middle of the night a lot." Fast forward to, "Oh dear, I went into ops," and I got paged in the middle of the night a lot. And after spending enough time being sort of miserable and cynical as one usually is in ops, getting to a place where with DevOps collaboration and improved tooling I and other ops people can be so much happier makes me really passionate about making unhappy ops people much happier or at least less sad.

Andre: I love it. So DevOps is all about happiness, right?

Bridget: I do think that the idea of cooperation and collaboration does lead to a lot better results in terms of just how you feel about your job and how you perform in your job. And of course we've seen from the DevOps survey of practice that Nicole _____, _____ et cetera work on that the companies that are using DevOps tools and practices also achieve better results on their bottom line. So there's some actual science there.

Andre: There absolutely is. In fact, I think that one of the things that DevOps does bring to the table is it does make for a happier developers and operations people especially on the operations side when they don't have to get paged in the middle of the night.

Bridget: Absolutely. That idea of being paged in the middle of the night really when I was on call, which by the way I'm not on call now. I'd like to say I spent 1999 until August 2015 on call for production infrastructure, which is probably long enough, at least long enough to know that you definitely want those alerts to be actionable when they wake you up. When I was on call I spent a lot of time trying to make sure that if something did wake me up it was something I could actually fix and it was something that actually required my attention then and not in the morning. So again, moving towards practices between your teams and also tooling that make that a lot easier is really key.

Andre: Yeah. It's really cool. So I know you're well, in your role at Pivotal what exciting things are happening there with respect to Dev Ops?

Bridget: So much excitement. So I think one of the things that I really didn't see coming into it and I've been really excited about and the possibility and the actuality of going in and talking to a lot of large organizations with a lot of legacy and a lot of challenges. And maybe people with their entrenched _____ who really don't want somebody else treading on their power structure, their territory. So if you bring in this kind of IT transformation what's gonna happen to me, fill in the blank? And going in and being as part of a trusted partner, helping those organizations figure out what direction they wanna go and what way our consulting and tools can help them go that direction, maybe working with our partners, CloudBees, et cetera, just the amount of trust that people place in you when they're looking for advice and they're in a lot of pain and the ability to actually be able to help them and see them, see their faces light up and see and realize that there is a way forward that they're gonna have so much better results. It's really fulfilling.

Andre: I agree. We see that at a lot of the continuous delivery summits that we do around the world. There's so much people are so eager to understand how they can move along that path of evolution towards DevOps and understanding not only the technology involved, but also the process aspects and the people and cultural aspects as well. So totally agree with you. So Bridget DevOps there's a lot of definitions of DevOps and a lot of meanings of DevOps. What I see quite often is DevOps gets equated with the term "operations" and not necessarily with DevOps in terms of the collaboration between Dev and Ops. What are your thoughts on that?

Bridget: I think it's definitely an antipattern to just do a search and replace of Ops with DevOps and now you've modernized your operations team. That isn't really gonna get you the results that you're looking for. Some people also add a DevOps team. Oh, a new silo in between the Dev and the Ops. That doesn't necessarily solve things either. I think that if you look inside an organization if you look at DevOps as the cultural practice of collaboration and cooperation and sharing and yes, better tool and automation in order to make that possible between the teams and not necessarily even just Dev and Ops. Funny story, when Patrick Debois and Andrew Clay Shafer started talking about Agile Systems Administration at the Agile _____ Conference in 2008 it was actually Shafer proposed I don't know if you've heard this story. But Shafer proposed a birds of a feather session for Agile System Administration and then didn't even go to it himself because he figured nobody would show up. Patrick Debois was the only person who showed up, had to go track Andrew down later and talk to him about it. Went home to Belgium and that turned in that idea of "Let's have a conference around this," turned into DevOps days, the first DevOps days was held in Ghent, Belgium in 2009. When asked, "Why did you call it DevOps Days instead of the Agile Systems Administration conference or something" Patrick just said, "Well, Agile Systems Administration was just too long for a conference name." It's really that simple. It's not, "This is restricted to only Dev and Ops." It's about this is about modernizing our practices and our interactions with each other, examining them, looking at where we can improve them of course using an agile approach, using iterative improvement, but using that across your whole organization. At DevOps Days in Minneapolis for 2016 we have a speaker, Megan Carney, from Yelp who's an info security engineer who's gonna be talking about security cooperating across the organization. And we have Sarah Goff-Dupont from Atlassian who's in marketing, who's gonna be talking about how your marketing department can of course be a great DevOps ally you didn't even know you had. So I think that restricting it just to this is Ops and this is how Ops people can learn to use source control kind of leaves out a lot of the story.

Andre: It sort of takes away from the full picture of what DevOps is trying to achieve for sure. We hear a lot about organizations that are struggling to adopt DevOps. From the people you talk to why do you think it's so difficult for the Dev and the Ops teams to actually start working together?

Bridget: I think the working together part isn't even necessarily as difficult as the working inside your organization to make changes that you might not even realize that you need to make. For example, if you have a very heavy weight change control process or a very heavy weight deployment process that requires all sorts of hand-offs and sign-offs and 18 hour conference calls and it has to happen on the weekend at 3:00 in the morning, et cetera, et cetera. If you don't give yourself permission to change those processes then even saying, "Oh, we wanna have CI, we wanna have CD, we wanna have IT transformation," isn't necessarily gonna get you there if you're still trying to cling to all of your old ways of doing things. Now of course there can sometimes be people, who because of the way their incentives are structured or the way the personalities work out in their org, there may be people who are the prime proponents of doing things the way we've always done them. But sometimes it's just the organizational inertia. For example, I was recently on a podcast with Matt Curry of All State. He's been at All State about a year doing Cloud stuff there but he was at PayPal for about eight years before that doing infrastructure scaling. So he has a lot of experience in this space. Going into All State when they started doing IT transformation working with Pivot actually, he said that they needed leadership in the form of their CTO Andy Zitney, who had to say, "Hey, those of you who are using this new platform, you do not need to go through the release process that we were doing in the past. You can actually use your CICD pipeline and push things out on the platform without going through the old checklist." And if you have that kind of buy-in from leadership I think it makes it a lot more possible to have the teams that need to work together, work together and move past the entrenched way of doing things because we've always done them this way TM that a lot of organizations with some legacy get trapped in.

Andre: So that's really interesting, that tops down approach. Are you what are you seeing across the board? Are you seeing mostly bottoms up approaches towards DevOps or are you seeing more and more tops down approaches?

Bridget: I'm not sure that I could generalize and say that there's one way that more places are doing it. I think it's more that you tend to see in organizations more success if you have some champions of the ideas scattered throughout the organization. Say for example, if you look at Target, Target has Heather McMann and Ross Clinton from Target who are located here in Minneapolis have spoken a number of times now. I think they first spoke at DevOps Days in Minneapolis in 2014 about this, but then they've also taken it to the DevOps enterprise summit and some other places and talking about how they started this DevOps movement inside Target very much a bottoms up endeavor and got champions throughout and had little pockets and got it spreading throughout the org. When they got the executive level support and buy-in it really made a difference to be able to meet their goals because an individual can say on their own, "I wanna collaborate. I wanna cooperate." Maybe a couple of individuals can start cooperating on the side or whatever. But what you can get if you just have a few people who want some kind of change whatever it might be, but they don't have widespread support throughout line of business or any kind of leadership what you end up with, as you're probably well aware, is those developers with the Jenkins server under their desk. But it has nothing to do with their actual delivery pipeline to production. That's kind of the antipattern we're trying to avoid. We want to make it possible for getting the other teams who are part of the blockers or the enablers to get stuff out to prod. You want those other teams on board so that say when you you're making CICD decisions you don't end up with just those little pockets of resistance. It's necessary. It not sufficient.

Andre: So for any CIO's that might be listening your suggestion would be what?

Bridget: For people in the C suite I think it's really valuable for them to listen to things like this or read things that come out of analysts. There's a lot of analysts who are writing stuff about this that's very succinct, digestible, and will give them pretty good perspective. Not just the big ones that they've heard of, Forester Gartner, whatever. Even stuff coming out of 451 or Red Monk they're going to see some insights that they might not have otherwise seen. But this idea that I would say the thing that I want the C suite to really take away from this is DevOps is not something you can buy. So you can't work with your vendor partner and implement some DevOps that you're gonna have delivered on this date and you'll definitely have eight units of it and when you turn it up you will have DevOps. That's not actually the way it works. So if somebody is selling you a package that comes with some sort of DevOps enablement or tooling that will aid your DevOps or whatever you still have to, inside your organization, make the commitment to decide to change and advocate for change and implement the changes. So that decision those decisions coming from and being supported by the C suite I think are really important.

Andre: That's a really good point. So the transition or transformation to a DevOps organization is really a journey. It's not a one step that you do that gets you there. What are some of the common pitfalls that you've seen organizations make in their journey?

Bridget: I think one common pitfall is when an organization says, "This person or this team is in charge of the DevOps." There was actually a funny screen cap tweet, whatever, that went out from Etsy a couple of years ago and they're of course well-known for all their DevOpsing even though they don't Cloud and they don't container, but they have an awful lot of metrics and cooperation. And somebody had e-mailed someone inside of their company asking who was in charge of DevOps and the answer that came back was, "We're all in charge of DevOps." So that idea of you can't just pick somebody and say, "This person is gonna make sure all the cooperation happens," because by definition the rest of the groups have to buy into the cooperation too. So while somebody can be leading the charge they can't have sole responsibility for it. Everyone has to it's kind of like diversity and inclusion. You don't have success with that if you hire someone to be in charge with it and then you leave it at that. Everybody does have to buy in. So I would say that's one thing that people run into sometimes.

Andre: It's got to be a group mindset.

Bridget: Right. It doesn't mean everyone has to agree before you can start, but it does mean that you need to start building that consensus before you're going to see much success just because in practice the human beings who have to go to work every day and work with each other need to actually want to work with each other and need to actually wanna work with each other in the new patterns or with the new tools that you're trying to promote. So I would say another problem is so the DevOps team or the person in charge of DevOps is sort of a problem that some people fall into, a lot of people I think are realizing that it's more nuance than that. Another one is the we've put DevOps on our Q2 agenda and we're going to fully implement DevOps by the end of Q3 and we'll have our DevOps measurables and deliverables and then we'll definitely see our DevOps ROI. Again while there definitely is an ROI, there's a measurable impact from, for example, of being able to react and add features or fix bugs faster than your competitors. That's measurable in your bottom line or if you're not a profit motivated organization it's measurable by your outcomes and the reaction from your stakeholders. But orgs that want to examine DevOps like they would some of their other their DevOps transformation or their DevOps efforts, orgs that wanna examine that and put it on their balance sheet the same way that they would any other I don't know move to virtualization or whatever. The move to virtualization didn't necessarily require the exact same amount of emotional heavy lifting in the form of people having to adjust to their jobs changing completely. Some of it, yes, but not quite as much as this does. So I would say trying to boil it down to dollars and cents too much is a little bit of a problem. Then I would say the third major antipattern that I've seen would be the people assuming that it's a tool they can buy. So after they go and they buy the DevOps tool that they've heard of whether it's that tool that has some pipelines 'cause those are a thing that people like or that tool that has some containers cause I've heard that container ships that tip over are a meme that are on the Internet a lot. Somebody who sees something and goes I don't know. There was an old Dilbert cartoon from a million years ago that said "What color would you like that database? Oh, I think mauve has the most ram." And that's how Dilbert figures out the manager has no idea what's going on with databases. I think of that sometimes.

Andre: That's really interesting. So within the world of DevOps technologies like container technology and automation technology like Jencons along with platforms of service technology seem to be really pushing the adoption along. What do you think of the combination of those three technologies for organizations that are looking to adopt a DevOps transformation?

Bridget: So you cut out a little bit right at the beginning of that. So I heard platform as a service and continuous integration. What was the other one?

Andre: I was asking about Docker and Jenkins and platform as a service.

Bridget: Sure. Absolutely. So I think that I've said before and I'll definitely say again, one of the things that Docker really did right was it's 2013 and they suddenly make containers accessible to pretty much everyone for an increasingly large subset of everyone because containerization is obviously not new, but it's also been pretty difficult to use if you're not super steeped and free BSD, _____, or Salaris zones or whatever. So the fact that Docker really made containers API driven, very developer accessible, you don't have to be a colonel wizard, et cetera. LXC was great, but it was, "Hey, if you're a Google engineer and you really understand C groups and name spaces dig in." But for the average developer it wasn't something they were gonna use. And so while Docker of course has a vast echo system of stuff that's going on with a lot of interesting fast moving parts, I would say the standard container format and them deciding to open source run C and have that be a standard with the OCI and whatnot, that was last year that was key. I think of all of the great things they did last your I would say that's the one that makes the biggest difference in terms of the container ecosystem because when you want people to adopt stuff like you would like people to all start using CIDC and putting their workloads into a platform when your average enterprise looks at what appears to be a completely fragmented ecosystem with pretty much no hope of them figuring out how to implement anything that's gonna be even remotely future proof, that tends to be a dissuading factor. Like maybe we'll just wait another quarter or three until this shakes out. So Docker deciding to say, "We're gonna have run CB the standard. We're gonna have the open container initiative, et cetera," that was a really good choice because I think containers are definitely useful, definitely the way to go, and having the Docker container format be basically the PDF of the container world, this is just a standard we're all gonna use it, means that if people would like to use an unopinionated or an opinionated platform of all the various sorts and there's you don't need me to run through them for you. There's a lot of different choices out there for the assemble your own from components all the way up to something as opinionated as Cloud Foundry. But for someone to be able to bring container as workload and run it in that I think is pretty powerful because it gives people a lot of flexibility about their choices. I also think containers work super well with Jenkins and with your CICD pipeline in general. At my last gig we had all of our builds and all of our tasks happen in containers and we didn't have to worry about something on the Jenkins server affecting something else in terms of builds or whatever. Actually at one point there was a very unfortunate assembling related accident that led to one of my co-workers blowing away a Jenkins home directory which would have been disastrous under many circumstances, but given that we had all the _____ backed up and we had all of our builds just launching containers it was a lot easier to recover from.

Andre: And your point about container technology really empowering developers is one that we're actually seeing and is being born out by the fact that whenever we do a webinar that talks about Jenkins and container technology and Docker specifically our numbers are through the roof. It's just crazy the interest that there is amongst the developer and DevOps community with Docker and Jenkins together.

Bridget: Well, I think people realize that they want to be able to do reproducible builds and they want to be able to do reproducible tests and they wanna be able to create version deployable artifacts and they can do all of these things through their CICD pipeline if they're using containers. If they're not using containers it becomes a lot more difficult. This is somewhat orthogonal to the question of exactly what platform you're gonna run your workloads on. So from a Pivotal opinionated Cloud Foundry point of view of course we think that Cloud Foundry is an ideal place to run many of your workloads, but you have to have the workload in the first place, right? You have to create that artifact. So having your CI system be able to create something that's going to be out there in your blab star, going to be in your artifact repository and gonna be something that's versioned with a build identifier is super powerful.

Andre: Extremely. I know that Docker is one of your specialties. I believe that you helped organize some of the local Docker meet-ups. Is that correct?

Bridget: Well, I've spoken at the Minneapolis Docker meet-up a couple of times. I actually organized the DevOps meet-up and the folks who organize the Docker meet-up that's happened here a couple of times we've I think we _____ with the Cloud Foundry meet-up once. It's one of those things where that's a newer meet-up in town, but I don't help organize that one specifically. I do enjoy speaking at Docker meet-ups especially when I'm gonna talk about Docker with Jenkins, Docker with our build system that we were doing with Drama Fever or run your Docker images on Cloud Foundry. Kind of taking it beyond just, "Here's some Docker." "Okay. Well, once you've Dockered all the Dockers what do you do next?" I like letting people think about the possibilities.

Andre: Interesting. So I think we get a pretty good idea that in your role in Pivotal you do get out a lot and speak a lot at conferences. Are you working on in any other projects at Pivotal right now that you could share with folks?

Bridget: Let's see. Well, I can tell you that I'm working on putting together a tutorial that I'm gonna be running at OSCON about Bosch. For that's the infrastructure automation layer of Cloud Foundry that you don't have to just use a Cloud Foundry. You can use it with all sorts of other things. It's basically for managing the life cycle of distributed systems. So I'm working on putting that tutorial together. I am also the lead organizer for DevOps Days Minneapolis. So we just as you alluded to, we were just putting together our slate of speakers for that. But yeah. The Pivotal specific stuff, some of it is to be announced and some of it is just related to, for example, working on stuff with the Cloud Foundry Foundation. I was just e-mailing earlier today with Stormy, who's in charge of community for the foundation, about some stuff that we're doing around Cloud Foundry Summer in Santa Clara later this year. Then Pivotal of course has platform coming up, the spring one platform conference August 1 through 4 in Las Vegas is gonna be all about the spring and Cloud Foundry and just all things Pivotal. So I'm involved with that conference as well. Then of course it's somewhat tangential my involvement with Pivotal, but I'm on the program committee for Velocity. So we're reviewing talks for Velocity New York right now. Of course Velocity Santa Clara is almost upon us.

Andre: Awesome.

Bridget: I have a talk that I've been giving lately called "Containers will not Fix your Broken Culture and Other Hard Truths." And I'm giving that at Craft Conf in Budapest in a couple of weeks again. I gave it already a few times. And I need to give a short version of that as a key note at Velocity Santa Clara. So I think one of the fun challenges when speaking in this space is trying to distill down your message into something that doesn't have a whole bunch of parentheticals in the sides, which I specialize in.

Andre: Well, I bet from the title it really draws huge crowds.

Bridget: Well, you know. Like you said when you put the word "containers" on something people get very excited.

Andre: There you go. So speaking of technologies are you seeing any other trends in the industry that you'd like to talk about?

Bridget: I think that people are pretty interested in, but not necessarily using Una Kernel so far. But there's also a rising tide of the idea of serverless computing, which I would say is sort of a misnomer. It's sort of like no Ops. There's Ops, they just might not work at your company. It's like serverless, there's servers, you might just be using _____ or whatever. And there's also stuff in spring that let you do this, just kind of the one-off task sort of thing. I think that that's pretty interesting. There's also there's a lot of container orchestration mud wrestling going on that Pivotal doesn't really get into necessarily, but of course I have a lot of friends in the space. So I see a lot of stuff going on like the my friends over at Joinent just launched their container pilot 1.0. So that's just yet another container orchestrator. It's like there's I feel like that's a very full field but also very fast moving and a lot of interesting stuff in it.

Andre: I couldn't agree with you more. I think the explosive growth of Docker as a container technology has spawned a lot of new companies with ideas about how they can improve and streamline the container rollout for organizations.

Bridget: Yeah. That's one of those things where again, the Pivotal party line is you can spend a lot of time assembling something that orchestrates and runs all of those containers for you. You probably wanna focus on your actual differentiating business value. So we encourage you to use more opinionated platforms so that instead of spending a lot of time building a platform, which I've totally done I built a Docker based platform with my former co-workers at Drama Fever. That was a lot of fun. It was also a lot of human hours went into building a platform. So you have to decide is this the best way for our company to differentiate ourselves and to get value out of our work? If it is, then super. Do that. If building out may be your customer facing apps is where you wanna put a lot of your talent then do that.

Andre: Exactly. Don't waste time on the nonvalue at layers of technology, right?

Bridget: Absolutely. I don't know if you've seen the value line diagram that was being tweeted around that James Waters came up with, but it kind of has under the value line you've got all the stuff like how exactly you launch the containers and above the value line you have the actual software your customers are interacting with. So you have to decide where that value line is for you.

Andre: Exactly. So I see you had a lot of success with a fun card game that you launched called DevOps Against Humanity. It really went viral. How did that happen?

Bridget: Oh my goodness. That was so funny. So that was a couple of years ago right before Monte Rama, which if you're not familiar with Monte Rama I think the conference might actually even be sold out for this year. You can go to the website and live vicariously. It's an artisanal _____ Portland base conference on monitoring, single track, 600 people, 3 days of monitoring. But right before I went to Monte Rama I thought it would be fun because I had tweeted out a link to just an open Google spreadsheet with 40 white cards and 40 black cards based off of cards against humanity only actually funny cause I don't find celebrities and bodily fluid jokes really that funny 'cause I'm not 12. But just the idea of the CEO with ____ access or my LinkedIn endorsements include it's like _____ of Slash or whatever. Don't try this at home, kids. So I had tweeted out this link and people had filled it in with a bunch of funny ideas and I thought it would be I found a generator that would generate the cards and you could print them. So I generated some cards and took them to the local print shop, printed them, brought them home, cut them up, and I recommend having a print shop cut them, by the way. Using their giant cutting saw device to do it is really a pain. So I brought them all home. This was like the night before I'm packing for Monte Rama and I just tweeted a picture of them thinking, "This will be funny." Then I went to go back and didn't look at the Internet for a few hours. I came back and oh, I figured out that you need to turn off Twitter notifications after that. I had so many e-mails. So yeah. It was people were very excited. So I had to put all of the source materials up on GitHub before I left for Monte Rama or people just would have been they were a little distraught to not have them. Of course a lot of people wanted it to be kickstarted or whatever. I was like, "Creative comments, attribution, noncommercial. That's the license the cards against humanity is under. That's the license I'm redistributing under. You go ahead and print whatever you want. I'm not getting in the business of card production." "This is what GitHub is for."

Andre: There you go. And it's so funny the way some of these things that you put out sometimes take off and you don't even think about it in those terms.

Bridget: Yeah. I printed them 'cause I thought it would be fun to play a couple of rounds of this game with my friends. And I did not realize that the entire Internet wanted them.

Andre: There you go. Off it goes. Well, Bridget, thanks so much. Is there anything you'd like to say to our audience as we close today?

Bridget: Just thank you for having me. Super fun to talk to DevOps Radio. You can definitely find me on the Internets. I am fortunate or unfortunate enough to have a Google unique name. So I am the only Bridget Kromhout. So I'm pretty easy for you to find. I'd be happy to chat with you on Twitter or you can listen to Arrested DevOps or take a look at my upcoming speaking page. I will be speaking probably, depending on your geographic distribution will be speaking at a conference near you sometimes in the next few months.

Andre: That's awesome. Thanks so much, Bridget. We enjoyed have you today. I really enjoyed the conversation.

Bridget: Thanks, Andre.

Andre: Bye-bye. Like what you've heard today? Don't miss out on our next episode. Subscribe to DevOps Radio on iTunes or visit our website at CloudBees.com. For more updates on DevOps Radio and industry buzz follow CloudBees on Twitter, Facebook, and LinkedIn.