Author: Alan Shimel

DevOps Dozen Finals Voting is Open!

Sometimes, good things are worth waiting for. I am happy to say that the voting for the DevOps Dozen finals is now open! There are 12 Categories with up to 12 finalists in each category. All of the finalists came from nominations by you our audience. In fact that is why it took so long for us to come up with the finalist list. There were over 1000 nominations and due to our own fault, we had to tabulate by hand. As a result we will keep voting open until November 18th.

We will publish all of the finalists in a subsequent article, but the are all available on the voting site. Congrats to all of the finalists! In many of these categories, it is going to be very hard to choose who to vote for.

You can only vote for one finalist in each category.

Here are the categories:

Best DevOps Open Source Project	Best DevOps Commercial Solution
Best DevOps Company Executive	Most Effective DevOps Solution Provider
Most Innovative DevOps Solution of the Year	Top DevOps Evangelist
Successful DevOps Transformation	DevOps Transformation Executive of the Year
Best New DevOps Solutions Company	Best DevOps Book/eBook
Best DevOps Presentation of the Year	Best devopsy.kinsta.cloud Article of the Year

Please only one vote per person and we will be enforcing this on the backend. Any questions please contact us at devopsdozen@devops.com. If any of the finalists would like a badge to send people to vote please again contact us at devopsdozen@devops.com

Lets hope we have less controversy and rancor than in our US Presidential elections and good luck to all of the finalists!

— Alan Shimel

October 31, 2016

Docker On Windows, Are You Serious? Microsoft’s Hands-on Lab Show’s You How

You have probably heard or read about the availability of Docker on Windows and Azure. Both Docker and Microsoft have turned up the noise on their collaboration. But have you really looked into what these two are up to? If not, now is your chance. Microsoft has put up a great free hands on lab all about Docker, containers and Windows.

In this hands on lab there are modules that feature Docker on Windows Server, Windows Nano Server and managing them with Windows 10. You can use Microsoft’s HyperV or not. It really is a great way to learn about containers, Docker and the Windows platform. You can play with this hands on lab by clicking here or if you prefer to cut and paste here is the link: http://msftdevops.learnondemandsystems.com/?wt.mc_id=AID557152_QSG_BLOG_22879. (Editors note: pop up blockers may stop the lab from loading. If you have an issue try disabling the pop up blocker.)

Here is what the lab covers in a bit more detail:

I took the opportunity to play with the lab myself. While I am far from a developer or even an Ops person, I have to say Microsoft got this one right. Even I could complete it! The lab is supposed to take you 30 minutes but they give you 8 hours to complete. There is a great set of introduction videos that give you a full picture of what you are going to be doing. Here is an example in a still shot:

The lab is actually broken down into several modules that don’t have to be completed in one sitting. The lab requires no set up on your part at all. It runs right in your browser. The lab has you run two different Windows machines, one Win10 and one Windows Server. You can switch and log in right from the browser. The lab also has you log into PowerShell:

It literally gives you the CLI commands that you have to type, tells you when to switch between machines and guides you step by step through each of the several tasks. There is a great info bar on the bottom that has context sensitive instructions that walk you through the entire thing. There is also a sidebar which gives you a great oversight of the entire lab, where you are in the process and options to move around. All in all I thought they did a great job with the UX to make what could be a complex set of tasks easy.

The whole Docker and containers on Windows theme is one has been bubbling up for some time now. While many doubted that it could ever happen, the new Microsoft seems to have made Docker right at home.

From what I have been told there will be similar hands on labs offered for free on the Azure platform and more on containers. We will be working with Microsoft to dig in deeper here, so stay tuned for more soon!

— Alan Shimel

October 31, 2016
Sanjay Mirchandani Builds Out Puppet While Keeping Culture Intact

I attended my first PupetConf last week in San Diego. While there I had a chance to sit down one on one with Sanjay Mirchandani who recently took over as CEO/President of Puppet from long time CEO and founder, Luke Kanies, who is now a member of the BOD. As this was my first meeting with Mirchandani, it was good to understand what he sees his mission is at Puppet and how he views the market and Puppet’s place in it.

