devopsy.kinsta.cloud

Category: Podcasts

DevOps Chat: DevOps Virtual Summit Preview w/ Dr. Nicole Forsgren, DORA

In this DevOps Chat episode our guest is DORA co-founder, Dr. Nicole Forsgren. Dr. Nicole talks to us about her upcoming appearance at the DevOps Virtual Summit on Tuesday, March 7th at 12:30PM EST.

Additionally, Dr. Forsgren gives us some news on upcoming activities and releases coming from the DORA team. It is always a pleasure speaking with Nicole and I am sure you will find this conversation useful and a good reason to hear her and Gene Kim at the DevOps Virtual Summit, along with several other former DevOps Chat guests!

In the meantime here is the streaming audio of our conversation. The written transcript will be available shortly.

Alan Shimel:                Hey, everyone, this is Alan Shimel, devopsy.kinsta.cloud, here for another DevOps Chat. Today’s guest is a special guest for our DevOps Chat, it’s Dr. Nicole Forsgren of DORA. Dr. Nicole, welcome to DevOps Chat.

Nicole Forsgren:         Thank you, and thanks so much for having me.

Alan Shimel:                Thank you. Nicole, we’re gonna talk a little bit about a Virtual Summit that you’re a part of, but before we do, I wanted to give our audience a little background on DORA. No, we’re not talking about the explorer, but it is—

Nicole Forsgren:         [Laughter] We do some exploring, though.

Alan Shimel:                – yes, you do, you do. But seriously, for people in our—and you know, we have kind of a worldwide audience, only 38 percent of our listeners are in the U.S., and there may be people out here who aren’t familiar with DORA. So why don’t you give them a quick background?

Nicole Forsgren:         Okay, sounds good. So, D ORA is a company that is myself, Nicole Forsgren, and Gene Kim, author of the famed Phoenix Project, and co-author of The Visible Ops Handbook and The DevOps Handbook, along with Jez Humble, co-author of The DevOps Handbook and Continuous Delivery and Lean Enterprise. And together, we are also the lead investigators and primary authors of the State of DevOps Reports going back a few years now—several years now.

So we have spent several years researching and understanding the key factors that drive excellence in software development and delivery across the industry, whether that’s, you know, the famed unicorns, but also enterprises. And so what DORA does is, we take everything that we’ve learned and everything that we know across our—you know, a decade each, really, so decades of understanding, and we help companies measure and assess and understand and drive improvement in their own technology transformations.

Alan Shimel:                Great. And, you know, so when I always hear the DORA story, Nicole, I am—I’m a child of the ’80s and the ‘70s before that, and I think of sort of a rock super band like Asia or something.

Nicole Forsgren:         [Laughter]

Alan Shimel:                You know? Where we’ve got all of these great kind of musicians coming together to make great music, and that is somewhat what DORA is, where we have three great—you know, three leaders of the DevOps community kinda joining heads. But it wasn’t just as you mentioned, it’s not just with the formation of DORA that you guys are doing this. I mean, there’s—I think it’s six years of the DevOps Survey kind of, or maybe this is the sixth year now, in the [Cross talk].

Nicole Forsgren:         Oh, so it’s—yeah, well, it’s four years since I’ve been involved, and then I think, like, rubbing science on things, right?

Alan Shimel:                Mm-hmm.

Nicole Forsgren:         And it’s been academically rigorous since that time. You know, it’s, the years of study have appeared in peer review, right? So we’ve got some fantastic data behind us. Gene and Jez have been involved, I think, five years, and then it goes back another year or two before that, right?

Alan Shimel:                Yeah.

Nicole Forsgren:         And then Gene and Jez have been studying the space, I think, going back a decade, right? And then I’ve been doing academic research in this space since ’07, so yeah, we’re going on at least a decade, each.

Alan Shimel:                Wow. That’s a lot of time kind of studying the subject matter and a lot of expertise in there. And I think that’s why, you know, personally, why I get excited to see what comes out of this, right, and what insights come out of the survey, of course. But DORA is more than just about conducting the survey, making sure it’s academically rigorous, making sure the numbers are, you know, bear witness to what they are, that they are, in fact, reliable and show things.

Nicole Forsgren:         Right.

Alan Shimel:                You’re actually taking that data and helping organizations as a result of the analysis of the data. So it’s not just analysis for analysis’ sake, it’s, how do you make your organization better by taking what we’ve learned?

Nicole Forsgren:         Right. Exactly. So we do have, you know, The State of DevOps Report that comes out every year, and we make that publicly available, we make that free. We partner up with the team at Puppet, right, and we do have a report that comes out free every year, and we’ve got an ROI white paper that’s gonna be coming out in the next few weeks. So we do everything we can to discover new information and make that free every year. But what DORA also does is, we have a product now that helps organizations measure where they are, benchmark where they are against the industry, understand what they should do, what levers they should turn to drive performance improvements and then prioritize those improvements and those capabilities so that they can really drive improvement most efficiently, and then track those improvements, so they can really see the value come out of that improvement.

I love it. It’s super exciting, it’s super fascinating, because like I said, we do this because we love it, and because we wanna make things better. You know, we wanna have an impact on the industry. We wanna see our peers, you know, get better. Who was it, I always forget who said this, but you know, survival isn’t mandatory. [Laughter]

Alan Shimel:                Yeah.

Nicole Forsgren:         You know what I mean? Companies—like, you don’t have to do this. You can die, right? You can fail. Companies can fail, but that’s not what we wanna see. It’s so enthralling and it’s so exciting to go to conferences like Velocity and DevOps Enterprise Summit and hear these amazing transformation stories and see what is possible. And to be able to help provide these insights—and really, that’s the genesis behind DORA. You know, we were sitting down—Jez and I, and Gene—we were sitting down and saying, “Every year, someone comes up to us, and dozens of people come up and they say, ‘Help me understand. The report’s come out, and we want to understand how to measure and how to benchmark, but what should I do? Help me understand what I should do next.’”

And it’s just, it’s so difficult to be able to say, “Well, the measures are out there,” but providing companies and organizations and teams with tooling that’s just going to be simple and easy and straightforward to use so that they can measure, they can benchmark, and then so they can prioritize and understand which levers they should be using to really optimize and maximize their investments and their improvements is really exciting, and really kind of fulfilling, honestly.

Alan Shimel:                Got it. Absolutely. So, Nicole, let us kind of pivot into talking about this Virtual Summit you guys have coming up. I think it’s next week.

Nicole Forsgren:         Yes! I’m so excited. It’s so fun

Alan Shimel:                So, go ahead. Tell our audience—I love it when you’re excited. Tell our audience about it.

Nicole Forsgren:         [Gasps] I nerd out so hard. I’ve got the best job.

Alan Shimel:                Uh huh.

Nicole Forsgren:         [Laughter]

Alan Shimel:                So this is, I wanna say it’s UVM, or maybe it’s not, I forget which—I know CA is a sponsor of it, but tell our audience about this Virtual Summit.

Nicole Forsgren:         So, you know what? I’m super excited about this. I think the Virtual Summit is fun because I know so many people that are like, “Ugh, I wanna go to these conferences, and I just, either I don’t have the budget” or most of the time, now, people just don’t have time, right? Going to conferences is tough because the travel is hard, taking a day off of work is hard. This Virtual Summit is fantastic, because you can log in, you can listen in, and you can hear from so many amazing, fantastic people, and you don’t have to leave, right? Even if you have budget, getting on a plane and leaving—like, it’s hard.

And the Virtual Summit is great, because CA has been able to line up so many fantastic people. Aruna did such a great job. I’m super excited. I’m excited, because I get to meet so many more people and hear all these fantastic transformation journeys.

Alan Shimel:                Yeah. I mean—

Nicole Forsgren:         I’m so excited.

Alan Shimel:                – that’s kinda what makes a lot of what we do, you know, the world go around, when we hear more and more companies—

Nicole Forsgren:         Yeah! This is why my job is the best! [Laughter]

Alan Shimel:                Yeah, I hear ya. I’m gonna bring up another thing, though, to you, Dr. Nicole, and that is this whole idea of kind of virtual summits, right? We saw it with the All Day DevOps event that a bunch of people put on last year.

Nicole Forsgren:         Uh huh.

Alan Shimel:                We’re seeing it now in this virtual thing. You know, for a long time—I don’t wanna be negative, but these virtual conferences just didn’t do it for me. But I think the technology’s gotten a lot better. I think the, you know, bandwidth and mobility and cloud and all of the things that help drive DevOps as well have led us to have better experiences in things like a virtual summit where you really can meet people, right? Even though you may not be in the room with them, it’s virtual.

Nicole Forsgren:         Right.

Alan Shimel:                But it’s really a great experience.

Nicole Forsgren:         Well, do you know what? I think it’s a combination of things. I think some of it’s the technology. Do you know what else I think it is? I think it’s also, like, the special magic sauce behind the DevOps community. It didn’t always work for me before, because the other communities just have a different underlying culture. DevOps is just a little bit different, right? I’ve been around tech forever, right? Before my Ph.D. I worked in hardware performance, where I, like, I’ve got a hardware patent, I—I worked in hardcore tech for a really long time. And those communities are, they just have a little bit different DNA.

DevOps is very, very different. And so for anyone who’s gonna tune into this summit—participate, pay attention, reach out. Add me on LinkedIn, right? Everybody say hi, wave—love you all. Add me on LinkedIn, add me on Twitter, follow me, send me a message. The thing I love about the DevOps community is that everyone is in it for the community. Everyone will reach out. So many people legitimately, honestly want to help everyone else get better. And it’s something that I just haven’t seen in very many other communities. It’s just so different.

Alan Shimel:                You know, I was—

Nicole Forsgren:         And I think that’s what makes so many of these virtual summits work so well.

Alan Shimel:                I agree with you. Nicole, I just saw you, I guess it was two weeks ago now or last week—no, it was two weeks ago at the RSA event—

Nicole Forsgren:         Oh, yeah, uh huh.

Alan Shimel:                – where we did our, you know, we did our Dev SecOps show there. And what was funny is, I got an e-mail from RSA—do you know there were 43,000 people at RSA this week?

Alan Shimel:                We—yeah.

Nicole Forsgren:         My word.

Alan Shimel:                We—that’s crazy.

Nicole Forsgren:         And I didn’t get sick—it’s amazing. [Laughter]

Alan Shimel:                Yeah! Well, I did, but—you know, we had about 900 people at the Dev SecOps event throughout the day on Monday, and then the cocktail party and all that. But what you said about the DevOps community so rang true for me. Even in this see of 43,000 lives out there, right, the DevOps people kinda gel. They were very into being together and sharing and talking. And it’s contagious to my security community friends, who, you know, they—I can’t tell you how, and I’ve been in security for 15 years—how many came over and they loved the vibe that we have in the DevOps team.

Nicole Forsgren:         Oh, yeah!

Alan Shimel:                And they wanna be part of it, and that’s very different, Nicole, than three to four years ago when I first started doing that at RSA conference, and it was very much a butting of heads, right?

So yeah, it is a testament. It’s a testament to, you know, we talk about culture all the time and a lot of people think we’re crazy, but it is a testament to that whole culture and vibe around the DevOps community.

So I’ve said my piece. I’ll step back off my soap box.

Nicole Forsgren:         [Laughter]

Alan Shimel:                So, Nicole, for people listening in on the Virtual Summit next week, I mean, Gene’s talking, obviously, I’m sure it’ll be interesting and he’ll give us some insight into some, maybe, new transformations he’s been studying and analysis. What do you—any previews of what you’re gonna talk about for our audience?

Nicole Forsgren:         So I’m gonna be talking about some of the trends that we see, some of the promising things that are coming up. Some of the big—the levers that you can turn that I think are exciting, I’ll be speaking to some of the things that Ops teams, you know, can really contribute that are important.

Alan Shimel:                Mm-hmm. Very cool.

Nicole Forsgren:         And honestly, I’m also—you know, I’m super excited to hear from some of the other speakers. I’m really excited to hear from Sylvia at United, Kelly at Jewelers Mutual, John at CNN—super excited for that.

Alan Shimel:                Yeah.

Nicole Forsgren:         Right? They’ve got such a great slate.

Alan Shimel:                They do, they have a nice slate and, you know, like you mentioned, Aruna from CA—I mean, CA has a great customer bench there.

Nicole Forsgren:         Oh, God. I tell you what, man, Aruna has so many fantastic insights. Anything she comes up with, I just love—super excited to hear what she has to say.

Alan Shimel:                She’s actually been a guest on our DevOps Chat regarding her book. So here’s—

Nicole Forsgren:         Yeah! So great.

Alan Shimel:                – between you and me, I always have a crush on Aruna, because I just, I really—I mean, she’s got it goin’ on, you know? She’s written her book, she’s an engineer, she’s done the business side, she’s full of energy, and I—you know, I just, I tell her all the time, man, if I had a daughter, I’d want her to grow up and be like her. Because she—

Nicole Forsgren:         I know. I have a serious intellectual crush on her. She is a mover and a shaker, man. She is doin’ some good stuff.

Alan Shimel:                Yeah, that’s good stuff. I’m really, really proud to call her a friend. Anyway—I’m really proud to call you a friend, though, too, because you’ve met my son, and I say, “You need to go talk to her. You wanna do statistics? There’s someone to grow up like.” But anyway.

Nicole Forsgren:         That’s right.

Alan Shimel:                Dr. Nicole, I’ll be listening, obviously. I hope our audience will be. We are all watching what DORA is doing, and I guess the new report—well, the survey’s closed now, right, so the new report is [Cross talk]?

Nicole Forsgren:         Yep. So stay tuned, the report will be coming out early June.

Alan Shimel:                Very cool. We’ll be looking forward to that. That’ll probably be around when DevOps Enterprise Summit is in London.

Nicole Forsgren:         Close. DOSE—oh yeah, DOSE London is June 5th and 6th. Also, DORA’s coming out with an ROI white paper and then summer, fall, me and the guys, Gene and Jez, are coming out with a book, summarizing all of the research that we’ve done.

Alan Shimel:                Ooh! You heard it here first.

Nicole Forsgren:         Including—yes—including things that did not fit in the book, surprises, and more on the science [Cross talk].

Alan Shimel:                Very cool. I’m looking forward to it. It’ll be an exciting summer.

Nicole Forsgren:         Thank you.

Alan Shimel:                I think we might be doing some book giveaways here. [Laughter] But until then—hey, check out Gene, Nicole, Aruna Ravichandran from CA and a bunch of other great practitioners at the DevOps Virtual Summit coming up. In the article on this, we’ll probably have links to the registration and so forth.

Dr. Nicole, it was so great speaking with you, and continued success with DORA and all of your endeavors. We wish you lots of success, and we’ll be watching it closely, and maybe we’ll have you back on.

Nicole Forsgren:         Thank you so much.

Alan Shimel:                Thank you. We’ll have you on to discuss some of this stuff again shortly.

Nicole Forsgren:         Sounds good.

Alan Shimel:                Alright. Dr. Nicole Forsgren, co-founder of DORA and guest on the DevOps Virtual Summit coming up just next week. Thank you for appearing.

This is Alan Shimel for devopsy.kinsta.cloud, and we’ll see you soon on another DevOps Chat.

— Alan Shimel

February 28, 2017
DevOps Chat: Madhura Maskasky, Platform9

This DevOps Chat is with Madhura Maskasky, co-founder and VP of product at Platform9. If you are not familiar, Platform9 offers an “open source as a service.” While that sounds pretty cool, think managed hybrid cloud and now managed Kubernetes in an infrastructure-agnostic service.

Madhura does a great job of explaining this, so have a listen for yourself. As usual, below the streaming audio player is a written transcript of our session.

Alan Shimel: Hey, everyone, this is Alan Shimel of devopsy.kinsta.cloud here for another DevOps Chat. Our guest on today’s DevOps Chat is Madhura Maskasky. Madhura, welcome and thanks for joining us.

Maskasky: Thanks for having me. I’m excited to be here.

Alan Shimel: Madhura, I didn’t mention in introducing you; you are with Platform9, an open source-as-a-service company. Correct?

Maskasky: Yeah. I’m VP of Product and co-founder at Platform 9 Systems. What Platform9 does is we pioneered a unique model, a SaaS-based model for deployment of complex open-source cloud-native frameworks such as OpenStack and Kubernetes.

Alan Shimel: Beyond sort of that tagline, Madhura, I believe—was it your co-founder or CEO that I might have interviewed at—I want to say it might have been the DevOps Enterprise Summit.

