devopsy.kinsta.cloud

Category: Features

  • DevOps Chat: Madhura Maskasky, Platform9

    DevOps Chat: Madhura Maskasky, Platform9

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

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

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

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

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

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

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

    Maskasky: Yeah. It must be Sirish Raghuram.  

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Madhura, where can people find out more information?

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

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

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

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

    — Alan Shimel

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

    DevOps Chat: Mik Kersten, Tasktop on Value Stream Visualization

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Mik Kersten:               Thank you.

    Alan Shimel:               This is Alan Shimel for DevOps.com.

    — Alan Shimel

  • Be Here Now – Agile and DevOps in the Current State of Synergy

    Be Here Now – Agile and DevOps in the Current State of Synergy

    If there’s one thing that our culture does not lack, it’s a litany of pithy catch-quotes meant to remind us to focus on the task at hand; yet, this often runs counter to our tendency to fixate on matters of the past and future.

    While we are so often encouraged to “live in the moment” and “seize the day”, this is hardly an easy task, especially as related to any sort of emerging phenomenon that compels us to improve on historical missteps, and predict how things should change for the better.

    Register today for the 3rd Annual DevOps Virtual Summit.

    With the methodologies of agile and DevOps the tendency is, of course, to do the same, harping on the inefficiencies of previous software delivery models and painting an elaborate portrait of how related workflows are being transformed overnight.

    The simple truth is that it’s easy to get excited about concepts that hold such tremendous potential in recasting an increasingly critical vital set of processes, and lose track of where things actually stand.

    To note, while a recent research project published by Coleman Parkes found that over 80 percent of organizations have adopted some manner of agile and DevOps practices, and see them as critical in transforming their internal software factories, only a third have adopted the methods on a broad scale.

    Point being, we’re still pretty early.

    That said, we in the business of helping organizations adopt related culture and tooling have gone to great lengths to encourage everyone that this change should be pursued with dogged intensity. We have sliced and diced the data to illustrate how those organizations at the forefront of so-called digital transformation, enabled by agile and DevOps, are realizing the results in the form of increased velocity.

    The same research finds that “advanced” adopters of the two concepts are, in fact, seeing significant improvement in time-to-market, customer satisfaction and new business growth.

    But research is just that, and often not completely aligned with real-world scenarios. Someone who takes the time to answer a survey about such matters, one could reasonably expect, is the type of person far more likely to be involved in agile and DevOps activities.

    My personal conversations with everyday practitioners [aka other parents on the sidelines at my kids’ sports and social events, many of whom work in IT] tell me that we’re much more oriented to the “pockets of innovation” phase at present, than any sense of pervasive adoption.

    So this begs the two-part question – where do we really stand, and what do I really need to care about?

    The only reliable source of record in my mind is the perspective of people already doing the work, beyond what I can discern amid basketball games and middle school theater. Real-world practitioners are the voices of reason that allow us to “be here now” and address the specifics of practical agile and DevOps implementation.

    Over the past several years, I’ve found one of the best sources of such input to be the customer panels available at industry conferences and on webcasts. When it’s time for me to sit down and crank out some related content, I often go back to these recordings to remind myself where the rubber actually hits the road.

    On Tuesday Mar. 7, we’ll host just such an event, the 3rd Annual DevOps Virtual Summit, where agile and DevOps leaders from organizations including CNN, GM Financial and United Airlines will share their thoughts on how this ongoing transformation is playing out, and where the remaining challenges lie.

    Along with those experts, we’ll also hear from Dr. Nicole Forsgren, one of the leading researchers in the space who is in seemingly constant contact with people leading the charge and working in the trenches putting agile and DevOps into practice.

    As a marketer, and previously as a journalist, everything that I know comes from direct interaction with those colleagues willing to share their hands-on experience garnered via doing this work every day.

    Register for the event and join us to find out where agile and DevOps actually stand today.

    — Matt Hines

  • 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, DevOps.com, 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 DevOps.com, 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 DevOps.com 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 DevOps.com, 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 DevOps.com from you as well.

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

    — Alan Shimel

  • In DevOps, Speed Isn’t Always the Point

    In DevOps, Speed Isn’t Always the Point

    The high-tech industry has fallen into a rut and seems to be struggling to get out of it. This rut is most fervently seen when talking about DevOps, but it exists across the board.

    We’ve fallen in love with the idea that faster is always better. That idea is provably false, and the assumption that everything needs to be faster is false, also.

    Early on, time to market and increased responsiveness to user needs were the driving market differentiators for agile development, DevOps and DevOps tools. There were indeed cases where IT was not responsive enough to business needs—I think most of us were acutely aware of this issue, so dwelling there for a while was not a terrible thing. But responsiveness to business needs is one piece of a much larger puzzle. And we seem to be stuck, with some lip service paid to other strengths of DevOps … as long as it’s still delivered yesterday.

    In my career I’ve worked in two industries where speed of delivery was a tertiary concern for core business systems. To be blunt, when you are putting together a system that will administer contracts expected to last a hundred years or more, you really don’t get that worked up about it being out there tomorrow and “good enough,” you worry about it being right when it does go out, so you’re not still paying for mistakes a century from now that were made by rushing today.

    Of course, there are vendors that don’t want to hear people like me say these things. Of course, there are products with other benefits that are more important than speed of delivery. But as an industry, we’re still too obsessed with speed.

    How we too often see priorities

    Most industries do not even fall into a neat category where they are all or nothing. For most, some teams need to be fast, using agile, CI/CD and fully automated deployment to drive out changes fast (not as fast as some talk—most don’t even need weekly, but fast, nonetheless), while other teams need to be more thorough and cautious and the cadence of releases really doesn’t matter as much as the final result.

    So my advice is similar to advice I’ve offered on similar “hot” topics for the last decade or so:

    You are the rock stars.

    No vendor, analyst, pundit or author knows your vertical market, organization, environment or team the way you do. Do not let them proxy their view of what is “right” over you. Yes, far too many act as though, “If you’re not doing X, you’re behind.” But again, you can look at your industry and get a better grasp of what the definition of “behind” is than someone talking in generalities.

    Know what you need, know what is most important, know how to get to what you need. Don’t do what “everyone” says you should.

    But don’t dismiss the need, either. There are other benefits to these technologies that we have only recently started discussing. Infrastructure as code is an astounding way to transfer knowledge should something happen to critical people, for example. You just have to choose the technologies for the right reasons, and what the right reasons are is dependent upon the organization, not what Vendor Y is selling today.

    We’ve come a long way, and are on the cusp of some very cool stuff, but make sure you know what you need, and how to get it, then keep doing your magic.

    — Don Macvittie

  • Automation’s Impact on a Structured Life

    Automation’s Impact on a Structured Life

    A few years back my sister’s husband died after an unexpected illness. My sister, who was in her early 50s, experienced a devastating loss at a relatively early age. To her good fortune, my brother-in-law left behind an adequate pension and their mortgage had been paid off, so she didn’t have to bear the burden of having to work to make ends meet. And she didn’t—for a while, anyway.

    After a period of mourning and adjustment, however, my sister decided to return to work. I asked her why, and this was her response: “There were only so many movies I could go to, only so many TV shows to watch, only so many trips to take. I just needed something to do.”

    Now you may ask, what does my sister’s loss have to do with the impact of automation on human employment? Consider this: As automation replaces more human labor, fewer people will be required to make the economy function. Many of those whose labor is no longer needed will be left unemployed, sitting at home deprived of the thing that gave their lives meaning and structure: a job. And without a job, many will be left adrift—not just economically, but also psychologically, living a life without meaning or purpose. That which made their lives worth living will be gone. The implications of a population put aside by automation and living a life without structure or meaning are significant.

    Allow me to elaborate.

    The Need for Structure in Day-to-Day Living

    Human beings are not born with the instinct to organize their waking hours. Anybody who has a 2-year-old can tell you, a child will run around all day until he or she drops. It’s up to mom or dad to say, “It’s time for breakfast, “It’s time for lunch,” “It’s time for a nap,” “Bedtime’s coming; put on your pajamas and let me read you a story. Good night.”

    Children need structure imposed on them from an external source. That’s how it is. This role is filled by a parent, and later in life the school in the form of structured activities performed at usual times. By the time a youngster enters high school, most will have a firm sense of how a day is organized.

    This sense of organization transfers well to the workplace: A good employee respects the structure of the day. She arrives on time, does the tasks for which she is responsible, communicates the status of her tasks, respects the time of others and meets the time demands made upon her. Whether you work in a factory or a law office, being able to operate effectively within the structure of the workday is essential to one’s economic and psychological well-being. There is a certain comfort that comes from knowing where one is going to be on Tuesday and knowing what one will be doing.

    So, what happens when the job goes away? How does one organize himself or herself without something explicit to do? As my sister said, “There are only so many TV shows to watch.”

    Let’s take a look at the extreme.

    Providing Structure Where None Exists

    When I was a young man, before I got into programming, I was a counselor at a secure detention facility for adolescent boys. This a nice way of saying I was a guard in a kiddie jail. Most of my day was spent supervising the movement of teenagers who had committed very serious crimes. When I say supervising their movement, I mean that in the most literal sense. The job of my squad was to make sure the residents woke up on time, dressed in their rooms and were ready to go to school. Then, we called for lineup. The boys lined up and were counted. After count, our squad moved the line to breakfast and then onto the facility’s school. Once in school, we stood at the back of the classrooms to supervise the residents. If a student acted out, we removed him from class. At the end of the school day, we did the lineup again and went back upstairs. The residents went to their rooms. Then they lined up for the exercise yard. At 6 p.m. we lined them up again and went to dinner. After dinner, we moved the line upstairs. At shower time, we moved the line to the shower room. The day was very structured, to say the least. Day in and day out, everyday was predictably the same.

    And you know what? It worked.

    The residents responded to the structure. Most grew to accept the routine. They went to school and got a little smarter. Three square meals a day made them a little healthier. These were boys who had been left to their own devices since early on, mostly because of neglect. They had little sense of how to organize a day. They just did whatever popped into their heads. And sometime what popped into their heads was an armed robbery or felonious assault. In terms of the ability to organize themselves, most were at the level of a 2-year-old—a scared 2-year-old. Not surprisingly, the predictability of events and presence of supervision made them feel safe. Once, I asked one of the residents why he was there. He said with surprising candor, “Because I want to be.”

    When a Job Goes Away

    Granted, adolescent incarceration is an extreme example of imposing structure on someone’s life where no structure exists. But, what happens to a person when a job—the basic agent for organizing one’s daily life—goes away?

    Here’s what happens.

    Some people die prematurely. A study of Shell employees found that those who retire at 55 are 89 percent are more likely to die in the 10 years after retirement than those who retire at 65.

    Others have increased rates of substance abuse. A study conducted by the Substance Abuse and Mental Health Services Administration indicates that 17 percent of unemployed worker suffer from substance abuse—twice that of those who are employed.

    Or, they spend more time sleeping and watching TV, as reported by the Wall Street Journal.

    Clearly, having a job is better than not having a job. Financial considerations aside, it’s the way by which most people organize their day. As more people become displaced from the workforce because of automated labor and are living without the demands of daily work to structure a day, more of the population will feel adrift. If the trends described above stay true, there will be an increase in substance abuse, TV watching and death rates. They also may look to other external forces for structure, such as political movements that promote order, rank and predictability.

    So, what are we to do? In earlier versions of this article, I included a call to action to revamp, maybe even revert, the educational system to focus more on the arts and humanities rather than the baseline skills required to get a job. I planned to point out that artists, athletes, scientists and entrepreneurs don’t need to a job to structure themselves. They always have something to do. They have an internal ability to organize themselves in the pursuit of short- and long-term goals that are their own. As we move toward full automation, these folks are going to do just fine.

    Anyway, that’s what I planned to propose in the earlier versions. Now I just don’t know. I am not sure we have the social or political will to address the problems that are on the horizon. The highly educated people who have good analytics skills and a creative outlook will find paying employment. But, as trends indicate, those who are paid to follow instructions and perform redundant tasks will be replaced by robotic automation. They will go home. They will watch unlimited amounts of movies and TV on Netflix, Amazon and YouTube. They will play games on the internet, for a while anyway. Then, one day they will come to realize that there are only so many movies to watch and so many games to play. The appeal of an unstructured life will wane. They will want something to do and have no idea about how to make that something happen.

    So the questions at hand are these: Will we fortunate ones—particularly those of us in IT, the people who are implementing the automation—watch from the sidelines? Or, will we come to understand the consequences of automation on human employment—and in doing so, will we be become part of the large-scale solution, devising ways that help those that are going to be displaced think different and be different?

    I hope so.

     

    This article is the last of the series, The Impact of Automation on Human Employment. Here is a list of the previous articles:

    What Do We Do When Everything is Automated

    Rethinking Unemployment in the Age of Automation

    The Impact of Automation: Considering 3 Facts

     

    — Bob Reselman

  • Security @ the Speed of DevOps Survey: Efforts Still Lag

    Security @ the Speed of DevOps Survey: Efforts Still Lag

    Enterprises today are in a relentless race to digitize or die. If they don’t digitize business processes, services or internal workflows and their competitors do, they will be at a steep disadvantage—and perhaps soon an irrecoverable one.

    In more and more companies these efforts are being driven by DevOps. According to IDC, the vast majority of businesses today think—and rightly so—that it is essential for them to put into place the right resources and IT processes to support a digital business model. Unfortunately, about 75 percent of organizations don’t think that their IT organization is actually scalable enough to deliver and support a comprehensive digital business model.

    There are many reasons why so many organizations have a challenging time with their digital transformation efforts. Many of these are cultural: IT commands tightfisted control over all information technologies used throughout the organization, yet being unable to deliver the infrastructure and digital services enterprises need to succeed, for example. Or, others within the organization still are unable to see how rapidly the world is being changed by digital technologies and so aren’t taking the necessary steps.

    Another reason is security. That’s because this rapid digitization of business processes can have a profound impact on how enterprises secure their data, applications and software development and delivery. In DevOps.com’s inaugural annual “Security @ the Speed of DevOps” survey, we queried 255 security IT decision makers within organizations currently practicing DevOps or that are on a path to DevOps adoption. The survey found that enterprises of all sizes are embracing DevOps, cloud, continuous integration and deployment. But in securing these processes, however, we found vast differences in maturity.

    When it comes to DevOps practices, larger companies are outperforming. For organizations with 5,000 to 9,999 employees, a full 90 percent have either adopted or started DevOps practices. However, only 38 percent of organizations with 500 or fewer employees have started DevOps or widely adopted such practices.

    As I wrote in our report on the survey, smaller organizations also have a way to go with automated security testing. Only 6.5 percent of those with fewer than 100 employees have automated large parts of their application security testing, while 29 percent have automated some of their application security testing. For firms with 5,000 to 10,000 employees, 38 percent have automated large parts of their testing, and nearly 50 percent some of their testing. For those with more than 10,000 employees, these figures are 20 percent and 48 percent, respectively.

    The challenge here, for many organizations, is the same with enterprise security in general: the view that security slows things down. For the business, it’s about getting more digital capabilities out as quickly as is possible. It’s the same for developers. Security too often is seen as standing in the way of this.

    When this conflict is experienced at DevOps speed, there is the risk not only of development slowing down but also security processes breaking. To succeed, enterprises can’t take the same approaches to security as they did in the past. They must find tools and processes that are designed for the highly automated and continuous world of DevOps.

    Have a look at our survey and report to see how enterprises are tackling this challenge today.

    — George V. Hulme

  • DevOps Chat: Justin Vaughan-Brown, AppDynamics

    DevOps Chat: Justin Vaughan-Brown, AppDynamics

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    What other kind of trends are you seeing?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    — Alan Shimel

  • Gain a Competitive Edge with DevOps

    Gain a Competitive Edge with DevOps

    DevOps has attained mainstream status. It is no longer a cutting-edge concept that only startups and progressive companies embrace—it’s a business imperative that delivers a significant competitive edge. If you want evidence of the impact of DevOps, take a look at the 2016 State of DevOps report.

    But what is it about DevOps that gives companies a strategic advantage over competitors?

    “A DevOps approach enables companies to respond much more quickly to customer needs, competitive pressures and realize faster time to innovation,” says Sacha Labourey, CEO of Cloudbees. “Because DevOps is all about a culture of shared goals, and processes that accelerate software delivery through smaller, incremental releases, issued more frequently.”

    However, Labourey cautions that DevOps doesn’t work to its full ability if the entire company is not on board. There needs to be strong communication and internal education within an organization to successfully implement a DevOps culture. You have to educate staff at all levels in the enterprise of the cultural and structural shift. Essentially, you have to break down barriers and get teams working together that haven’t typically worked together before. In fact, you need teams that may have been at war before, to now work together.

    Struggles between teams often are driven by opposing goals and measures of success. DevOps empowers teams and individuals to work together and collaborate toward common goals more effectively. It’s a synergy that fosters cooperation rather than conflict.

    Labourey says any company has the potential to transform to a DevOps culture. But there are some crucial questions organizations must answer before planning a DevOps transformation:

    • Can the enterprise commit to putting the time and hard work in that is required to effect internal change and behaviors?
    • Does the company environment support a DevOps culture and the values it brings with it?
    • Is the executive team fully supportive, and maybe have even mandated, the change to DevOps?

    “In order for DevOps to truly work, there must be a commitment to enable the change. This only happens with a lot of hard work, diligence and support from the top,” Labourey says. “Any company that needs to deliver quality software—and deliver it quickly—should care about DevOps and the supporting practice of CD.”

    DevOps, and the culture of teamwork it instills in organizations, delivers significant benefits:

    • A decrease in time to market—innovation is delivered rapidly. Additionally, experiments can occur, with a “fail fast” mindset.
    • Internally, satisfaction with the overall software delivery process attracts and retains better IT talent.
    • Employees can innovate quickly and just as quickly see the results of their innovation.
    • Software is of higher quality, since releases are smaller, incrementally produced and have less impact on the overall application and infrastructure.

    I know that this isn’t news to many companies and individuals, and that, to some extent, I am preaching to the proverbial choir. For those just climbing onto the DevOps bandwagon, though, or those who may have lost their way and have become frustrated with their DevOps experience, I think it’s important to remind everyone what the benefits of DevOps are supposed to be if you get it right.

    — Tony Bradley

  • 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, DevOps.com, 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 DevOps.com 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 DevOps.com 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 DevOps.com hoping to see you on another DevOps Chat.

    — Alan Shimel