I would say first of all that Sanjay understands what has made Puppet successful to this point. Luke and the team have built a tremendous culture around Puppet. With over 34,000 users, 75% of the Fortune 100 and a world-wide base, Puppet has the community and market perception of a winner. Sanjay sees his job to build a truly world-class organization on top of this great foundation. The difficult part is to not mess with this great foundation while building that world-class organization.

Sanjay has already started this building process. Over the last few months he has brought on board several senior level people flesh out the executive team. Some of these new Puppet executives are:

Mike Guerchon, Chief People Officer. Mike joins Puppet from Riverbed and while he is adamant about not being HR, he will lead Puppets HR department. Part and parcel of that is to preside over what will probably be a huge uptick in new Puppet employees all over the world.

Gary Green, SVP Sales. Gary was a long time VMware executive who was instrumental in building out the successful sales team over there. Sanjay is very excited about what Steve brings to the Puppet team. With Sanjay’s plans to expand Puppets offerings (more about that below) Gary will be key to taking Puppet to the next level.

Simon Hayes, Business & Corporate Development. To be fair Simon joined this past February, so not really a Sanjay appointment, but still a fairly new exec team member. Simon comes from Citrix and Sanjay says brings some big company biz and corp dev experience to the team. Could it portend some M&A activity going forward? Perhaps, we will have to see.

Scott Campbell, SVP of Go-To-Market Initiatives. Scott is another new add to the exec team. He was most recently at Jive Software and at Tripwire before that. His background is in sales. I asked Sanjay if he was a “farmer” to Gary’s “hunter”, but Sanjay says no. Scott’s role is to make sure Puppet customers are getting the most out of their products, as well as understanding what their needs and future needs are.

Besides the four highlighted above, the Puppet exec team is well filled out now. Sanjay should have the lieutenants needed to carry out his plans.

So what exactly are his plans? Well as I said before first and foremost is to not rattle the apple cart and mess with Puppets enviable culture and the fanatical support of its customers and users. At the same time converting more of those 34,000 users into paying customers is certainly a major priority. They currently have about 1200 paying customers. Quick back of the napkin math says about 3% of users are paying customers. In my experience that is about right for an open source tool. Somewhere between 2-4% convert to paying customers. The trick that successful open source vendors figure out is how to get that number higher. That is what Sanjay and team are working on.

One idea that Sanjay and I discussed was adding services to the mix. It is a common practice in commercial open source companies. At this time Puppet isn’t ready to announce something. But I would not be surprised to see either Puppet itself offer services or an aggressive move to grow a channel of service providers who work closely with Puppet.

Of course growing the user base beyond the 34, 000 current users is in mix. One strategy on that is Project Blueshift. I think of it as future proofing Puppet. But as you will find in an upcoming article from my conversation with Gareth Rushgrove, Blueshift is about making sure that Puppet’s core functionality of configuration management extends horizontally across all of the different platforms that the market is using. Right now Docker and containers are a major focus of this.

Beyond my meeting with Sanjay, PuppetConf was a great trip for me. I enjoyed meeting many new faces, catching up with many folks I knew already and most of all, seeing the Puppet culture up close. Sanjay Mirchandani has an exciting opportunity in front of him, but he seems to have a very capable team to work with and a great foundation to build on. Looking forward to next years PuppetConf (back in San Francisco) to see how it plays out.

— Alan Shimel

October 31, 2016
DevOps Transformations Everywhere; Join Us To Watch, Hear & Learn

For me and many others the best way we learn about DevOps is to hear others who have set about on this journey. For three years Gene Kim’s DevOps Enterprise Summit has been powered by hearing one DevOps Transformation experience after the next. The new DevOps Handbook has over 40 case studies of DevOps transformations. We here at devopsy.kinsta.cloud will be offering some great DevOps transformation stories this month that I wanted to share with you.

First of all Monday afternoon (2pm eastern time) we will be having a webinar, “Leading Change at DevOps Enterprise Summit San Francisco“. You can register by clicking the title or clicking here. The webinar will discuss leading DevOps transformation and features a pretty impressive cast:

Dr. Nicole Forsgren