Maskasky: Yeah. It must be Sirish Raghuram.

Alan Shimel: Yeah. It was kind of my first introduction of Platform9 and I was kind of taken with the business model. I thought it was interesting and unlike anything I had seen to that point. As I mentioned, Madhura, beyond the tagline, can you give our audience really a sense of what it is that Platform9 is doing?

Maskasky: Absolutely. As we started, our roots come from VMware. That’s where myself and my co-founder spent about seven-plus years. A common theme that we saw working with mid to large-sized enterprise customers at that time was the amount of struggle they were going through trying to realize this vision of a private cloud, which was a concept that had started becoming popular for a about a year at that point.

The reason for it starting to become popular was because public cloud had set such an exceptionally high bar for how easy it can be to consume infrastructure. But yet, enterprises, customers of VMware or otherwise, were really failing to live up to that high bar and create an equal offering that utilized their internal resources that might be based on their data centers or in a hybrid way, but create a similar and seamless interface for their internal consumers to consume those resources.

So Platform9 started with the vision that it should be easy, fundamentally as easy as consuming a public cloud, for anyone to consume resources from any infrastructure endpoints, whether they’re private of pubic or hybrid. We wanted to do this using possibly an open source software that’s available, because we also felt strongly that open source is going to be the new norm of how cloud infrastructure is consumed.

So specifically what Platform9 does, our very first product offering was managed OpenStack, our OpenStack-as-a-service. What that model means is that we deploy the OpenStack control plane in a SaaS-hosted manner. The control plane is deployed outside of our customer’s data center, and then it integrates with their data center or their public cloud endpoint via a mechanism of an agent.

An agent, if you have a private infrastructure, the agents become the bridge between the private infrastructure and our cloud-hosted control plane. And if you have a public cloud, then we have drivers that interact directly with that pubic cloud endpoint. So, that’s really how the model works, and it lets you get up and running with OpenStack in a matter of minutes.

Now we’ve repeated the same model with Kubernetes, which is the most powerful container orchestration framework for building your applications using the microservices paradigm, where Kubernetes is also deployed as a SaaS-hosted service on the infrastructure endpoints of the device, so private or public endpoints.

Alan Shimel: Got it. Of course when I look at it, Madhura, I see, okay, so you had the OpenStack offering, OpenStack-as-a-service, and now you dig into the Kubernetes and containers. I have to assume that—and maybe I shouldn’t assume. Let me ask you: How quickly is that OpenStack market growing?

Maskasky: We’ve seen a pretty significant growth in our OpenStack customer base just year over year. In 2016 we were at about 50 customers strong. There have been multiple statistics that forecast a pretty strong overall growth in OpenStack revenue for 2017-plus as well. Just yesterday I think I was reading an article that was mentioning a multibmillion-dollar projected revenue growth in the overall OpenStack market, and the fact that Fortune 500s are going to be consuming increasingly OpenStack.

So even with containers, virtualized infrastructures are not going away any time soon, and the big challenge that enterprise customers face that we see is, on one hand, they are looking to save some money by converting part of their currently virtualized infrastructure into open-source Linux KVM and use OpenStack versus, say, going entirely the VMware route. Or, on the other hand, some customers start by being 100 percent public cloud consumers, but then realize that that’s a very expensive model at scale, and hence want to go to more of a hybrid deployment, where part of their infrastructure is hosted privately or in a service provider data center.

For both of those cases Platform9 is an extremely good fit because we support both VMware as well as KVM and because of our as-a-service model.

Alan Shimel: Got it. What about Kubernetes? Maybe it’s because I live in a DevOps bubble, but that seems to be kind of taking off, huh?

Maskasky: Kubernetes is taking off in a pretty significant way. We felt that Kubernetes was going to start building this level of momentum about a year or so ago, as we were looking at the different container orchestration frameworks and evaluating them for their pros and cons, and the other two optimal ones are Mesos and Docker Swarm.

Mesos and Docker was in its very early stages with its offering at that time, but the primary reason for Kubernetes being so popular is I would say three important factors associated with it. One is from project maturity. They were kind of the most mature projects—it was built inside Google and vetted inside Google before it became the open source project that it is today. It had a pretty significant community outside of simply Google developers, who are actively contributing to it.

A new version comes out every three to four months and the pace of iteration is just astounding. In 3 it has a number of enterprise customers publicly vouching for it by showcasing the use cases and examples of how they are leveraging it.

Alan Shimel: Got it. Madhura, now that we’ve got that straight, let’s talk a little bit about recent news from Platform9. Do you want to share with our audience?

Maskasky: Absolutely. We shared two pieces of news recently, actually just a week ago. The first one was that the managed Kubernetes offering, which has been in beta for about six months, is now generally available. They’ve had the opportunity to have the offering beta tested with a couple dozen customers since we announced it around June of 2016. So now we are excited to share with the world that it is generally available.

What it is again, pure Kubernetes deployed as a SaaS-managed service. We think it’s the industry’s first infrastructure agnostic Kubernetes-as-a-service offering, because it lets you consume both your private and public infrastructure, and it comes built-in with a number of enterprise readiness features like multi-tenancies, single sign-on, quota management, as well as being able to deploy highly available Kubernetes clusters.

Alan Shimel: That’s great. Definitely, again, I just think there’s something—I think the market desperately needs this kind of offering. I remember when OpenStack first came out. Actually, if you remember Cloud.com, Martin Nickens I think was involved in that one and several other companies. It was really at that point in the evolution of migration to the cloud; it was important that people were able to get all the pieces in one box, if you will—cloud-in-a-box, for lack of a better word.

But in today’s world even that paradigm doesn’t work. People want as-a-service. So if they can get a Kubernetes kind of infrastructure-as-a-service like this and agnostic, it’s fantastic. Also, something called Fission was introduced as well, yes?

Maskasky: That’s right. That was the second part of our announcement, which is we announced a new open-source framework called Fission. What it is, is it’s designed to be the de facto open-source alternative to AWS Lambda.

Alan Shimel: I’m sorry. I didn’t mean to cut you off. Go ahead.

Maskasky: No worries, Alan. So just some context behind it. When it comes to serverless, AWS has really made Lambda extremely popular and introduced this new paradigm of function as a service. But a problem with it that we see is the fact that it locks you into the AWS ecosystem, because Lambda is firmly designed to integrate with all the other Amazon services that are offered in their ecosystem, but it doesn’t necessarily provide built-in integrations for the most popular open-source tools and frameworks that your developers might want to use.

It kind of goes back to an important piece that we’ve always held, which is the development community loves to embrace the right sort of tools that let them do their job well. They like choice and they do not like being told or being scripted to go to a set of one tools only. So those are some of the motivations behind Fission.

Now Fission is also built off of Kubernetes, and by having that focus on Kubernetes it has an added advantage that it simplifies consumption of Kubernetes as well.

Alan Shimel: Got it. In my mind, the company has positioned these Kubernetes offerings to really take a leadership position as we see Kubernetes and containers really kind of explode onto the scene. What’s next for Platform9?

Maskasky: Kubernetes and containerization is a big part of our road map and our strategy for 2017-plus. We’re just getting started with managed Kubernetes going generally available. We have a ton of work ahead of us as part of our road map, and we’re looking for customer feedback as well, truly making the offering cloud-agnostic, enabling as many current points as our customers would like us to offer with built-in integrations, providing the ability to create federated clusters across these current point. So, in a nutshell, really realizing that true hybrid container-as-a-service vision through the managed Kubernetes offering.

That’s one. The second big part is, again, Fission. Fission has just gotten started as an open-source project. We’re looking to make it the de facto way of running function as a service within Kubernetes. So we’re looking to work with the CNCF, the Cloud Native Computing Foundation, and we are looking for the Kubernetes community to really start investing in it.

We’re seeing some grassroots early traction adoption. Someone in the community recently built a dot-net client for Fission and out-of-box support for Node.js and have been building support for Go. We’ve been hearing folks who started using Fission on top of their internal community’s deployment and they’re telling us about their use cases. So these are all some points of feedback, so we want to grow and build on that.

Alan Shimel: Got it. Madhura, as I promised you before we came on, the time goes so quickly. We’re already past 15 minutes, but it’s okay. I think we got a great—at least a taste of what Platform9 is all about, and perhaps we could find out more on another DevOps Chat or maybe an article here on devopsy.kinsta.cloud or Container Journal, as the Kubernetes stuff certainly lends itself to that.

Madhura, where can people find out more information?

Maskasky: The best way to find out more about everything happening on Platform9 is by going to our website, Platform9.com. You can also follow us on Twitter. The handle is @Platform9Sys. Fission has its own website, Fission.io, and you can also follow Fission on Twitter as well. The handle is @Fissionio. So that’s the best way to stay on top of all our news.

Alan Shimel: Fantastic. Madhura—and I’m still mispronouncing your name probably, I apologize—Maskasky, thank you for being this episode’s guest on DevOps Chat. Continued success of Platform9 and please keep us posted. I love the open-source angle. I love the Kubernetes sort of as a service, the serverless stuff with Fission, very, very exciting stuff you guys are doing over there. So please keep us posted and best of luck.

Maskasky: Thanks, Alan. Thank you for having me. This was a lot of fun chatting with you and absolutely I will keep you posted.

Alan Shimel: Absolutely. This is Alan Shimel for devopsy.kinsta.cloud on another DevOps Chat, and we hope to see you on another one, another chat hopefully soon. Have a great day, everyone.

— Alan Shimel

February 28, 2017
DevOps Chat: Mik Kersten, Tasktop on Value Stream Visualization

In this DevOps Chat, we sit down with Dr. Mik Kersten, CEO and co-founder of Tasktop. Mik besides being the founder of Tasktop, is also the creator of the Eclipse Mylyn open source project. Tasktop continues to lead the way in value stream visualization and software delivery integration.

Mik gives us the latest on this and more in this conversation. Enjoy!

Alan Shimel:               Hey, everyone, this is Alan Shimel, devopsy.kinsta.cloud editor-in-chief, and we’re here for another DevOps Chat. Our guest on this episode of DevOps Chat is Mik Kersten. Mik, for those of you who don’t know, he’s almost synonymous with Tasktop. Mik, welcome.

Mik Kersten:               Thank you, Alan. It’s great to be talking to you again.

Alan Shimel:               So how does it feel to almost be synonymous with your company?

Mik Kersten:               Now that you mentioned it, it sounds good. It’s been an amazing journey with Tasktop. I think it’s just been a great now ten years of looking at how to bring those benefits of Agile and DevOps to large organizations. So it feels good is the short answer.

Alan Shimel:               Another one of those ten year overnight success stories in the startup world. Mik, all kidding aside, there might be some people in our audience who aren’t familiar with Tasktop. So, if we can, just maybe a real quick 30 second sort of elevator pitch on what Tasktop is, what it does.

Mik Kersten:               Yeah, absolutely. Most organizations now know that in order to get the up and coming productivity and efficiency that they’re after to be competitive in today’s world, they need to face an Agile toolchain and they need to deploy DevOps and continuous integration, and to do that you pick your issue tracking tools, your continuous integration tools, your release automation tools, and all of those bits and pieces. If you’re a large organization, you pick requirements management tools. If you’re doing any physical products, you need some additional tools for requirements and bills of materials and those kinds of things.

What’s interesting is that once organizations scale up there are DevOps transformations. They’re both hitting more tools and different kinds of partitioners. So the missing piece for making all of these benefits of DevOps work at scale is this piece of integration infrastructure. We can connect up all the tools to get an end-to-end flow, so to get the benefits of Agile and Lean, all the way from business idea to running software and the revenue results and delighted customers.

That’s what Tasktop has been doing. Over the last ten years, by release we’ve been connecting different stakeholders, processes and tools, so that you could have this end-to-end flow of information. So you could have the best of breed tools, the latest issue trackers or Agile planning tools, the latest continuous integration tools and so on, while getting this end-to-end flow, because really the problem that we’re addressing is that when you look under the covers in most transformations you’ll see that both DevOps and Agile have been deployed at these local optimizations. The team can do continuous integration or continuous delivery. Or the organization has continuous delivery, but has not optimized anything upstream, and that’s really the problem we’re trying to solve. Let’s get the entire IT organization to be Lean end-to-end.

Alan Shimel:               Fantastic. Mik, in us talking before we started recording today, you said that the most recent release of Tasktop and the hub is probably the most important and meaningful thing you guys have done in ten years. Why don’t you share with our audience why you feel that way? What is this great functionality and great feature set that came out in this last release?

Mik Kersten:               Absolutely. What we’ve noticed is that the way that – again, you take any large IT shop who has not yet deployed Tasktop and you look at how they support their transformation, and you’ll notice you’ll see all these point-to-point integrations. So you’ll see, let’s say, the Agile planning tool wired in through some APIs or Web hosts or some data integration technology into the requirements management tool, into the time tracking tool, into the quality management tool, into the automated test tool, into this _____ tool and so on.

What we noticed four years ago is that the slave connecting things point-to-point was going to blow up. Once you’re making point-to-point connections, you get this exponential factor. So it’s okay if you’ve got two or three tools. All of a sudden you’ve got four or five tools. Just the sheer number of API calls are bringing down your servers actually.

We know a lot of customers where they say their JIRA issue tracker is getting so many API calls from these integrations that it takes a minute to load an issue. So you get all these weird symptoms.

You also get this thing that’s very difficult to maintain, because as soon as one tool changes or someone adds some new fields to a project’s definition of a user story or something of that sort, multiple integrations break and you’ve got this spaghetti code of Web host and API integration madness.

So we realized four years ago we couldn’t even test all the integrations we’re supporting in that point-to-point way. It was already costing us hundreds of thousands of dollars of resources, of basically VM resources, just to test all the tools we support in a point-to-point based way. So we said four years ago, “We’ve got to stop doing things in a point-to-point way. It won’t scale. We need to support all the Agile and DevOps tools out there, and it won’t scale to supporting large scale DevOps transformations.”

So we started creating this notion of models. First you look to open standards. So we got our feet wet and we on the committee of OSLC, but to get everyone to adopt open standards just didn’t work. And these tools are so complex because the stakeholder tools right now have become very elegant, basically. The developer tools are very tuned to the developer process, and with that comes a lot of complexity specific to developers, to testers and so.

So we realized open standards won’t solve it. APIs alone don’t solve it, but are actually part of the problem. You need to take a different approach. So internally we made this integration factory so we could test everything, and we made these common models. The models are basically the currencies of Agile and DevOps and the ALM and SDLC systems, things like requirements, user stories, builds, releases, security, vulnerabilities, those kinds of things.

That’s how we started testing everything and then we said, “Okay. If you raise the slave abstraction, it actually makes it much easier to connect everything. With last week’s release of the Tasktop Integration Hub, we’re actually taking that model-based approach and exposing it to all of our users. So you simply define all of your models in your value stream, again, like user stories, requirements, builds, releases, chain sets and so on, and then you plug in however many tools you want into those models and you get this amazing thing. You get complete automation for your value stream.

So we’re calling that value stream integration, because end-to-end you can now have these flows and you can actually track things like cycle time, and you can basically get the benefits that a startup with 100 or 200 people is getting in terms of their speed of delivery at very large scales, at thousands or tens of thousands of IT staff. So you’ve got that value stream integration layer that we provide.

With that, you can also inspect what’s going on and you can basically support these large scale Agile and DevOps transformation, all because of the fact that we’ve raised the slave abstraction to make these models, have you map your different toolchain in your models and, as a result of that, what we’ve actually done is we’ve made the toolchain itself be modular. So you can plug in best-of-breed tools Here’s some dot-net. Here’s some Java. Here’s some JavaScript there, maybe some Python for your AI. You can plug all of those separate tool streams together into one end-to-end unified value stream. Really, the key thing that we’ve done here, the game changing thing is this notion of model-based integration.

Alan Shimel:               Excellent. I agree, Mik. You know what? Obviously you work at Tasktop. You’re very excited by what they’ve done. But for our audience out here who are generally pretty sophisticated technologists, I hope they appreciate really the – I mean it’s making people’s lives easier, right. When you can make people’s jobs and lives easier like that, it’s a good thing and this sounds like it could be a real game changer that way.

Mik Kersten:               Yeah. Alan, that’s a thing that’s absolutely near and dear to me. My whole background was from productivity tools, empowering developers and taking the waste out of their day with all the open source work on Mylyn and the dev tools that we’ve done. Our mission was to bring about that change in the way people work at scale, because it gets even worse.

