devopsy.kinsta.cloud

Author: Alan Shimel

  • GitLab Responds To GitHub Making Teams Free – We All Win

    GitLab Responds To GitHub Making Teams Free – We All Win

    Microsoft’s GitHub recently announced that it was going to make a change to its product lineup by making the team version of GitHub free and lowering the price on a full-featured version. The move seemed aimed squarely at matching GitLab’s offering. Well, now GitLab has responded to GitHub.

    While both of these excellent offerings compete to bring the best product to market, the real winners here are all of us. True market dynamics are at play resulting in both GitLab and GitHub lowering prices and adding more features (and not just GitHub and GitLab but also their competitors, including Atlassian among others).

    I had a chance to sit down with Sid Sijbrandij to discuss GitHub’s move, what GitLab will do and what this means for the market. (BTW, I have to apologize to Sid—it seems I have been mispronouncing his name for years and he is too much of a gentleman to correct me. The proper pronunciation of his name is “See Brandy.”) The video of our conversation appears below, and a blog on the GitLab site explains it all.

    In our interview, Sid was very clear that GitLab owes a huge amount of gratitude to GitHub, as it was GitHub that spurred on the early development of GitLab. He truly respects what GitHub has done, as well as the great job Microsoft has done since acquiring GitHub.

    The GitLab blog post lays out very clearly what the GitHub offering is and how it compares to the GitLab offering. It’s no coincidence that the new GitHub paid teams offering is the same price as the GitLab bronze offering.

    Price aside, according to Sid, the real advantage of GitLab is that its vision of an end-to-end total DevOps solution and the features it adds to achieve this vision give GitLab customers more than they can get from GitHub. While I agree that is true today, I don’t think GitHub is going to be content with its current lineup for long. I think the Microsoft entity already envisions a total DevOps solution as being part of GitHub’s future.

    On top of that, I think GitHub and Microsoft are already thinking of how they can leverage Azure to give GitHub an advantage. To Microsoft’s credit, though, at least until now there has not been any special advantage of using GitHub with Azure. Azure remains an open platform that all vendors seem to get fair access to and support from.

    All of this aside though, we are all the real winners here. What a great time to be a developer/DevOps professional. While GitLab and GitHub compete with each other to bring more features to market for less money, as I mentioned other companies are competing to bring end-to-end DevOps solutions to market as well. We benefit from all of this competition by getting better tools and solutions at better prices. That’s true market dynamics at work.

    It should get only better in the months and years ahead as well. In spite of COVID19 and the rest, it is a great time to be alive.

    — Alan Shimel

  • Digital.ai: The Companies Formerly Known As XebiaLabs and CollabNet Plus

    Digital.ai: The Companies Formerly Known As XebiaLabs and CollabNet Plus

    Another shoe has dropped in the continuing story of TPG Capital‘s foray into DevOps. The company formed by the merger of XebiaLabs and CollabNet VersionOne is now Digital.ai. Additionally, the company has acquired Arxan, a leader in application protection.

    Digital.ai logo

    I had a chance to catch up with Digital.ai’s CEO Ashok Reddy and Arxan COO Mark Lorion, who will be Digital.ai’s COO of Platform going forward. The video of our discussion which is also available on TechStrong.TV, appears below.

    What They Said

    Reddy made it very clear that Digital.ai is not content with simply adding this AppSec company to the mix. It is actively involved in due diligence operations on several other acquisitions. Reddy and the TPG team feel that the current COVID-19 situation affords those with cash to pick up some bargains. That may have been the case with Arxan, which was owned by private equity firm TA Associates, which acquired Arxan in 2013 for $132 million. TA may have decided it was time to get off the merry-go-round, given the unsettled state of things right now.

    In any event, TA’s loss is Digital.ai’s gain. Arxan adds some much-needed security muscle and a blue-chip bank customer list. But, of course, the real play here is building out the end-to-end DevOps company that will compete with GitLab, GitHub, CloudBees, JFrog and others. We detailed this market in an article when the original merger was announced.

    My take is that indeed Digital.ai is not a complete company just yet. It may not even be done in the DevSecOps space, as Arxan is not your typical DevSecOps technology. It may have been more of an opportunistic acquisition.

    Also, in terms of executive team, Reddy has been quietly assembling a team made up of some of the best people he worked with at previous stints at IBM, CA/Broadcom and the executives from the acquired companies.

    Stay tuned for more on Digital.ai’s continued evolution in the months to come.

    — Alan Shimel

  • DevOps Chats: DevSecOps and OpenShift, with Red Hat

    DevOps Chats: DevSecOps and OpenShift, with Red Hat

    In this DevOps Chats, we had a talk with Kirsten Newcomer, senior principal product manager at Red Hat. It is a great discussion on the state of DevSecOps and how the Red Hat OpenShift team is trying to make it easier for developers, DevOps and cyber folks to work together to create more secure applications.

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

    Transcript

    Alan Shimel: Hey, everyone, it’s Alan Shimel, devopsy.kinsta.cloud, Container Journal, Security Boulevard—you’re listening to another DevOps Chat. Welcome, and I’d like to welcome to our DevOps Chat Kirsten Newcomer of Red Hat. Kirsten, welcome.

    Kirsten Newcomer: Thank you, Alan. Great to be here. So, I’m Kirsten Newcomer as you said, Red Hat. My focus at Red Hat is DevSecOps for cloud-native applications, been working at Red Hat for about four years now. It’s really kind of fun. I’ve managed to leverage kind of my—all sorts of different elements of my background over the years. I spent time at Rational Software, nine years, working on developer tools.

    Shimel: Sure.

    Newcomer: Yeah. Spent some time with BMC BladeLogic on the operations side of the world, seven years at Black Duck Software focusing on solutions that help companies manage vulnerabilities in open source software, and that led to the move to Red Hat where I get to focus on OpenShift security and DevSecOps and sort of everything comes together. So, DevOps—

    Shimel: It really does.

    Newcomer: Yeah.

    Shimel: I mean, following your career, I think I know just about all of those companies intimately and know a lot of people—I’m sure we even have a lot of people in common that we’ve worked with.

    Newcomer: I bet we do.

    Shimel: It’s funny. So, you were at Rational, left Rational only to return to IBM Rational.

    Newcomer: I know! [Laughter] That is true.

    Shimel: You know, it’s the circle of life right there, man. [Laughter]

    Newcomer: It is the circle of life, yep.

    Shimel: Welcome. So, Kirsten, look, DevSecOps is of course something near and dear to us. We put on every year at the RSA conference our DevSecOps Days or DevOps Connect/DevSecOps Days.

    Newcomer: Uh-huh.

    Shimel: We actually have the virtual event of that live on Thursday, I think it’s the 26th, March 26th.

    Newcomer: Nice.

    Shimel: So, you know, it’s something, quite frankly, this whole security thing is the reason I got into DevOps is, I thought—what a great opportunity for security to cure a lot of original sin.

    Newcomer: Absolutely. [Laughter]

    Shimel: But anyway, you know, when we look at the DevSecOps and the DevOps world, Kirsten, you can’t help—you must take notice of the impact that Kubernetes and the whole cloud-native kind of movement has had on this.

    Newcomer: Okay.

    Shimel: And a great—

    Newcomer: Absolutely, no—big changes, yeah.

    Shimel: And, you know—and it’s really at the core of so much of what is being done right now from an infrastructure point of view. And oftentimes, I don’t know if people—like everything else, right? I remember when the cloud came out and we moved from client-server and all this. Security, there’s always that lag, right, where, “Oh, yeah, we gotta do security with this.”

    Newcomer: Yep.

    Shimel: And we had a little bit of that with Kubernetes, I think, where—

    Newcomer: No, I think that’s fair.

    Shimel: Yeah? You know, people were rushing to do Kubernetes and experiment with it, deploy it, and then someone started saying, “Wait a second, what about security, here? What about compliance? What about this or that?”

    Newcomer: Yeah.

    Shimel: And now, I will tell you, and I’m interested in your opinion—I thought the lag time was much shorter this time than what we’ve seen in the past.

    Newcomer: Oh, I absolutely think so. And I think it’s really interesting. A couple of things that I’ve observed. One is that I really think containers and Kubernetes have created a terrific opportunity to shift security left, and I’ll kinda be more explicit about that in a couple ways. But I, in fact, have worked with a chief of cyber defense in the public sector who believes and evangelizes that containers improve security, and I’ve stolen his line, because I just actually think that that’s really valid.

    Because of the changes in the model, with the OS dependencies and the run time, everything’s kinda packaged together and you have that immutable container image that you’re always deploying from, you really can manage things in a new way and not every team is ready for this, and not every team, not every security vendor is ready for this, either.

    So, I think the opportunity has been twofold. One is to kind of adjust the thinking about security so that it no longer becomes something that happens at the end, but that’s still a process, that’s still a lot of work. And the other thing is, the security tooling space itself has historically been pretty siloed, right? There’s been, you know, the OS layer security, the network layer, there’s been kinda—you know, my SIEM and my SOC that I’m working with, and my cert management and my vaults.

    And none of them really were designed to work with the level of automation that Kubernetes and containers enable, which led to this really interesting opening for smaller companies, a lot of startups that now have been around for a little while, actually, to start breaking down those silos and delivering security capabilities in a new way that kind of really do fit the DevSecOps model, because you get kinda one vendor bringing a set of capabilities that ranges from CI/CD integration to run time security to network security, really fascinating space to see how it’s been evolving.

    Shimel: It really has. The other thing that I will tell you, Kirsten, that I was again encouraged by was when I first started seeing people talk about security through containers and Kubernetes, it really was like—let me scan your container for vulnerabilities, right?

    Newcomer:  Yeah. [Laughter]

    Shimel: And I’m thinking to myself—I don’t care whether my code’s in a container or in a hypervisor or on bare metal. A vulnerability scan is a vulnerability scan. There’s gotta be more to this than just a more vulnerability scan kind of a thing.

    Newcomer: Absolutely. And that’s, I think, where, as you mentioned earlier, that, you know, Kubernetes really has come a long way in that space. So, there are things like, if we think about—so, absolutely. Vulnerability scans are fundamental and kinda, people always understood those. They tended—historically, they’ve happened a little too late in the life cycle, making challenges for the AppDev team and such.

    We’re seeing that shift left a lot, but then there’s all these other range of things that you should be doing and can be doing to build security into the platform. And so, when we saw pod security policies in Kubernetes, for example, that’s a way that the Kube admin can take advantage of the Linux features that enable container isolation at the Kubernetes layer and enforce things like ensure that a container doesn’t run with unnecessary privileges.

    Shimel: Sure.

    Newcomer:  And so, we are seeing more capabilities—now, that’s still beta, so the community still has some work to do there. But as you say, we’re seeing more emphasis and, you know, the open source Kubernetes security audit sponsored by the CNCF is a great example of that.

    Shimel: Oh, absolutely. And look, CNCF has done yeoman’s work here. They’ve really, really done a nice job with the whole Kubernetes project, specifically security.

    You know, but one of the reasons, like—we did a webinar yesterday for instance and it was on, you know, the different cloud providers versions of Kubernetes and—

    Newcomer: Uh-huh.

    Shimel: [Cross talk] environments. And, you know—fantastic, we had 700 and something people sign up for this webinar.

    Newcomer: Great.

    Shimel: A lot of great questions, even on the YouTube afterwards, a lot of great questions. One of the things that became clear to me in listening to people talk is that—you know what? Just going to, whether it’s AWS or Azure or GCP or whatever and setting up my Kube environment may not be the best thing for me because I’d rather get one of the package distributions, if you will, or a more complete solution, of which Kubernetes is a piece, like an OpenShift, but some others were mentioned—Rancher and so forth.

    Newcomer: Sure.

    Shimel: But OpenShift was the most popular one mentioned. And I think one of the reasons is, people want to know that security has been kinda built into it.

    Newcomer: Yeah.

    Shimel: Beyond just the Kube release, whether it’s 1.4, 1.5, what have you, 1.6—you know, what else has been wrapped around that just K8—

    Newcomer: Yeah.

    Shimel: —to make it easier?

    Newcomer: Absolutely, and that’s been a big focus for us at Red Hat, really, from the beginning. You know, an enterprise solution—and this is a place where, so, we’ve talked about changes in the security tooling that needed to be made to adjust to the technology, but by and large, the principles still apply. You know, you still need audit logs, right? You still need, you know, to log data from the cluster itself. You need log data from the applications. You need monitoring tools. And so—and you need to think about host arrest security as well.

    And so, we’ve kind of really looked at the stack as kind of spanning all of those things, and we want to make it as easy as possible to manage that solution as a solution, right? And so, that if you—and plenty of folks do this, you know, and get value from it. But if you’re in a situation where you can afford to kind of do a DIY Kubernetes and add in a logging stack and add in kind of all the different pieces that you really need for the enterprise solution, then you have to maintain them each separately and you’re maintaining the host OS separately as well.

    And so, we’ve really focused recently, especially with OpenShift 4, on automating everything, which includes the host operating system. So, Rel CoreOS, Fedora CoreOS available as an open source project. It’s a container optimized operating system that we manage as part of the full platform. It makes it much easier to apply OS updates across your cluster. You can do that in a way that has zero downtime for your well-behaving apps. You can take a node out of service in the way you would, you know, that Kubernetes manages it. Update that with a patch to OpenShift or its components or the operating system itself, put it back in service.

    And so, kind of a combination of looking at the whole stack holistically, what is an enterprise need in order to ensure that they have a secure environment, a stable environment, a highly available environment and making sure that we kind of leverage the terrific declarative and automation capabilities of Kubernetes kind of throughout the whole stack.

    Shimel: Absolutely. You know, I didn’t realize just really all of—you know, until you just said it, I never kinda put together all the pieces of what you guys are doing with that. It’s pretty amazing, isn’t it?

    Newcomer: It’s really cool. And one of the other fun things that we get to do is, we actually—so, back to, if we think about the host OS layer for a bit, right? If you need to scale your clusters, that means adding a new host and you’ve got the work involved to be sure that you deploy that infrastructure and that you secure that infrastructure according to your standards and then you put Kubernetes on top of it and add it to the cluster and you’re ready to put workloads on it.

    And we’re using the concept of Kubernetes operators to automate the components of OpenShift, including the host OS. So, we have a machine config operator, so if you’re deploying OpenShift in a cloud where you can automate the addition of infrastructure easily, you can use the machine config operator and the declarative nature of Kubernetes, right? It’s a container optimized OS, it’s delivered primarily as container images, the user space is read-only, you’ve got that declaration of what a host should look like and you can just use the machine config operator to spin up new hosts and add them to your cluster.

    Shimel: Excellent. You know, we would be derelict in our duties, I guess, if we didn’t mention the whole COVID-19 and how that’s affecting things.

    Newcomer: Fair enough, yes.

    Shimel: In my mind—so, first of all, I don’t think a lot of what we’re seeing right now and its effects are necessarily three-week or six-week or, you know, a lot of this stuff is gonna stick.

    Newcomer:  Yeah.

    Shimel: I think one of the things that are gonna stick are, people are gonna want more automation, right?

    Newcomer: Absolutely.

    Shimel: In their deployments, in their operations, in their infrastructure.

    Newcomer: Yep.

    Shimel: And automation, from a security point of view, is kind of a double-edged sword, right? At least we, from—when things are automated from a security point of view, we think we know exactly what’s gonna happen, and so we can plan around that. On the other hand, security people tend to get a little fritzy, you know, when things come out of our cold, dead hands, here.

    Newcomer: Yeah.

    Shimel: What do you think? How—what do you think?

    Newcomer: I know; I agree with you. And I think one of the things that, one of the ways that Kubernetes is kinda pushing the boundaries with security teams. And I talk to a lot of different security teams over time. So, it’s kinda like—you know, they’re a little bit more comfortable with the idea of DevOps for the application layer at this point, right? For those containerized apps that are gonna be deployed, it’s like—okay, they kinda have an idea of, “Yep, security static analysis tools, integrated vulnerability scanners integrated.” There’s some cool new stuff coming out that I’m seeing on the market, they’re tools that are starting to evaluate the configs and the Dockerfiles, too, that’s really great.

    But—and then as we continue to move into the ops space, right, with Kubernetes and the SDN, which is required for any Kubernetes cluster, and now we have service mesh added into the mix, or Istio for microservice based communications. The network security teams are uncomfortable with who’s gonna manage network policies at the Kubernetes layer and now, I’ve got service mesh or Istio policies as well, and who’s responsible for those?

    And in the end, it’s really about visibility. So, if we circle back to automation, we’re really looking at infrastructure as code, you know, GitHub’s model that applies again to the Kubernetes layer, to the configuration of the Kube cluster as well, and we need to put in place, you need the automation to get the best results, but you need to do it in a way that gives the security team visibility into the kinds of things they’re used to seeing.

    And so, I think this is another way where we’re starting to shift left in new ways, and I’m also seeing solutions that help automatically generate network policies based on evaluating an environment or an automatic generating service mesh policies based on evaluating the config for the apps.

    But all of that, you know, the network security guys aren’t necessarily gonna log into the cluster to look at that. So, how do they get the view they need to get, and how do they help the AppDev teams understand that whole risk management and their security perspective? And so, this is where it’s not just about tools, it’s about people and processes, right? And I think there’s so much richness here, but you’re absolutely right—we can’t do it without automation. And so, we’re gonna have to help these people become comfortable with this shift while ensuring that they get the visibility they need to know that things are being done in a way that meets their risk guidelines, their regulatory requirements, and the security posture they want.

    Shimel: So, to me, one of the fundamental things with DevSecOps, one of the fundamental shifts in DevSecOps is, first of all, security people recognizing that they’re not the only ones who care about security.

    Newcomer: Mm-hmm.

    Shimel: Believe it or not, the developers and the DevOps folks, they do care about security. They may not be security trained people, but they care about security.

    I think the second thing with that is, the developer people have to realize, and the DevOps teams have to realize that the security people aren’t there just to be the roadblock.

    Newcomer: Right.

    Shimel: And they aren’t always gonna be the people who say no.

    Newcomer: Right.

    Shimel: And what we’re—so, this has nothing to do with technology, per se. This is a people to people issue.

    Newcomer: Absolutely.

    Shimel: And I think we’re making real progress in that, and as a result, what we’re seeing is security people paying for and approving security tools that developers in DevOps teams are using—

    Newcomer: Yeah.

    Shimel: —on the Kubernetes platform—

    Newcomer: Yep.

    Shimel: —you know, because that’s kinda the platform of choice now, and that, to me, that’s what keeps me optimistic about this.

    Newcomer: Yeah. No, I’d agree, and also, when we think about the broader landscape, I mean, there’s, the security threats are just ever-evolving, ever-changing. And there aren’t enough security trained professionals to go round, right? There aren’t enough cybersecurity folks, et cetera.

    And so, we have to figure out, how do we help teams scale, and collaboration is the way to do that. And you’re right, I see the same thing you do, right, that the security team is approving those tools that are container native, Kube native tools that help to ensure. And in some ways, I don’t mean this in a negative way, but in some ways they kind of are pushed into that because they’re traditional tools that used to be used kinda at the back end of things aren’t effective in the container and Kubernetes world.

    And so, they really do have to go with this shift that we’re seeing in the vendor landscape, and it just opens up this terrific opportunity, though, for that collaboration and that shared knowledge which, you know, is an adjustment for people sometimes.

    Shimel: Yeah, agreed, agreed. Kirsten, when we first started, I said, you know, the time goes really quick, I’m only gonna keep you here 15 minutes—well, that was 21 minutes ago.

    Newcomer: [Laughter] Okay.

    Shimel: We—yeah, we did it. Alright. We’re gonna have to call a wrap on this one. Maybe we’ll have you come back another time and we—

    Newcomer: It’s a plan!

    Shimel: —can continue the conversation there, good?

    Newcomer: Great. It was great fun—thank you so much, Alan.

    Shimel: Thank you.

    Newcomer: Alright.

    Shimel: Kirsten Newcomer, Red Hat, our guest here. This is Alan Shimel for devopsy.kinsta.cloud, Container Journal and Security Boulevard. You’ve just listened to another DevOps Chat. Stay well, everyone.

    — Alan Shimel

  • DevOps Chats: Swiss, Simple Secure Collaboration with Adeya

    DevOps Chats: Swiss, Simple Secure Collaboration with Adeya

    The current situation with so many working from home has shined a spotlight on potential security issues with many of our collaboration solutions. Adeya, says they have the answer, offering Swiss, simple collaboration on a military grade scale.

    I sat down with Francois Rodriguez of Adeya’s executive team to discuss what makes Adeya both simple and secure, as well as what the offering is all about. This is more than video conferencing by the way. This is a well developed and tested collaboration suite that has been in use by the Swiss military and others for years. Have a listen and check out Adeya.

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

    Transcript

    Alan Shimel: Hey, everyone, it’s Alan Shimel for devopsy.kinsta.cloud. You’re listening to another DevOps Chat. We’ve got a new company to introduce you to on today’s DevOps Chat, and the name of the company is Adeya. I hope I didn’t mispronounce that, but my guest will give us the proper pronunciation. I’d like to introduce you to Francois Rodriguez, he’s the chief growth officer at Adeya. Francois, welcome.

    Francois Rodriguez: Thank you for hosting us.

    Shimel: Thank you. So, Francois, did I get the name right?

    Rodriguez: Yeah, correct. The pronunciation is correct. Americans tend to say Adeya, but yes, Adeya is correct. [Laughter]

    Shimel: Okay. Well, you know, I always thought I had a little bit of a French accent. [Laughter] But I’m glad I got it right, then. So, let’s start with the obvious, Francois. Our audience may not be familiar with Adeya. Why don’t you, if you don’t mind, give us a little background?

    Rodriguez: Yeah, the background of the company is the following. So, it is a spinoff from EPFL. EPFL is one of the top five universities in technology in the world, based in Lausanne, so next door. So, for those that don’t know where Lausanne is, it’s next door to Geneva. And from that spinoff, the ask was for encrypting voice communication for the Swiss Army at that time, using a Symbian Operating System. At that time, Nokia was the leading mobile phone operating system, and that was the foundation of the company.

    With the advent of the smartphones, the application has been enriched with messaging and then the mobile application becomes, as well, a desktop application, a tablet application, enabling as well file sharing, instant messaging and we’re introducing as well video conference calling, end to end encrypted. So, that’s the most important element of the suite is the encryption layer, initially deployed and developed for the Swiss Army, so we are using the highest grade of encryption, so called military grade. And we are bringing that technology to companies and small organizations as well.

    Shimel: Excellent. So, the Swiss Army is already a customer, is that correct?

    Rodriguez: It’s the historical customer.

    Shimel: Okay. And then, at this point, has the company raised venture capital? Is it self-funded? What is the situation?

    Rodriguez: Yeah, it’s a venture capital, which is important in this type of business. You certainly have heard the news of cryptogate that was having some links with governments. So, these days, it’s very important when you provide this type of technology that you don’t have strings with any organization state owned or having any back door.

    Shimel: Sure. Sure, I mean, everyone’s worried about that. And, you know, as—well, before we jump more into that, Francois, what about your personal background, your journey? How did you come to be chief revenue officer—excuse me, chief growth officer at Adeya?

    Rodriguez: So, I started my career in telecom. At that time, I was in charge of developing the multimedia content for the youth and student populations. Before the advent of the smartphones, multimedia was games, ring tones. I don’t know if you remember these days.

    Shimel: Sure, I do.

    Rodriguez: And then we developed the music content, the early days of .mp3s. And moving forward, I professionalized my expertise in multimedia, transforming application into more professional applications. With the arrival of the tablets, we develop more and more professional application for enterprise, and then I joined a brand new spinoff from Airbus Enceda to bring connectivity on airplanes. The company used to be called OnAir.

    Shimel: Mm-hmm.

    Rodriguez: You’ve got Gogo in the U.S., so it’s a similar company, providing connectivity to passengers, multimedia and content to passengers, but as well, professional application for the cabin crew, electronic flag backs for the pilots, and more recently, IUTs connecting landing gear, engines, and any data that the airplane was generating.

    Shimel: Sure. Fantastic.

    Rodriguez: I joined Adeya in 2016.

    Shimel: Also, how long has Adeya been around for? I didn’t realize. When was Adeya founded?

    Rodriguez: 2007.

    Shimel: Oh, really? So, it’s been—so, this is not some fly by night, started yesterday company. You guys have been at this a while.

    Rodriguez: Yeah, exactly. Yeah, the brand awareness is really recent, because the typical client of Adeya used to be governments that are quite shy to do any marketing around, and it’s really when I joined the company that we started the blocking and enterprise product.

    Shimel: You know, in some ways this reminds me of—so, I’m a little older than you. [Laughter] But, you know, back when we had the AOL message rooms or chatrooms, whatever—they called them meeting rooms, maybe, before then. It was a rather innocent time on the internet where people didn’t realize you can’t let your children go online and just go into some chatroom with people you don’t know and what can go on there. And of course, we saw horror stories of what people were writing in chatrooms being made public or used the wrong way or predators, you know, preying on women and children and stuff. And because—well, it’s the reason why we can’t have nice things, right? There’s always bad people trying to take advantage of things.

    And then, as a result of that, you know, we saw a locking down, if you will, somewhat, of a lot of that kind of technology. But then, I guess it’s just human nature, people want to communicate, right? People want to communicate—even, God knows now, when we’re all locked in our houses, right, people want to still communicate. Being alone and isolated is just kinda foreign to the human condition.

    Rodriguez: Yeah, you’re right. So, I used to put an application on my daughter’s phone to lock the phone after an hour. These days, we’re up to three hours, because, you know, they need to communicate. They don’t go to school any more, so they need to be connected to friends, they need to chat, they need to send pictures, to send videos, to do video calling. These days, video calling is very important for the youngsters. I’m usually not a very big fan of video calling, but they are, so those are—

    Shimel: No, they’re native. They’re native to this, right? To us, we look at it and—actually, I was having this conversation with my COO this morning, talking about, we both  have children who are in high school, college now and in university.

    Rodriguez: Yes.

    Shimel: And, you know, they’re net native people who, the idea of doing video calling, the idea of listening to podcasts and so forth, this is how they’re used to consuming, right? And [Cross talk].

    Rodriguez: They’re used to the technology, they’re used to the technology and they’re also very tech savvy in terms of what features and functions those tools can bring, and they are very, very, I would say, picky on which tools they’re gonna use. And we’ve seen that in certain companies that there is a kind of step back when they propose traditional tools that are quite clunky, quite difficult to use, very slow that you need to put the VPN around and all these old fashioned or traditional tools have been rejected by the young population of workers.

    Shimel: Yeah.

    Rodriguez: And more so now with these days of remote workers where you have, you know, a layer of Bring Your Own Device on top of it where people are installing their own favorite applications, too. It’s very difficult to control. It’s very difficult to put security around when you don’t have a clear policy on what is allowed, what is not allowed, and more so when you don’t bring options. People are starting to download their favorite tools online. Obviously, security is not their top priority, it’s to make their work easy and fast and provide agility to the organization. So, that’s a real issue.

    Shimel: I agree. And you know, I mean, but this is a classic security conundrum, which is, if we just think we’re gonna lay down on the tracks and say, “Stop!” the train runs us over, right? We can’t stop that, so what we need to do is, instead of being the people who say no, we need to be the people to say, “Yes, you can, but here’s a secure way of doing it that maybe isn’t too cumbersome, too expensive, and still allows them to do what they need and want to do from a communications perspective.”

    And I guess, really, that’s what the whole Adeya thing is about, right, is—hey, you wanna video or do voice calls or, you know, messaging, you can still do that, and we understand it’s important. But here’s a way of doing it in a more secure fashion.

    Rodriguez: Yes, security is important, but what we’ve been putting at the heart of the development is the user experience. Because there is a lot of tools in the security space in the market, but very few of them are really providing a seamless experience for the users, and more so when they’re not IT people. Because IT people will always tell you, “That’s very easy, you go in Settings, you configure that, and you put the VPN around and it’s working,” when in fact, nobody knows how to do it.

    So, what we’ve been doing is to bring in one unique application, I’m calling the Adeya like a Swiss Army knife. In one tool, you have got different features. You don’t need to have, you know, upswinging. You don’t need to have configuration. The security layers are ___, you instill it in your device, and you start triggering the feature that you want to use.

    Shimel: Absolutely. Francois, if you could share with our audience, you know, how easy and how much does it cost if you wanted to use the Adeya solution? Let’s say—look, I’m a little worried about our use of Slack and/or Zoom for corporate communications; you wanna use what you wanna use with your kids or whatever, that’s one thing. What does it take to stand Adeya up?

    Rodriguez: So, we’ve got four packages, depending on the security layer that you want to activate. So, the starting price point is $4, the $4 is already, you know, the starter package that provides you one to one video calls, security voice over IP, instant messaging, and as well, you know, all the Dropbox and Lockbox where you can store some documents.

    If you want to have the video conferencing with multiple users, you have an extra option, and if you want to install everything on premise on your own data center, and this is what we do for governments, there is an extra cost to deploy the system, but it’s your entire system, okay? You have no backdoors, no cloud act to open up your data center to foreigners, and you have everything in your house. So, that’s the model that we do.

    So, we’re starting with a very easy to set up cloud solution based in Switzerland and we use the strength of the cloud infrastructure in Switzerland with the data sovereignty, and we go up to deploy your own system on prem.

    Shimel: Really, okay. So, there’s sort of a cloud-based system, if you will, SaaS or cloud-based, and then you have a choice of on-prem. Because I know in many government situations, as you mentioned, they don’t want to share public infrastructure, right?

    Rodriguez: Yeah.

    Shimel: And so, that’s a real requirement. So, Francois, I’ve got to ask you, I mean, it seems like the Adeya system would find a very fertile ground in today’s environment with what’s going on with COVID, with people working from home and everything else—how has this affected, or how has Adeya responding? What are you seeing in the market recently now, just in the last couple weeks, as a result of the pandemic?

    Rodriguez: So, what we see is a variety of demands coming from the historical clients which are government administrations that are really expanding the fleet. It’s not, you know, just to secure a certain special project, but it’s really to provide everyone the tool to work from home, and in the most important security layers. Because, as soon as you leave the government institutions, you need to be connected from whom, with high level security, because then you bring the formation outside the typical firewalls, and this is what the governments are fearing.

    Now, the diversity that we’re seeing is that we start having—hello?

    Shimel: No, no, it’s okay. People are blogging, I have a meeting coming on.

    Rodriguez: Okay, understandable. What we see is, enterprises now coming to equipping their entire organization and not just the top executives that used to travel a lot or go to countries where they need to shield their communication, but as well to protect their messaging, to protect their messaging, to protect the documents that they’re sending, avoiding sending them over e-mail because even though e-mail has been encrypted for several years, it’s very difficult to have the IPs working because the systems are not interworking together, depending on the operator that you use. If one side is using Gmail, the other side is using Microsoft, you don’t have interworking with encryption, for instance.

    Shimel: Sure.

    Rodriguez: This is the—we try to ease the experience with this type of situation. What we see now is the remote workers as well, the employees themselves are contacting us to, “Hey, I heard about your solution. Give me some documentation that I can bring to my IT people.”

    Shimel: Well, that’s the way it always comes in. You know, it’s almost that open source mentality, but very good.

    Rodriguez: Exactly. So, that’s the number—

    Shimel: Francois, as I mentioned to you when we started, the time goes really quick, here. I apologize, but we’re way past 15 minutes.

    Rodriguez: Okay.

    Shimel: I wanna thank you for introducing Adeya to our audience. I wish you will in these uncertain times, both personally and with the company. And as I mentioned to you, maybe we could do a video interview for our TechStrong TV—

    Rodriguez: Yeah, sure.

    Shimel: And have you join us. Maybe we even could use a day or we could record the video through there or something, show people it in action.

    Rodriguez: Yeah. Okay.

    Shimel: Sounds good?

    Rodriguez: Yeah, perfect. Looking forward.

    Shimel: We’ll work on that. Alright.

    Rodriguez: Thank you, Alan.

    Shimel: Thank you.

    Rodriguez: Pleased to meet you. [Cross talk]

    Shimel: Chief growth officer for Adeya, Francois Rodriguez, here on DevOps Chat, this is Alan Shimel, and you just listened to another DevOps Chat.

    — Alan Shimel

  • DevOps Chats: Mobile, Monoliths & Microservices, With LightStep

    DevOps Chats: Mobile, Monoliths & Microservices, With LightStep

    Daniel “Spoons” Spoonhower made a bit of a name for himself while he was at Google, as did his two co-founders of their latest company, LightStep. All three were there at the birth of the microservices wave that has swept through the software world.

    They left Google and started LightStep to help all developers build better, more scalable applications.

    With its new release, LightStep has pushed the bar higher. In this DevOps Chats podcast, Spoons tells us what they are doing and where he sees things moving.

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

    Transcript

    Alan Shimel: Hey, everyone, it’s Alan Shimel for devopsy.kinsta.cloud and Container Journal. You’re listening to another DevOps Chats. I’ve got a great guest to talk with today, I hope you’re going to enjoy it. I’d like to introduce you to Daniel Spoonhower, better known as Spoons. Spoons, welcome to DevOps Chats.

    Daniel Spoonhower: Hi, great to be here.

    Shimel: So, Spoons, you are CTO and Co-founder of LightStep, and though some in our audience are probably familiar with LightStep, being that this is the first time we’ve had someone from LightStep on our podcast, I’m gonna ask you to kinda do some of the heavy lifting here and kinda—

    Spoonhower: Sure.

    Shimel: – tell our audience a little bit about LightStep and what you guys do.

    Spoonhower: Sure—sure, sure. So, LightStep provides simple observability for deep systems. We think observability is more than just metrics, logs, and traces, it’s really about being able to navigate from effect to cause. So, whether you’re pushing into deployment, you’re on call and you got paged or you’re just trying to improve performance, observability tools like LightStep should be able to give you the insights that you need to understand what’s happening in your services and across your system.

    Shimel: Excellent. And just by way of, again, giving the audience the background—Spoons, why don’t you tell them a little bit about your own personal journey? You are a Co-founder and CTO, but there was life before LightStep.

    Spoonhower: True, yeah. So, yeah, I’m Co-founder and CTO and LightStep, but we have three—all three of the Co-founders are technical, and so, we all have done technical things and we all have done a lot of non-technical things, too, which has been pretty fun for me just to learn about finance and about commercial real estate—who knows what.

    Shimel: Yeah.

    Spoonhower: But yeah, I’m an engineer by training. Before this, I was at Google for a while. I worked both on their internal infrastructure team, which was super interesting, as well as on the cloud platform. And I have various other experiences at big and small companies. I was at grad school for a while doing academic stuff, so—yeah, a lot of different things.

    Shimel: Excellent. Alright. So, before we—I know you guys have some new product announcements coming up, but you know, LightStep is, as I mentioned, new to our audience here on the podcast, but it’s been around five years, right? And I think you gave everyone kind of the—you know, the brief elevator pitch about it. But it really, you know, in an age where even just since I’m doing devopsy.kinsta.cloud, right, Spoon, we’ve seen APM turn into AIOps and companies go public in this space and everything, several. But yet, you know, the need to kinda monitor, manage, see what’s happening is still here and I don’t wanna say it’s getting easier or—you know?

    Spoonhower:  [Laughter]

    Shimel: Because I think it’s just, you know, natural. Things get more complex as we continue to build and so forth, and I guess that makes the monitoring easier, but when does it get simpler?

    Spoonhower: Well, yeah, so I think the situation has gotten a lot more complex. That might be because of things like microservices or serverless or things like that. I actually think a lot of complexity comes from the fact that we no longer run our whole applications. Like, we use DynamoDB, we use third party fraud detection service, right? There’s a lot of pieces of our software that are not even ours any more, so that adds a lot to the complexity.

    Shimel: Yeah.

    Spoonhower: I think the simplicity has to come from focusing more on the use cases. Like, what are you as a developer actually trying to get done? And then, I mean—I think this is where people kind of get into things like AIOps is, like, using software to sort of harness the data that we have to help you in that task. I think that can be a real-really nice as a developer, right, to not have to understand all of the depths of what’s going on underneath the hood.

    Shimel: Sure. I mean, I just find it somewhat ironic that, you know, we’re gonna break down silos, we’re gonna break up this monolith and go to microservices so that we can deal with smaller, more easily digestible threads, and then we’re gonna orchestrate all of this with a great tool like Kubernetes. And then I look at it, and I’m not the developer you are—I’m not claiming to be, or the technical person—but damn, it gets…it’s just the nature of the universe, at some level.

    But anyway, you guys are well aware of this. It’s acute. This is the world you play in. You’ve got some new product announcements. Let’s talk about ‘em.

    Spoonhower: Yeah. That’s right, yeah. So, I mean, the history of LightStep a little bit is that we started as a tracing tool, collecting data sort of—exactly to address the situation you’re talking about. You’ve broken your application into some pieces and you want to be able to understand the big picture, right, and put them back together.

    And what we’ve done actually is to continue to integrate additional data sources into that, so that we can provide sort of more user-centric things. So, what we’re rolling out right now is a couple different pieces. One is error analysis, so being able to understand, you know, you have a spike in errors in your service, harnessing that data, whether it’s traces or logs or metrics, to understand what the cause of those errors are. We have a detailed rollout analysis, so even if you’re in the middle of a rollout, so you’re saying you’re gonna canary or blue-green or something like that and you wanna understand what’s happening, we’ll do that analysis for you and do a side by side to tell you what’s different about the new release.

    And one thing that’s pretty exciting is that part of this is integrating metrics into the platform. Metrics are a tool that everyone has been using forever and ever and ever, but you know, there’s a lot of metrics out there, and part of what we think is important is that we’re able to focus on the right metrics, the metrics that are actually able to explain what’s happening right now.

    Shimel: Absolutely. So, this new release, April 2nd, is the key day?

    Spoonhower: Yeah.

    Shimel: So, people listening to this can go check it out right now at LightStep.com.

    Spoonhower: That’s right. We’ve got a free developer tier that you can try. We also have a really cool sandbox that’s sort of, it’s a sort of interactive playground where you can check out features and you can basically walk through one of these scenarios. So, say you’re doing a release, say you’re trying to debug an error or something like that. It’s not—you know, it’s not totally constrained, but will kind of show you along and give you a bit of a guide that you can still explore the rest of the product while you’re there, but really trying to help people kind of put two and two together and understand what’s happening.

    Shimel: Yeah, no, I love that, man. Because I gotta tell ya, we’ve been experimenting with something like that for a project we’re doing on devopsy.kinsta.cloud where, you know, we want to have web people do a little bit more hands-on playing with different vendors’ tools and so, we’re trying to give them a sandbox, right, where they can go in and do these things.

    Because, you know, we were talking off mic, right? Originally, this was gonna be an announcement around KubeCon which, unfortunately, you know, got pushed. And, you know, not getting into the whole politics and the whole thing around Coronavirus and all this stuff, but certainly, we need—we need more ways, we need more diverse ways of allowing people to see what kind of new products, what new technologies, how can they get it under their nails a little bit and really—

    Spoonhower: Yeah.

    Shimel: – kind of see if it’s for them?

    Spoonhower: Yeah, absolutely. I mean, I think people learn in lots of different ways, right? Some people wanna read, some people wanna watch a video. I personally really like doing this stuff. Like, until I’ve made it, coded it, whatever, I never remember it, so.

    Shimel: Absolutely. And you’re not alone. I do think specifically for technology vendors, having those kinda hands on that people can actually go in and we see it even on our webinars, man. If we do a webinar where the vendor’s doing a real live demo that people can follow along, we get insane numbers of people signing onto that, versus someone just talking, you know, and that doesn’t work.

    So, let’s talk a little bit about what was driving this, for you guys.

    Spoonhower: Yeah. I think, you know, we—so, I should say, when I say “we,” it’s me and one of the other Co-founders. Ben and I spent a while at Google, and Google—it’s a weird place, in a lot of ways, but there are some advantages. Like, there were ways in which being at Google is a little bit like seeing the future, and they weren’t called microservices at the time, but there were a lot of teams that built software that all had to stack together.

    And we saw, you know, sort of firsthand the problems that they had in terms of like, okay, I’ve broken this thing into pieces and now how do I understand that bigger picture? We saw a lot of arguments among those teams, like, you know—“Oh, no, it’s your fault,” “No, no, it’s your fault”—and needing some data to actually kinda resolve that.

    And so, I think, for us, you know, we saw the rest of the industry starting to adopt these things through different technology, maybe, but the same idea that you can have teams work independently and deploy independently yet still build a single application. And so, the motivation was really to try to help those folks to understand what’s happening and, you know, we see LightStep being used by individuals, but actually more and more by teams. We see it used in operational review so, you know, you’re doing a post mortem, you wanna show people what happened. LightStep is a great tool to help facilitate that conversation.

    And for us, this is really about being able to help those folks deliver software more confidently and then, you know, get back to building new features and doing all the fun stuff that they’re doing.

    Shimel: Yeah, yeah. I mean, wouldn’t it be great if we just, all we did was the fun stuff all the time? [Laughter] Some of us are lucky enough to do that, me included. But this thing, these are important things that need to get done and, you know, and LightStep is following that up.

    I wanted to return to the KubeCon thing if we can, for a second, Spoons. Not KubeCon itself, but rather the Kube community, right? And you know, look, Kubernetes itself comes out of Google, right? I’m not gonna say the Google people invented microservices, but certainly a lot of very foundational work was done there, right?

    When you are out and about or you see how this community has grown and the enthusiasm for things like LightStep, right—I mean, how does that, you know, kinda give you a warm fuzzy inside to say, hey, man, this is a whole—there’s this humongous community of people who kinda share our visions or our outlooks, and it’s a lot easier to sell to, and I don’t mean that you’re a salesperson, but it’s a lot easier to sell those solutions, right, than it is—you know, it’s not like pushing rope uphill.

    Spoonhower: Yeah, yeah. I mean, I think [Laughter]—yeah, I mean, Kubernetes is a result of a lot of mistakes that were made the first time around. [Laughter]

    Shimel: Yeah. [Cross talk]

    Spoonhower: So, I think a lot of people would admit that. No, but I think the community is really great. I think the thing that’s pretty exciting to me about it is really thinking about things like infrastructure as code, about, thinking about automation, about—and, you know, these things which we kind of think of historically as, you know, maybe more of a craft actually can be an engineering discipline, and I think that’s a lot of that community. It’s actually really great whenever I’ve been to KubeCon to see the range of folks there from, you know, sort of platform folks all the way up to people that are just building features and shipping code, that they’re also excited about those tools. That’s really, for me, makes a big difference, just to see that it’s not a niche thing so much, right, that it’s really a broad community that’s excited about it.

    Shimel: Oh, yeah, no, it’s broad. Me personally, I have 20 years in the security InfoSec space. I get excited when I see all the security people there about it, because I really feel like maybe this time we’ll do better, right? [Laughter]

    Spoonhower: [Laughter]

    Shimel: And we got out in front of this and where, you know, security is really kinda—it’s not the caboose on the engine, per se, it’s like, people care, and not just the security people care, the community cares.

    Spoonhower: Yeah, yeah.

    Shimel: And that’s important. So, you know, in today’s world, right, this isn’t this year’s release, this is just the April 2nd sort of new feature. So, what—and one builds on the next, right? So, what’s next here?

    Spoonhower: Yeah, so, I think we’re continuing to think about how we can do automated analysis. So, we have a future in the product already called correlations which, essentially, you know, you pick out some effect you think is important, you know? Errors went up, speed went down, whatever it is, and LightStep will find the things that correlate with that within sort of the set of requests that you’re looking at. So, we have a bunch more features related to that coming out later this year.

    So, this is kind of how I—I don’t know. When people say AIOps, I always gotta roll my eyes a little bit, but this is kinda how we think about, you know, bringing artificial intelligence to DevOps, right, is that it’s really through sort of putting the right clues in front of you, right? It’s not about providing 10,000 clues to solve a mystery, it’s about 5, right?

    Shimel: Right.

    Spoonhower: So, a bunch of stuff around that, and then—I mean, the other place that we’re thinking about is how do we get more proactive, right? How do we get in front of you and help you anticipate when these things are gonna be happening as well?

    Shimel: Absolutely. So, I suppose one day you’re gonna grow old and you’ll be on this side when—so, I’m no longer building products or founding companies that are building products, and I hear public lands come up with all these…and I don’t wanna say it’s just some marketing term, but—

    Spoonhower:[Laughter] You can definitely say that, that’s fine.

    Shimel: You know, I will tell you, the first time I heard AIOps, too, I said, “What?” You know? But, you know, I’ve been in technology long enough where—look, just don’t call me late for dinner, right? I don’t really care any more what you call it. And also on the media side of it versus on your side of it, I just report the news, you know, theoretically, right? We don’t—if you wanna call it, you know, if it quacks like a duck and it walks like a duck, it’s a duck.

    But in any event, I do hear you about that. And, you know, you wanna talk about an overhyped term? AI?

    Spoonhower: Yeah. I think in the world of—in DevOps, I think it’s actually, there’s some—

    Shimel: It’s overhyped, itself.

    Spoonhower: Yeah, there’s some [Cross talk] though, I think, because you know, if you’re talking about, like, I don’t know, ad placement or something like that, no one really cares about why, right? Like, you put the ad and someone clicks—nice job, right? Like, good job, robots.

    But like, you get paged and something’s like, “It’s that service over there, you should definitely roll it back.” And you’re like, “Yeah, but why?” Like, I’m not just gonna start rolling back things because robots tell me to.

    Shimel: Yeah, “I said so, that’s why.”

    Spoonhower: Right. [Laughter]

    Shimel: [Laughter] But I hear you, man, it’s out there. Well, listen, I told you, the time goes really quick here, and I think we’re about out, man. But Spoons, it was great having you on here. Good luck with this new release. I would say I look forward to seeing you at the next KubeCon. Let’s hope there is a next—

    Spoonhower: That’s right. I’ll see you somewhere, and if not, online.

    Shimel: Yeah. Otherwise, we’ll have you back here on the podcast, man.

    Spoonhower: Cool.

    Shimel: Alright? Hey, that was Daniel Spoonhower, Spoons, CTO and Co-founder at LightStep. He was just our guest on DevOps Chats. This is Alan Shimel for Container Journal, devopsy.kinsta.cloud, Security Boulevard. You’ve just listened to another DevOps Chats. Have a great day.

    — Alan Shimel

  • DevOps Chats: CloudBees Remains at Top of DevOps Market

    DevOps Chats: CloudBees Remains at Top of DevOps Market

    In this special DevOps Chats video edition, we speak with Sacha Labourey, CEO of CloudBees. From the very beginning of the DevOps movement, CloudBees has been one of the companies at the top of the DevOps market and, based on its latest business metrics, the company remains there.

    Being the enterprise Jenkins company helped CloudBees early on to be a leader at the top of the DevOps market. But with Jenkins and Jenkins X handed over to the Continuous Delivery Foundation (CDF), CloudBees can no longer count on its Jenkins connection to stay on top.

    Sacha, like any good CEO, did not allow CloudBees to rest on its laurels. An aggressive acquisition strategy including acquiring Electric Cloud, Rollout.io and others, has kept CloudBees on top. At the same time, Sacha has led the product and engineering teams as they roll out a new generation of DevOps products and services including the upcoming Software Delivery Management (SDM) and Software Delivery Automation (SDA).

    In this video, Labourey lays out what the past year has seen for CloudBees and what the coming year could bring. Of course, with Covid19 everyone is sailing into unchartered waters. But Sacha has the course in mind for CloudBees to follow.

    Have a listen to our conversation with Sacha to understand CloudBees’ plan to stay at the top of the DevOps market.

    [video src="https://videos.files.wordpress.com/TNgFIQ9x/2020-03-19-interview-with-sacha-labourey-1_hd.mp4" /]

    — Alan Shimel

  • Free Remote Endpoint Protection Solution From Qualys

    Free Remote Endpoint Protection Solution From Qualys

    Qualys today announced it is offering a completely free, 60-day version of its cloud-based remote endpoint protection solution. The product is fully featured, with nothing turned off in the free version. It’s also cloud-based, so there are no worries about hosting the solution. This comes at a perfect time, with so many workers working remotely.

    You can download the free solution at:

    www.qualys.com/forms/remote-endpoint

    According to the Qualys release:

    “The Qualys remote endpoint security solution allows security teams to leverage the lightweight Qualys Cloud Agent to:

    • Complete an up-to-date inventory of all their remote endpoint hardware and the applications they are running
    • Gain a real-time view of all critical vulnerabilities impacting the operating system and applications posing a risk to these devices
    • Remotely patch these systems within hours from the cloud with one click of a mouse without using the limited bandwidth available on VPN gateways
    • Realize visibility in device hygiene by tracking common misconfigurations that leave the endpoints exposed to exploits.”

    devopsy.kinsta.cloud spoke with Qualys President Sumedh Thakar for more information on this new free solution. That conversation can be heard below:

    Here’s a screenshot of the web-based interface of the solution:

    Qualys endpoint screen shot

    What happens after the 60 days you ask?  Qualys did not say definitively what the plan is for that, but I suspect that will depend on what happens with our economy and the work-from-home trends. In the meantime, if you are looking for a remote endpoint solution for the enterprise, this is a great chance to try one free for 60 days.

    — Alan Shimel

  • EP 6: How to Lead a DevOps Transformation

    EP 6: How to Lead a DevOps Transformation

    Is C-level support required to have a successful digital transformation? In the sixth episode of DevOps Unbound streaming broadcast on TechStrong TV and devopsy.kinsta.cloud’s sister site Digital Anarchist, Mitchell Ashley of ASG and Alan Shimel are joined by Eveline Oehrlich of the DevOps Institute, Louise McCarthy of Bain & Company and Mark Settle, author of “Truth from the Valley, A Practical Primer on IT Management for the Next Decade,” to discuss DevOps and digital transformation at the C level.

    The video is immediately below, followed by the transcript of the conversation. Enjoy!

    Transcript

    Alan Shimel: Hi, everyone. Welcome to another edition of DevOps Unbound. DevOps Unbound is brought to us by our friends at Tricentis. So, thanks for their sponsorship. But, you know, they sponsor but we pick the topics. We pick the guests. And we have a lot of fun here talking about relevant topics around DevOps. Today’s topic centers around DevOps and digital transformation at the C level. And let me introduce you to our panel. First of all, we have Louise McCarthy. And, Louise, I’m gonna ask you to kinda introduce yourself with a little background for our audience.

    Louise McCarthy: Yes. Thank you, Alan, and hi, everybody. I’m Louise McCarthy. My background more recently is doing large, complex digital transformations mainly for the financial services. And mainly through the eyes of the business rather than the technology, although I have held roles as CFO and I’ve held roles COO and CIO as well.

    Shimel: Excellent. Next, we have Mark Settle. Mark, welcome.

    Mark Settle: Thank you. So I am a seven-time CIO and I most recently left Okta about a year ago and have been advising startup companies since then. I’m based here in Silicon Valley. And probably my encounters with DevOps are focused on supporting DevOps communities in terms of infrastructure requirements if they have, and also introducing the concept in actually business application support within a conventional kind of an IT group.

    Shimel: Thank you and welcome. And then Eveline Oehrlich, Eveline, please.

    Eveline Oehrlich: Yes, hello there. Eveline Oehrlich. I’m the chief research director at the DevOps Institute. Before that I spent 13 years as vice president at Forrester Research studying a variety of topics, and DevOps of course was one of them, working with many enterprises and C levels and others to explore the challenges and the fun of DevOps.

    Shimel: Very good. I’ve never heard anyone talk about the fun of DevOps but I’m looking forward to discussing that. And then, last but not least, of course is my cohost here on DevOps Unbound, Mitch Ashley of Accelerated Strategies Group. Mitchell? 

    Mitch Ashley: Good to be here. I’m Mitch Ashley, CEO of Accelerated Strategies. We focus on digital transformation, DevOps, cloud native, and cybersecurity. I’m also a former CIO. Not nearly as experienced as Mark is, but have led transformations and also implementation of DevOps as well as been a CTO, CEO of product companies. So I’ve lived on both sides of DevOps. 

    Shimel: Great. What a great panel we have today. I’m really looking forward to it. So we’re talking about DevOps at the C level. As I mentioned to you all before we started today’s show, our friend Gary Gruver wrote a book, “Leading the Transformation.” He wrote several books. One of ’em was “Leading the Transformation.” And Gary is a big proponent of what he calls the top-down approach to DevOps and digital transformation. And in Gary’s view – and I’m not saying right or wrong. In Gary’s view, you cannot have a successful digital transformation or DevOps transformation without sponsorship, support, air cover, if you will, from the C level, including the CIO or CTO, depending on the organization. CEO, et cetera. 

    Let’s start there. Is C-level support absolutely positively required to have a successful transformation? Anybody?

    [Crosstalk] 

    McCarthy: Do you mind if I go first, Alan?

    Shimel: Sure.

    McCarthy: I would actually say, my recent – I’ve done about five or six transformations and tried all sorts of ways to actually get them going. There’s always blockers on the way and it’s usually the blockers that slows the whole problem down. And the blockers either come from the ground up, from the employees or the people that run the processes today, or you get the blocker in terms of the C-level-suite people who tend to wanna own things, and it’s a big of ego that actually blocks things going that way.

    And the most recent transformation was successfully owned by the C-suite. So they drove it. They owned it. They were the stakeholders. But most of the engagement actually came from the employees, from the process owners. So we ran the whole transformation from the process owners actually owning and identifying where the transformation needs to take place. And that really made it hugely successful because you didn’t have people fearing for their own jobs. ‘Cause with digital transformation it always means or often means that there’s gonna be heads that unfortunately are lost in various areas of the – in the transformation. But mainly doing transactional-type work. But if it’s the transactional people that are running the processes, they highlight their pain points and then we work with them to actually change those pain points into something positive. 

    So, I would arguably say both from top-down, but also if you don’t do it with engagement of the people running the processes today, it won’t work.

    Settle: I’ll chime in. I think I have the same answer but I’m gonna state it in a slightly different way. I think the way the question gets asked, it sounds as if the CTO or the CIO’s gonna come down from the mountain with the DevOps tablets and then ____ employees and team members _____.  “I’ve been converted and now it’s your turn. We’re all gonna go do this together.” [Laughs]. Most of the time that doesn’t work. For one person to come in – well, take an example where a startup company here that’s been reasonably successful. Maybe they get up to a product team of, I don’t know, a generic team of 500 people or something like that. They hire a new chief product officer or a chief technology officer who says, “We’re gonna do this completely different. I have a vision.” Et cetera. Well, they’re gonna do it but that’s gonna be a slog to kinda get there.

    What I’ve seen be more successful is almost like – what’s the right term in a battle when you send the beach guy out? The beach master that’s moving people around. So you really want almost like a fifth column movement down at the grassroots level of people who are genuinely interested in exploring these ____ ways of doing business. And then I think what the C-level person adds are the methodological resources to drive scale. And so many DevOps initiatives fail because they sound interesting; they sound contemporary; people think, “Other people do it so it must be beneficial.” 

    But then after like 18 months, everybody scratches their head; “Where are the benefits? We thought this was gonna be transformational.” It’s not. The technical people are having fun. They’ve developed this new terminology, et cetera. And if you scratch below the surface, well, guess what? You’re doing DevOps in like five different ways because the little C-groups have all picked the tool they wanted and decided that they’re gonna have a daily scrum twice a week or whatever. They’ve got their own little process set up. And then people say, “Where’s the benefit? This was supposed to be transformational.” So at some point in the early stage of the journey, it’s needed to drive scale and ____ of endorsement. But I think it can almost backfire if it’s launched from the brain of Mark Settle that, “Yea, and verily, I’m gonna lead you to the promised land.”

    Shimel: Sort of a Charlton Heston beard I’m picturing on you there, Mark. Eveline, how about you?

    Oehrlich: Yeah. I actually would say it should be outcome-driven DevOps. It doesn’t really matter if it is from the C level, from the individual, from the inside-out, from the outside-in, from the top to the bottom, the bottom to the top, from the middle to the whatever. It needs to be outcome-driven. What I mean by that is: Only metrics will make us change. Just like I drive through my town here – this is a little analogy. I drive through my town. They installed one of those things where they measure the speed and if you go over 50 kmh you get a ticket. Well, my husband, even though that thing has been there for two years, my husband manages to get a ticket every three months. But what he does is he intercepts the mail and then he doesn’t tell me that he has gotten that ticket. 

    So now what I have done to stop those 15-euro tickets every two months – because if you add it up you can go for a nice dinner – I am going to go through the mail before he gets home so I see how many tickets he gets. And he gets little lines. And that metric is on the refrigerator – I should’ve brought a picture of it – and that has actually reduced how he is driving through town.

    And so if you go back to the DevOps teams and the digital transformation and you ask the individuals at C level or VP level or practitioner level, “How successful have you been or what’s the challenges around?” It’s easy to point to somebody. But data, if you have data which shows where you are and it maps to where you want to go and you share that amongst all these different individuals, there is no argument. It’s not the guy with the long beard, as Mark would come in, or it is not somebody at the lowest level who could argue with that. We could huddle around it and figure out: What do we need to do?

    So I think it’s not really about who – of course we do need some individuals who pays for it. We need some kind of a fund and budget and all of that. But I really think it’s outcome-driven rather than organizational-level-driven.

    Settle: Can I just chime in on that one, too? So I would agree 100%. And outside of maybe the CTO or CPO or IT organization, bringing evidence of improved sophistication, operational metrics around the process to almost any other C-level executive – they don’t really care. The CFO – if you show that, I don’t know, the year throughput, the story whatever – in one of my books, it’s like reading a Bible to the cat. The cat will look at you and feign interest. But it has absolutely no idea what you’re talking about. And that’s sorta what you get outside the technical functions, everybody – “But that’s your job. You figure out what needs to get done.”

    And, again to your point, it’s more of a business outcome. Like, are we actually getting customer request enhancements through in greater quantity or are we able to respond to a competitor’s new feature set faster than we did at their last result cycle? Or whatever those things are. That’s what people wanna talk about.

    McCarthy: Yeah. And – [Crosstalk]

    At the end of the day, the outcomes is aligned to the strategy of the organization. So you’ve gotta be doing a transformation for a reason. And there’s usually three or four reasons why you’re doing a transformation. It’s around the customer journey so the customer needs to improve the satisfaction. You’ve gotta costs. You’re trying to grow your revenue. And then the one that’s usually an outliner that’s become ____ at the moment is carbon emissions. So for every one of these paint points that I mentioned earlier, there should be a business case that shows measurement of success against each of those four measures. And that’s what you – bottom-up, you report at top level to the C suite to say, “This is why we’re doing it. This is the measure of success of what we’re doing it.” And even breaking some of the pain points and the business cases down to quick wins. So ones that you can be getting on with relatively quickly that free up cash that then can pay for the more strategy-type things.

    Shimel: Yeah. So I think this brings up – all three of you have touched on it. And it brings up what I think is really sort of an entry question, which is – it’s the genesis of digital transformation. Why and how does any organization decide to go through the potential pain, heartache, and change of digitally transforming, of adopting DevOps or agile? Louise, I’m pretty sure we spoke about this – was it at an Emmet Keeffe Insight IGNITE in Iceland that you were at?

    McCarthy: Yes.

    Shimel: I was there with you and I remember talking to you about this. You know, Eveline, in your day, someone like Mark might go to a Forrester conference and come back and say, “Wow, Eveline Oehrlich from Forrester just presented this presentation study on the benefits of digital transformation and DevOps adoption. And, god darn it, she described us to the T. We really need to do that here.” And maybe that worked then, right, seven years ago, ten years ago? I don’t know if that’s the genesis of digital transformation today. I think a lotta times digital transformation today does start with technical champions lower down whispering in Mark’s ear that, “If we were doing DevOps or agile or whatever, we could really make better customer experiences. We can give customers what they want. We could do it better, cheaper, faster.”

    [Crosstalk] 

    Ashley: I think we have a chasm that we have to cross, and that is: DevOps can be sort of a vanity project for the IT or the development organization, right? It can be a purely self-interest: “We’re doing what we do better.” Which is always a good thing, but at the end of the day does it move the needle for the business? You have to be able to translate that into what Eveline said was the why. Louise also said the why. But what is the real benefit we’re trying to get out of it? And when you have a purpose for doing it, now you have metrics you can put around that. Is it revenue? Is it competitiveness? Is it responsiveness to the market? Is it changing customer expectations and behaviors? What is it? That’s truly – then the development or the IT organization knows that they’re making a difference. 

    Otherwise how do you know whether you should be working on more releases per hour, per day, or you should be working on just fixing the backlog? How do you know? You don’t other than just sort of your own internal metrics. And I guess it kinda reminds me of that phrase of the – what was it? Belly-button gazing, right? You’re sorta looking at yourself and what you think’s important. But I think that connection – you have to cross that chasm, whether the business is coming to you or you have an idea of what we can do better and how it might help, and then let’s then make that connection. 

    Shimel: That’s my point. Someone like Mark – Mark, what does it take to push you over the edge and say, “God darn it, we gotta do this; we’re committed”?

    Settle: Yeah. Let me _____. One thing’s funny about this whole line of conversation is of course, in the world that I live in out here, there’s no question about doing it. It’s like: Who is the most sophisticated – [Crosstalk] or more sophisticated? So, in the war for talent, that same 500-person organization I referenced – they might look at each other and say, “Who do we know at Google or Facebook, in their engineering group? We know we should be doing this better. We’ve kind of played around with the concept. We’ve hired some lower-level people who’ve said, “You guys are just behind the times here. So we need some real leadership inserted.” So that’s the other side of the coin. In parts of the country where maybe it’s like an accepted practice, there’s almost a competition to be the most sophisticated or get the most benefit. 

    But the spark plug, the question you’ve asked – I’m thinking about some second-tier markets – and I really hate to call out specific locales, but what the hell? As a consultant, you can talk like that. So if you’re in a place like St. Louis and you’re in an organization that just has done business the same way forever, all the IT management, all the technical management has come up through the ranks kinda doing things the old-fashioned way, quarterly releases, and they don’t keep the same kinda metrics that you would in a DevOps environment, to blow a place like that up – there’d have to be some kind of competitive imperative.

    Or, you know, the white knight does show up from time to time, right? So if you think about it, sometimes when the new CPO or the CTO comes in – and I’ve experienced this in my own career – there’ll be a cause or a initiative that I promoted during my entire tenure – the new guy or gal comes in and they get it done like in a year. And I think, “What the heck happened here?” 

    There was one company where I was trying to get them off of Microsoft Dynamics, get ’em onto Salesforce. There was another company, I was trying to get production systems up into the cloud. And we did every kinda seed activity you can imagine. The cloud one, we sent people up to Redmond for some AWS instruction. We did some prototyping, et cetera. New CIO comes in and says, “We’re going to the cloud,” 12 months later like half the production systems are in the cloud. Like, “How did that happen?”

    So sometimes change at the top – which gets us back to where this kinda started – maybe that is the seminal spark plug. And especially if that person’s been brought in because there’s a broader C-level recognition that, “We’re not keeping up with the times; we need to make some kinda change.” So you have that broader support. When people start to whine, they know that the whining’s not gonna get them out of the change that’s about to come. 

    But for just self-generated change for people that’ve – then I go back to, you know, Mitch, where you said: then you can always have a vanity project which you can point to as evolutionary. Like: “We’ve got a small group. They’re putting their toe in the water. They’re doing some interesting things. So we are keeping up with the times.” But then you just don’t get the scale benefits at the end of the day. 

    Oehrlich: I think there was – just to add to something to what Mark said, as the ecosystem of our organizations has expanded, we have to think of – well, the travel industry doesn’t exist at this point in time, but think of maybe manufacturing, right? In the area where I am in, I’m in Stuttgart, we have large car manufacturers, and they’re connected to Bosch and others, and the ecosystem is rather broad. And these folks at all levels are collaborating, connecting. Not as much now with where we are, but they have exchanged thoughts and ideas, they go to events, and they learn from each other. At all the different levels. And so I think there is that – as Mark said, to some extent there is this – not really a competition, but the exchange of ideas, which has brought additional adoption of DevOps at all levels, right? 

    So if I am the C level of Bosch and I go to a genomic car-driving event and I meet the CF C level of the CF industry down in Friedrichshafen and they are telling me about, “Wow, we really improved our reliability scores and we have really punched up our cadence around the product X, Y, and Z,” I go back and I say to my team, “Hey, I just met this team over there. They’re doing something fantastic. Can we start?” It’s that spark, which to some extent happens to cross over in this ecosystem as we start to be much more connected and dependent. I think that’s one point.

    The other one is: if you look at the individuals who are today in IT, they don’t look like this anymore. I’m a Cobol, Pascal, HP 3000, JCL person. That’s when I grew up. That’s my heritage in operations. The guys and the girls today in these teams – they are completely different. They want Python. They wanna do sexy things. They wanna do fun things. They wanna show what they can do. And they’re looking for inspirations from their leaders as well, and they want to see that they can make a difference. I think that is also, from a cultural perspective, I think – of course it’s important but I think that’s also a driving force. And that’s not just the individual contributors but also the consultants and the C levels who are – I call them the flip-flop-wearing, chino-looking guys who go to the conferences, which we’re seeing them; I’m like, “Oh, I think I’m overdressed with my suit.” That’s the people who actually make DevOps happen, and they wanna have fun. They wanna do things. They don’t wanna do JCL and things like I did in a boring ops group dying of boredom.

    Ashley: I think you’re talking about a couple of things, Eveline. One is the attracting talent, right? People have more selection, economic conditions aside, more selectivity about the kind of work that they wanna do, the companies that they wanna work for. There’s also just: how do you learn to develop software? If DevOps is what you’re coming into, a way of developing software, you’re looking for organizations and you expect that approach. So I think your point is right on. It’s also the audience of the people who are gonna be the adopters or the embracers or the champions of doing this. So that all makes a big difference. The command from on high, as Mark was talking about, the tablets – there’s an expression for that: “This too shall pass,” right? That’s the reaction, usually, of those kinds of initiatives. You have to have an option. And I think you spoke to that really well.

    Shimel: Look, if you’re a Silicon Valley cool kid or you work at one of these organizations where flip-flops and jeans are the rule and you do the hair thing and all of that – I don’t do that so well anymore – that’s cool. But, Louise, you’ve done transformations at what we may think of as large, stodgy financial organizations, right? And they’re not Silicon Valley-based and they’re not a jeans and flip-flop culture. So how does it play there?

    McCarthy: Actually, funny you were talking about flip-flops, high fives and cappuccino. I worked in government actually for a little while, the tax authority, and that was a time when the government was setting up its ____ global digital authority. And everybody in the government, all of a sudden they change from suits to wearing flip-flops and high fives and cappuccinos, and it was like a world away from the starchy government.

    But, anyway, moving on to the financial services, yeah, the financial services – I’ve been lucky enough actually to do transformation in legacy financial services, and the big boys like the HSBCs, for example, which is complex. It’s like turning the Titanic around. And I’ve often written articles around: it’s like moving deck chairs around. The reason why I say that is because automation is the way forward. We talk about automation in many guises. Automation takes out people. It takes out transactional-type activities. But the legacy banks just struggle to do it. So I say it’s like moving the deck chairs around the Titanic because of the legacy system they’ve got. Transformation – they talk about it. They move things around. But nothing real and concrete actually comes out of their transformation, which is really sad. Because there’s great opportunities there in the legacy banks. 

    And on the other side of the fence, I’m working currently with a contender bank, a digital bank, which is new. It’s new. It’s fresh. It’s green. It’s almost as green as your screen there, Alan. It’s a green ____. And it’s great to be able to take the whole end-to-end customer journey and see it digitalized. And how quickly you can change and transform. And developing and changing technology with that suite, the same thing end to end, it’s just awesome to be able to see how quickly it happens. Whereas the legacy banks are still thinking about planning it, talking about it, cogitating over it, when the small guys are out with a new technology. 

    And one of the things that I’m often transforming whenever I do my transformation – it’s not transformation, it’s Christmas; it’s for life in my mindset. So it’s around continuously thinking about the innovation and it’s about encouraging these legacy banks to have innovation departments that are constantly thinking about the new technology that’s out there to take them ahead of their competitors. So like these digital banks, if the legacy banks are doing this, they’re actually seeing a way of making it happen quickly. And I think that’s the problem that we’re constantly battling: the bureaucratic slowness of moving Titanic.

    Shimel: So clearly the kind of organization you’re at determines, or will have a huge impact on this. Guys, we’re coming on the back side of our time limit here. I wanted to talk a little bit about: okay, we’ve made the decision. We are moving forward with our transformation. We are adopting DevOps and agile and these new ways. How at the sea level do we – short of coming down from the mountain with the two tablets in God’s own writing, how do we translate that to the troops? How do we effect the organization? That this isn’t some passing fancy of the CIO and it’s not gonna pass in the next quarter. This is really the way we’re doing it. How do you make that change down the ranks, get people adopting as champions and being successful with it? Mark?

    Settle: You know, it’s not unlike an initiative around security. When you talk about cultural change within an organization, I think leaders don’t always appreciate what a huge impact they have on the people that they lead. You know, people take cues from the way you use your time, the things that you show interest in, things you follow up on. Your time management sends tons of signals to the organization. And some of the operational metrics that I poo-pooed before as being of no interest whatsoever to people outside the technical areas are a great way to kind of keep score. You go back to what Eveline said: If there’s a sense we’re making progress, some of those ____ celebrations can be really important.

    I’ll just leave you with a thought. I worked with a guys several years ago who used to say, “What interests my boss fascinates me.” As long as there’s some sustained interest – and to go back to, Alan, what you said before: I can just come back from the Forrester meeting all jazzed up, and then two months later I go to a Gartner meeting and now I’m on a whole different tangent. Now I think it’s automation; we gotta get RP robots in here. That’s gonna blow the business up. And then people in the trenches are like, “This too shall pass. He’ll go to another meeting. But I’m not gonna get my –

    [Crosstalk] 

    Shimel: Come back with some other toy, yeah. 

    [Crosstalk] 

    Settle: “He’s so crazy.”

    Shimel: Yeah. I used to feel it was whatever was the last book I read. That was the next greatest thing to me, right? ‘Cause I just read that book. But, Eveline, fundamentally – and this is something the DevOps Institute is deeply ingrained in – it also becomes a question of: how do we upskill our workforce? How do we prepare – do we just go out and hire new people? That’s hard. Do we upskill our existing people for this? At the C level, how do we effect that?

    Oehrlich: Yeah. So, from our research at the DevOps Institute, we know that most organizations are actually preferring to leverage their existing resources to train them and to upskill them. Now, upskilling of course has its challenges because you don’t just upskill around processes of learning a new way of doing continuous delivery, or it’s not just about upskilling new technical skills. It’s also about human skills. That’s I think the challenge. A lot of organizations are biting themselves into that – or pushing themselves, or actually locking themselves into the corner. They think, “Yeah, let’s give them AWS training. Let’s let them understand what the latest DevOps platform is and give them some language skills around whatever the latest hotshot technology programming language is.” 

    But it’s also soft skills or human skills which are necessary. People need to understand how to work empathetic, how to collaborate, how to connect, how to cross functional borders, how to understand when a security individual tells me something. So having skills around these different categories is important. And there is investment needed. We see that, unfortunately, 7% of survey participants we had last year said that they have no idea what their upskilling programs are. We know 37% of these individuals – a very large sample size of almost 1,200 – said that, “We don’t have a program in upskilling.” And the rest of them either are planning one or have one. So that’s really unfortunately poor and not enough. So, anybody listening in, get ready to upskill your people. Start thinking about training. Start thinking about exchanging knowledge and allowing them to learn. Give time.

    I, for myself – and we’re doing that at the DevOps Institute a little more, and our CEO does that a little as well. I call Friday my learning day. And it doesn’t matter what happens. Unless the CEO wants me there, Friday is my learning day. I learn French. I learn about design thinking. And I’m learning about metrics. That’s it. And we all have to do that. It’s very important. 

    Shimel: Agreed. Louise, you go in as a consultant. In terms of the skill level of the workforce, do you try to upskill them? Do you supplement it with fresh talent? It’s hard getting fresh talent in. Mark, you know in the Valley they cut each other’s throats for this. How do you do that?

    McCarthy: It’s an interesting thing because you’re trying to fly an aircraft while changing the engine in some cases. And the same people _____ transform are the same people that need to drive the aircraft. And also if you call in too much fresh talent, then you would probably put the noise in the joint of the people that are supposed to be helping you run the process anyway. 

    So the way I’ve done it is I’ve gone in and we’ve identified some highly skilled people that know the processes really well and then supplement them with some more transactional process mappers and people like that. So that those people that run the processes can also see things like: how do they do the process mapping and how do they identify the paint points? How do they convert it into business cases? How do they use it and then convert it into technology?

    So on that journey, the people that are running their processes are also being upskilled at the same time into continuous improvement and transformation. But I’d say that there’s also – it’s not about upskilling necessarily on all sorts of things. Because as technology’s changing, there’s less the need for upskilling because a lot of technology is self-serve-type technology now. A lot of the RPA touring now. People can do it like they learn Excel, like they learn Word and things like that. so the upskilling like it used to be, about spending months and months programming and that type of thing – there’s less the need for that. It’s more about the upskilling in terms of continuous improvement. And it’s a cultural change, I think somebody mentioned earlier. So it’s going in and using the resources that’re there, upskilling those people, and slightly supplementing them and doing hands-on job training.

    Shimel: Excellent. Mark, Mitchell, I’m gonna give you each a chance to kinda close it out here, and then I think we’re about outta time. Mark, final thoughts?

    Settle: Let me just make a final comment along the lines of this last topic. I’ve gone through many of these reskilling things, and seeding that group with new talent I think is essential. I mean, if somebody came into me and said, “We’re gonna go to DevOps and you can have consultant money; the consultants will come in; they’ll be here 90 days, 120 days” – this is an acquired skill. It’s almost an art form at its finest. And the devil is in the details. And the day the consultants leave, everybody’s left to their own devices, and it’d be just like saying, “Let’s just shut down the data center and move everything in the data center up on AWS, and we’ll get some AWS consulting in here, and then they’ll leave after 90 days, and you guys run all the production systems up there in that whole new environment after 90 days of familiarization.” I don’t think too many companies would take that kind of a risk.

    So I think people get so carried away with thinking that reskilling can be effective, that people will come to embrace it. And, again, I hate to say this, but in my personal experience, if you reskill a population of people, 20% will be superstars, 20% won’t get it, and 60% will be good enough. But if one of the 60% left, you’d recruit somebody in with a higher skill level than the person that left. So they make forward progress. I’m not denigrating people’s commitment to new things. But you’ve gotta bring in that fresh talent that’s been there and done that. They know what it’s supposed to look like, right? And they can look around a corner and they can see the big fuzzy hole in the road that we’re all gonna fall into here in the next two months. 

    So that’s my thing.

    Shimel: Mitchell, you wanna bring it home?

    Ashley: Yeah. I’d like to just wrap with the human element, but maybe from a little different perspective. You know, people react to change in different ways. Your advocates – great, they’re all about it. Your resisters – love them ’cause you can actually work on that. You can help. You can help bring them along. It’s that passive unspoken middle ground, the folks that’re waiting to see: “Before I commit myself – I’m not gonna put myself, my job, my career at risk for this next thing. I don’t know if I can do it.” And the idea of bringing people in – I think one of the main purposes is to show the team, A, it can be done, and, B, they can learn it. So it isn’t: bring the consultants in for 30 days, hand over what they did, and now everybody goes, “Now what do I do?” Right? 

    So I think if you can de-risk, address the fear of what this means, that: “You’re gonna be able to do it and we’re gonna stick with you to help you get there, help everybody get there. And if there’s some folks that choose not to go along the journey, that’s okay too. But we’re all in this together.” I think you’ve gotta address the human element from a very personal: how does each person feel about this and whether they’re signed on to do it? And that’s gonna guide your success. That’s been my experience. 

    Shimel: Absolutely. Well, guys, we’re about outta time. Mark, Eveline, Louise, and of course Mitchell, thanks for joining us on this episode of DevOps Unbound. Many thanks to our friends at Tricentis for their sponsorship. Until next time, this is Alan Shimel for DevOps Unbound. Be well, be safe, and we’ll see you soon. Bye-bye.

  • EP 5: Outsourcing DevOps, Oxymoron or Truth

    EP 5: Outsourcing DevOps, Oxymoron or Truth

    Can you outsource DevOps? And if you can, what are the keys to doing it successfully? In the fifth episode of DevOps Unbound streaming broadcast on TechStrong TV and devopsy.kinsta.cloud’s sister site Digital Anarchist, Mitchell Ashley of ASG and Alan Shimel are joined by Ming Gong of UST Global, Chris Rolls of TTC and Robina Laughlin of Guardian Life for a discussion on outsourcing DevOps.

    The video is immediately below, followed by the transcript of the conversation. Enjoy!

    Transcript

    Alan Shimel: Hey, everyone. I’m Alan Shimel, and welcome to another episode of DevOps Unbound. DevOps Unbound is a series, sponsored by our friends at Tricentis, that explores different topics around DevOps every other week, as well as having a monthly roundtable open to the public. Today’s episode is “Outsourcing DevOps: Oxymoron or Truth?” I’m joined, as usually, by my co-host, Mitchell Ashley, CEO, founder of Accelerated Strategies. Mitchell, welcome. Thanks for coming on.

    Mitch Ashley: It’s always awesome to be here. I’m excited about our guest today.

    Shimel: So am I. Let me introduce you to our guests. We have Robina. And, Robina, I’m gonna ask you to give your full name, title, company, background. And we’re gonna ask you to kick it off.

    Robina Laughlin: Sure. Hi. I’m happy to be here. Thank you. My name’s Robina Laughlin, I work for Guardian Life insurance. Actually Guardian Life and I have been working in the quality assurance space now for about 25 years. I’ve been working for Guardian for eight years. We have a great enterprise quality assurance journey. Most recently my department, my quality assurance department’s been working with integration into a DevOps model. So we’re starting that journey. We started about a year ago. And really happy to be part of the conversation.

    Shimel: Thank you, and thanks for joining us, Robina. Secondly, I’m gonna introduce my friend, Ming Gong. Ming, a little background?

    Ming Gong: Hey, Alan. How are you? It’s always good to be here. My name is Ming Gong and I work for UST Global, I’m vice president. I run a practice called Digital Agility Platform Solutions. So what we do is we provide all kinds of services and even product to our enterprise customers, things such as DevOps transformation, DevSecOps, digital, cloud transformation, as well as latency modelization. So, we have tons of battle scars as we’re implementing DevOps for our customers.

    Shimel: Absolutely. And then, last but certainly not least, Chris?

    Chris Rolls: Hi, nice to meet everyone. So my name’s Chris Rolls. I’m from a company called TTC. I’m CEO of Americas. And what we do is we help organizations with quality engineering, continuous testing and also Agile and DevOps transformation. So really happy to be here and excited to hear what everyone else has to say.

    Shimel: Absolutely. So, guys, when I started – so we launched devopsy.kinsta.cloud in March 2014. Working on it all through the second half of 2013. At that time it was sorta dogma in DevOps that DevOps wasn’t about the tools; DevOps was about people; DevOps was about culture. And that therefore, to be successful in your DevOps journey, outsourcing was a no-no. You couldn’t be successful and outsource your DevOps because it would destroy – you never got to the nitty-gritty of the culture. 

    Now, that was seven, eight years ago. A lot has changed. I think we’ve seen some very successful – the world is full of DevOps consultants, large, small and in between, who are helping organizations along their DevOps journey. So I think we have kinda moved beyond the dogma. But have we moved to truth? Can you successfully outsource DevOps? And if you can, what are the keys to doing it successfully? And I’m gonna throw that out to our panel today, and we’re gonna start that as our discussion. Ming, not to pick on you, but you already mentioned you have a lotta scars to prove it.

    Gong: Absolutely [laughs].

    Shimel: Tell us a little bit about your journey or UST’s journey in this space.

    Gong: Yeah. I think you mentioned a couple of things that’s really important, which is, ultimately, I think to do DevOps correctly the entire delivery team needs to live and breathe the DevOps – not only the automation, the tool set, but also the processes as well as how you do things or the whole mindset thing. So that’s the absolutely ultimate goal. I think even over the past few years, even though all the companies all moving towards DevOps, but they are still having a lotta challenges in terms how to take some isolated success in certain areas, trying to cascade that throughout the entire organization. And I think this is where, when we talk about, “Hey, is outsourcing a myth or a reality?” I would say it’s actually somewhere in between. 

    Because it really depends on where the continuum – when I think about DevOps, I think about DevOps continuum, ___ maturity, where they are. For the company who’s really mature, they are less likely to benefit from outsourcing before the folks who’s just starting the journey or middle of the journey – they definitely can use some help. And not only outsourcing in general but also what part of DevOps to outsource as well. So typically when I work with enterprise customers, they have a centralized organization, like some kind of DevOps COE. But they also have each individual team that needs to be enabled. So where we found there tends to be more success is when we help the COE to – infuse them with the DevOps expertise and help them kinda build up the practice around DevOps.

    So I definitely think it’s somewhere in between.

    Shimel: Fair. Chris, your organization is similar to Ming’s in that you are helping organizations with their transformation. Has your experience been similar, different?

    Rolls: Yeah. I think I’m not gonna shock the world by being a consultancy who sees consultants can help with DevOps transformation, right? I would be outta business if I thought that was the case.

    But if I was to answer your direct question, can you outsource DevOps? I would say no. Because DevOps is about a cultural change within the organization as well as the technical practices. Now, similar to what Ming is saying, it’s sort of in the middle because outsourcing and consultancies and other vendors can be a part of the solution. They can make some things more challenging in certain ways because you are introducing certain barriers, as in contractual sort of challenges around it. But it definitely can be part of it and it definitely can help, particularly when organizations are trying to figure out how to do things better. 

    Shimel: Fair. So, Robina, you look at this sort of 180 degrees different than Ming and Chris do, right? You’re not providing consulting to organizations. You are the organization. What’s your view on this?

    Laughlin: Yeah, thanks for having me. This is a really interesting conversation. Some of my thoughts around this is: I think the important thing to understand is: what’s your driver to DevOps? Why are you moving to that model? Why is that model gonna be important to you as an organization or as an enterprise? And when you start to answer that question, you get to different models. For us, we adopted SAFe. We started that journey two or three years ago. So DevOps was not the first thing we tried to conquer out of that transformation. It’s on the tail end of it. And it was always on the strategic road map. However, what we found is that it grew organically based on the improvements from adoption of SAFe and agile. So for the teams to get to the velocity that they wanted to do, it became a necessity as opposed to an aspirational goal, right?

    So for us when it became that driver to success, it took on a whole different model. And then when we started figuring out how do we wanna do this with our partners, the vendors that we work with, one of the things that we always hold true to in Guardian is that frameworks, guardrails, models our Guardian culture, and we developed those. We developed them in conjunction with our partners. We’ll seek for collaboration. We’ll seek for guidance. But the model has to come back to fit our culture and how our folks work.

    And then once we have the guardrails in place and the operating model, inclusion of an outsourcing model is very successful, I find. But I speak from a QA perspective, and I’ve been on an outsourcing model now for 15 years, right? So I always kinda take the same approach to things in that if you have the operating, the guardrails, and people know what they need and why they’re doing it then outsourcing is a good solution. But you have to have a strong backbone for the company that you’re working for and with to be able to represent that model and the culture. 

    Shimel: Mitch – oh, Ming, go ahead? Whoever, Chris.

    Rolls: Oh, sorry. I think just to drill into that as well, Robina mentioned you’ve gotta understand your drivers for DevOps; what are you actually trying to achieve? I think that a lot of times organizations – they want to do DevOps because that’s what the conferences and the experts say they should do. But also you need to understand: what’s your driver for outsourcing or engaging partners and other vendors, right? So if it’s a cost-saving mechanism, which often it is in this economic climate, is something that people are looking at, right? That can be one component. That can be one reason for outsourcing. You could also be outsourcing to get additional expertise that you don’t have internally. You could be outsourcing ’cause you’re scaling up with a whole another set of products and there are sort of HR reasons for wanting to do that. But you need to understand those drivers. 

    And I think another thing that Robina said crucially which I see organizations get wrong is: the organization who’s – the business, the incline for us needs to own the cultural change and needs to own the methodology. I come back to: no, you cannot outsource DevOps. You can’t buy that on a platter. You have to invest. You have to make the changes yourself as well.

    Laughlin: Yeah. There’s some parallels to that conversation, right? ‘Cause a lot time ago this was the conversation for quality assurance. Like: outsource it; there’s an easy button; all your problems will be solved. I think that, from the experience of that, for me there was never an easy button. It was a lotta work and it was a big partnership. But what we did was, through that partnership, we started bringing in technology that my team hadn’t had a lot of exposure to so our options grew, and I found that there were some easy buttons along the way to build, to run tests against that build. So we’re moving into a model now where the assets of quality assurance can be augmenting what is your DevOps model. And that model has to work for your company and it has to be part of your culture. It is not something that just kinda develop out of a box.

    Ashley: We probably need some precision around the term “outsourcing” too. So I think in this context – 

    Laughlin: That’s a good idea [laughs].

    Ashley: – we’re not talking about externalizing it. In other words, put it in a box, ship it somewhere, have someone else do it; give it to us when it’s done. Right? Because we’re transforming the organization. I think it can happen a couple of ways. It can happen early in the journey; I think it also can happen – organizations typically get stuck at some point where we’ve gotten 2, 3 teams there but man-scaling it to a 5,000 or 10,000-person IT organization – that’s hard. It’s easy to do it on a startup basis.

    So everything to me is always driven by what the company is about, what its DNA is like. Some companies are very data-drive: We don’t make a decision unless it’s got a graph attached to it or a financial analysis attached to it. Or tied to a strategy. Or whatever it is. And different companies often taken on the personality of the founders if it’s a younger company. But it gets established with it. And if you don’t have that figured out and aligned with how you’re implementing anything – agile, DevOps, SAFe, whatever it might be – you either go against the flow and fight it all the way and fail multiple times and never succeed or you figure out what fits into the flow and the momentum, the DNA of the organization. 

    That takes knowing people. It takes knowing the organization. It takes commitment by people in the company to do it. So it’s not an outsourced give away the problem. It’s a: I need help because I need expertise, because I’m stuck, because there’s other – we don’t know what we don’t know. And we’re looking to get smart from other people. And we want you to leave someday and help us operate on our own. Maybe help us with a different problem someday. But that’s kind of our goal as an organization.

    Gong: Yeah. Mitch, I fully agree with that. And we certainly have – a couple of points you point out is pretty interesting. One is the challenge that we seeing for large enterprise customers: they usually have problem with cascading kinda DevOps excellence across the organization, right? But there’re so many hurdles, I would say. One of them is organization siloes. We have seen so many times where you have one division, usually on the digital side, front end – they have great success because technology stacks tend to be more modern so it’s easier to get on the DevOps train. But then once you start trying to cascade to a legacy side, it just doesn’t work. Either because they don’t share very well because there’s organization siloes, or because the technology stack they develop doesn’t really work on the other side.

    So where we see, again – I know you have term about outsourcing can mean many different things. But where we see a lot of support or at least success is when we help kind of the organization where they have a COE, where they establish standards – and I think Robina kind of mentioned this too. It’s very important for company to really establish their true North, the compass, right? The guardrails and things like that. But it’s also important to not have a very heavy central organization either to trying to drive DevOps. Because then you’re missing out on all the distributed innovation happening on the ground level so you can never respond fast enough. 

    So this is why when we created our model, we usually have a team, or a very small team, help with the COE side of it to help them kinda develop their whole community, the culture, things like that. But then we have very nimble – we call it deep pod. It’s like a five-member crew. They have – consists of DevOps architect and couple engineers. And what they do is they will be kinda parachuted into an area within the enterprise where they need a lotta help or the application that they using is very critical to the business. Will drop in there. Not only helping with engineering, figure out the tech stacks and figure out the DevOps – all the nuances of it. But we also do a lot of coaching to make sure we can train the team to be self-reliant. Once they are, we lift the team up then we drop the deep pod into the next area where they need help. So this is kind of the hybrid model is where we find more success. 

    Ashley: I’m really curious: Who typically brings in your firm, Ming, your firm, Chris? Maybe, Robina, who brought in someone to bring in help with DevOps. Was that at a very high level? Is it a development team level? I’m thinking larger organizations here. What’s the –

    [Crosstalk] 

    Gong: I think Chris and I probably will share the same answer, which is: all of the above. We have a large DevOps engagement to where the CIO invites in. And we operate starting from the strategy level all the way down to the individual team level. But then we also have, through relationships or whatever case might be, where we insert ourselves into a particular team to help and then grow from there. 

    Rolls: Yeah. Exactly the same. And if it’s okay I wanna go back to one thing you guys said before, which is having a bit of precision around what we mean by outsourcing. Because I think when I see this topic, I jump to full, functional outsourcing of QA or dev or opportunities. But the reality is: outsourcing also exists on a spectrum. 

    You know, when you hire a maid to clean your house or to service your car or anything like that, you are outsourcing that function of your personal life. And it’s the same with software development, right? So there’s the really far down this end where it’s just you have a consultant who’s embedded in a project team, and then there’s all the way down to the far end where you do that full-scale outsourcing of a function or a department. 

    And what I want to be clear on is: the further you get along that continuum, the harder it is. You have to be far more careful about it. And so that’s something that’s really important. And to go back to the question that was just asked: completely the same. Sometimes – and you’re very happy when the CIO or the CEO says, “Come in and help me do this transformation across the organization.” Sometimes it is a QA or dev manager has a specific problem that they want to solve. But I’d also be really interested to hear Robina’s thoughts.

    Laughlin: So how did we bring – I’m sorry. Can we –?

    Ashley: What level did you bring? Was it the CIO brought in somebody to help you with the ____ or was it on a QA development team?

    [Crosstalk] 

    Laughlin: Oh, sure.

    Ashley: How did you start down the getting external help, outsourcing help?

    Laughlin: Yeah. So this is a little bit of a parallel run to a DevOps model. So from a QA perspective, what we did was we decided to centralize our enterprise quality assurance organization. And when we did that, certainly we got economies of scale, but I needed a partner or a vendor that would come and work with me. And when I say partner, I truly mean it. Like we have team meetings. They’re all folks that work for me. I don’t distinguish. So you have to be able to have that relationship I think to be able to get success out of outsourcing, if you wanna call it that. Because it’s really partner shipping, in my mind.

    So that was the journey that we took. And that’s been underway now for almost eight years. So we have an incredible wealth of assets behind us. And I started stopping and looking at what my partners were doing on the other side of building and deploying, and how are they verifying that building? We’ve been moving this shift-left journey of discovery of quality issues for a long time now, and we’re at the point where we’re in the build stage. And I’m like, “Well, we have great assets that could help verify that a build’s gonna work. What’s the next solution to that?”

    So I reached out to my Cognizant folks under my QA umbrella and said, “Hey, if we were to think about extending our assets use, what would we do?” And they were like, “Turn to your DevOps team. Turn to your build and deployment team. Let’s understand what they’re using. They’re using Jenkins. They’re using Bitbucket, example for us. So when we started looking at being able to scale our assets and use them across the enterprise, we built them in Jenkins. We built our actual Selenium code in Bitbucket. So now we have the hooks there and we can – as these teams start to catch up or we start to catch up and we meet in the middle, we then have a problem we’re trying to solve. We are getting builds. They are broken, or when they pass, there’s quality issues. Can we discover them through automation? So that’s the easy button.

    And in this case I actually do have the easy button. I have this regression suite. I can slim it down to a smoke test or something, and say, “If we can deploy this and do all of this then, yes, we can get those results.” And then the next phase of it is accountability of teams of what they’re gonna do with those results.

    So none of that is technical. That’s all cultural. Except for the hooks in what we built. So that’s kinda been our journey and that’s where I’m looking to go strategically.

    Shimel: Excellent. So, guys, I want to bring this down or – we touched on it already but I wanna clarify it. You know, Ming and Chris, you’re in a unique position in that you guys get to see dozens of organizations and how they approach this problem. Where, Robina, your view is Guardian-based, right? This is what you guys have done at Guardian.

    Here at devopsy.kinsta.cloud I’m also – I’m in a catbird seat in that I get to speak to many people like Ming and Chris, but I also get to speak to many people like Robina. I get to speak to people like Mitchell. I literally get hundreds of views on this. And I recognize patterns. And what do I do? What’s my superpower, superhero power? I’m good at recognizing patterns. I guess I’m a machine learner. But anyway, there usually is a pattern along DevOps adoption. And it’s similar to what Robina mentioned, which is – when I first launched devopsy.kinsta.cloud, our tagline was “DevOps picks up where agile leaves off.” Right?

    And, yeah, because what happened was people were moving the agile development processes probably going on 20 years now. Agile’s been around 20 years. And it was great. It makes you feel old. I’m sorry, Robina. But, yeah, it’s 20 years [laughs]. Don’t feel bad. I watched this “Halt and Catch Fire” about the birth of the PC industry. Yes, that’s what it is. Einstein’s theory of relativity [laughs]. 

    Laughlin: I remember my agile training with Ken. I can’t imagine 20 years –

    Shimel: Yeah. Ken, who now of course is Scrum.org, right? Versus Scrum – the other one. Not here to get into that one. That’s another rat’s nest.

    Gong: Different podcast [laughs]. 

    Shimel: Yeah. But the thing is: the normal course, if you will, is: yeah, we do some agile. Whether it’s Scrum or SAFe or whatever we’re seeing out there, scale. We wanna start getting into some lean IT stuff. And of course when you start marrying agile and lean, it’s DevOps, right? That’s kinda what DevOps is. And now we’re gonna get into CI/CD pipelines. And of course it’s grown since then. We’ve added SRE on. Continuous testing has become huge. Right? It’s a huge piece of this. So we’ve seen the sprawl, the urban sprawl of DevOps and agile over the last 20 years. Along with it, I think it’s become all but impossible to do at a large organizational scale, at a large enterprise scale, without some outside help. 

    I think we’ve recognized the enemy. It’s us. We’ve created the need in our large organizations, the way we go about adopting these things, that we can’t do it without outside help. 

    Laughlin: That’s very true, Alan. I think that’s why you really need the outside help and you need to go to the experts. Because no one size fits all. No one tool solves everything. That’s how I got involved with Tricentis: I went out really early looking for a vendor that would grow with me and was on the same aspirational journey that I was, right? So that’s where I think it really helps in terms of consulting. You need to pick the partner that’s gonna work with you and grow with you. And sees you for your uniqueness, not an industry standard.

    Gong: That’s right.

    Shimel: Chris, Ming? 

    Rolls: I think you can’t take a single ___ of technical practices or cultural adoption and apply it to every single organization. So that point, Robina, about making sure that you tailor it for the organizations that you’re working with – or even within an organization, the different departments, the different products that you’re working with, right? There’s a different sort of cultural mode within the digital section versus the enterprise technology section, right? So that’s really important. 

    And I think that also comes to a thing that I see that often people get wrong when they do outsourcing is that they don’t align the incentives properly. Because ____, we all have different incentives. Even, Robina, if I was partnering with you and we want to work as really good partners, then I have a slightly different set of incentives to grow my company as Guardian does, right? And so we have to find ways to align those incentives. Otherwise you will create a cultural conflict which prevents you from really going as fast as you can. So that’s just something that I see often people get wrong about moving to DevOps, because they have to use outsourcing in particular, engaging firms to help them with that.

    Gong: I wanna go back to the point Alan was talking about in terms of the massive talent shortage in industry. And it’s not just DevOps. It’s cloud, everything else, right? Just in general I think we all wish there’s more qualified folks who has those technical skills. And I think that’s one of the reason why a lot of our customers want some help from us. Because they simply cannot find enough talent out there that not only knows the DevOps technology but also has the ability to keep up with a crazy changing industry, right? I mean, you see a massive change even within the last couple years where used to be all the siloed best-in-breed product like Jenkins or whatever else, and then artifactory, whatever. 

    But now you see a trend where industry’s moving towards more of a kinda end to end all in one type of tools, right? For example, you have the Azure DevOps, GitLab, and the whole – they start offering the whole suite of things. Because they recognize the massive talent short. You can’t take care of the problem until you can also solve the problem on technology side as well. So that’s kind of approach that we’re taking as well, where not only we have on people side we have our deep pods kind of coaching the team so we can get lots and lots of teams to train up to be self-reliant. But on the other side we also develop on platform to kind of try to extract all the complexity of DevOps from the user so the user doesn’t have to be an expert. So we call it democratizing DevOps for everyone, right?

    So I think for a company to be successful they need to kinda take approach of kinda both people and the tools combination. 

    [Crosstalk] 

    Ashley: ___ kinda just share a personal story in my additional adoption of DevOps when I was a CIO at a company. And it was initiated by me ’cause actually Alan had reached out to me and said, “Hey, Mitchell, there’s this thing called DevOps. You gotta go read about.” I’m like, “Okay, what is it? I’ll go figure it out.” I got hooked onto it.

    But the rest of the team hadn’t really caught fire yet of getting onto DevOps. And so as a leader of an organization, it’s tough to say, “Okay, I want us to go this direction; I think this would really be helpful for us” when the team’s not there yet. And really understanding what it’s gonna take to get the organization going and get behind it and how to be successful at it. This was earlier, so you reach out more to individuals that’ve started to build some brand and some experience in doing things like DevOps.

    Today I would go to a different kind of a team to say, “Here’s where we are. Here’s the projects that we have going on. Here’s kinda what we’re being asked to do,” right? I think every – maybe not true, but it seems like most IT organizations are always being asked to transform some way, somehow. And sometimes pretty radically. And if you can sort of set where we’re headed and tie it to the why, as you talked about, Robina, the why for the business though, not for IT, that seemed to me to be the biggest thing that everybody could rally around. Not that it was DevOps or agile or it was this. It was: “We wanna go after this market. And our ability to get there is really constrained today. And let’s figure out some ways we can go after that.” And that tended to rally around.

    So I think today – I guess my point is: Today we’re at a point where we can hire more expertise. And we wanna de-risk our journey and learn from others. We don’t have to figure it all out ourselves and be the smartest person in the room. Certainly I don’t. And that’s a great environment to be able to bring in help.

    Shimel: Robina, I’d like to throw out – there was a time when we used to look at quote/unquote “outsourcing” and consultants, and one of the terms that was thrown around was “body shop,” right? Like, “Bring in some bodies. I’m gonna rent some bodies.” I remember when Mitchell and I were at StillSecure. We’d go down to – we had a big federal practice, and we’d go to a federal facility, whether it’s a lab or a knock or what have you. Eighty percent of the people there were not federal employees. They worked for Grumman Northrop or SAIC – take your pick of the beltway bandits. But it was all body shop. And when you’d speak to the salespeople at these consultants, you’d say, “How’s business?” “I got 50 people placed.” Not what the mission was, what the tools were. They judged their success by how many people they had placed.

    I like to think – and maybe I’m naïve; Robina, I’m gonna ask you – that we don’t judge the success of our DevOps outsourcing by how many bodies I’ve got buried at a given location. ‘Cause I think that’s a terrible metric to determine the success of a transformation.

    Laughlin: Yeah. That’s a great observation, Alan. You just kinda gave me shivers when you talked about number of bodies. I remember those days. They’re painful to look back on, honestly. There was a time when you needed an army of folks to do things and I don’t necessarily think that’s the case now. For me, our journey was: I needed a partner and I needed someone that was gonna come here and work with me. And through that partnership I also needed to know that I was gonna have a 24-7 shop, and that’s gonna necessitate overlap on both sides, right? Your onshore and your offshore. So I don’t think you can ever just kinda set it, forget it, and throw it away to an offshore team. That’s just not how it works.

    And I think the other piece of it is: at the very source of it, you have to remember that these are human beings. They have families. They have lives. They wanna do good work just as much as we wanna do good work. And the way that they’re gonna feel that contribution is being part of the team. And the way they’re gonna feel that sense of that is by being present. And we actually flipped the dynamics. So we’re no longer a headcount shop. We’re an outcome shop. So I measure the success of my organization by the outcome of our testing. And for me, with my partner, if they do it with 2 people or 200, that’s their discretion. So I don’t have to get into any more of these conversations of: “We need two more bodies here. We need eight more bodies there. I’m anticipating 12 bodies.” That just turns into I think an empty use of really valuable strategic time that you have with your partner. And you should be using it a little bit more productively, right? 

    So that’s how I flipped that dynamic. And I’d be very curious to see how Mitch and Ming feel about it. And Chris.

    Ashley: Well, my first reaction was I thought you were gonna talk about “Sopranos” or something. A whole different kind of body [laughing].

    Shimel: Bada bing.

    [Laughter] 

    Ashley: You know, I really like how Robina described it. Because it isn’t about budget size and all of those kind of backwards metrics. And I’m sure they’re still used today. To me that’s a measure of how aligned you are with the business. If you’ve shed the financial size, the IT-only-centric metrics to “What are we making an impact?” – there’re a lot of ways we can do a digital transformation project. We could get the contact list services let’s say. Something very relevant today. And it doesn’t have to be with hiring 50 more people ’cause we’re probably never gonna find 50 people to hire anyway. So we’ve gotta find other ways to do it. 

    But there’s also – there are times where I need these people to fill these roles. And I’m sure the body shop approach still applies in some situations. I doubt it on strategic projects though. That would be my supposition.

    Shimel: Chris and Ming, I’d like to hear from you guys on it though. Because you’re on the other side of the equation here. Chris?

    Rolls: I hate the term “body shopping.” It’s a terrible, terrible term. And I talk to the team and I say, “We have to have stamped on our forehead, ‘We are not a body shop.’” Because if you’re going in there and your goal as a account manager is to get 50 people on an engagement, you’re not thinking about what that organization needs. You’re not thinking about what the business outcomes are. You’re just thinking, “I can make $10.00, $15.00,” whatever how many dollars it is off each person, “and what’s my commission for that?” That’s a terrible way to think about it. And what’s more, it shows an outdated way of thinking about the people who are going to do this work. People, process, technology – people, in my mind, being the most important part. 

    If you’re thinking of them and you’re calling them “resources,” which sometimes we all slip into, or you’re calling them “bodies” – that’s not just a warm body in a seat typing some code or testing some software or monitoring the systems. They’re people who have skills who are thinking about things who are trying to do the best work they can to deliver outcomes for the company. And so I hate that term “body shop.” I hope that no one associates that with me and my company. And I think it’s a terrible way to think about delivering software.

    Gong: Yeah. I definitely second that. I mean, what Robina just articulated pretty much echoes what pretty much all of our enterprise customers have said. They should absolutely transition from where it’s just TNM type of model before now to it’s all about outcome-based. And that’s what we prefer as well. To Robina’s point, why the customer should care how we deliver it as long the outcome is what they want, right? 

    We actually created a digital agility transformation manifesto [laughs] in honor of agile manifesto. And one of the top one is actually called “Value over volume,” which is exactly what, Alan, you just talked about in terms of, hey, you should not be measuring success with transformation by the volume of things got done. But it’s more about the value, right? So in this case, instead of measuring, for example, how many DevOps ____ did we create – that’s not important. What’s important is: how much faster are we able to help the team to deliver software to the production faster? What’s the frequency increase? So those things are what matters. So that’s what we absolutely focus on.

    Shimel: Excellent. Guys, we’ve got maybe seven or eight minutes and there’s one area we haven’t hit on yet that we’d be kinda negligent if we didn’t hit on it, and that is: what effect has COVID had on all of this? On one level, we could say, “Well, look, everyone’s looking remotely anyway. What difference does it make if they’re an employee or an outsourcer? We’re all remote. We’re all equal in that regard.” The other way is: “How do I graft these people into our culture? How do we make them part of the team when we’ve never shook hands in person, when the only way I ever see you is on a “Brady Bunch“ Zoom window here and you take the top left?” Right? “Can we really integrate in just remote-only settings?”

    Ming, Chris, you guys deal with it. You’re dealing with it over and over again. Robina, you are too. Right? Everyone’s remote. How has COVID helped, hurt, hindered, accelerated – how’s it affected this?

    Rolls: So, I think one thing is that if we asked people five years ago, “How do you do agile? How do you do DevOps?” you’d say, “Everyone has to be in the same room. They have to be collocated. You’ve gotta have stickies up on the wall.” 

    Shimel: Chris is kinda sticking on us here. Okay. Go ahead, Chris, I’m sorry. You kinda hung on us. We got stickies on the wall.

    Rolls: Yeah. So I was saying in the past people would say, “You have to have everyone in the same room, stickies on the wall, and that’s the only way you can do agile and DevOps.” And I think one thing that has been good with COVID is that it has dissuaded us of that illusion that that is the only way to do things because we have been forced to do it differently. That being said, it is so much harder to create culture, whether it’s in-house or whether it’s outsourced, when you don’t have that face-to-face collaboration. There’s only so many times people can do a virtual happy hour and still really get into it. So you have to be – I’m sure first time everyone’s like, “We’re having five happy hours a week. I’ve got my bottle right next to me.” And you’re two months in and you’re saying, “Geez, I cannot do this anymore. I just wanna go to bed or watch “Sopranos,” right? 

    But I think that we really need to focus on building that culture and come up with creative ways to create connections between people. 

    Shimel: Agreed. Ming? 

    Gong: Well, let me see. Hold on. Give me a sec. 

    Shimel: Okay [laughs]. You going to your happy hour background?

    Gong: Absolutely.

    [Laughter] 

    What you’re seeing here is the – my family and I, we took a hike recently to a Malibu beach, and I took a 30-second video of Malibu and use that as my background. So this is one of the things that I started asking my team to do: trying to personalize this kinda virtual experience. I’m a absolutely people person. So I miss the in-person bonding dearly. But in lieu of that, we basically, every time we have team meetings with our customers or with our own team, we pretty much strongly encourage everyone to get on the video so at least we can see each other. But to Chris’ point, there’s always a silver lining to everything. Because the COVID certainly forced or speed up a lotta things that was gonna happen anyways. So, to that, I think it’s a positive thing. Robina? I’d love to hear your thoughts [laughs]. 

    Laughlin: Sure. What a year we’re all having, huh? Surprised. So, I think in terms of working with your partners through COVID – and we’ve been talking a lot about culture – I think one of the foundation things is to pick a company or a partner that has a very similar culture to you. So then you’re not trying to find middle ground in that. And that should really be a big part of your selection process. You need to be comfortable with the folks that you work with and you need to be living kinda to the same standards I think. 

    So for me, how COVID affected me was: while we were all scrambling to get ourselves home and reaping the benefits of a long-term plan to be able to have a remote workforce – we learned that through Sandy a long time ago and we had done a lotta changes – I was also working really closely with Cognizant in helping to get all the resources that they needed to get my folks home at offshore, right? So I was as concerned about offshore as I was concerned about onshore. 

    And now to this day my job is actually pretty high-touch now. And the reason being that we’re so far along, I have people that’re really overworking themselves. And I think that – and I don’t know that it’s deadlines as it is: take pride in craftsmanship, and they’re home and they wanna – this is something for them to do. Or it’s a stress release in a really challenging time where everything’s unpredictable. But I spend more of my time saying, “When was the last time you took a day off? When was the last time you took an afternoon off? You need to recharge. You need to gather yourself.” And that’s for offshore too. So that’s been my challenge this year.

    Shimel: Fair. Mitchell, I know you guys at Accelerated Strategies Group did a study on the whole remote thing and COVID. Thoughts? 

    Ashley: Boy, I could talk for an hour on this. But I’ll just point out a couple things and I’ll point folks to the report. We looked at – software developers already know how to work remotely, right? A lot of them do. And so how has that affected them? How has COVID and the work from home affected them and how have they kind of affected the organization?

    So, interestingly enough, across the board – there’s about 350 participants. Across the board, everyone is above 60 percent of who have accelerated digital transformation projects, contact – new forms the delivery and automation. But what I really found interesting was how influential DevOps practices, whether you called it DevOps or not, had started to infiltrate into the organization. So I’m talking about things like doing daily standup meetings or more cross-functional teams, increased use of that, asynchronous communications like a Slack or a team as opposed to being on a phone call or in a meeting. So there’s all these ways of working that, as we were talking before, sort of forced everybody into it. And the teams that had really good software teams working remotely jumped on board. And you saw an increase in the use of that kind of style of work, sometimes facilitated by tools, sometimes just process. 

    So if you wanna read the whole report – and reading is minimal; it’s all infographics; it’s super easy to consume – go to ACCELST.com. And it’s free to download. And enjoy. And let me know if you have questions. Love to talk to you about it.

    Gong: Awesome. 

    Shimel: Excellent. Guys, we are outta time. We’re actually over time. Robina, Ming, Chris, I wanna thank all of you for joining with us today. This was a great discussion. In the show notes, production notes, we will have links to your websites and any other links you wanna put in there. But all three of you are dealing in the real world with real problems that we’re seeing today and helping organizations solve ’em, whether it’s your own organization or other organizations. So keep up the great work. We may revisit this topic on DevOps Unbound someday, and we’d love to have you back on here. Okay?

    Gong: Pleasure.

    Shimel: Thank you so much. 

    [Crosstalk] 

    Laughlin: Nice meeting you guys. Good luck. Thank you.

    Shimel: All right. Mitch, thanks as always, man. This is Alan Shimel for DevOps Unbound. Thanks for joining us. We’ll see you on another DevOps Unbound real soon.

  • EP 4: DevOps and the Mainframe

    EP 4: DevOps and the Mainframe

    In this fourth episode of our DevOps Unbound streaming broadcast on TechStrong TV and devopsy.kinsta.cloud’s sister site Digital Anarchist, Mitchell Ashley of ASG and Alan Shimel are joined by Gerta Sheganaku of Tricentis, Rosalind Radcliffe of IBM and Sam Knutson of Compuware to discuss app modernization, mainframes and DevOps. Find out what’s the right way to modernize your applications and how to do app modernization in a Z environment.

    The video is immediately below, followed by the transcript of the conversation. Enjoy!

    Transcript

    Alan Shimel: Hey, everyone. This is Alan Shimel. Welcome to another episode of DevOps Unbound. This is episode four of DevOps Unbound, and then we’ve also done two DevOps Unbound roundtables. So this is actually the sixth DevOps Unbound event that we’re presenting. They’ve all been great, and I think this one is gonna be as good or better than any of ’em.

    Today’s topic is app modernization and mainframes, along with DevOps, of course. It’s DevOps Unbound. We’ve got a great panel lined up for you. Let me introduce you.

    First of all, we have Sam Knutson, and Sam is the product manager — is a product manager for mainframe and agile DevOps at Compuware, a BMC company. Sam, did I get that right?

    Sam Knutson: Pretty much, Alan.

    Shimel: Correct me. Get it right for the record.

    Knutson: So I lead product management at Compuware. We are a BMC company, and we are focused on enabling agile and DevOps on the IBM z/OS platform.

    Shimel: Fantastic. And the lesson I have learned here is I’ll let each of you introduce yourselves. My next guest is the one and only Rosalind Radcliffe. If you want to know about DevOps and mainframes, there’s no better person in the world to go to.

    Rosalind, welcome, and why don’t you give them a little bit of your title and background?

    Rosalind Radcliffe: Thank you. Glad to be here again. Rosalind Radcliffe, IBM distinguished engineer, responsible for DevOps for enterprise systems. I help clients with their transformation to DevOps for z/OS applications as well as application modernization and bringing z/OS into the rest of the world so you can do your cloud-native development for z/OS as well.

    Shimel: Excellent. Then we have – I’m gonna do my best here – Gerta Sheganaku of Tricentis. Gerta, how bad was that?

    Gerta Sheganaku: Thank you, Alan. That was perfect, really.

    Shimel: Okay. Gerta, your background and title?

    Sheganaku: I’m with Tricentis, as you said. I initially started at Tricentis in the customer experience space, where I was leading our customers through their digital transformation journeys, really helping them understand how they can enable testing as a catalyst to really get DevOps working.

    Then I have moved into the product organization, where I’m currently leading a team where we’re releasing our first AI-based test automation solution, which is really about tackling the problems that we see out there, especially when it comes to app modernization, and testing of old applications and new applications and really making testing easier.

    Shimel: Excellent. And then last but not least is my sidekick, well, partner in crime, Mitchell Ashley, CEO of Accelerated Strategies Group and also my co-host here on DevOps Unbound. Mitchell, good to see you.

    Mitchell Ashley: Good to join you.

    Shimel: All right, guys, today’s topic is app modernization, mainframe, and DevOps. It’s interesting. I’ve been kind of binging on Netflix that AMC show, oh, “Catch Fire”? I forget the name of it now. Anyone else watch this show? It’s an AMC on Netflix.

    Knutson: “Halt and Catch Fire”?

    Shimel: “Halt and Catch Fire.” You’ve watched it, Sam?

    Knutson: I’m familiar with the instruction. I’ve seen the previews for the show.

    Shimel: It’s a pretty good show once you get into it. So the company that started in Texas bets everything ’cause they’re tired of paying the timeshare people, and they buy an IBM, what is it, 3030, that’s based in Daly, San Francisco, or Daly, California, near San Francisco. They literally have to move the whole company to where the mainframe is versus moving the mainframe to where the company is. Well, it’s TV. But that was the late ’80s, right, and we don’t live in those worlds anymore.

    Mainframe applications are running on your phone, right, or at least the front ends of them are, on your tablets, on your computers. The mainframe doesn’t necessarily fill up – this was a whole basement that was one mainframe. It was pretty funny. The guy was sliding cards in and stuff like that. If you get a chance, watch the show. It’s an interesting, interesting look back.

    Certainly the modern mainframe has come into the world of DevOps. Rosalind, I think the work you have done with IBM has led the market with that. Quite frankly, Sam, the work Compuware has done has led the market in agile and DevOps on mainframes. How would you assess where we are currently in mainframes in the world of DevOps?

    Radcliffe: You mean where the mainframe is or where people are? I think those are two very different things.

    Shimel: You’re right. But what we’re not moving the whole company to the computer anymore, thank God. But let’s talk about where is the mainframe, and then we’ll talk about where the people are.

    Radcliffe: So you’ve got to remember, the mainframe itself, IBM Z, is the most modern machine out there. The IBM Z platform has evolved every few years for the last – ever since it was invented, and we keep evolving the machine.

    So the machine itself is the most modern system, and we’ve evolved the operating system. We’ve evolved things such that open source tools work there. We’ve done everything to remove the barriers from the system so that you can do exactly the same kinds of things, whether or not you’re doing z/OS development or another environment. And the Z hardware itself, we all know it runs – well, we all know on this call it runs Linux on Z.

    And so it’s a very large Linux server. It runs containers, and it runs OpenShift. So from a systems standpoint, it provides – there’s nothing keeping it out of the processes and practices. There’s nothing separating it from a systems standpoint. It’s the way people interact with the systems. It’s their existing applications that make it harder.

    Shimel: Sam?

    Knutson: I think Rosalind makes some great points. The current generation of IBM mainframes, the z15, is an engineering marvel, and the compilers and the operating system produce this amazingly efficient platform. It is the most efficient hyperconverged system in the world today.

    But I think the elephant in the room is the word that you used a minute ago when you said “modernization.” We alluded to this a little bit in the way that the practices that people and businesses have today. Well, modernization doesn’t mean moving off platform, because we already talked, and we could go on for an hour, about how great a hardware and software platform this is for running business computing. It is amazingly efficient, especially when you look at the large-scale, global business applications that the Fortune 1000 run, which is where the platform has its largest footprint.

    But the perception is that modernization is moving your application into a cloud-native application off the platform, hosted by another provider, or rewriting it in Java, and nothing could be further from the truth. The COBOL compiler alone is a perfectly paired piece of engineering with that platform, and it lets you wring every last ounce of efficiency out of it.

    But people need to get past that confusion and say, “What if I could work on the platform in the same way I’m working on every other platform?” It’s that normalization. We’ve kind of coined the phrase “mainstreaming,” “mainstreaming the mainframe” to make it different in syntax only, and Rosalind alluded to this. It’s being able to work on this platform in the same way that you work with any other platform. So when you think about DevOps, then you have a DevOps toolchain that looks like other toolchains, that you can connect all of the ecosystem partners that you’re probably already using in distributed development.

    People are definitely the problem, people and practices and culture. More than three-quarters, in fact 78%, of customers say it would be useful if they could update their mainframe applications more frequently than they do today. So there is an aspiration to change and to get better outcomes. You can see what they want. They want to be able to deliver value to customers more frequently, and that’s just one of the improvements that they want to make. But far too many people are not making progress on that.

    Shimel: Gerta, so you’re not a mainframe specialist, but certainly app modernization and testing of this. I’m wondering if you have any kind of information regarding people using Tricentis to test mainframe-based applications. How big a market is that?

    Sheganaku: That’s a very good question. One major thing that you always have to keep in mind, as we just said, especially when talking about app modernization, it is such a wide word, and it can mean so many things, too, to different people. It’s definitely something that’s challenging for our customers looking at their current system landscape. You see customers that are having everything in their landscapes from mainframe applications to also often very legacy mainframe applications that are trying to move onto more cloud-based environments. That is something that we see very often.

    Mainframes are still there, but the thing is that people really want to abstract away from the mainframe. Also thinking about where we are today, I think an important question we have to ask ourselves is why is everyone so into app modernization? Why is everyone into migration into the cloud currently?

    If you think about it, nowadays every company basically is becoming a software company, and not every company has the talent and the resources to maintain those mainframe applications because at the end of the day, honestly I struggle finding COBOL developers nowadays out there. I went to the Technical University of Vienna, and we definitely did not learn anything around COBOL there. It’s really hard to find the talent nowadays.

    When you look at it, basically every company, be it in retail, be it in banking, be it in the energy sector, you now want to have connected systems and so on. Really, everyone is going more towards being a software company. And with that, for people it’s becoming more and more increasingly important to have really good platform-as-a-service offerings, maybe going into serverless or software-as-a-service in the next step, but really having not really to deal with the underlying maybe mainframes and having a way of abstracting and using simpler technologies and only caring about the applications and the data that they’re running on those systems.

    Shimel: I’ll be honest with you, I don’t know if I agree with that. So here’s the premise of this, right? When we talk about app modernization, I’d love to live in a world where I could throw out an old app ’cause I want to have a new app. But we don’t live in that world, right, and no one lives in that world. That’s why we call it “app modernization.” We tend to modernize the apps we already have.

    And so when we look at – I think out of the Fortune 100, 98 are on mainframes. Or it’s some number like that, Sam or Rosalind, if you know. I don’t see 97-and-a-half of them throwing their mainframes out, right? As a matter of fact, they’re probably building more on mainframes. And so what’s happening is we’re seeing whether you want to call it hybrid cloud, VoLTE cloud, whatever you want to call it, we’re seeing where people can build maybe a front end for stuff in the cloud. But if that data is important, if security is important, if scalability is important, dollar for dollar, people who use mainframes know that that’s their best bang for the bank. Mitchell, I’ll let you chime in.

    Ashley: I have to jump in. So what’s interesting is we kind of do this to ourselves with the terminology that we use. “Mainframe” is a word for a cabinet used to house the computers the original IBM computers were stored in.

    If I said, “Hey, 71% of Fortune 500 companies rely on high-volume transaction-processing platforms. Ten out of the ten world’s top insurers, 23 out of the 25 world’s top airlines, 92% of the top 100 banks rely on high-volume transaction-processing platforms,” you would say, “Wow, that’s pretty cool.”

    “And it runs Linus, and it runs containers, and you can connect it to all kinds of applications from tablets and phones to wherever your application may be running, on cloud or on premises.”

    You’d say, “Wow, tell me about that. I’d like to learn about that.” That’s what mainframes are.

    So it’s interesting. It’s not going away. We do this to ourselves, and I say the analysts have done this to us, too, right? Today it’s all about this next shiny object, the squirrel moment. It is so vital to businesses today, and moving it into how we create software with DevOps and processes like that and tools to support it is essential for businesses’ both economic recovery, survival, and future. Digital strategies can’t happen without it for many, many, many companies.

    Okay, did I do a good job, Rosalind and Sam?

    Knutson: Mitch, those were great stats, and I think you did a great job quoting ’em. I’d boil that down to simply saying the worldwide economy and worldwide civilization runs on the mainframe. And I like the word “mainframe.” It has a little swagger. I don’t think it’s ever gonna go out of style.

    Ashley: Nostalgia.

    Knutson: And renaming the platform could make it cooler. It simply gets things done. We haven’t renamed cars yet. Well, maybe we’ll rename them to “highly efficient transport platforms,” but I think we’ll still be calling ’em “cars” when they have electric engines powered by portable fusion reactors. But customers see this as a long-term platform. BMC does an annual mainframe survey, and the 2020 edition is gonna launch soon. I can tell you that 90% of the customers see the mainframe as a platform for growth and long-term applications. Sixty-eight percent of ’em expect the size of that compute platform to grow, MIPS to grow. Sixty-seven percent of those organizations have the majority of their data on the mainframe. They trust it because, as you said, it’s highly available, scalable, secure.

    And to go back to Gerta’s key point about younger workers, that is absolutely essential. But what’s going on is that people are addressing that because – I think Rosalind and I both alluded to this – the syntax of COBOL isn’t Aramaic. It isn’t some incomprehensible script.

    If you put modern tooling around this, if you put modern process and a great, supportive culture that gives that great – you have a great developer experience, you have a great developer culture, then learning the syntax of COBOL is no more difficult than learning the syntax of Perl or Rust or Go. So we see that customers who see the platform long-term are making the appropriate investments. In the responses to that survey I mentioned this year, younger mainframe workforce definitely figures in, 43% less than five years on platform. Sixty-eight percent were under 49 years old, and 60% of that new generation see this as a growing platform.

    That really matches the experience that I’ve seen in Compuware’s journey is that we hired out of college and we have been hiring out of college, and those next-gen developers are more than a third of our workforce now in Detroit. Many of them did not know COBOL, and many of our applications are written in assembler. They certainly didn’t learn assembler in college. But what they did have was a strong bent for learning new technologies. Many of them came with computer science degrees. They had learned how to learn. They were what Gartner calls “polyglot programmers,” one, two, three, many in learning languages.

    So whether we needed to learn assembler or COBOL or C, it didn’t matter as long as we provided that supportive culture, the vehicles for learning, and we gave them meaningful work early on in their employment and made sure that they understood the vision, mission, and goals of the firm and how they were contributing to something that matters. I think our customers are having similar success in onboarding next-gen developers by doing some of these same things.

    Radcliffe: I think it’s interesting, the statement, “I can’t find COBOL developers,” because when I was hired in to work in this industry, nobody assumed you knew the language or the system you were going to work. That was the thing you learned. You learned how to develop, and then you came in and learned the company’s culture and the company’s tool choice.

    By using modern tools, modern practices, all of these things, the things they have learned in college on how to do, they’ve already got. And then the only thing they’re doing is learning COBOL.

    As I always joke, it’s just English. I know that works really well in the US and in parts of the world, and in other parts it’s, “Okay, it’s still a foreign language.” But it’s not a difficult language. It’s easy to understand. PL/I, it’s not difficult to understand. It’s just another language, and developers can learn other languages.

    I am kind of with the discussion about “mainframe” is not the word we should always use, and we really need to focus on how do we talk about our platform. I like the term “mainframe,” too. I still use it. But can we talk about our platform as this platform that provides this valuable, high-transaction server? It’s that big server as part of your pipeline. It’s not that old thing. It’s that big new thing that runs all this work, and now let’s focus on the applications that – Honestly, the best thing IBM ever did was a program you compiled in 19-whatever and still works today, and the worst thing IBM ever did was that program that you compiled in 19-whatever and still works today. It’s the best and the worst of the platform. You don’t have to change. It still just works.

    And if we can help companies understand if they start to change some of those, they can do the automated testing. They can do all those things. They can get more value out of their platform. They can help refactor and be able to move at the speed they need to.

    Shimel: Go ahead, Gerta.

    Sheganaku: These are all amazing points. I hope no one got me wrong at the time beginning with what I wanted to say. I really like what Rosalind just said, to talk about the underlying platform that is really enabling. But the point that I really wanted to make is that most companies are now becoming software companies. We don’t have that knowledge center of IBM, where there are so many smart people and you can learn from people and really develop that amazing platform that you offer other companies.

    But when I look at our customers, it’s usually self-built kind of mainframes that are sitting there that are not maintained that don’t apply current recent security standards. Those customers, what you see them do often is they all hear, “The cloud is the next thing. We all have to go to the cloud.”

    They all do this one big mistake that they just take whatever they have and they basically do the lift-and-shift approach, bring it to the cloud, and hope that everything’s gonna work. Of course that’s not gonna work at all. Also from a cost perspective that is insane, thinking about how much cloud resources actually cost you if you don’t do all the optimizations and so on. So what you see people do is kind of a step-by-step learning approach where they are taking things from not-so-secure systems, bringing them over to other systems, then starting to refactor the applications, and giving more and more also responsibility to the development teams.

    Once they do that, you see the development teams really getting that DevOps approach, really caring about the infrastructure, and so on. For the developers, of course it’s easier if they have container-based applications that they can simply deploy and so on. But of course underlying it’s very, very important that you have a secure and great platform that is enabling all of that.

    Shimel: I think that’s a great case for why you’d want to use a mainframe or whatever you call it, ’cause it’s probably more secure than the cloud is, I think, and it’s been proven. But here’s an interesting thing I’ll tell you here I see in devopsy.kinsta.cloud, right? This is devopsy.kinsta.cloud, mind you. And it was surprising to me. Our biggest article last year on devopsy.kinsta.cloud, most views, most comments, “The Beauty Of the COBOL Programming Language” by Bob Reselman.

    I don’t know, it had half a million or something, maybe more, a crazy amount of views. Most of the comments were by COBOL programmers in India because there they recognize that there’s such a need for COBOL programmers that you have a lot of young people who are studying COBOL because they know it’s basically a guaranteed job for them, right? They come out and they start working right away.

    Here’s another interesting thing, and my friends in Tricentis will notice – will appreciate this. What do you think was another huge area of interest in devopsy.kinsta.cloud? Running SAP in a DevOps world, right? We don’t think of SAP as DevOps-enabled or maybe not even agile.

    We did a roundtable a week or two ago on SAP in DevOps. I had to cut the questions off, and these were meaty questions: “How do I do this and that in this and that release?” It wasn’t just pie in the sky. They were very how-to, practical, “We’re running SAP, and we’re moving towards agile and DevOps and we’re doing these things.” So while everybody – we always rush to the shiny new trinket and the hot thing in our industry, I think the fact is certain things endure. As Rosalind said, it’s both their greatest and worst attribute. It is.

    But let’s talk a little bit about app modernization ’cause I think Gerta alluded to it. Mitchell, I’ll throw it out at you. No one wants to do shift and lift or lift and shift or whatever. It doesn’t work in 2005 when the cloud first started, and it doesn’t work now. But how do we do app modernization right in a Z environment? Sam, Compuware has made a – it was the reason for your being in a lot of these last couple years, right, something Chris O’Malley always harps on. How do you do modernization right in a mainframe world like this?

    Knutson: First, you do it on platform because – I can’t say that enough – when you see people try to avoid touching the mainframe apps that live on the mainframe, they do unnatural things from an architectural point of view, and they create these horrible kludges that are not robust, that are not scalable, that are not the most efficient implementation, and that aren’t easy to maintain. So you want to bring those practices on platform. You want to provide developers with helpful editors, with quality tools. You want to tap into the automation pipeline. So build a CD pipeline that goes right onto your pipeline so that you give developers a great developer experience, but you keep the business logic and the data on the platform.

    That goes to a number of things. When you talked about security, something that I learned a long time ago, the more copies of data you have, inherently the less secure it is, because typically when mainframe data is moved off the mainframe, the security controls that are on the platform are not replicated.

    So if you can take that core business logic, that digital DNA that a business has inscribed over 20, 30, 40, 50 years, continue to leverage that, and of course leverage systems off platform. Compuware really blazed this trail of using cloud and mainframe together with two-platform IT. We think these things are incredibly complementary. But what you don’t need to do is replicate that data all over the place. You don’t need to necessarily have a lot of on-prem systems. The term “hybrid cloud” was used, and that’s a nice, modern way to talk about that. We say “two-platform IT” because these things will pair very, very well.

    And the cloud, by the way, is an absolutely great place to host commodity applications. If you talk about your company’s e-mail system, I probably cannot run Microsoft Office better than Microsoft can with Office 365 in the cloud, and they can provide all the quality, the service, the latest updates. It’s a good solution. Can I do invoicing better than a cloud provider like NetSuite or Oracle? Probably not.

    But what I want to do is focus on those applications that give me unique business advantage, the things that I wouldn’t find in Amazon, Google, or Microsoft’s application catalog. Those applications give me a competitive advantage, and in updating them I increase that competitive advantage so I can provide new features, new capability. I want to take that on-platform application. I want to bring to it things like automated testing. Make it part of a CD pipeline. Give my developers a great set of tools and give them a great culture of development to help them help the firm be successful.

    That is the best approach to modernization I know of, and of course I work very hard to provide those things, including program understanding, so that developers can really get into code that they may not be familiar with, because when I talked about a younger mainframe workforce, that’s a good thing, but it also means that I don’t have people who have apprenticed with an application for ten years before being allowed to do important changes.

    You have people who are new to your firm, and they’re being tasked to do important work. So they need to be able to understand an application that may be older than they are quickly enough to inside a two-week agile sprint make a change, test it. Hopefully there’s already automated test present, but if there is not, they want to write some new automated tests and deliver that all as working, demonstrable code at the end of that sprint because that’s the way the world works today. So if you do that, you’re blazing down the road towards application modernization. It’s easy to talk about, but it boils down to just hard work.

    Ashley: Alan, I think to build on what we’ve said here, I look at it as three elements to the strategy here, and this is just also sharing my own personal experience with doing this. First is the people and the culture and getting our heads around new processes and new ways or additional ways of doing things. That’s what DevOps is about.

    Second is processes and tools, which Sam was just eloquently talking about. I think the third obstacle to app modernization is tackling the monolith because a lot of our applications were built differently, that we’re looking at how do we modernize. Well, why do you want to modernize? Sometimes it’s because we have to figure out a way to get in there and better maintain it ’cause it’s just too scary to tackle. The people that built it aren’t there anymore.

    Another reason, though, and I think the way to tackle that monolith part of it, is looking at our applications and saying what functionality and what business capabilities in the apps are most important to having the most flexibility or improving the speed at which we can improve that software to respond to and support the business?

    If we’re living in a world of changing how we’re delivering services into contactless, we’re living in a world where supply chains are going from inventory to on-demand, whatever it may be, examine those applications. Pick out where those elements are. And those are good candidates for going and saying, “Let’s carve out that piece and look at some new or alternative designs for how we can more easily maintain or more quickly develop capabilities in that part of the software.”

    It doesn’t mean you move it off the mainframe. It may stay there. It may be a combination of things. But that’s also part of app modernization is how we create software and the tools that we do it and sometimes how do we take on really big problems but divide ’em into much smaller pieces that we can do something about.

    Radcliffe: The application modernization of a Z application does unfortunately involve understanding it. And so having those tools for application understanding is the first key, but then actually understanding the business is the other key. And so it’s a combination of application modernization tools and understanding the business domains you’re trying to go after, really thinking about what are the focus areas and understanding what you need to run.

    Lots of discussion about microservices, and I always question, “Do you really want a microservice, or do you want a service? What level is the right componentization for this function?” And I always use a banking example because this one’s the easiest. “I need my credit card swipe to happen, and I only have a certain number of nanoseconds, whatever it is, to make that happen.”

    I’m not gonna make that a thousand microservices. I’m gonna make it a service. That service has to run fast. It has to be efficient. So it needs to be written as not a monolith, but a service itself. Where is that service? Is it bundled in the middle of something else that’s doing a whole bunch of other function? Can I strip it out? I need to look at the applications. And so using application understanding and the skills we still have today, because in many companies they actually still have a few people left that wrote those apps, not maybe for much longer, but they have ’em now. Let’s start to look.

    Use application understanding, the next generation, and learn from each other. I think the next generation, the newer developers, have a lot of skills in a lot of the new tools, and the people my age have the experience in the apps. So let’s bring these people together to help build this new culture, to help bring this together. Let’s take advantage of both sides and the tooling because even if they helped write the application, they still don’t know the whole thing anymore. It’s a monolith.

    Bring it together, and take advantage of these people. Use the people, both sides of the people, and bring all those skills together with the tooling to actually help you understand the business domains, the functions that you want to do, and split up that monolith. Maybe you’re splitting it up into a bunch of COBOL programs. It doesn’t matter. You’re providing the business value that you need to in a more maintainable, manageable way.

    Shimel: Fair. Guys, we’re running closer to the edge on time. I wanted to touch on the issue, though, ’cause it’s what Gerta does a lot of, and that’s around testing, right? As we’re modernizing these mainframe applications, we’re keeping them on the mainframe. Maybe we’re hybridizing them, if that’s a word, putting front end here and backend there or whatever. We’re modernizing the applications.

    Testing is an important part of it, as it is always. Anything special in particular that we’re doing around the testing of the modernization of mainframe applications that perhaps is different than – Gerta, go ahead.

    Sheganaku: When you think about testing, really just the whole topic of app modernization and also testing can be split into so many different bits and pieces. The one bit is really the architecture that we’re speaking about, where is everything hosted.

    Are we dealing with a monolith versus are we splitting everything up into service-oriented architectures or microservices or whatever we want to call those things, really making sure that we shift testing more to the left, that we make sure that the components are tested and such.

    Then the other side is really around the infrastructure, so really thinking about do you have those physical servers or do you have now more VMs, cloud-based environments? Do you have containers and so on where you’re hosting your _____ [break in audio] making sure that the intersections are tested properly?

    And then another point that’s also very important is really also the process side of things, so the delivery side. Are you having more of a waterfall environment or are you going more towards an agile DevOps environment? And all those things also go hand-in-hand.

    The typical approach would be especially you would have some more legacy type of applications that are running in the background that are really the backbone of your business, and then you would have more flexible applications built on top of that. For each of those you need different testing approaches.

    Something that we saw here, especially when we say “shift testing to the left,” was that while it was so far really possible to shift testing to the left when it comes to doing unit testing, doing API testing, and so on, it was always very hard when it came to end-to-end testing, especially across systems, when you have different systems, older systems, newer systems all working together, because there you really didn’t have that concept of just defining your tests up front and once everything is ready you just run your tests. It was really very difficult.

    Especially now I am focusing on the space of UI testing currently. In the UI space it was basically impossible to do that. That is also something where AI approaches can help in the future because if you look at the applications that we’re interacting with, no matter what technology is used in the background, no matter what type of programming language we’re using, if we’re having something in the cloud or on a server, it doesn’t really matter. How we interact with the applications as humans hasn’t really changed so much over time.

    When we looked at banking systems from 20 years ago and made an analysis, they look just the same like today. The applications that we work with on a day-to-day basis, although they move from one platform to the other, the technology keeps changing, bits and pieces keep changing, the way we interact with it really doesn’t change so much. So there it really helps to bring in AI-based approaches that help you take that human perspective when performing those tests to really be platform-independent.

    Shimel: Excellent. Sam, Mitchell, Rosalind, any thoughts on testing and app modernization with the mainframe?

    Ashley: I would just jump in and say it’s a great place to start, not to say you’re starting from scratch, but maybe you are, that whole CI/CD testing. As Gerta was saying, you can use cross-platform approaches, right? It doesn’t have to be one set of tools for this, one set of tools for that, et cetera.

    It can be, but there are some advantages to leveraging that knowledge base that Rosalind was talking about. You’ve been doing testing. Now how can you take that to the next level, whether it’s getting quality up or speeding up how quickly you can do releases, whatever the driver might be? As Gerta talked about, those are some fantastic approaches to take.

    Shimel: Rosalind?

    Radcliffe: Yeah, testing is one of the ways that we see people getting value fast, and it in some ways takes less cultural change. It’s easier maybe to get them to do automated testing, and automated testing is actually what makes you faster. You need that ability to test the system.

    Shifting left using virtual services, shifting left by virtualizing the whole system, allowing you to test your application in the build process, and doing unit test really does help in the mainframe space to get that feedback. It helps in every space, actually. But in the mainframe space, we seem to have forgotten this. I don’t know why. When I started, we did it. Okay, 20 years later people forgot. Getting to that unit testing, that automated unit testing, and making sure we’re doing that virtual testing, whatever it is to get that application transaction and really have that capability, and there’s lots of tools out there to do the testing.

    And the other part is it has to be cross-platform ’cause most Z applications are not Z-only. So open source tools like the Galasa framework that help you test across distributed and Z matter. Things like test data as a service matter. Use optimizations, looking at AI for data and understanding what data should you feed this.

    Multiple people have capabilities around that to look at the right data to test to make sure you get that fast feedback all the way at the beginning and get that developer that input so they aren’t waiting that six months of testing, that late-stage testing that is the reason why everybody says the mainframe is so slow because they spend too much time at the end testing. Let’s shift that all and bring it to the beginning, and then there are people delivering weekly into production because they have automated testing in place.

    Shimel: Absolutely. Sam, I’m gonna give you the last word, and then I’ve gotta wrap it up.

    Knutson: I think automated testing, and you have to underscore “automated,” is critically important. It’s one part of this. It’s not about the old, “Fast, cheap, good: Pick two.” People need to continuously improve quality, velocity, and efficiency on the platform, and automated testing is a key part of that. You will get measurable results, and you have to measure the results. So you have to put automated tests in place, you have to put quality aids in place, and then you have to measure that.

    If there’s one thing that we probably didn’t spend time today on that I think is a worthy thought for people to put front and center, it’s you’ve gotta measure from the very beginning what you’re doing, because any effort like this is going to entail some amount of spend in terms of resources. It is a worthy spend. It is the natural evolution of development for the platform.

    But you have to treat your developers like the high-performance athletes that they are. You have to give them continuous feedback. So use an analytics platform where you can understand what’s going on with your development process, what’s going on with your testing, so that you can see the results.

    When I looked in-house, what we were able to see is that as we evolved our development approach from waterfall to agile and we put these automated tests in place and we gave our developers a great developer experience, continually improving their tooling and our toolchain, we were able to get measurable results, like 25% more trapped defects that were caught before they ever escaped into customer hands.

    We were able to get twice as much code from individual developers and deliver at the speed of business. We didn’t get those results if we didn’t make the changes, including automated testing, including a great developer experience.

    None of it is optional. You don’t get a hall pass on any of this. Pick one and start, but you really have to think – this is a journey, and you’re gonna have to address all of these if you’re gonna get the outcomes that you want and be the most competitive that you want.

    I’ve seen customers getting amazing results that are measurable by outside firms where they’ve done studies and been able to see more than 467% ROI from implementing automated testing and building net-new applications on the mainframe. So this works. I’ve seen the proof points. I’ve seen the customer case studies. I would just urge people who have been sitting on the sidelines to get in because the competition absolutely is modernizing the way they build applications on the mainframe.

    Shimel: That was a strong finish, Sam. Thank you very much. Good stuff. Hey, Sam Knutson, VP of product at Compuware, a BMC company. Rosalind Radcliffe, Distinguished Engineer, IBM Enterprise Systems. Gerta Sheganaku from Tricentis on product for AI testing. And of course the one and only Mitch Ashley.

    This is Alan Shimel. Many thanks to Tricentis, by the way, for sponsoring DevOps Unbound today. This is Alan Shimel. We’ll be back in about another two weeks with another great DevOps Unbound. Stay tuned, but for now that’s it. Take care. Bye-bye.