CEO and Chief Scientist, DevOps Research and Assessment LLC

Dr. Nicole Forsgren is an IT impacts expert who shows leaders and tech professionals how to unlock the potential of technology change in their organizations.

Sam Guckenheimer

Product Planner, Microsoft

Sam Guckenheimer is the Product Owner for the Microsoft Visual Studio Cloud Services, including VS Team Services and Team Foundation Server.

Scott Prugh

Chief Architect & VP Software Development, CSG International

Scott Prugh is chief architect and vice president of software at CSG International and has been with the company for 10 years.

J. Paul Reed

Managing Partner, Release Engineering Approaches

J. Paul Reed has over fifteen years’ experience in the trenches as a build/release engineer, working with such storied companies as VMware, Mozilla, Postbox, Symantec, and Salesforce.

Next week devopsy.kinsta.cloud will be out at the DevOps Enterprise Summit, where we will once again have a video booth and will be interviewing most of the speakers at DOES, as well as many guests and friends from the DevOps scene. If you are attending and would like to sit for a video interview stop by during Monday or Wednesday of the show.

Our videos should be up in a few days afterwards, so if you can’t make it to San Francisco be sure to catch our interviews of the speakers and others.

Later this month we have another webinar that I am really excited about. It is again about DevOps transformation experiences. It features:

John LaFreniere is the Vice President of Global IT Architecture for the Hertz Corporation.

Raghunath Raman, Director, Digital Shared Services, API Delivery & Integrations, Corporate Services & Digital Technologies (CSDT), Kaiser Permanente

Sanjeev Sharma, is an internationally known DevOps, and Cloud Transformation thought leader, technology executive, and published author. Sanjeev’s industry experience includes tenures as CTO and Worldwide Technical Sales Leader, Acquisition Integration Technical Leader, and IT Architect. As an IBM Distinguished Engineer, Sanjeev is recognized at the highest levels of IBM’s exclusive core of technical leaders.

You can register for this webinar here.

Beyond these there is IBM InterConnect on the horizon, CA World, where I will be speaking as well, also in November and our own DevOps Connect: CD Summits this month and next in Austin, LA and Seattle.

So yes indeed DevOps Transformations are everywhere. There is much to be learned from hearing these stories. Sometimes more from the mistakes they made then from the success. Check these out if like me you are interested in these tales from the front lines.

— Alan Shimel

October 30, 2016
DevOps Chat: DevOps & CD with Tim Butel, XebiaLabs

devopsy.kinsta.cloud caught up with Tim Butel, VP of Products at XebiaLabs. Tim discussed some of the latest trends in DevOps & continuous delivery (CD) with us. He also gave us a great update on what XebiaLabs has been up to recently and why organizations including Gartner and others consider XebiaLabs a leader in the category.

Tim also gave us some great insight into how he has progressed in his own career. How can someone listening to this try to set out on a similar career path? Tim’s journey may prove helpful to you.

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

Alan Shimel: Hey, everyone, Alan Shimel, devopsy.kinsta.cloud here, for another DevOps Chat. Today’s DevOps Chat’s guest is Tim Buntel, VP of products at XebiaLabs. Tim, welcome.

Tim Buntel: Thanks so much, Alan. It’s a pleasure to be joining you today.

Shimel: Yep. Well, no, it’s our pleasure to have you here. So, Tim, I know you’re fairly new, though not really new new to Xebia, but how long have you been on board there now?

Buntel: Yeah, so it’s coming up on about six months now, so long enough to have had a couple releases and seen where we’re going as an organization and start to chip in, but can’t take too much credit for all the success of the company yet.

Shimel: No. Okay, fair enough. And then, Tim, VP of Product. So you’re—give our listeners what exactly does that entail in terms of your responsibilities.

Buntel: Yeah certainly. So, you know, my team brings together product management, user experience, and all of the folks who are basically bridging the needs of the market to the rest of the organization. So we’re looking strategically at where we want to invest in new features in the products, we’re bringing requirements back to the engineering team, we’re designing the solutions for the features, and then we help bring that back out to the market. So interacting with the analysts and press, interacting, you know, in the support capacity to sales and that sort of thing. So really being that conduit between the market and the customer’s needs and all of the activities that are happening in the organization.