You look at the large IT shops out there, the place where most of the world’s IT staff works, and we’ve measured what they do. Every developer or every tester, every business analyst, they’re spending at minimum 30 minutes, in some cases we’ve seen two hours per day of duplicate entering information for every code change they make, for example, because of all the governance and compliance and other rules which need to be there in large scale organizations, but all of that work is waste and it drives people crazy because they don’t like doing it, because it’s basically manual data entry.

When you think of what it actually is, they’re entering information and logging into different systems, all of which could have been done automatically if, again, we took this value stream-based approach. You make your code change. All that information propagates into however many tools the organization had to set up. You might have to track different kinds of requirements and changes differently. That’s okay.

So the most satisfying thing that we’ve seen with deployments of this, because we actually had customers in an early access program since April – the Tasktop Integration Hub is running in production at customer sites today – is that all of that waste gets taken out instantly. Basically our expectation is that the moment its deployed, and we’ve seen this, your employee engagement scores are going up that week or that month, that quarter, because you’ve taken out all that wasted work which drives the best people in their company crazy, the fact that you’re making them do it.

So that’s our whole goal. The person goal is just make the lives of all those people in IT better by removing all that waste. Then of course the organization economic goal is through that: make your organization more innovative, because you’re now able to deliver at the speed of a startup and get that promise of DevOps at scale.

Alan Shimel:               Absolutely. Mik, we’re running short on time, as we always are on DevOps Chats, but let me quickly pivot to something else I wanted to touch on with you, and that is the idea of the bridge of that job to DevOps or bridge between that job and DevOps. When I first started with DevOps four years ago, maybe more, five years ago, there was, “Well, DevOps really picks up where Agile leaves off,” but they were clearly two separate things. Agile is for developers. DevOps is for everyone.

But what we’ve seen is that DevOps is borrowing more and more from Agile, more and more from Lean. Where do you see the connection between Agile and DevOps, if that makes sense?

Mik Kersten:               It’s by different thought leaders, different vendors and so on. In the end, it’s all the same thing. It’s Lean for software and software at scale. So in terms of how organizations have aligned, I think what has happened is that so much of the bottleneck for software delivery for so many large organizations has been in deployment reliability and velocity and automation. DevOps has formed the big new movement and really picked up as a movement where Agile left off.

In the end, the technology is you need continuous delivery. You need to implement continuous delivery, but the DevOps movement has come from that side, from development and operations and said, “We need to deliver things faster, more reliably, and automate all the stuff that’s manual in their account.” That’s actually shifted and taking over where the Agile movement started, which is we need to track work and be responsive to change and bring customers into the feedback loop.

So there are two key components and I think the sheer velocity that we have right now behind organizations going to DevOps has made it the more important transformation agent. Everything that was going with Agile stays as a key part of the transformation. I think it’s very important for those leaders out there, putting together those DevOps transformations to not stop at code commit.

You have to actually take the Lean fast feedback loop, continual learning all the way into business analysis, design and so, because if you stop you’re going to have to solve the deployment bottleneck, but not the upstream bottleneck. For example, if you don’t have enough UI designers, it won’t matter how quickly you’re deploying. You’ll do bottlenecks on your UI design. You’ll need to higher there.

So I think we all need to take this end-to-end Lean view and DevOps is just a great transformation agent and a great movement to help us all do that.

Alan Shimel:               Good stuff. Mik, we’re coming up to the end of our time. I want to ask you one last question, not a trick question, but I always like to ask if possible. For our audience out there, if you could recommend one book that they read, and not an obvious one, don’t tell us The Phoenix Project or even the DevOps Handbook. It doesn’t have to be DevOps related. What book would you recommend?

Mik Kersten:               I’m holding it up right now. I know you can’t see it, but it’s the book Learning to See by Mike Rother and John Shook. If you even just flip through this book, you’ll see the value stream mapping and value stream integration and management approach that make the manufacturing work. As we go into this post-DevOps, post-Agile bigger picture world, it’s that same view of the value stream, focusing on the end-to-end value stream that I think need to inspire that next generation of leaders creating these transformation.

I think the DevOps Handbook contains a lot of this. It’s a great book. I’m nearly finished reading it. It has a lot of the right sources, but in terms of something that you might not have seen it’s this Learning to See book, which is really about learning to see production. We need to learn to see the flow of software across the value stream and most organizations have not done that yet, and that’s really – our mission is to help organizations do that, but the ideas are here. We’ve done them before. Again, it’s been done in manufacturing and now it needs to be applied to software delivery.

Alan Shimel:               Fantastic. Mik Kersten, Tasktop, thanks for being this episode’s guest on DevOps Chat. Continued success and looking forward to more, and maybe seeing you at DevOps Enterprise Summit in London.

Mik Kersten:               Absolutely. Thank you, Alan. Great chatting with you, as always.

Alan Shimel:               All right, Mik. You be well.

Mik Kersten:               Thank you.

Alan Shimel:               This is Alan Shimel for devopsy.kinsta.cloud.

— Alan Shimel

February 23, 2017
DevOps Chat: Why Real Transformation Starts with Culture, Bryson Koehler and Shelbee Smith-Eigenbrode, IBM
While culture is of the utmost importance to enable digital transformation, there are many other milestones in a successful DevOps journey. In this DevOps Chat, join Alan Shimel, Editor-in-Chief, devopsy.kinsta.cloud, as he hosts Bryson Koehler, GM, Distinguished Engineer and CTO of IBM Watson and Cloud Platform, and Shelbee Smith-Eigenbrode, Senior Software Engineer/IT Architect at IBM.

Learn about challenges that The Weather Company (TWC) faced during the transition from TWC, to being TWC: an IBM company. Koehler is CTO of IBM’s newly formed Watson and Cloud Platform, as well as GM and distinguished engineer for IBM. Prior to this role, he served as executive vice president, distinguished engineer and CIO/CTO of TWC. He has an extraordinary record of leading significant business transformations and underlying cultural shifts. To do so successfully, Koehler maintains cultural change must first be incited in tech companies at the developer level. While at TWC, Koehler built a DevOps culture and practice that encourages transparency, accountability and collaboration. It is his mission to replicate this model in the transformation of IBM’s culture from a legacy IT enterprise to a true cloud platform company.

As usual the streaming audio of our conversation is below with the written transcript below that:

Alan Shimel:                Hi, everyone. This is Alan Shimel, Editor-in-Chief of devopsy.kinsta.cloud, here for another DevOps Chat. We have a special edition of DevOps Chat this time and we’re joined by two special guests. First of all, we have Bryson Koehler, GM and Distinguished Engineer and CTO of IBM Watson and Cloud Platform. Bryson, welcome.

Bryson Koehler:          Thanks so much, great to be here.

Alan Shimel:                Thank you. And we are lucky to be joined by a DevOps Dozen winner, Shelbee Smith-Eigenbrode of IBM, and also a devopsy.kinsta.cloud columnist. Shelbee, thank you for joining us along with Bryson.
1. Smith-Eigenbrode: Thank you for having us.
Alan Shimel:                Of course when Shelbee is not writing for devopsy.kinsta.cloud, Shelbee is a Senior Software Engineer/IT Architect at IBM.

Bryson, let’s turn to you first, if it’s okay. First of all, you’re involved with IBM Watson, and I think everyone kind of feels a little bit about Watson like I did about the space program when I was young, which is that’s cool. Everybody wants to be an astronaut and I think everyone can’t wait to see how Watson changes our lives. How did you come to be involved in the Watson program?

Bryson Koehler:          Well, I was the CTO of the Weather Company prior to the acquisition by IBM. If you think about the Weather Company, the Weather Company really at its core was a decision company. We helped people in businesses make smarter decisions, and we used a lot of machine learning techniques in our weather forecasting and how we looked at creating those inputs into our decision applications, whether those were businesses or consumers. So we’ve been doing that kind of work for quite some time, and if you look at Watson, Watson is a very revolutionary way to look at cognitive learning, machine learning, and augmented intelligence capabilities. So they’re very similar and they go hand-in-hand.

So when you look at how do we take Watson forward, Watson becomes smarter every day as it ingests more data and it learns more. So the more we can teach Watson and the more we can help Watson learn and become educated, the smarter it will become. So it becomes a data scaling problem, and that was a problem that we had been solving at the Weather Company.

So I think there was just a very natural marriage between the work that the Weather Company team had been doing, the work that we wanted to do with Watson as we continued to evolve it and its capabilities. So I’ve been honored to have a role with helping Watson move forward now in kind of its next stage of evolution.

Alan Shimel:                Sure. If you don’t mind, let’s just stay on that one for a while, Bryson, and Shelbee, if you want to add in. This is a fairly new kind of not department, but a fairly new grouping of IBM Watson and Cloud platform. What exactly – I mean it kind of says it for itself, but, Bryson, is there anything special about it that our audience should know about?

Bryson Koehler:          Yeah. I think it is amazing and really only someone like IBM has the breadth of capabilities to do what we are doing. Bringing together all of the groups around IBM that have been working on cloud native capability, whether it’s in our video team and our storage team, the infrastructure group, Watson, our analytics team, the Weather Company itself, all of these groups were working in and around cloud native capabilities.

What we have set forth to do is to bring all of those groups together and make sure that as we journey forward that we are building a single unified platform. The view of the Watson and Cloud group together is around a unified platform that’s very developer-friendly, focused on cloud native capabilities, that really enables us to bring to life not just a bunch of piece parts. Right?

You can go to our competition and you can find ways to get individual services. We offer those, too. But how do we do it in a much richer way? How do we make data less of a conversation around, “Hey, I have some data. I need to store it somewhere,” and how do we bring data to life? How do we take that data and actually treat it as a living, breathing part of the organization, where as we ingest it and as we enrich, and as we use that to create better and smarter signals and capabilities for our applications to learn from, we need to treat all of this as a unified platform, not a set of bespoke capabilities or service offerings.

So it’s really exciting when you think about bringing together video, for example, as well as then the image and video recognition capabilities that Watson has. So plumbing in the ability to ingest a stream of video or content from images, having Watson natively there to be able to recognize and manipulate and do things, do metadata tagging or additional enrichment of that content as part of literally a pipeline versus it being, “Oh, I’ve got to now reach out over – I’ve ingested the data. Now I’ve got to store the data. Now I need to reach out over here and make another service call. I’ve got to create another application that manages that service call.”

We’re trying to make the life of the developer easier, and by providing a native platform that is pre-built, pre-plumbed and really focused at incredible data analytics and data management capabilities, I think we have a real differentiator on our hands, and we’re really excited about bringing these teams together to do that.

Alan Shimel:                Very cool. Shelbee, let me turn a little bit away from the Watson stuff and talk about you recently did a DevOps blog on culture transformation. Interestingly enough, you interviewed Bryson about it. We haven’t really spoken about DevOps and cultural transformation here. I’m interested in why. What made you think Bryson was a cultural transformation kind of dude, for lack of a better word?
1. Smith-Eigenbrode: First off, let me just say that at the time I reached out to Bryson he was not in my management chain. So it wasn’t a brown-nosing activity at all. I had the opportunity to work within the Weather Company and work with some of the Weather Company employees who are now of course IMB’ers, while working on a project to move an application to the Sun platform and utilize some of the Sun services.
During my time that I was there and able to work with some of the employees there, I was so impressed with the culture that they had. They had a great balance between agility and time to market, but also having that quality of operational readiness. Of course for me operational readiness has always been key, because I’ve always felt the pain of not having that included upfront.

Then this was a terrific collaboration with passionate people that were extremely skilled, one, but you could also tell that they actually enjoyed their jobs. They loved what they did. They were extremely willing to help others. It was always very quick to find who was the expert in this area, a very high degree of empowerment as well.

So being able to see that firsthand, I really wanted to reach out to Bryson, because I know he had led cultural change at the Weather Company, to get his views on how that transformation went, what he did to enable it, and then also how he’s planning to bring that forward into the broader IBM Watson today. He was very willing to help me and provide input. So that was why I reached out.

Alan Shimel:                Excellent. So now, Bryson, Shelbee has put you on the spot. What are some of your secrets? What’s the secret sauce here? Because that’s probably the single biggest question we get from our audience, which is: how do you do this culture thing? How do you lead the transformation from a cultural perspective? What do you want to tell our audience?

Bryson Koehler:          I would say, first of all, everybody that recognizes the cultural challenge, they’re definitely on the right track. All of the transformation that a company that I have had the privilege of leading over the years, they are not technical challenges. They’re all people challenges. They’re all cultural challenges. And fundamentally, at the end of the day, the technical success of your strategy, whilst you need a good architecture and you need a good plan, you more than anything need great people and great culture.

So first, you’ve got to focus on that and you’ve got to spend the time on it. It doesn’t just happen. Everybody spends a lot of time in front of a whiteboard working on their architecture. But how much time do the leaders really spend doing the same thing, but focusing on their people and culture?

So to me it starts with a very simple premise. I want people to love what they do. I want you to get out of your bed every morning and I want you to love what you do. I want you to be excited about coming into the office. And if you don’t love what you do, then I want to help you go find a different job. Life is too short for any of us not to love what we do.

We haven’t all won the lottery. We all have to get up and earn a living, so we might as well enjoy it. I think that it sounds simple, but you’ve got to create an environment where people are free to actually love what they do.

I think understanding the mission is important. Why are we building this? Why is this feature important? Why is this product important? You can find a great mission in just about any industry or any application or any part of the business as to why it’s critically important that the team excel at what they’re doing.

Then I think you have to allow decision making to be pushed down to people. You need to learn to make very fast decisions. I always tell my team, “If you walk into a meeting and you don’t know who’s making the decisions or what decisions need to be made, you should disband the meeting and just leave.” People get frustrated if there’s just too much time being spent discussing things and not enough action being taken.

So I look to create an environment where we have high velocity decision making, where we’re willing to take some risks together as a team, where we are passionate and love what we do. It starts with me, it starts with my leadership team, and it starts with the employees. Everybody has a piece and a role to play in bringing all of this together, and you have to work on it every day.

This is not a, “Hey, we had an offsite and we talked about culture. We had three PowerPoint slides and now we all feel loved.” This is something that every single day we have to lead by example. We have to reinforce the energy and the passion for what we’re doing. We have to enable our leaders to be able to make quick decisions. We have to have the courage to change, and the courage and the guts to admit mistakes and move on from that, and enable the team to feel like they’re in a safe place as long as they’re working hard and loving what they’re doing and passionate about their outcome, that they’re in a safe place.

I think it takes time to create that environment. It doesn’t happen overnight. I have to reinforce it every day. So you have to have the patience that you’re going through a technical transformation, have the patience to do the cultural transformation, too, realize you’re going to have to repeat the same message a thousand times, over and over again. Over time it begins to stick and over time, as the winds happen, it builds momentum and pretty soon you have a self-fulfilling prophecy, because the team kind of takes care of itself and now you’ve actually created a native culture, that as a new person joins the organization they’re converted to your way of working and they’re converted to a way that you’re proud of.

Startups have it easy because they start with employee one and then employee two, and the culture is kind of created organically over time. But when you start with large teams of people in a preexisting culture or workplace, or if you’ve brought two companies or teams together that each have their own cultures, you don’t have that luxury to start with a clean sheet of paper. So, honestly, there’s just no substitute to realizing that that is a key part of a leader’s job is to work at that every day.

Alan Shimel:                Got it. Bryson, you described a situation and I guess your real-life situation is that to the umpteenth degree. Coming from a company like the Weather Company, I think that had under 1,000 employees, right?

Bryson Koehler:          The Weather Company was just around 1,000 employees, yes.

Alan Shimel:                And now working even just within a division of IBM, but nevertheless it’s IBM. I forgot – I think it’s 400,000 or some crazy number. How do you take that? How do you scale that? How do you take that philosophy, that cultural mantra and bring that to an organization the size of IBM?

Bryson Koehler:          Ha. It takes time. There’s no substitute to that. I’m spending my time going around, meeting with as many teams as possible, and still hold to the town halls and still bring people together. Town halls are bigger now than they would have been at the Weather Company, but the Weather Company had offices in Atlanta and Boston and New York and San Francisco.

The town halls now, we still have them in different parts of the country and different parts of the world. They’re just bigger, but my style and my approach doesn’t change. It is continue to reinforce the journey we’re on, the vision that we have, the reason why our mission is so critically important, the role that each person plays, why we have to do this together as one team to create one platform, not an individual kind of bespoke set of capabilities that everybody has done independently, but how we have to do this together as one IBM Cloud approach.

