devopsy.kinsta.cloud

Category: Features

  • It Is Not All Choice and Speed in DevOps

    It Is Not All Choice and Speed in DevOps

    One of the stumbling blocks starting to show in the agile/DevOps world is that speed of delivery and developer choice are asserting themselves as the primary worthy goals.

    I’m a developer. I have that “look what I did” attitude when I tackle a particularly tough problem and I love it when an environment lets me choose a toolset that helps me achieve my goals faster (or lets me play with tools I have been eyeing for a while). I want to solve problems quickly, and have no issue with stand-ups to show my progress.

    Creative Commons Attribution: winnifredxoxo, flicker
    http://www.flickr.com/photos/61056899@N06/

    But we’ve lost sight of the whole longevity issue, and far too many of us have lost sight of the whole “necessary restrictions” thing, too, which is related. The security environment did not change just because your team went to DevOps with Agile, and what must be supported to keep your cool app up and running didn’t change—at least it didn’t change conceptually. And that’s where we start seeing issues.

    Lori and I were talking this morning, and I came to the conclusion that Ops/DevOps teams would be warranted in saying, “Okay, you want that cool gizmo new thing that is totally outside our architecture, YOU support it.”

    Think about it. Between Agile and “Developers are Kingmakers,” we have set different Dev teams using different environments, from languages to databases to deploy targets to even load-balancers. And while there is a lot of talk about “chuck it over the wall” being gone, the truth is that the responsible Devs will be responsible for code in production, but not the infrastructure that we’re allowing them to inflict upon the Ops/DevOps team. And all of this is done with “timely delivery” as a mantra.

    The problem today is different for security. In security, it is seen by many in the DevOps crowd as inherently slowing down the process. And this, in our current fever dream of rapid delivery, is seen as inherently a problem. Time to step back and see where security can benefit from and add to DevOps. That movement is, thankfully, starting, but needs to be more prevalent. My blog about DB monitoring is an example of DevOps benefitting security, and increasingly the SecureOps movement is showing promise in integrating security with DevOps.

    Do yourself a favor. Look around your IT org. Are there apps running that are 20 years old or older? If yes, speed is still important to business agility, but you have to acknowledge that every unique database/load-balancer/whatever that you introduce is potential technical debt. If you’re working on a core system replacement and have decades-old apps running in your world, chances are pretty good that 20 years from now, someone will be figuring out what you were doing.

    Don’t make it harder than it has to be for future-you. Stick as close to standards as your development effort will allow. It’s been a long time since companies successfully enforced database standards, for example, but having a first choice means that support and training can focus on the first choice. And that 20 years from now, some poor new developer will be able to go “Oh, it’s another MariaDB app.” instead of “What the heck is SuperFastDBForMe, and why are these queries written in pig-latin?”

    And don’t make it easier for hackers by demanding that security not slow down the process. Encourage them to move faster, but it’s not all about speed. In fact, both security and ops were never about speed; they were about thoroughness. The environment and the apps that run in it need to be as secure as is reasonable, and the production environment needs to be as stable as possible. DevOps tends to find itself at odds with both of these facts, sublimating them to the desire to be “agile.” Yes, automation helps with stability, and I’m a huge fan of that. It also helps with the knowledge crunch, but it is more of a shifting of tribal knowledge than an elimination. Someone, in the end, has to be able to modify tools to face the new reality, and that person needs much the same knowledge that they need to do it manually.

    The goals and results of DevOps are great, but if you’re working for an enterprise that will have long-lived apps, just make certain you’re not sacrificing more than you’re gaining. Business agility matters, but so do both security and long-term technical debt.

    Balance, as always, is the way forward. Strive for it early, or struggle for it later.

    — Don Macvittie

  • Is Site Reliability Engineering the True ‘Ops’ in DevOps?

    Is Site Reliability Engineering the True ‘Ops’ in DevOps?

    I recently had the privilege of attending the SRECon conference in San Francisco. It’s in its third year and 650 attendees gathered to learn and share their experiences, insights and site reliability engineering (SRE) practices.

    Most SRECon attendees either identified as SREs or were there to learn more about this new role and approach. While there was strong representation from the “unicorn” community (Google, Shopify, Twitter, Netflix and Linkedin), enterprises such as Capital One and Comcast were among the many exhibitors actively seeking to recruit SRE talent. The conference spirit was infused with enthusiasm, a willingness to share, innovative thinking and grassroots advice. It reminded me very much of my first DevOps Days in 2012. There is no doubt that interest in SRE is rapidly growing and worthy of attention by enterprise IT.

    The practice of site reliability engineering was born out of the book by the same name from Google. Interestingly, the SRE movement emerged separately from the DevOps movement—although there is little doubt that they are part of the same IT spectrum with similar customer value-driven goals. DevOps focuses on engineering continuous delivery to the point of  deployment; SRE focuses on engineering continuous operations at the point of customer consumption. Both domains rely on sharing, culture, metrics and automation. Both require human and automated resources to ensure a seamless value stream and exceptional customer experience.

    The role of the SRE is rapidly gaining momentum. Part systems administrator, part second tier support and part developer, SREs are encouraged to be inquisitive, to acquire new skills, to ask questions, to solve problems and to embrace automation. I asked several of the exhibitors what types of skills they were looking for in new SREs. The answers almost unilaterally included the ability to code as well as an unwavering thirst for knowledge and improvement—to find answers, solve problems and ensure the highest levels of reliability and availability.

    I also can see a clear bridge between SRE with IT service management (ITSM). Many of the presenters spoke about the handling and management of late-night incidents, escalations, root cause analysis, service level objectives, availability metrics and other topics addressed in ITSM frameworks such as ITIL. The tools and process definitions may be different, the opportunity to instill agility into many of the ITSM processes to meet changing demands is certainly apparent.

    What are the risks? To my mind the biggest risk is if SRE, DevOps, ITSM, Agile SDLC and other frameworks do not align and remain siloed outposts. SRE and DevOps are two sides of the same coin. Let’s hope that the SRE momentum catches up to DevOps and that enterprises begin to integrate both sets of practices as the norm.

    — Jayne Groll

  • DevOps Chat: State of DevOps Report 2017, Nigel Kersten, Puppet

    DevOps Chat: State of DevOps Report 2017, Nigel Kersten, Puppet

    The results and analysis of the State of DevOps Report 2017 report are due out in early June. just in time for the DevOps Enterprise Summit London June 5-6. In this DevOps Chat we speak with Puppet exec and one of our favorite interviews, Nigel Kersten.

    Of course, Nigel and the folks over at Puppet have been co-producing the State of DevOps report and survey for six years now. For this year, Nigel along with Dr. Nicole Forsgren and Jez Humble of DORA, will be co-presenting at the DOES London, where they will announce the results of this year’s survey. It should be quite interesting.

    Nigel gave us some sneak peeks and early trends for this years report, as well as discussed the DevOps Enterprise Summit and, as usual, some good info on what is happening at Puppet and the DevOps world in general.

    You know the drill by now: The streaming audio of our conversation is immediately below and the transcript of our conversation is below that. Enjoy!

    Streaming Audio

    Chat Transcript

    Alan Shimel: Hey, this Alan Shimel, devopsy.kinsta.cloud, and we’re here for another DevOps Chat. And we’re happy to be joined again by a repeat guest on DevOps Chat, none other than Nigel Kersten of Puppet. Nigel, welcome.

    Nigel Kersten: Hey, Alan. Nice to talk to you again.

    Shimel: Good to speak with you. So, Nigel, we’re not talking about the latest and greatest from Puppet today. Well, maybe if you wanna just mention it quickly, feel free, but I wanted to really talk a little bit about the upcoming DOES London event, Gene Kim’s DevOps Enterprise Summit, which is June 5th and 6th in London at the QEII Center, and you will be presenting there. Correct?

    Kersten: I will be. Yep, with Dr. Nicole Forsgren, who’s one of the other authors of the DevOps report, and DevOps Enterprise Summit London last year, I think, was honestly one of the best events I’ve been to in this space for a long time and I adore London for lots of reasons, and so it’s always great to be back there.

    Shimel: Yeah. And, Nigel, correct me if I’m wrong – is Jez Humble also presenting with you and Dr. Nicole?

    Kersten: I think Jez probably will be, but I’m not sure if it’s quite confirmed yet. We’re sort of trying to work out how we’re covering all of the different events, for the various roadshows and webinars we’re doing around the DevOps Enterprise Summits and the DevOps enterprise report.

    Shimel: Yep. Okay, so I guess we’ll stand by for final confirmation on that, but, certainly, you and Dr. Nicole will be on, and, of course, Nicole has appeared on our show before and we’ve talked a little bit about not only this year’s DevOps survey but past years’ as well. But, Nigel, for some of our listeners who maybe weren’t lucky enough to hear previous talks about it, this is what? The sixth or seventh year of the State of DevOps survey?

    Kersten: This is the sixth year, which is kind of amazing ’cause, you know, I think, when we first started with the fantastic Alanna Brown, who also works here at Puppet, everyone was a bit skeptical about it. I think this was even before you’d started devopsy.kinsta.cloud and people were like, “Is this really a thing? Do we really need a survey about all of this?” but I think it’s just gone from strength to strength over the years. So, yes, I guess, for the people who are sort of new and may not have come across the report before, what we essentially do is we survey a whole bunch of practitioners—we’ve done tens of thousands of ’em around the world over the last six years—and what we do is we ask about the practices and the tools that they use, but also some metrics about “What’s your mean time before failures? How quickly can you deploy your software? What sort of practices do you use?” as well as what sort of outcomes you have. And then we do a statistical analysis on all of that so that we can—and we actually end up showing that there’s a huge gap between what we call “high-performing” IT organizations and everyone else.

    And, in fact, interestingly enough, over the last few years, we’ve shown that the gap is increasing over time, so the people who’ve adopted DevOps practices—because, essentially, what we’re showing is we’ve been able to show statistically that what we tend to call “DevOps practices,” around using CI, using CD, using infrastructure-as-code software, doing continuous deployment, using testing, storing things in version control, all of these practices, when you cluster them, are the people—the people who employ these practices are the people who have high-performing organizations. And they’re really huge statistics—they tend to be thousands of times better, being able to deploy just ridiculously faster—and, essentially, what this ends up showing is you really don’t have to sacrifice quality for speed or vice versa, so we’re seeing that these people are both producing high-quality infrastructure and applications and they’re doing it far more quickly than everyone else.

    I think one of the things I’m really proud of with the DevOps report is that it’s useful to sell DevOps practices within your organization, so I talk to an awful lot of customers and practitioners out there who are really thankful for the report because it tends to be focused on business outcomes. So, even though we’re surveying practitioners, it’s something that’s really applicable to C-levels and VPs and directors. They can look at this with them and go, “Ah, this is where the industry’s moving and these are the sort of benefits we’ll actually get.”

    Shimel: Excellent. And, Nigel, in typical humble Nigel self, you’re—I mean, let’s give a little bit more flavor, if we can. Over the five previous years, I think there’s over 25,000 responses to these surveys.

    Kersten: Yeah, no, that’s right. 25,000 over five, six years. It’s pretty crazy.

    Shimel: So that does represent a—in a field like DevOps, which is fairly new, right, it represents a sizable amount of people and organizations who have taken the time and contributed to the data that you guys have analyzed over the years. And another important thing, I think, to note for our audience is not only the analysis of the data but even the questions themselves are, from a statistics point of view, a statistician’s point of view, rigorous—rigorously designed and rigorously analyzed. And, look, having a Ph.D. statistician helping you with it doesn’t hurt, but so these are not just some –

    Kersten: No, it’s not your average –

    Shimel: – go up and doing surveys.

    Kersten: – sort of marketing survey at all, and I think this is why it’s always really important for us that—you know, we’re a software vendor and we’re in this space and there’s a lot of people in our space who do pretty fluffy kind of surveys that only take two or three minutes and then some sort of ridiculous claim gets made, so this is why we’ve always been really keen on working with the external parties of Gene Kim, Jez Humble, Dr. Nicole Forsgren. Particularly Nicole. She’s a trained statistician who’s literally got a Ph.D. and has spent her career working on studying organizational performance, which overlaps with DevOps in really interesting ways, but I think having that external rigor, and I think it helps keep us honest as a software vendor. So this is something we really loved, having a partnership with them, ’cause this is their specialty.

    They actually—to give them a little bit of a plug, they have their own organization, DORA, DevOps Research and Assessment, where they’ll come in and do benchmarking of your organization and actually measure how you’re actually doing, so I think it’s just really great. We’re clearly really plugged in as Puppet into this whole community, but they plugged in at a different level, and working together, I think, means that we both get to expand reach and bring a bunch of statistical rigor to something that could easily devolve into a self-serving survey, which ultimately doesn’t –

    Shimel: Hey, Nigel?

    Kersten: Yep?

    Shimel: I thought I lost you there for a second. I apologize. Agreed, I mean, on all of the above. And that’s really—I want people to understand that, that this isn’t a marketing survey they up and have done now for six years running. I wanted to make another point, Nigel, and that is, certainly, over the last two years at least, and I would imagine for this year as well, one of the real nuggets of wisdom that have come out of this analysis is really just how high-performing or what high-performing IT organizations mean to the bottom line of these companies that are doing it. I think, at some level, we all at a gut level say, “Well, if you’re performing better, you’re releasing faster, it should translate into a better company,” but, certainly, the State of DevOps report—survey and report is one of the few that are out there that really connects the dotted lines here.

    Kersten: Absolutely. So you look into the sort of things that people are actually sort of seeing. What we’re seeing, so to sort of hit some of the boon stats from last year, is that we’re seeing the high-performing IT orgs, three times lower change-failure rate, 200 times more frequent deployments, and 24 times faster recovery from failures. And those are really amazing stats because I think they really resonate, both with practitioners who’re the people who are getting woke up in the middle of the night or having to deal with the pain of a deployment that didn’t work properly, but they’re also the sort of stats that your average, been-away-from-the-technology-keyboard for a few years, high-level executive, can look at it and they go, “No, that’s actually what we want. We want to be able to deploy more frequently,” because, I think, one of the lessons that SAS has taught us is the reason a lot of SAS companies outstrip on-premise competitors is because, every time they deploy, it’s a chance for learning, it’s a change for feedback.

    And Agile has taught us, from traditional software development, the more frequently you can deploy, the smaller the deltas are in those deployments and you can do more frequent cost correction, so you can actually produce a much better outcome over time by deploying more frequently and being able to correct course more frequently.

    And, to, I think, bring it back to enterprise folks, not everyone always thinks about deployments in this way, but, every time you get a patch from your vendor, that’s another deployment. Every time you respond to a security incident internally, every time you have to follow through a recommendation of your audit and compliance committee—all of those things are deployments and the more pain-free and friction-free you can make the ability to deploy within an organization, the more responsive you’re gonna be to all the different stakeholders.

    Shimel: Yeah. Let me give you my favorite stat that you omitted or you just didn’t get a chance to, and that is these high-performing IT organizations have 50 percent less vulnerabilities post-deployment.

    Kersten: Yep.

    Shimel: That’s huge.

    Kersten: It’s a major. And you’re spending less time on that. And I think the other related one that’s really amazing is that the high-performers spend 22 percent less time on unplanned work and rework. And, for anyone’s who’s been neck-deep in infrastructure, it’s the unplanned work that kills you. It’s the context switching. You’re not making progress on your defined road map every time you’re having to spend time on unplanned work.

    Shimel: Yeah. So, Nigel, these are all fantastic insights and metrics, so now, of course, though, we’ll turn the table on you and say, “Hey, what have you got for us this year?” I know it’s early; I know you haven’t released the report yet. You’ll probably be announcing a lot of the results, I think, come out just at the time of DOES London, which, again, is June 5th and 6th, but is there anything you can share with our audience as maybe a preview?

    Kersten: So I think one of the things that I could share is we’re still going through doing the analysis, but we’re seeing that, again, the high-performing orgs are achieving just as well compared to everyone else, as they have in previous years. It doesn’t look like there’s only sort of peak, as far as implementing these practices. I think the whole industry, even people who have been doing this for a while, have still a fair way to improve.

    I think one of the really interesting things—well, there’s two big ones I wanna call out. One is that, this year, we spend a bit of time working on non-profit performance ’cause, in previous years, we’ve shown that commercial companies who are high-performing IT orgs tend to outperform their financial metrics, outperform in the stock market, their internal company goals, but, this year, we decided to focus on non-profit performance, and so we’re looking at things like, “What’s their operating efficiency like? Customer satisfaction? Quality of the products that have been shipped?” So we’re actually, I think, showing that DevOps practices in high-performing IT orgs impact in a positive way all sorts of industries, so I think that’s gonna be one of the really interesting sections.

    The other section, I think, that’s gonna be really fascinating is that we’re actually looking at what’s the—there’s a myth out there, to sort of back up a little bit, that DevOps practices tend to work if you’re building all of the software yourself, if you’ve got a web app, if you’re building a whole bunch of stuff in Node.js or something like that, and deploying it to the cloud, sure, you can do DevOps—you can do continuous integration; you can do continuous delivery—but, for those of us who are sitting there running commercial, off-the-shelf software, we can’t actually do that and we can’t actually obtain the benefits that are available by employing DevOps practices. So I think what we’re gonna be showing is that this isn’t true, that there’s a couple of things you can do as an organization, in the way you consume commercial, off-the-shelf software, to actually let you employ continuous integration, continuous delivery.

    Now the reality is you’re not gonna be able to test all the same kinds of things because, unfortunately, you know, lots of vendors that release software don’t necessarily have an API-first policy, so you’re not always gonna be able to test everything inside the application, like you can’t run unit tests, necessarily, ’cause it’s not your code, but there are a whole bunch of things you can do. And one of the big bits of guidance that we’re gonna be pushing is that, when it comes to commercial, off-the-shelf software, really try to make the installation as vanilla as possible. Don’t spend forever customizing it. And, if you’re having to customize it because that’s what your business processes say, in many ways, the lower-cost and better-outcome approach is to not customize the software and adjust your business processes because there’s something within your control, generally. And if you adjust those, then it becomes simpler to deploy that software into a CI system, to have Jenkins or Bamboo or whatever do deployments of it, do external black-box testing, make sure that it actually works, and then roll it out to production.

    So we’ve got a pretty strong belief that, when it comes to utility computing, to sort of use Martin Fowler’s distinction between utility and strategic computing.

    Shimel: Yep.

    Kersten: There are huge efficiency gains to be made there, but there’s a few things you can do to avoid those problems. The analogy I kind of come back to is that there was a period, I think, in the late ’90s and early 2000s, when lots of people would customize their Apache installs. They would sit there and come up with this fine-grained list of modules, configured in specific ways, and, every time they deployed a new version of Apache, they’d eke out another one or two percent performance by having this really customized installation. It turns out the actual cost to the business is really great because those tend to be manual processes—you’re turning yourself into a snowflake when you didn’t actually need to be—and I think the more you can commoditize the software you’re buying and that you’re building and that you’re deploying, the faster and more friction-free a lot of these processes are gonna be.

    Shimel: Got it. You know, Nigel, that—so I’m old. That’s firing up some old synapses in my brain back from the dot-com days, when I helped start a company called “Interliant.” We were an early ASP. And, mind you, this is before we have a modern cloud and virtualization and ubiquitous connectivity, but we were offering hosted Lotus Notes, PeopleSoft, Oracle applications, Lawson ERP—I don’t know if you remember Onyx was an early CRM tool back then.

    Kersten: Oh, yeah. Yep.

    Shimel: That’s a blast from the past, huh?

    Kersten: Totally.

    Shimel: Anyway, so our thought was to offer hosted versions of these applications. This is early, right? We called them “application service providers.” And what we quickly learned in—you know, when you go to market, and we did the whole IPO thing, all of that, but what we learned from our enterprise customers was that, as much as we wanted them to run a vanilla PeopleSoft or a vanilla Lawson or Onyx or even Lotus Notes, for that matter, the best we could hope for was about 80 to 85 percent of out-of-the-box, just plug-and-go. They always needed—and so what happened was we had to change our whole business model and we wound up acquiring a bunch of service bodyshops, for lack of a better word, who would come in and do that last-mile customization, if you will, that last 15 percent. And, as a result of that, I will tell you, the business model failed, ultimately bankrupt. And, if you look at all those early ASPs, none of them really succeeded—USinternetworking and Corio, some others—because we weren’t able to get people to use the vanilla configs that would have been easy for us to host, spin up, and put down.

    I think you see the same thing a lot today, with kind of bare-metal hosting. Right?

    Kersten: Yep.

    Shimel: Versus a traditional cloud virtual, you know, kind of hypervisor thing. How many people are using just vanilla bare-metal kind of config versus how many have—and you guys are Puppet, right? You’re dealing with this more than most, right? How many people are highly, highly customizing their bare-metals?

    Kersten: I think we’re seeing people shift away from customization. I think there’s probably a few things. One is I think people are realizing that a lot of this industry is sort of commoditizing, and so you may as well use off-the-shelf stuff. And so, if you’re just consuming stuff the way it was sort of shipped from the vendor, whether it be hardware or software, there’s sort of a general expectation that, I think, both software quality has improved—as much as we like to bitch and complain about software, I generally think software has gotten better than it used to be. There was no sort of Golden Age of incredibly rigorous enterprise software, as far as I’m concerned. I think stuff’s getting better. So I think there’s a couple of different pressures there, is that software’s gotten better, people have gotten more used to the idea that various things are being commoditized, and so they’re more willing to entertain the notion that the next layer up is getting commoditized.

    Shimel: Yep.

    Kersten: I think we’re also seeing things like—so here’s a good example, I think. If you consume Atlassian’s JIRA, the hosted version, versus the on-premise version, you can’t customize it as much. And, if you’re consuming GitHub the public service, versus GitHub enterprise, you can’t customize it as much. And so there’s a general understanding from people that, you know, an uncustomized version, or as much as is sort of possible, is actually pretty good and we don’t need to make everything completely different for everyone else because it means that documentation just works out of the box and people who’ve used the software somewhere else can join the company and have much faster on-ramp.

    And I think we’re seeing that—and this is a somewhat optimistic approach—that there’s a general desire for people to adopt software engineering principles and sort of DevOps cultural changes to get to that higher-performing IT organization state. And I genuinely think, if we keep pushing this sort of attitude out to people that, “If you don’t customize your software, adjust business processes to fit instead, that’s cheaper and you’ll get a better outcome,” I think all of those things combined sort of give me hope that we’re actually heading towards a world where people are giving up unnecessary customization.

    Shimel: I hope so. But, Nigel, we’re so far off our course here. You know, we were supposed to be talking about DOES London, and let me try to bring you back. So, I mean, obviously, all of this is background and the—this is why this survey is so important, so that we see these trends and we see it manifest itself in how companies are doing things and so forth. Let me ask a little bit—so, Nigel, you’ve presented at DOES before and I did an earlier interview today—I was talking to one of the program committee’s members for London, Jonathan from Hiscox—and –

    Kersten: Ah, yes.

    Shimel: Yep. And, forgive me, his last name—Jonathan Fletcher from Hiscox.

    Kersten: Yeah.

    Shimel: You know, and I’ve known Jonathan for some time—great guy. What we—you know, we forget—all rolled into one place in the space of two days, we’re gonna be jam-packed with all of this great information around DevOps and what we’re seeing and not only what we’re seeing but people are gonna talk about what they’re doing right now and what they did last year versus this year versus next year, what the findings are in our surveys, and I think that’s what really makes for a great event. Right? I think –

    Kersten: Yeah, I think there’s a couple of things that are really unique about it. I think one is that it’s not a vendor event, and I’m in the business of working the software company and we make and sell software, but it’s also really refreshing to go to an event where everyone who’s on stage is really there just telling case studies, their real-world stories. They’re not product-pitching to you. We’re not getting up and pitching Puppet Enterprise to you at all. We’re getting up and talking about the DevOps report, and everyone who’s there is—I think this is Gene’s big focus, is that everyone’s telling a real-world case study about what they’re actually doing, where the challenges were. It’s war. It’s honest. So I think that’s one section of it, that it’s real stories from out in the field.

    But, perhaps more importantly, it’s not just practitioners. And I think those of us who sort of have had a technical background can sometimes get too in the weeds about going and watching someone’s talk about this incredibly interesting deployment they’ve done and what they achieved, but we’re seeing business leaders talking about the actual impact on the business, how they ran large departments, large transformation projects. You know, the term “digital transformation”’s been kicking around for quite a long time, but we tend to see very sanitized case studies, driven either by a software vendor or a large consulting firm or the PR department of some multinational corporation talking about what they’re doing, and these tend to be really warts-and-all stories, going, “This is what we did and this is how it worked or this is how this didn’t work.”

    And I think some of those are some of the more fascinating stories, where people are getting up and talking about “Here were our lofty ambitions and we only got 60 percent of the way there and these were the problems we ran into.” And that, I think, is just really, really powerful, so I think the fact that you’ve got senior business leaders and executives there, as well as the fact that they’re all real-world case studies, is just a really, really powerful combination.

    Shimel: Yep. I agree with you. As a matter of fact, one of the things I’d love to see is more people get up and talk about failures, right, where maybe DevOps, they didn’t do it right, or what they could have done differently or what have you, where it didn’t work out right and this is what we did as a result, ’cause I think too many people come out of these events, out of Gene’s things, sometimes, and it’s like it’s all rainbows and unicorns and horses and such, and that’s great, but we—you know, as a dad, I try to teach this to my kids—you don’t always win. And that’s why you gotta learn to deal with failure and how to recover from that as well. And I think those are some of the best lessons for people to learn, is we learn more from our failures than from our successes sometimes, so.

    Kersten: Absolutely. And I think it’s hard because we haven’t always had a culture in the IT industry of actually performing postmortems and retrospectives on large projects that we’ve done, so it’s people don’t always have great answers for how they would have done things differently, but I think that’s something that’s actually also starting to shift quite considerably. We’re seeing DevOps has been a big part of that, of “Let’s do blameless postmortems,” and, hopefully, that continues so that we see more people being open about their failures.

    ‘Cause I think one of the things I find really frustrating—this has happened to me more than once and I don’t think this is gonna identify me, one customer or user, because they do so many of them—seeing your executives at Amazon summits get up and talk about how fantastic their whole cloud migration journey has been and that they’re all in the cloud and everything’s done and it’s absolutely wonderful. And then you go talk to the VPs or directors who are actually running those deployments and they’d be like, “Oh, God, no. We’ve only moved five percent of things and it’s been a miserable failure and we’ve now added three years to the project because we’ve fallen over organizational boundaries.” So I think that gap between the sort of PR-style business leader talk and the reality—that’s not a gap that actually exists at the DevOps Enterprise Summits, which I think’s been really fantastic.

    Shimel: Yep. Agreed. Agreed. Well, Nigel, our little 15-minute chat has turned into a solid half-hour, and I think we’re gonna need to call a break here. We are looking forward to the release of this year’s analysis of the survey, looking forward to your presentation along with Dr. Nicole at Gene Kim’s DevOps Enterprise Summit in London, June 5th and 6th, and just always looking forward to what you’re up to and what the folks in Puppet are up to. Many people, you know, when they think DevOps, they think of companies like Puppet, right? A leader in—I don’t know if they’re ever gonna do a DevOps Magic Quadrant, but—or some sort of stuff like that, right? But, I mean, seriously, Puppet’s one of the cornerstones here and you’re one of the cornerstones in Puppet, so it’s always great to hear what’s happening from you and getting caught up. It’s a pleasure.

    Kersten: Aw, thanks, Alan. So I will get one little pitch in, which is, because of DevOps Enterprise Summit being in London that week, we’re going to be announcing pretty soon that we’ve got a Puppet Camp happening pretty soon afterwards, so there’ll be a Puppet Camp in London, and this will be a slightly different tweak on the Puppet Camp format. We’ve run hundreds and hundreds of these events over the last few years, but we’re doing a slightly different thing, where we’re having a sort of more executive-manager-focused morning and a more practitioner-focused afternoon. So, if you’re someone who’s an IT architect, you might find mornings and afternoons both applicable, but we’re really looking to try and join together the conversation for sort of senior executive leaders as well as practitioners on the ground. So we’re already collecting a whole bunch of really great talks, both for the morning and for the afternoon, but, for those of you who are into Puppet, look out for a Puppet Camp London coming soon after DevOps Enterprise Summit.

    Shimel: All right. We’ll try to get info on that up on devopsy.kinsta.cloud for anyone interested. Nigel, fantastic, man. Thank you so much for the time today. We appreciate it. Nigel Kersten of Puppet here on DevOps Chat. This is Alan Shimel for DevOps Chat. Hopefully, we’ll see you soon at the next—on the next DevOps Chat. Until then, have a great day.

    — Alan Shimel

  • DevZone and Bluemix Garage @ the IBM InterConnect Expo Floor

    DevZone and Bluemix Garage @ the IBM InterConnect Expo Floor

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

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

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

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

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

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

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

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

    — Alan Shimel

  • DevOps Chat: Hiscox CTO Jonathan Fletcher

    DevOps Chat: Hiscox CTO Jonathan Fletcher

    Our guest on this DevOps Chat is Jonathan Fletcher, CTO of Hiscox. Jonathan will be quick to tell you that he is actually “interm” CTO. But as I told him in our Chat, if Hiscox is as sharp a company as I think it is, it will make that title permanent soon. I have known Jonathan for about 3 years or so now; I believe it was at a Ranger4 event in London where I met Jonathan. It was readily apparent to me that he was the driving force behind Hiscox’s impressive DevOps transformation.

    Jonathan is on the program committee for this years DevOps Enterprise Summit London. We spoke a bit about what it is like to be on the programing committee for DOES. We also spoke about what he is presenting at DOES. You will have to listen or read along to find out.

    As usual, the streaming audio is directly beneath, with the transcript of our chat below that. Enjoy!

     Audio of our Chat with Jonathan Fletcher

    Transcript of the chat with Jonathan Fletcher

    Alan Shimel: Hey, everyone. This is Alan Shimel, devopsy.kinsta.cloud, here for another DevOps Chat, and I’m very happy to be joined by our guest for this DevOps Chat. It’s Jonathan Fletcher, CTO of Hiscox. Jonathan, welcome to DevOps Chat.

    Jonathan Fletcher: Hi, Alan.

    Shimel: Great to hear from you, Jonathan. I probably haven’t spoken to you since, oh, maybe DOES London of last year, which was also in late June and –

    Fletcher: No, that’s right.

    Shimel: Yep. Since that time, looks like you’ve got a new title over at Hiscox. Is that correct?

    Fletcher: That’s right. Interim at the moment, but, hopefully, that will develop into a permanent role in the not-too-distant future.

    Shimel: Well, if they’re smart, they’ll make you permanent.

    Fletcher: A CTO office.

    Shimel: Yep. Excellent, John.

    Fletcher: Yeah, I think you’re quite right.

    Shimel: And well-deserved.

    Fletcher: Yeah

    Shimel: Well-deserved.

    Fletcher: Thank you.

    Shimel: So, Jonathan – excuse me – Jonathan, I wanted to speak to you today, though, a little bit about the upcoming DevOps Enterprise Summit London 2017, which is June 5th and 6th, at the QEII Conference Center in London. And you’re actually one of the speakers lined up for the event. That’s correct?

    Fletcher: That’s right.

    Shimel: And, Jonathan, can you – I don’t know if it’s too early or not, but can you give our audience maybe a little bit of a preview of what you’ll be talking about?

    Fletcher: That’s a good question [chuckles] and I’m not sure really sure yet. I think what I’m gonna be talking about is a little about a continuation of our journey, particularly about moving to cloud and what that means, the business results that can be found from doing that, along with sort of where we started and how that changes the IT organization. ‘Cause moving to cloud isn’t just a move of technology; it’s change in skills; it’s a cultural change. It changes things that I hadn’t really thought about, a way we budget, I mean, in fact, from a legal compliance teams. It’s a real transformation program for us. I kind of keep (saying) that savings isn’t IT 1.1; this is IT 2.0. This is a new IT department. So I’m really excited to kind of talk about that. We’ve got a long way to go ourselves, but seen some good early signs with cloud adoption, so I think that’s where I’m gonna focus my time.

    Shimel: Fantastic. And, Jonathan, of course, in addition to your speaking role with DOES London, you’re also on the – is it called the “speakers committee”? Is that what it’s called?

    Fletcher: Yes, right, programming committee.

    Shimel: Programming committee. I’m sorry. Jonathan, can you – our audience, the overwhelming majority of them have not served on the program committee. Can you give us a sense of what is involved in that?

    Fletcher: So there are dozens and dozens of people who want to come along and share their story next year, so the program committee really is around trying to filter some of those down – not everyone can come and talk – and trying to make sure they are as much relevant to the audience that’s coming, so I think it was worth reimbursing in last year.  it was real stories from people doing transformations at real enterprises, and not unicorns, not ace, but is this a real bank, real insurance company, real companies with a legacy of acquisitions and different types of IT, different technologies, and hearing about how they’ve got on and what they’ve got to do in the future, so that’s really powerful. So program committee’s trying to turn a number of – dozens and dozens of submissions to the program down into a really good, tight sets to deliver over two days in June.

    Shimel: I got it. And, Jonathan, I don’t know if you even know the answer, but can you give our audience a sense of how many submissions versus how many speakers are actually selected for an event such as DOES London?

    Fletcher: So I’ve seen a bit of pre-filtered list, so I couldn’t speak on Gene’s behalf how many there were, but I’ve seen hundred – in the hundreds, I guess. And I think that’s down to 30-something; again, I don’t wanna get the numbers wrong, get the (incorrect) stats, but it’s significant amounts and significant amounts of people that Gene has conversations with, I guess, _____ _____ _____ _____ get through to a formal submission, so it’s very significant, which I think is a really good thing. Obviously, people are seeing a value in DOES London and wanna come share their stories, so it’s a shame not more people can do it, but it’s only those two days.

    Shimel: Yep. Absolutely. You know, and I have some ideas around that I’m gonna talk to Gene about. But, Jonathan, was there any – obviously, the DOES, the Dev-Ops Enterprise Summits, traditionally focus on large organizations, “horses,” as we call them, telling their transformation story. And some of these stories we’ve now seen and followed over multiple years and we’ve seen that transformation evolve. Were there any particular themes or things that the committee wanted to really bring out for this year’s event?

    Fletcher: I think it’s lot of different things. I think a – in terms of sense of continuity between last year’s and this year’s, so what are the results that we’ve seen, in terms of transformation and – that seems to be a bit of a theme. To share that continuity _____ _____ years is quite an interesting thing to look at. The theme, obviously, is try and – the _____ tend not to be technically focused, so we don’t have too many groups talking about technology, more about the people and process of things. So I think a lot of what you’ve heard last year, the same kind of thing, but, hopefully, just seeing people a bit further along the journey, where they’re going to and the challenges that they’re running into.

    Shimel: So, Jonathan, this – you know, I’m gonna attend this year’s DOES London event, and this will be the, man, the fourth or fifth DOES that I’ll be attending. And, though I think I’ve come to – I think all of us have come to appreciate hearing the transformation stories of these various organizations, bigger picture, in order for DevOps to continue to grow, right, what else needs to come to the forefront at conferences like DOES, other than “Hey, we tried to do this DevOps thing and here’s how we’ve done”? Do you think at some point we need to hear more than that around DevOps?

    Fletcher: Sorry, what do you mean?

    Shimel: So, in other words, at this point in the game, depending on who you believe and who you listen to, a majority of enterprises have at least dipped their toes in the DevOps pool, if you will. Not many of them have undergone an enterprise-wide transformation, but at least they’ve started along their way. What more – so, in other words, what is there beyond the “We’ve tried to transform the company” type of lessons that the DevOps community needs to learn from these events? Or maybe there is nothing more.

    Fletcher: That’s a good question. Well, I don’t know. It’s a difficult question to answer, really, ’cause it depends on the strategic direction for those companies and how far they need to push the barrel. I mean, not everyone needs to release 400 times a day _____ _____. You know, the different companies got different requirements. And I think, really, DevOps is such a all-encompassing term now that it’s kinda lost its meaning. If your company is about improving quality or that’s your strategic goal, rather than the pace of change, there are different things for different people, so dipping your toe in the water is fine. I think DevOps is for everyone, regardless of scale of company, so those focused on enterprise, well, that doesn’t mean that, if you’re a small shop, that’s not relevant to you ’cause it is.

    I think, really, it’s such a wide topic that seems to encompass Agile and Lean and technology and people, and it’s so vast in topic that, actually, the next step for people in the transformation program ought to stop worrying so much around necessarily what other companies are doing. The war stories are good, but it’s focusing more on what that really means to your company. It’s no longer about DevOps transformation; it’s about business success transformation and what you need to get to get you there. So I think a bit of maturing thinking from companies that started on this program is really actually what they tried to achieve and where they need to get to because I think there’s an assumption between certainly some people aspect where it’s all about Puppet and getting 4,000 releases out the door, and that’s not always the case. So _____ _____ big business goals and I think really trying to realize some of the results so that the business benefits ’cause we’re doing this not because it’s cool and it’s _____ cool IT; it’s because there’s tangible business benefits in doing it. And I think that’s really what the community needs to focus on and _____ –

    Shimel: Yep. And I think you’ve — Jonathan, I think you’ve hit that right on the head and that’s just what I was looking for, which is so many people, especially in the IT industry – I don’t know what it is about the IT industry, but we suffer from “shiny trinket” syndrome, right? Where everyone wants to latch onto what the new cool thing is. And the risk you run is that, when the luster is off of the trinket, people tend to start looking for the next trinket, instead of doing what makes sense for the business, what’s best for the business. You know, ’cause to my mind –

    Fletcher: Yeah, exactly.

    Shimel: Right?

    Fletcher: It becomes a – go ahead. Sorry.

    Shimel: No, no, go ahead. I’m listening.

    Fletcher: Yeah, it becomes a little bit of a statistics race, like, “How fast can I get a release out the door? How many servers can one person look after?” And, actually, that’s fairly meaningless, unless there’s a business benefit behind it, so that sort of arms race to be the fastest becomes less and less relevant, so. And, as I said, DevOps is such a wide term now that it kind of – it’s just about doing IT better.

    Shimel: Yeah. And that’s exactly it. I mean, Jonathan, to me, in my many, many years in IT and in business, there’s very few revolutionary things. There’s more evolutionary type of developments, right? And, when we look at DevOps, we look at the Agile that came before, right, and we see kind of where Agile is and its effect, but yet we still see plenty of organizations that are doing waterfall or some may call it “fast at waterfall” or “Agile waterfall” or whatever you wanna call it. But, you know, it’s a very – the inertia in our systems is such and entropy in our systems is such that nothing moves – we don’t move at the same speed across. And even something like DevOps, though you may have organizations that are now presenting for the third or fourth year at a DevOps Enterprise Summit, there’s still plenty of organizations that are still just starting on that journey, and they will be on that journey for many years going forward. And I think we lose perspective of that when we live in this bubble of “Who’s releasing the most often? Who did this first? Who’s on to the next thing?” That’s not who wins the game, necessarily. People who win the game are organizations –

    Fletcher: Well, and –

    Shimel: – and their customers. Go ahead. I’m sorry.

    Fletcher: And some of these things are – all these things are less relevant, so, if you’ve got a system you’re gonna throw away in two years’ time, there’s – ROI to spend tons of time automating it and putting all that engineering in place with, you know, sort of – is kind of mothballed. So, again, it’s picking the right application, the right teams, to get benefit from this. I don’t necessarily see the – you have _____ all of these other _____ everywhere. Waterfall has its place. It’s about picking what is right for the business and getting the business _____ _____ _____. It’s not about a blanket “This is a right way or this is a wrong way of doing IT.” I just don’t believe that.

    Shimel: Mm-hmm. I agree with you. And so, Jonathan, we’ve come full circle in our short little chat, but this is what makes DOES a great conference to attend. Right? Where we are hearing these transformation stories, and some of them may be old hat to some of us, some of it may be a revelation to others. Right? But it’s – the last part of this that I wanted to hit is that it’s, at the end of the day, it’s about the community. We as a collective community learn from each other’s experiences and these shared experiences, and that’s how we evolve and that’s how the whole movement moves forward, not just Hiscox, not just Disney, not just any particular organization, but as an industry, as a movement, that’s how we move forward. And then I think that’s what DOES is about.

    Fletcher: Yeah, and that feels fairly unique. I can’t remember, in my 20-odd years of working IT, a movement with such a community feel, with so many people who want to help other people, and it’s – I think that’s amazing. And I don’t ever get – when I speak to people much further down the line than we are and they do better things then we do, I never get that looking down their noses or “You should be where we are.” It does feel like a real community sense of being, that everyone’s gonna help each other. And I don’t know what it is about DevOps, but I think that’s amazing, and you really see that at DOES.

    Shimel: Yep. Absolutely. Jonathan, we’re about out of time here – probably, we’re over time – but, listen, I wanna thank you for joining us today on DevOps Chat. I look forward to hearing your presentation at DOES London and we’ll check in before then and get more of a final version of what you’re speaking about. And, also, I wanna thank you for being on the program committee. I’ve been on organizing in program committees of events in the past and I know it’s, in a lot of ways, an unsung job – you don’t get paid for it and God knows there’s ton of work that goes into it – so thank you for your service.

    Fletcher: You’re welcome. Thanks very much.

    Shimel: No, my pleasure. And, Jonathan, I’ll get together in London beyond that. Maybe we’ll catch up on a video or something. Hey, but continued success. I hope, by the time I see you in June, the interim title’s gone. They couldn’t find a better man or person for that job. All right?

    Fletcher: Thanks, Alan.

    Shimel: Cheers, Jonathan. Jonathan Fletcher, Hiscox and the program committee at DOES London 2017. This is Alan Shimel for DevOps Chats and devopsy.kinsta.cloud, and we’ll see you on another chat soon.

    — Alan Shimel

  • An Unanticipated Obstacle to Full Automation

    An Unanticipated Obstacle to Full Automation

    I’ve been concerned about the impact of automation on human employment for a while. My research activity started after November 2016, when I decided I needed to learn whether the much-touted phrase, “We’re bringing back the jobs,” was valid or not.

    While it is true that some jobs in the United States have been exported to other countries, a study coming out of Ball State University in Indiana asserts that 88 percent of the jobs lost by U.S. workers is due to automation. Combine this study with the one published in 2013 by Frey and Osborne out of Oxford University that says that 47 percent of the jobs in the United States are risk, then things don’t look so rosy. Martin Ford, in his book, “Rise of the Robots,” goes so far as to say that every occupation is at risk, not just low wage workers who are paid to do repetitive tasks that are easy to learn. Not only will we have machines flipping burgers, they’ll also be perusing volumes of legal documents during discovery processes, which is the type of work that now is done by paralegals and newly hired law school graduates.

    Machines are getting smarter all the time and they are getting cheaper. You can buy Baxter, a full fledged factory robot, for $22,000. Baxter can work 24/7 and is not subject to OSHA laws or workers’ compensation coverage.

    Software? That’s getting cheaper, too. Every day, another open-source project is made available on GitHub that allows anybody with a computer and connection to the internet to take advantage of the power of artificial intelligence and machine learning. You want Swift code for artificial intelligence? No problem. It’s on GitHub and available to all for free! Want to convert your English ReadMe into Japanese? Simple, just use an API such as Microsoft Translator or Google Cloud Translate.

    Given the current trends in technology, it’s not hard to imagine that within the next 15 years to 20 years we’re going to have a world in which fewer people are employed. This future scenario worries me.

    About a week ago I was sharing my concerns with Chris Surdak at Surdak and Company. Chris works with large corporations implementing robotic process automation (RPA). He is also on the board of the Institute for Robotic Process Automation and Artificial Intelligence. Chris is at the front lines of using robotics and artificial intelligence to increase commercial efficiency. He and I share a concern about the wave of worker displacement we see on the employment horizon. However, Chris has an interesting take: While he agrees that automation is going to cause significant displace of human workers, he sees an obstacle.

    Imagine you are an executive in a corporation and you have 5000 people under you. One day someone like me tells you that you can replace 80 percent of your workers, 4000 people, by streamlining your work processes using robotics and artificial intelligence. You should be ecstatic, right? That is a significant cost savings that is going to directly affect your bottom line.

    But, it doesn’t work that way because that is not how many corporate managers think. They want to keep their jobs and in order to do so they need two things: headcount and budget. So, if I come along and tell them that I can create an efficiency that is effectively going to cost them power (less employees and a smaller budget to manage) and maybe their jobs, do you think they are going to jump on board right away? Nope. In fact, they are going to do everything that can to slow down my work until they retire.

    Chris’s statement was a revelation to me. Previously, I thought corporations in their continual quest to seek greater profits will do whatever is required to reduce costs and increase efficiency. Most of us who do tech, particularly in DevOps, have embraced this notion. Automation is our friend. We’re lazy. We want the code and machines to do the heavy lifting. And, we’ve created environment where automation is necessary, For example, large-scale container deployment alone went beyond the capabilities of human management a long time ago.

    There is a good argument to be made that the factory floor has not had problems using machine automation to improve efficiency. Factories have looked for improved efficiency via tooling since before industrial textile mills used water wheels to power their looms. But, there are other industries that are risk-averse and slow to change; insurance, for instance. The virtue of an industry such as insurance is that it’s ingrained in its culture to manage risk and to be measured when considering change. After all, would you want your retirement annuity to be subject to the whims of a day trader? No. You want your money well-protected by a cautious steward. However, with such safety comes inertia. Thus, there is an intrinsic resistance to change in general and automation in particular. Add in a culture of self preservation on the part of management and … well, you get the picture.

    So there are industries that will be resistant—for a while, anyway. Then one of two things will happen. The companies that are not resistant to automation will enjoy the efficiencies the technologies bring. They will gain market share by providing a better product at lower cost and they will trample out the competition—think Uber and the taxi industry. Or, those resistant corporations will realize that to survive, managers who manage by “saving my job” will be given a golden parachute after revealing all the tribal knowledge hidden in their work groups. (Undocumented rules and processes are the bane of process engineers when implementing automation.) Either way, the march of automation will continue and workers will be displaced.

    Given the increasing rate at which jobs are being replaced by automation, will these displaced workers find other jobs? This question I leave to you to answer.

    — Bob Reselman

  • DevOps Chat: Maslow’s Hierarchy of Needs & DevOps with Omed Habib

    DevOps Chat: Maslow’s Hierarchy of Needs & DevOps with Omed Habib

    OK, I admit it. Thinking of Maslow’s Hierarchy of Needs and DevOps doesn’t seem like an obvious connection. But Omed Habib of AppDynamics gives us the connection of how Maslow’s theory applies to developers and DevOps people. Because after all, they are people too, right? Right?

    Anyway, this is a great conversation that I think you will enjoy. As usual the streaming audio of our conversation is below and the text is below that. Enjoy!

    Alan Shimel: One, two, three. Hey, everyone, this is Alan Shimel, devopsy.kinsta.cloud here for another DevOps Chat. Today’s guest on DevOps Chat is Omed Habib from AppDynamics. Omed, welcome to DevOps Chat.

    Omed Habib: Thank you, Alan. Pleasure to be here.

    Shimel: Thank you. So, Omed, I would imagine most of our audience is already very familiar, at least pretty familiar, with AppDynamics. You guys have sort of become just a huge success in the APM market, though some may call what you guys do not exactly “APM”—I’m not even sure if AppDynamics calls it “APM” anymore—but, nevertheless, company that’s had tremendous amount of success. What’s your role at AppDynamics?

    Habib: Well, I originally joined AppDynamics as a product manager. My first couple of years, very proudly brought our PHP, Node.js, Python APM agents to market. And, as of a couple years ago, I joined the product marketing team, so I’m now helping lead the strategy behind all of the outbound product responsibilities.

    Shimel: Sure. So, Omed, in simpler times, just three, four years ago, it was easy to put AppDynamics into that sort of APM bucket, if you will, but that’s not necessarily the case anymore, is it?

    Habib: You know, the term “APM” itself, like you said, is starting to put into question. What AppDynamics does, at least in my opinion, is very simple. I think what is becoming—the definitions that are changing right now are the processes within the software environments and where AppDynamics plays a role or, rather, where AppDynamics—sorry, APM as a concept plays a role. Historically, we’ve had divided teams, right—operations are responsible for production monitoring, and so they would have the production-monitoring tools; developers had their siloed environments—they would ship their code—and so they had their decouple tools.

    But what we’re starting to see now is a shift in runtimes becoming far more sophisticated, and the barrier to entry to production is so much lower now that developers and operations—I’m gonna introduce a whole new term; we call it—it’s not new, but I’m just gonna call it “engineering teams,” “application teams,” are now responsible for the entire software development life cycle of the product, so developers are now deploying code; operations folks are now responsible for not just the infrastructure and the production monitoring, but also they’re starting to look at everything from an application perspective, versus an infrastructure perspective.

    The other thing that I’m noticing, Alan, is that we’re starting to see far more abstraction here of the infrastructure and the deployment models of applications. In other words, teams are no longer responsible for spinning up servers and configuring hardware and configuring the specs behind the infrastructure. All of that’s becoming abstracted, and so it’s causing—again, I’m not gonna call it “dev teams” or “ops teams” because I see these two teams merging, I’m talking, five years, maybe possibly in 10 years, possibly even sooner than that, down the line. I’m just gonna call it “engineering teams.” Engineering teams responsible for the application, the product itself.

    And I see these roles starting to merge. We’re starting to already see _____ the ops responsibilities. You know, Google’s introduced the SRE role, right? The site reliability engineer. And the nature of that role is someone who comes from a developer background, facing the challenges of operations and the idea behind that is to have a developer mindset of “How much of this can you automate using code?” And so they’re trying to solve—again, it goes back to the abstraction idea, right? Everything becoming abstracted. So what they’re essentially trying to do is automate as much of the infrastructure as possible so that, end of the day, a developer can do what they do best, which is checking code and work on features and work on the backlog.

    What we’re seeing today, right now, is the crossroad of development teams starting to take a step back and realize that, “Hey, what the heck is going on here? We have this giant backlog full of features and we’re doing nothing but putting out fires all day long. We have bugs; we have performance issues; we have database issues; infrastructure issues.” Right? So if you were to look at it—[chuckles] it’s kind of funny. I get very Maslowian here, but if you look at Maslow’s Hierarchy of Needs, right?

    Shimel: Mm-hmm.

    Habib: I’m getting kind of philosophical here, but I got a point. [Chuckles]

    Shimel: No, no, go ahead.

    Habib: Maslow’s Hierarchy of Needs, essentially, states that everybody, every human with a purpose, goes through this journey, but they have to go through levels, and it starts with the foundational layer, right, into the second layer and a third and fourth layer. But the very top of that pyramid is what they call—what he calls “self-actualization.” And self-actualization is when you, as a human being, as a person, you get to actually do what you were on this planet to do, where you solve for everything else—shelter, security, your social needs, your physiological needs. And so you get to a point where you say, “Well, what is it that I was here to do to begin with?” Right? And so you get to actually work on the things that are larger purpose of you as a person.

    Developers, I’ve noticed, are actually going through a Maslowian hierarchy. The very premise, the very foundational premise, of what they do is their toolset—their development environments or sandbox environments, their pre-production environments—and so what we’re noticing here is that developers are starting to go through their own Maslowian-style pyramid, in that the foundation of the pyramid, essentially, is a development team solving for their proper development environments, sandbox environments, embracing a DevOps culture, ensuring a pragmatic, iterative software-dev life cycle, ensuring for proper infrastructure, making sure that they have the proper monitoring tools in place. And so, as they continue to move forward and advance from one layer to the other, they no longer have bugs in production, they’re no longer solving for bad code being shipped, because they’ve already solved for that. Right? The teams that have not are stuck at the bottom of the pyramid, and the teams that have advanced forward are hitting a point of self-actualization.

    And so, if I were to draw a parallel with Maslow, I’d say that developers—development teams, applications teams—today, have hit a point of self-actualization, which essentially says, “Well, what are you actually here to do?” And what you’re actually here to do, as a development team, is to work on moving the business forward—work on the backlog, work on the features. And what are those features? Those features come from a road map and have been prioritized, from business strategy perspective. So you’re essentially getting your development and engineering teams back in line with what they were there to do to begin with, which is “Now let’s start to move the business forward.”

    From a philosophical perspective, that’s what DevOps was to begin with, right? That’s what developers and operations teams are hired to do to begin with. Unfortunately, because of the lack of sophistication in the tools and the processes, what we’ve seen in the last few decades is that, developers and engineering teams and operations teams, they’ve been stuck in this rut on the first foundation of that pyramid or the second level of that pyramid. And it’s change blindness, right, from a psychological perspective. It’s, when something happens, some kind of change happens, so slowly over time, you don’t notice it whatsoever, and so you start—you eventually start seeing these development teams accept. Unfortunately, they’re trying to accept their roles as, “Yeah, I just fix bugs all day long.” Right? “I just put out fires all day long.”

    Shimel: Yeah.

    Habib: [Chuckles]

    Shimel: And you –

    Habib: That’s because you’re stuck at the bottom of that pyramid.

    Shimel: Yeah. And you know what? It’s funny you say that, Omed, because I’ve been in technology, oh, 25 years, and so we used to call it “They’re working in the sausage factory, but they really don’t know how we make sausage.” Right? And this happens. I see it in software’s life cycle and supply chain, where everyone kinda does their job but they don’t realize how their job is part of the larger picture. Right? If someone’s just stuffing meat in the sausage machine, in the back of the sausage machine, but they never see what the sausage looks like when it comes out or what it tastes like, it’s very hard for them to imagine or to empathize with the guy who has to eat the sausage. And, all too often, that happens, especially in software development. I’m sorry to say, but –

    Habib: Yeah, no, you’re absolutely correct.

    Shimel: Yep. So –

    Habib: What’s funny is that not only is the pyramid very similar to how software developers evolve, but Maslow also said that, if you’re stuck at any one of the foundational layers or, for example, if you don’t even have the foundation, that actually goes into the symptoms of what a person experiences. For example, if you don’t have a roof over your head and you’re constantly worried about the elements, right, the symptoms of that is gonna be anxiety and paranoia and discomfort, right? Development teams—I mean, you can draw the exact same parallel and say, “Well, if you don’t have a proper DevOps environment, then the symptoms of that are gonna be X, Y and Z,” right? Anything that is lower than self-actualization is gonna have symptoms, and those symptoms, obviously, are bugs in production, application issues, the backlog growing ever so bigger without you actually even touching it, technical debt increasing, so on and so forth.

    But it kinda reminds me—when you talk about the guy that works in the sausage factory, it reminds me of the famous story of the three—I might butcher the story, but it’s the three workers that were working on a cathedral. A passerby comes by and asks the first person, “What are you working on?” and he says, “Oh, I’m just—I’m working on this stone and I’m just hacking away at the stone.” And then he goes to the next person and says, “What are you working on?” He goes, “Oh, I’m just working on this wall, and it’s something that’s gonna be used on this home.” And he goes to—and, by the way, all three of them are doing the exact same thing.

    Shimel: Mm-hmm.

    Habib: He goes to the third person. He says, “What are you working on?” And he says, “Can’t you see? I’m working on a cathedral.”

    Shimel: Hmm.

    Habib: So, when you’re at the bottom of that pyramid, you lose sight of what you’re doing to begin with.

    Shimel: Got it.

    Habib: When you’re at the top of the pyramid, a point of self-actualization, right, where you’re supposed to be to begin with, where you’re supposed to be doing what you’re actually supposed to be doing, then you begin to realize the big picture. When you realize the big picture, then, as an engineering team, you are realigned back to the strategy of the business. And self-actualized engineering teams understand not just what they’re working on and how they’re working on it but also why they’re working on it. And with that comes the additional responsibility of, “Well, if you know why you’re working on it, then how do you measure success?” ‘Cause you already measured success at the bottom of the pyramid, for your application, but, if you’re now at the top of the pyramid—and, as a self-actualized engineering team, you’re not just measuring the success of the application, right—performance of the application, the technical performance of it—but you’re also measuring the success of the business performance of your application.

    Shimel: Sure.

    Habib: And that is what we’re starting to see today. A lot more engineering teams who are moving to the top of that pyramid are now getting reintroduced to having a seat at that table of “Hey, I’m not just a software developer. I’m not just an IT cost center. But I’m a partner in the business strategy behind this application.”

    Shimel: Yep. “And I deliver customer satisfaction.” Fantastic. This was a great—great conversation, Omed. Very insightful. Unfortunately, well, we’ve gone way over our time, but we’ll deal with it.

    Habib: [Chuckles]

    Shimel: Omed, we’d love to have you back on at some point, though, ’cause our audience is so developer-centric and ops-centric too, but “tech-centric,” I guess, is a better word, that I’m sure they identify with this, and I’d love to continue this conversation. So perhaps we’ll –

    Habib: Yeah, it was a pleasure chatting with you.

    Shimel: Yeah. We’ll find some time and do it—do more of it. Or maybe you wanna write about it on devopsy.kinsta.cloud. We’ll talk about it offline. Anyway, Omed Habib, AppDynamics, thanks for being this episode’s guest on DevOps Chat, and thank you for everyone listening, and we’ll see you again on another DevOps Chat. This is Alan Shimel for devopsy.kinsta.cloud.

    — Alan Shimel

  • DevOps Chat: DOES London 2017 Speaker Jose Quaresma, Accenture

    DevOps Chat: DOES London 2017 Speaker Jose Quaresma, Accenture

    In anticipation of the DevOps Enterprise Summit (DOES) London 2017, we are interviewing a series of the announced speakers who will be appearing there. The first in our DOES London 2017 speaker interviews is with Jose Quaresma of Accenture. Jose is a leader at Accenture and has a lot of knowledge on real DevOps transformations. I think you will find this conversation very enlightening.

    As usual immediately below is the streaming audio of our chat, followed by the transcript of our discussion below.  DOES London 2017 is shaping up to be another great conference. Also as usual, we will be live on-scene with coverage.

    Alan Shimel: Hey, everyone, this is Alan Shimel, Editor in Chief of devopsy.kinsta.cloud, and we’re here for another DevOps Chat. Today’s DevOps Chat guest is Jose Quaresma—and I probably messed that up, but Jose is with Accenture, and he’s based over in Denmark. Welcome, Jose—how are you?

    Jose Quaresma: Thank you, Alan. I’m pretty good. First of all, thanks a lot for having me. I would say it’s quite an honor to participate in this chat with you.

    Shimel: Oh!

    Quaresma: Oh, and yes—and by the way, you got the—

    Shimel: Well, flattery will get you everywhere.

    Quaresma: [Laughter]

    Shimel: But we’re talking a little bit today, and it’s regarding, you know, the second annual DevOps Enterprise Summit London is coming up June 5th and 6th at the QE2 in London, and you will be presenting there, correct?

    Quaresma: Yes, that’s correct—yeah.

    Shimel: And I wanted to—well, before we get into your presentation at DevOps Enterprise Summit, why don’t we give people a little bit of your background?

    Quaresma: Sure. I can give it a quick try. So, as you said, I’m Jose, and Quaresma is the last name, so you actually did pretty well, Alan. And I’m originally from Portugal, but I’ve been living in Denmark for almost eight years now. I kinda moved in here to study, and kinda after university, then I started Accenture here in Denmark as well, which I’ve been for around three and a half years now.

    I am an Application Development Associate Manager in Advanced Technology in a subgroup called Advanced Technology and Architecture, and I am the DevOps lead for Accenture Denmark.

    Shimel: Excellent. And Jose, as part of that, why don’t—any particular engagements of interest that you can talk about right now?

    Quaresma: Yeah. So I had, I can say, so, there were two main engagements that I’ve been involved with, and the first one was actually not so much involved in DevOps. I kinda started more as a middleware developer and kind of then walked towards the kind of web service design and team lead on that middleware area, and there was some DevOps work related there kind of with deploying the web services. But that wasn’t really something that I was driving.

    But then around two, two and a half years, I kind of, it was actually, my manager—and I guess I have to thank him for that; thanks, Jarom—he kind of, he was the one kind of guiding me towards, “Okay, we have this kind of DevOps domain getting a bit more traction, and we would like to, how would you like,” it was actually asking, “How would you like to lead that domain and try to raise a bit more awareness of DevOps here in Denmark?”

    So that was an interesting opportunity that I saw and yeah, from then, I was also then transitioned to a new project, which is actually the project that I’m going to co-present at DevOps Enterprise Summit now in London in June, and I’m co-presenting that with Amin Budali from Nordea, and that is the client that I’m currently working with, and this is a huge project. So Nordea, for the ones who don’t know, it’s a huge Nordic bank, being active in Denmark and Sweden and Norway and Finland. And this is, the project is about replacing their core banking application across the four countries. So it’s a huge project, a five-year project where we are working on replacing the core application with a new T24 application provided by Temenos. And that—

    Shimel: Go ahead. Go ahead, Jose.

    Quaresma: —and then that’s where kind of the more, it was, the DevOps, it has been very relevant now in this project, and the main thing is that, what we are, the part that we are presenting at DOES now, it’s, as I was saying, it’s not really a finished story, I would say it’s a story that has started around one year ago and we already have some interesting successes that I’m happy to talk about, but it’s hopefully a story that will have one, two, three more years until we have this very successful destination that I’m hoping I can come back to, to the DevOps Enterprise Summit and talk about that in one or two years. That would be great.

    Shimel: That would be great.

    Quaresma: Yeah, and that’s something I hope for, and I work for as well.

    Shimel: So I’d like to ask you, Jose, for our listeners out there who maybe are listening and saying to themselves, “Man, I sure would like to present one day at a DOES, you know, a DevOps Enterprise Summit or a similar thing.” Can you give our audience maybe a little bit of background on how it came to be?

    Quaresma: Yeah. I can try. So, it was actually, we have, this all kind of started with, we have a DevOps Week internally in Accenture as well, and in that internal DevOps Week, which was maybe one or two months ago, around there, maybe one month ago, we were actually, I was—I got to present this kind of, a little bit this story as well together with the client at our kind of internal DevOps Week.

    And then the idea came, from that point on, it’s like, “Oh, we actually have, there’s this really amazing conference in London. Why don’t we just try, maybe?” And we did have—I confess, we did have some doubts whether we would get in, and I think the main part is thinking that, okay, we don’t actually have this beautiful, happy ending story yet. We’re still struggling, we’re still halfway through our journey. But then, also, reading through the description, we saw that these kind of ongoing journeys are also welcome at the conference, so we thought, “Well, let’s write down the things that we have learned and what we would like to present, and then let’s see if they think that will be interesting.”

    Shimel: Got it. And sort of, you know, I think that’s a great description of the process and everything. Have you spoken at other events, Jose?

    Quaresma: No, not really. Not at this magnitude. I’ve given kind of more internal presentations and also outside Denmark, but not really, not an event of this magnitude. So yes, I’ll be pretty nervous. [Laughter]

    Shimel: What? There’s nothing to be nervous about. I’ve always found that as long as you are fluent in what you’re going to speak about, as long as you’re comfortable with that, you know, whether it be a big audience, a small audience or have you, it’s all the same, really.

    Quaresma: Yeah. That’s a good point. I’ll take that with me. And not only being fluent, but also that, I think it will help that I will be talking about something that I’m really excited about and that I’ve been working hard for, so I think that will make it a little bit easier.

    Shimel: Got it. You know, one of the things I wanted to talk to you about is, you know, working for Accenture, you—a little different than working for just a single company in that you work with multiple clients, right, and so that gives you a chance to see sort of transformational issues, you know, across multiple organizations.

    Quaresma: Yeah.

    Shimel: Where a lot of people, you know, they work at Disney or they work at NBC Universal or they work at a company and sort of very much—and even at jeans events like the DevOps Enterprise Summit, it’s very much, “Here is my company’s transformation story.”

    Jose, having looked at multiple companies’ transformations, what do you think you can share with our audience that sort of transcends any one organization, right, and go into multiple ones?

    Quaresma: Yeah, there’s—so, one thing is, I won’t lie to you or the audience. I mean, this is the first big DevOps transformation that I’m involved with, so I can’t really kind of pull out of my hat kind of the 10 transformations that I’ve been involved with and share some kind of overall wisdom on that.

    So this is definitely an advantage that I see and that I hope to use more in the future once I kind of, as you say, keep getting the experience of several different transformations in different clients with different scenarios, when you kind of—once you’ve started getting more experience with all those different transformations, there will always be things that are different, then I hope I can kind of learn from that and be able to extract some knowledge from those differences as well.

    Shimel: Sure, sure. Jose, we’re almost out of time. As I promised you, it goes really quick. But let’s talk for a moment about, and this is something—so you did it, when you started your career and, you know, you said you’ve been in Denmark now eight years. Certainly it wasn’t to do DevOps transformations and so forth, but where did you come from to get to here, kind of, if you know what I mean?

    Quaresma: Yeah, and that’s a pretty tough question. So, it’s kind of, my background is mostly on security and also related with—so my Master’s was actually called Security in Mobile Computing, and then I also had a, after that I had a Ph.D. in network security, mostly related with formal methods and how to kind of analyze the security of a communication protocol.

    But I think the, kind of my career evolution, if—[Laughter] I never thought about it like that, but if you can say that, it has been pretty, I would say pretty organic. I mean, I have—it’s not like I’ve been forcing myself or have this five-year plan that I think, “Okay, in five years, I wanna be there.” It has been mostly about doing the things that I kind of enjoy doing and that I can see that I’m providing some good value, and also following the interesting thing.

    So, for DevOps, it was actually that, before it was my work, it was already kind of a hobby in that I was at home outside working hours playing around with some Docker setup and trying out some different technologies there, and then I think that also made it easier to bring that to work, because if it’s something that I’m excited about also outside work, then it was even easier to just bring that excitement and motivation for something that I do in my everyday life.

    Shimel: Excellent. Well, Jose, I’m sure you’re gonna have a great presentation with the bank at DevOps London, DevOps Enterprise Summit London, and we’re looking forward to seeing you there.

    Quaresma: Yeah.

    Shimel: And thanks for being our guest on this episode of DevOps Chat as well.

    Quaresma: Yeah, thanks so much, Alan.

    Shimel: Thank you, and continued success, Jose Quaresma of Accenture, who is a speaker for DevOps Enterprise London 2017 on June 5th and 6th, our guest today on DevOps Chat. This is Alan Shimel for devopsy.kinsta.cloud. Thanks, everyone, and have a great day.

    — Alan Shimel

  • DevOps Chat: Dead-End Computer Languages with Scott Wilson

    DevOps Chat: Dead-End Computer Languages with Scott Wilson

    Scott Wilson from Automic is always a great source of knowledge around DevOps. I have spoken with him several times and he never disappoints. In this DevOps Chat, Scott talks to us about dead-end computer languages. Scott, who is a developer himself, often marvels at the explosion of languages available today and wonders how many will survive beyond the useful life of the applications that they are written in.

    It is a great point. We did a survey a while back that showed the average organization is supporting upwards of 10 + languages concurrently. Talk about tower of Babel. Well, Scott gives us some great background on this.

    Streaming Audio

    Chat Transcript

    Alan Shimel: Hi, everyone—Alan Shimel, devopsy.kinsta.cloud, here for another DevOps Chat. This episode’s guest on DevOps Chat is Scott Wilson of Automic. Scott, welcome to DevOps Chat.

    Wilson: Thank you, Alan. I’m glad to be here.

    Shimel: Yep, and Scott, we’ve spoken before, we’ve done webinars and podcasts in the past, and are fairly familiar, but for our audience who may not know who Scott Wilson is, why don’t you give us a quick background?

    Wilson: Okay, great. Thank you, Alan. I am currently the product marketing director at Automic Software, and basically, I am specializing particularly in DevOps and application release automation.

    I come from a pretty technical background. I started basically in high school writing code. I was a software developer for a long time, and you know, in many evolutions, different vertical markets of writing code, and I’ve evolved ultimately now into marketing, so.

    Shimel: That’s not such a bad thing, Scott. But [Laughter]—there are fates worse than death.

    Wilson: [Laughter]

    Shimel: But anyway, Scott, we were gonna talk a little bit today about, you know, sort of, we can call them dead-end languages—and by that, I mean, you know, it’s a great time to be a developer today. You have so many choices in what you want to develop.

    But, like anything else, you know, there will be winners and losers among development languages that you can choose from. And I know this is a—

    Wilson: Absolutely.

    Shimel: – yeah, this is a topic you’ve spoken and written on. So I wanted to kind of, you know, with that premise, why don’t you explain to our audience a little bit about what you’re talking about?

    Wilson: Okay. Well, you know, as I mentioned in the intro, Alan, I am no stranger to code, and I will admit I still write code on the side for various things here and there. And one of the things that has struck me over my experience, especially with talking with customers and even working for a couple of vendors for application release automation products is that, in DevOps in general, there’s this great level of interest and experimentation going on with languages. A lot of the ARA tooling provides ways for you to build your own plug-ins, for example, so that you can extend these products and extend their reach into building a nice, cohesive tool chain—a DevOps pipeline, if you will.

    And the challenge is, as I started looking at a lot of these products and a lot of the momentum in DevOps is, I started realizing that people are choosing languages that are kind of dead on arrival already. What really sparked my interest in this was not only my observation here, Alan, but I spoke with an executive at a large company, and he was telling me that they were having to rewrite a lot of their DevOps code—their deployment code, if you will—because the folks that had written their pipeline five years ago used a language that they can no longer hire people to write it. And so they’re having to scratch it and rewrite it again, and I have actually heard this theme a few other times as I’ve met with executives across the U.S.

    So that had me really diving in and trying to figure out, well, how big of a problem is this? There is—and I won’t name the company, but there is one area vendor that does offer a PERL toolkit, just for example, to connect to their API and interact with it. The problem is, PERL is a dying language. So, if—now, this vendor also does not exclusively demand you use PERL, but I just found it an odd choice that they would even support that, given its decreasing popularity. Additionally, I was at a Chef conference this last summer, summer of 2016, and they announced their new Habitat write platform, and it was all written in Rust. Again, another odd, obscure language.

    And so, Alan, what I did is, I went around and started looking to find out, well, why are some of these companies choosing a language and then five years later, not able to support the language and the tool that they have built it in? And there are several, it turns out, popularity indexes, Alan, and you can look around for these. There’s one called the Popularity of Programming Language, PYPL, and it’s listed on GitHub, and it lists all the popularity—languages by popularity and share. There’s the TIOBE index as well, and there are several indexes. Some of them compile indexes, I think—what is it? There’s one that is garnered by what’s called Coding Dojo, and several others that go look at job listings to see what are the most popular language requirements in job listings.

    And if you wanna get a good sense of this, actually, you can actually go to ZDNet.com. They wrote a great article that basically took all the different indexes, aggregated them, and put them together. And what’s interesting in their findings is that you don’t see PERL, you don’t see Rust, you don’t see a lot of these, I call them doctorate languages, meaning people going to get their doctorates in computer science wind up creating these languages and they each kinda have their own cult following, Alan. Which is cool in one respect, but in the other respect, it means that if you’re not careful, you can latch on to some programming language for your DevOps practice and wind up choosing a language that is in fact not sustainable. That’s a trend, and you wind up—

    Shimel: Certainly—so Scott, in the case of Rust and maybe some of the other more obscure kinda languages we run into, I get what you’re saying and I don’t disagree, but you know, when you look at PERL, you know, you and I are not 20-somethings, Scott, right? I mean, PERL has been around a long time, and in its day, you know, back in the dot com bubble, you know, PERL was the equivalent of PHP, you know? And recently I saw, I think PHP is out—PHP 5 or whatever is out there now.

    But, you know, PERL—if you would have asked me a language to bet on in 1998, I probably would’ve bet on PERL. You know, I wouldn’t think it would become obscure or obsolete—though, look, ’98, you know, we’re talking 18, 19 years, and certainly nothing lives forever.

    But how are people out there—you know, it’s so hard. We don’t have a crystal ball, right? And we do have these indexes, but how do we know, like, what’s the next hot one and which is the next dud?

    Wilson: That’s an excellent question, and just to provide me the story, Alan, of your, what you’ve pointed out—because there is no crystal ball, and it is tough—I think the whole IT industry right now, including programming languages, it really reminds me a lot of the turn of the 20th century when there was really no clear definition of what an automobile should look like. And there were various versions—Edison had his battery operated vehicle, and there were several steamers, there several combustion engines and there were lots and lots of losers, lots of investments that went bust.

    And it took, you know, basically a couple of decades, but by the time we hit the 1920s, everyone understood and knew what an automobile looked like, and it looked like and operated like a Model T, right?

    And so it’s really kinda tough right now. So what I like to do, or what I recommend in the context of what we’re talking about here with languages is to really look at where it’s trending and what its longevity has been. If you look at that, you know, Java, C++ are popular. That might be, C have had, and even JavaScript have had a great deal of sustained momentum over a couple of decades.

    You were right—PERL, at the time, was great, but according to the popularity index, it is as its lowest popularity point since 2001 and is continually trending down. PHP has been holding its own, and in the composite index, it is still listed as one of the more popular languages.

    And so, you know, I would be—frankly, if I were practicing a language to help extend my DevOps practice, I would definitely look at what things have been sustainable over the last several years—decades, rather—and really look at the trending. And that’s why—and not to sound too critical, but when I look at Chef, placing Habitat on Rust, for example, was probably not a great idea for the future. If you look at what languages have sustained over the last 20 years, it would have been better for them to have chosen Java, because you have a huge base of Java developers and you could have then had a much larger contribution base to the project. So I think there’s just things you can do like that.

    And then, you know, the other thing, Alan, to your point—and it’s very unsexy to say this, but there has been one kind of, I’ll call it quasi-programming interface that has spanned the entire test of time and has remained consistent. And it also, what’s neat about this, is I have observed, it transcends every IT specialist, and then as a command line interface or a CLI. I’ve found, in looking at this, that it was very interesting that one of the challenges of, let’s say, extending some new fad DevOps tool using a programming language is that it requires a programmer, and you have to understand the grammar of the language. And that usually silos the expertise that is capable, or readily capable of picking this up. Where, versus a command line interface, they were designed, frankly, for the use case to be readily understood and easily picked up, and they transcend everybody, whether you’re a software developer, a DBA—everyone kind of gets to very quickly understand how command line interfaces work.

    So I’d be, if I were trying to build my DevOps practice today, I would actually be more keen on looking at using command line interfaces, published ones, to set up a lot of my extensions and automation mechanics, just because they have transcended time and have the longest life span of any language, though I wouldn’t say command line interface is a language, it is an interface, right? But the nice thing is, they are mostly self-documenting, where the programming languages, you have to know the language to understand what it’s doing, and they’re generally not self-documenting.

    Shimel: Got it. Scott, I don’t wanna put you on the spot, but give our listeners, if you can, what you think are your top three choices for the languages to use, let’s say, in the foreseeable future.

    Wilson: Alright. Excellent question. Well, as always, it depends on what you’re looking to do. That’s what’s very interesting when you look at the indexes and the aggregates and the composites of these indexes is, it really depends. I look at languages a lot like tools in a tool shed. They do a specific thing. You wouldn’t want to write a web server, for example, in C. I mean, you could, but you know, it has diminishing returns.

    I would say, in the modern cloud that we’re in, the more popular languages that would support this are certainly Java, you’ve got Python, PHP, JavaScript and C# are amongst the more popular ones. They’ve been around for a while. C#, as you know, is backed by Microsoft, a big company, and is recently going open source, the .net platform is. It works on every platform—Mac, Windows, Linux, what have you. So that could be interesting. JavaScript, I mean, for its ease of use? I mean, goodness, it’s been around for quite a while. You’ve got services like Node.js in which you can run very sophisticated apps on it.

    I’d probably be looking in that tier for the modern, cloud-based apps—Java, Python, PHP, C#, JavaScript would probably be the languages I would be more keen on looking at.

    Shimel: Got it. So, Scott, believe it or not, we’ve kinda used up our 15 minutes of fame, here. But you know, this is an interesting subject matter, Scott, that I think many developers sort of delve in. You know, there’s the, I call it the shiny trinket syndrome where everybody wants to use the latest and greatest cool tool, but sometimes, you know, these fads fade out quickly and you’re left, you know, with a fantastic product that was developed in a dead-end language, or a fantastic app developed in a dead-end language. So definitely something to be wary of.

    Wilson: [Cross talk] Yeah, like I said, the languages that are great for creating a project, if you’re trying to do a lot of those DevOps automation mechanics, I would really, highly recommend looking at command language interfaces to stitch a lot of that together.

    Shimel: Yep. So, Scott, we’re gonna call it a wrap on today’s podcast. Obviously there’s big news going on with Automic and acquisition news and stuff, and maybe once the dust settles on that, we could have you back on and talk about that a bit.

    Wilson: Absolutely. I’d love to.

    Shimel: Until then, though, Scott Wilson, Automic—continued success, keep doing what you’re doing, and thanks for being this episode’s guest on DevOps Chat.

    Wilson: Thank you, Alan. Have a great day.

    Shimel: Alright. This is Alan Shimel for devopsy.kinsta.cloud for DevOps Chat, and thanks for listening and we’ll see you on the next chat. Bye bye, everyone.

    — Alan Shimel

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Sharma: Thank you.

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

    Sharma: Sorry. [Audio breaks up]

    Shimel: Did I break up there? I apologize.

    Sharma: Could you repeat that?

    Shimel: Sure.

    Sharma: I’m sorry.

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

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

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

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

    – but you have to disrupt it.”

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

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

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

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

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

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

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

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

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

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

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

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

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

    Shimel: No, of course I wouldn’t.

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

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

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

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

    Sanjeev Sharma –

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

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

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

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

    — Alan Shimel