Shimel: Great. And Tim, you know, we might have some people out there who are a little younger, starting out in their careers, and they hear, wow, this guy is VP of Product at a company like Xebia. Can you give you listeners, give us a little bit of background, so what sort of qualifications, what experience did you bring to this position that kind of, you know, makes you able to succeed at it?

Buntel: Hmm. Yeah, I mean, product is a great role for folks who really want to help be the advocate for their customers. So in my case, my whole career has been in Dev tools and building businesses that create product that other software engineering companies, you know, sell and use. So I ran the developer tools business at Atlassian, I’ve worked for Microsoft and Adobe, I’ve done a couple of startups that are in the Dev tools space myself.

But the most important thing was originally I came from a development background myself. So as a developer, I was able to understand the challenges that development organizations faced. So often when I talk to professionals who are in this space, you know, maybe you are a DevOps engineer or you’re a software professional and you like solving problems, and you have a keen sort of interest in the people, right? So talking to people, understanding what their problems are, and then being able to creatively come up with solutions to those problems, that you can turn into a product so that you’re not only solving one person’s problem, but you can turn it into a product that solves that problem at scale for a market. Those are really the qualities that are most important for the job. So understanding the space and the domain—understanding, you know, in my case, what it means to build software—and then wanting to work with other creative people to find solutions to those problems, that can translate into a road map of features in your product portfolio.

Shimel: Excellent, excellent answer, and I hope our listeners or anyone who might be interested in that topic takes that to heart, Tim. I think there was some great advice and lesson there. So let’s turn a little bit, Tim, though, and talk about Xebia, right, and to kind of lay the groundwork, to you, what is XebiaLabs really all about? What is the secret sauce of XebiaLabs, if you will?

Buntel: [Laughs] Yeah. I mean, I think for me, the most important thing about us is that we’re really focused 100 percent on continuous delivery. We’re an independent company and that’s all we do. So every day we wake up and we figure how can we help other software organizations, generally they’re enterprise IT teams, how can we help them deliver better software faster, with less risk, right? So we combine many years of experience in that area. We were looking at deployment automation, as much as seven years ago now, I guess, so really before the term DevOps was even broadly adopted, we were solving these problems for large enterprises. And to this day, we continue to do that. So we are able to solve really large-scale enterprise problems because it’s 100 percent of our focus.

Shimel: Excellent. And so that being said, Tim, now that we know sort of what Xebia is about, I guess fair to say what attracted you to this position? You have a long resume of success with some very, very successful companies, obviously. What was it about Xebia that said, man, this is where I want to be?

Buntel: Yeah. Well, it’s really the culmination of a lot of the pieces that I’ve been working on in my whole career. So if you look at a software engineering organization today, many of the products that I’ve worked on constitute elements of that technology landscape that they have, right? So everything from issue tracking systems and collaboration tools at the beginning, through source code control and build tools and deployment tools, all the way to the end, to monitoring and user feedback, right? This is a great assortment of individual products, but it also results in a fairly chaotic landscape. So if you’re an organization trying to apply all of that at scale, keeping track and orchestrating all of that together has consistently been a challenge, right?

So for me, this opportunity to step in and say, okay, the next really important challenge in doing continuous delivery at scale is to orchestrate all of those pieces, and that’s what we’re really focused on at XebiaLabs right now. So XL Release, for example, is release orchestration automation tool that does just that. So we can help organizations automate and manage that process for even the most complex pipelines, and for me, that was a great next step, right? So I had worked on some of these individual pieces that were solving very specific parts of a development team’s challenge, and now I’m able to step back and offer a solution that helps sit above all of that and really make all of those pieces fit together. It’s like a conductor in a symphony, you know, being able to get the most out of each individual musician. That’s kind of what we’re doing for all of these other great parts of the continuous delivery pipeline.

Shimel: Excellent, excellent, excellent. So, Tim, why don’t we—we’ll continue on the Xebia topic here for a while. What’s new? What’s new, what’s exciting coming out of Xebia these days?