I think it resonates with people, but I also don’t think for a second that just because I – last week I was in Germany, and I was in Ireland meeting with teams there. I can’t just check that off my list and say, “Okay, Ireland is good. Germany is good.” I have to continue to reinforce that, help and encourage the teams, get back out there, share the wins, showcase the challenges, and just be very visible and never disappear from those teams.

I look at is as kind of like a rollercoaster. As those cars are clickety-clacking up the track to get up to the top of the hill, if that chain that was pulling it up to the top broke before the car or the set of cars got enough over the top, it would just roll back down to the station. So if you’re thinking about the organizational change, you’ve got to get enough momentum over the top of the hill, so that if the chain broke the weight would actually carry it down the other side.

So my job is to continue to push and encourage that change every day, to ensure that, yeah, at the end I do want the momentum of the team to carry it forward on its own, but it doesn’t just happen because you went and had one meeting. This is an ongoing, every day, live this, breathe this and own this. It’s just going to be a constant reinforcement and encouragement to the team that we are serious. We are going to do what we said we were going to do. We are going to have fun and enjoy and love what we do.

People want to believe that, but I think a lot of times, “I’ve heard that. I’m not really sure if I believe it. Is he serious? Are we really actually going to do what we say we’re going to do? Are we going to follow through or will this too pass?” You have to stick with it, because you don’t want anybody ever doubting or believing that you’re not serious in the mission that you’re one.

Alan Shimel:                Absolutely. You know, Bryson, you brought up another point earlier on in your last comment, which is I think fostering cultural change and change in general isn’t a hit and run exercise. You can’t stop in, in Ireland or Russia or wherever and say, “Okay. I talked to them and they’re good now. Let me move on. Maybe I’ll stop here next year or whenever.” It’s a constant tendering. It’s like a shepherd and their flock or a farmer and his crops. I think to do it right, these groups and so forth, they do need – not constant attention, but steady attention.

Bryson Koehler:          I don’t view this as my employees. This is my family. It needs love and encouragement and coaching and guidance and feedback, positive or negative, every day.

Alan Shimel:                Agreed.

Bryson Koehler:          That’s why I was saying, to me, we spend so much time as technical leaders working on either architecture or budgets or contracts and all of these kind of gross behind closed doors things, although doing architecture is my fun. But do we spend the same amount of time being leaders to our people and encouraging and growing them? If we spent as much time doing that as we did all of the other things, I think more of our problems would take care of themselves.

Alan Shimel:                Agreed. Guys, we went way over our 12 to 15 minute time allotment, so we’re going to need to wrap up. But before we do, Bryson, I wanted to ask you my famous closing question. That is: if you had to recommend one book for our audience to read that might help them in their careers or in their life in general, what book would that be?

Bryson Koehler:          My answer to that might be a little bit old. The back out I think in 2003.

Alan Shimel:                That’s not old.

Bryson Koehler:          I’m just not the latest business book of the day. Bob Lutz, who was an executive at many of the auto companies over the years, wrote a book called Guts. It was around the guts and courage of leadership in transformational times in challenging business environments. I still to this day find that to be one of the best books around the type of culture I try to drive in the team. So I would recommend reading Guts by Bob Lutz.

Alan Shimel:                Got it, excellent book. Well, Bryson Koehler, thank you so much for being this episode’s guest on DevOps Chat. Shelbee, always a pleasure to have you on here as well. We hope to have you both on again in the future.

You know, we didn’t even mention – Bryson, will you be at InterConnect, IBM InterConnect?

Bryson Koehler:          I will absolutely be there and I hope that all of your podcast listeners sign up. It’s going to be a really great conference this year, a little bit different than we’ve done it in the past. You’re going to hear, I think, a lot of new messages from IBM and some really exciting positioning of where we’re headed, and how a lot of what we’ve been talking about here at the platform come to life. So you don’t want your audience to miss out on being there. Come to InterConnect in March; it’ll be great.

Alan Shimel:                Absolutely. And I am doing a panel there on “DevOps: It Takes a Village,” which is very much in line with some of the concepts you’ve been talking about, Bryson.

Bryson Koehler:          I will come and be in the room with you, and I’ll meet your fans and your audience there. It’ll be great.

Alan Shimel:                All right. We may drag you onto the panel. Bryson, thanks very much for being with us here today on DevOps Chat. Shelbee, as I said, keep up the great work, and we look for more columns on devopsy.kinsta.cloud from you as well.

But until next time, this is Alan Shimel of devopsy.kinsta.cloud. Thanks for listening, everyone, and we’ll speak to you or listen to you all soon.

— Alan Shimel
February 22, 2017
DevOps Chat: Justin Vaughan-Brown, AppDynamics

This episode of DevOps Chats is with Justin Vaughan-Brown of AppDynamics. This was recorded just prior to the announcement of Cisco’s intent to acquire AppDynamics for about $3.7B. So sorry, folks no insight into that deal here. Nevertheless, Justin is a DevOps veteran. While at AppDynamics for just a few months, Justin has worked and helped lead several DevOps tool and consulting businesses. He has some great insights that he shares here with us.

As usual, the streaming audio of our conversation is immediately below, followed by a transcript of our conversation. Enjoy!

Alan Shimel:                Hey everyone, Alan Shimel, devopsy.kinsta.cloud here for another DevOps Chat. And our guest for this edition of DevOps Chat is Justin Vaughn Brown of AppDynamics. Justin, welcome to DevOps Chats.

Justin Vaughan-Brown:          Thanks Alan, glad to be with you.

Alan Shimel:                Glad to have you here. Justin, you are a DevOps industry veteran, if there is such thing, in a relatively short time. But you’re hanging your hat at AppDynamics now. How long have you actually been with AppDynamics?

Justin Vaughan-Brown:          I’ve been with AppDynamics since – it was the very last day of October, so kind of two to three months in now.

Alan Shimel:                Perfect, just enough to get I guess the lay of the land there. And as we spoke beforehand Justin, and as I think most of our audience, it’s been a busy two to three months, you know, between the end of the year and everything going on in the market you’ve had a good chance I would imagine to get a flavor for not only what AppDynamics is doing but really kind of where the market is heading a little bit in terms of DevOps APM and stuff like this. Correct?

Justin Vaughan-Brown:          Absolutely Alan. I think what was very interesting was – actually a few weeks after joining – was spending time with customers and partners and colleagues at App Sphere in Las Vegas in November: that was absolutely fascinating, so that was a real eye opener in terms of how APM customers – you know, those of AppDynamics are actually using DevOps and adopting it and how they’re leveraging our technology to help them in their DevOps adoption.

Alan Shimel:                Yes, I was actually at App Sphere as you know – I was at App Sphere myself and it was a great conference and it was a great customer-focused conference in that there were a lot of users there – real live users, right? – the rare, endangered live user at these conference – not a Biz Dev first and not a sales person but real users and I had some fantastic conversations myself.

Justin, I wanted to spend a moment a little bit talking about APM because sometimes when we look at software development life cycles and kind of where the action is around DevOps you know a lot of people get all hot and bothered and hyped up around configuration management, right, the puppet and the chef and the ansible and salts and these kinds of things. And then, you know, they move from configuration management to CICD and of course that’s a world unto itself.

But then when we look at let’s say post deployment, you know, okay, so now we delivered and we’re delivering continuously, but what impact is that having? How are things going? Are our customers happy? Are we delivering better products, right, and are they performing as intended?

And you know all of these things you would think would make APM sort of king of the castle, top of the heap. But a lot of times it doesn’t: it kind of gets subsumed within the whole DevOps conversation or is maybe a little bit outside.

I’m interested in what’s your opinion on that?

Justin Vaughan-Brown:          That’s an interesting perspective and I can see where you’re coming from. I think it’s possibly because, you know, from historically a lot of the vendors are more and more what you call classically the dev side and have generated a lot of interest and adoption. But ultimately we’ve seen the company grow from strength to strength, and I think what was really eye opening was – at App Sphere – was seeing how critical app dynamics was in enterprise DevOps adoption.

And I think what most particularly – you’ve hit the nail on the head there – if you look at for example the impact of those applications in production how are they actually performing, where our issues lie, where the – the apps themselves can be fine tuned and ensure that you have the best customer experience possible.

I think in the main – and this is a generalization of course now, there are exceptions – I think we’ve gone beyond the state where applications – with the exception of certain tougher cases like say, you know Black Friday and so forth where sometimes some organizations can have challenges – but in the main I think what we are seeing is most applications perform at what I would call a base level – what we’re really now into is tuning them: is identifying absolutely the tiniest little bit of latency or glaze or issues wherever they may lie so that the performance of those applications, irrespective of where they’re delivered – you know, on a tablet or mobile device, on a PC or whatever – are highly high performance, and again, irrespective of platform, operating system or so forth – all of those – I think that’s become one of the overriding demands.

And I think it’s evolved even more so now – you know, we recently launched Business IQ which actually drills it even further and actually looks at the business benefit of the application you’ve released where a consumer’s using the application, where are they located, where are they on the user journey, where are they on the purchase cycle. And you’re finding lots of consumers are going through to about to purchase and then there’s a delay in the actual purchase process as the transaction is going through or not going through.

So I think it’s definitely evolved and I think we’re seeing certainly an absolute relevance for APM now.

Alan Shimel:                Got it. Absolutely. Justin, let me – as I said earlier you’re a DevOps industry veteran though and AppDynamics isn’t your first stop on the DevOps train.

Why don’t you, if you can share with our audience a little bit – we’d like to hear your views though on – so that’s APM and what sets it apart – what other kind of – let’s look at trends in the DevOps space and maybe how it relates to APMs.

What other kind of trends are you seeing?

Justin Vaughan-Brown:          I think one of the interesting ones that we’re seeing is – you know, you’ve seen the evolution of Docker over the last kind of 18 months to 24 months, and I think that and the overall rise of containerizations in general is having a huge impact.

I recently saw an article by a bank – folks who were going to report that they’d recently issued on the – I would say the stellar rise of containerization and adoption, and it’s almost a case of, you know, there’s no going back.

So I think it’s really down now to where you’re adopting containers and to what degree, one or another, if, for example. And that’s where we’ve seen our ability to help that; for example in terms of their integrating and monitoring docker container performance easily to ensure that you’re optimizing and maximizing the potential there and that doesn’t become a black box area where you’re not getting the granularity of insights that you’re looking for. So that’s one area definitely.

I think also, you know, with cloud adoption as well, to be able to monitor across multi cloud environments – and that’s just not one vendor only, you know – as I said multi cloud – whether it’s Amazon AWS, Microsoft Azure, and so forth.

So I think there’s a need to be, you know, platform and cloud agnostic going forward. And that’s something recently I’ve seen at analyst conferences where they talked about so many enterprises now from an operations point of view being cloud brokers and then looking at not just one vendor – not being locked in – but being able to switch and change dependent on which particular application they’re working on or initiative and so forth. So I think those are two clear areas.

                                    I think the last one probably I’d highlight is micro services where, for example, the ability with APM to automatically monitor in micro services, you know, deployed in an elastic infrastructure so you can look at issues around say threat contention and then zoom in and identify and address their root causes.

So seeing all these kind of technologies orbiting around that APM can absolutely assist in the adoption. And if you adopt this properly obviously they’re hugely advantageous. If you struggle with them then they can actually set you back and you’re worse than if you hadn’t embarked on that journey. So those are three that immediately come to mind Alan.

Alan Shimel:                And I don’t disagree with any of them Justin, I think they’re all dead on.

Let me throw another – and this might be a bit of a curveball at you – but as a fellow observer of the DevOps space Justin what I find interesting is that when we first started talking about DevOps everyone sort of said, “Oh yeah, DevOps is great for startups because it’s in their DNA and they do it by – you know, not by choice: they have to. And this is – DevOps was made for these folks.”

Where you know this whole issue of “enterprise DevOps” was almost like a different animal or a different set of stripes. And you know I was always one of the ones that argued DevOps is DevOps, you’ve got to recognize who your customer is and who your organization is, but the principals of DevOps apply across small and large organizations.

But low and behold here we are now, you know, a new year and we’re a couple more years into this DevOps thing and it almost feels like DevOps is a big organization way of doing business, maybe even more so than the startups. What’s your feeling on that?

Justin Vaughan-Brown:          I think you’re absolutely spot on Alan. I mean I think we’ve both been on that journey where we’ve observed certain trends and how the markets evolved.

And if you look at, for example, at the DevOps Enterprise Summit that took place last year in San Francisco and London – both extremely well-attended – and then if you look at those agendas on both of those the vast majority from my perspective of those presenters presenting from the end user side were representing enterprise organizations – household names – in fact if anything those smaller organizations were the minority, and equally even the – you know, there’s also I think with the larger organizations it was those that were not just the, you know, the purely kind of online shop equivalents where they’ve got no legacy infrastructure that they have to deal with: a lot of these are, you know, 50-, 100-year-old companies that have been around a long time yet are making that brave journey.

And I’d like to just kind of re-quote an observation made by Gene Kim last year when he said what really impresses him is – it makes him really think of people who are being heroes within these large enterprises, within these organizations, who are, you know, probably I’d say mid-level advanced in their career and in age and during their career who are making these brave decisions, who are doing things differently: they could carry on as normal.

And in doing so they are trying different things, they are embarking on new journeys and they’re bringing their teams with them, they’re collaborating more closely.

And I think that’s – it’s those kind of – I think Gene Kim is absolutely spot on in it’s those kinds of heroes, those catalysts to change – and I think frankly DevOps is absolutely for the enterprise and will continue to be so.

Alan Shimel:                Makes sense. Justin we’re running a little low on time. Let me turn this back to App Dynamics if you don’t mind. What are you – so we’ve talked about these trends, we see the market kind of taking shape – what does it mean for AppDynamics?

Justin Vaughan-Brown:          I think it means a lot of opportunities to continue to help the enterprise customers. Most of all I think – you know, from a personal level I’m very excited by the recent release of Business IQ because I think that enables DevOps teams now to take information relating to how that application is being consumed, where and in which way of these visual user journeys – to actually then take that information and present it to the business – and that moves it from purely a DevOps conversation to a business one just to say, “Look this is – you know, we’ve all be slaving away the last couple of months on this application. Here’s the actual impact to your business; this is what’s happening, this is the value.”

And then maybe the business turns around to say, “You know what? Interestingly sales in this region are going really well but not in this region or this group of customers, you know, our gold card member carriers are absolutely loving this promotion but our silver card holders aren’t. Maybe we need to incentivize them in some way,” you know, and so forth.

So that’s moving, as I said, the DevOps teams into a more business conversation. We know about this topic such as Citizen Developers and obviously Shadow iTeam – more and more and more the businesses are being involved in these decisions, and that’s the way for DevOps to help drive that dialogue rather than being on the receiving end and taking requests from the business, that they’re actually driving that discussion which puts them in a really good position.

Alan Shimel:                Excellent. Justin, we’re just about out of time here but I want to ask you one last question and that’s the kind of question I ask a lot of our guests here on DevOps Chat.

For our audience listening out there if you had to recommend one book – and not the usual, you know, Gene Kim Phoenix Project that you would expect from a DevOps podcast – what book would that be?

Justin Vaughan-Brown:          I think I would go back to a book and a course that I took almost 20 years ago which is The Seven Habits of Highly Successful People by Steven Covey which pretty much broke down most of everything that I knew and rebuilt it another way and gave me a fresh perspective, so I strongly recommend that.

And if you’re pushed for time I think there’s some YouTube videos where you can go in and get the canned insight in 15 minutes, so that’s well worth taking a coffee break.

Alan Shimel:                Absolutely. But that’s a classic. And for any of our listeners who have not read that one it really should shoot to the top of your list.

Hey, Justin Vaughn Brown, AppDynamics, thanks for being this episode’s guest on DevOps Chat. Look forward to having you on again soon and sharing some more market insights.

Justin Vaughan-Brown:          My pleasure. Thanks very much indeed Alan.

Alan Shimel:                Okay. This is Alan Shimel for devopsy.kinsta.cloud and DevOps Chat. We’ll see you soon on the next DevOps Chat.

— Alan Shimel

February 13, 2017
DevOps Chat: Chris Lazzaro & Peter Klenk, IBM Bluemix and IBM Bluemix Garage

