devopsy.kinsta.cloud

Category: DevOps Chats

DevOps Chat: Cognitive DevOps w/ Hayden Lindsey, Enterprise Systems and DevOps IBM

I recently had a chance to catch up with Hayden Lindsey, distinguished engineer and VP of Enterprise Systems and DevOps at IBM. I have spoken with Hayden several times as well as seeing him present at various conferences. Hayden truly understands how DevOps and related practices are changing the game for Enterprise Systems. Hayden and I caught up on Cognitive DevOps, as well as new developments in the enterprise systems.

His leadership of the Enterprise Systems team at IBM has really seen them make tremendous progress in keeping “big iron” relevant and up to date with the latest technologies. This includes acquisitions of new technologies which Hayden speaks to me about that are bringing next generation DevOps to market.

Have a listen to our conversation and if you like follow along with the transcript below.

Alan Shimel:                Hey, everyone. Alan Shimel, devopsy.kinsta.cloud, here for another DevOps Chat. This DevOps Chat we’re very happy to be joined by an old friend of devopsy.kinsta.cloud, Hayden Lindsey, VP and distinguished engineer for DevOps and enterprise systems at IBM. Hayden, welcome.

Hayden Lindsey:         Thanks a lot, Alan. Good to talk with you again.

Alan Shimel:                Always a pleasure, Hayden. Hayden, we’ll get right down to it. Lots going on in the world of DevOps, but also lots going on over at enterprise systems in IBM, so let’s jump in. First of all, Hayden, you know – I know, I don’t know if our audience knows, but they will now, you are relatively hands on in going out there and speaking to real live people and hearing what their challenges are in, you know, everything, not just DevOps, but this whole kind of digital reinvention, digital transformation that companies are undergoing. In a bigger picture, how is DevOps helping them with that, and then specifically, how are you and your team at IBM helping them with this?

Hayden Lindsey:         Yeah, so I do very much enjoy getting out from the lab. I mean, I like visiting the lab, love visiting the lab _____, but like getting out, meeting with clients. And so I do a good bit of travel around the world, meeting with them, either individually or at conferences, such as Edge, that we had in Vegas last week. And in general, I’m talking to them about how to modernize or transform, and of course, a lot of focus these days is on digital transformation. You know, just like some years ago, everything was about service orientation and so and all that.

Now, I think intellectually, most clients understand that they need to modernize, and of course, the ones I’m talking to are clients that have mainframes, but every single one of those clients have distributed systems and they have – most of them now have some form of mobile app, and of course, they’ve got web apps, so they have all different types of platforms. Now, they may all intellectually understand that they need to do a better job of leveraging the investments they’ve made in their back end systems over the years, and so that we’re talking to them now about is, you know, hybrid cloud topology, API management or the API economy, which is, you know, the latest and greatest way of exposing systems for use by applications on other platforms and the other technologies. And the way DevOps fits, that’s how you go about doing it. If you want to be modifying systems and you need to do it at a rapid pace and yet in a low risk, high quality manner, DevOps is the answer. And now getting people to – you know, getting them from intellectual understanding to action, sometimes that’s the challenge, so that’s why we get out and talk to them.

Alan Shimel:                Absolutely. So Hayden, big news, or at least in our world, and specifically in your division, was a couple of months ago, you guys announced an exciting acquisition. You want to share that with our audience?

Hayden Lindsey:         I would love to, yes. Took quite a while to get this announcement out the door, but on June 24th of this year, we announced acquisition of a company called Easy Source. They – and I’ve been aware of them for quite some time, been familiar with the former CEO and all that for quite some time. They have a very strong offering in the area of what we call application discovery and understanding. And basically what it does is it looks at source code, looks at schedulers, looks at JCL, looks at all different sources of information on mainframe systems, but also distributed systems, and then helps you do what if analysis, impact analysis. It helps you understand – the reason we talk about understanding, it helps you understand these very large and complex systems by visualizing linkages, control flow, data flow, many things like that.

So it’s a very, very powerful tool, supports IBM technologies, but many, many non-IBM technologies as well. So we view this as an essential first sort of step one, if you’re going to go about modernizing for purposes of a digital transformation or any other purpose, you need to understand what you have. And so we’re very excited to be able to offer this to our clients. And just by the way, it’s called Easy Source now, but as of October 4th, we will rebrand it IBM Application Discovery, and we’re combining that with some other solutions that we have around application delivery intelligence, or what we like to call Cognitive DevOps, to give a very comprehensive understanding and improvement offering.

Alan Shimel:                Got it. So that triggered something with me, Hayden. You know, last year at InterConnect, cognitive was such an overriding, overarching theme of InterConnect, so much so that, you know, you guys are kind of breaking out – I don’t know if it’s called Watson World or whatever, but a conference just dedicated to Watson and I guess things cognitive. And now we’re using the term Cognitive DevOps. Why don’t you share with our audience, if you don’t mind, a little bit about what you mean by Cognitive DevOps?

Hayden Lindsey:         Yeah, and in fact, from InterConnect last year, we introduced that term associated with a new offering that we had called IBM Application Delivery Intelligence, and I’ll explain in a minute what it’s about. But the more we started thinking about it, the more we realized DevOps is, of course, important, but how do you improve day after day, week after week, month after month, you know, after you have maybe automated all your tests, or you actually do have an automated delivery pipeline? How do you continue to improve? And that’s where we thought we would be able to look at different types of data that is owned by – owned or created by various tools in the overall development and delivery life cycle. And by combining these different sources of information, we believe, and I’ll give you an example, but we believe we can actually make recommendations to our clients about how to be much more efficient in what they’re doing to reduce risk, to improve quality, to improve productivity.

So our MVP, and it really is an MVP, we’re trying to take that concept seriously, was focusing on testing, because in the mainframe space, but also in a lot of other spaces, there is still a lot of manual testing that goes on. And so that’s obviously – the DevOps parlance, that’s waste and that’s error prone, because it’s being done by humans and they’re gonna make mistakes and it’s slow. And so we combined the information around test coverage, code coverage, tied to test cases, and then mapped that to change sets that we can observe that you change, you know, these three lines of code from when you open it in the editor and from when you save it and check it back in to a source code management system. And then we can tell you of, let’s just say, 10,000 test cases, that you only need to run 12 of them. And, you know, this would save time if the tests were automated, but it saves phenomenal amount of time if you’re doing this manually. So that’s one example of the type of insight, you know, pulling information from a variety of sources, to help people do DevOps better. And so therefore, I claim that equals cognitive.

Alan Shimel:                Absolutely. So Hayden, you kind of opened a little bit of a genie’s bottle with MVP. You know, one of the – I guess one of the issues, and you probably know this from running around and speaking to them, is this whole how do you get customers comfortable, right? Especially big companies that are doing, you know, once a year updates to their app, and say, hey, guess what, guys? We’re gonna do an MVP release, you know, weekly, or even monthly to start with. You know, how do you – I mean, that’s – you want to talk about a shock to the system. How are you getting – and especially we’re talking enterprise systems with mainframes and Z systems and so forth. How do you get them comfortable around that?

Hayden Lindsey:         It takes time. [Laughs]

Alan Shimel:                Has to be more than time, more than time, right?

Hayden Lindsey:         What you need to do is you need to get small wins, and you need to gain confidence by getting small wins and progressing – if you think about what it takes to get a truly integrated, continuous integration, continuous delivery pipeline, it takes many, many, many different efforts. You have to do test automation, you need to do deployment and configuration automation, you need to have powerful tools, maybe for test case generation, on and on. There’s many things to do. You can’t do it all at once.

So what we do is we actually offer DevOps assessments for our clients, to go in, talk to their SMEs, figure out where the low hanging fruit is, where are their biggest pain points, and then put together a roadmap to say, all right, we recommend you start here, and don’t – and start with something where there’s gonna be real value if they’re successful. But also, don’t try to get them changing six or eight things in their overall development life cycle at once, because in all likelihood, you change that many things at the same time, you’re gonna fail. So it’s about getting small wins, to help them become comfortable that what people are saying in the DevOps community, what we’re recommending to them, can actually be done even if they’ve been doing things a different way for the last 30 years, because that is, in fact, the reality. I like to tell people my biggest competitor, not to slam any other folks out there, but my biggest competitor is inertia. People are comfortable doing things the way they’ve been doing them, and we have to come up with an argument about why it really makes a lot of sense to change.

Alan Shimel:                And you know what, Hayden, unfortunately, it’s almost a law of physics. The bigger the organization, the more the inertia.

Hayden Lindsey:         Absolutely.

Alan Shimel:                And the more it takes to push it down. And, you know, in doing that, I do think you’re right, it is small wins, it is little things, building up momentum, breaking down these silos, if you will, between DevOps and even QA and security and a bunch of other stuff.

Hayden Lindsey:         Another thing, Alan, that I’ll just say is that, you know, it’s not just a vendor, like IBM or any other vendors out there saying it. There are many clients, and you hear these folks talk, for example, at Gene Kim’s DevOps enterprise summit, which is coming up here in San Francisco in a few weeks or a month or so. The stories are amazing, and so the DevOps success stories are not by any means limited to the born on the web companies. There are many, many enterprise companies, like Nationwide, like Fidelity Investments, many others that embraced this, even before we were using the term DevOps.

And they’re very, very mature, but they are – they’re leading the way. But if you are in the insurance industry and you’re not at the forefront, and you say, oh, Nationwide is doing that? Maybe I better pay attention. So it’s good to have some role model companies out there that are also willing to share their story, so I think that’s great.

Alan Shimel:                Absolutely. You know, speaking of share your story, I just wanted to mention, Hayden, as long as we have you on, that coming up on October 25th, later this month, we’re gonna have a great webinar with our friends at IBM, on breaking down the barriers or the silos between Dev and Ops. And I don’t know if you want to talk about a little bit, but – our friend Rosalind, and –

Hayden Lindsey:         Rosalind, Rosalind is one of our distinguished engineer, and she and I have been working together for a number of years now. She and Dave Willoughby, who is from the cloud architecture and emerging technologies area, are gonna talk about this – you know, how – the types of things that you can do and we need to be doing. Instead of just using this term DevOps and thinking it’s, you know, more about automating that handoff from DevOps, but what about the Ops back to Dev, and how can we more effectively utilize systems management and monitoring information to then provide – so this is just another example, providing improved insight back to the development community, so that they can do things better.

And it turns out this is actually an area that we are actively working on for that application discovery intelligence offering that I mentioned previously. You know, there is a wealth of information in the what you think of as the system administrator’s realm or the ops realm, that could be combined with development information to get some really interesting insight. So this is what we’re exploring. It’s also an area where we’re trying to find sponsor users in the client community to help us. You know, let them tell us, okay, I wish I could know or get some insight about this area, and then that can get us thinking about what type of data we would need in order to provide those types of recommendations. But so Rosalind and Dave will discuss some of their thinking around that area.

Alan Shimel:                Got it. Lastly, you know what, Hayden, we’re probably way over time, I’m just gonna ask you one more question, if it’s okay. And that is we were talking, you know, offline before we got on about both of our schedules, spending way too much time on the road. What events are on your plate coming up, that people might catch you at or might be of interest?

Hayden Lindsey:         Well, one that I have been to, and I spoke at the inaugural one, was this one I mentioned just a moment ago, Gene Kim’s DevOps summit. It’s here in San Francisco, which is where I live now, and so it’s extraordinarily convenient. [Laughs] And so that’s November 7th through the 9th, and I think it’s just amazing the stories that you hear there, so I intend to be there for the three days. And then I’m sure there will be others that will come up, but our big annual one is InterConnect, which this year, instead of being in February, is gonna be March 19th through the 23rd, yet again in Vegas. And there may be many more, but those are the two that are on the calendar at the moment.

Alan Shimel:                Got it. I’m looking forward to it. I’m looking forward to both of those. I will be, of course, at Gene Kim’s event filming again and doing interviews, and we’re making some big plans for InterConnect this year, Hayden. I can’t announce them right now, but it’s gonna be a lot of fun. Anyway, Hayden, we’ve gone way over time, I apologize, but I want to thank you for joining us today on DevOps Chat. Continued success with the enterprise and DevOps team, or the DevOps and Enterprise team at IBM, and let’s have you on again soon and let’s catch up.

Hayden Lindsey:         Sounds good, Alan. Take care, now.

Alan Shimel:                Always a pleasure. Hayden Lindsey, VP and distinguished engineer, IBM DevOps Enterprise Systems. Thanks for being this episode’s guest on the DevOps Chat. This is Alan Shimel for devopsy.kinsta.cloud, and see you again on our next DevOps Chat.

— Alan Shimel

October 18, 2016
DevOps Chat: Gene Kim on The DevOps Handbook and DevOps Enterprise Summit

Today was a red letter day in the DevOps world. Besides DevOps Connect: CD Summit’s being held in Atlanta and Berlin today. It was also the day of the highly anticipated release of the DevOps Handbook. The book was over five years in the making. It contains over forty case studies of real organizations and their DevOps journeys. I had a chance to chat with Gene Kim about the DevOps Handbook today. The audio of which is below.

The authors of the book are some of the leading lights in the DevOps world: Gene Kim, acclaimed author of the Phoenix Project, Jez Humble, author of Continuous Delivery and Lean Enterprise, Patrick Debois, who coined the term DevOps and the one and only John Willis, @batchagalupe. All four put a lot of time in reviewing each case study and picking from the many different examples the best ones for the book.

The case studies are organized into examples of each of the three ways that were espoused in the Phoenix Project. So while the DevOps Handbook is a very different style book than the Phoenix Project, which was a novel, it continues common themes. According to Gene, the DevOps Handbook is a prescriptive guide showing patterns that repeat themselves across multiple examples.

The book itself is available on Amazon (link above), as well as other book sellers and from the IT Revolution site itself.

Gene also talks a bit about the upcoming DevOps Enterprise Summit in San Fransisco this November. He gives us his top three reasons why he is really excited about this years event.

Below is the streaming audio of our conversation. We wanted to publish this ASAP, so are putting it up before the written transcript of our conversation is complete. We will append it to this article when it is complete. In the meantime enjoy the conversation and let us know what you think of the book!

If you read up to here, you deserve a special bonus. Here is a link for a download of 100+ pages from the DevOps Handbook to get you started. Enjoy!

Alan Shimel:                Hi, everyone. Alan Shimel – devopsy.kinsta.cloud here for another DevOps Chat. This is a special edition DevOps Chat with none other than Gene Kim. Gene, welcome.

Gene Kim:                   Hey, Alan. Always great to hang out with you. Thanks so much for having me on.

Alan Shimel:                Thank you. Gene, you know a big day for Gene Kim, IT Revolution – John Willis, Jez Humble, Patrick Debois. The official release of the long and anticipated [laughter] or much anticipated book – The DevOps Handbook.

Gene Kim:                   Yeah. Five and a half years in the making and hopefully people will stop making George R. R. Martin jokes to me. [Laughs]

Alan Shimel:                Gotcha. Well, you know it’s funny. I’m here in Atlanta recording this at an event we were putting on and John Willis was the keynote and he said the same thing. He said, “Please, if you’re doing DevOps it shouldn’t take you five years to do the book, but it took us – but you’ll do your DevOps faster.” But you know what? Anything worthwhile is worth waiting for, Gene and certainly high, high expectations with this book

Gene Kim:                   You know, John and I have talked a lot in the last couple of weeks and one of the things we keep talking about is just how much we learned in the writing process. I mean it’s just a – even looking back I guess when I first met John six years ago and how much – we’re definitely kindred spirits and I’m also including Patrick Debois and Jez in this as well, but this conversation that John and I were having was as much as we thought we knew six years ago just even looking at how much we learned last three years is just amazing and I think we’re both kind of shaking our head at how much – almost the assumptions we had in our head to think that we could have been done by 2013, so I’m just so thrilled that so much that I’m learning made it into the book and I’m just so thrilled with the way the book turned out and I especially love the fact that it has 48 case studies and a lot of it came out of the DevOps Enterprise Summit in terms of how people are putting these principles and practices to work in large, complex organizations like Target, Nordstrom, Raytheon, Nationwide Insurance, Capital One and so forth, so I’m just thrilled to death.