Buntel: Yeah, there’s some great work that we’re doing. You know, we continue to get great recognition from the analysts and press, we’re getting some great coverage from Gardner and Forrester recently, which is really exciting for us. And what we continue to hear both from them and from our customers themselves is that because we’re focused entirely on the continuous delivery piece, we’re able to offer some insight into our users in a way that, you know, individual point solutions aren’t necessarily able to do that. So a large emphasis for us is on this kind of reporting and insight, being able to analyze the performance of your continuous delivery process and kind of your DevOps organization. That could be through reporting, it could be through analytics, helping organizations find out where bottlenecks might be in their process. So it’s not just managing things, but it’s helping guide you toward ways to improve the efficiency of your program, and even to help folks measure the ROI of that.

So lots of organizations are trying to adopt DevOps and continuous delivery, and in many cases, it’s difficult for them to know what’s the ROI of that. So a big emphasis on our tools lately is on that aspect. So helping you get insight into your continuous delivery process, and we’re doing that in a way that’s extensible and supports integrations with pretty much any technology that you’re likely to find in the enterprise DevOps stack.

So that’s one piece, the insight and analysis part. The other piece that I think is a real strength of ours, that’s very exciting for me, is the breadth of participants in the process that are successful with our products. So a lot of solutions that are out there helping organizations with continuous delivery are really focused on the most technical people in the process, right? So they’re very script-focused, they tend to be very technical, and really, in the enterprise, the people who are participating in continuous delivery or DevOps initiatives more broadly, they’re coming from a lot of different backgrounds. You might have, you know, less-technical business owners, you might have risk or compliance professionals, and a host of managers and other stakeholders besides the real technical teams.

And one approach that’s been really centered to our product development recently is to make sure that the products are approachable, they have a great user experience, they are easy to use, they’re easy to understand, regardless of the degree of technical expertise in the user, while at the same time still satisfying all the needs that the most technical parts of the team have. So you can fully automate and fully script all of our solutions. We’ve got full API access and CLI capabilities as well. But the spirit of DevOps as a social process as much as a technical process can only be successful when the products are appropriate for folks with a range of different experiences. So that’s another really key focus for us now.

Shimel: Yep. What about the bigger—Tim, what about the bigger DevOps market, and how Xebia is sort of playing in that. We’re starting to see, you know, DevOps Express, for instance, was announced two weeks ago at Jenkins. But, you know, I think that’s a symptom of a bigger—I don’t want to say disease, that’s the wrong word, but a symptom of a bigger thing, which is sort of interoperability, right? No one DevOps tool is gonna do all your DevOps for you, right? So what – you know, what do you think about that kind of trend, if you will?

Buntel: Sure, certainly. You know, in fact, I can point to something that XebiaLabs has been running for the last couple of years now, probably, that really illustrates that beautifully. That’s our periodic table of DevOps. I don’t know if your listeners are familiar with it, but you can find it on our site, and it’s a, you know, a play on the periodic table of the elements, that’s cataloguing all of the different technologies that are typically present in, you know, a DevOps or continuous delivery stack. Everything from ticketing systems through STMs and builds and provisioning tools and all that.

And it’s community-sourced, so folks vote on the technologies that they use and the things that are most important to them. And we have a new tool now that’s part of that, that allows you to define the pieces of technology that are part of your enterprise IT environment, and it’ll help display kind of what your DevOps environment might look like, based on the combination of all of those technologies. But my point there was that, yeah, exactly as you said, it’s such a cluttered landscape and it’s growing at such an explosive pace, right? There seems to be a new open-source technology that’s looking at a different piece of the puzzle that comes up almost weekly, right?

So the challenge that we see for professionals that are in this space, especially in the enterprise, where you might be managing the development initiatives across different geographic locations and teams who are trying to be empowered to select their own technology is how do you centralize that and manage that while still balancing the control that you need as an enterprise, with the autonomy that you want to give your individual development teams to pick and choose the technologies that are best for them. our approach for it in our product is to really focus on integrations. So we have, you know, both of our products really emphasize integrations first, so that we can build integrations as they come to all of these emerging technologies, as well as the established and even older technologies. Everything from mainframe to the most recent sort of container or container management systems, we’re able to integrate with because we’ve built our products in this loosely coupled integration-based way. So that’s certainly something to look for if you’re considering how to construct your own continuous delivery or DevOps, you know, sort of landscape. Make sure that the products put integration at the center of how they’re able to hook together.