In this DevOps Chat, we catch up with Chris Lazzaro and Peter Klenk of IBM Bluemix and Bluemix Garage. With IBM InterConnect just a month or so away, it is a good time to hear what those innovative Bluemix folks are up to. Peter and Chris give us their take on new IBM Bluemix services, as well as the continuing evolution of IBM Bluemix Garage and the Bluemix Garage method.

I will be chairing a panel at InterConnect too by the way called: DevOps, It Takes a Village. If you are going to InterConnect come say hi!

As usual below is the streaming audio player, followed by the transcript.

Alan Shimel:                Hey, everyone, Alan Shimel, devopsy.kinsta.cloud, here for another DevOps Chat. I’m happy to have two people as our guests on this edition of DevOps Chat. I’m joined by two friends of mine from IBM, Chris Lazzaro and Peter Klenk.

Peter, Chris, welcome to DevOps Chat.

Peter Klenk:                Thanks a lot, Alan, glad to be here.

Alan Shimel:                Okay. Peter, why don’t we start off by just giving our audience a little bit of background on your position and who you are at IBM?

Peter Klenk:                Sure. I’ve been at IBM a while doing a lot of various type things, but as we try to become a cloud company I’ve become the product manager for pretty much everything DevOps in the cloud, so how we promote working, the kinds of tools we’re offering in the cloud and so on.

Alan Shimel:                And, Chris, how about you?

Chris Lazzaro:           I’m Chris Lazzaro. I’m the lead architect for the Bluemix Garage Method. The Garage Method is where we try to teach customers how to be successful in the cloud, adopting best practices for DevOps and really act like a startup.

Alan Shimel:                With scale like in enterprise.

Chris Lazzaro:           Yep, and meet those enterprise demands.

Alan Shimel:                Absolutely. Gentlemen, obviously the cloud is not new. It was funny. I spoke to someone the other day and they were with another large provider such as IBM, and they were transferred internally. They said, “Well, yeah, they wanted me to go to IOT and stuff because that’s where all the growth is.” I said, “What about cloud?” He said, “Oh, cloud is old news already. That’s not as strategic anymore.”

I must admit I was somewhat blown away because everything I’ve seen says while most or the overwhelming majority of organizations have some infrastructure in the cloud, it’s a relatively small amount of their total infrastructure and the greater migration is certainly ahead of us.

Peter, you are DevOps in the cloud. What are you seeing? Is that true, not true?

Peter Klenk:                The reality is I think most enterprises have been experimenting in the cloud, doing pilots, doing some innovation projects, but the bulk of the workload in the world is still running in a more traditional infrastructure. We still talk to a lot of mainframe clients. We talk to certainly a lot of on-prem datacenter clients.

There are kind of two things going on. Getting to the cloud is part of it, but I think the bigger question they ask is: how do we get more efficient, more developer productivity, more team productivity, more essentially rapid innovation, reduce the time to feedback from our clients, so that the systems we’re building stay relevant and don’t get disrupted by all these kind of born on the cloud enterprises, which we see popping up in every industry, like in entertainment, you name it?

Alan Shimel:                Yeah. Chris, when we talk about Bluemix Garage Method and stuff, there is a certain element of that, right, taking what these startups, these, as Peter said, born in the cloud sort of startups, some of what’s in their DNA and trying to – I forgot the word of the program we use to edit DNA now, not Zipper, but whatever – trying to –

Chris Lazzaro:           CRISPR.

Alan Shimel:                CRISPR, you’ve got it – trying to transplant some of that DNA into these enterprises. That’s what you guys spend a lot of your time on.

Chris Lazzaro:           We are trying to bring that rate of innovation that’s possible in the born on the cloud kind of startups, and then teach everyone how to utilize the cloud in order to get those innovative ideas that are out there as quick as possible, and reduce those barriers from going from idea to production.

But like you said, there are a lot of enterprises out there where the backend systems of record are mainframes or just data that simply won’t ever be able to move to the cloud, and that’s why hybrid cloud is so important. Some of these new technologies like IOT and cognitive, you can start experimenting with those and still connect them back to your on-premise infrastructure.

Alan Shimel:                Yeah. You know what? Certainly IBM is going to be the last company that tells you, “You should move off your mainframe.” But you’re right. People aren’t going to move off their mainframe, but that doesn’t mean there are some things that remain on your enterprise mainframe system and some things that are better off in the cloud, and you do have this sort of hybrid, not one-size-fits-all, and you do what’s best for that individual need. Sometimes it is staying back in the datacenter. Sometimes it’s moving up to the cloud.

Peter, I think you hit it on the head in saying it’s all about improving productivity. If it feels good and if it’s better for the company, then do it – to paraphrase a 1960s thing.

Of course, gentlemen, this is a big part of the whole Bluemix – not Bluemix Garage Method, but the Bluemix platform in general in the cloud. Correct, Peter? And that is to make developers or make developing more productive and more efficient. Fair enough?

Peter Klenk:                Yeah, fair enough. I think what Bluemix is has changed since we launched it a couple years ago. I think maybe this is just indicative of what’s happening in the cloud in general, but we started talking about very specific runtime environments and you’re going to run workload on the cloud.

It certainly is that and Bluemix has infrastructure. It has cloud foundry. It has containers. It has a serverless programming model called OpenWhisk. There are plenty of ways to run your workload in the cloud.

But it’s also this catalog of services you can use in your application. How is that related to developer productivity? Well, no one is going to build a NoSQL database or a natural language processor or a cognitive sentiment analysis or any of these types of frameworks on their own anymore. You’re going to use services, and that’s a big part of what the platform is, is this rich catalog of services.

It gives you a leg up in building the application for your domain, leveraging new direction models, cognitive models, IOT-type sensors and feedback systems.

Alan Shimel:                I think it’s even more than that, Peter. You mentioned NoSQL. No one wants to stand their NoSQL up themselves, their NoSQL infrastructure up themselves. And certainly what we’ve seen with Mongo recently around security issues, it’s nice to know that you have an IBM, right, and everything they bring in the way of security, standing behind your Mongo service that IBM has stood up for you.

I think that’s a big part of it. Who can afford to really do it right?

Peter Klenk:                I think that’s something we bring to the table. If you look at our catalog, we’ve got open source-based things. We have third-party things. We have IBM homegrown things, like the whole Watson set of cognitive services. But with them all comes – you know, it’s a foundation of scale and security and global distribution with points of presence around the world, but you need an IBM-scale kind of partner to deliver.

Alan Shimel:                Yeah. Chris –

Chris Lazzaro:           So it’s that –

Alan Shimel:                I’m sorry; go ahead.

Chris Lazzaro:           It’s that ability to get a small application or a minimum viable product up and running very, very quickly using a platform as a service or a cloud, but then being able to scale it as required and to add those DevOps tools, the management and monitoring tools or deploy it across multiple datacenters with multiple instances. So the complexity can grow as you start gaining customers and being successful with your app.

Alan Shimel:                You anticipated my question. That was exactly it. Really, that is sort of – because when you look at how most startups operate, they don’t create to scale immediately. It’s not build it and they come. They build it small and as they come they kind of build it bigger.

I come from that world I should add. I spent 25 years in that world. It just seems to me to be a no-brainer to say, “Geez, if I can partner with someone who can bring me that instant scalability, and not just the cloud infrastructure as a service, but the whole kind of scalability that a Bluemix brings to me, just from a DevOps perspective that just has to make things much easier.” But it’s much more appealing and it’s probably much more economical.

Peter, agreed?

Peter Klenk:                Yeah, agreed, and you got to the DevOps point, which is to me is part of that whole cloud picture. It’s the platforms, the services, but it’s also the way of working, which is what the Bluemix Garage Method is all about. Chris can elaborate on that, but it’s meant to be a set of practices that teams will adopt, potentially incrementally. It’s not everything will apply to everyone out of the gate, but it’s kind of the foundation of how effective DevOps teams work. Then we back that up with a set of tools that represent the kinds of tools that support those practices.

Similarly, everyone needs a place to store to their code, and a way to build it and push it onto a runtime on a platform like Bluemix. But, let’s face it; most of the world has on-prem stuff. They might be dabbling in other clouds. So it’s really deployed multiple places often.

And for that little startup mentality maybe that’s all you have, but as you grow you’re going to want to add different kinds of testing. You’re going to want to move the code through more environments, to expose it to different kinds of scenarios around performance and scale and security and vulnerabilities. You’re going to want to probably have more rigorous change management policies about what gets allowed into production with what level of review.

So when we build out the DevOps offering, we’re providing point tools. We’re partnering with point tools. But we’re really focused on how they integrate together and how they can be simple for the teams that really are just starting out, the kind of – I won’t even say two pizza teams. I’ll say the one pizza teams – but then grow up with those teams and then with those whole organizations, where now they’re deploying multiple apps across multiple runtime environments, multiple clouds, and manage the rigor and complexity that comes along with that.

Alan Shimel:                Agree. Guys, as often happens here, our time starts getting ahead of us or behind us, but I wanted to come back to there is some new news around continuous delivery on Bluemix. I don’t know. Peter, are you the better person to share with our audience or is that a Chris thing?

Chris Lazzaro:           Well let me set the context first and then I’ll hand it off to Peter.

Alan Shimel:                Great.

Chris Lazzaro:           There’s two really key points. One is as we look at DevOps methods and help people define that, IBM’s definition really starts with idea. It’s everything from going from idea to production and then managing and scaling that up.

So we start off with design thinking, and that’s really important to really get that into your DevOps process. From there it’s all about reducing the barriers of bringing that idea into production, and you want to get rid of all the barriers and friction points. You need not just a platform that can support you, but also a set of tools that enable continuous delivery, so that your developers are curating and getting that right out into production.

That’s where the continuous delivery service really helps. Peter, do you want to talk about that?

Peter Klenk:                Sure. We just announced at the end of last year a new service in the Bluemix catalog called Continuous Delivery. It focuses on a few things. One is the continuous integration, continuous delivery pipeline. But another is managing the set of tools and the integrations that a team is going to need to do the whole job around software delivery.

One thing we find in the enterprise is that it’s easy for a couple of folks to go off and start downloading a bunch of different tools, and getting them to run somewhere and use them like in their little project because maybe they’re motivated to try new stuff, but to then scale the successful patterns across the enterprise is really hard. Not everyone is as motivated. Not everyone wants to do the research to figure out what’s going to work in their environment.

So in addition to that continuous integration, continuous delivery pipeline, we have this first-class concept called Toolchains that can be captured in templates, so that you can easily provision new teams onto, say, a source repository on an agile plan or an issue tracker and CI/CD patterns that have the right kinds of jobs and environments in them, to give you a way to just quickly bring new teams into this modern world of tools and practices.

Alan Shimel:                CI pipelines, sure. Peter, if someone is interested in kind of toying, messing, experimenting with Bluemix continuous delivery, do you have to be on Bluemix to do it? Does it have to be on public cloud? Where could they get more information on that?

Peter Klenk:                They can start reading about it at Bluemix.net/devops. If you have a Bluemix account, you have everything you need to get started. If you don’t, that’s something you can easily create, no monetary commitment. The service right now is free. I imagine it will remain free for small teams that just want to start trying it out. So it is running in the public cloud.

We do have something called Bluemix Dedicated, which is a single tenant instance of Bluemix for certain enterprises that want that, and the service is also available there.

Alan Shimel:                So private cloud, is that not in style anymore, Peter?

Peter Klenk:                I think that’s fair. I think there are different ways to –

Peter Klenk:                Yeah. The key point here is it’s a single tenant instance, but it’s the full Bluemix stack. So our service is available that way as well. But for tire kickers, go to the public cloud, Bluemix.net/devops.

If you’re not quite ready for that, Chris, Garage Method. How do you get started over there?

Alan Shimel:                We’re going to come back to that in a second, before I lose my train of thought, because it doesn’t take me much. Peter, you mentioned the toolchain aspect of Bluemix and the continuous delivery in the stuff you’re putting together. If someone is experimenting or testing the Bluemix continuous delivery, can they add other tools to the toolchain, sort of maybe do a custom integration?

Peter Klenk:                They can. The pipeline is highly customizable through scripting. There is a set of integrations, the third-party tools available, kind of no box because it’s on the cloud, but virtually out-of-the-box. And certainly then in the applications they’re building, they certainly have access to all the other services in Bluemix as well. So there is some cool stuff.

Alan Shimel:                Got it. Chris, let me come back to you. We mentioned Watson earlier. I remember last year at InterConnect I was kind of blown away when I realized Watson was going to be on Bluemix. With APIs anyone can hook into Watson. I met some lady who in no time created a custom dating site where Watson was picking your dates for you. I mean I’m married, it didn’t me any good, but it was still an interesting concept.

But, Chris, when we talk about this Bluemix continuous delivery, does it work with Watson and some of the other services? And is that something we can do with the Garage Method and so forth or no?

Chris Lazzaro:           The continuous delivery pipeline can definitely work and deploy cognitive or Watson applications. We’ve got a number of examples of those on the Garage Method site. So if you just Google Bluemix Garage Method you’ll get there.

What’s really neat is that with these toolings and this platform, you can deploy an application that’s making use of the giant Watson cognitive capabilities and then easily tie in your logic to that. So you just plug into Watson as if it was a regular service.

Alan Shimel:                Excellent.

Chris Lazzaro:           So we’ve got those courses out there that walk you through it. The other place to get started would be at InterConnect this year. We’ll be having a lot of workshops and training and sessions at the InterConnect conference.

Alan Shimel:                Let’s talk a little bit about InterConnect. Of course it’s coming up. It’s moved back a little bit this year. I believe it’s in – is it late March now or April?

Peter Klenk:                March.

Alan Shimel:                Peter or Chris, you don’t have the exact dates, do you?

Peter Klenk:                I will in a second. I want to say March 20 –

Alan Shimel:                Yeah, like March 20 to –

Alan Shimel:                I know the 22nd is a Wednesday and that was a big thing. I’m speaking there as a matter of fact. I just got all my speaker kit stuff today.

Peter Klenk:                The 19th through the 23rd at Mandalay Bay in Las Vegas.

Alan Shimel:                Yes. Guys, we might as well end things off then with an InterConnect question. What are you most looking forward to this year at InterConnect?

Peter Klenk:                Feedback.

Chris Lazzaro:           I always love the expo floor and being able to talk directly with the clients and get that feedback and just see the cool things that are being developed.

The other session or workshop actually that I’m looking forward to is the one around the method, where attendees will actually – by the end of the workshop they’ll have applications up and running in Bluemix that cover all the phases. So they’ll have the tooling plugged in for managing the app and the continuous delivery tools as well.

Alan Shimel:                Got it. Peter, what about me?

Peter Klenk:                For me it’s feedback. Last year at InterConnect we were certainly talking about the method and different tooling approaches and we had some previews, but it’s different now that we have our service out there in the Bluemix catalog with real users doing real applications and solving real problems. So I just want to hear from them and also hear some more perspectives from clients and other companies in the business about the trends they’re seeing.

We’re going to have a couple good panels with some of the other DevOps companies. So that and then clients talking about the kinds of apps they’re building on the cloud is always fascinating.

Alan Shimel:                I always enjoy talking to clients as well at InterConnect. It’s great stuff. And I will just mention that if you really want to sit in on a great session, there is one called “DevOps: It Takes a Village.” I’ll be hosting that one. I want to say it’s Wednesday at 9:00 AM at Mandalay Bay, but I’ll put more on that at devopsy.kinsta.cloud in the near future. Just a little personal plug guys. I’m sorry.

Peter Klenk:                Shameless.

Alan Shimel:                Shameless on me. Anyway, guys, I look forward to seeing you both at InterConnect. We’re actually going to probably have some devopsy.kinsta.cloud surprises there in terms of our coverage. So maybe we’ll get a chance to sit down and chat.

But for now, Chris Lazzaro, Peter Klenk, thanks so much for being our guests on this episode of DevOps Chats, and we’ll see you in two months or so out in Vegas hopefully.

Chris Lazzaro:           Sounds good. We’ll see you there.

Peter Klenk:                Always a pleasure.

Alan Shimel:    Okay. Chris Lazzaro, IBM Bluemix Garage Method, and Peter Klenk, IBM Bluemix and Cloud Services for DevOps, thanks for appearing on DevOps Chats. This is Alan Shimel of devopsy.kinsta.cloud hoping to see you on another DevOps Chat.

— Alan Shimel

February 9, 2017
DevOps Chat: Ken Cheney, Chef on AWS OpsWorks for Chef Automation

