devopsy.kinsta.cloud

Author: Alan Shimel

  • 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

  • The 2016 DevOps Dozen Winners Announced

    The 2016 DevOps Dozen Winners Announced

    In what turned out to be a much bigger job than we anticipated, we have gone through the numbers and checked them twice (actually more like 20 times). All of us here at devopsy.kinsta.cloud are happy and proud to announce the winners of the 2016 DevOps Dozen!

    With thousands of votes cast in just the finals alone, it was a daunting task to verify votes and select the winners in each of the 12 categories for awards this year. Also several of the categories had incredibly close races with just a few votes separating the winners from the other finalists. But there can be only one, winner in each category that is.

    So without further adieu, here are the winners of the 2016 DevOps Dozen awards:

    Best DevOps Open Source Project: Jenkins

    The DevOps world is chock full of great open source projects. Many of them have huge communities who are  very passionate and involved. The Jenkins community holds its own with any of them. More importantly, Jenkins seems to be at the center of the DevOps/CD  world.

    Also congrats are in order for CloudBees who while not managing the Jenkins project do a great job of shepherding and nurturing it.

     

    Best DevOps Commercial Solution: Automic

    Another extremely competitive category with so many great finalists. Automic was the choice of the voters here and I guess to CA Technologies as well, who just closed on the acquisition of Automic last week.

    We can’t move on without acknowledging and congratulating the other finalists in this category as well as the bevy of DevOps tools and tool vendors in the market though.

    Best DevOps Company Executive: Barry Crist, CEO, Chef

    Well deserved recognition for one of the leaders of our industry. I still remember when Barry was first announced as the CEO of Chef, as they embarked on a major rebranding effort, shedding OpsCode and firmly moving to an enterprise solution path.

    Along with CTO Adam Jacob, Chef continues to lead with innovation in both product and go to market. In many ways Chef represents the best of the DevOps community and Barry has a lot to do with that.

    Most Innovative DevOps Solution Provider: Ranger4

    OK I have to admit it, I was pulling for Ranger4 in this category. Helen Beal and Steve Green are great people who were out there evangelizing and leading in DevOps consulting way before the current Cambrian explosion of DevOps consultants we see today. Their DevOps Liftoff Workshop and their latest, DevOps for CEOs, are both high water marks in the industry. Congrats to the entire Ranger4 team.

    Make no mistake though that DevOps consulting is a rapidly growing market with many different solution providers out there. Ranger4 on top of their a first mover advantage continues to blaze a path that others follow.

    Most Innovative DevOps Solution: IBM Bluemix Garage Method

    There is no shortage of innovation in the DevOps space, but what IBM has done with the Bluemix Garage Method is really ingenious. It is not software or hardware, it is not SaaS, it is truly a methodology.

    The method takes IBM’s lessons learned during their own DevOps transformation, combined with tools and processes, to form a complete blueprint that allows organizations to “innovate like a startup, while scaling to the enterprise.”

    Top DevOps Evangelist: Jason Hand, VictorOps

    Again a very close margin of victory here, but a well deserved accolade for evangelist/author Jason Hand of VictorOps.  Luckily, for VictorOps they don’t pay Jason by the mile as it seems he is constantly on the road. I don’t remember the DevOps Days or other DevOps event where I didn’t see Jason there. Somehow in between all of this travel, Jason also found time to write a book, ChatOps.

    We are blessed in the DevOps field to have many worthy recipients for this award, but kudos for Jason for being the people’s choice here.

    Successful DevOps Transformation: Nationwide

    Many of our stories here on devopsy.kinsta.cloud, as well as just about every presentation at Gene Kim’s DevOps Enterprise Summits are about successful DevOps transformations. Name the vertical and there is probably a DevOps transformation story you have heard from one or more organizations in that vertical.

    Nationwide is a DevOps transformation story that we here at devopsy.kinsta.cloud are very familiar with. Primarily through the efforts of Carmen DeArdo who is one of the leaders of that transformation. We have interviewed Carmen a number of times and for me the way Nationwide has rolled out DevOps in a deliberate manner across the organization and still does so today is truly a model to be emulated. Congrats to the Nationwide DevOps team. When it comes to DevOps, “Nationwide is on your side (sorry couldn’t resist).”

    Best New DevOps Solution Company: DBMaestro

    Winning the “rookie of the year” in an industry that is itself still immature is no easy task. There seems to be a new DevOps company coming out of the woodwork everyday. But DBMaestro has managed to stand out from the crowd. Pioneering in the “DevOps for the database” market, DBMaestro has gained attention not just with a great product/service, but also by producing high quality content to help evangelize and educate the DBA market about DevOps.

    Of course the thing about winning best new company is now the pressure is on. We expect big things from DBMaestro going forward. Can’t wait to see what they do for an encore.

    DevOps Transformation Executive of the Year: Angel Diaz, IBM

    Dr. Angel Diaz is a charismatic, dynamic leader at IBM. He is VP of Cloud Architecture and Technology. In that role Angel’s team pioneered IBM’s BlueMix platform. Hearing the story how Bluemix came to be is a great story of innovation and entrepreneurial inspiration.

    Angel and his colleagues were able to move “Big Blue” and teach the elephant to dance by adopting Bluemix. Not just the Bluemix platform, but also such innovations as the Bluemix Garage and the Bluemix Garage Method. Dr. Diaz is not afraid to take chances and innovate to keep IBM at the forefront of technology. This award is well deserved for leading a massive DevOps transformation that has not only made IBM a leader in offering DevOps solutions to market, but also having IBM eat its own DevOps dogfood.

    Best DevOps Presentation of the Year: Better, Faster, and Cheaper. How? by Damon Edwards & John Willis

    Again, how blessed are we in the DevOps space to have such a wealth of great presentations to pick from? Whether they be slides from webinars or video from the many, many conferences around the world, there are some really great presentations that inform and educate us all.

    One presentation stood out among them this year. It happens to be one that I was lucky enough to catch while in London for the 2016 DevOps Enterprise Summit. Damon Edwards and John Willis (who literally had just stepped off a redeye from the US and rushed over from the airport) delivered what I have come to call “2 out of 3 ain’t bad, but why settle”. To me it is the best way to show what the advantages of DevOps. Why you can have both better, faster and cheaper (and might I add more secure).

    Of course Damon and John have been delivering killer DevOps presentations for years now and this is just the latest in the line. Both John and Damon are very deserving of this award and congratulations to them.

    Best DevOps Book/eBook of the Year: The DevOps Handbook, Gene Kim, John Willis, Jez Humble and Patrick Debois

    While there are several great DevOps books that came out last year, one really was in a league of its own. The highly and long anticipated companion/sequel to the Phoenix Project, The DevOps Handbook has lived up to the expectations of the industry. Gene Kim assembled a DevOps superband of rockstars to help him as co-authors and they delivered a great book.

    The DevOps Handbook is a collection of over 40 case studies broken into several categories. It claims to show, “How To Create World-Class Agility, Reliability, & Security in Technology Organizations” and it succeeds on every level. The DevOps Handbook will be a required component of DevOps collections for years to come.

     

    Best devopsy.kinsta.cloud Article of the Year:  5 Things DevOps is NOT by Shelbee Smith-Eigenbrode

    While not the story with the most views, 5 Things DevOps is NOT struck a chord with our readers. It was one of the most widely commented articles of the hundreds of articles we published in 2016. Additionally, it has a long tail in social media with comments on Linked In, Facebook and Twitter as well.

    Shelbee Smith-Eigenbrode hasn’t written a lot of articles for us here at devopsy.kinsta.cloud (hint, hint), but she brings a real life view of DevOps in the field that she has learned in her role at IBM. It is this hands on view that I think allowed her to capture the sentiments in this article that so many identified with.

    Congrats to Shelbee and hope this encourages her and you to consider contributing your own thoughts on DevOps to us here on devopsy.kinsta.cloud. We are always looking for quality content. You can write us at editor@devops.com with your thoughts on contributing your own article of the year.

    Well there you have it. A dozen winners in the 2016 DevOps Dozen awards. Congrats to all of our winners and also congrats to all of our finalists. This was such a strong class of finalists.

    The trophies are already on their way to the winners and we hope to see pics of them on the desks of the winners soon!

    The DevOps Dozen for 2017 nominations will start in August so stay tuned for details if you are interested in throwing your hat in the ring for next year.

    — Alan Shimel

  • 2017 Security Blogger Awards – Open for Voting!

    2017 Security Blogger Awards – Open for Voting!

    It’s another year, and another awards ceremony to come at the Security Blogger Meet-Up at RSA Conference in San Francisco. It’s time to vote for your favorite blogs, which were selected solely by our esteemed influencers: Ericka Chickowski, George Hulme, Kelly Jackson-Higgins (Dark Reading) and Don MacVittie. We are very grateful for their taking the time to support our bloggers and the event. 

    Before you vote (https://www.surveymonkey.com/r/sbn2017), remember a few things from last year:

    • Anyone can vote in the awards. However, a valid email is required and it will be verified. Only one vote per IP
    • Any nominee caught trying to “game the system” will be disqualified. Please try to play by the rules and may the best blog win
    • If you are going to RSA be sure to register for the Rugged DevOps event on Monday at the Moscone Center. Free to anyone with any type of RSA ticket (even just expo pass holders). You can register for the event on the RSA Conference website. Here is a code for a free expo pass, 1U7DEVOPSXP. If you are already registered for RSA, you can reserve a seat here.
    • You can also participate in our “Security @ the Speed of DevOps” survey here.

    Here are our nominees for the 2017 Security Blogger Awards

    Most Entertaining Security Blog

    Most Educational Security Blog

    Best New Security Blog or Podcast

    Best Security Podcast

    Best Blog Post of the Year

    Best Corporate Security Blog

    Please vote today!

    — 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

  • DevSecOps @ RSA Conference 2017

    DevSecOps @ RSA Conference 2017

    One again this year, devopsy.kinsta.cloud, Sonatype and RSA Conference are teaming up to bring a Security/DevOps day of learning and networking to RSA Conference 2017 in San Francisco on February 13, 2017.  The event is DevSecOps @ RSA Conference 2017. Building on the previous two years of great events, this yearsevent promises to be even better. Some of the confirmed speakers are below and you can see for yourself what an amazing array of sessions there are. The best part is attending all of the RSA DevSecOps events are free.

    DevSecOps Sessions

    The line up for DevSecOps includes DevOps and DevSecOps pioneers, John Willis, Damon Edwards, Jez Humble, Dr. Nicole Forsgren, J. Paul Reed, Josh Corman, Shannon Lietz and more. Check out the site page for full details on speakers and topics.

    Attending the full day event (10am to 4pm) is free, but you need to register with RSA Conference. If you are already attending RSA, you need to modify your registration to indicate you are attending DevSecOps (or Rugged DevOps). If you are not already registered you can do so and receive a free expo pass to RSA Conference, which will allow you to register and attend the DevSecOps conference. You can use the code: 1U7DEVOPSXP and register here.

    DevOps Wine-ing (No Whining) Party

    In addition to the full day of amazing speakers, we will host the annual DevOps Wine-ing (no whining) cocktail party, immediately following the sessions. You need to be registered separately for the Wine-ing event. There is a link to the eventbrite registration here.

    The wine-ing event is from 4:30 to 6:30 and should once again be a great time for the security and DevOps tribes to intermingle. A tip of the hat to Josh Corman who is speaking at DevSecOps for starting the DevOps Wine-ing party 4 years ago.

    Security @ the Speed of DevOps Lunch ‘n Learn

    On the following day, Tuesday we will host a lunch-n-learn on the “Security at the Speed of DevOps” report we are co-producing with the Cloud Security Alliance. We will have a panel including George and some leading DevSecOps and Cloud Security experts discussing the findings over lunch at Jillians. Again this event is free but you need to register for it here.

    The report is being written by George Hulme and is based on a survey co-produced and distributed by devopsy.kinsta.cloud and the Cloud Security Alliance. You can participate in the survey (we need your help here, so please do) by taking a few minutes at https://www.surveymonkey.com/r/RSACSADEVOPS. Feel free to tell your friends about it as well.

    security at the speed of devops

    We will be distributing copies of the report at RSA Conference, as well as digitally via devopsy.kinsta.cloud. We will also be distributing several other surprise giveaways at the event as well.

    Yes, this years RSA Conference will feature lots of DevSecOps and you can partake in all of it for free. Of course this wouldn’t be possible without the help of a great bunch of sponsors who have stepped up this year to support the events. In addition to RSA Conference, Sonatype and devopsy.kinsta.cloud, sponsors for the event are:

    Gold Sponsors

    CA Technologies, HPE, White Hat Security, Veracode, Cloud Passage, New Context and Illumio

    Silver Sponsors

    Signal Sciences, Twistlock

    See you on the 13th in San Francisco!

     

    — 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