Shimel: Got it. So, Tim, believe it or not, we—I told you we’d do this for 12 minutes, and we’re at 15.

[Laughter]

Shimel: It happens. Just one last question, and if you have an answer for it, fine, if not, it’s okay, but I usually always like to ask my guests if you had to recommend a book to our audience to read, a must read, what book would you recommend? It can’t be “The Phoenix Project,” by the way. We’ve already got that one, but go ahead.

Buntel: [Laughs] Yeah. Well, yeah, well, you know, on my desk right now I’ve got sort of the following on “The Phoenix Project,” right? We have the new “DevOps Handbook,” from Gene Kim and Jez Humble, and we’re getting a lot of interest from our customers in that book, and, you know, we talk to Gene a lot and he has some really great insight. So I’m pretty excited—I’m about halfway through that, and there’s some really terrific case studies and great, practical, you know, kind of illustrations of how this actually works in real world technology and organizations out there. So that’s a great one for me, the latest.

Shimel: Yeah, yeah. It’s interesting, a very different sort of focus than the first one. But anyway—

Buntel: I love that—I love that there’s a good focus on metrics in this one as well. That’s something that I’m personally really interested in, is, you know, this ROI of DevOps initiatives, and I think he’s got some great case studies in there that help measure that.

Shimel: Well, Gene is a metric nut.

Buntel: That’s right.

Shimel: So anyway, Tim, we’re at the end of time, really, we’ve got to wrap. Tim Buntel, VP product XebiaLabs. Thank you so much for being this episode’s guest on DevOps Chat. Hope to see you soon, and we’ll catch up again, all right?

Buntel: Thank you so much, Alan, and look forward to talking to you again sometime soon.

Shimel: Okay. This is Alan Shimel for devopsy.kinsta.cloud. See you on the next DevOps Chat.

— Alan Shimel

October 21, 2016
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
CD Summit/Jenkins Days with John Willis, KK & Mustafa Kapadia
Our fall lineup of DevOps Connect: CD Summit/Jenkins Days are coming on fast. We kick off this fall’s schedule of seven events in Atlanta on Oct. 4 and 6. The speakers and subjects are up on the site, but I wanted to highlight the three keynote speakers: Our three headliners for Atlanta are Mustafa Kapadia of IBM, Kohsuke Kawaguchi (KK), the founder of Jenkins and CTO of CloudBees and, finally, the one and only John Willis (@botchagalupe). Each one of these speakers would be a great listen by themselves, but getting all three in one morning should be great!

But wait, there’s more. In addition to Mustafa, KK and John, we have a full day of DevOps learning in store. The afternoon features three separate tracks with four or five sessions per track. On track is solely on Jenkins, one is DevOps in general and one is on automation and interoperability. Some of the other speakers include Ben Bomhoff from Security First Insurance and Daryl Bower from Accenture. Check out the website to get more information.

All of the above speakers are on the second day of the event, Oct. 6. The first day, Oct. 5, features several great workshops on Jenkins, Blue Mix and a DevOps Foundation workshop by the DevOps Institute.

You can check out the full line up of speakers, schedules and topics at the DevOps Connect website. The cost without workshops for the day conference is just $99 and includes lunch, refreshments and access. If you would like to attend the first day of workshops as well it is just another $99. If you are in the Atlanta area, this is a great day of DevOps!

If you are not in Atlanta, be sure to check out http://www.devopsconnect.com for the full schedule for the fall. Other cities we are visiting include:
- Amsterdam
- Berlin
- Denver
- Austin
- Seattle
- Los Angeles
If you are in any of these cities, please come spend a day or two with us. Also be sure to stay on the lookout for additional conferences we are planning including DevSecOps events at RSA and InfoSec World 2017.

— Alan Shimel
September 22, 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