devopsy.kinsta.cloud catches up with Chef’s busy CMO Ken Cheney. Ken give us the inside look at AWS’s OpsWorks for Chef Automate. While this is an AWS offering it is based on Chef and is a pretty big bet by AWS on Chef. In addition Ken brings us up to speed (pun intended) on other things regarding Chef. Ken is always a great person to chat with and full of great info. We are going to have Ken on every month or so, we can count on hearing more Chef and DevOps talk soon.

In the meantime, as usual the streaming audio of our conversation is below and the written transcript of our chat follows. Enjoy!

Streaming Chat

Transcript

Alan Shimel:                Hi, everyone. This is Alan Shimel, devopsy.kinsta.cloud, here for another DevOps Chat. I am happy to be joined in this episode of DevOps Chat by Chef CMO, Ken Cheney.

Ken, welcome.

Ken Cheney:                Alan, nice to hear your voice again.

Alan Shimel:                Nice to hear from you, Ken. Actually, I think the last time you were on our podcast or the last time we spoke you had maybe just been appointed CMO, or maybe it was even before you were appointed CMO at Chef, but it’s certainly been a busy time for you I’m sure.

Ken Cheney:                Yeah, it has. There’s been a lot going on in the past two months and some of it we’re going to talk about today, the work we’ve been doing with AWS.

Alan Shimel:                Yeah. I think the last time I spoke to you was right before AWS re:Invent, and there was some big Chef news coming down the pipe that we weren’t able to talk about then. It was still kind of under embargo, but it certainly is fair game now.

So, Ken, why don’t you share with our audience what was big for Chef at AWS re:Invent?

Other Great DevOps Chats to listen to:

DevOps Chat: Nigel Kersten, Puppet, 2017 DevOps Survey
DevOps Chat: Huw Price, Smart Automation Is Key
DevOps Chat: InterConnect 2017 w/ Randy Newell, IBM DevOps
DevOps Chats: Aruna Ravichandran, Co-Author, DevOps for Digital Leaders

Ken Cheney:                First off, AWS re:Invent, a super-impressive show to go to. So if folks haven’t gone, I’d recommend this next year that they pencil it in. But at re:Invent we announced – actually AWS announced, it’s their offering, a new offering called AWS OpsWorks for Chef Automate. It really brings for the first time the full capabilities of Chef’s commercial platform to AWS as a managed service offering. So they provide support and they backup the offering 100 percent.

So it’s a new offering that makes that job of configuring, deploying, scaling, both in the cloud as well as on-premise infrastructure simple and secure. We get there by really doing what Chef has done best over the years, which is automating infrastructure as code.

I think to really highlight what I said, Jassy at re:Invent went out of his way to make the point that hybrid is the new normal in their view. So what’s interesting about what we are doing with AWS is you can manage both in the cloud with AWS as well as your on-premise workloads, and you can have that consistency in how you manage your resources across both.

Alan Shimel:                Absolutely. Now, Ken, our audience may not be aware, but I happen to have known this, that Chef was sort of the dominant tool in use for AWS customers now for a few years; I mean an outrageous amount. If I’m not mistaken, wasn’t it like 65 or 70 percent of AWS customers who use some CM are using Chef?

Ken Cheney:                Yes. A large proportion of AWS customers use Chef, and AWS themselves use Chef for many of their core services. It’s a platform that is really well suited to the job of: how do you get your workloads to the cloud, and how do you manage those workloads on an ongoing basis in the cloud?

Alan Shimel:                Absolutely. And of course, Ken, when we talked about hybrid – I actually had a conversation yesterday, actually with maybe some IBM folks. We were talking about mainframes aren’t going away any time soon, obviously, the mainframe market. It’s probably bigger than ever in terms of dollars.

But the idea of working with your systems of record and systems of engagement, and one is on a mainframe and one is in the cloud, is becoming more and more the norm for large organizations, right?

Ken Cheney:                Yeah. It really is.

Alan Shimel:                Yep. I mean they’re not going to just walk away from billions of dollars invested in mainframes and datacenters, but in order to compete with stuff that lends itself to it, it’s hard to beat the economics of the cloud. So for the foreseeable future anyway, probably the rest of our working lives, Ken, hopefully, hybrid cloud is going to be the dominant form there.

Ken Cheney:                Right. Then if that is the case, then manageability and that kind of consistency in your manageability becomes front and center, and that’s where Chef plays a big role in being that bridge that really allows you to have a platform where you can store those configurations in one place, where your resources are going to work perfectly every time at scale, and you make changes in that single place and propagate those changes across those environments. So whether you’re running under a mainframe environment or you’re doing dev, test, prod in the cloud you get that repeatability.

Alan Shimel:                Absolutely. Before we leave the AWS stuff though, Ken, I just want to, for our audience that may be interested, this is available now, today, through the AWS marketplace?

Ken Cheney:                No. It’s a core AWS offering.

Alan Shimel:                Okay.

Ken Cheney:                So if you’re an AWS customer, you login through the AWS console and it’s one of the offerings that you can select. So it bills through AWS. It’s managed by AWS. It’s supported by AWS. So it’s very easy if you’re an AWS customer to get started, and you can get started for free, up to ten nodes for free per month.

Alan Shimel:                Great.

Ken Cheney:                Yeah. You can get started and get all those advantages.

Alan Shimel:                That’s cool. All right, so people can go check it out right now. If you’re using AWS, it’s a core offering. And I guess that kind of makes sense because it is an AWS offering after all, isn’t it?

Ken Cheney:                That’s right. We’re partnering very heavily with them to make sure it gets the kind of traction and success that we have envisioned.

Alan Shimel:                You know what? That really is big news, Ken. Great job by the Chef people. Give my kudos to the business development guy. He did a hell of a job there.

Ken Cheney:                Will do. Thanks, Al.

Alan Shimel:                Weren’t you the business development guy, Ken?

Ken Cheney:                I was. I’m weird, so –

Alan Shimel:                Yeah, I know, just a little inside Chef joke. Ken, we talked a little bit about hybrid cloud and this new offering at AWS. Let’s look at the bigger picture. Here we are in January of 2017 and it’s not too late yet for – where do you see DevOps in 2017? Where do you see Chef in 2017? What big picture item should we be looking at?

Ken Cheney:                What’s interesting right now in the market is that – you and I both see this, Alan – the market is still very young. I saw some Gartner data where you can extrapolate out that 90 percent of the market is still untouched. Even that 10 percent that has started down the path of adopting is only partially adopting.

Yet what’s very clear, both at an industry level, if you look at industry data, as well as what we see with our own customers, is that DevOps has a significant impact on the bottom line. Companies that adopt DevOps have been shown again and again to outperform their competitors.

Alan Shimel:                Yep.

Ken Cheney:                And I think that DevOps – we’ve been talking about this for some time – but it’s really a full-on move from the early adopters, those organizations who figured out how to be disrupters, to the rest of the market who are being disrupted.

Alan Shimel:                Yeah. It’s DevOps or die, as I like to say.

Ken Cheney:                That’s a great statement.

Alan Shimel:                Yep. Ken, I saw some interesting statistics from a study that CNA had commissioned, 1,700 respondents, and it said something like only 34 percent, so just a third of organizations had adopted DevOps.

Ken Cheney:                Right.

Alan Shimel:                Which to me and probably to you too, right, because how many organizations do we talk to that either haven’t adopted DevOps or don’t want to adopt DevOps? We live in a DevOps bubble. We think everyone does, but yet the fact is it’s only about a third, 34 percent. When you look at it that way, it’s barely mainstream, right?

Ken Cheney:                That’s right. And even those who have adopted it typically adopted it in a small silo.

Alan Shimel:                Right, the pockets of DevOps, as they call them. I continually refine that, Ken. What I mean by that is you’ll have a team – a team – using DevOps, maybe a team here and a team there, but only when those multiple teams come together under a common DevOps sort of processes, framework, manager, whatever, do I really consider the organization doing DevOps. So for me, an organization that’s doing DevOps is doing it with multiple teams.

Ken Cheney:                Yeah. I totally agree, and I think this is the year where we start to see organizations really at an executive level begin to put their shoulder into what that means. How do you actually begin to go automated scale?

And at the same time they’re going through the tech modernization investments around embracing the cloud, embracing microservices, containerization. So I think this is going to be a really interesting year, where I expect many traditional shared services organizations are going to be under a lot of pressure to change.

Alan Shimel:                I agree 100 percent. It goes back to the DevOps or die thing. All kidding aside, if these organizations don’t change you’re going to start seeing them falling by the wayside.

But you know what else I think, Ken, and I’m interested in your opinion on this. DevOps tools have to change, too. They have to continue to mature. They have to continue to be enterprise-ready. They have to continue to deliver and meet the challenges that organizations are faced with.

Ken Cheney:                I totally agree. I think that there’s been a Cambrian explosion of tooling.

Alan Shimel:                Yes. That’s a great phrase for it, a great way to put it.

Ken Cheney:                Yeah. And there’s been a rapid kind of organic team level adoption, but what’s happening is that there’s been a lack of standardization, a lack of scale. When you look at the disrupters who have been wildly successful, and many of those are Chef customers, they have been successful automating at scale. Automating at scale means you do drive consistency across the board.

The path to get there though, from my view, is you have to be thinking about vertical integration. If you look at our strategy, like take what we announced at AWS, that is where we are actually vertically integrating into their platform in a very real, meaningful way. And we feel the same way about the broader ecosystem of _____ capabilities that we need to integrate in with, to make that job of automating at scale easy.

Alan Shimel:                Yeah, agreed. I do think you’re onto something with that, also vertically integrating, but it’s also integrating into the IT stack. For instance, for me and maybe it’s my own personal bias and history, if you look at 2017 as a year where we have to see security integrating with DevOps and we can call it DevSecOps or Rugged DevOps – I don’t really care what you want to call it – but there has to be that tighter coupling, that tighter integration into the IT stack of security shifting left as part of this DevOps.

I know Chef obviously has now some history in trying to bring compliance at scale and compliance in security and speed. But I think that has to accelerate.

Ken Cheney:                Yeah, it does. We are pouring the investment into that set of capabilities. When we look at what our customers are trying to get done, there are things like driving known vulnerabilities down to nothing, being able to remediate in minutes as opposed to days. To get there, that concept of shift left that you put forward is front and center. You have to start thinking about shifting risk to the left.

So we’ve invested a lot in, one, our InSpec open source framework that people should go check out, as well as the overall compliance capabilities, where you can have broad compliance profiles that ensure that the state of your infrastructure and applications is conforming to policy.

Alan Shimel:                Got it. You know what, Ken? You mentioned open source and it triggered something. What’s happening with Chef Habitat, anything new you can share with the audience?

Ken Cheney:                Yes. Chef Habitat has been in the market now for about nine months. We have been seeing a tremendous amount of traction. We’re going to be launching a Habitat road show in a few weeks, visiting multiple cities. So people should go to the Chef website and see if we’re going to be coming to a location near them.

We are really now moving into the phase where we have large enterprise customers moving workloads into production with Habitat, and they’re really targeting that job of: how do I easily encapsulate my applications and manage those applications, in a way that I don’t have to spend a lot of calories worrying about extraneous services and getting true portability out of it, meaning I can move that application workload anywhere I want?

So Habitat is definitely getting legs at the moment. We’ve had some new product news that will hit in a couple weeks, Alan, so you and I will be talking about that.

Alan Shimel:                Fantastic. All right, a little teaser. Ken, to tell you the truth, we’ve gone way over our usual time that we allot for podcasts. We don’t want to take up too much of people’s time, but let me just do a quick recap. For people who want to find out more about Chef Habitat, what’s the URL?

Ken Cheney:                They go to the website, which is Habitat.sh or they can go to the Chef site, which is Chef.io.

Alan Shimel:                Right, and it’ll just run through from there and they can find out about the Habitat road show there. The Amazon stuff you can get right through your Amazon portal or dashboard, if you’re an AWS user.

Ken Cheney:                That’s right. AWS just did a webinar yesterday that was recorded that does a nice walkthrough on it. So they are actively out there promoting it and pushing it for their customers.

Alan Shimel:                And the open source compliance and security?

Ken Cheney:                You can get that through the Chef website.

Alan Shimel:                Also.

Ken Cheney:                Yep.

Alan Shimel:                Okay. I just want to make sure people get it, Ken. Ken, we could probably spend hours talking. We’ll have to have you back on soon, maybe in a few weeks when you have your next bit of news. But until then, keep up the great work. Oh, we should mention ChefConf.

Ken Cheney:                Oh yeah, ChefConf coming up May 20th to 22nd in Austin, Texas. People can go and register today. We’re pretty excited. We just closed the call for papers last night and had a record number of submissions. So it’s going to be a great event.

Alan Shimel:                Cool. I went last year. It was a great event. I had a great time. It was some great content. The Alaskan Airlines was still my favorite, Ken. Actually it got me to fly Alaskan Airlines watching that guy present.

Ken Cheney:                It was amazing, yeah.

Alan Shimel:                It was the first time I ever flew them, and I was counting to see how quickly the door closed and how quickly they opened it, from his whole presentation. It was a great one.

Anyway, Ken Cheney, CMO Chef, thanks for being our guest on this episode of DevOps Chat. Continued success at Chef and we’ll be watching and listening to find out what’s new.

Ken Cheney:                Thank you, Alan.

Alan Shimel:                All right. Okay, everyone, this is Alan Shimel for devopsy.kinsta.cloud and DevOps Chat. Thanks for listening and we’ll see you on our next DevOps Chat.

— Alan Shimel

February 8, 2017
DevOps Chat: Nigel Kersten, Puppet, 2017 DevOps Survey

I had a chance to sit down recently with Nigel Kersten, chief technical strategist at Puppet. Besides the fancy title, Nigel is one of the smartest, nicest people you will meet. Always a pleasure catching up with him. We spent most of our time speaking about the Puppet 2017 DevOps survey, which is now open right here.

We also spoke about some of the findings of the past five annual DevOps surveys and the DevOps space in general. Great, informative conversation. As usual, the streaming audio of the our chat is below, followed by a written transcript. But please remember to take the 2017 DevOps Survey. Enjoy!

Alan Shimel: Hi, everyone, Alan Shimel, editor in chief, devopsy.kinsta.cloud here, for another DevOps Chat, and today’s DevOps Chat guest is none other than Nigel Kersten, chief technical strategist at Puppet. Nigel, welcome back.

Kersten: Hey, Alan—thank you. It’s great to be back, and always good to talk to you.

Shimel: Absolutely. Nigel, you know—well, first of all, it’s always great to have you on the show, and we’d love to have you on as often as we possibly can, but specifically today, I wanted to talk a little bit about—it’s that time of year again where Puppet will be launching their, the annual DevOps survey, and I wanted to spend a little time talking about it and cluing our audience in, into what’s in store for this year.

Kersten: Absolutely. Always happy to talk about the survey. So I think, you know, this has been—we’ve been running this for quite a while now, this is now the sixth year. And I think one of the things that’s really fascinating about the survey is, we survey generally technical practitioners, but also managers as well. But, in the course of surveying all of these practices and technical behaviors and how teams communicate with each other, we end up coming to a bunch of really great conclusions around the actual business outcomes.

And this is why I think it’s so important for people to be going out and filling out this survey, because I see customer visit after customer visit, every time I’m out there on the road, so many people come up to me and say, “We’ve been trying to change the way we work inside our company, and your surveys turned out to be a really useful tool for handing to our senior management, and saying, ‘This is the sort of outcomes we can expect if you let us work the way we actually want to work.’”

Shimel: Yes. And you know what, Nigel, just a little bit of a frame of reference, I got the number while I was at Gene’s last DevOps Enterprise Summit in San Francisco, but I was speaking to Nicole, Dr. Nicole Forsgren. What was the total—you may not know—but the total amount of people who have taken this survey at this point over the past five years?

Kersten: There are actually over 25,000 people, which I think is fantastic, and particularly even in the first few years, we’re definitely really focused on the sort of North American market. We’ve been seeing this growing more and more in Europe, in Asia, and we’re starting to see that, really, DevOps has become a global movement and is being recognized as such within the enterprise, not just sort of the, you know, webscale hacker groups.

Shimel: Yeah. Well, that’s certainly for sure. And Nigel, this year, is Dr. Nicole—well, they’ve actually started a company now around DevOps statistics and research.

