devopsy.kinsta.cloud

Category: DevOps Chats

  • DevOps Chat: Dead-End Computer Languages with Scott Wilson

    DevOps Chat: Dead-End Computer Languages with Scott Wilson

    Scott Wilson from Automic is always a great source of knowledge around DevOps. I have spoken with him several times and he never disappoints. In this DevOps Chat, Scott talks to us about dead-end computer languages. Scott, who is a developer himself, often marvels at the explosion of languages available today and wonders how many will survive beyond the useful life of the applications that they are written in.

    It is a great point. We did a survey a while back that showed the average organization is supporting upwards of 10 + languages concurrently. Talk about tower of Babel. Well, Scott gives us some great background on this.

    Streaming Audio

    Chat Transcript

    Alan Shimel: Hi, everyone—Alan Shimel, devopsy.kinsta.cloud, here for another DevOps Chat. This episode’s guest on DevOps Chat is Scott Wilson of Automic. Scott, welcome to DevOps Chat.

    Wilson: Thank you, Alan. I’m glad to be here.

    Shimel: Yep, and Scott, we’ve spoken before, we’ve done webinars and podcasts in the past, and are fairly familiar, but for our audience who may not know who Scott Wilson is, why don’t you give us a quick background?

    Wilson: Okay, great. Thank you, Alan. I am currently the product marketing director at Automic Software, and basically, I am specializing particularly in DevOps and application release automation.

    I come from a pretty technical background. I started basically in high school writing code. I was a software developer for a long time, and you know, in many evolutions, different vertical markets of writing code, and I’ve evolved ultimately now into marketing, so.

    Shimel: That’s not such a bad thing, Scott. But [Laughter]—there are fates worse than death.

    Wilson: [Laughter]

    Shimel: But anyway, Scott, we were gonna talk a little bit today about, you know, sort of, we can call them dead-end languages—and by that, I mean, you know, it’s a great time to be a developer today. You have so many choices in what you want to develop.

    But, like anything else, you know, there will be winners and losers among development languages that you can choose from. And I know this is a—

    Wilson: Absolutely.

    Shimel: – yeah, this is a topic you’ve spoken and written on. So I wanted to kind of, you know, with that premise, why don’t you explain to our audience a little bit about what you’re talking about?

    Wilson: Okay. Well, you know, as I mentioned in the intro, Alan, I am no stranger to code, and I will admit I still write code on the side for various things here and there. And one of the things that has struck me over my experience, especially with talking with customers and even working for a couple of vendors for application release automation products is that, in DevOps in general, there’s this great level of interest and experimentation going on with languages. A lot of the ARA tooling provides ways for you to build your own plug-ins, for example, so that you can extend these products and extend their reach into building a nice, cohesive tool chain—a DevOps pipeline, if you will.

    And the challenge is, as I started looking at a lot of these products and a lot of the momentum in DevOps is, I started realizing that people are choosing languages that are kind of dead on arrival already. What really sparked my interest in this was not only my observation here, Alan, but I spoke with an executive at a large company, and he was telling me that they were having to rewrite a lot of their DevOps code—their deployment code, if you will—because the folks that had written their pipeline five years ago used a language that they can no longer hire people to write it. And so they’re having to scratch it and rewrite it again, and I have actually heard this theme a few other times as I’ve met with executives across the U.S.

    So that had me really diving in and trying to figure out, well, how big of a problem is this? There is—and I won’t name the company, but there is one area vendor that does offer a PERL toolkit, just for example, to connect to their API and interact with it. The problem is, PERL is a dying language. So, if—now, this vendor also does not exclusively demand you use PERL, but I just found it an odd choice that they would even support that, given its decreasing popularity. Additionally, I was at a Chef conference this last summer, summer of 2016, and they announced their new Habitat write platform, and it was all written in Rust. Again, another odd, obscure language.

    And so, Alan, what I did is, I went around and started looking to find out, well, why are some of these companies choosing a language and then five years later, not able to support the language and the tool that they have built it in? And there are several, it turns out, popularity indexes, Alan, and you can look around for these. There’s one called the Popularity of Programming Language, PYPL, and it’s listed on GitHub, and it lists all the popularity—languages by popularity and share. There’s the TIOBE index as well, and there are several indexes. Some of them compile indexes, I think—what is it? There’s one that is garnered by what’s called Coding Dojo, and several others that go look at job listings to see what are the most popular language requirements in job listings.

    And if you wanna get a good sense of this, actually, you can actually go to ZDNet.com. They wrote a great article that basically took all the different indexes, aggregated them, and put them together. And what’s interesting in their findings is that you don’t see PERL, you don’t see Rust, you don’t see a lot of these, I call them doctorate languages, meaning people going to get their doctorates in computer science wind up creating these languages and they each kinda have their own cult following, Alan. Which is cool in one respect, but in the other respect, it means that if you’re not careful, you can latch on to some programming language for your DevOps practice and wind up choosing a language that is in fact not sustainable. That’s a trend, and you wind up—

    Shimel: Certainly—so Scott, in the case of Rust and maybe some of the other more obscure kinda languages we run into, I get what you’re saying and I don’t disagree, but you know, when you look at PERL, you know, you and I are not 20-somethings, Scott, right? I mean, PERL has been around a long time, and in its day, you know, back in the dot com bubble, you know, PERL was the equivalent of PHP, you know? And recently I saw, I think PHP is out—PHP 5 or whatever is out there now.

    But, you know, PERL—if you would have asked me a language to bet on in 1998, I probably would’ve bet on PERL. You know, I wouldn’t think it would become obscure or obsolete—though, look, ’98, you know, we’re talking 18, 19 years, and certainly nothing lives forever.

    But how are people out there—you know, it’s so hard. We don’t have a crystal ball, right? And we do have these indexes, but how do we know, like, what’s the next hot one and which is the next dud?

    Wilson: That’s an excellent question, and just to provide me the story, Alan, of your, what you’ve pointed out—because there is no crystal ball, and it is tough—I think the whole IT industry right now, including programming languages, it really reminds me a lot of the turn of the 20th century when there was really no clear definition of what an automobile should look like. And there were various versions—Edison had his battery operated vehicle, and there were several steamers, there several combustion engines and there were lots and lots of losers, lots of investments that went bust.

    And it took, you know, basically a couple of decades, but by the time we hit the 1920s, everyone understood and knew what an automobile looked like, and it looked like and operated like a Model T, right?

    And so it’s really kinda tough right now. So what I like to do, or what I recommend in the context of what we’re talking about here with languages is to really look at where it’s trending and what its longevity has been. If you look at that, you know, Java, C++ are popular. That might be, C have had, and even JavaScript have had a great deal of sustained momentum over a couple of decades.

    You were right—PERL, at the time, was great, but according to the popularity index, it is as its lowest popularity point since 2001 and is continually trending down. PHP has been holding its own, and in the composite index, it is still listed as one of the more popular languages.

    And so, you know, I would be—frankly, if I were practicing a language to help extend my DevOps practice, I would definitely look at what things have been sustainable over the last several years—decades, rather—and really look at the trending. And that’s why—and not to sound too critical, but when I look at Chef, placing Habitat on Rust, for example, was probably not a great idea for the future. If you look at what languages have sustained over the last 20 years, it would have been better for them to have chosen Java, because you have a huge base of Java developers and you could have then had a much larger contribution base to the project. So I think there’s just things you can do like that.

    And then, you know, the other thing, Alan, to your point—and it’s very unsexy to say this, but there has been one kind of, I’ll call it quasi-programming interface that has spanned the entire test of time and has remained consistent. And it also, what’s neat about this, is I have observed, it transcends every IT specialist, and then as a command line interface or a CLI. I’ve found, in looking at this, that it was very interesting that one of the challenges of, let’s say, extending some new fad DevOps tool using a programming language is that it requires a programmer, and you have to understand the grammar of the language. And that usually silos the expertise that is capable, or readily capable of picking this up. Where, versus a command line interface, they were designed, frankly, for the use case to be readily understood and easily picked up, and they transcend everybody, whether you’re a software developer, a DBA—everyone kind of gets to very quickly understand how command line interfaces work.

    So I’d be, if I were trying to build my DevOps practice today, I would actually be more keen on looking at using command line interfaces, published ones, to set up a lot of my extensions and automation mechanics, just because they have transcended time and have the longest life span of any language, though I wouldn’t say command line interface is a language, it is an interface, right? But the nice thing is, they are mostly self-documenting, where the programming languages, you have to know the language to understand what it’s doing, and they’re generally not self-documenting.

    Shimel: Got it. Scott, I don’t wanna put you on the spot, but give our listeners, if you can, what you think are your top three choices for the languages to use, let’s say, in the foreseeable future.

    Wilson: Alright. Excellent question. Well, as always, it depends on what you’re looking to do. That’s what’s very interesting when you look at the indexes and the aggregates and the composites of these indexes is, it really depends. I look at languages a lot like tools in a tool shed. They do a specific thing. You wouldn’t want to write a web server, for example, in C. I mean, you could, but you know, it has diminishing returns.

    I would say, in the modern cloud that we’re in, the more popular languages that would support this are certainly Java, you’ve got Python, PHP, JavaScript and C# are amongst the more popular ones. They’ve been around for a while. C#, as you know, is backed by Microsoft, a big company, and is recently going open source, the .net platform is. It works on every platform—Mac, Windows, Linux, what have you. So that could be interesting. JavaScript, I mean, for its ease of use? I mean, goodness, it’s been around for quite a while. You’ve got services like Node.js in which you can run very sophisticated apps on it.

    I’d probably be looking in that tier for the modern, cloud-based apps—Java, Python, PHP, C#, JavaScript would probably be the languages I would be more keen on looking at.

    Shimel: Got it. So, Scott, believe it or not, we’ve kinda used up our 15 minutes of fame, here. But you know, this is an interesting subject matter, Scott, that I think many developers sort of delve in. You know, there’s the, I call it the shiny trinket syndrome where everybody wants to use the latest and greatest cool tool, but sometimes, you know, these fads fade out quickly and you’re left, you know, with a fantastic product that was developed in a dead-end language, or a fantastic app developed in a dead-end language. So definitely something to be wary of.

    Wilson: [Cross talk] Yeah, like I said, the languages that are great for creating a project, if you’re trying to do a lot of those DevOps automation mechanics, I would really, highly recommend looking at command language interfaces to stitch a lot of that together.

    Shimel: Yep. So, Scott, we’re gonna call it a wrap on today’s podcast. Obviously there’s big news going on with Automic and acquisition news and stuff, and maybe once the dust settles on that, we could have you back on and talk about that a bit.

    Wilson: Absolutely. I’d love to.

    Shimel: Until then, though, Scott Wilson, Automic—continued success, keep doing what you’re doing, and thanks for being this episode’s guest on DevOps Chat.

    Wilson: Thank you, Alan. Have a great day.

    Shimel: Alright. This is Alan Shimel for devopsy.kinsta.cloud for DevOps Chat, and thanks for listening and we’ll see you on the next chat. Bye bye, everyone.

    — Alan Shimel

  • DevOps Chat: ‘The DevOps Adoption Playbook’ by Sanjeev Sharma

    DevOps Chat: ‘The DevOps Adoption Playbook’ by Sanjeev Sharma

    Before the recent IBM InterConnect conference I had a chance to sit down and chat with Sanjeev Sharma, CTO of DevOps Adoption at IBM. I have spoken to Sanjeev many times and he is a contributor to devopsy.kinsta.cloud, as well as the author of “DevOps for Dummies.” Sanjeev has a new book out called “The DevOps Adoption Playbook.”

    With no disrespect toward the “DevOps for Dummies” book, the playbook is on a whole different level. This book represents the culmination of years of learning by not only Sanjeev, but by IBM in general, as well as some of the leading names in DevOps that he learned from during this time.

    “The DevOps Adoption Playbook” lays out a clear “how to” for DevOps including topics such as value-stream mapping, how to lead the transformation of culture and scaling DevOps to the enterprise. As Sanjeev himself says, the book started from a power point of best practices that he had started that tried to take in everything he had learned.

    Sanjeev also stays true to the “playbook” paradigm. He makes references to cricket, soccer and other sports throughout. It is a good read and well-organized. As I told Sanjeev, in a field full of “what is,” “The DevOps Adoption Playbook” is a “how to.” I highly recommend it.

    As usual, the streaming audio of our conversation is below, with the transcript of our conversation below it.

    Alan Shimel: Hi, everyone. Alan Shimel, devopsy.kinsta.cloud, here for another DevOps Chat. Today’s guest on DevOps Chat is Sanjeev Sharma, a DevOps author and IBM CTO DevOps. Sanjeev, welcome.

    Sharma: Thanks, Alan. Good to talk to you again and I’m glad to be on this DevOps Chat

    Shimel: Absolutely. Sanjeev, you are of course CTO DevOps Solutions at IBM, correct?

    Sharma: The exact title, not that it matters as much—it’s just nomenclature—is CTO DevOps Adoption. I am client-facing and work with customers around the world, helping them adopt DevOps, primarily focused of course on IBM solutions.

    Shimel: In addition to that, Sanjeev, of course you are the author of both editions of the “DevOps for Dummies” books, which were very successful in introducing DevOps concepts to the world at a time when DevOps wasn’t quite as well-known as it is now. Correct?

    Sharma: Right, yes. It’s hard to believe that that book has been around for multiple years now. We’ve had tremendous success. Bernie Coyne coauthored the second edition with me. We updated it and it’s been very successful. The book came out at a time when people were mostly asking the question, “What is DevOps and what does it mean to me?” That’s what that book is targeted towards. It’s a very short book. You can read it in an hour, an hour and a half. It’s like a dummified version, so pretty short and to the point.

    Shimel: Yes. But really, Sanjeev, I wanted to talk to you about the new book that you just came out with through Wiley and IBM Press and its called “The DevOps Adoption Playbook: A Guide to Adopting DevOps in a Multi-Speed IT Enterprise.” Sanjeev, I’ve read the book and to me this sort of represents the culmination of all of the lessons and the knowledge that you have accumulated over these last few years, in helping organizations around the world with their DevOps. Is that fair to say?

    Sharma: Absolutely, but I would go one step further and say it’s just not my knowledge and my experiences, which are fairly extensive. I’m sure I worked with dozens of customers around the world. I haven’t counted, but some of them very intimately through their multi-year DevOps adoption journey.

    But as you will see in the acknowledgement section of the book, it was also knowledge I gained talking to my colleagues here at IBM, talking to people like you and other business partners, our followers and colleagues in the DevOps industry, and also of course from our customers, because I wasn’t with them 24/7 carrying the tools of the trade and implementing DevOps and fighting the technology and the political and the business battles. They were doing it, and I was learning by observing them succeed or, in some cases, stumble and then figuring out with them how to go around the hurdles they were facing. So I owe a lot to all the people I worked with over these years, including our customers, in putting together what has come in this book.

    Shimel: Absolutely. Sanjeev, you’re being humble. You have worked with dozens of DevOps people. But in that role, as you say, you’ve interacted with many of the thought leaders, if we can call them that, within the DevOps movement.

    More than that though, when you look at the book, what I’ve said about the book and I’m writing a review of it, is that in a world full of books that are “what is” your book is a “how-to.” I think that’s an important reminder. We read too many books around DevOps that are trying to define what DevOps is, trying to put your finger on that slippery fish of, “This is DevOps,” where you spend some time on that right in Chapter 1. We give a little review of DevOps, but you spend a lot more time on good practical how-to DevOps advice.

    Was that your idea with this book? What drove you to write this book?

    Sharma: Absolutely, Alan. If you read this as a “how-to” book and not a “what” book, then I have succeeded in getting my message across. Quite frankly, it’s how this book came together. As I was working with our clients maybe two years, 18 months ago, the questions started changing. People no longer were asking us, “What is DevOps?” They were asking us, “How do I adopt DevOps? What are you seeing other people do? What can I learn from your experiences when you go with that bank over there or that health care company or that telco, that retailer? What are you observing when you’re out there in the trenches?”

    I started actually putting together a PowerPoint deck. This is where this book started, as a PowerPoint deck of best practices as part of the success. In fact, last year at InterConnect, myself and my colleague, Lee Reid, who is actually the technical editor of the book, we did that presentation and we called it “The DevOps Adoption Playbook,” and that’s what I intended this to be, this book to be a playbook which somebody reading it can have or they can learn all about it and then, based on the situation they are facing, pick a play, just like a coach or a captain does or a quarterback does in American football. He can do a read and get an idea of, “Okay. We need to run this play because that’s what’s needed here.”

    So it’s definitely a how-to book. There are certain, of course, strategic areas in the book on how to convince the business that the DevOps is in order to make a business case. Like its name suggests, it’s a playbook on how to go and get in the trenches and adopt DevOps in a large organization.

    Shimel: Sanjeev, first of all, the book is available on Amazon and other sort of traditional bookseller sites. Correct?

    Sharma: Absolutely. This is my first retail book. The first book that you mentioned, “DevOps for Dummies,” was a free book we were giving away, sponsored by IBM. So to me as an author, when the book came out and I knew it would be available, the first thing I did was drive to the nearest Barnes & Noble, which actually is 15 miles from my house, just to go see the book on the shelf. So yes, it is available at all major booksellers, both as a physical book and as an e-book.

    Shimel: Let me ask, and I think I probably know the answer. Did you take a picture, a selfie of yourself with the book on the shelf behind you?

    Sharma: I wanted to do that, but the book was placed at a very awkward angle, so I couldn’t get myself into it. So I just took a picture of the book sitting there with the other books. And, you know, it’s not a selfie if you give the camera to somebody else. This was in the middle of the day. They were letting nobody in the bookstore. It was pretty hilarious. I wish I had videoed the whole thing.

    Shimel: Very cool. Sanjeev, people can get the book. They can see you for themselves. Also, I will mention that it’s the kind of book where if there’s something specific you’re looking to hone in on, a particular issue, problem, topic you’d like to delve into, the table of contents and the way it’s laid out makes it very easy to do so. So you could use it to kind of pinpoint in the kind of thing you’re looking for, or you can take it as an overview around the whole book. Either way it’s pretty good.

    Sharma: Thank you.

    Shimel: But, Sanjeev, there are a couple of terms in the book that I’d like to – one of the things is you talk about this concept of fast waterfall. It was mentioned in there a few times and I’ve seen others mention it.

    Sharma: Sorry. [Audio breaks up]

    Shimel: Did I break up there? I apologize.

    Sharma: Could you repeat that?

    Shimel: Sure.

    Sharma: I’m sorry.

    Shimel: Sanjeev, you talk about this concept of fast waterfall. Did you hear that?

    Sharma: Yes, I did. Thank you for repeating that. We were seeing a very broad spectrum of maturity levels and a spectrum of business needs, and we go with clients and see how they adopt DevOps. So when I go into an organization, no organization is monolithic. No organization is homogenous. You see one part of the organization where nothing is broken, things are going fine, but they’re using a very old-school waterfall approach to delivering systems.                           

    So the question that arises is: What do you do there? Do you disrupt something that is working during maintenance, more to try to introduce agile principles or try to introduce continuous delivery? Or do you just make what they are delivering more efficient?

    My thesis in the book is that you focus on optimization. You look at the delivery pipeline. You do what we call a value-stream mapping, and look at where the waste is, where the bottlenecks are, and look towards eliminating or mitigating those, without necessarily needing an end-to-end sea change to say, “No, you have to stop what’s working for you. Your business doesn’t need you to go any faster. Your business doesn’t need you to be more innovative because this is an application in

    – but you have to disrupt it.”

    That all or nothing approach does not work. It is also very expensive. So how do we make it more efficient? I don’t like the term “fast waterfall.” I would like to call it “optimized waterfall”. You focus on optimization. Yes, eventually your goal should be to move to full Agile. You goal should be to move to continuous delivery, but you cannot do that day one. You cannot do it across every project, every system and every application at the same time, but you can do some things to start everybody on that optimization journey.

    That is to me what I am referring to in the book. Get started. Get started where you are. Understand your end goal. But you don’t have to get there at light speed. You don’t have to get there yesterday and you don’t have to get there all together. You have to make that business decision of how much change to introduce, how much change you can consume, and how much change you can afford at this time. Maybe not today, maybe you can only do it next year. So that’s summarizing some of the thinking behind what you’re really getting ready to do.

    Shimel: Understood. Sanjeev, you mentioned value-stream mapping. That’s a workshop that I’ve seen you perform over the years and it’s great. If anyone ever gets a chance to sit in on one of your value-stream workshops they absolutely should. Can you give us just a little bit of an idea of what’s involved with that?

    Sharma: Sure. Value-stream mapping, I would add, as an exercise is nothing new. It’s been in there in the Lean movement since the last century, probably since the 1950s. It’s a technique by which you look at processes and you try to figure out where there might be some waste, and then do a root cause analysis to determine why the waste is there and make a plan to mitigate it.

    So in DevOps, if you look at your delivery pipeline as a value stream, that requirements are coming in at one end and code running and production being used by a user, getting business value at the other end, we do a value-stream mapping to look at where the waste is. So we look at artifacts going through that delivery pipeline.

    What are those artifacts? Who are the stakeholders who touch those artifacts and perform actions on them, who do processes on them? How does the transition happen from one stakeholder to the other? How does the artifact get transformed as it goes from one stakeholder to the next? What environment or tool or repository does the artifact live in and is it consumable?

    There’s a concept in Lean called percent complete and usable, which tells me: when I get an artifact, can I use it as _____ to consume it? Are the requirements coming from the business usable by developers? Is the code coming from developers usable by the testers or whatever? Are there manual tasks which are causing waste? Are there tasks people are doing which add no value to the product? They don’t add any business value, like status reports. They have some value, but are the status reports really being used to progress the product or are they really being used because some needs a view, and they have to spend time creating those reports rather than having a real-time dashboard somebody can just look at?

    So a value-stream mapping exercise and what you’ve seen is a half-day version of a workshop we do with clients, where we go in and take one project of theirs and do a value-stream mapping to get an idea of where the waste is. Many times, actually more often than not, we do it at a division or a program or a line of business level and look at for that line of business: What does the value stream look like and where are the bottlenecks? Where is the waste?

    Then we spend some time doing root cause analysis on each bottleneck we identify. Then we go away and come back with a recommended adoption plan of what DevOps practices and capabilities and tooling, and organization change also, would we recommend to help mitigate those bottlenecks. So it’s a very powerful exercise we do.

    I have an entire section dedicated to it in my book. And on YouTube, if you Google, search for DevOps Whiteboard, you will find me doing a mock value-stream mapping also. There’s a 30-minute video of me doing it with one of my colleagues. So it’s something we’ve had a lot of success with and I think it’s something every organization should do.

    Shimel: I agree with you and I have seen the video. Sanjeev, we’re almost out of time. I wanted to just pivot from the book for a moment and talk a little bit about InterConnect. IBM’s InterConnect this year is coming up in about two weeks. I know you’ll be appearing there and I would imagine the book is involved in what you’re talking about. Yes?

    Sharma: Absolutely. IBM Press was the publisher of the book along with Wiley. On Wednesday afternoon we will do a book signing. They’ll set one up. So if you have a book, if one of your listeners has the book, they can bring it there. I’ll be more than happy to sign it and have a chat with them. They will also be selling the books there at the IBM Press store.

    And I am told—I don’t know if I’m even supposed to tell this, but if you come to a DevOps session, a track in the DevOps session, in some of the sessions we’ll be doing some surprise giveaways of books also. But don’t tell anybody that.

    Shimel: No, of course I wouldn’t.

    Sharma: It’s one big secret. No, no, no. Personally, I am doing three sessions, one of which is a panel with customers, and there are two other sessions related. Both of them are topics I picked out of the books, individual chapters from the books. One is on building a business case for DevOps, and the other one is a risk-based model to adopting DevOps.

    Then the third is a panel, and the fourth is a workshop I’m doing on driving innovation. So it’s kind of broader than DevOps. That’s going to be an hour-and-a-half workshop. So it’s going to be a fun few days and I look forward to meeting your listeners there.

    Shimel: Absolutely. You know what? We’ll try to get some links to these in the transcript and notes on this podcast.

    But for now, I think we’ll call it a wrap on this DevOps Chat. Sanjeev, congratulations on a great book here. I mean “DevOps for Dummies” was certainly a great read, but this is a book. Kudos to you and the team. You put together a really nice how-to here. I’m looking forward to hearing and seeing you at InterConnect. Of course we run into each other quite a bit during the year and I’m sure we’ll continue to do so.

    Sanjeev Sharma –

    Sharma: Absolutely, Alan. Thanks a lot for having me and I looking forward to chatting again soon.

    Shimel: Absolutely. Sanjeev Sharma, “The DevOps Adoption Playbook,” a new book out, definitely pick it up, by Wiley Press and IBM Press. Sanjeev, thanks for being on DevOps Chat today and we’ll speak to you soon.

    Sharma: Thank you for having me, Alan. I’ll speak to you soon.

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

    — Alan Shimel

  • DevOps Chat: DevOps and Databases w/ Steve Jones, Redgate

    DevOps Chat: DevOps and Databases w/ Steve Jones, Redgate

    In this DevOps Chat, our guest is Steve Jones of Redgate and SQL Server Central. Steve talks to us about DevOps and databases, as well as the latest from Redgate SQL Clone. More and more we are hearing from DevOps teams that the database is becoming a constraint. We must take DevOps to the database!

    As usual, the streaming audio is directly below, followed by the transcript of our chat. There also is a link to a downloadable white paper from Redgate for your reading enjoyment.

    Streaming Audio

    Chat Transcript

    Alan Shimel: Hey, everyone! Alan Shimel, devopsy.kinsta.cloud, here for another DevOps Chat. This episode of DevOps Chat features Steve Jones of Redgate. Steve, welcome to DevOps Chat.

    Jones: Thank you, Alan. It’s good to be here.

    Shimel: Thank you. So, Steve, you are in—well, you have sort of a dual role in that you’re an evangelist with Redgate, but you’re also the, I don’t know if you wanna call it the curator, the editor, the manager—

    whitepaperJones: The founder. [Laughter]

    Shimel: – founder of—

    Jones: SQL Server Central.

    Shimel: – SQL Server Central, exactly.

    Jones: Yes.

    Shimel: Before we jump into SQL Server Central, though, you know, I’m sure there are people out in our audience who may not be familiar with Redgate, so let’s give them, if you can, just a quick kind of elevator story pitch on who Redgate is and where they fit in in the DevOps world.

    Jones: Okay. Well, Redgate has been around about 17 years, and really, we, our tagline kind of is, “We build ingeniously simple tools that help you build software.” So our goal is to help you build database software or .NET software in a more efficient manner. So that’s kinda the quick pitch on what Redgate does.

    Shimel: Got it. And how—give us a little more background. How long has Redgate been around?

    Jones: So, Redgate started right around 2001, and interestingly enough, SQL Server Central started at the same time. Myself and a couple partners put together this publishing area where we wanted to help people get better at their jobs and grow, and Redgate was actually our first customer and we sold advertising to them back in 2001.

    Shimel: Oh, cool.

    Jones: So I’ve known them almost since the beginning. And over the years, they’ve—Redgate has grown up. We’re now around 300 people or so. We have our main office in Cambridge in the UK, and then we have a sales office in Pasadena (California) as well, and we have a few people, then, like myself scattered around the world that do various jobs.

    And so, across the years, Redgate has tried to help different groups build software better. You know, we sell to a lot of Fortune 100, Fortune 1000 companies all over the world, and over the last probably five or six years, we’ve tried to tackle the DevOps problem in the database world. So we’ve spent a lot of brain power, a lot of effort to build products to try to help people incorporate the database into a DevOps flow.

    Shimel: Mm-hmm. So, you know, that kind of pre-empts my next question, Steve, which was, you know, obviously, when Redgate first started up here, there wasn’t people running around talking about DevOps, though people were still trying to do more faster and automate and all of these things.

    But it’s been about four or five years, you think, where you guys have kinda consciously said, “Oh, we’re gonna, you know, try to hit the DevOps mindset,” if you will, or the DevOps [Cross talk]?

    Jones: We are, yeah. You know, our founder—so, an interesting story. At the beginning, when he was looking for some additional money to get the company going, we had built our first product called SQL Compare, which compares the scheme of two different databases and gives you the differences and generates you a script so that you can do a deployment.

    And, in trying to explain this to the laymen, to the managers, to the people that would be bankers or sign checks, it’s kind of a cumbersome process, right? The idea of a schema and comparing that is a fairly technical area; I think a lot of people don’t intuitively understand that. But he brought in two phone books to the customers and said, “Find me the differences between these two,” you know? And they’re like, “I don’t know how we do that,” right? [Laughter] “Like, we go page by page and we lick this out?” And he said, “This is what our product does—it finds the differences between two things and lets you know.”

    And that’s where we’ve gone over the last 17 years. We’ve matured that product and then, five or six years ago, we decided to find ways to make it even better, and so we spent time looking at how people perform the deployments, some of the shortcomings sometimes of having somebody run a particular product to determine at this point in time what are the differences. And so we’ve built automation, we’ve built some of the other security ideas, some of the things you do in DevOps to produce a flow into various products so that we can ease the pain of deploying database changes.

    Shimel: Makes sense, makes sense. So, Steve, you know, we’ve seen Redgate and a few others really kinda not attack, but really work hard to bring the database and the DBA into the DevOps environment, into the DevOps family, if you will, right? You know, we talk a lot about culture and so forth in DevOps and we try to bring—break down silos, bringing teams together, bringing dev together with ops, bringing QA into it, bringing security into it, and bringing the DBA and the database into it.

    And, you know, I personally have seen this become a bigger and bigger piece of the DevOps puzzle. How—now, Redgate had a lot of success before that, right, and—

    Jones: Yes, yes.

    Shimel: – Yep, so my—I guess my question is, where are you seeing this uptake or, you know, DevOps—so your business was, it sounds like it was good before this. Is it really kinda hitting where—you know, or has it found that sweet spot with DevOps?

    Jones: You know, it’s getting better. I gotta say, five years ago, when I started to try to talk about doing deployment—so, we started a product years ago to do deployments to try to help people do web deployments, and we wanted to include a database in that. And we found it was a much more difficult problem than we expected, and you know, one of the things that we found as we worked on this is that, you know, DBAs, I think—more than ops, more than J, more than security, more than any other group, we fundamentally have a challenge that they don’t have in that we have to maintain state between deployments.

    In the ops world, right, they say that we wanna treat our servers like cattle—if one dies, we just pop another one up in its place and we go. Certainly we do that with containers, we do that with software, we can—you know, the QA people are used to doing that. But, you know, in the database world, we can’t do that, you know? If I could drop tables and recreate them every time I deployed software, my life would be so easy. [Laughter]

    Shimel: [Laughter] [Cross talk]

    Jones: Yeah. [Laughter] But you know, I think over the last decade, we’ve started to see in many industries, many businesses that the data is really, hugely important. You know, and as we see people moving to machine learning and AI and all these different things, the database fundamentally becomes even more important, because that data is required, you know? And whether you’re relational NoSQL or something else, you have to maintain that data as you make changes.

    And so we have this fundamental issue that we have to find ways that we can make changes without disturbing the state of our system too much. And that’s a difficult process, right? If I deploy the wrong .dll or the wrong XT or the wrong .jar file, I drop it and I throw the last one I have up there and we’re good. If I deploy the wrong version of a database, if I make a fundamental change to a table and it’s the wrong change, maybe store, which could be hours, minutes out, you know, who knows—you’d have to substantially try to reverse a change, which means, if any data has been altered, I have to try to undo that, I’m gonna have to capture that statement and then go through some sort of ETL transform to put that data back.

    It’s extremely risky and cumbersome, and you know, as a former DBA as part of my career, you’re risk averse. You don’t want to be in that place where you take the database down for substantial periods of time. So, you know, Redgate really, as we were trying to find new products to build and sell and try to enhance what we had, we realized this was a difficult process.

    Shimel: Mm-hmm.

    Jones: And so, five years ago, I talked to people, they thought it was done, they didn’t think it could be solved, and I’ve had a number of good friends that laughed at me three years ago, four years ago, and you know, in the last year, year and a half, they’ve been coming back to me and saying, “Alright, how do we actually get this database into a DevOps process and deployed?”

    Shimel: Yeah, fair enough. So, Steve—well, first of all, what’s the latest news ? Anything with Redgate?

    Jones: Absolutely. So today, actually—you know, we’re recording this from February 27th—Redgate has released SQL Clone, which is a product similar to some other ones in the marketplace, but it’s designed to provision copies of databases in seconds. So, what we essentially do is, we build an image file of your database, and then we can make real live copies of that in literally seconds.

    So if you’ve got a 1 terabyte database, once I’ve provisioned that image, I can make 1 terabyte copies of a SQL Server database and have it appear on your instants in about 7 to 10 seconds. And every copy is independent, they all look the same, they all look like the original database. You can write to them, you can change things, and you can drop them and recreate them in seconds.

    So, in the Dev/Test world, it’s a fantastic idea that I can provision a developer database in seconds, they can be on their own branch, they can make any changes they want structurally to the data to alter things. And if they decide they’ve made a mistake, as we often do in development where we experiment and we try something and if we want to undo it, they can drop that database, build another 1 terabyte database in seconds and continue with their development.

    Shimel: Got it, got it. Steve, I wanted to spend a little time talking about your role as evangelist with Redgate.

    Jones: Okay.

    Shimel: So, you know, evangelist is not—what’s the word I’m looking for? It’s not an unheard position within the DevOps world, but can you give our audience a little bit of a flavor of what your role entails, especially in dealing with the DevOps marketplace?

    Jones: Sure, sure. So, I—as an evangelist, what I end up doing is a lot of writing and speaking about Redgate and Redgate products, and certainly the DevOps world, but also just in general about good practices of software development and database administration.

    I’ve been working with SQL Server for Microsoft for 25 years, so I’ve been—basically since Microsoft has had the product, I’ve worked with it as part of my career, and you know, the mission of SQL Server Central is really to help you get better at your job every day. And so I do a lot of writing and speaking to that effect, and you know, Redgate is essentially all over the world, so I get the chance to go to different conferences, different events, and provide information about general good database practices or Redgate products in particular.

    Shimel: Excellent. Steve, we’re—as I mentioned here before, we got on, you know, live, the time here goes quickly. But I wanted to know if you can give our audience—well, first of all, where can they go to your SQL World blog? How can they find that?

    Jones: Yeah, so SQLServerCentral.com—all one word, SQLServerCentral—that’s the site where I’m kinda the editor, I was the founder, and I run that right now. So we publish daily information to help you there.

    I maintain my own blog at VoiceoftheDBA.com—so VoiceoftheDBA.com—and that’s where I write about a variety of topics related to data and databases and software in general. So, do that, and then on Voice of the DBA, I keep a speaking schedule, so I’m traveling all over. I head to Colorado Springs in about three weeks, and then SQLBits in England, and various places after that, so. [Laughter]

    Shimel: Got it. What about—and what about Redgate? Any plans for conferences, shows, DevOps events where maybe our audience—you know, our audience is pretty worldwide, Steve, if I didn’t tell you before.

    Jones: Okay.

    Shimel: Places where they might see Redgate?

    Jones: So, we’ll be—we go to a variety of DevOps conferences in the UK and the U.S. and elsewhere, so we will be at SQLBits in Telford in April, and then we’ll be at the Data Platforms Summit in Bangalore, and I’ll be there as well. And I don’t know all of our marketing presence where we’re gonna be beyond that, but you know, we have a good, active Twitter account at Redgate, and we post on there often where we’ll be with different events, so it’s a good place to find us.

    Shimel: Excellent.

    Jones: And of course, Redgate.com. [Laughter]

    Shimel: Yeah, well, that makes sense. So, Steve, we’re almost at the end of our time here. I wanted to ask you one last question, it’s one I ask a lot of our guest, and it’s this—if you had to recommend one must-have book, one must-read book for our audience out there, maybe regarding DevOps and databases or something related, what would it be?

    Jones: So, yeah, we talked about this briefly. I know probably everybody has thought about, talked about “The Phoenix Project,” which is great. If you haven’t read “The Goal,” which is kinda the precursor to “The Phoenix Project,” that’s good.

    But the one I might recommend is “Database Refactorings” by Pramod Sadalage, and it’s interesting because there’s a domain of problems in the database world that are complex and they’re problematic. And so they are the types of problems where you can’t easily make a change and undo it, you know? If I had a column, then I could drop it very quickly—but there are certain problems that are difficult.

    And in the “Database Refactoring” book, they’ve done a good job of laying out these problems and how you solve them across time, because most of these require you to make changes across maybe days, weeks, or months to actually complete them—so that might be the one I’d recommend.

    Shimel: “Database Refactoring”—great. By the way, I loved “The Goal” as well. I read “The Goal” many, many years ago—way before “Phoenix Project.”

    Jones: Yeah. Right—I did, too. That was the first one I read.

    Shimel: Yeah, it was good stuff—but “Database Refactoring” sounds good.

    Steve Jones, it was nice having you here. This is obviously your first time appearing on DevOps Chat, but we’d like to have you back in the future maybe again, and we can talk some more. And you know, I really do like to delve deeper into databases and DBAs and, you know, adopting and being adopted into the DevOps kinda methodology and work routine in many organizations. So maybe next time we could dive a little deeper.

    But for now, I think we’re about out of time.

    Jones: Okay. Thank you very much for having me, Alan.

    Shimel: Steve, thank you for appearing. Steve Jones, evangelist for Redgate, and the founder of SQL Central—is that, did I say that right?

    Jones: SQL Server Central.

    Shimel: Excuse me—SQL Server Central. Steve, I apologize.

    Jones: Yeah. No worries.

    Shimel: Steve, until next time, then, we’ll have you on, and continued success with both SQL Server Central and Redgate.

    Jones: Thank you very much. Great being here.

    Shimel: Thank you. Hey, this is Alan Shimel for DevOps Chat, and we’ll see you on the next DevOps Chat.

    — Alan Shimel

  • DevOps Chat: Purpose Built Appliances for Containerized Applications with Diamanti’s Mark Balch

    DevOps Chat: Purpose Built Appliances for Containerized Applications with Diamanti’s Mark Balch

    Back in my StillSecure days, building purpose-built appliances for security was all the rage. Over time, though, security-as-a-service captured much of the market (although security appliances are still a big seller). For containerized applications, you may think cloud is the way to go. But the folks at Diamanti say that purpose-built appliances for containerized applications are a superior option.

    I spoke with Mark Balch, their VP of product and marketing about this, and he gives us Diamanti’s views here and, frankly, makes a good case. It is early in the containerized application market and the winners are yet to be crowned. Mark tells it better than I can. Have a listen and let us know what you think.

    As usual, the streaming audio of our conversation is below and the transcript of our conversation is below that.

    Streaming Audio

    Written Transcript

    Alan Shimel: Hey, everyone. Alan Shimel, devopsy.kinsta.cloud here for another episode of DevOps Chat. Very happy to be joined today on DevOps Chat with Mark Balch, VP of products and marketing at Diamanti. Mark, welcome to DevOps Chat.

    Balch: Hey, Alan. Thanks for having me. It’s great to talk to you.

    Shimel: Thank you, Mark. So, Mark, let us first start off with Diamanti. I think that’s a fairly new company to our audience or at least to us here at devopsy.kinsta.cloud, although the company itself is not new, but, for those of our listeners who may not be familiar, why don’t you give us a little background?

    Balch: Yeah, definitely. We’ve been around since 2013, and Diamanti spent the first couple of years in stealth mode, as you may say, building our product. And we launched the company last year. We just launched our GA product this past week, in February.

    And just a very quick background or why are we here. Well, we saw the container revolution occurring. We believe that containers are the next mainstream application platform for new cloud-native applications, moving forward. And we’ve seen that users are spending a tremendous amount of time and money trying to custom-engineer their own infrastructure and figure out how to make cloud-native applications operate at scale, with reliability and performance. And we said that, “You know, we wanna make sure that users can do this out of the box, very simply, get control of their costs and be able to focus their time, instead of reinventing the wheel and infrastructure, on building the unique business applications that they’re being measured on.” So that’s why we’re here.

    Shimel: Excellent. And, you know, Mark, what was interesting is, at a time when we’re seeing software-defined everything, right, Diamanti’s out here with a purpose-built appliance for containerized applications. And I would imagine there are many people who say, “Oh, no, we don’t wanna sell hardware.” But, really, if you want control over your environment, you don’t have much of a choice.

    Balch: It’s a real tricky situation for a lot of users, right, because just go out there and spend a little bit of time searching on the web and going to meetups and looking at user testimonials about the challenge of being able to get reliable performance at a reasonable cost point in the traditional model. It’s really very difficult. People spend a lot of time custom-engineering, and that’s time that they can’t spend building their unique services. So, for us, really, it’s a very simple value proposition.

    We’re not saying that you have to customize your application or do anything proprietary; what we’re saying is that, “Continue to go with your open-source approach—standard Docker images, standard Kubernetes orchestration, standard Linux—but operate on a platform that is going to give you the automation of getting that entire application deployed properly, that’s gonna give you predictable performance and outcomes and that’s gonna let you run at a reasonable cost point.” I mean, people have massive bills, whether it’s public cloud, whether it’s looking at virtualized traditional infrastructure that was built for a different type of application. People spend a tremendous amount of time and money trying to get cloud-native applications working, and our goal is to make sure that people can get those applications working within minutes, not within weeks or months.

    Shimel: Sure. And that is the advantage of having that sort of purpose-built platform. Mark, I wanted to, first of all—you know what? Shame on me. I didn’t even ask. Can you give our audience a little bit of the background of who you are, though? And I’ve said your title, but who’s Mark Balch and how did you come to Diamanti?

    Balch: Yeah. That’s a good question. So I’ve been in the IT and application industry for 20 years. I started off my career as an engineer. I love doing development work. I love to build things. I love to deliver great products that have an impact. And then, somewhere along the way, I got into product management because I wanted to figure out whose job was it to make sure that we’re building the right products at the right time, that it could solve real needs. And so, for the last more than 10 years, I’ve been focused on product management and product marketing, doing everything from data center automation and application provisioning software to cloud automation software, and, now here at Diamanti, focused on the open-source side of application development and, again, focusing more on the outcome. Whether we’re talking about an appliance, whether we’re talking about software you can deploy, at the end of the day what I care about, as a product manager, is making sure that there’s a value at the end that’s gonna make someone’s life better, that’s going to give them a greater experience in being able to be personally successful in getting their applications into people’s hands. So that’s what motivates me.

    Shimel: Great. Appreciate that. Mark, if I may, I wanted to take a moment and talk a little bit about Kubernetes. There are obviously choices for container orchestration and container management out there, and it seems like Diamanti has clearly put their chips in the Kubernetes market. As I said, there are other choices. Can you give us a little bit of the background on why Kubernetes and—or maybe I’m wrong. Can Diamanti customers choose other container orchestration options as well?

    Balch: Yeah, you know, I think, when it comes to talking about container formats and orchestration, I think we all have to be a little humble, in that the market is still very early and very dynamic. There’ve been so many changes. Kubernetes is doing a great job. Mesos is doing a great job. Docker’s doing a great job. You’ve got now standardization happening in the Cloud Native Computing Foundation for the Open Container Initiative. So I think, honestly, it is too early to call a winner, and I think all of us have to make sure that we’re giving users choice in working with an open ecosystem. It’s not about forcing people down a particular path; it’s about giving people options. Right? So we can work with a variety of different options, but let me tell you why we have been doing a lot of work with Kubernetes. And we’ve been doing this work with Kubernetes for the last couple of years.

    Kubernetes, from a governance perspective, has been a great ecosystem to work with. Obviously, Google contributed that code to The Linux Foundation last year, and you’ve got large and small contributors from all over the ecosystem, including Diamanti, contributing to make Kubernetes bigger and better and more extensible. So what attracted us to work with Kubernetes early on was that governance, where, really, anyone could come to the table. Everyone has been welcome to pitch in and to take leadership roles, frankly. For example, Diamanti contributed something called “FlexVolume” into Kubernetes. It was upstream; it was a year ago. And we were welcomed with open arms, and now there are, literally, more than two dozen members in the storage SIG who we work with. Same thing around scheduling for Kubernetes—we upstream contributions there. Working with CNI, container network interfaces, is another example.

    So we’ve just seen a lot of great governance and a lot of extensibility, where the Kubernetes community seems very focused on this concept of extensibility, where it’s not that my solution is better than yours; it’s that we have APIs that we can use to extend different options and then users can pick and choose what’s gonna work for them, but it’s supported with a common framework. So that’s what we love about Kubernetes.

    Shimel: Got it. Interestingly, Mark, in our several studies, surveys on this with our audience, overwhelmingly—well, not overwhelmingly ’cause, actually, Mesio was pretty close, but Kubernetes clearly was the choice among our audience for container management and orchestration, so probably not a bad move there. Mark, what about people who have invested in public cloud infrastructure for containers? What’s the Diamanti value proposition to them?

    Balch: That’s a really good question, Alan, and people ask us that a lot. And, by the way, I’ll say that Diamanti is gonna be at the Google Cloud Next Conference next week, so we—

    Shimel: Really?

    Balch: Yeah, so we actually do a lot in terms of public cloud, okay? So I think the first thing is that it’s back to that concept of choice and no vendor lock-in. We need to make sure that we’re all offering users capability—we’re not trying to force them down a path with something that is proprietary—so everything we do at Diamanti is standard Docker runtime, and, as that evolves and maybe we have more standardization around runtime, that’s gonna evolve into making sure that everyone participates in the standard format. So, if you develop an application and you’re using Google Cloud or using Amazon or Azure or someone else, one of your goals, probably, should be to do it in a way where you can be portable, where you’re not locked in, where you can bring it to another provider if that provider offers you better economics, better performance, better reliability, data governance, things like that.

    And that’s where we come in. You could think of Diamanti as a provider, but we are an on-premises provider. We allow users, like MEMSQL or NBCUniversal, to be able to build an on-premises private cloud that is fully open source and you can take your existing containers, you can move them onto Diamanti, you can get all the great performance and automation benefits that we talk about. If, for some reason, you wanna go elsewhere, you wanna go to Google, to Amazon, somewhere else, we don’t stop you. You can do that. You can go back and forth, right? So we wanna make sure it’s very easy to go back and forth so that the user is in control of deciding what’s more important to them, in terms of all those things like governance, data sovereignty, performance, and economics.

    Shimel: Sure. Do you envision a time when people sort of have hybrid Diamanti-public-cloud containerized applications?

    Balch: Yeah, that’s a good question and actually brings up a really—another good wrinkle around Kubernetes. Kubernetes has an emerging project called “Ubernetes,” or its formal name, “cross-cluster federated services.” Now one thing I will say—I love the Kubernetes community, but sometimes, from a marketing perspective, we could do a little better. “Cross-cluster federated services” doesn’t really roll off the tongue very quickly, but what it means is, essentially, it can mean hybrid cloud or multiple availability zones.

    And so, just like Diamanti has made upstream contributions to the community around scheduling, we can now extend those scheduling capabilities, using Ubernetes, so we can move that across the availability zones and into hybrid cloud scenario. Right? So I definitely envision a scenario like you’re talking about, where you can have multiple Diamanti clusters in different data centers, you can have availability zones up in Google or Amazon or Azure, and you can, basically, allow the cross-cluster federated services to figure out where to deploy that application based on your performance requirements, on your sovereignty requirements, on your compliance requirements, or you can say, “Hey, I wanna make sure this thing goes into public cloud,” or, “I wanna make sure it goes into my Los Angeles data center with Diamanti.” You’re in control of that, from a policy perspective, and that’s, I think, what’s really interesting about the cross-cluster federated services road map, moving forward.

    Shimel: Absolutely. And you’re right; that does just roll right off the tongue. But, look, they’re engineers; they’re not marketing people. Mark, let me ask another question, and, not to hold your feet to the fire, but, for people who may be interested at home, can you give us sort of a ballpark pricing on Diamanti?

    Balch: Yeah, absolutely. So we’ve announced our pricing. Each Diamanti appliance has a list price of about $40,000, slightly under that, in fact. Obviously, discounts apply. So we are highly competitive with all alternatives, whether you look at commodity, whether you look at converged infrastructure, hyper-converged infrastructure. We are highly competitive from a price perspective. And then, when you look at the consolidation and the time savings, frankly, there is no competition there. So, certainly, love to chat with any of your listeners who are interested, and I pretty much guarantee, from an economic perspective, it’s gonna work out great.

    Shimel: So that brings up—you opened that box, Mark. For any of our listeners who may be interested in finding out more about Diamanti or speaking to someone, is there an e-mail address or a web address where they can check it out or contact someone?

    Balch: Yeah, definitely. So please check out our website, it’s www.diamanti.com, or just send us an e-mail, info@diamanti.com. We can get you set up really quickly.

    Shimel: Okay. Mark, we’re running low on time, but I did want to just mention that Diamanti is sort of riding the wave, if you will, of this tremendous momentum building up behind containers and micro-services and Docker, Kubernetes, etc. Where in the adoption cycle do you think all of this is? Has it really gone mainstream yet or are we still at the early-adopter stage?

    Balch: That’s the multibillion-dollar question, so we are seeing adoption all over in different kinda fits and starts, to be honest with you. So the industries we see the most adoption, Alan—we see media moving quickly. We actually do see financial services moving quickly. We see web infrastructure. We even see service methods moving ahead, wanting to offer containerized services and competing with the large public-cloud vendors. So where we see containers happening is developers are downloading Docker on their laptop; they’re able to accelerate their application lifecycle and development processes. Operations is a little slower. To be honest with you, it is lagging a little bit behind. That’s where we come in—we’re working with ops teams to help them get off the ground—and, just like always, developers ultimately have the influence where they’re defining application architecture, and then they work with their ops teams to figure out how to get those architectures deployed successfully into production.

    So there are lots of different numbers out there—451 Group had some good numbers; I’ve seen numbers from Forrester and from Gartner. The industry’s still early, maybe at only about 10 percent of adoption, and that’s a very anecdotal number, but it’s growing really quickly and we’re seeing a lot more inbound requests now because everyone’s trying to learn about it. The cat’s out of the bag; it’s not a secret anymore. And I think either people are doing it today or they see it coming quickly and they wanna figure out, when it comes down the pipe from their development team, how do they be successful with containers and actually make it work for their business.

    Shimel: Got it. Got it. Sounds great. Mark, we’re actually way over time. I apologize to our listeners and to you, but I thought we had some good information here and I didn’t wanna cut it off, but we need to wrap up. Mark Balch, thanks so much for being our guest today. Continued success with Diamanti. It sounds great. And, obviously, through Container Journal and devopsy.kinsta.cloud, this is a space we watch pretty closely, and I’m sure we’ll be hearing more from Diamanti soon.

    Balch: Thank you so much, Alan. This has been a great conversation. I appreciate it.

    Shimel: You know, one last thing. Mark, I forgot to mention. You mentioned you were going to be at the Google Cloud conference, which is the week of March 9th, something like that, right?

    Balch: Yep.

    Shimel: In March 8th and 9th?

    Balch: Yeah.

    Shimel: And then –

    Balch: March 8th through 9th.

    Shimel: – DockerCon is next month in August – in Austin.

    Balch: April.

    Shimel: In April.

    Balch: Yes. We will _____.

    Shimel: You’ll be there as well.

    Balch: Yep. Definitely gonna be there, yep, and we’ll also see you at OpenStack Summit, so we’ll be at Google Cloud Next in March, DockerCon in April, and Open Stack Summit in May.

    Shimel: And I think that one was in Boston?

    Balch: It is in Boston this year. That’s right.

    Shimel: Yes. Okay. Hey, we actually have some DevOps Connect events going on in Boston, Austin, and Chicago, but for another day. Mark Balch, Diamanti, thanks for being this episode’s guest on DevOps Chat and we’ll speak to you soon.

    Balch: Thanks a lot, Alan.

    Shimel: Thank you. This is Alan Shimel for devopsy.kinsta.cloud and we hope to see you soon on another DevOps Chats.

    — Alan Shimel

  • DevOps Chat: The Evolution of APM with Jonah Kowall, AppDynamics

    DevOps Chat: The Evolution of APM with Jonah Kowall, AppDynamics

    In this DevOps Chat we speak with Jonah Kowall, VP of Market Developments and Insights at AppDynamics. Of course prior to that Jonah was a VP of Research IT Operations at Gartner. Jonah actually gave us a great overview of the evolution of APM  and how the market has evolved. He also tells where we might be heading now.

    It is not often you can get the lay of the land from an expert like Kowall, so I highly recommend you give this a listen.

    As usual, immediately below is the streaming audio of our discussion and below that is the transcript of our conversation.

    Streaming Audio

    Transcript of the Conversation

    Alan Shimel:                Hi, everyone. Alan Shimel, devopsy.kinsta.cloud here for another DevOps Chat. Our guest on this episode of DevOps Chat is Jonah Kowall of App Dynamics. Jonah, welcome to DevOps Chat.

    Jonah Kowall:             Thanks, Alan. Happy to be here—great to speak with you and everyone else listening.

    Alan Shimel:                Thank you. So Jonah, before we jump into App Dynamics, you have a—you’ve had a bit of a career already. Why don’t you share with our audience a little bit about kinda your journey to how you got here today?

    Jonah Kowall:             Yeah, definitely. Well, I always knew I wanted to be a technologist and, for many years, I worked at about six or seven different startups. I co-founded one of the first content filtering companies back in the early 2000s and, you know, got acquired a couple of times.

    And I kinda shifted careers a few years ago, about seven years ago, and moved into the analyst world and kinda moved away from running ops and security and infrastructure and application performance and decided to take the analyst path, and did that for about four years, which was very interesting and different, learned a lot of new skills, a lot of new muscles were built.

    And I joined App Dynamics a little bit over two years ago, and I work with our       co-founder and CTO running product strategy. I do a little bit of marketing, but quite a bit of product management and kind of looking into where we’re going as a company to solve the next generation of problems that we’re starting to see in our customer base.

    So that’s a little summary of where I came from and however you’d like to take it is great.

    Alan Shimel:                Sure. I guess the real question is, do you know where you’re going, but we’ll come back to that in a second.

    Jonah, as I spoke to you offline about, I wanted to talk to you a little bit about what I have seen, you know, as an observer of the market at devopsy.kinsta.cloud. In terms of the evolution of what used to be just a few years ago, a very kinda stable space called APM, right? We had, the APM space had a handful of players—App Dynamics was certainly one of them—who were, by the way, all doing pretty well, it seemed.

    And what we’ve seen in the last few years is, you know, in the—first of all, more people joining the fray, but more than that, in the race to distinguish one from the other, many players within this space are kinda rephrasing their mission, their—not running away from APM, but their APM plus, maybe. And so we’ve seen, you know, alphabet soups of ARAs and a whole bunch of different combinations.

    What’s your take on that, Jonah?

    Jonah Kowall:             So, when you look back—and, you know, when I started at Gartner, there was a lot of confusion around application performance and application monitoring. And there was like a general belief that anything that monitored some kind of application or even monitored the network and tried to extract application information was, in fact, APM.

    And what I kind of tried to do in my time at Gartner, and I think it sort of changed some things, was really focus APM on instrumentation of applications. So, how do we see the code, how do we get inside the application, how do we trace from end to end and really provide that visibility and the diagnostic capabilities that are really gonna be needed in today’s applications, which are incredibly complex and diverse, and consist of a lot of new technologies?

    So, building that kind of visibility is really hard to do. I mean, if an APM company—and there are plenty of them that have started over the last couple years—they have many, many years before their instrumentation becomes decent, if they’re even going down that path. And the ability to extract information from a running application, without breaking it, is very, very difficult to solve. It takes a lot of time, a lot of experimentation, a lot of work with customers.

    And so this market is very hard to enter into and compete with the three leaders in the space. It’s just a big challenge, and you’re looking at five to six years before these things mature, if they continue to pursue them. So what you’re kind of seeing, and what you alluded to, is that companies are trying to take a different angle and avoiding the deep instrumentation and just trying to provide SVKs and tools for developers to build those, you know, that visibility. But it’s a big challenge, because in enterprise and packaged applications, those products don’t work, and that’s really the challenge that I continually see out there when I observe the industry.

    Alan Shimel:                Got it. So, you know, certain—I’m sorry, Jonah, I have a little tickle. App Dynamics, you know, in, let’s call it an immature industry, rapidly become an 800 pound gorilla, and I think we’ve all seen the proof of that in recent news around acquisitions and so forth. But I’m not gonna go there, Jonah—suffice to say, App Dynamics is a market leader in its space.

    How does this evolution, if you will, changing dynamics, you know, you said you’re working on future problems—how do you think this plays into the future of App Dynamics?

    Jonah Kowall:             Yeah. Well, I think that applications and technologies will continue to evolve, and you know, we’re already starting to see a lot of new application paradigms that we’re gonna have to shift a lot of our core technology to support and to essentially leapfrog what the rest of the market is able to do, and we’re hard at work doing that.

    But aside from the deep, you know, introspection of software, there is also a big push for us to really understand the business, because today’s enterprises, regardless of what they do, whether it’s extracting natural resources from the earth or building cars or providing mortgages—these companies are all software companies, and their businesses depend and are driven by their software. And our goal is really to understand the business execution and the user experience of those transactions that are critical. And, in kind of taking that to the next level is really, how do we look at the outcome of software and of these business transactions as they come together.

    So, our vision is not only to increase our capabilities of the core of what we do in APM, but also to really provide a lens into the business that really provides that IT business alignment that everyone talks about and everyone struggles with today. So we really see that as the differentiator in these large enterprises that are really challenged with a lot of legacy and a huge amount of demand to change their businesses.

    Alan Shimel:                Got it. Got it, got it. So, Jonah, let me pivot a little bit to, there was another area I wanted to touch on with you, and that is this whole area of containers, micro-services—but containerization. Virtually every call, every briefing that I’m on, somehow or another containers make their way into the conversation. How big a focus is it over in the, in terms of product and in terms of the strategy at App Dynamics?

    Jonah Kowall:             Yeah, I mean, micro-services and containers are definitely the peak hype, let’s say, of the day—there’s no question about that. And they provide a lot of benefit, but a lot of people really feel that containers and micro-services are the answer to every problem. And this is something that we’ve seen over and over in our industry where, you know, there’s a new kind of angle to an existing set of technologies that we feel is really gonna make the biggest difference. And although containers and micro-services are both important paradigms, they’re not the answer to everything.

    Our customers are clearly retooling some of their applications around a micro-services architecture, and they’re definitely running workloads on containers, and these things are important for us to support, but are they more important than, you know, building core functionality to support new languages and new frameworks and really helping our customers with their more core business problems. It’s hard to say. I mean, both are clearly critical, but a lot of it is hype, and you know, the hype obviously fades as people become disillusioned with the fact that containers and micro-services don’t solve all your problems. They create a lot of new problems, and that’s just the reality of technology.

    So, as an industry, we’re very over rotated to containers, micro-services, and public cloud, and you know, we’ll soon realize those aren’t the answer to all of our problems—and oftentimes, they create new problems, as well. So, you know, I think it continues to be a cycle and, you know, I really think the evolution of cloud into a decentralized model will be a pretty interesting trend over the next, you know, 5 to 10 years as well.

    Alan Shimel:                Got it. I think we’ve barely scratched the surface. You know, Jonah, I was on a call previous to this and it was around software defined storage and networking and stuff, and it just—listening to it, I had such a déjà vu of sitting back in on the VMware stuff, you know, back in, I guess mid-2005, around then.

    Jonah Kowall:             Yep.

    Alan Shimel:                It just seems to promise so much change for us here; it’s crazy.

    Jonah Kowall:             [Laughter] It always does, and you know, it comes with challenges, always, and people become kind of disillusioned, but there are benefits to those that embrace it, do it well, and you know, have the types of problems that those technologies can solve.

    Alan Shimel:                Yep. Excellent. Well, Jonah, we’re just about up on our time. I’m gonna give you a surprise question here, if you don’t mind—if you can’t answer, that’s okay.

    Jonah Kowall:             Sure.

    Alan Shimel:                But I usually ask, the last question I always ask my guest is—recommend one book to our audience that you really think they should read to help them with their careers.

    Jonah Kowall:             That is an interesting one. I actually tend to, I do a lot of traveling. I actually flew over 200,000 miles in 2016.

    Alan Shimel:                Wow.

    Jonah Kowall:             So, when I actually get to read, I tend to read lighter materials, or I read very deep, technical materials that kind of help with some of the product work that I’m doing. So a lot of the books I read tend to not be too inspirational, but I do really enjoy participating in some of the open Slack communities. I enjoy reading a lot of blogs and other content that tends to be fresher.

    Alan Shimel:                Mm-hmm.

    Jonah Kowall:             You know, I read probably about 500 blogs in my RSS feed regularly, so that tends to really be how I get information, and I do really enjoy reading some of the Google Scholar, if you set some interesting alerts up, you can get some great research papers coming out from universities that are very interesting and forthcoming, just kind of highlighting some of the next generation thinking from the educational institutions all over the world.

    So that really tends to be more what I tend to read versus, you know, something that’s more career focused, I would say, or inspirational in that manner. So sorry I don’t have the best answer, but that’s what I tend to do.

    Alan Shimel:                No, no—that’s fine, and that works for us. Well, Jonah, I think we—well, we are out of time, but I want to thank you for joining us today on DevOps Chat, and I look forward to perhaps having you on again in the future.

    Jonah Kowall:             Sounds great. Thanks for your time, Alan, and thanks, everyone, for tuning in

    Alan Shimel:                Thank you. Jonah Kowall, App Dynamics, our guest today on DevOps Chat. 

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

    — Alan Shimel

  • DevOps Chat: CI/CD with Travelers and Urban Code

    DevOps Chat: CI/CD with Travelers and Urban Code

    In this DevOps Chat we speak with Laurel Dixon-Bull of Urban Code and Frank Canihuante of Travelers about CI/CD. Frank explains to us how he improved the CI pipeline at Travelers and some of the challenges he faced with the scale of a large enterprise like Travelers. Good case study.

    As usual, immediately below is the streaming audio of our conversation. Below that is the written record of our chat. Enjoy!

     

    Alan Shimel: Hey, everyone. Alan Shimel, Editor in Chief, devopsy.kinsta.cloud. Here for another DevOps chat. Today we have two guests on DevOps Chat. First of all we have Laurel Dickson-Bull of IBM’s UrbanCode. Laurel, welcome to DevOps Chat.

    Dickson-Bull: Hey, thanks Alan. I’ll just give you a quick introduction. I’m an offering manager for UrbanCode Deploy. And I started at IBM about 14 years ago, working on internationalization and localization. I spent a few years in release management and saw the agony of software delivery. And then now working very close with UrbanCode Deploy delivery team.

    Shimel: Excellent. And our second guest is Frank Canihuante. If I mispronounce it I apologize Frank. We’ll give you a chance to correct. And Frank, you’re with Travelers. Welcome to DevOps chat.

    Canihuante: Hi, Alan. That was close enough as far as pronunciation. Yes. So I’m a tech lead here at Travelers. I’ve been with the company for three years and was actually hired to lead the technical aspects of setting up a new pipeline actually. Been a developer for over two decades under various roles, different types of projects. And for the past 10 years or so, I’ve been very involved with things that relate to what we now call DevOps. And always thought of that as being just doing good software engineering.

    Shimel: Absolutely.

    Canihuante: So this is right up my alley.

    Shimel: So we spoke a little off camera or off mic before we started today. And Frank, you mentioned that you’ve been doing sort of very DevOps like things for the last 10 years, way before they started calling it DevOps. And you know you’ve been riding this wave for a while. But Frank, I wanted to take a quick moment and talk about sort of the legacy that you had at Travelers. You mentioned you joined three years ago and you were brought in to really kind of update the pipeline, the CI process if you will. Right, continuous integration. Can you give us an idea of what it was like when you first came on board?

    Canihuante: Sure. You know the interesting thing about this project that is now basically setting up a pipeline. That it wasn’t really stated as such. It was about replacing the old systems. And that right away told me that we weren’t quite sure of what the actual solution was. Now, these days we think of CI, CD, even three years ago, those two words weren’t all that popular as they are now. Of course now we understand that that is the way to go these days. You set up a continuous integration and a continuous delivery set of tools. So there was a lot of confusion. There was a lot of angst because everyone knew that if you were about to change, these tools are near and dear to your day to day activities as a developer, as a QA, as a DevOps professional. There’s some disruption that’s gonna happen. So lots, lots of expectations and a little bit of apprehension as well.

    Shimel: Yep. Got it. And so Frank, you came in and you know tasked with updating this. For someone who’s listening out there and says geez, that’s just where I was. Where Frank was three years ago, that’s where I am today. Can you give ’em a little advice? Where do you start?

    Canihuante: Sure. So I have put pipelines together before but at a smaller scale. So my biggest concern _____ at the same time what made it very exciting for me to take on the job was how am I gonna do this in a large enterprise. Travelers has 30,000 employees, 3,000 of which are in IT. So I knew this is directly or indirectly impacting hundreds of thousands of people. So there was a lot of responsibility to go with it. So one thing that I would recommend is you have to do your homework. You have to have a lot of experience in development to be familiar with the way developers think. Because at the end of the day they are your customers. And they’re very demanding. They have things that work now, however quirky they may be, it works. You’re about to change that. You have to be sure whatever you’re gonna replace the old tools with, it’s something that you as a developer feel comfortable with. This is where the Devs part of the DevOps part comes in. And the other part also is once you have the system put together, you have to run it like a product. And this is something that sometimes we in the rush of getting something out there, people don’t perhaps think of the operational aspects of a system. But it is something that we need to have.

    Canihuante: I was just saying that you know putting it together requires a set of skills that basically call on all your development experience. But you cannot forget about how are you gonna run these tools, how are you gonna operationalize them. So trying to keep your customers happy is yet another challenge.

    Shimel: Yeah. Absolutely. And so Frank, ultimately you and the Travelers team wound up partnering up with IBMs UrbanCode deploy on this project, correct?

    Canihuante: Yes. So we looked at several tools. We had all the main vendors of CI and CD tools.

    Shimel: I mean you don’t have to name names but —

    Canihuante: Okay. Sure. So we had a process in which we brought in several vendors of CI and CD tools. And we really put UrbanCode Deploy through its paces as far as the deployment tool. We had in our RFP, which we did have a formal RFP process, many, many questions that related to how it actually worked and how it was actually operated. So we had a pretty good idea before we even brought the tool in for actual POC. But having the POC is what really made a big difference in realizing what it can do. It was very different from the old tool that we replaced. And actually once we had our users in, it brought the level of angst and anxiety that they had about the new system down to the normal levels. You know one thing is to see a demo, another thing is to actually put your hands on it and actually get an application be deployed through this new tool.

    Shimel: Got it. So Laurel, let me turn to you a little bit. When did you become involved with Frank and the Travelers team?

    Dickson-Bull: Well, I’ve been aware of Frank and Travelers team probably for the last couple of years. I think I visited you down you in Connecticut Frank, probably a year or two ago. I have to say though most of what I know about Frank and his team are things that I’ve heard. Really strong team. They’ve actually adopted UrbanCode very quickly and have you know made really fast progress. You know to some people, two or three years may seem like a long time. But to standardize on a deployment tool and in a large organization with ten thousand developers, that’s actually really, really good progress.

    Shimel: I agree. So Frank, give us an idea you know first of all do you consider this project to be successful at this point?

    Canihuante: Absolutely. There are many ways to measure how a project is successful. Projects of this type. In our case, we had over 2,000 applications in the old system. And one way to measure success is to say how many do we still have in the old system after a years’ time. So out of the 2,000 plus, we got about a hundred or so that are still in the old system. And they’re on track to be actually migrated to UCD in the next few weeks or months. But in addition to that, there are these other things that actually make it successful. Just having built something in collaboration with hundreds of other people and get their heads together as to putting together a pipeline that’s gonna make their life easier down the road. That’s another way to measure success. It’s kind of hard to measure it, but you see it in the way people talk. For example, we’re no longer talking about the way we need this tool or that tool. We’re talking about two different ways to solve a particular problem. Before, we didn’t even know how to solve it. Now we have multiple ways. And even the conversations are different. It’s not about particular problems that a group may have. But it’s always thinking how can we solve this problem for everyone. How can we come up with that pattern that solves how to build and deploy applications? Not just for my group or my division, but for the entire company.

    Shimel: Got it. And Laurel, does that jive with you know I’m sure you’re speaking with other organizations using UrbanCode Deploy. Is that sort of measure of success the same you know across the board? The same type of thing?

    Dickson-Bull: Yeah. Well, I would say that what Frank described as you know the challenge of standardizing on a tool for the enterprise and then going through that and it really opens up the conversations. Because once you have the visibility into the deployment automation and you start having success operationalizing your software delivery. People get excited about that. And they want to you know solve problems of automation. Dev and Ops are talking to each other. And the conversations become more collaborative. So I have definitely seen that with other large companies. And you know Travelers does represent a very large segment of our customers in the financial services. You know banks and insurance make up a good chunk of our customer base.

    Shimel: And you know Frank, in talking again off mic a bit you know setting up your CI pipeline. UrbanCode Deploy’s obviously a tool that you use. But you guys are also using the integration with that and Jenkins. Correct?

    Canihuante: Right. Yes, that’s correct. And Jenkins is interesting too because it was already in-house so _____ reasons why people wanted it. But it comes in two flavors. We have Jenkins ______ with various versions ______ also standardizing on a enterprise version of it. And we provide solutions that now encompass not just UrbanCode Deploy but also Jenkins. And we’re also providing a standard way of solving particular types of deployments. For example, how to deploy to WAS or JBoss. How to do .Net deployments. How to do database deployments. And it gets everyone really excited about having a standard way but sometimes even with flexibility to even tweak that a bit. Because we have some groups that only do say .Net, others do only JAVA or some do a mix of both. And now we have a menu of solutions that will span more than one tool. In addition that, there are other things that we have done that we are picking up these oddball applications. Like for example, telephone applications, voice applications. Even things that _____ not thought that we were actually going to install for but we have the ability to do that such as mainframe components, desktop components. We’re all bringing it together as a family of solutions on these tools in addition to integrations with other systems outside of the tools themselves. Such as the ticketing system for example or the monitoring system.

    Shimel: Got it. And Laurel, you know I’ve known about UrbanCode having integration with Jenkins for some time. Actually at Interconnect I think it was last year or the year before, Eric Minick of UrbanCode actually did a joint session with Kohsuke Kawaguchi, the founder of Jenkins and CTO of CloudBees. And so I’m wondering have you run into a lot of UrbanCode customers who are also using Jenkins?

    Dickson-Bull: Oh, yeah. For sure. I would say about half of our customers are using Jenkins. And UrbanCode is you know a great extensibility platform for Jenkins, right. So we’ve got over 300 plugins that will integrate with multiple technologies. And then like Frank was saying, multiple platforms from COS and even .Net, right. We have a lot of Microsoft integrations. So, yeah. I mean Jenkins is a great partner actually in the customer environment.

    Shimel: Interesting. Guys, as I mentioned to you earlier, our time here goes so quick and we’re already coming up on 15 minutes. We’re gonna have to try to wrap up. But as I mentioned, I always like to ask our guests you know can you recommend a book to our audience that you know kind of a must read or should read. And Laurel, I’m gonna let you go first. Is there a particular book you’d recommend to our audience that they might find useful?

    Dickson-Bull: So in the vein of DevOps, collaboration and teamwork that’s really important. Especially in agile development. There was a tool that I came across (that helps you) figure out your strengths. And then when you work with your _____.

    Shimel: You know what Laurel —

    Dickson-Bull: What?

    Shimel: I think we missed you when you said the name of the book. Can you repeat it?

    Dickson-Bull: Okay. It’s not a book.

    Shimel: Oh, okay.

    Dickson-Bull: It’s actually a survey or it’s a tool that you can use with your agile teams to figure out your various strengths. And it’s called Strengths Finder and it’s published by Gallup.

    Shimel: Got it. Oh, very cool. We’ll see if we can get a link to that in the notes.

    Dickson-Bull: Okay.

    Shimel: Frank, how about you? Anything you could recommend to our audience?

    Canihuante: Yeah. There’s so many books out there. But there’s one that I really like. It’s more of an author than a particular book. His name is Steve McConnell and he’s written the famous “Code Complete.” And I believe there’s a “Code Complete 2.” But there’s one other I really like. Actually two more. It’s called Rapid Development and the other book is called “Software Project Survival Guide.” These are from late 1990s. But if you read them it’s kind of like “The Phoenix Project” but 20 years ago. The same problems. The psychology of the software development world and how all that works. Really exciting stuff.

    Shimel: Excellent. Well, Frank, before we close off and Laurel, I wanted to mention Frank, you are appearing at IBM Interconnect this year?

    Canihuante: Yes. I am. I’ll be talking about our Travelers story at Interconnect.

    Dickson-Bull: And we’ll be having you on a panel too, right Frank?

    Canihuante: Oh, that’s correct. That’s gonna be on Wednesday. I forget the date.

    Dickson-Bull: Yep. We have a few of our larger customers who have had success with DevOps joining us on a panel called, “DevOps-You’ve Got This.”

    Shimel: Great. Sounds Great. We look forward to seeing it. I’m actually doing a panel there too called DevOps-It Takes a Village. So we could share notes Frank, while we’re out there. And Laurel, will you be attending Interconnect as well?

    Canihuante: That’s awesome.

    Dickson-Bull: I will be. I’ll be leaving that panel, DevOps-You’ve Got This. And then right before the conference, we have a full day workshop with customers from UrbanCode. So I’m organizing that now and we’ll be leading that on Sunday.

    Shimel: Fantastic. All right. Well, Laurel Dickson-Bull of IBM UrbanCode. Frank Canihuante of Travelers, thank you for being our guests on this episode of DevOps Chat. Look forward to seeing you both out at IBM Interconnect the week of March 19th. And your panel Laurel that you’re organizing as well as Frank, you’re talking a little bit about your Travelers experience. And good luck as you continue to you know make the pipeline and DevOps happen at Travelers Frank. Thanks for telling us about it.

    Dickson-Bull: Thanks Alan.

    Canihuante: Thanks Alan.

    Shimel: Thanks guys. This is Alan Shimel for devopsy.kinsta.cloud. Thanks for being our guests today and we’ll see you on a DevOps Chat soon.

    — Alan Shimel

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

    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

  • DevOps Chat: Madhura Maskasky, Platform9

    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

  • DevOps Chat: Mik Kersten, Tasktop on Value Stream Visualization

    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

  • DevOps Chat: Why Real Transformation Starts with Culture, Bryson Koehler and Shelbee Smith-Eigenbrode, IBM

    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