devopsy.kinsta.cloud

Category: DevOps at IBM

  • DevZone and Bluemix Garage @ the IBM InterConnect Expo Floor

    DevZone and Bluemix Garage @ the IBM InterConnect Expo Floor

    Things have been so busy here at devopsy.kinsta.cloud, I have not really had a chance to report on what a great event IBM InterConnect 2017 was. Once again this year this year the IBM InterConnect expo floor showcased the latest developments in cognitive, cloud, DevOps, security and more. But this year there was definitely a vibe of DevOps, agile and cognitive are now firmly mainstream and not just the latest shiny objects.

    We have over 40 videos of interviews and updates from this years InterConnect over on our DevOps TV Youtube channel. Included in this playlist are some great interviews with Jeff Sussna, John Comas of NBCUniversal and more.  Check them out if you have some time.

    For this article though I wanted to give you a flavor for what it was like on the expo floor at InterConnect 2017. We took our video team mobile and toured several of the areas that the floor was broken into. Two of the most crowded was the Dev Zone, that featured development trends across many areas and the IBM Bluemix Garage which was expanded this year.

    Over at the Bluemix Garage area we had a special tour guide Bluemix Garage CTO, Rachel Reinitz as well as some of her friends.  This video is pretty long, almost 30 minutes, but it really captures everything that is happening with the Bluemix Garage including some new offerings and some of the design thinking that is shaping a lot of what is happening at the garage.  Have a watch below:

    While the Bluemix Garage was all things Bluemix garage, the DevZone was some of this and some of that. It had some Watson stuff, lots of automation and more. It was broken into two main areas.  One was hands on working on laptops in a lab type of area. The other parts of the zone were more exhibits of some of the cool things being done with IBM dev tools.  Robots, beer, food and lots of other good stuff.

    Again we were lucky to have a VIP tour of the DevZone from Brian Bryson and some special guests. Have a watch of this and get a great sample of what it was like on the DevZone as they served up “steak and sizzle”.

    If you like these looks at the show floor, be sure to check out our tour of the Watson area and the DevOps and ITSM Zone from the expo floor.

    We will be following up with a few more articles highlighting some of the other great videos from InterConnect 2017 in future articles, but you can check them all out now here.

    — Alan Shimel

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Sharma: Thank you.

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

    Sharma: Sorry. [Audio breaks up]

    Shimel: Did I break up there? I apologize.

    Sharma: Could you repeat that?

    Shimel: Sure.

    Sharma: I’m sorry.

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

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

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

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

    – but you have to disrupt it.”

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

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

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

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

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

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

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

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

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

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

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

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

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

    Shimel: No, of course I wouldn’t.

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

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

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

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

    Sanjeev Sharma –

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

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

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

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

    — Alan Shimel

  • DevOps in Legacy Systems: A Mission Impossible?

    DevOps in Legacy Systems: A Mission Impossible?

    The word “legacy” evokes mixed reactions from the IT and business crowds alike. For those who depend on legacy systems such as the zSeries and iSeries platforms, it is a way to deliver stable and reliable applications into production. Business stakeholders who may not know the intricacies of the technology often take a view of, “Why fix it when it ain’t broken?”

    mainframe

    On the other hand, for those who haven’t experienced the joys and pains of legacy systems , legacy world will continue to defy their logic and assumptions because their view of the world is shaped by the open system world which has completely different characteristics: being more malleable to change and easy to maintain etc. Hence there is this great divide between the legacy and new worlds. Add Agile and DevOps to the equation with the lofty goals of increased release frequency and reduced lead times, we end up with a divide that is too far to bridge.

    cobol code

    The likes of Gartner have come up with constructs such as two-speed delivery to help deal with this legacy challenge. In my view, there is a problem with the idea of dual-speed because it is based on a wrong analogy to start with — that of allowing vehicles to move at different speeds depending on whether you are on the motorway or a city road. That analogy works well for traffic management scenarios but not for complex IT architectures we see in the enterprise. The dependencies across the systems in the enterprise landscape are just too intricate and too tightly coupled to be defined using such a binary logic. In my experience, I find that many Agile and DevOps transformations hit the roadblock and never achieve the desired levels of productivity and effectiveness because of an oversimplified view of these complex dependencies across legacy and open systems.

    The three biggest challenges that prevent a legacy DevOps transformation are mindset problems, architectural constraints and tooling limitations.

    The Mindset Problem

    “There are no legacy systems, just legacy thinking.” That’s a great quote I heard recently from an engineer in a large organization trying to adopt DevOps at enterprise scale. The initial resistance from teams to move into DevOps ways is due to reluctance to change, emerging from an inertia of doing things a certain way for years if not decades. The mindset problem is as much a problem for those outside the legacy world as those inside. The “outsiders”—typically leadership, management team and consultants—tend to oversimplify the problem and, too often, rely on examples from the open systems world. This just alienates the incumbent legacy teams and makes them even more skeptical of DevOps driven change. The outsiders need to have a genuine appreciation of the challenges with legacy architecture and need to work in collaboration with the legacy teams if they really want to transform their organization.

    Architectural Constraints

    Legacy systems have certain characteristics such as being static, tightly coupled and monolithic blocks of procedural code. These systems were not built for the modern Agile workflows that focus on incremental and iterative deliveries. A significant majority of these systems are written to operate in batch mode.Testing the systems requires cycling through multiple business days, which simply limits the level of agility you want to introduce in the organization. I am currently working with a legacy engineering team in the financial services space where you have to cycle through a minimum of 20 business days to simulate even 70 percent of the test scenarios. However, there are a number of solution options to overcome the architectural challenges; they range from killing applications to migrating to modern platforms or re-engineering legacy code. Not surprisingly, the right approach depends very much on your context.

    Tooling

    Tooling in the legacy world to support a DevOps ways of delivery has always been a challenge. But it is fast changing now, thanks to a number of startups and even old-school IT product companies investing in this space. If you consider zSeries as an example, there are better IDEs (integrated development environments) such as RDz that can replace traditional code editors typically based on “green screens.” These IDEs provide great features such as better navigation, debugging, split views and searches on the legacy code. One of the CIOs I worked with made it clear to his team that he wanted to get rid of “green” screens from the IT floor. There are tools such as SmartBear Collaborator that support a great peer review experience and help bring one of the original XP practice of pair programming to the legacy world. There are tools such as endeavor from CA that promise automated build and deployments in the z-series world. Similarly, there are tools that support test automation of mainframe applications and tools for code coverage and code quality checks on legacy programming languages like COBOL. XATester looks like a promising tool for unit test automation from a Danish startup called Xact.

    While this write-up is not intended to be a compendium of all DevOps and engineering tools, the central message is that there are a number of DevOps tools emerging on the legacy landscape which can help your legacy delivery teams get on to the DevOps and Agile journey.

    What is more important is for organizations to realize that many of these legacy systems will remain part of their IT landscape for the next foreseeable future and it is time to invest in these core systems. They may not look as appealing as the digital platforms, but they are fundamental for businesses and you cannot ignore them on your DevOps journey. DevOps in the legacy world is not going to be smooth, but it is certainly not a mission impossible!

    — Aditya Vadaganadam

  • IBM InterConnect – CrowdChat, Preview and Panel Discussion

    IBM InterConnect – CrowdChat, Preview and Panel Discussion

    We are just about 2 weeks out from IBM InterConnect, which is shaping up to once again be heavy  on DevOps and related technologies. Of course there are other things on the agenda besides DevOps (really?), like cognitive and Watson for instance. There will be plenty of cloud, IoT and more cutting edge technology subjects. But you could read about that on other sites. Lets stick to DevOps here.

    First things first is I want to invite you to participate in a CrowdChat we are holding on March 10th at 1pm EST. CrowdChats are one of my favorite social media activities. For the duration of the event it is controlled chaos, as multi-threaded discussions break out across Twitter, Facebook and Linkedin.  You just have to use the hashtag #ibminterconnect to join in the discussion.

    I will be one of the hosts of this event, but I will be joined by Gene Kim, IBM’s Angel Diaz and Erick Minick and some surprise hosts that I can’t mention right now. So join in the discussion and fun on the 10th.

    At InterConnect itself, there are some great keynotes lined up and many outstanding speakers from diverse backgrounds. I want to call your attention though to one session in particular.

    Enterprise DevOps: It Takes a Village

    Wednesday, 9:00 AM – 9:45 AM | Mandalay Bay Ballroom A | Session ID: 1346A

    When talking about enterprise DevOps transformation, many people look for a silver bullet—a magic wand that will convert an old, inefficient organization into a high-performing, DevOps-enabled IT team. But in truth there is no single silver bullet. DevOps takes a village. This DevOps village, like a real village, consists of physical infrastructure, as well as members. DevOps often needs a cultural transformation that builds a true community with the same aims and goals. No one vendor has all the tools and no one tool does it all. DevOps tools must work in unison. Finally,  a methodology that recognizes the communal nature of DevOps is essential to bringing it all together.

    I hear the moderator for this panel session is pretty good. Some guy named Shimel ;-). Seriously, we have a strong panel and it should be a great discussion.

    Other speakers to catch are Gene Kim, Sanjeev Sharma (on his new book), IBM CEO Ginni Rometty, Wayne Brady and Reshma Saujani, founder and CEO of Girls Who Code. Check out the InterConnect site for full details.

    We will be posting some more DevOps Chats and interviews of some of the scheduled speakers between now and March 20th as well. So stay tuned for those.

    Tomorrow, we have a webinar with Carmen DeArdo of Nationwide, Donovan Stevens, South African Revenue Service and Rachel Reinitz, IBM Distinguished Engineer, CTO IBM Bluemix Garage. The webinar is on “Lesson Learned in Scaling Enterprise DevOps”, you can register here.

    — Alan Shimel

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

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

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

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

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

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

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

    Alan Shimel:                Thank you. And we are lucky to be joined by a DevOps Dozen winner, Shelbee Smith-Eigenbrode of IBM, and also a devopsy.kinsta.cloud columnist. Shelbee, thank you for joining us along with Bryson.

    1. Smith-Eigenbrode: Thank you for having us.

    Alan Shimel:                Of course when Shelbee is not writing for devopsy.kinsta.cloud, Shelbee is a Senior Software Engineer/IT Architect at IBM.

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

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

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

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

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

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

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

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

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

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

    Alan Shimel:                Very cool. Shelbee, let me turn a little bit away from the Watson stuff and talk about you recently did a DevOps blog on culture transformation. Interestingly enough, you interviewed Bryson about it. We haven’t really spoken about DevOps and cultural transformation here. I’m interested in why. What made you think Bryson was a cultural transformation kind of dude, for lack of a better word?

    1. Smith-Eigenbrode: First off, let me just say that at the time I reached out to Bryson he was not in my management chain. So it wasn’t a brown-nosing activity at all. I had the opportunity to work within the Weather Company and work with some of the Weather Company employees who are now of course IMB’ers, while working on a project to move an application to the Sun platform and utilize some of the Sun services.

    During my time that I was there and able to work with some of the employees there, I was so impressed with the culture that they had. They had a great balance between agility and time to market, but also having that quality of operational readiness. Of course for me operational readiness has always been key, because I’ve always felt the pain of not having that included upfront.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Alan Shimel:                Agreed.

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

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

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

    Alan Shimel:                That’s not old.

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

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

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

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

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

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

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

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

    — Alan Shimel

  • DevOps Chat: Chris Lazzaro & Peter Klenk, IBM Bluemix and IBM Bluemix Garage

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

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

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

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

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

    Peter, Chris, welcome to DevOps Chat.

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

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

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

    Alan Shimel:                And, Chris, how about you?

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

    Alan Shimel:                With scale like in enterprise.

    Chris Lazzaro:           Yep, and meet those enterprise demands.

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

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

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

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

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

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

    Chris Lazzaro:           CRISPR.

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

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

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

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

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

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

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

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

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

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

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

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

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

    Alan Shimel:                Yeah. Chris –

    Chris Lazzaro:           So it’s that –

    Alan Shimel:                I’m sorry; go ahead.

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

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

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

    Peter, agreed?

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

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

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

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

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

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

    Alan Shimel:                Great.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Alan Shimel:                Excellent.

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

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

    Peter Klenk:                March.

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

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

    Alan Shimel:                Yeah, like March 20 to –

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

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

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

    Peter Klenk:                Feedback.

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

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

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

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

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

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

    Peter Klenk:                Shameless.

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

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

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

    Peter Klenk:                Always a pleasure.

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

    — Alan Shimel

  • A Six-Step Approach to Enterprise DevOps Transformation

    A Six-Step Approach to Enterprise DevOps Transformation

    Agility of businesses to transform and adjust to market conditions is perhaps the most important aspect of managing today’s enterprise. With digitization of almost all facets of running an enterprise, it is safe to say that IT agility translates to either the success or failure of such adaptation. Smaller and new-age businesses are better able to adapt, while large, established enterprises struggle or are too slow to adapt. Large enterprises have been executing in an established, traditional way for decades and have solidified their existing processes and decision-making.

    New-age businesses don’t have a choice. They have to be agile because of the force to create something new. They either have cloud-native technology support or, even with traditional IT are able to embrace agile, automation and continuous delivery paradigms to stay nimble.

    So, what constrains large enterprises? There are three main elements: organization structure, legacy technology stack and culture.

    The good news is that there are proven industry approaches to embracing agility in delivering business outcomes. The bad news is that it is quite often a long, arduous journey. This long transformation is often riddled with compromises from “comfort zones,” is potentially career-redefining for executives and practitioners and, of course, requires a fair bit of time and dollar investment.

    In my travels and working with many clients across multiple industries, I’ve found that executives do not like terms such as “transformation.” Somehow it is often interpreted as “cost cutting” or “resource realignment” or “outsourcing.” There is some merit in using terms that are appropriate to each enterprise. But, the intent is to transform the way solutions are being delivered today and to do it faster, cheaper and better. The techniques of Agile and DevOps have been successfully implemented in many large and small organizations to enable those outcomes.

    To address the three areas of organization, technology and culture, let me present an approach that works quite well for most enterprises. There is always an element of customization of the approach to meet specific needs, but it should provide a basic framework of the activities and potential time frames necessary to implement the transformation program.

    The Six-Step Approach

    Step One: Initial Planning for Enterprise Readiness

    Participants and Inputs, Existing Collateral, Design Thinking, High-Level Outputs

    As stated earlier, these steps are customized to each organization, including the participants and inputs, among other factors. For example, the CEO may not be the program sponsor for a given enterprise as it could either come from the CIO or it could be business line-driven. Other enterprises may choose to launch the program at director levels. If possible, this should not be done. The highest chance of success is when the program is championed at the highest levels.

    Participants should absolutely include all the towers that make up the solution delivery. Business participation is imperative, along with operations, security and development. I always recommend that the workshops conducted in this step be led by an external experienced consultant or a coach. The key here is to get executive buy-in and create common goals and understanding on what an Agile-DevOps program will look like.

    Typically, there are several small DevOps programs already in place in silos that lack maturity to scale to the enterprise level. Design Thinking is a great method to use since it leverages the expertise of all stakeholders, enables them to come to a common understanding, and establishes the needed buy-in. The diagram below illustrates an initial plan for project readiness incorporating the components discussed. 

    Step Two:  Establish a DevOps Center of Excellence

    Identify an Executive DevOps Lead with Enterprise Authority

    Establishing a Center of Excellence (CoE) is not good enough if it’s not at the right organizational level and enterprise authority. It has to be led by an enterprise leader who has the support and buy-in from all the towers. Active participants of the CoE include representatives from all the delivery towers and also vendor organizations. These participants must be chosen wisely.

    I highly recommend that initial phases of CoE be led by an external experienced partner and transitioned over time. The initial phases help cement the vision and strategies of the COE and setup the best practices to support it. Typically, the time to transition from the business partner to internal is 12 to 24 months.

    Step Three:  Establish Program Governance

    Create Communications Plan, Enablement Program, Establish Program KPIs

    This is the most important step to make an impact to the culture of the organization. With Agile and DevOps, practitioners’ roles and responsibilities will change. They’ll need awareness, enablement and empowerment to succeed. It is extremely important they understand collaboration between organizations that historically may have had animosity so they can break down these organizational walls. KPIs must shift from individual metrics to holistic customer business outcomes.

    Step Four:  Establish Project In-take Process

    DevOps Subject Matter Experts (SMEs) Conduct Intake Workshops for Scrum Teams

    Project intake really sets the tone for how successful each sprint that onboards the program will be. It is not so much about tools and process, but the right sizing of tools and process. There needs to be a fit for purpose in the selection of accelerators, tool chain and development methods. Once established, communication of the intake process needs to occur across the organization.  Gather feedback and continually evolve and mature. 

    Step Five:  Identify and Initiate Pilots

    Applications Representative of Target Portfolio to Scale

    This step has the best chance of success if applied to a specific portfolio of applications or a domain solution. I strongly recommend having some working sessions prior to this workshop to identify an area of development work that represents a portfolio to scale to the enterprise.

    The purpose of this step is to conduct a value stream-mapping exercise of a specific application with participants from all towers. This needs to be conducted with the level of detail necessary to identify end to end as-is process, tooling, manual and automated processes, and skills and people involved.

    The next part of the project intake is the collaboration of the subject matter experts (SMEs) from the CoE with the project team. The purpose is to advise on “to-be” process with necessary tooling, reusable assets, automation and SMEs needed from operations, security and other applicable areas. These SMEs will comprise the application scrum team. As the application goes through its development/test cycle, identified KPIs for the program are captured. This is absolutely necessary to compare with existing KPIs.

    Step Six:  Scale Out DevOps Program

    Onboard Parallel Release Trains; Apply Intake Process; Support, Monitor and Manage

    The final step is to take feedback from metrics of the pilots and scale them by running multiple release trains from different application portfolios. It’s not good enough to just do daily builds and automated deployments. The final piece of the DevOps puzzle is the continuous feedback and optimization.

    Summary

    The above is an approach that can be implemented in a flavor that best represents each organization’s needs and constraints. Be considerate of large gaps or excessive deviations that may be red flags to be corrected.

    Now that you are equipped with the six steps for an enterprise DevOps transformation, you can look at each of them critically, see best fit, and start the journey!

    I will be @ Interconnect this year for a session on Environment As A Service. Stop and say hello. Other articles to reference are:  “Five things to understand about Enterprise DevOps Solutions,” “DevOps in a Hybrid Model,” and What is platform as a service (PaaS)?”

    About The Author/Sunil Joshi

    Sunil is an IBM Senior Certified and Open group certified Distinguished Architect. He is currently the Application Innovation Cloud Services Emerging Technology leader. His specialization is in the areas of hybrid cloud solutions, platform as a service and DevOps strategy. Sunil has authored several IBM Redbooks, blogs and also a co-author of the IBM Cloud Computing Reference Architecture (CCRA). Sunil is a regular speaker in the industry on Cloud, DevOps, Microservices, Digital Transformation and related topics. Connect with him on LinkedIn | Twitter

  • Mainframes and the Myth of Bimodal in DevOps

    Mainframes and the Myth of Bimodal in DevOps

    Rewind 20 years ago when we lived in a business world where big companies with unlimited resources beat out smaller, more strapped companies. The digital era—also known as the “age of the customer”—is changing all that. Where big once beat small, fast now beats slow. The DevOps approaches of startups often make them more adept at continuously delivering the innovations and conveniences that earn customer raves. Bigger, established companies often feel disadvantaged‚ shackled by an outdated culture and inflexible processes that haven’t kept up with the pace of change.

    Gartner coined the term “bimodal IT” as a way for older IT establishments to keep pace with agile startups. In the bimodal model, IT teams are separated into two distinct styles of work—one focused on supporting predictable, well-understood workloads with legacy systems and another that is more fast-moving, experimental and adaptable in meeting users’ constantly evolving demands and flourishing digital expectations.

    But the bimodal concept is not well-aligned to the spirit of innovation underlying modern application development and delivery. This is especially true for bigger organizations using mainframes. Here’s why.

    Successful DevOps Depends on Mainframe Agility

    The goal of DevOps is to roll out high-performing software and updates, ahead of the competition and with maximum speed, ease and cost-efficiency. In a DevOps model, software delivery can only happen as quickly as the slowest team. Modern web and mobile applications tend to span multiple platforms in their end-to-end transaction—from front-end web servers (systems of engagement) all the way back to mainframes (systems of record). IT places a lot of emphasis on systems of engagement, often taking back-end systems of record for granted. The reality is, the value in systems of engagement cannot be realized without the systems of record—making it essentially all one system. Developers supporting modern applications must be able to maneuver across and between all platforms, especially within mainframe code and data.

    Let’s look at a tactical example of this. According to industry research, 80 percent of the world’s corporate data—including customer data—continues to reside on mainframes. When a mobile web application is used to make a bank deposit, or purchase a product, for example, the transactional component of those applications typically is executed on back-end mainframes.

    This means mainframe applications are crucial to development efforts. What happens when mainframe developers and testers are locked into waterfall processes or don’t have the modern tools necessary to understand application logic or access mainframe data for testing? Frustration mounts and the overall innovative effort is unnecessarily stalled.

    Stability and Agility are not Mutually Exclusive

    The longstanding myth that stability and agile cannot co-exist is simply untrue. Unfortunately, it’s at the core of negative perceptions surrounding the mainframe today—people think the mainframe environment is too slow and cumbersome to support agile development. Development teams may think if they have mainframes, the only approach it can support is waterfall.

    The reality is, though, no customer will accept poor availability and performance in exchange for new features delivered quickly.  People with hands-on experience painfully understand that slow, waterfall delivery methods produce far greater quality issues and missed expectations, resulting in competitive risk. Additionally, large enterprises taking the “slow and stable” route give startups a head start in beating them to market, with offerings that customers want now.

    Alternatively, Agile process and DevOps tool chains enable scrum teams to test quality in terms of usability, function and stability early and often in the development cycle—when the time to remediate is the fastest and the cost the lowest. Agile process and DevOps tool chains build higher quality applications and enable continuous improvement in quality over time.

    Re-Platforming is not Necessarily the Answer

    Some DevOps proponents believe moving off the mainframe—to a supposedly more modern, commodity server-based distributed architecture—is the best way to circumvent perceived challenges to nimbleness and agility. But this is almost never the best answer. The mainframe retains its distinction as being the most powerful computing platform on the planet. It remains deeply embedded in large organizations, setting the standard for reliability, security and availability for mission-critical data and transactions. The new IBM z13 mainframe, for example, can handle the load of 100 Cyber Mondays every day, 365 days a year. Currently, mainframes process 30 billion business transactions per day. The post-modern mainframe is an engineering marvel unequaled as a system-of-record, business compute platform.

    The mainframe also offers cost advantages. Studies have shown that the mainframe is more cost-effective than commodity servers in handling the massive computing volume increases instigated by mobile applications. This is because decreases in commodity server pricing have not kept pace with the increase in computing volumes. In addition, leading vendors have worked together to deliver intelligent cost management on the mainframe, enabling workloads to be distributed in a way that keeps mainframe licensing costs (MLCs) down.

    In our view, “biomodal” advocates for the exact problem that must be solved. We think the answer is not replacing the mainframe, although if mainframe development is left unaddressed, this can present obstacles to DevOps. Rather, the answer is to evolve the mainframe to keep up with the pace of DevOps. There are mounting examples from large, high-performing organizations that it is possible to apply modern practices to the fullest extent, including mainframe applications. These organizations do this by giving developers the tools they need to work on mainframe code and data just as they would with any other programming language on any other platform, while meeting the escalating quality expectations of the digital age. For example:

    • Mainstreaming the Mainframe Environment – Mainframe users need to move away from the antiquated “green screen” mainframe environment, adopting state-of-the-art interfaces and tools. This is the first step enabling developers to work more fluidly on the mainframe, in an environment that’s much more familiar and comfortable to them. Organizations that fail in this adoption will have a very difficult time enabling the next generation of development talent to leverage invaluable and irreplaceable mainframe code and data. This will place a huge hindrance on DevOps success.
    • Leveraging Tools from the Java Development World – One example is visualization capabilities, which enable developers to quickly and easily identify critical interrelationships between apps and data. This helps them to sidestep unintended, undesirable impacts as they modify applications, increasing confidence and mitigating unnecessary delays.
    • Make it Easier to Identify Mainframe Code-Level Issues – Developers need tools that enable them to identify problems with mainframe code; for example, when it is the source of a widespread user performance issue, or when it is consuming too many resources and driving up costs unnecessarily.

    Conclusion

    In our view, “bimodal” is not the solution, but a broken state of disadvantaged affairs for too many organizations. From a competitive vantage point, bimodal will only hurt DevOps teams and hold back the innovative efforts of the organizations they support.

    The bimodal IT model is a road to inevitable failure for those enterprises seeking success in the digital economy. This is especially true for organizations that rely on mainframes. A smartly leveraged mainframe is an extremely valuable competitive asset that needs to be removed from its silo, evolved and smoothly integrated into modern, heterogeneous development environments.

    It is possible for big, established companies to adopt DevOps, become agile, and move as fast as startups. But the ability to think and act like a startup requires some major fundamental changes, particularly at the level of software development. The good news is, the legacy technologies that are often perceived as impediments can actually be a tremendous competitive advantage, if they are harnessed and evolved in the right manner.

    About the Author / Christopher O’Malley

    chris-omalley2Christopher O’Malley is CEO of Compuware. He has nearly 30 years of IT experience with past positions including CEO of VelociData, CEO of Nimsoft, EVP of CA’s Cloud Products & Solutions and EVP/GM of CA’s Mainframe business unit, where he led the successful transformation of that division. Connect with him on LinkedIn and Twitter.

  • DevOps Chat: CJ Paul, IBM, on DevOps, ITSM, Cloud and More

    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.

  • A Panel Discussion On What DevOps Looks Like In 3 to 5 Years?

    A Panel Discussion On What DevOps Looks Like In 3 to 5 Years?

    With all of the hype around DevOps, I wanted to return to a topic that I was lucky enough to moderate a terrific panel on at IBM InterConnect this past February. The panel was an all star one anchored by Gene Kim, moderated by myself and we were joined by Dan Berg of IBM, Michael Azoff, principal analyst at Ovum and Raghunath Raman of Kaiser Permanente.

    It was a lively discussion as we all had our own opinions on where DevOps may be headed and how this will impact how we do business. Unfortunately this panel was not video taped, so I cannot share it with you here. But I did get a chance to sit down and discuss this topic with three of the four panel members (I was not able to catch up with Gene as he was running right after our panel).

    So I wanted to share my discussions with each of the panelists with you. First is Raghunath Raman of Kaiser Permanente:

    Next up is Michael Azoff from Ovum. Also you may want to check  in a subsequent DevOps Chat I did with Michael a few weeks ago.

    Finally, last but certainly not least is IBM’s Dan Berg who I have had the pleasure of interviewing several times.  Dan’s interview was done a little later at the show, so is less focused on our panel subject. Our discussion on the panel comes in at about 2:58. Here is Dan’s interview:

    So what about the panel? Some of the highlights were that containers and microservices are going to become a major factor in development going forward. They won’t replace hypervisors totally, but they will become the defacto standard for building and deploying apps.

    Several of the panelists said they didn’t know if DevOps would be called out as DevOps anymore, it would just become the way things are done (something I very much agree with). Of course Gene was full of antidotal stories and studies of companies he has spoken with who are adopting DevOps. All in all the 45 minutes was way too short to dig in as much as one would like with four great panelists, but the standing room only crowd certainly got a lot to chew on.