Kersten: Yeah, so we’ve been working with Dr. Nicole Forsgren and Gene Kim, who many people know from the author of, “The Phoenix Project,” and ex-CTO of Tripwire, and the inimitable Jez Humble, who many people know from his Lean Enterprise and Continuous Delivery books. We’ve been working with them for about the last four or five years and, yeah, this year they’ve formed a new company called DORA—DevOps Research and Assessment—where they go in and help companies do benchmarking around their actual sort of DevOps practices.

Shimel: Yep.

Kersten: And so I think that combination of industry experience, great sets of contacts, and really, the statistical rigor that people like Nicole actually bring to this—

Shimel: Exactly.

Kersten: —make this to be much, much more than just a vendor survey. Because it’d be easy for us at Puppet to just survey the Puppet user base and come to a bunch of conclusions. But I think the really interesting fact is when we get to talk to people—more people than are just using Puppet, people across the whole industry, some people who are just coming to DevOps for the first time.

Shimel: Sure.

Kersten: So I’d really highly encourage anyone who’s listening, you know, go out and fill out the survey when we launch next week, and don’t just feel like, “I don’t really know very much about DevOps, I shouldn’t fill out the survey.” We’re really looking for input from people all across the spectrum.

Shimel: Absolutely. And of course, Nigel, by the time people hear this, it will be next week, and we will include the URL in the show notes so that people can click right out of this article to the survey.

Kersten: Excellent.

Shimel: Nigel, I don’t know if you would know this, even, but is there sort of a shortened URL that people can look for, to go to?

Kersten: Yeah, we’ll give you a shorter URL by the time we actually launch this podcast out.

Shimel: Okay. Not a problem. We’ll put that in there. So Nigel, six years in, though, if you’re not moving forward, you’re dying, right? [Laughter] As they say. What’s different about the survey this year?

Kersten: Yeah, so I think we’ve really shown, over the last few years, that there’s a couple of practices that have really been formalized when it comes to DevOps enterprise adoption. We’ve seen that things like version control being heavily used in operations teams and that infrastructure being shared with your development groups, we’ve seen the role of continuous delivery and lean product management practices. So we really feel that, over the last four or five years, we’ve really shown a bunch of this stuff, that it really isn’t changing very much.

So we’ve switched focus a little bit this year. So one of the interesting things we’re really looking at are the role of infrastructure architecture patterns in DevOps environments. And I don’t just mean, you know, “Are you adopting containers, are you doing macroservices, service-oriented architecture?” But we’re really looking for information on, architecture-wise, in terms of the way your application is set up, is your team self-sufficient and autonomous? Can you make changes quickly on your own, without lots of dependencies across the organization, and can you experiment really quickly?

Because I think we’ve seen from Agile and from all of the DevOps enterprise movements over the last few years that the ability to do small tests and iterate quickly on the results of those tests to set your larger direction is really critical to both advancing your service, but doing so quickly and more reliably. Because I think that’s been one of the really huge sort of new things for senior management who haven’t been so familiar with these practices to realize is, adopting DevOps practices doesn’t actually mean sacrificing quality for speed or vice versa. It actually means you’re producing better, high-quality software more quickly.

Shimel: Absolutely. So, Nigel, as I think you mentioned, this week, or the time people are listening to this, the survey will be open. Just in terms of time frames, how long will it be open and when do you think people might start getting a look at some of the data in the report?

Kersten: Yeah, so we should be launching later on in the year as far as the results go. We tend to leave it open for at least a few weeks. Some of that sort of depends upon, you know, making sure we get a sufficiently large statistical base to get the conclusions that we’re actually looking for. So, the faster people want to see the results, the faster we want to see them fill out the survey. So, basically, head off and go and do it now.

Shimel: Right. [Laughter]

Kersten: As soon as we get that critical mass of data, we’ll be launching the results. So you’ll see us talking about this at Velocity, at the DevOps Enterprise Summits and a bunch of the different events happening.

Shimel: Oh, I’m sure, I’m sure—looking forward to it. And being written about on devopsy.kinsta.cloud, I might add. [Laughter]

Kersten: Absolutely.

Shimel: For sure. So, Nigel, if you were king for the day, you know—

Kersten: Okay.

Shimel: —what would you, you know, and you looked into your crystal ball, what would the headlines be from this year’s survey?

Kersten: If I looked into the crystal ball, what I would really like to see is that we’ve drawn some really strong conclusions around the benefits of DevOps practices in the public sector and in nonprofit organizations, because that’s been a constant source of feedback for the last few years, that we’ve managed to draw really great conclusions for profit-oriented companies.

But I think we’ve also seen, with the rise of the U.S. Digital Service in the U.S. and .gov.uk that’s been running for quite a long time in the UK and the Digital Transformation Office in Australia—we’re really starting to see some of these practices start to be applied to the public sector. And, honestly, that’s in all of our interests, for government infrastructure to work more efficiently and deliver better services that progress more rapidly to all of us.

So that’s something I would really, really love to see, that we can draw those conclusions, which I’m feeling pretty optimistic about. But I think the big headline I would like to see, continuing that thread of, “How do we make sure that the survey and the results in the report that we’ve come out with are useful for practitioners selling upwards in their organization, as well as senior leaders trying to implement change?” is—give your teams more autonomy. Make sure that you’re designing your infrastructure in such a way that they can test on their own, that they can rapidly experiment on their own, and that you can actually progress things much, much faster than we’re you’re needing lots and lots of meetings just to create major changes.

So the more we can actually absorb the lessons of service-oriented architecture, and not just create a mass of complicated services, but create clusters of services that teams can work on with a high degree of autonomy and flexibility. That’s really the headline I would love to see—teams that are able to experiment and are autonomous will produce better results for the business.

Shimel: Absolutely. Nigel, let me ask—go off on a little bit of another tangent, here. You know, one of the things that I kinda, I find fascinating and I tend to come back to and I get as much of as I can is the Project Blueshift stuff that you guys do at Puppet. Gareth Rushgrove is deeply involved in it. And while, today, you know, there’s certainly a strong container focus on it, it really is about sort of future-proofing Puppet, right, and making sure that the folks at Puppet are aware of, you know, what’s the next big thing coming down.

What can we look for in the survey that may give us a clue in terms of what is the next big thing and hence, you know, something for Blueshift to be aware of?

Kersten: Yeah, so I think we’ve generally tried to stay a little bit away from stuff that’s too vendor-specific research for us. But I agree—so you’ve totally captured what Blueshift is about for Puppet. It’s very much about us making sure that, you know, Puppet’s a highly successful project, you know, and used by tens and tens of thousands of companies across the world.

But we’re in a very fast-changing technology landscape right now and I think it’s really critical for us as a company to make sure that we’re not just resting on our laurels there. We’re seeing lots and lots of things change. It’s entirely possible that, in 10 years’ time, everyone will be on completely serverless infrastructure, so to speak. And, you know, you might have been able to hear my air quotes somewhat around serverless, because there’s always someone’s servers running that code somewhere.

Shimel: Right. [Laughter]

Kersten: That old saying that the cloud is just someone else’s server.

Shimel: Uh huh.

Kersten: And I think, really critical for us, we’ve seen that Puppet, the language, has been an incredibly portable model. We started off in the UNIX and Linux space, and it’s proven to be hugely successful in the Windows space for a lot of our enterprise customers, and people really like having that common language describing all of your infrastructure. And we see no reason why, just as you’ve seen the Puppet container build stuff that we’ve done, that we can use the Puppet language to describe and compose containers and maintain that audibility.

We can also describe all sorts of infrastructure, no matter where things come from. So, for us, Blueshift is very much about keeping that eye on the sort of next level horizon over the next six to 24 months, and just seeing what’s emerging and making sure that Puppet stays agile and that we start baking in the features to Puppet the language and the platform that will enable us to all take advantage of those things.

Shimel: Sure. And I—

Kersten: I think it’s really exciting. I don’t think we’ve seen infrastructure technology change as fast as this, ever.

Shimel: It’s crazy. And, you know, I don’t know if it’s the gadget boy in me or, you know, I’ve lived in tech for so long, but it’s that—it’s not even a Puppet thing to me, Nigel, it’s a thing. What is the next thing? I think it’s a little bit of how I got into DevOps, it’s a little bit of how I got into computers and technology to begin with. So I’m always interested and curious.

Kersten: Totally.

Shimel: And sometimes, you know, the nice thing about this survey is, it does cast such a wide net of responses that you—

Kersten: Yeah. And I wanna make sure that people don’t feel too left out as well. Because, you know, I often talk to people who are in big enterprise environments, managing important legacy applications, and some of them are still struggling with getting relatively basic principles adopted—of just using version control, using infrastructure as code.

Shimel: Mm-hmm.

Kersten: And sometimes you talk to them and they get a little demoralized, going, “You know, everyone’s talking about all this cool technology out there, and we’re not actually getting to use it.” But I think the reality is, most enterprise environments, the software they’re running is delivering actual business value, and it’s important to keep making sure that’s as efficient as possible.

We saw from the “DevOps Handbook” that Gene and Jez and all of those people are involved in that you can apply these principles to mainframes, you know? You can see people taking incredibly legacy technology, applying these modern ways of working to them, and getting really, really huge benefits.

Shimel: Got it, got it. Nigel, we’re almost out of time, unfortunately. You know, we can talk all day, but people only listen, it’s the curse of the modern, you know, the 10-minute or the 10-second sound bite and the 12-minute podcast—but first of all, good luck with this here survey. You know, I encourage anyone listening to go, please click on the link and fill out the survey. Can’t wait to see what some of the results are this year.

Continued good luck with Puppet, too, as you guys are really, you know, coming out of Puppet Conference and meeting with Sanjay and some of the exec team, I was very excited about the possibilities, and I’m sure you are more than me—

Kersten: Absolutely.

Shimel: —about, you know, what’s on the horizon here for Puppet, so good luck with that as well. And thanks for being our guest on DevOps Chat.

Kersten: No problem, Alan. It’s always great to catch up with you.

Shimel: Okay, my friend. Nigel Kersten, chief technical strategist at Puppet, thanks for appearing on this DevOps Chat, and thanks for telling us more about the upcoming devops survey, or sixth annual devops survey from Puppet.

This is Alan Shimel for devopsy.kinsta.cloud. Have a great day.

— Alan Shimel

January 30, 2017
DevOps Chat: Aruna Ravichandran, Co-Author, DevOps for Digital Leaders

Our first podcast of 2017 is with Aruna Ravichandran, co-author of DevOps for Digital Leaders. Of course when not authoring books or helping financially challenged but gifted students attend college, Aruna is a VP of DevOps marketing at CA Technologies. I have interviewed Aruna before on DevOps TV and discussed her career that has seen her go from a million lines of code contributor at HP and Juniper to business line executive.

Aruna is a very interesting person who also has some great things to share. That is why I think you will find not only this DevOps Chat interesting, but her book as well. Also, we will be doing a full hour Q & A with Aruna on January 17th that you can sign up and attend for free. If you like this interview, don’t miss the webinar. Also, if you would like to download the book you can here: http://www.apress.com/us/book/9781484218419

In the meantime, as is usual on our DevOps Chats below is a streaming audio of our Chat with the written transcript below. Enjoy!

Alan Shimel:                Hey everyone, Alan Shimel here with our first DevOps chat of 2017 and we’re lucky to have Aruna Ravichandran, a VP DevOps Marketing at CA Technologies. Aruna welcome.

Aruna Ravichandran: Thank you Alan. Thanks for actually having me. I’m excited to be here with you.

Alan Shimel:                Well, you are leading of 2017 so we’re going to set the bar high right away Aruna and hope to live up to it.

But Aruna, truth be told, we don’t have you on today in your VP of DevOps role: you’re here as Aruna the author today and we’re going to talk about a book that actually came out I guess towards the end of last year but it’s still out there and we’re going to be doing a webinar on it later this month, and I wanted to really talk to you about that a little bit.

The book is called DevOps for Digital Leaders. Correct?

Aruna Ravichandran: Yes, that’s correct.

Alan Shimel:                And why don’t – just from the get-go why don’t you give our listeners a little bit of an overview of what the book is about.

Aruna Ravichandran: Sounds good. So this book is called DevOps for Digital Leaders, it’s all about how one can reignite their business with a modern DevOps-enabled software factory. I embarked on this journey on writing this book almost about a year-and-a-half ago along with two of my co-authors Karen Taylor as well as Peter Waterhouse.

We looked at all the different books within the market – there is no dearth for books in the market when you think about DevOps – but what we saw was that even though there are so many different books in the market nothing really talks about some of the pain points which we constantly encounter customers asking us when we talk to them.

Some of the pain points which customers constantly ask us are, “I want to be able to start this journey called DevOps. How do I start? What should my journey be? Where can I start? How do I develop? What should be my maturity model?” And so that’s one question which we constantly get across the board.

Second pain point which we have heard from customers is, “How do I actually measure the success of DevOps? What kind of metrics can I use? How is success actually going to look like which I can report back to my management chain that whatever initiative I have embarked on with DevOps is now actually successful?”

So we talked to several – over 100-plus customers – we learned from their experiences on what metrics are actually used and what is actually built practically in the industry and shared those in the form of use cases as well as actual metrics in the book.

So the book primarily focuses on DevOps adoption in terms of a journey as well as what are some of the key metrics one can actually use in order to embrace DevOps.

Alan Shimel:                Great. Aruna you hit on a couple things that are kind of near and dear to me. One is something that I’ve spoken about and talked to people now for a while which is too many people – you know, DevOps is so hyped and so many people are positioning DevOps to be, you know, it’s this great, white unicorn that’s crapping out rainbows for everyone but it doesn’t always work like that, right?

There are failures, there are challenges, there are hurdles, and not everyone who just wants to do DevOps can wave a magic wand and become a DevOps factory or a modern software factory. So I’m glad to hear that this is kind of something that you guys are exposing in the book.

The other thing is, you know, in almost three years of doing devopsy.kinsta.cloud now I find that our listeners, our readers learn the most from listening to how their peers have dealt with stuff: so case studies, case scenarios and these kinds of things. So the fact that you had access to hundreds – literally hundreds if not thousands – of customers who CA Technologies – CA has worked with – really gives us some great insight.

Can you give our listeners a little bit of a taste for the kind of – I know you call them case scenarios – and they’re kind of case studies, right? – can you give us a little flavor for what those are like?

Aruna Ravichandran: Yeah, absolutely. So if you look at the book it’s organized across the entire software factory. Let’s say if you think about customer deployments DevOps basically goes all the way down from planning to requirements to development, testing, release, and then into operations.

And so what we did was we talked to – we interviewed several different practitioners who are existing CA customers, sometimes we even talk to non-CA customers – understood the role DevOps plays in terms of culture and collaboration as well as the toolsets which they’re actually leveraging in order to implement DevOps within their companies.

And we looked at – we _____ the use cases around the whole software delivery to the chain. So if you look at the book – even though we talked with several thousand customers – you know, we couldn’t basically put all those case studies within the book, so what we did was we broke up the book across the entire software delivery chain and there is a chapter dedicated for every aspect of the software factory starting from planning to development to testing to release to operation and we leveraged one customer example on how they actually implemented DevOps best practices along with the underlying toolset and what are some of the metrics or the results they actually got in terms of being able to show what success actually looks like.

Alan Shimel:                Got it. So Aruna I wanted to touch on another aspect of DevOps adoption that you hit on in the book, and that is the idea that not everyone started their DevOps journey at the same time or are going at the same speed or at the same rate, right? Some organizations are relatively mature in their DevOps adoption and DevOps practices: others are still talking about starting. So is there something for everyone in the book or do you need to be sort of on-your-way DevOps expert to really get value?

Aruna Ravichandran: No. So, you know, like I said because we knew that there is no clear-cut framework, right – like if you think about I-_____ there is a very prescriptive framework in terms of where you can actually start and how you can actually end. With DevOps one can start many different ways.

So what we actually did was we looked at some of the best practices a lot of the customers have actually implemented and built a framework in terms of a maturity model and we shared that as best practices.

So if you think about accelerating the maturity we talk about, you know, three different examples of how customers could actually start. The first way is to basically build an end-to-end release management system; and the second one is to how can you operationalize with feedback loops going all the way from Dev to Ops and vice versa.

And the last one is how could you actually optimize the continuity stability pipeline?

So we shared some of the best practices in terms of where one can actually start and how they can actually modify their processes to give them a lifecycle regardless of where they want to start. They could start in Dev and end in Ops; they could start with Ops and make changes to Dev. But we shared some of the best practices in terms of maturity model which customers can actually implement.

