devopsy.kinsta.cloud

Category: DevOps Chats

  • 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, devopsy.kinsta.cloud 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 devopsy.kinsta.cloud and DevOps Chat. We’ll see you soon on the next DevOps Chat.

    — Alan Shimel

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

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

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

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

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

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

    Peter, Chris, welcome to DevOps Chat.

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

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

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

    Alan Shimel:                And, Chris, how about you?

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

    Alan Shimel:                With scale like in enterprise.

    Chris Lazzaro:           Yep, and meet those enterprise demands.

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

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

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

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

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

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

    Chris Lazzaro:           CRISPR.

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

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

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

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

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

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

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

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

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

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

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

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

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

    Alan Shimel:                Yeah. Chris –

    Chris Lazzaro:           So it’s that –

    Alan Shimel:                I’m sorry; go ahead.

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

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

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

    Peter, agreed?

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

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

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

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

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

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

    Alan Shimel:                Great.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Alan Shimel:                Excellent.

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

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

    Peter Klenk:                March.

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

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

    Alan Shimel:                Yeah, like March 20 to –

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

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

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

    Peter Klenk:                Feedback.

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

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

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

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

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

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

    Peter Klenk:                Shameless.

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

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

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

    Peter Klenk:                Always a pleasure.

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

    — Alan Shimel

  • DevOps Chat: Ken Cheney, Chef on AWS OpsWorks for Chef Automation

    DevOps Chat: Ken Cheney, Chef on AWS OpsWorks for Chef Automation

    devopsy.kinsta.cloud catches up with Chef’s busy CMO Ken Cheney. Ken give us the inside look at AWS’s OpsWorks for Chef Automate. While this is an AWS offering it is based on Chef and is a pretty big bet by AWS on Chef. In addition Ken brings us up to speed (pun intended) on other things regarding Chef. Ken is always a great person to chat with and full of great info. We are going to have Ken on every month or so, we can count on hearing more Chef and DevOps talk soon.

    In the meantime, as usual the streaming audio of our conversation is below and the written transcript of our chat follows. Enjoy!

    Streaming Chat

    Transcript

    Alan Shimel:                Hi, everyone. This is Alan Shimel, devopsy.kinsta.cloud, here for another DevOps Chat. I am happy to be joined in this episode of DevOps Chat by Chef CMO, Ken Cheney.

    Ken, welcome.

    Ken Cheney:                Alan, nice to hear your voice again.

    Alan Shimel:                Nice to hear from you, Ken. Actually, I think the last time you were on our podcast or the last time we spoke you had maybe just been appointed CMO, or maybe it was even before you were appointed CMO at Chef, but it’s certainly been a busy time for you I’m sure.

    Ken Cheney:                Yeah, it has. There’s been a lot going on in the past two months and some of it we’re going to talk about today, the work we’ve been doing with AWS.

    Alan Shimel:                Yeah. I think the last time I spoke to you was right before AWS re:Invent, and there was some big Chef news coming down the pipe that we weren’t able to talk about then. It was still kind of under embargo, but it certainly is fair game now.

    So, Ken, why don’t you share with our audience what was big for Chef at AWS re:Invent?

    Other Great DevOps Chats to listen to:

    DevOps Chat: Nigel Kersten, Puppet, 2017 DevOps Survey
    DevOps Chat: Huw Price, Smart Automation Is Key
    DevOps Chat: InterConnect 2017 w/ Randy Newell, IBM DevOps
    DevOps Chats: Aruna Ravichandran, Co-Author, DevOps for Digital Leaders

    Ken Cheney:                First off, AWS re:Invent, a super-impressive show to go to. So if folks haven’t gone, I’d recommend this next year that they pencil it in. But at re:Invent we announced – actually AWS announced, it’s their offering, a new offering called AWS OpsWorks for Chef Automate. It really brings for the first time the full capabilities of Chef’s commercial platform to AWS as a managed service offering. So they provide support and they backup the offering 100 percent.

    So it’s a new offering that makes that job of configuring, deploying, scaling, both in the cloud as well as on-premise infrastructure simple and secure. We get there by really doing what Chef has done best over the years, which is automating infrastructure as code.

    I think to really highlight what I said, Jassy at re:Invent went out of his way to make the point that hybrid is the new normal in their view. So what’s interesting about what we are doing with AWS is you can manage both in the cloud with AWS as well as your on-premise workloads, and you can have that consistency in how you manage your resources across both.

    Alan Shimel:                Absolutely. Now, Ken, our audience may not be aware, but I happen to have known this, that Chef was sort of the dominant tool in use for AWS customers now for a few years; I mean an outrageous amount. If I’m not mistaken, wasn’t it like 65 or 70 percent of AWS customers who use some CM are using Chef?

    Ken Cheney:                Yes. A large proportion of AWS customers use Chef, and AWS themselves use Chef for many of their core services. It’s a platform that is really well suited to the job of: how do you get your workloads to the cloud, and how do you manage those workloads on an ongoing basis in the cloud?

    Alan Shimel:                Absolutely. And of course, Ken, when we talked about hybrid – I actually had a conversation yesterday, actually with maybe some IBM folks. We were talking about mainframes aren’t going away any time soon, obviously, the mainframe market. It’s probably bigger than ever in terms of dollars.

    But the idea of working with your systems of record and systems of engagement, and one is on a mainframe and one is in the cloud, is becoming more and more the norm for large organizations, right?

    Ken Cheney:                Yeah. It really is.

    Alan Shimel:                Yep. I mean they’re not going to just walk away from billions of dollars invested in mainframes and datacenters, but in order to compete with stuff that lends itself to it, it’s hard to beat the economics of the cloud. So for the foreseeable future anyway, probably the rest of our working lives, Ken, hopefully, hybrid cloud is going to be the dominant form there.

    Ken Cheney:                Right. Then if that is the case, then manageability and that kind of consistency in your manageability becomes front and center, and that’s where Chef plays a big role in being that bridge that really allows you to have a platform where you can store those configurations in one place, where your resources are going to work perfectly every time at scale, and you make changes in that single place and propagate those changes across those environments. So whether you’re running under a mainframe environment or you’re doing dev, test, prod in the cloud you get that repeatability.

    Alan Shimel:                Absolutely. Before we leave the AWS stuff though, Ken, I just want to, for our audience that may be interested, this is available now, today, through the AWS marketplace?

    Ken Cheney:                No. It’s a core AWS offering.

    Alan Shimel:                Okay.

    Ken Cheney:                So if you’re an AWS customer, you login through the AWS console and it’s one of the offerings that you can select. So it bills through AWS. It’s managed by AWS. It’s supported by AWS. So it’s very easy if you’re an AWS customer to get started, and you can get started for free, up to ten nodes for free per month.

    Alan Shimel:                Great.

    Ken Cheney:                Yeah. You can get started and get all those advantages.

    Alan Shimel:                That’s cool. All right, so people can go check it out right now. If you’re using AWS, it’s a core offering. And I guess that kind of makes sense because it is an AWS offering after all, isn’t it?

    Ken Cheney:                That’s right. We’re partnering very heavily with them to make sure it gets the kind of traction and success that we have envisioned.

    Alan Shimel:                You know what? That really is big news, Ken. Great job by the Chef people. Give my kudos to the business development guy. He did a hell of a job there.

    Ken Cheney:                Will do. Thanks, Al.

    Alan Shimel:                Weren’t you the business development guy, Ken?

    Ken Cheney:                I was. I’m weird, so –

    Alan Shimel:                Yeah, I know, just a little inside Chef joke. Ken, we talked a little bit about hybrid cloud and this new offering at AWS. Let’s look at the bigger picture. Here we are in January of 2017 and it’s not too late yet for – where do you see DevOps in 2017? Where do you see Chef in 2017? What big picture item should we be looking at?

    Ken Cheney:                What’s interesting right now in the market is that – you and I both see this, Alan – the market is still very young. I saw some Gartner data where you can extrapolate out that 90 percent of the market is still untouched. Even that 10 percent that has started down the path of adopting is only partially adopting.

    Yet what’s very clear, both at an industry level, if you look at industry data, as well as what we see with our own customers, is that DevOps has a significant impact on the bottom line. Companies that adopt DevOps have been shown again and again to outperform their competitors.

    Alan Shimel:                Yep.

    Ken Cheney:                And I think that DevOps – we’ve been talking about this for some time – but it’s really a full-on move from the early adopters, those organizations who figured out how to be disrupters, to the rest of the market who are being disrupted.

    Alan Shimel:                Yeah. It’s DevOps or die, as I like to say.

    Ken Cheney:                That’s a great statement.

    Alan Shimel:                Yep. Ken, I saw some interesting statistics from a study that CNA had commissioned, 1,700 respondents, and it said something like only 34 percent, so just a third of organizations had adopted DevOps.

    Ken Cheney:                Right.

    Alan Shimel:                Which to me and probably to you too, right, because how many organizations do we talk to that either haven’t adopted DevOps or don’t want to adopt DevOps? We live in a DevOps bubble. We think everyone does, but yet the fact is it’s only about a third, 34 percent. When you look at it that way, it’s barely mainstream, right?

    Ken Cheney:                That’s right. And even those who have adopted it typically adopted it in a small silo.

    Alan Shimel:                Right, the pockets of DevOps, as they call them. I continually refine that, Ken. What I mean by that is you’ll have a team – a team – using DevOps, maybe a team here and a team there, but only when those multiple teams come together under a common DevOps sort of processes, framework, manager, whatever, do I really consider the organization doing DevOps. So for me, an organization that’s doing DevOps is doing it with multiple teams.

    Ken Cheney:                Yeah. I totally agree, and I think this is the year where we start to see organizations really at an executive level begin to put their shoulder into what that means. How do you actually begin to go automated scale?

    And at the same time they’re going through the tech modernization investments around embracing the cloud, embracing microservices, containerization. So I think this is going to be a really interesting year, where I expect many traditional shared services organizations are going to be under a lot of pressure to change.

    Alan Shimel:                I agree 100 percent. It goes back to the DevOps or die thing. All kidding aside, if these organizations don’t change you’re going to start seeing them falling by the wayside.

    But you know what else I think, Ken, and I’m interested in your opinion on this. DevOps tools have to change, too. They have to continue to mature. They have to continue to be enterprise-ready. They have to continue to deliver and meet the challenges that organizations are faced with.

    Ken Cheney:                I totally agree. I think that there’s been a Cambrian explosion of tooling.

    Alan Shimel:                Yes. That’s a great phrase for it, a great way to put it.

    Ken Cheney:                Yeah. And there’s been a rapid kind of organic team level adoption, but what’s happening is that there’s been a lack of standardization, a lack of scale. When you look at the disrupters who have been wildly successful, and many of those are Chef customers, they have been successful automating at scale. Automating at scale means you do drive consistency across the board.

    The path to get there though, from my view, is you have to be thinking about vertical integration. If you look at our strategy, like take what we announced at AWS, that is where we are actually vertically integrating into their platform in a very real, meaningful way. And we feel the same way about the broader ecosystem of _____ capabilities that we need to integrate in with, to make that job of automating at scale easy.

    Alan Shimel:                Yeah, agreed. I do think you’re onto something with that, also vertically integrating, but it’s also integrating into the IT stack. For instance, for me and maybe it’s my own personal bias and history, if you look at 2017 as a year where we have to see security integrating with DevOps and we can call it DevSecOps or Rugged DevOps – I don’t really care what you want to call it – but there has to be that tighter coupling, that tighter integration into the IT stack of security shifting left as part of this DevOps.

    I know Chef obviously has now some history in trying to bring compliance at scale and compliance in security and speed. But I think that has to accelerate.

    Ken Cheney:                Yeah, it does. We are pouring the investment into that set of capabilities. When we look at what our customers are trying to get done, there are things like driving known vulnerabilities down to nothing, being able to remediate in minutes as opposed to days. To get there, that concept of shift left that you put forward is front and center. You have to start thinking about shifting risk to the left.

    So we’ve invested a lot in, one, our InSpec open source framework that people should go check out, as well as the overall compliance capabilities, where you can have broad compliance profiles that ensure that the state of your infrastructure and applications is conforming to policy.

    Alan Shimel:                Got it. You know what, Ken? You mentioned open source and it triggered something. What’s happening with Chef Habitat, anything new you can share with the audience?

    Ken Cheney:                Yes. Chef Habitat has been in the market now for about nine months. We have been seeing a tremendous amount of traction. We’re going to be launching a Habitat road show in a few weeks, visiting multiple cities. So people should go to the Chef website and see if we’re going to be coming to a location near them.

    We are really now moving into the phase where we have large enterprise customers moving workloads into production with Habitat, and they’re really targeting that job of: how do I easily encapsulate my applications and manage those applications, in a way that I don’t have to spend a lot of calories worrying about extraneous services and getting true portability out of it, meaning I can move that application workload anywhere I want?

    So Habitat is definitely getting legs at the moment. We’ve had some new product news that will hit in a couple weeks, Alan, so you and I will be talking about that.

    Alan Shimel:                Fantastic. All right, a little teaser. Ken, to tell you the truth, we’ve gone way over our usual time that we allot for podcasts. We don’t want to take up too much of people’s time, but let me just do a quick recap. For people who want to find out more about Chef Habitat, what’s the URL?

    Ken Cheney:                They go to the website, which is Habitat.sh or they can go to the Chef site, which is Chef.io.

    Alan Shimel:                Right, and it’ll just run through from there and they can find out about the Habitat road show there. The Amazon stuff you can get right through your Amazon portal or dashboard, if you’re an AWS user.

    Ken Cheney:                That’s right. AWS just did a webinar yesterday that was recorded that does a nice walkthrough on it. So they are actively out there promoting it and pushing it for their customers.

    Alan Shimel:                And the open source compliance and security?

    Ken Cheney:                You can get that through the Chef website.

    Alan Shimel:                Also.

    Ken Cheney:                Yep.

    Alan Shimel:                Okay. I just want to make sure people get it, Ken. Ken, we could probably spend hours talking. We’ll have to have you back on soon, maybe in a few weeks when you have your next bit of news. But until then, keep up the great work. Oh, we should mention ChefConf.

    Ken Cheney:                Oh yeah, ChefConf coming up May 20th to 22nd in Austin, Texas. People can go and register today. We’re pretty excited. We just closed the call for papers last night and had a record number of submissions. So it’s going to be a great event.

    Alan Shimel:                Cool. I went last year. It was a great event. I had a great time. It was some great content. The Alaskan Airlines was still my favorite, Ken. Actually it got me to fly Alaskan Airlines watching that guy present.

    Ken Cheney:                It was amazing, yeah.

    Alan Shimel:                It was the first time I ever flew them, and I was counting to see how quickly the door closed and how quickly they opened it, from his whole presentation. It was a great one.

    Anyway, Ken Cheney, CMO Chef, thanks for being our guest on this episode of DevOps Chat. Continued success at Chef and we’ll be watching and listening to find out what’s new.

    Ken Cheney:                Thank you, Alan.

    Alan Shimel:                All right. Okay, everyone, this is Alan Shimel for devopsy.kinsta.cloud and DevOps Chat. Thanks for listening and we’ll see you on our next DevOps Chat.

    — Alan Shimel

  • DevOps Chat: Nigel Kersten, Puppet, 2017 DevOps Survey

    DevOps Chat: Nigel Kersten, Puppet, 2017 DevOps Survey

    I had a chance to sit down recently with Nigel Kersten, chief technical strategist at Puppet. Besides the fancy title, Nigel is one of the smartest, nicest people you will meet. Always a pleasure catching up with him. We spent most of our time speaking about the Puppet 2017 DevOps survey, which is now open right here.

    We also spoke about some of the findings of the past five annual DevOps surveys and the DevOps space in general. Great, informative conversation. As usual, the streaming audio of the our chat is below, followed by a written transcript. But please remember to take the 2017 DevOps Survey. Enjoy!

    Alan Shimel: Hi, everyone, Alan Shimel, editor in chief, devopsy.kinsta.cloud here, for another DevOps Chat, and today’s DevOps Chat guest is none other than Nigel Kersten, chief technical strategist at Puppet. Nigel, welcome back.

    Kersten: Hey, Alan—thank you. It’s great to be back, and always good to talk to you.

    Shimel: Absolutely. Nigel, you know—well, first of all, it’s always great to have you on the show, and we’d love to have you on as often as we possibly can, but specifically today, I wanted to talk a little bit about—it’s that time of year again where Puppet will be launching their, the annual DevOps survey, and I wanted to spend a little time talking about it and cluing our audience in, into what’s in store for this year.

    Kersten: Absolutely. Always happy to talk about the survey. So I think, you know, this has been—we’ve been running this for quite a while now, this is now the sixth year. And I think one of the things that’s really fascinating about the survey is, we survey generally technical practitioners, but also managers as well. But, in the course of surveying all of these practices and technical behaviors and how teams communicate with each other, we end up coming to a bunch of really great conclusions around the actual business outcomes.

    And this is why I think it’s so important for people to be going out and filling out this survey, because I see customer visit after customer visit, every time I’m out there on the road, so many people come up to me and say, “We’ve been trying to change the way we work inside our company, and your surveys turned out to be a really useful tool for handing to our senior management, and saying, ‘This is the sort of outcomes we can expect if you let us work the way we actually want to work.’”

    Shimel: Yes. And you know what, Nigel, just a little bit of a frame of reference, I got the number while I was at Gene’s last DevOps Enterprise Summit in San Francisco, but I was speaking to Nicole, Dr. Nicole Forsgren. What was the total—you may not know—but the total amount of people who have taken this survey at this point over the past five years?

    Kersten: There are actually over 25,000 people, which I think is fantastic, and particularly even in the first few years, we’re definitely really focused on the sort of North American market. We’ve been seeing this growing more and more in Europe, in Asia, and we’re starting to see that, really, DevOps has become a global movement and is being recognized as such within the enterprise, not just sort of the, you know, webscale hacker groups.

    Shimel: Yeah. Well, that’s certainly for sure. And Nigel, this year, is Dr. Nicole—well, they’ve actually started a company now around DevOps statistics and research.

    Kersten: Yeah, so we’ve been working with Dr. Nicole Forsgren and Gene Kim, who many people know from the author of, “The Phoenix Project,” and ex-CTO of Tripwire, and the inimitable Jez Humble, who many people know from his Lean Enterprise and Continuous Delivery books. We’ve been working with them for about the last four or five years and, yeah, this year they’ve formed a new company called DORA—DevOps Research and Assessment—where they go in and help companies do benchmarking around their actual sort of DevOps practices.

    Shimel: Yep.

    Kersten: And so I think that combination of industry experience, great sets of contacts, and really, the statistical rigor that people like Nicole actually bring to this—

    Shimel: Exactly.

    Kersten: —make this to be much, much more than just a vendor survey. Because it’d be easy for us at Puppet to just survey the Puppet user base and come to a bunch of conclusions. But I think the really interesting fact is when we get to talk to people—more people than are just using Puppet, people across the whole industry, some people who are just coming to DevOps for the first time.

    Shimel: Sure.

    Kersten: So I’d really highly encourage anyone who’s listening, you know, go out and fill out the survey when we launch next week, and don’t just feel like, “I don’t really know very much about DevOps, I shouldn’t fill out the survey.” We’re really looking for input from people all across the spectrum.

    Shimel: Absolutely. And of course, Nigel, by the time people hear this, it will be next week, and we will include the URL in the show notes so that people can click right out of this article to the survey.

    Kersten: Excellent.

    Shimel: Nigel, I don’t know if you would know this, even, but is there sort of a shortened URL that people can look for, to go to?

    Kersten: Yeah, we’ll give you a shorter URL by the time we actually launch this podcast out.

    Shimel: Okay. Not a problem. We’ll put that in there. So Nigel, six years in, though, if you’re not moving forward, you’re dying, right? [Laughter] As they say. What’s different about the survey this year?

    Kersten: Yeah, so I think we’ve really shown, over the last few years, that there’s a couple of practices that have really been formalized when it comes to DevOps enterprise adoption. We’ve seen that things like version control being heavily used in operations teams and that infrastructure being shared with your development groups, we’ve seen the role of continuous delivery and lean product management practices. So we really feel that, over the last four or five years, we’ve really shown a bunch of this stuff, that it really isn’t changing very much.

    So we’ve switched focus a little bit this year. So one of the interesting things we’re really looking at are the role of infrastructure architecture patterns in DevOps environments. And I don’t just mean, you know, “Are you adopting containers, are you doing macroservices, service-oriented architecture?” But we’re really looking for information on, architecture-wise, in terms of the way your application is set up, is your team self-sufficient and autonomous? Can you make changes quickly on your own, without lots of dependencies across the organization, and can you experiment really quickly?

    Because I think we’ve seen from Agile and from all of the DevOps enterprise movements over the last few years that the ability to do small tests and iterate quickly on the results of those tests to set your larger direction is really critical to both advancing your service, but doing so quickly and more reliably. Because I think that’s been one of the really huge sort of new things for senior management who haven’t been so familiar with these practices to realize is, adopting DevOps practices doesn’t actually mean sacrificing quality for speed or vice versa. It actually means you’re producing better, high-quality software more quickly.

    Shimel: Absolutely. So, Nigel, as I think you mentioned, this week, or the time people are listening to this, the survey will be open. Just in terms of time frames, how long will it be open and when do you think people might start getting a look at some of the data in the report?

    Kersten: Yeah, so we should be launching later on in the year as far as the results go. We tend to leave it open for at least a few weeks. Some of that sort of depends upon, you know, making sure we get a sufficiently large statistical base to get the conclusions that we’re actually looking for. So, the faster people want to see the results, the faster we want to see them fill out the survey. So, basically, head off and go and do it now.

    Shimel: Right. [Laughter]

    Kersten: As soon as we get that critical mass of data, we’ll be launching the results. So you’ll see us talking about this at Velocity, at the DevOps Enterprise Summits and a bunch of the different events happening.

    Shimel: Oh, I’m sure, I’m sure—looking forward to it. And being written about on devopsy.kinsta.cloud, I might add. [Laughter]

    Kersten: Absolutely.

    Shimel: For sure. So, Nigel, if you were king for the day, you know—

    Kersten: Okay.

    Shimel: —what would you, you know, and you looked into your crystal ball, what would the headlines be from this year’s survey?

    Kersten: If I looked into the crystal ball, what I would really like to see is that we’ve drawn some really strong conclusions around the benefits of DevOps practices in the public sector and in nonprofit organizations, because that’s been a constant source of feedback for the last few years, that we’ve managed to draw really great conclusions for profit-oriented companies.

    But I think we’ve also seen, with the rise of the U.S. Digital Service in the U.S. and .gov.uk that’s been running for quite a long time in the UK and the Digital Transformation Office in Australia—we’re really starting to see some of these practices start to be applied to the public sector. And, honestly, that’s in all of our interests, for government infrastructure to work more efficiently and deliver better services that progress more rapidly to all of us.

    So that’s something I would really, really love to see, that we can draw those conclusions, which I’m feeling pretty optimistic about. But I think the big headline I would like to see, continuing that thread of, “How do we make sure that the survey and the results in the report that we’ve come out with are useful for practitioners selling upwards in their organization, as well as senior leaders trying to implement change?” is—give your teams more autonomy. Make sure that you’re designing your infrastructure in such a way that they can test on their own, that they can rapidly experiment on their own, and that you can actually progress things much, much faster than we’re you’re needing lots and lots of meetings just to create major changes.

    So the more we can actually absorb the lessons of service-oriented architecture, and not just create a mass of complicated services, but create clusters of services that teams can work on with a high degree of autonomy and flexibility. That’s really the headline I would love to see—teams that are able to experiment and are autonomous will produce better results for the business.

    Shimel: Absolutely. Nigel, let me ask—go off on a little bit of another tangent, here. You know, one of the things that I kinda, I find fascinating and I tend to come back to and I get as much of as I can is the Project Blueshift stuff that you guys do at Puppet. Gareth Rushgrove is deeply involved in it. And while, today, you know, there’s certainly a strong container focus on it, it really is about sort of future-proofing Puppet, right, and making sure that the folks at Puppet are aware of, you know, what’s the next big thing coming down.

    What can we look for in the survey that may give us a clue in terms of what is the next big thing and hence, you know, something for Blueshift to be aware of?

    Kersten: Yeah, so I think we’ve generally tried to stay a little bit away from stuff that’s too vendor-specific research for us. But I agree—so you’ve totally captured what Blueshift is about for Puppet. It’s very much about us making sure that, you know, Puppet’s a highly successful project, you know, and used by tens and tens of thousands of companies across the world.

    But we’re in a very fast-changing technology landscape right now and I think it’s really critical for us as a company to make sure that we’re not just resting on our laurels there. We’re seeing lots and lots of things change. It’s entirely possible that, in 10 years’ time, everyone will be on completely serverless infrastructure, so to speak. And, you know, you might have been able to hear my air quotes somewhat around serverless, because there’s always someone’s servers running that code somewhere.

    Shimel: Right. [Laughter]

    Kersten: That old saying that the cloud is just someone else’s server.

    Shimel: Uh huh.

    Kersten: And I think, really critical for us, we’ve seen that Puppet, the language, has been an incredibly portable model. We started off in the UNIX and Linux space, and it’s proven to be hugely successful in the Windows space for a lot of our enterprise customers, and people really like having that common language describing all of your infrastructure. And we see no reason why, just as you’ve seen the Puppet container build stuff that we’ve done, that we can use the Puppet language to describe and compose containers and maintain that audibility.

    We can also describe all sorts of infrastructure, no matter where things come from. So, for us, Blueshift is very much about keeping that eye on the sort of next level horizon over the next six to 24 months, and just seeing what’s emerging and making sure that Puppet stays agile and that we start baking in the features to Puppet the language and the platform that will enable us to all take advantage of those things.

    Shimel: Sure. And I—

    Kersten: I think it’s really exciting. I don’t think we’ve seen infrastructure technology change as fast as this, ever.

    Shimel: It’s crazy. And, you know, I don’t know if it’s the gadget boy in me or, you know, I’ve lived in tech for so long, but it’s that—it’s not even a Puppet thing to me, Nigel, it’s a thing. What is the next thing? I think it’s a little bit of how I got into DevOps, it’s a little bit of how I got into computers and technology to begin with. So I’m always interested and curious.

    Kersten: Totally.

    Shimel: And sometimes, you know, the nice thing about this survey is, it does cast such a wide net of responses that you—

    Kersten: Yeah. And I wanna make sure that people don’t feel too left out as well. Because, you know, I often talk to people who are in big enterprise environments, managing important legacy applications, and some of them are still struggling with getting relatively basic principles adopted—of just using version control, using infrastructure as code.

    Shimel: Mm-hmm.

    Kersten: And sometimes you talk to them and they get a little demoralized, going, “You know, everyone’s talking about all this cool technology out there, and we’re not actually getting to use it.” But I think the reality is, most enterprise environments, the software they’re running is delivering actual business value, and it’s important to keep making sure that’s as efficient as possible.

    We saw from the “DevOps Handbook” that Gene and Jez and all of those people are involved in that you can apply these principles to mainframes, you know? You can see people taking incredibly legacy technology, applying these modern ways of working to them, and getting really, really huge benefits.

    Shimel: Got it, got it. Nigel, we’re almost out of time, unfortunately. You know, we can talk all day, but people only listen, it’s the curse of the modern, you know, the 10-minute or the 10-second sound bite and the 12-minute podcast—but first of all, good luck with this here survey. You know, I encourage anyone listening to go, please click on the link and fill out the survey. Can’t wait to see what some of the results are this year.

    Continued good luck with Puppet, too, as you guys are really, you know, coming out of Puppet Conference and meeting with Sanjay and some of the exec team, I was very excited about the possibilities, and I’m sure you are more than me—

    Kersten: Absolutely.

    Shimel: —about, you know, what’s on the horizon here for Puppet, so good luck with that as well. And thanks for being our guest on DevOps Chat.

    Kersten: No problem, Alan. It’s always great to catch up with you.

    Shimel: Okay, my friend. Nigel Kersten, chief technical strategist at Puppet, thanks for appearing on this DevOps Chat, and thanks for telling us more about the upcoming devops survey, or sixth annual devops survey from Puppet.

    This is Alan Shimel for devopsy.kinsta.cloud. Have a great day.

    — Alan Shimel

  • DevOps Chat: Aruna Ravichandran, Co-Author, DevOps for Digital Leaders

    DevOps Chat: Aruna Ravichandran, Co-Author, DevOps for Digital Leaders

    Our first podcast of 2017 is with Aruna Ravichandran, co-author of DevOps for Digital Leaders. Of course when not authoring books or helping financially challenged but gifted students attend college, Aruna is a VP of DevOps marketing at CA Technologies. I have interviewed Aruna before on DevOps TV and discussed her career that has seen her go from a million lines of code contributor at HP and Juniper to business line executive.

    Aruna is a very interesting person who also has some great things to share. That is why I think you will find not only this DevOps Chat interesting, but her book as well.  Also, we will be doing a full hour Q & A with Aruna on January 17th that you can sign up and attend for free. If you like this interview, don’t miss the webinar. Also, if you would like to download the book you can here: http://www.apress.com/us/book/9781484218419

    In the meantime, as is usual on our DevOps Chats below is a streaming audio of our Chat with the written transcript below. Enjoy!

    Alan Shimel:                Hey everyone, Alan Shimel here with our first DevOps chat of 2017 and we’re lucky to have Aruna Ravichandran, a VP DevOps Marketing at CA Technologies. Aruna welcome.

    Aruna Ravichandran: Thank you Alan. Thanks for actually having me. I’m excited to be here with you.

    Alan Shimel:                Well, you are leading of 2017 so we’re going to set the bar high right away Aruna and hope to live up to it.

    But Aruna, truth be told, we don’t have you on today in your VP of DevOps role: you’re here as Aruna the author today and we’re going to talk about a book that actually came out I guess towards the end of last year but it’s still out there and we’re going to be doing a webinar on it later this month, and I wanted to really talk to you about that a little bit.

    The book is called DevOps for Digital Leaders. Correct?

    Aruna Ravichandran: Yes, that’s correct.

    Alan Shimel:                And why don’t – just from the get-go why don’t you give our listeners a little bit of an overview of what the book is about.

    Aruna Ravichandran: Sounds good. So this book is called DevOps for Digital Leaders, it’s all about how one can reignite their business with a modern DevOps-enabled software factory. I embarked on this journey on writing this book almost about a year-and-a-half ago along with two of my co-authors Karen Taylor as well as Peter Waterhouse.

    We looked at all the different books within the market – there is no dearth for books in the market when you think about DevOps – but what we saw was that even though there are so many different books in the market nothing really talks about some of the pain points which we constantly encounter customers asking us when we talk to them.

    Some of the pain points which customers constantly ask us are, “I want to be able to start this journey called DevOps. How do I start? What should my journey be? Where can I start? How do I develop? What should be my maturity model?” And so that’s one question which we constantly get across the board.

    Second pain point which we have heard from customers is, “How do I actually measure the success of DevOps? What kind of metrics can I use? How is success actually going to look like which I can report back to my management chain that whatever initiative I have embarked on with DevOps is now actually successful?”

    So we talked to several – over 100-plus customers – we learned from their experiences on what metrics are actually used and what is actually built practically in the industry and shared those in the form of use cases as well as actual metrics in the book.

    So the book primarily focuses on DevOps adoption in terms of a journey as well as what are some of the key metrics one can actually use in order to embrace DevOps.

    Alan Shimel:                Great. Aruna you hit on a couple things that are kind of near and dear to me. One is something that I’ve spoken about and talked to people now for a while which is too many people – you know, DevOps is so hyped and so many people are positioning DevOps to be, you know, it’s this great, white unicorn that’s crapping out rainbows for everyone but it doesn’t always work like that, right?

    There are failures, there are challenges, there are hurdles, and not everyone who just wants to do DevOps can wave a magic wand and become a DevOps factory or a modern software factory. So I’m glad to hear that this is kind of something that you guys are exposing in the book.

    The other thing is, you know, in almost three years of doing devopsy.kinsta.cloud now I find that our listeners, our readers learn the most from listening to how their peers have dealt with stuff: so case studies, case scenarios and these kinds of things. So the fact that you had access to hundreds – literally hundreds if not thousands – of customers who CA Technologies – CA has worked with – really gives us some great insight.

    Can you give our listeners a little bit of a taste for the kind of – I know you call them case scenarios – and they’re kind of case studies, right? – can you give us a little flavor for what those are like?

    Aruna Ravichandran: Yeah, absolutely. So if you look at the book it’s organized across the entire software factory. Let’s say if you think about customer deployments DevOps basically goes all the way down from planning to requirements to development, testing, release, and then into operations.

    And so what we did was we talked to – we interviewed several different practitioners who are existing CA customers, sometimes we even talk to non-CA customers – understood the role DevOps plays in terms of culture and collaboration as well as the toolsets which they’re actually leveraging in order to implement DevOps within their companies.

    And we looked at – we _____ the use cases around the whole software delivery to the chain. So if you look at the book – even though we talked with several thousand customers – you know, we couldn’t basically put all those case studies within the book, so what we did was we broke up the book across the entire software delivery chain and there is a chapter dedicated for every aspect of the software factory starting from planning to development to testing to release to operation and we leveraged one customer example on how they actually implemented DevOps best practices along with the underlying toolset and what are some of the metrics or the results they actually got in terms of being able to show what success actually looks like.

    Alan Shimel:                Got it. So Aruna I wanted to touch on another aspect of DevOps adoption that you hit on in the book, and that is the idea that not everyone started their DevOps journey at the same time or are going at the same speed or at the same rate, right? Some organizations are relatively mature in their DevOps adoption and DevOps practices: others are still talking about starting. So is there something for everyone in the book or do you need to be sort of on-your-way DevOps expert to really get value?

    Aruna Ravichandran: No. So, you know, like I said because we knew that there is no clear-cut framework, right – like if you think about I-_____ there is a very prescriptive framework in terms of where you can actually start and how you can actually end. With DevOps one can start many different ways.

    So what we actually did was we looked at some of the best practices a lot of the customers have actually implemented and built a framework in terms of a maturity model and we shared that as best practices.

    So if you think about accelerating the maturity we talk about, you know, three different examples of how customers could actually start. The first way is to basically build an end-to-end release management system; and the second one is to how can you operationalize with feedback loops going all the way from Dev to Ops and vice versa.

    And the last one is how could you actually optimize the continuity stability pipeline?

    So we shared some of the best practices in terms of where one can actually start and how they can actually modify their processes to give them a lifecycle regardless of where they want to start. They could start in Dev and end in Ops; they could start with Ops and make changes to Dev. But we shared some of the best practices in terms of maturity model which customers can actually implement.

    Alan Shimel:                Excellent. Aruna, again, we only have 12 minutes or so on these podcasts but we’re going to spend about an hour – 45 minutes plus 15 minutes in questions – on an interactive Q&A webcast with you on this subject.

    And I just wanted to, in our remaining time here, remind everyone or let everyone know that the webinar is scheduled for January 17th – so about two weeks from today or so – a little less than two weeks – at 2:00 PM Eastern Time. And within these show notes – if you’re listening to this on Sound Cloud or iTunes – within the show notes there we’ll have a link to the webinar. And if you’re reading along or listening on devopsy.kinsta.cloud we’ll have a link to the registration there as well. You can get to the registration on devopsy.kinsta.cloud – go to the webinar section and of course it will be listed there.

    But importantly Aruna I wanted to mention the book itself is free, correct, for download?

    Aruna Ravichandran: So the software version of the book is free. If they want to get the hardcopy they can buy it through Amazon or through our publisher which is Apress. I also want to call out and say that if they buy a hardcopy version of the book we are donating all the proceeds – the royalty from the book are being donated to a nonprofit corps Foundation of Excellence – the Foundation of Excellence’s mission is to award university scholarships for exceptionally talented but economically underprivileged high school graduates in India in order to embrace stem carriers.

    And so they can either go through the softcopy of the book or they can download the hardcopy and that all of their contributions are going to be donated to the nonprofit.

    Alan Shimel:                That’s great Aruna. Fantastic. I also want to mention that for those who register and attend our webinar we are going to give out ten signed copies – signed by Aruna and her co-authors – to ten folks who attend the webinar. I have to mention that those are US-based folks only as the logistics of mailing hardcopy books make it prohibitive to send them across the oceans. But ten US attendees will win signed copies of the book and everyone who attends will get a link to download the soft version, and of course you can buy the hardcopy version – the hard-book version on Amazon or Apress. Again, we can register that at devopsy.kinsta.cloud.

    Aruna, we’re almost here at the end but just to give some of the people – some of our listeners a little tease of what we’ve got going on. I know there’s some CA-sponsored DevOps research that’s due out shortly and that kind of reinforce this idea that organizations that do DevOps are doing better. Can you give us a preview or you’re not allowed yet?

    Aruna Ravichandran: I can give a little bit of preview. But what I can say is we did our research with one of our analyst vendors and partners with over 1,200 participants around DevOps and what I can say is that 87 percent of DevOps adopters have reported an improvement in customer experience.

    There is a lot of rich statistics which we uncovered as a result of that particular survey and we will be able to share the results from that particular survey report on January 11.

    Alan Shimel:                Great. Maybe we can speak about it a little bit on the webinar for January 17 as well – or incorporate it into –

    Aruna Ravichandran: Absolutely we will.

    Alan Shimel:                That sounds great. Well, Aruna, we certainly look forward to the webinar on January 17, but more, you know, as importantly, congratulations on authoring or co-authoring what sounds like a great book, and kudos actually for your donating the proceeds of the book to a worthy cause: I think it says a lot about who you are and what are the kind of reasons behind that, so thank you.

    Anything else before we wrap up?

    Aruna Ravichandran: Nope. I’m very excited to partner with you in order to share our experiences around writing this book and the journey, and hope that this book will be insightful for all of our DevOps practitioners who are embarking or are already on their way within DevOps.

    Alan Shimel:                Okay. Well, Aruna Ravichandran, co-author of DevOps for Digital Leaders, thank you so much for appearing on this episode of DevOps chats and we look forward to our interactive Q&A webinar on January 17 at 2:00 PM with you to continue our discussion. Thank you.

    Aruna Ravichandran: Thank you Alan.

    Alan Shimel:                Thank you. This is Alan Shimel for devopsy.kinsta.cloud and we’ll see you soon on another DevOps chat.

    — Alan Shimel

  • DevOps Chat: Huw Price, Smart Automation Is Key

    DevOps Chat: Huw Price, Smart Automation Is Key

    Before the new year, I had a chance to sit down and chat with Huw Price, Vice President, Application Delivery, CA Technologies. Given Huw’s title what do you think we spoke about? You guessed it, automation. Actually there is more to it than that. Automation for automation’s sake alone is not necessarily a good thing. As Huw points out, smart automation is key.

    Huw and I will be participating in a full webinar on the topic of Smart Automation and how to build it on January 24th. You can register for this free webinar here.

    As usual with our DevOps Chats, below is a streaming audio player with our interview and below that is a transcript of our conversation. Enjoy!

    Alan Shimel:                Hi, everyone, it’s Alan Shimel, Editor in Chief at devopsy.kinsta.cloud here for another DevOps chat. Today’s guest on DevOps Chat is Huw Price of CA Technologies. Huw, welcome to DevOps Chat.

    Huw Price:                  Hi, Alan, nice to be here.

    Alan Shimel:                Nice to have you here, Huw. Huw, if you wouldn’t mind, if you could give our audience a little bit – I said you worked at CA, but what’s your title and what are you responsible for over at CA?

    Huw Price:                  Yeah, I’m a VP at CA. I was the managing director of Grid Tools, which venture you may have heard of, where we specialized in all things test data, and laterally we moved into all things test case optimization and into test automation. My role at CA – I’m kind of an evangelist QA specialist practitioner, and it’s actually fitting quite well with the DevOps land of trying to improve quality whilst improving speed at the same time, which is a bit of a magic trick. But it can be done and it needs some new thinking.

    I would say that over the years, it used to be cost was the top driver for businesses, but now due to the pressure of business, it’s all about competition and it’s all about getting stuff to market quickly, and you can’t have poor quality code going out to customers because they’ll just move to someone else. And I think that’s really what’s kind of driving a lot of our thinking at CA at the moment.

    Alan Shimel:                Absolutely, and it is somewhat counterintuitive when they tell you you could go faster but have higher quality. And I’ll even throw one more improbably into it – and be more secure by doing that.

    Huw Price:                  Yeah, that’s an interesting area. I think actually what I’m finding now is that I’m a big fan of doing everything in parallel, the days of sequentially waiting for one team to hand stuff off to the other, and what we’re finding is things like performance testing and security testing are kind of job one, and you need to build those in almost as functional requirements as you’re designing your software really. That sort of hopping from one piece of functionality or requirement to another seems to have vanished. It’s all hands to the pump I think at the moment is what I’m finding out there.

    Alan Shimel:                It is a bit of a Chinese fire drill, as they say. But out of chaos comes order, and that’s kind of the good news. Working with you and your team we’re actually doing a webinar after the New Year, in January, and it’s titled “How To Build the Right Automation.” And you and I were talking a little bit offline, of course, and the idea that you just automate for automation’s sake, maybe that was a couple years ago, but now we’re trying to be smarter about designing what’s to be automated and how we do it. Can you share with our audience a little bit of maybe your insight into that?

    Huw Price:                  Yeah, I think so. Automation’s got a bit of a bad press, and to be honest, I think rightly so, it’s considered very fragile. You only need a small change, a pop-up appearing on a screen, some kind of slight delay in a network and some of the automation breaks. And then everyone looks for the results and you spend days and days actually finding out that the program is fine or the functionality is fine, but it was actually the automation script that was wrong. That’s the first problem.

    And the other one is the time it takes to build the automation in that it’s not uncommon for automation to be built three months after a sprint is finished, which of course means you’re automating something that doesn’t exist any more, which is not very continuous. And the value of what you’re actually doing is pretty poor. I think that is kind of the backdrop of where people have been.

    They’ve moved towards test-driven development, behavior-driven development etcetera, but they still have the problem that actually maintaining the automation scripts, even if they’re key word or Gherkin, it’s still an issue. Because, you know, requirements don’t exist any more, just change requests exist, and a change request means you’ve got to go back through all of your existing automation and say, “Do I have to change all these automation scripts, which ones do I change, which ones are duplicates, which ones make no sense?” And that is a massive amount of work.

    I’ll just give one example. There was a bank in Canada, and basically for every single requirement change, they would go through every automation script by hand to see if it needed to be changed. So one change request took one tester all day to see if it impacted any existing automation scripts. So that’s just one change request. So how many testers do you have, how many automation guys do you need, how many change requests can you fit through that very narrow pipe. I think that’s where people, even with some of the new techniques – and I’ve got to say that the automation frameworks are becoming better. They’re becoming more structured; they’re becoming more malleable key word based. But they still don’t really address the problem of if I make a change to a requirement how quickly can I update my automation framework.

    Alan Shimel:                Excellent.  Huw, I want to talk to you a little bit about the go to market with your group. You’re obviously probably dealing with mostly large enterprises, how does a large enterprise realize they have this problem? Is the problem one where, “Geez, we need help automating,” and they haven’t even cut across the threshold of “we need to be smarter about automation” because they’re still at just the “we need automation.” Or is it organizations who have already, let’s say, dabbled with automation and are now realizing, “Wait a second, this is just a giant cluster waste of time.”

    Huw Price:                  Yeah.

    Alan Shimel:                “And we need help being smarter about automation.”

    Huw Price:                  I think the answer is yes to all of them. Even within the same organization – and I can think of one we’re dealing with at the moment – you get such a sort of disparate set of skill sets, capabilities, maturity models, and quite often we’ll go into a large company and introduce teams to each other and say, “Do you realize you have a really nice sort of key word driven framework sitting over here with a very clear object library, which you’ve got all this work and you’re going off and building yet another selenium framework, maybe you guys should talk to each other.” I just find that we do a lot of sort of introducing companies to other people in the same company.

    Alan Shimel:                Sort of like matchmaking, huh? Matchmaking all that stuff. Interesting.

    Huw Price:                  I’d like to add on that, certainly what I do and members of my team and other people in the business are doing, we are genuinely hunting for best practice here. This is not about us selling software any more, the market is moving so quickly and this ability to be a sort of lightening rod of best practice amongst other companies, genuinely it’s quite fun and we’re enjoying it, and we do share around what we’re finding out in the market in terms of what’s good, what people are struggling with, and hopefully we’re bringing not just software to the market, it’s more some best practice thinking as well, and I think that’s quite interesting.

    I’ve got to say that chatting with you when we met in Vegas, I learned a couple of things from you. And I find that when I talk to pretty much everyone. And I’m trying to feed that back, whether that’s by webinars or with the direction of how we build the software. We’re trying to just keep pushing the boundaries, keep communicating, keep thinking. It’s kind of fun. We’re really enjoying it at the moment.

    Alan Shimel:                Absolutely. I always tell people these are interesting times to be in the IT world, there’s just so much change happening – and change I think in a good way. New tools and trends and ways of doing things, it is fun, it really is fun.

    Huw Price:                  I’m going to take a slight tangent here. I was listening to an agile coach talking and I agreed with 80 percent of what he said, and disagreed with 20 percent. But then I challenged him and said, “Can you tell quickly whether an agile team is good or bad?” And he said, “If they’re having fun, that’s generally good.” And I know everyone is into hero culture at the moment, charging around trying to get the release out the door at the last minute. That’s what we’re trying to focus on is move away from the hero culture and actually getting that fun back into – you know – solving challenging problems and automating as much as possible and joining stuff up and getting feedback loops going and all that kind of fun things. So it is, as you say, very interesting times.

    Alan Shimel:                Sure. Steve, let me ask you a – and I’m not being facetious but a real question – can we have too much automation?

    Huw Price:                  Actually, that’s interesting. I did a presentation at Star West and I talked about risk based testing. It’s actually kind of touched on an interesting subject here. The reality is, if you have a very stable system and you’ve got a bunch of very experienced programmers, you know, you run it through a code quality engine and it’s very solid and stable, and they also understand all of the data that flows in and out of it – the reality is that actually you might need a very minimal amount of automation to test that.

    If you’ve got something which is highly, highly active – I’ll mention an Indian company, they’ve got one API which brings in 150,000 new customers a day. That API, I mean, that is staggering. 150,000. This is to do with the 4G rollout across India. That API, you know, I would be automating the hell out of that. I would have so many automation scripts around that. I would have docker images spun up in every different direction, I would have visualization wrapped around it, I would have negative testing up the wazoo, so that if you make a change – performance testing, blaze meet up, whatever it takes, to make sure that that baby, when you make the slightest change, you don’t mess with it — because if it’s down for ten minutes, that’s 5,000 customers. So I think people maybe should start thinking a little more sort of holistically and higher up in terms of the different levels of risk associated with it. I think that’s one thing.

    So I think that’s one thing, and then the other one is the speed at which you can automate. The reality is that what we do, we will generate – we’re very much into building a model of what the system should do. You could potentially build all your automation scripts before you’ve actually built the application. I was doing some work with Eggplant the other day and we actually generated a whole bunch of Eggplant scripts based off a Microsoft PowerPoint of what the system should do. So in other words, before the developers started, we’ve actually created the automation framework.

    Now, if that takes 15 minutes, great. If it took 3 days, then it’s a little bit of a tradeoff. So I think this balancing things up based on risk, and also the technology that you have to hand, is probably the two criteria you should start thinking about.

    Alan Shimel:                Agreed, agreed. Steve, as I had told you offline, the time here goes incredibly quick and we’re coming up on our 15-minute outside limit. I just wanted to bring you back home to the webinar in wrapping up. I believe our webinar is scheduled for in the latter half of January, and it is called “How To Build the Right Automation.” For people who are listening right now, give me two or three points why they really should make it their business to attend the webinar.

    Huw Price:                  I think firstly they’ve got to understand what they’re automating. If you look at most automation scripts, you’re probably only covering about five percent of the functionality. We would look to automatically generate 85 to 90 percent of the functionality of the system in either the same time or less time, so I think that’s firstly. To really understand coverage, I think that’s important.

    The other one then is to think about that actually automation is not just about the scripts themselves, it’s about getting the right test data and the right – I’m going to use the phrase visualization, whether that’s service visualization or message visualization or sort of network visualization or visualization environments. So trying to create an environment such that your automation is actually testing the bit that you really want to test. If you think of an end to end test, to get to something like a share trade close where you might have 200 functional logic gates I need to test, is actually really difficult, because you’ve got to have all of the right bits around your automation to make sure that you’re testing the right stuff.

    So better automation in terms of the design and also the assets around the automation to make sure that you’re actually testing the correct stuff. I think that’s probably what I’m going to focus on during the webinar.

    Alan Shimel:                Got it, got it. Well, obviously on devopsy.kinsta.cloud we’ll be publishing links to the registration page for people who want to join us on that webinar. It sounds like it could be – it sounds like it could be a great one if folks are interested.

    Huw Price:                  And it’s lots of demos. I’ll do a couple of slides, but I prefer to do demos.

    Alan Shimel:                Oh, that’s greatest.

    Alan Shimel:                Yeah, most techies love to see stuff.

    Huw Price:                  Actually, we’ll drive right in here.

    Alan Shimel:                They’ll give you a slide, but anything beyond that they’re just like, “Show me stuff, show me stuff.”

    Huw Price:                  All right, so let’s stay tuned to devopsy.kinsta.cloud. I would imagine we’ll probably have the landing page up within the next week or two as we head into the holidays.

    Alan Shimel:                Well, Huw price, I’m going to ask you one last question – not a curveball or anything, but I usually ask a lot of our guests this – for our audience listening, one book that you would highly, highly recommend they read.

    Huw Price:                  Actually there’s a book called Model Based Testing. What we’re discovering is that people are now moving pretty much – they’re realizing that without a model it’s very difficult to proceed. And there’s a book called, it’s actually an adjunct book to the Model Based Testing Course. We’re massing this out to our customers now to kind of reset their thinking. Everything we do in life is a model, everyone’s making decision gates, logic gates, risk based profiles, and this is going down really well. People are really taking the time to read it. What I’ll do is during the webinar I’ll put up the pages so people can go and get it. I can’t remember the exact title. It’s called Model Based Testing – The Course Guide, or something like that. But I highly recommend that.

    Alan Shimel:                Excellent. Huw Price, thank you so much for being our guest on this episode of DevOps Chats.

    Huw Price:                  Oh, it’s a pleasure.

    Alan Shimel:                Thank you, it was our pleasure and we look forward to the upcoming webinar, “How to Build the Right Automation,” including demos, and we’ll have more information on that. And we hope to have you back on DevOps Chat soon, Huw.

    Huw Price:                  Great, all the best. Thanks so much.

    Alan Shimel:                All right. This is Alan Shimel for devopsy.kinsta.cloud and DevOps Chat. Thanks very much, everyone, and we’ll see you on the next DevOps Chats.

    — Alan Shimel

  • DevOps Chat: Jeff Schaeffer, CA Technologies, on Everything Continuous

    DevOps Chat: Jeff Schaeffer, CA Technologies, on Everything Continuous

    I recently had a chance to sit down with Jeff Schaeffer, senior vice president and general manager of Continuous Delivery and DevOps Business Unit at CA Technologies. I have interviewed Jeff before, most recently at Jenkins World, where we did a video on our DevOpsTV YouTube channel. Jeff is a great interview who always gives good insight into what CA’s and his views of the dynamics shaping the DevOps market are.

    Jeff and I had a chance to talk about the launch of the new CD neighborhood sponsored by CA Technologies. Specifically, we discussed how CD—and, for that matter, the whole idea of continuous IT—is reshaping the way organizations do business. It is a great conversation that I hope you will enjoy.

    Below is a streaming audio of our DevOps Chat and below that is the transcript of our conversation.

    Alan Shimel: Hi, everyone. This is Alan Shimel, editor in chief, devopsy.kinsta.cloud, here for another DevOps Chat. Today’s DevOps Chat guest is Jeff Schaeffer, who is responsible for CA Technologies’ continuous delivery CD business.

    Jeff, welcome to DevOps Chat.

    Schaeffer: Thank you, Alan. Glad to be here today.

    Shimel: Good to have you here. Jeff, of course, I think the last time you and I spoke was at—it was at the Jenkins World event, and we had a chance to actually sit down on video and talk a little bit about, you know, where do you see the market, where you see the DevOps market going, what CA’s involvements are and where you guys are kind of placing your bets and moving your pieces around as this market continues to evolve.

    And we were, of course, talking offline before we started today’s podcast about kind of how you view the different waves, if you will, of maturation of companies’ life cycles with software and so forth, and you mentioned third wave, fourth wave.

    I’d love, if you don’t mind, if we could share a little bit of that context with our audience in terms of your view of the historical ebb and flow here of history, if you will, of where we are. So would you mind sharing that?

    Schaeffer: Thanks, Alan. So, Alan, as we were discussing, our—the thesis and the drivers for continuous delivery actually start kind of in the history of technology, and it’s probably never been a more exciting time for any of us to actually be involved in application development and technology in general as it’s transforming all the markets.

    And the history is useful to the extent that it helps us understand the future as well, and when we think about it, you know, we’re really in the midst of the third wave, in which businesses have disruptively adopted technology in the business.

    The first wave was back in the 1960s and it was really about the mainframes and the digitization of the paper processes in the company. I mean, it was a process disruption.

    The second wave was in the ‘90s, and it was really about ERP and CRM systems where we were automating the supply chains of companies, and again, it was a process disruption.

    Today we’re in the third wave, around the application economy, and in the context of digital transformation and the app company, you know, companies today, they promote their brands, their products, their services through their web and their mobile applications, and it’s become the primary methodology by which they engage their end users. And it is actually underpinning and enabling business model disruption, which is very different than the prior two waves of disruption.

    So when we look at it, it’s an entirely new business model. We’re all familiar with the majority of those in terms of, for example, Uber disrupting transportation and Netflix disrupting media, et cetera.

    And one of the challenges about the third wave is that—following the third wave, actually, I think is the fourth wave, and the fourth wave is gonna be around systems of insight and engagement, by which companies are able to take all of the multitude of data that they’re generating in terms of every interaction with their end consumers—you know, with suppliers and providers—and be able to analyze those data sets’ multivariate analysis and derive deep insights, and to be able to then, in turn, customize their offerings. Companies would be able to use that data to make more of the right decisions more often, to drive efficiencies, et cetera.

    And so naturally, the fourth wave—and it’s coming, but before we can actually fully benefit from the fourth wave, we actually still need to master the third wave. And in the context of the third wave, the app economy, it’s really about, how do you get these applications, these web or mobile applications into the hands of end consumers more quickly and, you know, great quality and at lower cost and factor of production.

    And so that’s really the area where companies today are focused. And, to do that, what most companies are doing is, they’re adopting agile methodologies, right? They have to increase their competitiveness and their ability to deliver this custom software. So they look to get development up to velocity, so they’re adopting agile methodologies, and then they quickly realized that the rest of the value streams are not at velocity—so testing, release, operations—which then leads them to adopt DevOps, which is where we’re gonna have a great conversation today.

    And, with DevOps, they start to adopt the culture and the practices, and then realize they need a new enabling tool chain, and so if you think about any technological disruption and being a function of organization and people being a function of process and being a function of tools and technology, they now adopted a new tool chain, which is the continuous delivery tool chain.

    And that’s an area where we at CA are focused about how do we provide the coaching around the organizational transformation and the practices in the process transformation and then, you know, from a product perspective, we’re building the next generation tool chains, building block fashions, and bringing those to market to support companies’ transformation and competitiveness in the application economy.

    Shimel: Perfect. And you know what, Jeff, that actually dovetails into, of course, just today, we announced on devopsy.kinsta.cloud that we’ve added a new CD—or continuous delivery—Neighborhood, which CA has graciously sponsored. And we’re really looking to build this into a—I don’t want to use the word portal, it’s so 1999—but a destination where people can come and get some great content and some great education around this whole CD tool chain and the CD economy, if you will, that is growing up.

    But, you know, Jeff, going back to what you were talking about, we can’t get to the fourth wave until, I think, the third wave is a little bit more solidified and a little bit more mature, a little bit more settled. In my mind, what we’re seeing is, a lot of these convergent circles starting to overlap, right? You mentioned agile, we mentioned CD, we mentioned things like API, right, which is another big area for CA.

    Schaeffer: Yes.

    Shimel: And, you know, they’re not totally independent of each other, nor are they totally dependent on each other, but you know, they kind of form the ultimate Venn diagram where the overlap is just marvelous, right? I mean, it’s just a wondrous time to be in business if you’re using—you know, you’re leveraging all of these things.

    You know, and you’ve been around, Jeff, as I have—what do you see with that?

    Schaeffer: Yeah, so Alan—exciting things, exciting things. So, a couple of quick comments, one on the Continuous Delivery Neighborhood—really excited for that. Alan, I can tell you that in that context, whenever I meet with peers across the industry, one of the things that comes out very broadly today is, there’s a big gap between conceptualization of things like agile, DevOps, and continuous delivery, and translating those into real world practice.

    Shimel: Mm-hmm.

    Schaeffer: And the opportunity to provide that education, to provide a journey to share examples of how people have adopted these and succeeded is gonna become absolutely instrumental in terms of unlocking the full potential of these methodologies and these concepts and deriving the business benefit.

    So we’re really excited with what devopsy.kinsta.cloud is doing with respect to the educational exercise, and also devopsy.kinsta.cloud and that sponsorship of the DevOps Express Consortium, which is another multi-vendor body that’s focused on this translation of concept of real world practice, and of course, here at CA, we’re happy to be a founding member of DevOps Express as well as a sponsoring member here for devopsy.kinsta.cloud and the CD Neighborhood.

    The second thing is, when we look at the change in the continuous delivery tool chains, what we’re finding is, as companies adopt agile, they start looking to have—okay, what is the prescription of the next generation software factor, software life cycle, and as they look at continuous integration to continuous test, continuous release and deployment and continuous operations, you know, how do you string these building blocks together?

    And the only way to reduce the cycle times is making both a process change but also the tooling change. And the tooling is very different today versus, say, some of the legacy providers of application development and testing tools. It’s all pragmatic, API driven, so that it’s fully automatable. There’s a lot more—as you were describing the intersection and the Venn diagrams, it’s really a function of the feedback loops. So how do I take data, for example, from operations and use that to make a smarter example in continuous testing?

    Let me share an example of what we mean by that. So, if you have a mobile application, you know, mobile application is much more difficult to manage in production than, say, a web app. First, people simply don’t update their smartphones that often, and so you end up with a long tail of versions in production environments.

    Shimel: Mm-hmm.

    Schaeffer: They’re running on different operating systems—iOS or Android and different versions of the operating systems. They’re running on different hardware platforms like an iPhone 4 or an iPhone 7, Galaxy 7. They’re running across different carriers, and there’s over 700 different carriers worldwide. And it becomes a factoral problem, and it’s unlikely that any given testing team has the ability to model that many combinations—because it’s a factoral problem—to model that many combinations in their test matrix.

    But, if you have operating data, and you know that 80 percent of the user base is on these five to seven combinations, then you can provide that data back to the QA team and proactively test those combinations and take your risk in the tail of where people have more infrequently completed combos. But, by the same token, if you can detect failures in operations, you can provide that same data back to dev, and they can focus their investigative research as they work on the current product engineering.

    So when we think about the Venn diagrams and how all of that works together in the future, it’s—not only are the format factors of the tools changing, but the feedback loops become absolutely essential in order to fully automate and to systematically improve the software life cycle process. And so, a really exciting time.

    And we’ll often hear that today, this idea of shift left and shift right, but it’s really a—you know, those things embody, that vocabulary embodies a number of concepts. One is, you know, how do I push activities earlier and earlier into the development process under shift left, so how do I incorporate, say, for example, performance testing early, and then how do I tie performance testing into operational testing, and how do I provide that feedback loop all the way back?

    So just exciting times, lots of transformational changes, and people are definitely looking for prescription and methods as how to reconfigure their software life cycles and incorporate that into their current software development methodologies, and that’s what, I think, DevOpsExpress.com will be so good at is helping provide that center of knowledge and best practices for the betterment of the industry.

    Shimel: Absolutely. Jeff, believe it or not, we’re almost up at time, but I wanted to—and I don’t mean to embarrass you, but I want you not to be shy here. CA has done a masterful job of amassing, developing—both holistically, acquisitions, et cetera—a play in this new third wave, fourth wave economy, if you will.

    Schaeffer: Absolutely.

    Shimel: Give our audience—again, don’t be shy. Why do you think CA is best situated to really leverage what’s happening out there right now?

    Schaeffer: Wow, great question, Alan. So, two, maybe three key points on that. So number one, Clayton Christensen, who is a professor at the Harvard Business School, he’s written extensively on the concept of disruption and then disruptive innovation in the market. And one of the key things that you learn about, or learn from Clayton, is that the incumbents never survive the disruption. And it’s not because they’re—you know, it’s just because of their decision making and how they’re driven by their paradigm.

    And CA, uniquely, is in a position as a company to invest in this next generation of continuous delivery capabilities. And so we’ve been putting together this next gen tool chain through a combination of organic product development as well as acquisition, and so we’re uniquely in that position in the market in terms of being a vendor of sufficient size to provide that consolidated next generation tool chain and to ensure it works together. Per kinda the research of the market and industries over time, you know, we’re in a unique position relative to the traditional incumbents and I’m excited.

    You know, we’ve pulled together the Rally Software, which brings kind of market leading agile management capabilities into the portfolio and we start with the planning process and agile management. We realize that, in the application economy driving the automation, that oftentimes in the app economy, the API is the application, but that’s also the primary means by which we exchange data and are able to integrate or automate all of the functions as well as create the next generation architectures, which are all kind of composite applications built on microservices which work through APIs.

    So we’re connected by the APIs, and so we’ve invested in their seven and brought in a really robust API management capability, and then we are laser focused in the continuous delivery space. So, how do we take and orchestrate release with release automation software and release automation continuous delivery addition, which is basically harvesting the data and providing the analytics so that we can systematically improve and continuously improve the software development life cycle.

    And then, beyond that, we have a number of kind of the next generation continuous testing tools. So, everything in terms of, we just recently acquired BlazeMeter. It’s a fantastic capability and at the heart of continuous testing. You know, it’s a commercialization of open source projects, JMeter and Taurus, which allows us to automate any open source testing tool, whether it’s the JMeter testing, which is the second most widely adopted community developed testing product, or Selenium, which is the most widely adopted testing product. Gatling, Locust, et cetera, so a host of open source testing engines.

    We add value above and beyond that. It’s all hosted in the cloud and deploys both in public and private clouds for the tests themselves, and so it’s highly automated, it’s very scalable, and it allows us to left shift the testing all the way into the integrated testing, the component testing, and the unit testing of the new life cycle processes.

    We also have put together a number of tools that improve testing efficiency around test data management, so how you can’t automate your tests unless you automate the test data, and providing test data with the right sort of attributes in order to drive the tests in a productive way. We have service virtualization software, which allows us to simulate test environments, and to emulate the test environments and abstract away things like mainframes or databases, which allows for both parallelized development. When other components aren’t available, we can simulate those or emulate them, and then in the testing practice itself, we’re able to isolate applications and put them under load testing in an effective way.

    All the way out into our operational tools, where we’re able to shift right, and provide kind of the—you know, what’s done in pre-prod gets used in production, how do we get the integration and the feedback loops back into the testing and the development processes.

    And so we’ve really been focused on putting together that next gen toolset around continuous integration, continuous testing, continuous release and deployment, and continuous operations. And again, we’re in a unique position to do it. We’re unique in the fact that it’s a disruption within the market and we’re able to put together this tool chain, and we’ve made a lot of progress in developing that tool chain up ‘til now. And we’re finding companies like—the people we’re working with across the industry adopting the CA tool chains, you know, we’re finding some significant improvements in not only the velocity but the quality and the cost effectiveness of their software development practices.

    So, for example, companies that were getting one release out every year are now able to do 30,000 deployments per month on 300 applications in both the test, the pre-prod and the prod environments. We’re able to significantly reduce the cost of handling data and increase the automation of testing, up international the 85, 95 percent range, lowering the costs and achieving ROIs, in some cases, of over 300 percent in paybacks on the investment measured in months—you know, two to three months, which is very unusual around what people would normally expect in an enterprise software vendor.

    So we’re really excited with the difference we’re making in the lives of our customers—the operating benefits, the business benefits, and then the overall, you know, the impact that we’re gonna make in the industry as a whole.

    Shimel: Fantastic. Hey, Jeff, we’re way over time. I apologize, here. I apologize to—well, I’m not apologizing to those listening, I think they’ll find it worthwhile. But we do try to keep these at 10 to 15 minutes, and we’ve gone over—but I think it was worthwhile, we had a lot of information to share.

    Jeff, continued success in leading up the CD business at CA Technologies, and we’re looking forward to more exciting news soon, and we’re actually looking forward to the CD Neighborhood on devopsy.kinsta.cloud really becoming a go-to place for people looking for information around it. So thanks very much on the sponsorship for that as well.

    We’ll be in touch again, soon. Until next time, I hope you stay well. Jeff Schaeffer, he runs the CD business at CA Technologies—thanks for being our guest on this episode of DevOps Chat.

    Schaeffer: Thank you, Alan.

    Shimel: Thank you. This is Alan Shimel for devopsy.kinsta.cloud, and we’ll see you again on another DevOps Chat.

    — Alan Shimel

  • DevOps Chat: Lucas Carlson, VP Strategy, Automic, Can Ops Thrive In DevOps?

    DevOps Chat: Lucas Carlson, VP Strategy, Automic, Can Ops Thrive In DevOps?

    In this DevOps Chat our guest is Lucas Carlson, newly appointed VP of Strategy at Automic. Of course, Lucas has already had a distinguished career. Here is his bio from Linkedin:

    Lucas Carlson is an author, entrepreneur and executive. He also has a background of 20 years of programming to back it all up.

    He’s written scalable software that has been downloaded millions of times and used by millions of users. As a keynote speaker in the technology arena and innovation leader in the cloud space, Lucas helps companies discover opportunities for growth.

    Lucas wrote a bestselling book on Ruby for O’Reilly called The Ruby Cookbook and has created over a dozen open source libraries, some of which have been downloaded almost a million times.

    Lucas was formerly the CEO and founder of AppFog, a massively popular DevOps startup acquired by CenturyLink in 2013. AppFog signed up more than 100,000 developers, raised nearly $10M in venture funding and has become an industry leading Platform-as-a-Service.

    Before following his passion and writing books, Lucas served as the Chief Innovation Officer for CenturyLink, in charge of building next-generation Docker and Linux Container products for a $20B company.

    Lucas also writes for major tech and entrepreneur publications including Inc, Business Insider, InfoWorld and InformationWeek.

    I spoke with Lucas about why he joined Automic. Our discussion proved to be a provocative one, in which we explored Lucas’s view that DevOps is not a great thing for Ops. Ops needs its “own DevOps” that is more geared to its challenges and world view. Of course, many thought that DevOps is just that. Before you comment, have a listen to our conversation to see what Lucas said. I am interested in your thoughts and comments on this.

    Alan Shimel: Hi, everyone. Alan Shimel, editor of devopsy.kinsta.cloud here for another DevOps Chat. Very happy to be joined in this DevOps Chat by VP of Strategy at Automic Lucas Carlson. Lucas, welcome.

    Lucas Carlson: Thank you so much. Glad to be here.

    Shimel: Thank you. Lucas, I know you’ve been at Automic now, what, about two or three months?

    Carlson: Yep.

    Shimel: But I’ve known Lucas Carlson for years before Automic and I don’t know if our audience is familiar with you, but you’ve had quite a storied career already at a relatively young age.

    Carlson: Thank you. Yeah.

    Shimel: Why don’t you give our listeners a little bit of the Lucas Carlson story.

    Carlson: Sure. Well, I started out as a programmer: for 20 years I wrote code. I started code when I was in elementary school and ever since I’ve been writing code. And I wrote two programming books during my career. I’ve mainly focused on the open-source side of things so Ruby, PHP, Python worlds.

    And then I started a platform-as-a-service startup about seven years ago and I used Cloud Foundry as the foundation for my startup and it was called AppFog. We signed up 100,000 developers, it was a lot of fun. It was a great time.

    We were acquired by a telco and it was really interesting to spend a few years inside of a telco and watching them attempting a digital transformation—trying to move their applications into the cloud was a very interesting story.

    And after that I quit that job, I moved to Paris for a while—it was a life dream of ours—moved my family, and after Paris I looked around for what to do next and this opportunity came at Automic, and I thought it was a very interesting opportunity for reasons we might get into.

    Shimel: Great. Great. And of course, you know, interesting with your background and accomplishments Lucas that Atomic, which is an automation company, is where you wound up and as VP of Strategy there.

    So as someone who was a chief strategy officer at the last company I co-founded, Lucas, I can appreciate the title of VP of Strategy. But for our listeners who are saying, “Well, that sounds like just another corporate title,” give them a little insight. What’s your role as VP of Strategy at Atomic?

    Carlson: Yeah. Well, my role is to take a company that’s been around for almost 30 years that’s had a product that is battle tested, been around the block, really works, works at scale, has thousands upon thousands of enterprise scale customers, has a lot of pedigree and DNA, and yet is a company nobody’s heard of.

    That’s actually why I kind of joined. I thought it was a really interesting challenge to take a company that nobody’s heard of yet has had a product that is—has stood the test of time, is very, very robust, very strong, and see if there wasn’t a way to kind of help that company get recognized for the work that they do, which is actually really great work.

    And so I joined the company with that kind of concept in mind. And it’s been very interesting because fundamentally when I came into the company they called themselves a DevOps company and I come from a background—I’ve been doing DevOps for a long time. I grew up around Portland, I hung out with Luke Kaines who founded Puppet and he was one of my mentors when I was building AppFog and—so I knew DevOps inside and out. I used DevOps to build my own startup.

    And so I came in and I looked at what Automic had and Automic has a very interesting, strong product, but it’s not DevOps, because DevOps is predominantly—you know, having grown up around it I know you know DevOps is not some mystical union of developers and operations into this perfect combination that can do both and is just as adept at writing Ruby as they are debugging MySQL.

    You know, that’s kind of a story—a fairytale that people like to tell, but it’s not the truth. The truth is, DevOps was created by developers for developers to get around operations. They were sick and tired of waiting for operations to get around to provisioning their SQL server so they wrote some code that did it for them.

    They were tired of kind of the delays and lags so they wrote code that got around it. It wasn’t really meant to create this mystical union it was really meant to bypass operations.

    So, I guess, how does that apply to Automic? So, Automic came in saying they were DevOps—they weren’t a tool for developers and yet I thought they have this long track record. They’re doing something right, but what is it?

    And I spent a lot of time thinking about that before I joined and when I joined I became convinced that there is a huge part of the DevOps story that is getting left out: it’s getting forgotten, it is getting sidelined and ignored that doesn’t deserve to be ignored.

    I think that DevOps isn’t enough on its own. Having run a platforms and service company myself, having put platform as a service into major name-brand banks, having seen people trying to adopt these DevOps technologies—what I’m seeing over and over again is that one of the biggest struggles about DevOps is a myth that I’m trying to shatter. And the myth is that DevOps doesn’t need operations: that DevOps outsources operations, that operations isn’t necessary for DevOps.

    In fact, I think the absolute opposite is true and I don’t think ops is becoming part of dev. I think that ops deserves its own practices equivalent to what DevOps brought to developers. Equivalent and yet different, because I think that fundamentally operations was a different world of developers: always will, always has.

    To developers, failing fast is important and breaking stuff is totally acceptable. And going iteratively is great. So if you write some code, it doesn’t work you can fix it really quickly because you failed fast and it makes it better. And that kind of iterative approach is something that works really, really well for developers but it does not translate for operations. Operations cannot fail fast. If you fail in operations and your database goes down in production, that could be millions upon millions of dollars lost for the business.

    So it’s not that operations doesn’t want speed—of course they want speed, it’s just that speed is not the primary. For developers, speed is primary; for operations, reliability, robustness, scalability trumps speed. It’s not that they don’t want speed, it’s that they have a different core value set—a different world view—and instead of trying to mush these things together, instead of making them one idealized person that’s never going to exist, what I say is, let’s raise up the ops side of DevOps, bring it to the same level that developers have been raised. When developers adopted DevOps practices, it raised them up to a new level as a power-up—it was a mushroom in Mario. And what we need is to give the ops side a mushroom.

    We need ops to level up and be able to play at the same level as developers, but with tools built for operations, not built for developers.

    The tools out there for developers in DevOps are not the right tools for operations in DevOps and that’s what –

    Shimel: Hold on, I’m going to stop here because I’ve got to jump in—I’m sorry—I’ve been biting my tongue.

    So this is actually a pretty—I don’t want to say radical, but a very different kind of view of DevOps and what goes on between dev and ops than I think we hear from most people.

    And it actually reminds me I had a conversation—actually a DevOps Chat—with Dave West, who is the CEO of Scrum.org. And you know, obviously, Scrum and part of Agile is really aimed at developers. And though he saw sort of a potential bridge from dev to ops he had a similar view of yours that, you know, we have tools that are written for developers that developers are using that are letting them get more involved in ops but how much is ops really being involved in this DevOps, if you will.

    But yet, you know, let’s look—like configuration management tools.

    Carlson: Yep.

    Shimel: Do you think those are dev tools not ops tools?

    Carlson: Yep, I absolutely do.

    Shimel: Absolutely. And –

    Carlson: I could go into that more but I think it’s self-evident. I think that developers use those tools vastly more than operations. I think that the reasons are obvious. The tools were built for developers by developers.

    Operations looks at the world through a different lens; they use a different way of approaching the same problems and they kind of—the way that configuration management works embraces a development mindset.

    Shimel: Okay, fair enough. Let me ask—so how does this, Lucas, play into Automic and their future toolset? Will we –

    Carlson: Well, I joined Automic specifically because I saw this as the biggest problem in DevOps today and that Automic has solutions on the ops side of DevOps. Automic’s solutions are the level-up for ops teams. They don’t say—like one of my biggest pet peeves right now is this rip-and-replace mentality. You see it … with Mesosphere, with Docker containers, with Cloud Foundry, with OpenShift. All the big vendors out, there they all have the same promise: “Take everything you’ve done, throw it away, import all of your applications into our platform that will do it all for you and it will solve all your problems.”

    Well, I’m sorry, but that’s just not going to happen. Those platforms are generally underdeveloped, undertested at scale, they are a brand new way of managing applications that is untested. They don’t embrace the vast majority of enterprise scale applications architectures. They basically force you to rip and replace. And rip and replace is not just a thing for the code it’s a thing for all the IT processes that have been known to work for the last 10, 15, 20 years.

    So you’re trading a potential promise for a solution to all your problems, but the risks are exponential and vastly untested. So this whole concept of rip and replace I think is very, very dangerous in our industry today and very prevalent.

    And I joined Automic because their approach is to embrace what already exists and make it better. Instead of saying, “We’re going to have a new platform for you to import all your apps to,” they have a way to describe the topology of your existing infrastructure and built on top of that and automate that instead of throwing it out and replacing with something new.

    And so, I think to me, it really levels up the ops side of DevOps—it makes operations a hero, the co-hero of the DevOps story. It doesn’t deny operations their vital role.

    Shimel: Excellent. Excellent. You know what? Lucas, I’d love to see this at a Speak—you’ve got to submit to Speak about this somewhere.

    Carlson: Yeah, for sure.

    Shimel: Or, maybe we can do a webinar and get into it because honestly, our DevOps chat format being just 15 minutes doesn’t give us enough time to really delve in here and I’d love to get a counterview of these things too and let’s really have a discussion around it. I think I’m going to take that as my job. I’m going to go find someone and we’ll go back and forth on this.

    But unfortunately we are just about out of time—we’re at 15 minutes already. As I said, it goes quickly.

    Carlson: No problem.

    Shimel: This has been a very interesting discussion. I would call it truly an ignite or a fire starter in that you’ve opened the door here and we’re not finished with this one Lucas. We’re going to come back to it.

    Carlson: Sounds good.

    Shimel: But for now we’re going to call it a wrap. I hope if you’re listening to this you found the conversation interesting. Of course on devopsy.kinsta.cloud you’ll also see a written transcript of the conversation so you can hold Lucas to his words here and it’s going to be in writing.

    And if you have any questions, comments, feel free to also put them on devopsy.kinsta.cloud we’ll get them out to Lucas, and as I said we’re going to try to continue this discussion at a later date.

    But for now Lucas Carlson, VP of Strategy Automic. Thank you so much for really kind of blowing the doors up today on this and we look forward to seeing what the follow-up’s going to be. And success at the new position.

    Carlson: Thank you so much. I’m very happy to be here.

    Shimel: Thank you. Yeah, no, it’s a great company. We’ve worked with Automic for some time and I’ve met a lot of great people there.

    Anyway, that’s a wrap for this edition of DevOps Chat. Lucas Carlson from Automic was our guest and this is Alan Shimel for devopsy.kinsta.cloud. We’ll see you at the next DevOps Chat. Thanks everyone, have a great day.

    — Alan Shimel

  • DevOps Chat: InterConnect 2017 w/ Randy Newell, IBM DevOps

    DevOps Chat: InterConnect 2017 w/ Randy Newell, IBM DevOps

    In this episode of DevOps Chats we are again joined by Randy Newell, Director World Wide Marketing for DevOps. Randy had a bunch of news he wanted to share with us including the call for speakers for IBM’s InterConnect 2017 which is open until November 11th. Randy also gave us a preview of the IBM sessions at the upcoming DevOps Enterprise Summit.

    Randy always has some good news and point of views to share. This interview is no different. Enjoy!

    As usual the streaming file is below with a printed transcript below:

    Alan Shimel:                Hey, everyone. Alan Shimel for another DevOps Chat. Happy to be joined on this episode by Randy Newell, Director Worldwide DevOps Marketing for IBM and a friend of mine. Randy, welcome to DevOps Chat.

    Randy Newell:             Thanks, Alan. Good to be here.

    Alan Shimel:                Absolutely. Randy, I invited you on because it’s getting near that time of year again where we’re ramping up for IBM Interconnect and I know you and your team have spent – have already invested weeks if not months of man hours and blood, sweat and tears in getting Interconnect ready to rock for this year. Why don’t you give our audience some highlights?

    Randy Newell:             Okay, sure. Yeah, I mean this is absolutely the most exciting time of the year for a number of reasons. I mean we’re getting ready for Interconnect, which we’ll talk about. We’ve got really key events in the DevOps space like the DevOps Enterprise Summit. Gartner puts on a big applications strategies event in December and so forth, so this is absolutely, you know, my favorite time of the year.

    I think the – kind of the cool thing that’s hot right now is we have just gone live with the call for speakers for IBM Interconnect 2017. That event is March 19th to the 23rd in Las Vegas. Last year we had, you know, over 20,000 attendees. Next year, this coming year, we’ll be even bigger. So it’ll be over 24,000 attendees.

    Alan Shimel:                Wow.

    Randy Newell:             Yeah. Where we ended up last year – and you were there, Alan. I mean the – it’s exciting, it’s a big conference. DevOps is a major piece of what happens at this bigger conference that has, you know, cloud and cognitive and mobile going on as well, but the DevOps piece itself I think was almost 250 sessions last year, labs, workshops, sessions, and I think one of the big things that we’re doing this year is actually bolstering the ops side of this thing. So we’ll have over 300 sessions and labs and workshops this year with a really good balance across the DevOps lifecycle, if you will, and we’re pretty excited about it.

    Alan Shimel:                Yeah. Sounds great, Randy. Randy, I – you know, you mentioned the call for speakers. If I’m – I happened to take a look. I believe the call for speakers is open through November 11th, correct?

    Randy Newell:             Yep. We’ve just opened it up in the last week so now through November 11th, you know, we’d encourage everybody to get their proposals in. I mean if it’s not something that you want to speak at we would obviously encourage you to attend the event anyway but would encourage, you know, a lot of the subject matter experts and thought leaders that pay attention to devopsy.kinsta.cloud to submit papers to this. It is – you know, if people have not attended before or watched online, you know, just thinking about some of the highlights from last year, and you interviewed [laughs] so many of these people –

    Alan Shimel:                Yeah.

    Randy Newell:             – you know, Lloyds with Mark Howell and John LaFreniere at Hertz, Topo Pal who is a Cap One fellow from Capital One, Nationwide with Carmen DeArdo and just some really super innovative smaller companies like Security First Insurance, Ben Bomhoff, who I know you interviewed

    Alan Shimel:                Yeah.

    Randy Newell:             – and, you know, it just keeps going. Presentations from a lot of our cool business partners like Datical and Blue Agility and PointSource, so it’s really high quality presentation content from organizations big and small who have figured out DevOps and are scaling it and getting, you know, real success out of it, and then I think we’re also drilling down from an IBM perspective to provide labs and workshops and so forth to really get deep into some of the sever system tools that we’re providing.

    Alan Shimel:                You got some good hands-on stuff. Randy, for those who might be listening and saying, “Geez, I’d – you know, I’d like to throw my hat in, I’d like to speak,” what are you looking for in not only speakers, obviously, but in subject matter?

    Randy Newell:             Well, I think it’s actually an interesting topic for this year because I think we’re really expanding what we want to see. I think kind of standard fare, but we want to continue to push on these areas because we’re pushing the envelope on what we’re seeing clients able to achieve, you know, areas of continuous delivery, application release automation, software test automation including things like API testing and virtualization, but I would underscore and expand some of the areas on the ops side, especially where we’re looking for application performance management, IT ops management, IT ops analytics, and then I think especially kind of where we’re come over the last year with the introduction of the garage method as well as what we’ll be doing between now and Interconnect around tool chains. I think those are areas that are particularly exciting for us to see new presentation proposals on, so we’d really encourage some of those topics.

    Alan Shimel:             Yep. And I’ll just mention – ’cause, Randy, as I mentioned to you offline, I myself am submitting a speaking proposal. What’s nice is you can submit basically a one-man speaking proposal, you could submit a panel or anything in between there, so there’s lots of options and also if you go and register or to submit you will see – I think you guys did a great job of kind of guiding people what area you’re proposed session deals with so that it can be categorized and put in there and, you know, kind of so you could pick the best of the best, right, within an existing –

    Alan Shimel:                Yeah, there’s a –

    Randy Newell:             – subject matter.

    Randy Newell:                – lot of prompting, you’ve got a lot of prompting. So if people are going about doing this go to – you know, I mean the easiest way is just to search on IBM Interconnect 2017 call for speakers, and when you get into the tool just take a look. There’s two main topic areas where we’ll find the DevOps stuff. It’s listed directly under hybrid and DevOps and then also under Bluemix and Softlayer there’s DevOps as well. There’s an awful lot of prompts under the hybrid category for some of the topics that I just reeled off in addition to a whole bunch of others and don’t stop there. I mean people should have some fun with this; what they’re challenged with, where they’re seeing successes. I mean we want to push the envelope a bit on the type of topics that we’re seeing.

    Alan Shimel:                Sure. And Randy, just as an aside, it’s not all DevOps all the time – well, actually it is all DevOps all the time for me anyway, but IBM Interconnect also – like last year, for instance – cognitive and Watson and some of the really good kind of gee whiz kind of stuff that IBM’s working on is also on full display at Interconnect.

    Randy Newell:             Absolutely. Yeah, there’s a whole – as you’re aware, we did the whole _____ arena which is a lot of hands-on to be able to play with brand new capabilities, Watson APIs, [laughs] a foosball table that’s hooked up live to a Bluemix application. I mean there’s just – there’s so much kind of exciting stuff to do and it is – you know, while I think we lead with Interconnect as our key presentation of our cloud capabilities, we’re so integrated, you know, within IBM that you will see how that plays out in collaboration with Watson capabilities. We’ll see representation of our systems group and, you know, representation of Z mainframe technology. We’ll see mobile capabilities.

    It really is a great display. And I think it’s actually – in the industry, it’s probably pretty unique in the fact that – I mean historically Interconnect represents many different conferences coming together that IBM offered, and so you have a slice of the IT organization and now kind of increasingly bringing in line of business representatives and so forth so you’ve got – for me anyway, looking at it from a DevOps perspective, you’ve got dev, you’ve got ops, you’ve got your business owners, you’ve got everyone attending, you’ve got practitioners that are attending, you’ve got architects. It’s really a neat opportunity and I think when organizations are evaluating their attendance at Interconnect, you know, it’s really – the interesting part of it is we can bring a large organization and there is deep content for all parts as you drill down and get technical and there are also very interesting subjects for the organization as a whole, so it’s a very broad and deep context from an IT perspective.

    Alan Shimel:                Excellent. And Randy, for those who maybe don’t want to – you know, are not planning on speaking or presenting but would like to still attend, of course it’s open to anyone, right?

    Randy Newell:             Absolutely.

    Alan Shimel:                You can buy tickets. I mean, again, I would just probably Google search IBM Interconnect 2017. And Randy, the dates – I know you moved it later in March this year. Just again for our audience.

    Randy Newell:             Yep. It’s March 19th to the 23rd in Las Vegas –

    Alan Shimel:                Perfect.

    Randy Newell:             – at the MGM Grand and Mandalay Bay.

    Alan Shimel:                And Mandalay Bay, yep. That’s a big show. But Randy, that’s not the only conference IBM DevOps is kind of really exerting a strong presence. We have the Gene Kim’s DevOps Enterprise Summit coming up around Election Day, November – I think it’s 5th, 6th, 7th, perhaps in San Francisco.

    Randy Newell:             We will be out there on Election Day, yes. So all attendees make sure you do your absentee vote before you go unless you’re in the Bay Area. [Laughs] 

    Alan Shimel:                Yeah. Exactly. But you guys have kind of an all-star lineup and a bunch of different activities lined up for that week. Why don’t you just give us a quick preview, if you don’t mind.

    Randy Newell:             Sure. So DevOps Enterprise Summit, you know, this is Gene Kim’s lead event and it’s November 7th to 9th in San Francisco. IBM’s a platinum sponsor, there’s a lot of great sponsors. It’s an exciting event and so we’re really looking forward to it. I think it’s – you know, the content especially is very well curated and I think a lot of the success stories that are brought forward are really in tune with kind of the frontend of what’s happening with DevOps where organizations are achieving scale and real results, so I think in that case it’s particularly exciting among the many DevOps events that are out there. We’ve put together I think a really interesting set of presentations, and I’ll click through them real quickly here. I think one that’s particularly exciting is we call it adopting DevOps at scale, lessons learned at NBCUniversal, Kaiser and GitHub and IBM. So Sanjeev Sharma, who you’ve interviewed a number of times –

    Alan Shimel:                Sure.

    Randy Newell:             – he’s an IBM distinguished engineer and the author of DevOps for Dummies is going to kind of host that panel, and on that panel we’ve got John Comas from NBCUniversal, Raghu Raman from Kaiser,  and we’ll also represent some of what we’ve been doing inside at IBM where we’re about – you know, we’re kind of well into our DevOps transformation. We’ve got about 40,000 developers that are in the process of transforming to a DevOps approach and we’re through about 10,000 of those and a lot of that learning we’ll be bringing forward as part of this presentation. So the idea is, you know, how do we use that time that we’ve got in that particular session to really show off three or four very significant organizations that have been able to achieve some scale? And I think what Gene has represented as kind of the horses, but you know, the more typical, big, complex enterprise organization and how they can succeed at both, you know, the two-pizza team and scale it all the way up to, you know, kind of enterprise adoption.

    Alan Shimel:                Sure. You know what, Randy, I wanted to just mention – you mentioned Raghunath Raman from Kaiser Permanente and actually he and another fellow who I interviewed at Interconnect last year, John LaFreniere – I probably butchered John’s name, I apologize, I’m better with Indian names than French names but… [Laughs]

    Randy Newell:             Well, just say John’s name with a French accent and you’ll get by.

    Alan Shimel:                John from Hertz, doing an amazing transformation there. I have both Raghunath and John on a webinar. I think it’s on November 29th, so this’ll be after DevOps Enterprise Summit, but we’re gonna talk about, you know, transformations and checking in – both of these gentlemen, Raghunath and John have really done some pretty cool stuff with, as you say – you know, or as Gene says horses, right? Not unicorns but large organizations and especially the Hertz one, Randy.

    It’s kind of just an out with the old and in with the new kind of transformation and a little unusual where Raghunath I think has gone more of a traditional transformation, but he’s also pushed the needle a heck of a lot there. So for those – the audience out there, November 29th is that webinar on devopsy.kinsta.cloud. You can register online. Highly, highly recommend that one. Randy, I think there’s some news around Bluemix garage method around for Gene’s event as well or no?

    Randy Newell:             Yeah, definitely. And so let me – and let me tell you that there’s a couple of sessions, additional sessions at DevOps Enterprise Summit where we’ll be showing some of that off. So one is adapting the squad model with Ann Marie Fred, at – and she’s an IBMer – and she’ll talk about some of the transformation that we’ve done internally at IBM. So that’s an exciting one. And then, of course, you know Rosalind Radcliffe.

    She’s co presenting with Rich Jackson from Walmart and that is a mainframe DevOps team savings of the day at Walmart. So there’s a number of really interesting presentations. We’re also running a series of lightening talks, demos, in our booth area and we’ll publish a schedule. So for people who are attending that particular conference, you know, look for a theater presentation for what we’ll be doing in the booth, we’ll be driving down into some key offerings like method and tool chain into urban code into test automation, Bluemix, et cetera. So that can be a lot of fun, and then of course, encourage people to attend the overall conference and we’ll be highlighting these other presentations that we just talked about.

    But you asked about, you know, kind of methods and tool chains and I – you know, for those of your listeners and readers who may have missed it, last year at Gene’s conference we introduced the Bluemix garage method – we refer to it just generally as a method – and as I indicated earlier, we’re kind of, you know, a CIO-level endorsed movement, transformation to DevOps inside of IBM. We’ve got, you know, over 40,000 developers. We’re about 10,000 developers into this material transformation which impacts process and tooling and underlying infrastructure technology and methods that we’re using, and we’ve harvested a lot of the learnings from this significant transformation as well as what we do through global services, client interactions and codified that into a methodology, and so, you know, people can go to http://www.ibm.com/devops/method or just Google Bluemix garage method. And what you’ll find is we’ve populated this with elements of the methodology.

    What’s evolved since we announced this thing is we’re now rolling in reference architectures, a concept of tracks, you know, syncing with online courseware, the idea being, you know, as we’ve dealt with both transforming ourselves and as we see our clients adopting DevOps some of the challenges are how do we take the success of that two-pizza team where you have focused on business outcomes and technical outcomes and then scale that. And some of the challenges are cultural, some of them are process-related, some of them are tools-related, and so that’s a lot of what’s gone into the methodology, and so these tracks are somewhat – are basically use case-oriented. I am building, you know, some bimodal or multispeed application, I’m building a cloud native application, I’m building a mobile app, those sorts of things, and it surrounds you with elements of the methodology, of reference architectures, and now we’re moving towards this introduction of tool chain.

    And the tool chain concept is really cool and people will find it especially cool coming from IBM, is because based on that use case that you select, the specific tool chain, you will be prompted with a set of services that sit on Bluemix, which is our cloud platform, and it’s a mix of both IBM services as well as third party services that represent the key elements and key services that you need in your tool chain for the particular use case. So if you’re, you know, selecting a – you know, let’s say a simple cloud native application it would prompt you on, you know, GitHub and a WebIDE and our delivery pipeline service from IBM and you literally click a button that says, you know, build this tool chain for me and it instantiates that, provisions it and integrates those tools and presents it to you as your dashboard on Bluemix and all of that takes, you know, a couple of minutes. So the idea is that through method reference architecture tool chain you have the ability to spin it very rapidly and then some guidance and architectures for actually how to move forward and how to scale, and so that’s kind of it. And I know you’ve spent some time with Rachel and so forth who’s, you know, directly involved with the garage method and kind of expanding this thing in conjunction with how we’re using it in the Bluemix garages and really seeing some pretty exciting response to it.

    I think some of the customer’s names that we’ve mentioned earlier as well as others, you know, have seen some of this stuff firsthand and benefited from it, so we’re looking forward to gaining some commentary on that. It’s part of the reason that we’ve brought the GitHub team into the presentation that we’re doing at DevOps Enterprise Summit, because I think they’ve seen firsthand how the IBM transformation has actually utilized GitHub Enterprise, which is taking all the benefit of GitHub and using that within the Enterprise firewall through GitHub Enterprise and we have that instantiated as a, you know, full Bluemix service. So it’s pretty exciting execution.

    Alan Shimel:                Cool. Randy, we have gone significantly over our allotted time here. I apologize. I didn’t want to interrupt you and I think our audience finds it – will find it useful and informative, but I – for those of you who are still listening at the end of our interview, I thank you very much for staying with us and I think it was worth your time and I certainly hope so. Well, Randy, we’re gonna have to call it a wrap on this version of DevOps Chats. Perhaps we’ll have you back on if we have time before Enterprise –DevOps Enterprise Summit, but if not I’m sure we’ll have you back on before IBM Interconnect in March, maybe once we have some more information on speaker selected and stuff we can review some highlights.

    Randy Newell:             Yep. Fantastic. Appreciate the time, Alan. This was great.

    Alan Shimel:                Not a problem. Randy Newell, Worldwide Marketing – Director Worldwide Marketing for DevOps IBM. Thanks for being this segment’s guest on DevOps Chat and continued success and good luck. We’ll see you San Francisco I guess next for Gene Kim’s DevOps Enterprise Summit. Until then, this is Alan Shimel of devopsy.kinsta.cloud. Thanks for listening and we’ll see you on another DevOps chat.

    — Alan Shimel

  • DevOps Chat: DevOps & CD with Tim Butel, XebiaLabs

    DevOps Chat: DevOps & CD with Tim Butel, XebiaLabs

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    [Laughter]

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

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

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

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

    Shimel: Well, Gene is a metric nut.

    Buntel: That’s right.

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

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

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

    — Alan Shimel