Alan Shimel:                Absolutely. And Gene, I don’t want to minimize 48 case studies and all that we’ve heard. It’s a tremendous body of work here, right? But what –

Gene Kim:                   Yeah, yeah. Sorry.

Alan Shimel:                No, no. I was going to say. It’s a tremendous body of work.

Gene Kim:                   Yeah. So, [laughs] one of the things that we made as a bonus for people who pre-ordered the book was actually a lot of the dropped case studies – so in order to keep the book below 450 pages, we had to take out 20,000 words.

Alan Shimel:                Uh-huh.

Gene Kim:                   And so there was a lot of stuff that I actually was fighting tooth and nail to try to keep in the book, but eventually senior has prevailed and you know I definitely saw that you have to actually be able to carry the book

[Laughter

Alan Shimel:                We might –

[Crosstalk]



                                    We might see on late night TV sometime outtakes, bloopers and outtakes of The DevOps Handbook.

Gene Kim:                   Yeah. Exactly. So we’ve actually made that available to some folks and – but then I think it really does represent what we thought were the most important parts and there’s a lot of stuff that we had to cut that I thought was also very useful and valuable. So it’s been an incredible journey putting this book together with my fellow colleagues.

Alan Shimel:                Absolutely. So Gene, we may have some listeners out here who (a) haven’t read the book obviously. It’s just coming out today. But (b) maybe you’re not familiar in how this book really is a very different book than The Phoenix Project, right? I mean they’re totally different genres, right?

Gene Kim:                   Yeah, yeah, yeah. That’s a good point. So, The Phoenix Project is of course a novel that was I think really intended win the hearts and minds of the technology community at large and really describe in vivid detail what does the DevOps problem look like? Which DevOps is really the solution for and one of the biggest comments that we got was, “Wow. I see this problem that I didn’t even know I had whether I’m dev, test, or operations or information security, but – and I totally want to replicate the outcomes that that amazing unicorn team did at the end of the book. How did they do that?

And that’s what really The DevOps Handbook is designed to do is to be that non-fiction prescriptive guide to really inform those people going on the journey with hopefully – with what they need to know – certainly everything that we’ve learned in terms of what are the principles behind DevOps that allow organizations to have this fast flow of work from dev through tests through ops and the infosec, so we’re creating value to the customer while providing world class reliability security and stability whether we’re – regardless of where the value stream we’re in and so the book certainly expands upon the three ways that was first introduced in The Phoenix Project.

The three ways being the principles of flow, feedback and continuous experimentation of learning, but we also talk more in the beginning about the principles from which you can derive all these patterns from and we have a big section around how to get started, how to organize those teams, what are the various adoption patterns whether – when dev is driven by ops, by chief architects or by developers.

Alan Shimel:                Uh-huh. It’s very interesting. I actually just had this conversation yesterday with a bunch of folks who are kind of – you know, there’s always doubters, Gene, right? So I had one guy telling me that DevOps will not truly succeed because it cannot succeed if led by developers. And I said, “Well, who said DevOps can’t be led by ops?” Right? Or –

[Laughter]

                                    I mean we’re –

Gene Kim:                   Exactly right. And those were the questions that we set out to answer by doing the DevOps Enterprise Summit, right? Is to really through experience reports really capture what those journeys look like – who it was led by, where they fit in the org charts.

Alan Shimel:                Yep

Gene Kim:                   What the outcomes were and in some of the book we talk about the – where that source of energy can come from, what the outcomes and the transitions look like from those perspectives and what the implications are to how we design our organizations and I just love the fact that we’ve been actually now to document that in writing as opposed to buried in 50 videos.

Alan Shimel:                Yes. Well, we – I don’t knock the videos. I do a lot of them. [Laughs]

Gene Kim:                   No, I love the videos.

Alan Shimel:                [Laughs] I’m only kidding. But Gene –

Gene Kim:                   No, really. I love this book from The Danish Project. It actually came from Paul Muller, VP at HP.

Alan Shimel:                Uh-huh.

Gene Kim:                   And he said, “Messiah’s are great, but scripture is better.”

Alan Shimel:                Uh-huh.

Gene Kim:                   There’s still no better, more viral mechanism to spread knowledge than written word, so I love videos as much as you. And I depend upon them a lot in my own work, but in terms of the way that – ideas for the fastest – still through books.

Alan Shimel:                Agreed. But you know what, Gene? An interesting – and I want to talk about the book, but just a quick aside – when we talk about the body of knowledge when we talk about the lessons that you’ve been able to glean from research, we would be bereft if we didn’t talk about the Puppet – the state of DevOps survey that you’ve done with Puppet Lab or Puppets – no longer Puppet Lab – with Puppet all these years.

Gene Kim:                   Sure.

Alan Shimel:                All of the DevOps Enterprise Summit transformation stories now going on into what? Our third year of that, right? The 48 case studies here in the book and frankly – I mean I know you. You’re out talking to people all year around, listening and anytime – your ears perk up when you hear someone talk about their story, so though these are 48 that make it and as you said some wound up on the cutting room floor, the body of knowledge of research that’s gone into where we are today is phenomenal. I mean it’s really some piece of work when you look back at it, no?

Gene Kim:                   Oh, yeah. Absolutely, man. I loved the way you framed it. I mean I think kind of the book that we wanted to write was one, we wanted to make sure it was grounded in sound principles, right? And so there we looked to – did the body of knowledge around lean and theory of constraints and plan operations and that goes back 50 years of knowledge – you know, go back 100 years and so that’s I would say the principles and then the primary research around the state of DevOps report. This is the work that I’ve done with Jez Humble, Dr. Nicole Forsgren and Puppet that spans 26,000 respondents over 4 years, so this I think helps us establish validity or confirm validity of these practices

And then the third part is the experiential part of observation, right? The experience reports often told at conferences, including the DevOps Enterprise new Summit and I think maybe just to show a little bit of the method behind the madness. I mean so many of the talks at DevOps Enterprise are specifically – they were invited just because they were those experienced reports that we were looking for to help fill out The DevOps Handbook and that also attracted other likeminded thinkers, which has just been so great.

Alan Shimel:                Yeah

Gene Kim:                   So, I think it really take all those approaches really to I think kind of the best – especially business books out there are those that kind of have that kind of quality to them.

Alan Shimel:                Yeah. Gene, one other thing just on the book and then I want to turn over to devs for a moment and that is a lot of people thought we were going – it would be the DevOps Cookbook if you will where there would be a recipe of step-by-step, but that’s not really what the handbook is about, is it

Gene Kim:                   Yeah. In fact it will be – yeah. In The Phoenix Project there’s still – in the editions that are out there right now, they still have DevOps Cookbook in them and we renamed it to DevOps Handbook and I think the – I would say this book is definitely a prescriptive guide, but not necessarily saying that you have to do these things in sequential order, but it is still prescriptive in the fact that you have patterns, right? That we have each one of the three ways.

There’s at least 100 plus pages on each principle on patterns that help fulfill flow, feedback and continuous experimentation learning, so by no means do you have to do them in order. You don’t have to do all of them, but I think what’s so great about patterns, it really does – anyone who has seen the transmission stories, whether they’re told that velocity, whether it’s Google, Amazon, Twitter or Facebook or at DevOps Enterprises, Target, Nordstrom, Nationwide Insurance, Capital One and Disney, right? You can’t help but observe the patterns, right? There is an emergent set of paths that these organizations take and so the goal is really to help to write a prescriptive path so that other organizations can achieve those same outcomes with hopefully less trial and error.

Alan Shimel:                Sure. Sure. Gene, before we turn to devs, the book is generally available today. People can order it on Amazon. Can they order it directly from IT Revolution?

Gene Kim:                   They can. In fact there’s a whole great – a bunch of great retailers that you can order the book from including Barnes and Noble, 800-CEO-Read, and you can buy it directly through IT Revolution and I think the reason why people would do that is right now it’s probably the cheapest way they can get the book internationally, but also there’s great retailers like Amazon UK, Book Seller. There’s a fabulous shop in the UK that actually sends books for free internationally and so that’s also a wonderful service

Alan Shimel:                Very cool. Very cool. All right Gene. We’re probably going to go over time. I’m sorry. I apologize, but let’s quickly talk – turn over and talk about the upcoming DevOps Enterprise Summit in San Francisco. It’s the third San Francisco summit – fourth DevOps Enterprise Summit if we count London, right? I’m excited. Of course I’ll be there. We’re going to do videos again and looking forward to hearing some perhaps new transformation stories and hearing – catch up some of the people we’ve heard from before, but give our audience a little – what are you looking forward to? What’s getting you jazzed about this event?

Gene Kim:                   Oh, yeah. Yeah. I mean having coming off two years of DevOps Enterprise in the U.S. and we just did London a couple of months ago with DevOps Enterprise in London. I can still say this is going to be the best DevOps Enterprise yet. What excites me? I love all the conferences, [laughs] but I’m super excited for this one. Let me give you my top three

One is we get to see a bunch of speakers that we’ve come to know and love and they’re coming back again and telling about their third year and so one of the neatest things that I just feel so honored and privileged is that we can chronicle the journey at Target, Nationwide Insurance, Capital One, Raytheon and their – CSG – all these organizations – we get to hear kind of – they’re going to summarize – here’s what your one and your two were like, which we’ve heard from before and then here’s the challenges that remain. Here’s changes and their responsibilities and here’s what they’re doing about it. And I just love that because yeah, I think most conferences you – I remember going to many conferences and you see the same person and sometimes they’re even giving the same talk and you’re like, “Why am I seeing the same person?” But in this case, right? It’s almost like a documentary, right?

Alan Shimel:                Yeah.

Gene Kim:                   Where you got to see – follow them on their journey. So I think that’s pretty unusual in conferences and I hope everyone appreciates that as much as I do and I’m hoping that people will look forward to that. The second thing I’m really excited about is that we have more companies telling their journey that are – of which are very different than we’ve heard from before. Three come to mind for me. One is the adoption of DevOps inside of the Forge.mil program, so this is supporting the DoD across all of the armed services. And this involves classified systems.

Alan Shimel:                Right.

Gene Kim:                   And since this is a really neat story of like – a heroic story of how they were able to get DevOps outcome even though they never actually got to see the classified production systems.

Alan Shimel:                [Laughs] It seems –

Gene Kim:                   Astonishing

Alan Shimel:                Yeah. It’s kind of working in the dark.

Gene Kim:                   Yeah. I know. And still it doesn’t matter how much harder it is when you’re in the dark

Alan Shimel:                Yep

Gene Kim:                   The other one is we have Susanna Brown and Benjamin Chan from American Airlines, so we’ve never had anyone from the aviation industry before, so this is – their area of responsibility include most of the non-ecommerce properties of flight operations, flight safety. All that stuff. I love that stuff. And we have the CTO from Hyatt speaking and so we’ve never had someone from the hospitality industry present before and so those are both keynote talks.

Alan Shimel:                Fantastic.

Gene Kim:                   I think that’s – yeah. The third think I’m looking forward to is we actually have two luminaries that I think almost anyone in the DevOps community holds in incredibly high esteem. One is John Allspaw from the famous Allspaw/Hammond presentation in 2009. He’s CTO at Etsy and John Willis, DevOps Handbook co-author. He’s going to be interviewing him about his journey now as a CTO of a publically traded company and one of the talks I’m also looking forward to is from Mark Imbriaco, so he is famous because he was the head of operations at 37 Signals

Alan Shimel:                Right.

Gene Kim:                   So EMG’s Basecamp or Campfire, right? That’s him. Heroku, DigitalOcean, LivingSocial. Oh, he was the head of ops at GitHub for many years.

Alan Shimel:                Yeah.

Gene Kim:                   So in my mind these are some of the most storied, famous properties in our –

Alan Shimel:                Well, no. He’s a great – he’s left a trail of success wherever he’s went with that stuff. It’s pretty interesting. One of the things you – you mentioned American Airlines – we had Dan Glass talk at our regular DevOps at RSA last year actually and they are – they’re doing the whole DevSecOps thing and I’m looking forward to that AA one. That ought to be good and AA I mean American Airlines. Yeah.

Gene Kim:                   Absolutely.

[Crosstalk]

Alan Shimel:                Yeah. Good stuff there. And Gene, just – I think early bird pricing may have just ended maybe today or tomorrow. I don’t remember. I get your emails all the time on it, but people can still sign up, right?

Gene Kim:                   Yes. Registration is still open and anyone who is interested in hearing about how large compass organizations are transforming and the amazing, heroic journey that they’re on. We would love to see you there.

Alan Shimel:                Fantastic. And dates, Gene? Just maybe in case someone is wondering.

Gene Kim:                   Yep. November 7th to 9th at the Union Square Hilton in San Francisco.

Alan Shimel:                Absolutely. I will be there, so I encourage our listeners if possible to come by.

Gene Kim:                   And get in line to be interviewed by the famous Alan Shimel, right?

Alan Shimel:                Exactly. [Laughs] I will be doing video interviews there. So Gene, what are you doing with your free time?

Gene Kim:                   [Laughs] Well, boy. You know, right now my planning horizon is about 15 minutes ahead of me. Everything – right now I’m spending a lot of time around the DevOps Enterprise Summit just getting ready. We have – I’m working with all the speakers in terms of making sure that those talks are as successful as they can be for both the prior community objectives as well as the attendees and we’re doing something new, which is – I think as adult learners we tend to learn less from theory and we learn more from experimental learning and that’s why we do – we share experience reports, but we’re actually – for that reason we’re kind of – we’re having facilitated discussion sessions.

We’re calling them DevOps workshops around the top problem areas that have identified by the community, so that’s organizational design needing change, information security and compliance, minimal competency – essential competencies for our leadership and so those are small group sessions. Each one of them will have an assigned facilitator to really help maximize the learning within that group, so I’m super excited about that.

So yeah, I guess the long and short, I’m working on helping make sure that DevOps Handbook, the people that are looking for it, that they know about it and that DevOps Enterprise is going to be successful and even more successful than prior years.

Alan Shimel:                Fantastic. Well, Gene Kim. We’re way over time. I apologize, but it’s always a pleasure just catching up and just listening to everything you work on energizes me, so continued success with all of this, looking forward to the book. I think we’ll probably be doing something on devopsy.kinsta.cloud with maybe a free chapter or something you know, that –

Gene Kim:                   Oh, yeah. Oh, I want to say – you’re right. Thank you so much. Yeah. So, we will make available the first 140 pages of The DevOps Handbook. So if that’s of interest, we’ll have instructions on how to get it, so if you are so –

[Crosstalk]

Alan Shimel:                I’m putting it together. Yep. I’ll try to include it in with this article and audio file for people who want it. I have the background already, Gene. I’ve been working with your team and we’re on it. I’ll do my best.

Gene Kim:                   Yeah. Great. So that is almost a third of the book if you take out the index and the footnotes and the endnotes, so if you think you’re interested, I think the best way to find out for sure is actually to download the excerpt and see it for yourself and hopefully it will be of value to you.

Alan Shimel:                Okay. Gene Kim, principle author of The DevOps Handbook.

Gene Kim:                   No, no. Just one of the co-authors.

Alan Shimel:                Just one of many? Okay. One of the co-authors of – we might as well mention them all – Gene Kim, Jez Humble, Patrick Debois and the one and only John Willis. So great job, Gene. I’m looking forward to the DevOps Enterprise Summit in November in San Francisco and to everything else, I want to thank you for – well, number one for getting me into DevOps as you know, but number two, just for all the work you do and the research and the leg work and running around and cheerleading and you know what? You’re a good man, Gene Kim.

[Laughter]

Gene Kim:                   And Alan, it’s always so fun to be on the spinner with you as well.

Alan Shimel:                All right, then. I will be in touch. Congratulations again on the book.

Gene Kim:                   Thank you so much and see you in a couple of weeks in San Francisco.

Alan Shimel:                Absolutely. Gene Kim, author of DevOps – one of the authors of DevOps Handbook, The Phoenix Project, the man behind DevOps Enterprise Summit. Thanks for being our guest today on DevOps Chat. This is Alan Shimel for devopsy.kinsta.cloud.

— Alan Shimel

October 7, 2016
DevOps Chat: Panzura’s Cloud-Based File System Gives DevOps Big Savings

Have you heard of Panzura? If not, you are probably not alone. The company is relatively new to the DevOps market. But it’s not some new startup that grabbed some VC money by using DevOps as a buzzword: Panzura has been around for years, perfecting its cloud-based file system that can deliver eye-popping results in terms of speeding file requests, as well as the volume of data that you have to transport. For DevOps, this kind of speed savings is just too good to pass up.

I had a chance to sit down with Rich Weber and Barry Phillips of Panzura and discuss why DevOps teams are finding Panzura’s offering so enticing. Barry is the VP of Marketing at Panzura, but don’t let that title fool you—Barry is highly technical. Rich is chief product officer at Panzura and is also really knowledgeable. Together, we had a great conversation about this interesting offering and why the DevOps market actually came to Panzura rather than Panzura coming to it.

As usual, the streaming media player is below, followed by the written transcript of our conversation. Have a listen or a read, or both. Enjoy!

Alan Shimel: Hi. Alan Shimel, Editor-in-Chief, devopsy.kinsta.cloud here for another DevOps Chat and I’m happy to be bringing—I, well, I think introducing to our audience a new company or a new company to the DevOps face perhaps that we haven’t had a chance to speak to before and that company is Panzura, and I’m happy to be joined on this episode by Rich Weber, Chief Product Officer at Panzura, and Barry Phillips, Chief Marketing Officer at Panzura. Gentlemen, welcome.

Weber: Nice to be here. Thank you, Alan.

Phillips: Yeah. Thanks, Alan, great to be here.

Shimel: Okay and just for our audience, though, Rich, that was you first and, Barry, that was you second. So guys, I’m gonna guess right now that our audience may not be familiar with Panzura, can one of you give me the elevator pitch or a quick background on Panzura and we’ll go from there?

Phillips: Yeah, it’s Barry. I’ll do that. So yeah, so Panzura and it’s interesting as I start this off, most people may go I’m not really sure why you’re in this DevOps space, so what we do is have a hybrid-cloud storage solution and really what that means is we put all of our customer’s unstructured data in the cloud and we happen to cache the data that they’re using on physical or virtual appliances that’s set in the offices. And that happens to work really, really well for some specific use cases because of some unique technology that we have inside of our software so you know one of those is for manufacturing and it really makes CAD applications work really, really well across sites, architectural apps, engineering apps and just like those use cases we’ve have customers actually bring us into the use case into the DevOps use case and really specifically being able to globally distribute software builds and artifacts quite quickly. And so that’s really the part of DevOps that we play and it really kinda plays into the continuous development, continuous delivery, continuous integration space and essentially what happens is in the case of electronic arts you know we dramatically taking the time it takes to distribute globally you know 50GB build files from 10 hours to essentially minutes and we’ve got many different examples of customers like that, so it’s always great to be brought into a specific space by a customer need that’s taken a platform that you have and really using it for a specific use case.

Shimel: Absolutely. And, Barry, of course when we’re talking about a time difference of 10 hours to a few minutes, I mean that’s the kind of eye-popping differentials that we like to tell in the best of cases in DevOps, right, where we’re putting those kinds of savings, those kinds of numbers in front of people. So thanks for that background. Rich, if I can ask you so you know obviously there’s use cases here for the DevOps audience, for the DevOps market and DevOps use patterns, as we say. As chief product officer, Rich, what kind of—you know, how did you steer feature set? How do you plan your road map to kinda further help the DevOps community with this product/service?

Weber: Well, I mean typically it’s based on feedback from real customers that we have doing workflows and things that run through there and like so that eye-popping one that you were talking about is how do we reduce that time by so much? You know a lot of that came from working with software developers and one in particular is in the gaming industry where imagine their builds are very large, right? They’re building into like Blu-ray ISO images and things and enabled low-cost QA centers to test that. Now you can have anywhere from 20GB to 50GB resulting builds and transferring those takes a long time, right? Suddenly, you come to the point of, ‘Hey, I could probably get that data across the globe faster on FedEx than I can digitally over the line.’ Our product really helps do that by providing a global file system that’s available in each site and by virtue of talking to the Panzura device it’s automatically in the cloud. It’s automatically duplicated, compressed and transported and available in their real time. Especially if I’m doing many hundreds of builds very quickly, the deltas between those builds are very short so effectively I can make those available for tests, production and immediate use through my build process.

Shimel: Excellent. And, Barry, you and I spoke a little bit offline and you know I think I had asked you about so is this a product or service that is really only for big companies or for unicorns you know of the world? I mean who’s a good candidate, especially from a DevOps point of view, for Panzura?

Phillips: Yeah and I would even extend it, I would say, beyond DevOps, right? So if you think of any company that does any sort of global testing and development whether that’s pure DevOps, whether that’s somebody who is in the process of putting DevOps in place or even somebody who’s basically not even there yet that when you think of just the ability to move these builds and artifacts quickly that really increases the number of test cycles you can do on the software itself. Of course, that’s better quality software you know typically gets market—it gets software to market faster. It’s all those typical things. But I think it really encompasses anybody who is actually has dev and test teams essentially around the world.

Shimel: Yep. And another kind of phenomenon that we’re—that I’ve observed, Barry, in talking to a lot of people, obviously, is this idea of a multi-cloud. So let me back up. When we first saw the whole sort of cloud revolution, if you will, I think the—everyone agreed that hybrid cloud was the way to go. No one was moving a hundred percent of their infrastructure to a AWS or Azure, a public cloud platform, but there was a hybrid where some of it might be public. Some of it might be in a private cloud in a data center. Some of it may be on-prem, right, but it was that hybrid situation. Now we’re seeing multi-cloud, right? And I think it’s a different animal. Barry, Rich, what do you think?

Weber: I think multi-cloud is good and particularly for DR purposes but going to that hybrid concept that you were speaking of before and how do companies really bridge the, hey I’m working inside of my four walls or inside of my data center and how I take advantage of that cloud space that’s where Panzura really helps companies bridge that gap. So in particular, if I am working within my own data centers and my own sites and I’ve got multiple sites, that example that I gave you before not only was the time reduced from many hours of days down to minutes but in terms of that footprint that went down to one—from 1.5PB to 45TB by utilizing the cloud because I had one central location of the data and I didn’t have to store and move and transfer many replicas. So that cloud gives you the ability to aggregate and make that data available quicker. Multi-cloud I think gives you an opportunity to then further do a disaster recovery even redundant across clouds not only from sites but from cloud to cloud, right? That first step is really getting that data and aggregating it in the cloud itself and Panzura really gives companies the advantage on how to move there and take advantage of that and even burst inside of computing, not—and beyond data, as well.

Shimel: Absolutely. I mean and that’s exactly where I see with multi-cloud. Once I’ve been able to move that data to the cloud whether I have some of my infrastructure on Windows, let’s say in Azure and some other stuff on NOS and AWS and maybe something on OpenStack at Rackspace or somewhere doesn’t make a difference ‘cause my data is rather—you know my data is multihomed anyway or not multihome. That’s not the word I’m looking for. Panzura takes care of the data. I don’t have to worry about that. Is that—is that the gist of it?

Weber: Yeah, I mean, in fact, we’ve got customers who I would say maybe you didn’t start out as being cloud-forward customers or cloud-savvy but Panzura makes that simple, right? If all they have to do is make a mount, my workflow stays exactly the same as it is today and you don’t have to worry about where that replication it goes, what data center is getting used. Panzura makes that part simple. All you got to do is mount it regardless of where I’m at. It’s the beauty of having a global main space in a global file system.

Phillips: And maybe to further add on top of that, Alan, is you know Rich mentioned workflow and as you think of you know companies who essentially go from you know waterfall to Agile and then get into you know really this DevOps model. You know we can sit underneath there and it stays the same for them ‘cause we are just we look like a regular storage mount for them, so everything will remain the same as they move down this process into DevOps.

Shimel: Great. So let me get a little geeky on us. Rich, can you kinda describe what the Panzura stack, if you will, looks like? I know you referenced a Panzura device earlier. What exactly—give us a little—our audience a little bit more detail on that.

Weber: Yeah, so I’ll try and keep it simple but on the front end it looks just like a file server you know whether that be like a net app or even a Windows file server on the front end, so it integrates with AD or other authentication methods and you just mount it, right? So, on the front end you’ve got either an SMB/CIFS front end or an NFS front end. You mount that drive and you store your data there. As data comes to us, it runs through our stack and our stack begins with de-duplicating and that de-duplication what you need to know about Panzura is it’s not just for the data at that place. It’s for the entire footprint for all data written everywhere because that de-duplication information is part of the metadata that’s shared globally. Then it gets—after it gets de-duplicated it gets compressed, then it gets encrypted and none of the customer keys or security access stuff exist in the cloud, so none of our customers actually even have to trust the cloud provider themselves because no data sits in there in clear text. Then it all gets compressed, packaged up and put in the cloud and that’s done at the block level from a de-duplication standpoint. So as it run through our stack we integrate WAN optimization, as well, so moving that data becomes very fast and simple and on the other end everything works in reverse and the customer doesn’t have to manage all that; all that happens automatically. Again, all they see is a drive mount and access the data in exactly the same way they would from their filer today.

Shimel: Has anyone ever used the term data storage as a service or data storage and access as a service?

Weber: Yeah, absolutely –

Shimel: Would that be fair?

Weber: Yeah, I think you especially as you move into that cloud paradigm, right? You’ve got platform as a service, storage as a service, software as a service and this is where, like I said, Panzura makes the adaptability of that service very simple, right? That’s storage and object storage in the cloud without you having to write specific apps to do that. Panzura allows you to adapt those type of either storage as a service or platform as a service integrated into your existing data center or workflow.

Shimel: Okay and guys, if I can ask ya, can you give our audience a sense of how this is priced or sold or offered or however you want to call it?

Phillips: Yeah. We essentially sell controllers and those controllers are what sits in somebody’s office and that can be either a virtual machine or it can be a physical controller and the more capacity those controllers have on them the more expensive they are. The other thing we do is we do have controllers that run inside the cloud and so and they would run inside Amazon right now and we do have just a preview that’s running inside Azure and the whole idea there is now not only does every single office see the same file system across every office but also that cloud does. So if you happen to have some sort of application or service running in the cloud, let’s say it’s platform as a service and you’re looking to be able to access file data that may be on premise, you know right now what we provide there is the same exact cloud data everywhere. So in all those cases somebody would purchase a controller from Panzura and that would be either a physical controller on site, a virtual machine that they would put on top of their own hardware, or it would be a Panzura controller running inside the cloud itself.

Weber: Yeah, I mean it depends on what your needs are. I mean in our hardware system think of this as a lightning-fast flash filer that sits inside of here, where our algorithms concentrate on the cache or very fast local performance usage. But software-only deliverable inside of a VM for flexibility of the customers or, like Barry said, an in-cloud solution if I want to burst into the compute and have my data there, Panzura controller in there, we’ll help ‘em do that. And again, global file system and mail work in concert together.

Shimel: Got it. Guys, I’m curious. As part of maybe your market research customer feedback, what have you, what has the feedback been from people from DevOps teams, let’s say? I don’t want to use the term DevOps engineers. It gets people up in arms but you know from teams that are using DevOps within some of your customers have you gotten any feedback from them on this and is it different than your customers at large?

Weber: I think the interesting feedback that comes through is probably twofold, right? There’s two things that you hear. Most of the concentration really comes in productivity, right? It’s about that speed. How do I make things faster? How do I get bills done quicker and get product to market faster? And we give some examples of that and I’m not kidding. I’ve been into customers before and they say, you know, “Hey, can you beat FedEx bandwidth?” and it just blows me away. You’d think it was the nineties or something again. So when you’re dealing with big files that helps and it’s not only about delivery of the final executable but also about doing builds in remote locations. If I’ve got remote mounts on those build artifacts or dependencies, people hit builds for private builds and remote site and wait ‘til the next day. With us they hit a build and they enjoy the same performance that they do at the headquarters or where the files reside. The second portion is, of course, the economic side, right? How do I save money? And I think that most of the feedback comes in as they pick us up or productivity gain, get products back to market faster and then they found out without having to do replicas and manage multiple file loads of data they end up saving a ton of money and it’s another example I gave you, right? 1.5PB of replicas down to 45TB—that’s a huge storage savings.

Shimel: Yep.

Phillips: Yeah and bear in mind I’m the marketing guy here, I mean the things that I’ve heard is when you think of these distributed teams who are working in a DevOps environment it really makes them seem like they’re really in one office, right, because it makes that speed seem just as fast over a wide area network across the world as essentially on a local area network in one office.

Shimel: Sure. And, Barry, you’re being facetious when you say you’re just the marketing guy. I happen to know you have two degrees in computer science so let’s not hide behind the marketing title too much. Anyway, gentlemen, we’re—actually, we’re past our time already. We always go past our time and I apologize, but I need to ask one last question which is the question we usually end our DevOps chats with. Though there’s two of ya, I’m gonna ask you just to recommend one book to our audience that they really should read as soon as they can or at least put it on their list and get to it when they can. What book would that be?

Phillips: Yeah, it’s Barry. I really enjoyed reading, “The Big Switch,” from Nicholas Carr and it really was—it was interesting ‘cause it—and I think it applies to DevOps and especially with DevOps in the cloud. I think someone wrote it’s kind of the whole chocolate and peanut butter you know together as a chocolate peanut butter cup and just really gave examples of what happened when power used to be generated from waterwheels and how that moved to the grid and really making that comparison of how things are moving to the internet. So I thought it was a great book and I recommend it for anybody.

Shimel: Great. Rich, you second that one?

Weber: Absolutely. [Laughs]

Shimel: Great. Well Rich Weber, Barry Phillips, Panzura—of Panzura, thank you for joining us on this episode of DevOps Chat. We welcome you to the devopsy.kinsta.cloud community and we hope to see and hear more from you in the near future. Continued success and we’ll see you both soon.

Weber: Thank you.

Phillips: Thanks, Alan.

Shimel: All right. This is Alan Shimel for devopsy.kinsta.cloud and DevOps Chats. Thank you and we’ll see you again at our next DevOps Chat.

— Alan Shimel

September 19, 2016
DevOps Chat: CJ Paul, IBM, on DevOps, ITSM, Cloud and More

devopsy.kinsta.cloud editor-in-chief Alan Shimel sat down to speak with Dr. CJ Paul, Distinguished Engineer, DevOps Methods & Tools, IBM Cloud. CJ is someone we have interviewed previously on video at IBM InterConnect and is always a great source of information. In this interview Dr. Paul discussed DevOps, ITSM, Cloud, Bluemix, Bluemix Garage method and more.

As usual, the streaming audio of our discussion is below. You can also find it on SoundCloud and iTunes. Below the audio player is the transcript of our conversation so you can follow along. Enjoy!

Shimel: Hi, everyone. Alan Shimel here for another DevOps Chat on devopsy.kinsta.cloud. Thanks for joining us. I’m happy to be joined on this episode of DevOps Chat by a friend of mine CJ Paul of IBM. CJ, are you there?

Paul: Yes. Hi, Alan. How are you?

Shimel: Good. Good to have you on DevOps Chat with me today, CJ. Of course you and I have done several video interviews from various conferences we’ve both attended. But you know we haven’t had the pleasure of having you here, so welcome. CJ, I’m gonna bet not everyone in our audience knows who you are. Why don’t you give a quick little background on who you are, what you do, where you work and so forth?

Paul: Yeah. Definitely. So my name is CJ Paul. I work at IBM. I’m a Distinguished Engineer in the cloud unit. And focused on DevOps methods and tools. So some of the things that my team puts out are the Bluemix Garage Method. It’s out as a website at IBM.com/devops/method. Then we also work on the Bluemix DevOps services and you know I work with a lot of clients as they do their transformation to the cloud. And trying to develop DevOps practices along the way.

Shimel: Great. So CJ, you know just kind of off the beaten path here, but we’ve had several guests on DevOps Chats that are distinguished engineers at IBM. And for our listeners who you know maybe are not familiar with what that means and it’s more than just a pretty title. Can you give our listeners a little bit of insight into what it is to be a distinguished engineer at IBM?

Paul: Oh, definitely the focus of a distinguished engineer is to leave a portfolio of products in a particular domain. So in this particular case you know I have several product teams that work on different offerings in the DevOps space. And I’m responsible for crafting the technical strategy and providing architecture and technical direction to multiples of these teams.

Shimel: Got it. So CJ, as I think I mentioned to you in our off camera or off microphone conversations, you know the month of September is gonna see devopsy.kinsta.cloud focusing a bit on APM and DevOps. And of course this is a subject that you are you know very familiar with. And part of what you do in Bluemix and all of these things, obviously APM’s a part of it. But why don’t we start with this? Can you define for our audience, when we talk about APM and DevOps and maybe it’s in relation to ITSM, right? IT Service Management which is something you’re also very familiar with. Can you kinda pull this all together for us?

Paul: Yeah. Definitely. Traditionally operations teams have always worried about application availability and performance. Where performance includes you know how the application might respond from different locations around the world and how the response time evolves or changes for different types of transactions. Now, as we look at DevOps and the role of the DevOps teams becoming more cross functional, a lot of the focus is shifting to how do we get the synthetic monitoring, the configuration of the monitoring and all of that to be handled much earlier in the development cycle. In fact, in an ideal world, just like our source code is written to the specs of the product, we would also create the associated operational configuration of the monitoring tool, as well as the creation of the synthetics scripts, along with the source code. And so in the ideal case you would have all that be checked into the same repo. And then as part of your continuous delivery process you’d want to make sure the operations tool is configured to monitor that particular build that is deployed in a particular environment.

So that’s the shift in thinking that we see a lot of the teams going through is how do we actually make this possible you know where all of the setup and configuration is treated as an extension to the source code of the product and worked through the lifecycle. Because it gives various advantages. Let’s say a new build comes out and you’re going to go deploy that new build in a particular environment or perhaps even introduce it to a small subset of your users in production. When you introduce that new build with a new feature, you want to monitor that new build or that new feature. And take all of that data and make decisions on whether you now ramp up to your full population. So what we see happening is in the new world of DevOps and especially on the cloud, you know monitoring has to go very much hand in hand with the features that the development team has built. And so it’s no longer just an after the fact operations thing to worry about. It is something you have to worry about as an integral part of the DevOps lifecycle. So that’s why I think this is a really exciting time. Especially the cloud enables application teams to do A/B testing and evaluate you know performance of new features, the response times of new features as it compares to their existing version of the application that is running.

Shimel: Sure.

Paul: And so all of the new capabilities you know that are the focus area in the application performance management space.

Shimel: Sure. Exciting times indeed. CJ, I would be remiss if I didn’t mention on this very topic that we actually have a webinar scheduled, I believe it’s Tuesday, September 20th at 1 p.m. Eastern Time with a colleague of yours at IBM, Arun Bilgiri.

Paul: Yes.

Shimel: Are you familiar? Yeah.

Paul: Arun Biligiri.

Shimel: Yes.

Paul: Yeah.

Shimel: And Arun is gonna be doing this on Learn Why We Must Shift APM Left in the DevOps Lifecycle. And he’s gonna be also joined by Dan Kern, Solution Architect over at Prolifics. So you know if you’re listening to this and this is a topic of interest to you, not you CJ, I know you’re interested. But our audience, I’d highly recommend. You can probably register for this off of our devopsy.kinsta.cloud. Go to the Webinar and Events page and you can register there. But it should be dead on on topic for this. So CJ, I wanted to focus back on though this idea of shifting APM left, right. So when we talk about DevOps and how we fit in things like security and QA, now APM, that seems to be a common theme of shifting these things left. Get them earlier into the development process, right. Because the earlier it’s in, hopefully the better it comes out in the end, right. I guess my question to you CJ, is can we just continue shifting everything left, right. You know what I mean? Is there a point of diminishing returns of shifting left?

Paul: Yeah. I think in this particular case especially, you know it’s something that is a good thing to think about right from up front. Especially as the velocity of deployments increases, we would expect the development teams to be more and more you know working the monitoring of the applications in conjunction with the code. Because you’re just kind of thought to have a throw it over the wall kind of syndrome. Because you know that would be too slow in this world to make it successful. So that’s why I think the shift left is almost an inevitable side effect of the need to go faster. And also with some of the shift to cloud, you know the way things are done are also different. So more and more the application architectures and topologies are becoming more complex to handle geographically distributed deployments and so on.

So more and more we expect the development teams that are involved to be doing some of these operations automation just like they would work on you know features for the product. So some of these concepts surround you know cycle liability engineering and so on that are being out in the industry are just examples of why you know we’ll get more and more of a DevOps perspective on things that used to be just purely operations activities in the past.

Shimel: Got it. CJ, my next question with you on this is and by the way we’re running low on time so I only have one or two more questions left. Is you mentioned earlier one of my favorite things happening in IBM and that’s the Bluemix Garage method, which is an open source methodology kind of taking best practices and lessons learned from IBM themselves, as well as your partners into this methodology. Talk to us a little bit. Where does APM fit into there?

Paul: Yeah. So with this Garage method what we’ve been doing is to take the learnings from across the industry on agile practices and design thinking and you know the latest DevOps practices and lean practices and so on. And organize it in such a way that enterprises can learn how to act like a startup but do it at enterprise scale. So within that method, we talk about how you think and plan, and code, and deliver, and run, and manage, and learn around a whole culture of DevOps. So in this particular case as we talk about application performance management, we typically think of it in managed. But as we have been discussing here, it kind of permeates through the lifecycle because you have to think about the availability of your applications as you design and build them. And you have to write the code for the synthetic monitoring steps, along with your features of the product. And you have to deploy them as part of delivery. And then clearly you’ll collect and analyze the data as part of manage and learn. So I think this whole shift left of APM fits in very nicely with the Garage method and its different lifecycle phases.

Shimel: Got it. CJ, I apologize, but just as I promised, yeah, we’re way over 12 minutes already and we’re gonna need to wrap things up here. But before we do, I wanted to just ask you one final question which is usually one that I ask most of our guests here on DevOps chats. CJ, for our listeners out here, if you had to recommend one book that they should read, what should be the next book they read?

Paul: I would highly recommend folks read the Site Reliability Engineering book that has come out of Google. They talk about how engineers with development skills can automate a lot of what used to be production activities. That’s a very good read. Within IBM we’ve been doing these kinds of activities ourselves. You know me make sure that the individual squads are also responsible for their performance. But I find this is a good book for teams to look at if they haven’t already read it.

Shimel: Got it. Okay. CJ Paul, Distinguished Engineer at IBM. Thank you for being this episodes guest on DevOps Chats. Look forward to seeing you in person at some conference or another soon, CJ. And until then, keep up the great work.

Paul: Thank you, Alan.

Shimel: This is Alan Shimel of devopsy.kinsta.cloud for DevOps Chats. Thanks everyone. Have a great day.

September 9, 2016
DevOps Chat: Michael Olson, Puppet, A Roadmap for DevOps Success

devopsy.kinsta.cloud editor-in-chief Alan Shimel sat down with Michael Olson, senior product marketing manager at Puppet, to discuss a number of topics including the recent DevOps Salary survey that Puppet released. Another topic of discussion was the webinar Puppet is sponsoring and Michael is taking part in Sept, 27 titled, “A Roadmap for DevOps Success.”

This webinar is a great jumping-off point for those who are looking to set off on their DevOps transformation or even anyone looking for a DevOps reset. Please click the link to register if you are interested. In the meantime, Michael gave us a great amount of information about the topic and DevOps in general. I think you will find it very interesting and useful. This interview is a little longer than our usual (about 20 minutes), but well worth the listen.

As usual, the streaming audio is embedded below with a written transcript of our conversation below that. Enjoy!

Shimel: Hi. This is Alan Shimel, editor in chief of devopsy.kinsta.cloud. Here for another DevOps Chat. Very happy to be joined for this episode of DevOps Chat with Michael Olson, senior product marketing manager at Puppet. Hey, Michael. How are you?

Olson: Alan, I’m doing great. How about yourself?

Shimel: Great. You know Michael, it’s a very exciting time here for Puppet obviously. A lot going on in the world of DevOps, in the Puppet world and everything else. So before we get started with anything, what I wanted to talk about, our upcoming webinar. Why don’t you give our audience a little bit of background? What’s the latest with Puppet?

Olson: Sure. Yeah. Happy to address that and also say thanks for having us on the DevOps Chat today. It’s always good to catch up with you.

Shimel: Thank you.

Olson: So for folks out there who may not be familiar with Puppet, we provide a software platform that really helps companies and organizations automate the delivery and operation of all of their software. And the idea there being that you know in today’s world, software powers everything around us. More and more companies are recognizing the need to behave like software companies as a competitive differentiator, as technology is perceived as more of a way to improve the customer experience and kind of deliver better value to end users. And so we’re seeing organizations that are looking for automation as a way to ultimately deliver better software to their customers and end-users faster. And that’s really why Puppet exists. So, in terms of what’s new for the company, I would say it’s a great time to be here. We’re growing pretty rapidly. You know we’ve been adding new customers at a pretty astounding rate and really growing the organization and seeing a lot more momentum for organizations that are looking to adopt DevOps practices and more of a DevOps way of working, as well as seeing the role that automation plays in helping them get there faster.

Shimel: Sure. It’s a great time to be alive in the DevOps space. You know Michael, I wrote an article just this week on the results of your DevOps salary survey, which was just released. You know coming out of the Puppet DevOps State of DevOps Survey. And it’s certainly a good time if you have DevOps skills and you’re looking for a job. It seems to be you know an employee’s market. So no doubt you know what we’re seeing and what you’re describing is playing itself out in that way as well. It’s where the jobs are.

Olson: Yeah. For sure.

Shimel: Yeah. Crazy. You know I have friends who aren’t in IT and I posted the article on Facebook and some of them read it and saw kind of what the salaries were. And they were like you know do you have to be a rocket scientist to work in DevOps that you know those are the kinds of salaries. And I was like no, but you know it helps. But honestly you don’t obviously, right. You just gotta be into it. But that brings us actually Michael, to kind of the subject matter of our talk today. Which is this webinar we have happening on I believe it’s September 27th. Correct?

Olson: Yeah. That’s correct.

Shimel: And Michael, why don’t you share with our audience a little bit about kind of what the subject matter of our webinar is going to be.

Olson: Sure. You bet. So you know we spend obviously a lot of time at Puppet consulting with organizations that are either you know at a stage where they’re trying to build the business case if you will for change and for kind of evolving the way that teams work to deliver better software out to their customers and end-users faster. And we also talked to a lot of organizations that are you know looking for guidance on kind of you know how to scale a DevOps practice within their organizations. And you know I think the common thread that we’re seeing is that you know in this day and age in 2016, that DevOps really isn’t just for the unicorn companies out there if you will. You know the Googles and the Apples of the world. We’re seeing a lot more evidence that DevOps practices are really hitting the mainstream as more organizations you know realize they need to behave like software companies and improve the way that they work. And so really the goal of the webinar that we’re gonna be digging into on the 27th is kind of to provide a roadmap based on findings from the 2016 State of DevOps Report.

Ways of driving adoption of DevOps practices within your organization. And we’ll kind of cover that from a few different points of view. One of which is you know how to sort of build the business case for a DevOps way of working. If you’re maybe sold on the need to change, but trying to get either peers or managers to buy into your point of view. And then we’ll also address some of the cultural changes that we see our customers implementing and share some ideas on ways to align incentives and teams to improve collaboration. And then we’ll dig into you know some of the key technical practices that we see high performing IT teams implementing. And then some guidance on just you know where to get started to start to scale a DevOps practice within you know an enterprise organization. So it’ll be a lot to chew off in an hour Alan, but we’ll do our best to –

Shimel: I was gonna say Michael—

Olson: —hit all those subjects.

Shimel: —yeah, it sounds like a full hour of webinar right there. But you know Michael, one thing I want to stress and it goes back to what I was saying earlier about my friends who saw the article on the DevOps salary survey. Thinking about my goodness, you know you must need to be uber smart or something you know to be able to do something like DevOps. But so much of what you need to you know make a horse you know have a successful DevOps journey and transformation, I don’t know if it’s really sort of book smart, or intelligence, or you know rocket science. A lot of it is cultural and you know we tend to poo poo it. But a lot of it is about working together as a team. Getting buy-in. Getting buy-in from your boss and his boss. Getting buy-in from your team members. Getting buy-in from other team members. And I don’t know if that’s really you know “intelligence” or you know it’s more of social aspect. Do you agree or what do you think?

Olson: Yeah. Honestly I think that’s a pretty great point, Alan. And I’m a big believer here that you know DevOps is not something you can buy and it’s not specific technology. And I would be very skeptical of any software company or vendor that claims to be the DevOps tool. Because what we tend to see and hear is DevOps is really more about the cultural changes and the technical practices required to you know help teams improve the way they work. To deliver better value to customers and end-users. And so from a cultural perspective, I think you’re spot on. It’s you know how do we move from a culture of lack of alignment, of low trust, of silo-ed teams, to you know cross functional teams that share incentives, that are aligned around a common set of goals. That have that high trust where you can kind of complete the no look pass so to speak to other groups. And you know the outcome ideally being you know reducing cycle times. Getting software out the door faster that meets the needs of customers. And then being able to iterate and kind of foster an environment of continuous improvement. I see those as some of the key drivers behind you know what’s required for success with DevOps.

Shimel: Agreed. But you know I don’t want people to think I’m giving them a false sense of it either, Michael. You have to have a good understanding of environments, of tools, of what it takes for a successful software release, of what it takes actually for you know IT to help the business, right. I don’t want people to think that DevOps folks are a bunch of dummies who happen to just be really social, right. There are tools and skill sets that you know are kind of required. And so that being said, why don’t we go in a little bit deeper in terms of things we want to you know kind of peel the onion back a couple layers in this webinar. You’ve kind of given us a high level. But if we can go a little deeper.

Olson: Sure. Yeah. Let’s do it.

Shimel: So, let me start with this then. And that is sort of getting the buy-in on you know going forward with DevOps, right. Some people say it’s best to go top down. Some people say no, you gotta have buy-in from the bottom up. Some people say you got go top down and bottom up and meet in the middle. And I’m sure any and all of them can be successful in a particular given situation. But I think the issue then is how do you make that happen, right. I mean we recognize that’s an issue. Just if you can give a little preview, Michael of what we’re gonna do on the webinar. What would be some tips people can follow-up with?

Olson: Yeah. I think it’s a great question, Alan. And you know my take based on what we tend to see from our customers that have been down this path is its super important to start with the why. And what I mean by that is really focus if you’re trying to you know get buy-in for implementing a DevOps way of working within your organization, it’s really important to start with what are the problems we’re trying to solve and what is kind of the end state or outcome that we’re hoping or looking to achieve. And so one of the ways that we tend to see our customers be more successful at you know getting buy-in for a DevOps initiative is you know by focusing on the benefits that other organizations have seen from implementing you know a DevOps way of working. And we’ve got some pretty awesome research that we’ll share on the webinar next month that you know talks about just how much more agile and how much more fast moving high performing IT organizations that are implementing DevOps practices actually are you know around being able to deploy applications and infrastructure changes much more frequently than their lower performing peers. And doing so with you know much shorter lead times or cycle times.

But also being much more reliable. Actually seeing kind of a higher change success rate. You know faster meantime to recovery when things do invariably go wrong. And then we’ll also share some data that really shows and correlates kind of IT performance around you know moving faster, doing so more reliably with how that’s actually helping organizations win the marketplace. You know become more productive, become more profitable and achieve higher company growth at the end of the day.

Shimel: And that’s really what it’s about, right. I mean and you know what Michael, for those who are listening and it sounds easy because it relatively is rolling off your mouth. The language that you’re using, the terms that you’re using. You know I learned this in many years of security when I used to hear from so many security people. I can’t make the executive team understand why I need this IPS. Why I need this Intrusion Prevention System. And because they were talking to their executives about snort signatures and capturing packets, right. And executives don’t talk that language. I think it’s important to take note of the language you’re using Michael, you know again, not that you have to be a rocket scientist to do DevOps. But there’s a certain language of business. There’s a language of you know what is gonna be important not only to me and my team, but to my boss and his boss as well. So for those of you listening to this on streaming, you should rewind it to hear what Michael said again. Because I think you might understand more of what we’re talking about in hearing how he’s describing these things.

Olson: Yeah. And I think that’s a good point Alan, if I can interject. I think one of the things that we tend to see is adopting a bit of a chameleon approach if you will actually can be effective. And what I mean by that is you know really knowing your audience and making sure that you’re speaking the language of the people that you’re trying to sell on the value of doing DevOps. And so if you’re talking to folks in IT leadership roles, I think they’re gonna be more attuned to the notion of becoming more agile and improving the frequency of speed of software delivery and improving the reliability and quality of that software. But certainly stakeholders on the business side are probably gonna be more focused on how does this actually impact our ability to deliver value to customers and help the business grow and be successful. And so being able to tailor the message if you will you know to the people you’re speaking with, I think is an important skill and a trait when it comes to you know navigating an organization to build a case.

Shimel: Absolutely. So Michael, you know I mean obviously to me anyway, this sounds like we’re gonna have a great webinar on the 27th. And I hope people listening in at home will join in. You can find out more information by the way if you’re interested in registering for the webinar on devopsy.kinsta.cloud if you go to our Events section under Webinars. The webinars we’re doing are in chronological order and you can click on the graphic or the link and register from there and of course that’ll set you up to get reminders and everything else. Michael, we’re kind of running a little low on time. I’ve got two last questions for you. For people who maybe they haven’t heard enough yet about the webinar or maybe they have, but they have questions, anything else you want to tell them why this is a good webinar to attend. It’s worth their time.

Olson: Yeah. Sure. I would say you know the companies and IT professionals you know that certainly I talk to on a daily basis you know frequently fall into one of three camps if you will. The first of which is still trying to figure out what this DevOps thing really is and what it means. You know there’s still a perception at some level that it’s a loose and evolving collection of practices. And you know you walk into a room and you ask a room of 10 people to give their definition of DevOps, you’ll get 10 different responses.

Shimel: Yeah.

Olson: So I think if that’s the stage you’re at is still trying to kind of develop a deeper understanding of what it means to bring DevOps practices into your organization, we’ll definitely address that. If you’re sold on the value and just trying to you know get buy-in from peers or from executives within your organization, hopefully you’ll walk out of this with some ammunition in your toolkit to be able to have those conversations within your organization. And then I think the third camp is if you’re you know sold on the value, you’ve got buy-in from the rest of the team and you’ve started to implement more of a DevOps way of working and are looking to kind of scale that across the rest of the organization, hopefully we’ll provide a roadmap for you know ways to do that and ways to kind of take it to the next level. So ambitious agenda but if any of those three kind of current states apply to you, then definitely look forward to seeing you on there.

Shimel: Perfect.

Olson: All right. Michael, we’re over time but I’ve got to ask you my last question anyway. So, people listening, if you’re gonna recommend one book that they read, just one, what book do you recommend, Michael?

Olson: Oh, man. That is the million-dollar question, Alan. It’s a tough one to answer but you know there’s so many good books out there that I think cover kind of this and adjacent topics. I’m sure you know folks who are listening in have either read or heard about the Phoenix Project by Gene Kim. That’s a must-read in my opinion. Another one that I really enjoyed and I found really informative was a book by Jez Humble. It was co-authored by Barry O’Reilly and I think Joanne Molesky. And it’s titled Lean Enterprise.

Shimel: Yep.

Olson: And the focus is really kind of how high performing organizations innovate at scale in response to you know evolving customer needs and response to new technology. You know it provides kind of a roadmap for some of the methodologies that organizations need to become more efficient and ultimately deliver better value to their end users. So definitely would recommend that. It’s also you know a nice quick read that you can knock out. You know I’m a pretty slow reader so for me we’re talking a couple weeks. But I’m sure for most folks on the podcast we’re looking at maybe a few days or less.

Shimel: You know what Michael, it has a treasured place on my bookshelf here in the office and my copy is pretty dog-eared already. I’ve looked at it and referred to it many times. It’s an excellent book. You know a lot of people think you tell a Jez Humble book and they’re thinking the CD book. But the Lean Enterprise book in a lot of ways is a superior book. But anyway, great suggestion. We highly recommend it. And Michael, thank you for being this episodes guest on DevOps Chat. Again, we’re doing this webinar with Puppet on the 27th of September. So a little more than a month from when we’re recording this which is on the 26th of August. So, plenty of time to register. We want to see you there. Michael, continued success at Puppet. Continued success to Puppet. A lot of interest. As we said early on, it’s a great time to be alive. It’s a great time to be in DevOps. It’s a great time to be a Puppet. So you know do keep us posted. We’d love to have you back again in the future.

Olson: Absolutely. Always a pleasure, Alan. And appreciate the time and we look forward to seeing everybody next month.

Shimel: Okay. This is Alan Shimel for devopsy.kinsta.cloud on a DevOps Chat. And we’ll see you next time. Bye, bye.

September 8, 2016
DevOps Chat: Mark Nunnikhoven, Trend Micro on Hybrid Cloud

devopsy.kinsta.cloud sits down with Mark Nunnikhoven, VP Cloud Research at Trend Micro. We discuss hybrid cloud, hybrid cloud security, DevSecOps and more. Mark is very involved in research on the latest threats and trends in cloud security. This is a great interview that I think you will find very interesting.

As usual, the transcript of our conversation follows:

Alan Shimel: Hi, this is Alan Shimel, devopsy.kinsta.cloud, here for another DevOps chat, and I’m joined today by Mark Nunnikhoven of Trend Micro. Mark, welcome to DevOps Chat.

Nunnikhoven: Thanks for having me, Alan.

Shimel: I hope I didn’t mangle your name too bad, did I?

Nunnikhoven: No, it was perfect. It’s a tricky one. It looks really menacing, but ends up being relatively simple after you’ve heard it a few hundred times, so –

Shimel: Absolutely, very good. So, Mark, I asked you to join us today—I think we had done a webinar and talked a bit offline about, you know, some of the challenges around securing hybrid cloud and, you know, versus obviously people moving stuff to the cloud, people still have stuff in their data center, and what’s good for one may not necessarily be good for the other, but what’s good for both might be an entirely different thing. And I wanted to just spend a little bit of time with you talking about the challenges of securing the hybrid cloud.

Nunnikhoven: Yeah, it’s definitely an interesting topic that I don’t think gets enough attention, so I’m glad we can have this chat.

Shimel: Yep. Before we jump into it, though, Mark, I’d be remiss if I didn’t give you a chance to just let people know, I did mention you’re with Trend Micro, but what is your role there?

Nunnikhoven: Yeah, I’m the vice president in charge of cloud research. So I look at how organizations are tackling security in the cloud, in hybrid environments for, you know, traditional servers and workloads, containers, serverless, sort of anything that’s breaking new ground. It’s a lot of fun and there’s a lot of really interesting stuff happening.

Shimel: Great. So, Mark, you know, I think I started us off by saying there’s people who are making solutions for the cloud, there’s people making solutions for the data center, the ARM RAM. And what’s good for one is not necessarily good for the other, and then, of course, most of the world is living in some sort of hybrid environment.

Nunnikhoven: Yeah.

Shimel: What do we do?

Nunnikhoven: [Laughs] That’s a great question, ’cause, you know, I’ve seen—working with organizations around the world, I’ve seen sort of all of the possible scenarios, I think at least the major ones that people kind of come to thinking might work, and they sort of range from we’re going to force data center processes and controls into the cloud, which is a recipe for disaster. You know, they’re very different environments, to the opposite, of we’re gonna take everything that’s working in the cloud and we’re gonna force it on the data center, to, you know, we’re gonna run two completely different environments in completely different ways, and essentially double the workload. None of those is really satisfactory. Sort of the best route forward tends to be looking at what’s working in the cloud and trying to push a lot of those concepts into the data center. But you still need to make adjustments for the reality that the data center is very, you know, sort of slow and very high level of rigor and very formulaic, and, you know, very well-established. So you do need to make adjustments, but, you know, the goal is to get one way of doing things with allowances for the difference in both environments.

Shimel: Yep. And Mark, as you said, that may be the goal, but, you know, from day one, you obviously—you need a plan to get there. And can you maybe share with our audience a little bit, where do you see the logical steps, if you will, to getting there?

Nunnikhoven: Yeah, and I think that’s a really good way to phrase it, you know, because we can all—we all love the architecture Powerpoints and you go the events and you get real excited about what the eventual design and implementation will look like. But getting there can be really ugly and really messy. I think the biggest thing, and it’s unfortunately the thing that people tend to forget about, is looking at not just the security, but the operations processes and controls that you’re using today, and why you’re using them. And I think that’s the big piece that people miss, is, you know, why am I using something like an intrusion prevention system, or why am I using anti-malware or why do I have this change review board for any sort of operational change I want to make. And once you start to dig into the why you do these things, you realize that the implementation can change, as long as you’re still meeting that why.

So, you know, we put intrusion prevention in place so that we make sure that any time we open up traffic to this server, that we verified it is actually secure web traffic like we’re expecting. Once you know that’s the reason, then you can look and say in my data center, that makes sense to have a big perimeter appliance doing that job, whereas in the cloud, it makes more sense to have something running on the host, doing that same job. So you’re still getting the same answer to why. It’s just the how is different in each environment. So it’s—you’ve got to dig into those, and it starts to clarify what you’re doing.

Shimel: Got it. Mark, what are we seeing—I mean, what—obviously at Trend, you’re probably talking with a lot of customers. Are they coming from the cloud down with their solution? In other words, buying a cloud solution and building—or from the data center up, if you will?

Nunnikhoven: A lot of the time we’re seeing the data center up, simply because it’ll be one team within a larger organization. So we’re talking mainly, you know, traditional enterprise and large governments. And it’ll be one team that’s gone and said we’re gonna push everything and build it new in the cloud, and when they start to kick off that process, they start to get a lot of existing policy and existing culture enforced on them. So they’ll get, you know, specifically the security. They’ll get people saying, well, you need this, you need to make sure that, you know, you go across these boundaries in your design, you’re networking a certain way. So they start to try to take those same designs, which are great in the data center, but horrible in the cloud, and they try to push those into the cloud, and they usually end up failing. And then about six months afterwards realize that they need to take a new approach, because it is a completely different environment.

Shimel: Got it. And, you know what, Mark, I’m a firm believer that at least for the foreseeable future, five, 10 years, hybrid cloud is the—is the dominant, right, the dominant usage pattern that we’ll see from people. Is this yours as well?

Nunnikhoven: Yeah, 100 percent. And for me, it’s simple economics. As much as you want to be in the cloud, if that’s the case, if bought in even, you know, you’ll see it at the major events from the big cloud providers. They’ll pull up big enterprises who are—their CEO or the CIO is, you know, yelling from the top of their lungs that they’re gonna be all in on the cloud. Even in those scenarios, they’re still going to take 12 to 18 months to move out of their data centers.

But the reality is most enterprises have already made a multimillion dollar investment in technology that’s working. It might not be working as fast as they want, but you can’t walk away from that. The cost savings in the cloud, if they’re there, are not that significant that you’re gonna leave millions on the table. So the reality is, you know, for a standard data center life cycle, so like you said, a five to seven year term, you’re gonna be dealing with two environments. And it’s not just that it’s two environments, it’s two environments that are completely different. It’s very much apples and oranges. So you do need a different approach.

Shimel: Got it. And, Mark, I don’t want to put you on the spot, but what Trend Micro specifically, what kind of solutions are you guys, you know, working with customers on?

Nunnikhoven: Yeah, so one of our big push, and we’ll just hit it real brief, because we don’t want it to be a sales pitch at all, it’s just we have a platform called Deep Security, and we built it with the principle of trying to put security as close to the data and application as possible. And because of that, we’ve been able to adapt it for multiple cloud use, for data center use, for the hybrid scenario quite well, because we’ve taken a lot of the principles that work in the cloud and made it so that you can leverage them where it makes sense in the data center. So a lot of automation, a lot of programmability, and a lot of intelligence in the products so you don’t have to worry about the nitty-gritty of dealing with security day to day, unless it’s really urgent and requires you to intervene.

Shimel: Excellent. And, I mean, Trend is obviously not the only one doing this, Mark. When we talk about cloud too, I wanted to ask you this, public versus private clouds, where are you seeing this kind of—you know, are we—you know, to me, a private cloud is—goes hand in hand with hybrid, right? But there are people who are doing public cloud and data center, and that’s hybrid as well.

Nunnikhoven: Yeah, and I find for me, you know, private was a real big push back from a lot of the incumbent data center vendors, and, you know, we’ve kind of gotten out of that hype phase and into the reality of it. And I tend to see what a private cloud is, is somebody who’s taken the data center and adapted a lot of the cloud processes and the ideas behind a public cloud and implemented them within their data center, which can be a really good thing. So you can get on-demand resources, so you just query in API instead of sending out a ticket and getting a bunch of people to do work. You know, getting that accountability, getting that accessibility and that visibility that we’re used to in the public cloud, getting that in the data center.

So I think the ideal hybrid scenario is leveraging private cloud/public cloud. A lot of people aren’t there with their data center, because implementing change takes a long time. There’s a lot of cultural change, a lot of tooling change. So you’ll see them with sort of more the traditional data center approach. But if they want to be successful over the next few years, they need to start pushing more of those private cloud ideas internally, because that will help them have one set of processes and tools across both the public and the private cloud.

Shimel: Makes sense, makes sense. And Mark, what about people, though, who just say, you know what, I’m—I’m biting the bullet, I’m just gonna do cloud, you know, or I’m just gonna do data center. You know, first of all, nothing is forever, obviously, right? You could say that today, but things change. Is the Trend Micro solution, specifically, let’s say, is it one that will work with one, but that scales to the other? Or, in other words, how do we stay out of dead ends?

Nunnikhoven: Yeah, and specifically from us, this is something we’ve been dealing with with our customers over the last few years, because we’ve got customers who are 99 percent in the cloud and 1 percent in a data center somewhere, and the exact opposite. And it really—you know, every culture and enterprise is unique in what their blend and their mix of those environments is. So having the tool be agnostic to that is really important. So, you know, we’ll scale from protecting one system, to protecting 100,000 systems, with the same platform, very, very easily.

And I think there are a lot of projects out there, you know, not just commercial offerings from Trend Micro, but we’re seeing this a lot in the operational monitoring space. So, you know, things like Ryman or Logstaff, which are two great open source projects to help you correlate data, they work equally well in the cloud as they do in the data center, and I think that’s really a big win for people, is that you need to put the assets in the environment that makes the most sense, but you should be able to use modern tools in both. And that’s a real big, important point for people to take away, is that you want to be—even if you’re in a traditional sort of slowing evolving data center environment, you want to be making sure that you’re leveraging some of the great advances we’ve made in security and in operational tools.

Shimel: Excellent, excellent. Mark, we’re coming near the end of our time, as this always seems to go quick. But let’s talk a little bit about the research that you’ve been doing, and just give our audience maybe a little insight. What are you kind of researching now? What do you find really interesting?

Nunnikhoven: Yeah, the biggest area I’m focusing on right now is the rise of what’s been deemed the serverless architecture. So obviously sort of a poor choice of names. There are servers somewhere. But it’s the idea of leveraging a function as a service as something like Microsoft du jour functions or AWS Lambda, where you’ve just got code that you input that runs in a sandbox on someone else’s system and you don’t have to worry about any of that. So scaling and operational tasks are kind of out the door, but these are heavily leveraging SaaS services and you’re sort of picking the best aspects of multiple providers, and stitching it together into one big application. And there’s a lot of really interesting advantages for the business there, because you’re focusing purely on delivering value to your users.

But from a security perspective, now you’ve got multiple parties and systems that you have to trust, that have to work together, that have to share security controls, and then that is normally only one application in a suite of others. So you’ve got serverless applications, you’ve got applications that are running on containers, and then traditional applications. So I’ve been looking at not just the serverless, but how you do you address all of these in a consistent manner, so that you can apply security to the data where it’s being processed.

Shimel: Excellent. Mark, we are butting up against time here, but one last question, and it’s one I frequently ask our guests here on DevOps Chat. If you had to recommend one book to our audience to read, not necessarily the last book you read or anything like that, but one book they should read, what’s your recommendation?

Nunnikhoven: Yeah, that’s always a tough question. I love reading, so I’m always reading three or four books at a time. And, you know, it’s a safe assumption that this audience has already read “The Phoenix Project.” If they haven’t, they should. My latest favorite in this space is called “The Art of Monitoring.” It’s by James Turnbull, and it’s a look at how to implement metrics and measurements around running applications, regardless of where they are. So it talks about logging, it talks about real-time alerting, and it’s a really great approach, in that, you know, it’s always looking at results. So not just collecting data for data’s sake, but it sort of walks you through how all of this stuff should roll up to give your teams some actionable insight on how your application is doing. It’s a really great book.

Shimel: Got it, interesting. Well, Mark, thank you so much for being this episode’s guest, of DevOps Chat. We’d like to maybe have you back on sometime and talk to us about more of the research you’re doing. Continued success to you and Trend Micro, and just thanks again. This is Alan Shimel, for DevOps Chat, and thanks for joining us. Until next time.

August 22, 2016
DevOps Chat: John Harris, LeftShift on DevOps Consulting and Continuous Testing

This episode of DevOps Chat has us speaking with John Harris of LeftShift IT. LeftShift is based in London, but has customers the world over. He speaks with us about DevOps consulting and continuous testing. John has some great insights to share that I think you will find interesting.

Alan Shimel:                Hi, everyone. Alan Shimel – devopsy.kinsta.cloud here for another DevOps chats. This episode’s guest is John Harris of LeftShift IT. John, welcome.

John Harris:               Thanks, Alan. Good to be here.

Alan Shimel:                Thank you. So John, what exactly is your role with LeftShift

John Harris:               My role is the Head of Continuous Delivery in DevOps with LeftShift.

Alan Shimel:                Okay. And John, you know what? Some people in our audience are probably not familiar or may have not heard of LeftShift IT before. Why don’t you give us quickly a background of LeftShift?

John Harris:               Yeah. We’re primarily a services consultancy in the continuous delivery – DevOps continuous testing space. We work quite a lot with IBM, a lot of other different vendors. Based in London and the UK, but we have a lot of our business offices based in the U.S. as well.

Alan Shimel:                Sure. And John, before we jump into the subject of today’s chat, which is around continuous testing, I want you to take a moment and just talk about this burgeoning field of DevOps consulting. It seems to be exploding. I was in London for the DevOps Enterprise Summit last month and I was absolutely blown away with the diversity of firms from big to small that are offering DevOps consulting services. How long has LeftShift been in the DevOps consulting space?

John Harris:               We’ve been in the area kind of on and off I guess you could say ten years. I guess most people would say DevOps has only been around since that original kind of DevOps coining days again in Belgium, but I guess a lot of people say the discipline itself had been around before the name, so I guess the processes around DevOps you could say we’ve been involved in for quite some time I guess.

Alan Shimel:                Sure. And John you know I don’t think we would be seeing this explosion of DevOps consulting if there wasn’t a wanting audience for DevOps consulting continuous delivery consulting services. Is that pretty much what you’re seeing with LeftShift? I assume business is good.

John Harris:               Yeah. It’s one of those interesting areas where one of the things I guess the DevOps consultants could say is you don’t just want to create a new DevOps practice in your company. You don’t just want to bring in these pieces, but it’s a difficult loop because you’ve got to then support those processes and you’ve got to get that knowledge into the organization somehow, so I think our model is firmly to go and help people get started and gussy up their own practice and their own good processes and then kind of lead them to it, so yeah absolutely.

Alan Shimel:                Got it. So John, let’s pivot a little bit here and talk about continuous testing. So, I will tell you that on devopsy.kinsta.cloud the whole notion of testing, continuous testing, automated testing is one of the most hotly debated and in some ways controversial topics within DevOps. Wondering if you see similar?

John Harris:               Yeah. I think so. I mean I think traditionally in so far development, testing has traditionally kind of been seen as just the necessary part that you have to do at the end, but I think now that continuous delivery is becoming a real discipline and people are being forced to go faster and faster for getting ahead of the market and things like – can’t afford to see testing as a poor cousin of development anymore and I think testing is really becoming – people realize I can throw stuff out into production as quick as I want really, but actually it’s throwing it out with the quality that it needs to – that product to still be viable in the market. So I think absolutely. The drive towards testing is long overdue, but it’s definitely getting started.

Alan Shimel:                Got it. And John, can you have continuous without the automation though?

John Harris:               Personally I don’t think so. I think that DevOps really – one of the biggest buzz words for me – DevOps and continuous delivery is really the organization. I think you have to have the process behind it, but I think when you go towards anything delivering more rapidly through all of these stages in our development life cycle in production, I think you just cannot scale at the size that we need to in order to get that stuff out without automating the process.

I mean when you talk about the union it forms like Netflix and Etsy and all of those guys, now three, four years ago, there’s no way you can deliver that kind of scale without putting in the automated tool in and also the processes and the culture around that to enable that to where it will have the effect that you need.

Alan Shimel:                Sure. So John, I think one of the controversy – not controversy, but one of the big discussion points around this though is what does this mean for the traditional Q/A role and for the people in the Q/A space?

John Harris:               Yeah. I think teams have traditionally kind of been split. I mean obviously we have these silos and DevOps as kind of trying to address the silos of development and testing and ops and those kinds of things. I think again, testing’s one of the things that gets left out of that, but certainly in the customers that we work with, we’re seeing a lot of Q/A teams being retrained in certain ways, brought into the development side of the organization, having their practices changed to more of a development software engineering kind of way of working.

We’re certainly seeing some of the geographic splits that have been traditional in this area kind of being broken down, perhaps testing, quite a lot of off shoring work in testing. Some of that’s coming on shore. Testers are becoming more technical but yeah, retraining and the different skills required now for the Q/A role, to bring that into more of a technical automation. That’s certainly a question a lot of our customers are grappling with right now and I think the decisions they aren’t just technical, but they go into the culture side of the company and how the company has organized itself. So yeah, it is a contentious area. I agree.

Alan Shimel:                Yeah. It certainly is and it’s really one of those – for people in the Q/A space, it’s a pocketbook issue, right? They perceive a threat to a livelihood, even though I don’t think that’s the case. I think it allows them actually to soar and higher and do bigger and better things, but there’s certainly that element to it.

John, I want to talk for a moment about service virtualization and we actually have a webinar coming up on I think it’s August 23rd where we’re going to looking at a real unicorn company – Mertz Shipping Lines, which is I think is 80 years old or something in traditional shipping, not what you would think of as your Google, Facebook kind of company. But they’re going to be talking about service virtualization, shifting left. Thoughts on that at all?

John Harris:               Yeah. Service virtualization is an area that we work with quite a lot, especially around the IBM tool set. And yeah, Mertz is doing great work. Almost all of the organizations that we work that are trying to do some kind of parallel development, I mean one of the patents that we see is building the y and Rex API layers on top of some of their legacy – so business services and things like that and they want to do some parallel development with the ____, with the Rex, with the user in space layers. So SV’s really able to give those teams a really solid platform because everything’s based on their service interface definitions and it can really do some proper parallel development there and we’re seeing some great shifts left with those development teams and actually the ability to identify a whole bunch of defects before they would even go and integrate with each other.

I think we had one team who identified over 100 defects in the early testing stages using service virtualization before they even would have integrated with the other services. They were able to get those fixed even before they went into their next integration environment, so that was a really great success story – service virtualization.

Alan Shimel:                Yeah, absolutely. I think I interviewed the Mertz guys at Interconnect last year and it was an interesting case study. I guess we should mention – there is a Service Virtualization for Dummies book that people can download and I don’t have the URL in front of me. I’ll try to include it in our notes. I think it comes out from IBM for people who are interested in this. But John, let’s return – what do you see – what in your role with LeftShift, what do you see as sort of the next frontier where the – not the battle, but where there are points to be made, where there are battles to be won for lack of a better word in the near term future?

John Harris:               I think the biggest one really and we’re starting to see the shift now, but it’s still early stages and the custom is that – for the unicorns and the startups, this is probably not going to be a big bull, but certainly for enterprise – user interface testing is still very prevalent and we talk about the testing pyramid how most of our tests are one of the unit tests and then we’re gonna have a good base of integration tests and then a small percentage of UI test if you want.

I think currently a lot of our organizations have one of them that’s flipped on its head because it’s easy to do UI testing and reason about it going to the business, but now when we go faster, I think the traditional focus on UI testing is going to have to go away, but when we talk about APIs on top of everything and things like the API economy and a lot of systems now just don’t have UIs. Coming out with a lot of systems that are all API driven and smart devices.

I think everything’s going to have to be integration tested. I think the APIs and the logic behind them is really where the core business functionality is, so I think that’s where the importance is gonna be and it’s going to be moving organizations and showing them that integration testing and API testing is not the way to go and obviously automating that as part of their delivery pipeline, which is sometimes a little more difficult to do on the UI side.

Alan Shimel:                Yeah. Quick question on that because I thought about how to deal firsthand with this issue. Shouldn’t the API testing – at least the tests themselves come from the same people who are writing the API? In other words, where’s the burden? Should the people who are providing the APIs also provide the testing for it or is that sort of letting the wolf in the chicken coop, right? Where you’re using someone else’s API. The burden is on you to make sure that that is in fact working with your system.

John Harris:               Yeah. That’s a really interesting point I think and there are different kind of philosophies around it. Myself, we work a lot with the virtualization and the testing side of it, so we would say that if you’re developing the interface then you’re also in charge of developing the basic virtual service for that to integrate with your consumers, but I’m very much on the side of consumers developing the API test or the APIs that you consume, because if you think about the case where I’m a consumer, I may not need every field in an API. I may just use a few if I’m developing loosely coupled micro services let’s say.

So I’m really in favor of each team who consumes an API developing their own tests and then contributing those tests to the API team so they can be run as call, every build or every deployment. So then if I change functionality and those tests fail, I know which team gave those tests to me and I can go and alert them, “Well, look I’ve made a change and I’m just going to break your implementation or your call of this API, but I may not have broken anyone else’s.”

I mean I think putting the burden to test every piece of functionality, especially as we go to more loosely coupled services is kind of an unreasonable burden on the team developing that API.

Alan Shimel:                Got it. You know what, John? Believe it or not as I told you I think before we went live, time goes really quick on these and we’re coming up on the end. If someone wants to find out more about LeftShift, where can they go?

John Harris:               I think it’s LeftShiftIT.com and we’ve just revamped out website, so they can find out all about our services and products and everything we offer on there.

Alan Shimel:                Okay. And then finally John, I wanted to end with the kind of question I guess I ask just about every guest, which is for our audience out there, if they’re gonna read, what should – if they –hopefully if they do read everyone should read books. What do you recommend is the next book our audience reads?

John Harris:               I’m a big Jez Humble fan and I’m not going to recommend Continuous Delivery, because I’m sure everyone’s read that who’s listened to the podcast, but is Lean Enterprise book – How High Performance Organizations Innovate at Scale and it’s Jez Humble, Joanne Molesky and Barry O’Reilly is an awesome book for any enterprise looking to get into this kind of area.

Alan Shimel:                Absolutely. I actually have it on my book shelf in the office. Good one, John. Anyway, I think that’s gonna use up our time here on this edition of DevOps Chat. John Harris, LeftShift IT, thank you very much for being our guest and we look forward to hearing more about LeftShift and continuous testing service virtualization going forward and continued success.

John Harris:               Great. Thanks for having me, Alan.

Alan Shimel:                Thank you. This is Alan Shimel for devopsy.kinsta.cloud and DevOps Chats. Until next time, have a great day.

August 16, 2016
DevOps Chat: Dave West, CEO Scrum.Org

I recently met Dave West, CEO of Scrum.org. While not one of the founders of Scrum.org, West is the CEO and product owner at Scrum.org. Dave and I spoke a bit what is happening with Scrum.org and how it interacts with DevOps. If you are interested in Agile, DevOps and Scrum, this is a good DevOps Chat to listen to.

Here is the SoundCloud audio and the transcript is below:

Here is the transcript of our conversation:

Alan Shimel: Hi, Alan Shimel here for another DevOps Chat. And this DevOps Chat is with Dave West , product owner and CEO of Scrum.org.

Dave, welcome to DevOps Chats.

West: Oh, thanks for inviting me Alan.

Shimel: Thank you. So, Dave, I’m going to make a wild bet that most of our audience at least is familiar with Agile and Scrum. But maybe some of them aren’t and maybe there are even some who aren’t familiar with Scrum.org and the role it plays within the Agile community. So why don’t we do a quick level-set of Scrum.org and how it relates to Agile and Scrum.

West: Yeah, thanks, Alan.

Yeah, probably. It’s definitely a confusing fragmented place, the Agile community. So Scrum.org is an organization—mission-based organization created by Ken Schwaber, one of the co-creators of Scrum. Him and Jeff created Scrum—interestingly, in the building that I’m talking to you from, over 21 years ago. The outing 21-year anniversary is in October. Maybe it’s October the 19th. Interestingly. So they created Scrum.

Scrum.org is an organization that Ken created to, basically, focus on improving the profession of software delivery. We do that with a very large, active community—I suppose not very large—of professional Scrum trainers. About 170 of those. We do that with assessments; training and assessments around the world.

A significant number of people visit Scrum.org every day to either assess their knowledge or to connect up with a trainer or some training class.

Shimel: Sure. And Dave, one of the interesting things about the different classes and courses, if you will, that Scrum.org offers is the—there’s different sort of—I forgot the exact word, but there’s different roles. Right? Within the Scrum training.

West: Yeah, I must—what’s interesting, actually, Alan, is that particularly for this audience, one of the reasons why Scrum.org came into being was obviously, Ken created Scrum Alliance.

He left Scrum Alliance because they wanted to focus on the world of work. And Scrum.org cares about software delivery, and that’s a very important distinction. And so our professional Scrum developer class is actually—focuses on the practices for doing done software. And when we mean, “done,” we don’t mean, “almost done.” We don’t mean, “Oh, well, it’s kinda done with me.” We mean done. Meaning, potentially shippable. And when we mean potentially shippable, we don’t mean potentially shippable because operations haven’t looked at it yet, and that’s the potential. We mean, that the product owner can flip a switch and it’s live in the masses.

So ultimately, this technology focused class, PSD, is one of the reasons why Scrum.org came into fruition, and obviously Scrum Master Product Toner—that the three roles of Scrum—we have classes for all of those different roles, and they’re very team-based. And so that potentially you could have more than two roles in the same class, as well with our team-based classes.

So yeah, we definitely—we’re trying to improve the profession, Alan. So we have to provide training and certification. Third-party, validated certification on that profession and those professional skills.

Shimel: Got it. So, Agile’s been around now for a number of years and at this point, I don’t think there’s any doubt that it’s gone mainstream, obviously and has a tremendous impact across the entire software development world spectrum. But, Dave, specifically for as it relates to DevOps, often people say, “Well how do those work together?” Right? I’ve heard people say—actually devopsy.kinsta.cloud before I had started it as a site, when it was just a blog, sort of said, “Picks up where Agile leaves off.” But I don’t think that’s necessarily true. I don’t think it was true then, it’s certainly not true now. How do you describe—let’s put it that way: How do you describe that relationship?

West: It’s an interesting one. In fact, recently I was on a presentation with Ken Schwaber. It was a DevOps presentation at a DevOps organization and event and Ken and I were talking about DevOps and Ken’s perspective is very interesting and I think it sort of sums up the original signatures of the Agile manifesto’s perspective on it.

Ultimately, they believe and he believes in particular that we needed DevOps because nobody really got Agile. And it’s interesting because when they—when the Agile manifesto was signed one of the key terms was, “working software.” Working software. The 12 principles—working software frequently, delivering working software. That word, that phrase, “working software,” is frequently described in the manifesto.

Scrum focuses on it now. Many people get Scrum wrong because frankly, and I don’t know if you see this, Alan, and if other people have said this to you but, what most people do is they take Scrum and then try to put it into a Waterfall life cycle.

Shimel: Yeah.

West: So they sort of create these things around Scrum and particularly in the DevOps world, the bits after—they have this whole set of processes after the Scrum and hardening sprints. They have a release train that goes through, you know; Scrum’s just a series of stations on the release train journey and it ends up in operations and the like.

And so ultimately, Ken would argue that it’s just, unfortunately, people didn’t understand Agility or Scrum in particular and that’s what led to the DevOps movement.

I have a slightly different view. I think that the Agile was very focused on at least getting testers and requirements people and the customer and the developers together in some way. And by that focus—and that focus was important to get to improve how we’re doing software—it highlighted that we actually need other people involved and that led to this sort of movement; combined with some technology changes like stuff around the cloud and the ability to self-provision and all that kind of stuff.

So, it led to this sort of DevOps movement. I’m not sort of anti-DevOps. I think DevOps is an awesome set of ideas. I think people like Gene Kim and the Phoenix Project etc.—amazing stuff. But ultimately, in my opinion, it’s all about improving the profession of software delivery and it’s all about Agile software and I see Scrum and a variety of other approaches really just being incomplete without the ideas of DevOps in them. And that’s certainly true of our PSD class. That’s certainly true of the message that we send to our customers. Sometimes they don’t like it when we say, “Okay, what does done mean to you?” and they say, “Tested.” And we say, “Not quite sure. There’s a few things after test.”

Shimel: Correct.

West: And they go, “Well, no. There’s nothing after test to us. That’s when those ops guys get involved.”

Shimel: Yeah.

West: And they’re like, “Well, there might be a lot of—does ever defects come back into the process after test?” Well yeah, of course, you know, there’s – “And do ever customers have issues with it?” Oh yeah, and, “Do you ever get operations saying, ‘well we can’t get this to run on this environment?’” And do you ever say, “It works on my machine”?

And all of those things get in the way. All of those things that, whether you call them debt, whether you call them quality issues, get in the way of delivery and working software that amazes the customer, and getting that feedback.

So DevOps is a great set of practices and ideas and a great movement than can make Agile even more successful.

Shimel: Absolutely. I call those things “life,” by the way. But, you know, life gets in the way of the best-written software.

So, a couple of things Dave. I have two specific questions I’d like to ask you.

One is, you know one of the things that—maybe it’s been a double-edged sword for Agile/Scrum movement—but in my mind it certainly had so many positives, was the whole idea of the Agile manifesto, right? And sort of codifying if you will. What it is; the definition is. And then I think that leads to the ability to really nail down roles and training and methodologies.

Well, as you know, in DevOps, there’s been a big resistance from even defining it officially. We never had a DevOps manifesto and there probably never will be one either. Do you view that as—let me contrast that with the Agile and Scrum experience— positive? Negative? Double-edged? Both ways? What do you think?

West: It’s interesting because I think a lot about how you drive change into the world and obviously at Scrum I spend—at Scrum.org I spend a lot of time thinking about the success of Scrum. Scrum, as I said, turned 21 or turns 21. It currently can’t drink but in November it’s gonna be crazy.

Shimel: Mm-hmm.

West: In October, it turns 21 and I think about the success and Scrum is practiced—I was talking to Ken this morning, and it’s funny because I said, “You do realize Ken that over a million people every day, do a daily Scrum.”

Shimel: Yep.

West: He said, “Wow, that’s a lot, isn’t it?” And it’s practice.

Now, whether it’s practice—well, Alan—whether they’re doing it right and whether that actually is good, and lots of questions. But ultimately, you can’t argue with the success of Agile and Scrum. And you can’t argue with its—and so I often think about what makes it successful and is it the manifesto? I think in part it is.

I think it provides a set of principles and ideas that sort-of provide the social system as it were to the practices that Scrum encourages. And I think things like the Agile conferences and that continues—you provide a place for people to talk about it, which is good. I also think there needs to be a very effective commercial model and when I mean commercial model—a commercial model around driving, making people go to pay their mortgage and put food on their table using Scrum to help them do that. Whether that’s through training, certification, writing books—there’s over a hundred books with Scrum in their title just on Amazon. There’s like 130 and I got bored counting. And I didn’t count the foreign books obviously because I’m English, and that’s against my principles.

But what’s interesting is that—so that commercial model is incredibly important and I think also ownership. I think the one thing that we’ve found with the Scrum community is that Ken and Jeff have continued to really push it and drive it and that ownership connected with certification, assessments, training, books, community—strong community—simplicity, because I think that’s a very important idea that comes out, have allowed Scrum to be successful.

So, I look at DevOps. And DevOps is very fragmented—even more-so than Agile. Vendors tend to have taken it and defined it to their own needs. You know, the Scrum Guide is the definitive definition of Scrum. It’s about 16 pages. It’s translated into over 40 languages and you can’t—it tells you what Scrum is. And if anybody says, “Oh, well, to do Scrum you have to do Jira and Jira does this,” I’m just using Jira as an example; it’s an awesome tool. No, actually, no, Scrum says this and yes, you can have ways of doing the daily Scrum with your Jira board and whatever, that’s cool. But Scrum is Scrum. And the problem is we’ve got all these vendors defining DevOps to be what they want it to be. To sell some software. All good—I mean, fair play to them. I would do exactly the same.

So, without that sort of body of knowledge, without people sort of saying, “Hang on a minute,” sort of leadership, clear leadership. Without a commercial model that’s driving DevOps into organizations, or Scrum into organizations is another example. I think you have some significant challenges. I’m not sure they need a manifesto Alan, I’m not sure they need—but they definitely need a definitive what it is, however that’s done. It could be done with a guide. Or it could be done with something else. And I think that it needs that sort of leadership as well. And Gene is awesome—Gene Kim and the guys. There’s some really good thought leaders, but again, they’re fragmented as well.

Shimel: Sure.

West: Is Jez Humble a thought leader in it? Yes, he is. But he talks about continuous delivery. He doesn’t really talk about DevOps and …. That’s challenging.

Shimel: Yeah, I know, Dave. So just, my 2 cents on it is, it’s very much a two-edged sword. In some ways, it’s been its biggest help and in some ways its biggest hindrance.

I’m just back from London with Gene Kim’s DevOps Enterprise Summit, London took place and I interviewed all the speakers there and we did a ton of video and speaking with people and what’s interesting is by its lack of definition, the DevOps way if you will—the DevOps way is whatever you—sounds like something out of the Dune movie, the Weirding Ways. But, the DevOps ways are that patterns or whatever you want to call it is moving even beyond Dev and Ops. Dev and Ops working together to encompass security, QA, other parts of the IT stack and even beyond the IT stack, we heard stories of marketing and biz and HR even, teams that are starting to use Kanban and stuff like this because it helps them. I mean, look: Here at devopsy.kinsta.cloud, we do a 9:30 standup meeting around the table every day, right?

And you know, I don’t consider us a software company, per se, or that we’re developing software but the entire on-prime staff is in that meeting. And we do our check-in and so forth. But that being said, that lack of definition has almost, I think enabled DevOps to move beyond pure Dev and Ops. But you speak to—you talked about Jez Humble—you speak John Willis for instance; another DevOps, kind of, personality who’s been around a while and John says, “No, I’m more of a purist.” DevOps is about Dev and Ops. Right? I don’t buy into that whole kind of thing, but that all being said, that kind of helped it not having that definition but to your point, it hindered it in that you can’t really put your thumb on it and it’s nebulous and a lot of people say that. Right?

West: Yeah.

Shimel: And it’s this—

[Crosstalk]

West: It might be good and it might be bad. What ultimately all of us are striving for is the values of the Agile manifesto.

Shimel: Sure.

West: And DevOps is doing that as well. It’s about delivering done. And it’s about breaking up batch sizes to smaller increments of value driven by hypotheses or experiments or ideas and it’s about delivering practices which the DevOps community have in spades of actually being able to do that.

Shimel: Yep.

West: So if you have the principle of delivering software frequently, and observing it’s use by customers—if that’s a principle that’s driving your delivery mechanism then it’s crucial that you get that transparency. You instrument etc. You do it frequently, you get the batch size smaller, etc. Those principles—and they all trace back to that ultimate set of Agile ideas—and those ideas are basically all in response to the fact that we’re working in environments where there’s a large amount of unknown. Whether that be technology, whether that be business. And those unknowns require us to work in a different way.

The traditional, very efficient, big silos, clear hand-off, control points, get in the way when there’s a large amount of unknown and where variability is the currency of the entire operation. And when you do that, you have to work in different ways. And all those practices, make it so much better. And I think that’s what we need to concentrate on.

[Crosstalk]

Shimel: Those are the universals. Dave, I think that’s universal. Yeah.

West: And I think that’s what—and I think, to be frank, most of the—I know Gene definitely is very, very conscious of that. Obviously, protecting his brand as he needs to. Yeah, I just love the fact that all these vendors positioned DevOps for their own means. Yeah, so, I don’t know. What I do know is that Agile isn’t versus DevOps and Scrum.

[Crosstalk]

Shimel: Certainly not.

West: And Scrum isn’t versus DevOps and we need to stop thinking about the Sprint Review as a phase gate to release to operations. And we need to think about it as a mechanism for learning, inspect and adapt. Learning at the boundary of the Sprint. So, we’ve got this chunk of work—two weeks of work—we’ve delivered some software and production hopefully during that two weeks of work. Operations is part of our Dev Team. There just—whether that be directly or indirectly. Obviously, we know that if it’s indirect, cues are bad because that reduces Agility.

So, we need self-serve, we need automation that allows them not to be a bottleneck. We need to be able to get RVMs when we need RVMS, etc. And we need mechanisms in place that get rid of all the overheads to the delivery teams. And I say delivery, not development. It’s everybody that’s needed. We need some mechanisms in place that get rid of the inhibitors to delivering working software as frequently as we need to, to get that inspection working for our business.

That’s what ultimately we need to do and sometimes DevOps—it’s a great movement. Sometimes, it gets in the way because we go, “Oh, wow now I’m DevOps, not Scrum.” And I don’t give a diddly if you’re Scrum or DevOps. All I care about is delivering frequently to learn so that I can improve and deliver value faster to our customers.

Shimel: Got it. Well, Dave. I hate to do this to you, but we’ve run over schedule here. But it happens. I told you before we got on, that it goes quick. We’re well past it at this point. But, one last question that I like to always ask guests, and that is: Can you recommend one book to our audience that they should read?

West: Yeah, Alan, I don’t know if I can recommend a book to read, but I can tell you the book I’m currently reading.

Shimel: Fair enough.

West: And it’s interesting because there’s lots of great books, obviously. A wise man once said to me, “I don’t mind if you read my books, as long as you buy them.” So there’s lots of great books, but I like the book I’m reading at the moment. It’s called, “Turn the Ship Around.” And it’s a really interesting—it’s a true story of this—basically, this guy that’s running this nuclear submarine by this gentleman called David Marquet. And it’s really very interesting because a nuclear submarine you would think has got as much in common with a software delivery project as—I don’t know—as something that doesn’t have much in common with something else.

But ultimately, you learn a lot about how you can get autonomy, get self-direction in your teams, how you can keep people happy when you’re in this, sort of, steel coffin under the water when you’re not talking to your loved ones for thousands of hours because you’ve got nuclear weapons on, and you have to be hidden somewhere in the Atlantic or Pacific. And it’s a very interesting book and I’m about halfway through, so I can’t tell you if it’s the best book in the world but I can tell you the first half has started very, very well. “Turn the Ship Around.”

Shimel: Got it. Sounds like a good and I will see if we get any feedback from the audience.

Well, Dave, so we totally blew through this, but it’s okay. It was a great interview and I hope people enjoyed listening to you continue success with Scrum.org and maybe we could have you back on at some point; we could continue this discussion.

West: I’d love to Alan. Love to. It’s been an absolute pleasure.

Shimel: Okay. Dave West, product owner, CEO of Scrum.org, thanks for being this episode’s guest of devopsy.kinsta.cloud

This is Alan Shimel for devopsy.kinsta.cloud.

August 3, 2016
DevOps Chat: Steve Hazel, Sauce Labs

I recently had the chance to sit down and speak with Steve Hazel, CTO and co-founder of Sauce Labs. With so much being written and talked about the role of quality assurance (QA) and testing in a continuous integration/continuous delivery (CI/CD) world, it is good to hear from someone like Steve who is an actual thought leader in the space. Steve tells us what he thinks the limits of automated testing are, the future of QA and more. Have a listen for yourself to find out, or follow along with the printed transcript below!

Alan Shimel: Hi, everyone. Alan Shimel, devopsy.kinsta.cloud here, for another DevOps Chat. Today’s DevOps Chat’s guest—that was a tough one—is Steven Hazel, co-founder, CTO at Sauce Labs. Steven, welcome to DevOps chat.

Steve Hazel: Hi, Alan. Glad to be here.

Shimel: Thank you. Glad to have you here, actually. So Steven, there might be some people listening who maybe aren’t familiar with Sauce Labs. So, before we start, why don’t we, if you don’t mind, give our listeners a quick overview? Tell us about Sauce Labs.

Hazel: Yes. At Sauce Labs, we do automated testing for both web and mobile apps. We run a cloud service that gives our customers access to a wide range of platforms, whether that’s operating systems and browsers for web testing, or mobile devices and emulators and simulators for mobile testing. You can get access to all the different platforms you need to test on, and you can get access to a lot of platforms at once to run your tests in parallel to get through a large test suite rapidly, which is really what people need for today’s continuous integration and continuous delivery workflows.

Shimel: Got it. Of course, Steven, Sauce Labs was closely linked with around Selenium and some of the open-source testing tools that are out there today, right?

Hazel: That’s right. Selenium is the dominant web-testing technology. In mobile testing, there’s a variety of technologies, but we support Appium, which also uses the web driver protocol that underlies Selenium. We really think that fitting in with those open-source tools is the smart way to go. It fits with what people are doing.

It gives people a lot of choices about how they want to do their testing, what kind of languages and frameworks they want to use on their end. So, we just plug right into Selenium tests, if you’ve already got Selenium tests, or Appium tests. You can just change the config and point them at Sauce Labs, and they’ll run unmodified on our systems.

Shimel: Got it. Steven, we were talking before we started recording today, I was telling you about a recent article we had over on devopsy.kinsta.cloud. The gist of it was basically that DevOps was the death knell for QA. I told you I didn’t agree with that and you agreed with me. You said you didn’t agree with it, either. But for our audience—they’ll respect you a lot more than they respect me—why don’t you agree with that, Steven?

Hazel: Yeah. I think that to suggest that there’s no longer a role for manual QA when you take on a DevOps process is just not in line with the facts. If you look at what we see large organizations doing, they’re not dropping manual QA for automation. They’re changing the mixture of what they have manual testers doing by quite a lot, but they still have manual testing teams. You still need a manual testing team.

So, what I see happening, as you start to take on automation, your testing coverage improves dramatically because you can afford to do a lot more testing when you’re automating than was ever possible with a manual testing team. But automated testing, the classic example is exploratory testing. You’re just not gonna get the kind of creative, exploratory walk-through of your app with an automated test that a manual tester can do. I think there’s still a role for QA organizations, beyond just manual testing, in being the other side of the conversation, right?

A lot of people have the concern that if developers are writing tests, it’s the inmates running the asylum. The exact developers writing the software are the ones deciding whether it’s high quality, and you want another perspective in there. You want a perspective that’s maybe closer to your end user. So, I think that the other side, beyond just manual testing, that you see with QA teams continuing to have a role is in deciding what cases should be tested, whether you have good test coverage, encouraging good testing practices, even when you are automating your tests.

Shimel: Absolutely. Really, Steven, I guess the boogeyman in the room around the friction with DevOps and QA is automation. There’s some schools of thought that says, “Well, we can automate everything. The more we automate, the better we are.” There’s another school of thought that says, “Well, you can automate as much as you can and automation’s not a bad thing, but there are just gonna be some things that are not automatable, if that’s a word now, or may never be automated. Where do you go in on that continuum?

Hazel: Well, being someone who’s pushing forward automated testing, I want to see automation go as far as we possibly can. I think that that’s very far. That said, I think that the way the mixture of tests changes as you adopt automation is maybe a little bit counterintuitive. You might imagine, well, we’ll automate some percentage of our manual test cases, maybe 80 percent or 90 percent. Maybe we could get to 100 percent if you’re a zealot for automation.

But actually, what you see is, it’s not that you’re automating a percentage of what was there in manual testing. You’ll actually have more automated test cases than you were able to do with manual testing. So, if you just looked at the number of test cases, your automated cases are gonna way outnumber the original count of manual test cases just because you can, right? You can now cover a lot more edge cases, a lot more scenarios because of the power of test automation. So, that’s a real advantage to test automation.

Shimel: Sure.

Hazel: At the same time, certainly there are things, visual testing, there’s some interesting approaches out there, but I don’t think we’ve yet seen a way of making sure that the app looks right, especially as it changes. You really need a human being involved when there are deliberate visual changes to make sure that they came out right. I think it’s those things where automation really can’t give you an answer about, does it look right? Does it act in a way that’s gonna be acceptable to somebody?

I think you still need a human being in there at some point, checking those things, but it’s a different process. It’s no longer this phase gate before every change is released that you used to have. It’s now a process that can be made asynchronous from the bulk of your development and release process.

Shimel: Absolutely. If you don’t mind, Steven, a little bit of time on, you mentioned a little bit, but what do you think of the kinds of tests that lend themselves well to automation? Certainly, a visual test of an interface, different arts. What are the sweet spots for automated testing?

Hazel: I think certainly at the bottom of the testing pyramid, unit testing brings tremendous value. It’s something that’s very easy to automate in a way that’s completely deterministic, very fast. Gives you really quick feedback as a developer as you’re making changes to the code on whether you’ve broken something. But the coverage with unit testing, the coverage of functionality that may be important to your end users, it’s really hard to achieve. It’s really hard to achieve good, solid feedback from your unit tests that you haven’t broken anything anywhere.

Functional testing, the next layer up, which is what really we focus on, gives you that complete end-to-end check. You’re actually testing the features of your product and you’re making sure that end to end, with all the various components involved, they work properly. That’s more of a challenge for automation, but we’re seeing, I think, a majority of development organizations out there seeing success automating functional tests and real value from having that be something where you can run through hundreds of test cases in minutes and get feedback to your team. So, that works quite well for automation.

I think it’s that next level up, as you start to get into the types of tests where you’re looking at, what’s an acceptable experience for the end user? User acceptance testing as distinguished from functional testing, where you’re really starting to look for, does it look right? Does it act right? Is the response time throughout the entire process acceptable?

You can zoom in and measure a lot of these things very specifically, but getting the answer to, “Overall, though, was it a good experience?” That’s the kind of thing where it’s really tough to cover that with automation.

Shimel: Yeah, agreed. Steven, if you don’t mind, I’m an old security guy prior to DevOps. One of the things within the security community that we’ve really pushed around is the idea of automated security testing shifting left in a DevOps environment and allowing security testing to be done in an automated fashion at a CI/CD-type of level. Where do you see that in this whole discussion?

Hazel: Security testing isn’t what we focus on at Sauce Labs, so –

Shimel: Right, I know.

Hazel: I’m not an expert in this, but it is something that I follow and care a lot about. I think I see a lot going on with static analysis, with some of these tools that can help to constrain the types of mistakes that you could have in a program, type systems and things along those lines. I think really that’s very badly needed in making code secure. Some of the issues we’ve seen come up over the last few years, things like Heartbleed, the Glibc bug, really those kinds of things aren’t acceptable, aren’t something that we can continue to have happen, and I think the solution really is fully automated tools, like static analysis tools and type systems, that can lock down the code and just constrain the types of mistakes that could possibly happen.

Shimel: Sure. You know, Steven, I see it as very analogous to the QA situation, which is I think a lot of security people get very territorial around job security because they’re afraid somehow that doing automated security testing earlier in the process—shifting left, so to speak—is somehow gonna affect their livelihoods, or make them obsolete.

Hazel: I can see that. We see that among QA folks, for sure. To me, that’s a shortsighted view. If the world is getting more intense security problems, more intense quality problems, we’re shipping more software, you just can’t solve it 100 percent by throwing bodies at the problem. I think that what’s gonna happen is not that those people’s careers are in jeopardy; instead, as a society, we’re just gonna do more and better security and quality testing than we’ve been able to do in the past.

Shimel: Yeah, agreed. Steven, we’re running a little low on time, so let me get just one or two more questions. Sauce Labs has been, in my opinion anyway, for what it’s worth, somewhat of a DevOps darling in terms of really encompassing—you’re living the DevOps model. You’re working with open-source tools, testing and automation, enabling automation. Sauce Labs is a player in the DevOps ecosystem. Where do you see it going?

Hazel: Well, toward the enterprise is one big trend we’re seeing. Earlier on in the history of Sauce Labs, a lot of our customers were essentially software companies, companies that their primary focus is technology. Now, a lot of our customers are retailers, financial institutions—companies that you don’t think of as primarily a software company, but all of these companies have apps, they have complex web experiences. They’re really adopting DevOps in a big way. They’re moving to what is, for them, a very different process than what they’ve been doing and allows them to ship better software faster, with more complexity than they were able to handle before.

Shimel: Absolutely. Steven, we are low on time. I’m gonna ask you the final question, which I ask most all of my guests here on DevOps Chats. That is, if you had to recommend one book to our audience that they should read, a must-read for them, over the next six months or a year, what would that book be?

Hazel: Oh, wow. A book recommendation. I think the obvious choice in a conversation about DevOps is “The Phoenix Project.” If you haven’t read it, you’ve got to read it. It’s a quick, enjoyable read, but it really gets the concept across better than probably anything else is going to. It’s an obvious recommendation, but I still think it’s worth it.

Shimel: Sometimes the obvious is good. I will just add to that, if you already have read “The Phoenix Project,” Gene Kim’s next book, I think co-written with John Willis and Jez Humble and someone else that I’m blanking on – oh, darn it, the guy who started DevOps, who coined the phrase. Patrick. Patrick Debois. Their new book, I think it’s called “The DevOps Handbook,” will be out, I want to say, in the fall. Not a sequel to “The Phoenix Project,” but another good book to look at.

Anyway, Steven Hazel, CTO, co-founder of Sauce Labs, thanks for being this episode’s guest on DevOps Chat, and continued success with Sauce Labs.

Hazel: Thanks a bunch. Thanks for having me.

July 25, 2016
DevOps Chat: GitHub Enterprise as a Hosted Service, with Jean-Louis Vignaud

I recently sat down with Jean-Louis Vignaud, program manager at IBM, about the new GitHub Enterprise as a hosted service that recently was rolled out on Bluemix. The GitHub Enterprise as a hosted service is a great option for enterprises that, due to compliance or other security requirements, cannot used a shared, public GitHub service.

This GitHub Enterprise as a hosted service is the first of its type available and is hosted on the Bluemix service as both on-premises and hybrid environments. You can get more info on this at:

1. Blog : Introducing the first-ever GitHub Enterprise as a hosted service

2. Video : Benefits of GitHub Enterprise with IBM Bluemix Dedicated

3. SlideShare: IBM Bluemix Dedicated – GitHub Enterprise

Also, we will have a webinar that goes into greater detail on this. More info is at: http://webinars.devopsy.kinsta.cloud/scaling-devops-github/

In the meantime, here is the streaming audio file of this chat, followed below by the transcript of our conversation to follow along.

Alan Shimel: Hi, this is Alan Shimel, devopsy.kinsta.cloud, and I’m here with another DevOps Chat. Today’s guest on DevOps Chat is Jean-Louis Vignaud, Program Manager from IBM. Jean-Louis, I hope I didn’t mess up that name too bad.

Jean-Louis Vignaud: No, that’s fine. Thank you, Alan.

Shimel: Okay. Welcome to DevOps Chat, Jean-Louis, and as I mentioned, you are a Program Manager at IBM, and right now anyway, you’re very involved in working on the GitHub Enterprise as a hosted service offering, and we wanted to talk to you specifically about that.

Vignaud: Okay.

Shimel: So, Jean-Louis, I think everyone listening out here is familiar with Git and GitHub, but they may not be familiar with the concept of GitHub Enterprise as a service, so why don’t we start there, if you can explain to our audience a little bit about what that is.

Vignaud: Okay, so maybe we can start with GitHub first.

Shimel: Okay.

Vignaud: GitHub is very well-known, it has probably 15,000,000 users as of today, it’s a very well-known user experience. It’s a collaboration platform, and it’s based on Git, so it’s running on top of Git, but it has many other services on top of Git. And the purpose of GitHub is to provide this collaboration platform that enables people from all around the world to collaborate on a business project, or even a private project.

And that very well-known collaboration platform is very attractive for enterprises that want to provide the same level of collaboration within their own organization. And so what was introduced by GitHub the end of 2011, early 2012 was GitHub Enterprise. GitHub Enterprise is an on-premises version of GitHub. So, same set of capabilities, but you can install it when it’s on-premises in your—on-premises in your environment, and get it working within your firewall. So that enables teams to—you know, to enable organizations and different teams to collaborate among each other in a safe way.

So that’s the background, and where we were standing before we introduced our offering.

Shimel: Mm-hmm, and [Cross talk]—I’m sorry. I didn’t mean to interrupt.

Vignaud: Yeah, so what I was going to say is that, as usual, inside an organization, as soon as you have to install your product, you have to run it, you have to manage it, you have to provision your infrastructure, you have to have the people set up and standing to manage the GitHub Enterprise offering, meaning doing the backup, doing the upgrade, monitoring its running and doing everything that needs to be done in order to comply with the enterprise security requirements.

And that requires time, and most of an inside organization, you know, people are looking to move to the cloud, benefit of the cloud facilities, which they could find in GitHub today, but it’s a public cloud that does not meet the security requirements of an organization, and they would want the same GitHub experience, but within their organization. And this is where we come with our service offering around GitHub Enterprise—providing the user experience of GitHub within the organization while still managed by IBM.

Shimel: Got it. And just to make clear, Jean-Louis, as far as I know, IBM is the only one actually offering this GitHub Enterprise as a hosted service, correct?

Vignaud: Yes, this is a first-of-its-kind offering. I know if you look into what GitHub provides, GitHub provides GitHub Enterprise so you can run it on premise. You also can install it on infrastructure as a service, so you can run it inside AWS, you can run it inside Azure, but there was no one providing a service offering around GitHub Enterprise. So, with IBM, it’s hosted and managed by IBM so the “and managed” is unique.

Shimel: Got it. And another thing I just want to emphasize, because as we were speaking about before we started today’s broadcast was, you know, this is in partnership with Git, right?

Vignaud: Yes, that’s a partnership with GitHub, yes. We announced the partnership at InterConnect early this year in February, and so since the announcement, we have been working and creating this offering. So it took us 12 months to build it and to release it.

Shimel: Understood. And I think that’s important, because you know, it’s one thing to just take some open-source project and offer it as a hosted service, right? Anyone could do that, it’s open source.

Vignaud: Yes.

Shimel: But to really have the cooperation with Git behind this really gives, I think, the best chance for enterprises to have their own Git environment really, truly as a hosted service.

Jean-Louis, I wanted to talk about another aspect of this offering, and that is, as it’s part of an Integrated Bluemix Dedicated offering as well, right?

Vignaud: Yes.

Shimel: So let’s start off with, what is Bluemix Dedicated?

Vignaud: Okay, so IBM platform-as-a-service offering is Bluemix. So, Bluemix, it consists of a huge set of services, for mobile application, for cognitive applications, so about more than 150 APIs organizations can use to build a cloud-native application, to integrate these applications with a back-end system. And so Bluemix is available in the public cloud, but as well, it’s available as a single-tenant dedicated cloud for the customer.

So that’s Bluemix Dedicated. So, meaning, it’s a Bluemix for our customer with all this API, all these platforms that enable you to build and run your application. It’s based on Cloud Foundry, it supports containers, Dockers and so on. So it provides a very extensive set of technology that enables organizations to quickly build applications.

As part of Bluemix, there are a set of DevOps services, so tools we provide to help organizations build those Bluemix applications. And this is where our GitHub Enterprise offering sits. It’s a DevOps offering, part of Bluemix Dedicated.

Shimel: Got it. So, Jean-Louis, this is—I mean, unfortunately, we only have 12 to 15 minutes here, but there’s a lot of layers that we can peel back it of what one can do with this GitHub Enterprise offering, you know? And especially, in my mind—look, if you’re developing applications and you just want to have your whole platform as a service with best-of-breed stuff such as a Git, such as a Cloud Foundry, all of these elements that give you a best-of-breed application development in platform as a service forum, it seems that all the pieces are here to come together. And it’s a great time to be alive. It’s a great time to have to—you know, if you wanna develop applications, to have that at your fingertips.

Vignaud: Yes, and in the context of Bluemix Dedicated, single-tenant, completely integrated with your enterprise network, so it enables you to safely integrate with your back-end system. So you really have a very advanced platform enabling you to develop in a safe way; you know, very innovative applications.

Shimel: Yeah. So, Jean-Louis, two questions for you. No. 1, in terms of advantages of using the GitHub Enterprise hosted versus the public Git, that GitHub that so many of us, I think 50 million is the number of people use—the obvious advantage is, this is a more secure environment, it’s yours only. But are there any downsides? Is there any kind of features not available in the hosted service that would be available in the public service?

Vignaud: No, not really. You know, the GitHub Enterprise has been designed to provide the same user experience as GitHub. I would say that the value of GitHub Enterprise, it’s the user experience of GitHub, but you can run it for you, so it’s a single-tenant for you as a customer, leveraging the cloud infrastructure from IBM, you can run it in a data center where you want to, geographically you can localize it in the country where you belong. So if you have compliance requirements requiring you to host your source code in-country, you can do that.

So, I would say, no limitation and much more flexibility when it comes to the deployment of the offering.

Shimel: Excellent. Next question, I just wanna make sure—is this publicly available today? Because I remember—

Vignaud: It is, yes. It is available today. We announced it on the 17th of June. We officially announced it on the 17th of June, so yes, it is available today, and any Bluemix Dedicated customers can use it as part of the offering.

Shimel: Oh, excellent. And I should also mention, Jean-Louis, that in the near future, actually—I think we’re finalizing scheduling right now—we’re actually gonna do a full webinar with GitHub and IBM, where we’re gonna explore a little deeper into this offering and for those of you listening who may be interested, I strongly, strongly encourage you to attend that webinar.

But Jean-Louis, if people don’t want to wait for the webinar, I know IBM has put up several content pieces where people can get more information from this. One is a blog introducing the GitHub Enterprises service, there’s a video that shows the benefits, and I think there’s also something up on SlideShare about IBM Bluemix Dedicated and GitHub Enterprise. I will try to—

Vignaud: Yes.

Shimel: — yes, I will try to include the links to those when we publish this chat, but again, I strongly—if you have questions about his, if you’re a Git user and thinking you’d like your own GitHub Enterprise dedicated service, I’ll try to put those in there.

You know what, Jean-Louis, unfortunately we’re just about out of time. Is there anything you want to add?

Vignaud: I think this is fine. Thank you very much, Alan, for the interview here.

Shimel: Thank you.

Vignaud: I really look forward to have many customers for this offering.

Shimel: You know, I think it’s something the market needs. It’s good to have that. As I said, it’s a great time to be a developer today, right? So many tools, so easy to use.

Vignaud: Yes.

Shimel: Anyway, Jean-Louis Vignaud, Program Manager at IBM, thanks so much for joining us today, and we look forward to hearing more about GitHub Enterprise as a service.

This is Alan for devopsy.kinsta.cloud. Thank you for listening in, and we’ll see you on the next DevOps Chat.

Vignaud: Thank you.

July 21, 2016