Alan Shimel:                Excellent. Aruna, again, we only have 12 minutes or so on these podcasts but we’re going to spend about an hour – 45 minutes plus 15 minutes in questions – on an interactive Q&A webcast with you on this subject.

And I just wanted to, in our remaining time here, remind everyone or let everyone know that the webinar is scheduled for January 17^th – so about two weeks from today or so – a little less than two weeks – at 2:00 PM Eastern Time. And within these show notes – if you’re listening to this on Sound Cloud or iTunes – within the show notes there we’ll have a link to the webinar. And if you’re reading along or listening on devopsy.kinsta.cloud we’ll have a link to the registration there as well. You can get to the registration on devopsy.kinsta.cloud – go to the webinar section and of course it will be listed there.

But importantly Aruna I wanted to mention the book itself is free, correct, for download?

Aruna Ravichandran: So the software version of the book is free. If they want to get the hardcopy they can buy it through Amazon or through our publisher which is Apress. I also want to call out and say that if they buy a hardcopy version of the book we are donating all the proceeds – the royalty from the book are being donated to a nonprofit corps Foundation of Excellence – the Foundation of Excellence’s mission is to award university scholarships for exceptionally talented but economically underprivileged high school graduates in India in order to embrace stem carriers.

And so they can either go through the softcopy of the book or they can download the hardcopy and that all of their contributions are going to be donated to the nonprofit.

Alan Shimel:                That’s great Aruna. Fantastic. I also want to mention that for those who register and attend our webinar we are going to give out ten signed copies – signed by Aruna and her co-authors – to ten folks who attend the webinar. I have to mention that those are US-based folks only as the logistics of mailing hardcopy books make it prohibitive to send them across the oceans. But ten US attendees will win signed copies of the book and everyone who attends will get a link to download the soft version, and of course you can buy the hardcopy version – the hard-book version on Amazon or Apress. Again, we can register that at devopsy.kinsta.cloud.

Aruna, we’re almost here at the end but just to give some of the people – some of our listeners a little tease of what we’ve got going on. I know there’s some CA-sponsored DevOps research that’s due out shortly and that kind of reinforce this idea that organizations that do DevOps are doing better. Can you give us a preview or you’re not allowed yet?

Aruna Ravichandran: I can give a little bit of preview. But what I can say is we did our research with one of our analyst vendors and partners with over 1,200 participants around DevOps and what I can say is that 87 percent of DevOps adopters have reported an improvement in customer experience.

There is a lot of rich statistics which we uncovered as a result of that particular survey and we will be able to share the results from that particular survey report on January 11.

Alan Shimel:                Great. Maybe we can speak about it a little bit on the webinar for January 17 as well – or incorporate it into –

Aruna Ravichandran: Absolutely we will.

Alan Shimel:                That sounds great. Well, Aruna, we certainly look forward to the webinar on January 17, but more, you know, as importantly, congratulations on authoring or co-authoring what sounds like a great book, and kudos actually for your donating the proceeds of the book to a worthy cause: I think it says a lot about who you are and what are the kind of reasons behind that, so thank you.

Anything else before we wrap up?

Aruna Ravichandran: Nope. I’m very excited to partner with you in order to share our experiences around writing this book and the journey, and hope that this book will be insightful for all of our DevOps practitioners who are embarking or are already on their way within DevOps.

Alan Shimel:                Okay. Well, Aruna Ravichandran, co-author of DevOps for Digital Leaders, thank you so much for appearing on this episode of DevOps chats and we look forward to our interactive Q&A webinar on January 17 at 2:00 PM with you to continue our discussion. Thank you.

Aruna Ravichandran: Thank you Alan.

Alan Shimel:                Thank you. This is Alan Shimel for devopsy.kinsta.cloud and we’ll see you soon on another DevOps chat.

— Alan Shimel

January 10, 2017
DevOps Chat: Huw Price, Smart Automation Is Key

Before the new year, I had a chance to sit down and chat with Huw Price, Vice President, Application Delivery, CA Technologies. Given Huw’s title what do you think we spoke about? You guessed it, automation. Actually there is more to it than that. Automation for automation’s sake alone is not necessarily a good thing. As Huw points out, smart automation is key.

Huw and I will be participating in a full webinar on the topic of Smart Automation and how to build it on January 24th. You can register for this free webinar here.

As usual with our DevOps Chats, below is a streaming audio player with our interview and below that is a transcript of our conversation. Enjoy!

Alan Shimel:                Hi, everyone, it’s Alan Shimel, Editor in Chief at devopsy.kinsta.cloud here for another DevOps chat. Today’s guest on DevOps Chat is Huw Price of CA Technologies. Huw, welcome to DevOps Chat.

Huw Price:                  Hi, Alan, nice to be here.

Alan Shimel:                Nice to have you here, Huw. Huw, if you wouldn’t mind, if you could give our audience a little bit – I said you worked at CA, but what’s your title and what are you responsible for over at CA?

Huw Price:                  Yeah, I’m a VP at CA. I was the managing director of Grid Tools, which venture you may have heard of, where we specialized in all things test data, and laterally we moved into all things test case optimization and into test automation. My role at CA – I’m kind of an evangelist QA specialist practitioner, and it’s actually fitting quite well with the DevOps land of trying to improve quality whilst improving speed at the same time, which is a bit of a magic trick. But it can be done and it needs some new thinking.

I would say that over the years, it used to be cost was the top driver for businesses, but now due to the pressure of business, it’s all about competition and it’s all about getting stuff to market quickly, and you can’t have poor quality code going out to customers because they’ll just move to someone else. And I think that’s really what’s kind of driving a lot of our thinking at CA at the moment.

Alan Shimel:                Absolutely, and it is somewhat counterintuitive when they tell you you could go faster but have higher quality. And I’ll even throw one more improbably into it – and be more secure by doing that.

Huw Price:                  Yeah, that’s an interesting area. I think actually what I’m finding now is that I’m a big fan of doing everything in parallel, the days of sequentially waiting for one team to hand stuff off to the other, and what we’re finding is things like performance testing and security testing are kind of job one, and you need to build those in almost as functional requirements as you’re designing your software really. That sort of hopping from one piece of functionality or requirement to another seems to have vanished. It’s all hands to the pump I think at the moment is what I’m finding out there.

Alan Shimel:                It is a bit of a Chinese fire drill, as they say. But out of chaos comes order, and that’s kind of the good news. Working with you and your team we’re actually doing a webinar after the New Year, in January, and it’s titled “How To Build the Right Automation.” And you and I were talking a little bit offline, of course, and the idea that you just automate for automation’s sake, maybe that was a couple years ago, but now we’re trying to be smarter about designing what’s to be automated and how we do it. Can you share with our audience a little bit of maybe your insight into that?

Huw Price:                  Yeah, I think so. Automation’s got a bit of a bad press, and to be honest, I think rightly so, it’s considered very fragile. You only need a small change, a pop-up appearing on a screen, some kind of slight delay in a network and some of the automation breaks. And then everyone looks for the results and you spend days and days actually finding out that the program is fine or the functionality is fine, but it was actually the automation script that was wrong. That’s the first problem.

And the other one is the time it takes to build the automation in that it’s not uncommon for automation to be built three months after a sprint is finished, which of course means you’re automating something that doesn’t exist any more, which is not very continuous. And the value of what you’re actually doing is pretty poor. I think that is kind of the backdrop of where people have been.

They’ve moved towards test-driven development, behavior-driven development etcetera, but they still have the problem that actually maintaining the automation scripts, even if they’re key word or Gherkin, it’s still an issue. Because, you know, requirements don’t exist any more, just change requests exist, and a change request means you’ve got to go back through all of your existing automation and say, “Do I have to change all these automation scripts, which ones do I change, which ones are duplicates, which ones make no sense?” And that is a massive amount of work.

I’ll just give one example. There was a bank in Canada, and basically for every single requirement change, they would go through every automation script by hand to see if it needed to be changed. So one change request took one tester all day to see if it impacted any existing automation scripts. So that’s just one change request. So how many testers do you have, how many automation guys do you need, how many change requests can you fit through that very narrow pipe. I think that’s where people, even with some of the new techniques – and I’ve got to say that the automation frameworks are becoming better. They’re becoming more structured; they’re becoming more malleable key word based. But they still don’t really address the problem of if I make a change to a requirement how quickly can I update my automation framework.

Alan Shimel:                Excellent. Huw, I want to talk to you a little bit about the go to market with your group. You’re obviously probably dealing with mostly large enterprises, how does a large enterprise realize they have this problem? Is the problem one where, “Geez, we need help automating,” and they haven’t even cut across the threshold of “we need to be smarter about automation” because they’re still at just the “we need automation.” Or is it organizations who have already, let’s say, dabbled with automation and are now realizing, “Wait a second, this is just a giant cluster waste of time.”

Huw Price:                  Yeah.

Alan Shimel:                “And we need help being smarter about automation.”

Huw Price:                  I think the answer is yes to all of them. Even within the same organization – and I can think of one we’re dealing with at the moment – you get such a sort of disparate set of skill sets, capabilities, maturity models, and quite often we’ll go into a large company and introduce teams to each other and say, “Do you realize you have a really nice sort of key word driven framework sitting over here with a very clear object library, which you’ve got all this work and you’re going off and building yet another selenium framework, maybe you guys should talk to each other.” I just find that we do a lot of sort of introducing companies to other people in the same company.

Alan Shimel:                Sort of like matchmaking, huh? Matchmaking all that stuff. Interesting.

Huw Price:                  I’d like to add on that, certainly what I do and members of my team and other people in the business are doing, we are genuinely hunting for best practice here. This is not about us selling software any more, the market is moving so quickly and this ability to be a sort of lightening rod of best practice amongst other companies, genuinely it’s quite fun and we’re enjoying it, and we do share around what we’re finding out in the market in terms of what’s good, what people are struggling with, and hopefully we’re bringing not just software to the market, it’s more some best practice thinking as well, and I think that’s quite interesting.

I’ve got to say that chatting with you when we met in Vegas, I learned a couple of things from you. And I find that when I talk to pretty much everyone. And I’m trying to feed that back, whether that’s by webinars or with the direction of how we build the software. We’re trying to just keep pushing the boundaries, keep communicating, keep thinking. It’s kind of fun. We’re really enjoying it at the moment.

Alan Shimel:                Absolutely. I always tell people these are interesting times to be in the IT world, there’s just so much change happening – and change I think in a good way. New tools and trends and ways of doing things, it is fun, it really is fun.

Huw Price:                  I’m going to take a slight tangent here. I was listening to an agile coach talking and I agreed with 80 percent of what he said, and disagreed with 20 percent. But then I challenged him and said, “Can you tell quickly whether an agile team is good or bad?” And he said, “If they’re having fun, that’s generally good.” And I know everyone is into hero culture at the moment, charging around trying to get the release out the door at the last minute. That’s what we’re trying to focus on is move away from the hero culture and actually getting that fun back into – you know – solving challenging problems and automating as much as possible and joining stuff up and getting feedback loops going and all that kind of fun things. So it is, as you say, very interesting times.

Alan Shimel:                Sure. Steve, let me ask you a – and I’m not being facetious but a real question – can we have too much automation?

Huw Price:                  Actually, that’s interesting. I did a presentation at Star West and I talked about risk based testing. It’s actually kind of touched on an interesting subject here. The reality is, if you have a very stable system and you’ve got a bunch of very experienced programmers, you know, you run it through a code quality engine and it’s very solid and stable, and they also understand all of the data that flows in and out of it – the reality is that actually you might need a very minimal amount of automation to test that.

If you’ve got something which is highly, highly active – I’ll mention an Indian company, they’ve got one API which brings in 150,000 new customers a day. That API, I mean, that is staggering. 150,000. This is to do with the 4G rollout across India. That API, you know, I would be automating the hell out of that. I would have so many automation scripts around that. I would have docker images spun up in every different direction, I would have visualization wrapped around it, I would have negative testing up the wazoo, so that if you make a change – performance testing, blaze meet up, whatever it takes, to make sure that that baby, when you make the slightest change, you don’t mess with it — because if it’s down for ten minutes, that’s 5,000 customers. So I think people maybe should start thinking a little more sort of holistically and higher up in terms of the different levels of risk associated with it. I think that’s one thing.

So I think that’s one thing, and then the other one is the speed at which you can automate. The reality is that what we do, we will generate – we’re very much into building a model of what the system should do. You could potentially build all your automation scripts before you’ve actually built the application. I was doing some work with Eggplant the other day and we actually generated a whole bunch of Eggplant scripts based off a Microsoft PowerPoint of what the system should do. So in other words, before the developers started, we’ve actually created the automation framework.

Now, if that takes 15 minutes, great. If it took 3 days, then it’s a little bit of a tradeoff. So I think this balancing things up based on risk, and also the technology that you have to hand, is probably the two criteria you should start thinking about.

Alan Shimel:                Agreed, agreed. Steve, as I had told you offline, the time here goes incredibly quick and we’re coming up on our 15-minute outside limit. I just wanted to bring you back home to the webinar in wrapping up. I believe our webinar is scheduled for in the latter half of January, and it is called “How To Build the Right Automation.” For people who are listening right now, give me two or three points why they really should make it their business to attend the webinar.

Huw Price:                  I think firstly they’ve got to understand what they’re automating. If you look at most automation scripts, you’re probably only covering about five percent of the functionality. We would look to automatically generate 85 to 90 percent of the functionality of the system in either the same time or less time, so I think that’s firstly. To really understand coverage, I think that’s important.

The other one then is to think about that actually automation is not just about the scripts themselves, it’s about getting the right test data and the right – I’m going to use the phrase visualization, whether that’s service visualization or message visualization or sort of network visualization or visualization environments. So trying to create an environment such that your automation is actually testing the bit that you really want to test. If you think of an end to end test, to get to something like a share trade close where you might have 200 functional logic gates I need to test, is actually really difficult, because you’ve got to have all of the right bits around your automation to make sure that you’re testing the right stuff.

So better automation in terms of the design and also the assets around the automation to make sure that you’re actually testing the correct stuff. I think that’s probably what I’m going to focus on during the webinar.

Alan Shimel:                Got it, got it. Well, obviously on devopsy.kinsta.cloud we’ll be publishing links to the registration page for people who want to join us on that webinar. It sounds like it could be – it sounds like it could be a great one if folks are interested.

Huw Price:                  And it’s lots of demos. I’ll do a couple of slides, but I prefer to do demos.

Alan Shimel:                Oh, that’s greatest.

Alan Shimel:                Yeah, most techies love to see stuff.

Huw Price:                  Actually, we’ll drive right in here.

Alan Shimel:                They’ll give you a slide, but anything beyond that they’re just like, “Show me stuff, show me stuff.”

Huw Price:                  All right, so let’s stay tuned to devopsy.kinsta.cloud. I would imagine we’ll probably have the landing page up within the next week or two as we head into the holidays.

Alan Shimel:                Well, Huw price, I’m going to ask you one last question – not a curveball or anything, but I usually ask a lot of our guests this – for our audience listening, one book that you would highly, highly recommend they read.

Huw Price:                  Actually there’s a book called Model Based Testing. What we’re discovering is that people are now moving pretty much – they’re realizing that without a model it’s very difficult to proceed. And there’s a book called, it’s actually an adjunct book to the Model Based Testing Course. We’re massing this out to our customers now to kind of reset their thinking. Everything we do in life is a model, everyone’s making decision gates, logic gates, risk based profiles, and this is going down really well. People are really taking the time to read it. What I’ll do is during the webinar I’ll put up the pages so people can go and get it. I can’t remember the exact title. It’s called Model Based Testing – The Course Guide, or something like that. But I highly recommend that.

Alan Shimel:                Excellent. Huw Price, thank you so much for being our guest on this episode of DevOps Chats.

Huw Price:                  Oh, it’s a pleasure.

Alan Shimel:                Thank you, it was our pleasure and we look forward to the upcoming webinar, “How to Build the Right Automation,” including demos, and we’ll have more information on that. And we hope to have you back on DevOps Chat soon, Huw.

Huw Price:                  Great, all the best. Thanks so much.

Alan Shimel:                All right. This is Alan Shimel for devopsy.kinsta.cloud and DevOps Chat. Thanks very much, everyone, and we’ll see you on the next DevOps Chats.

— Alan Shimel

January 5, 2017