devopsy.kinsta.cloud

Category: Features

  • DevOps Chat: OPA and the CNCF, With Torin Sandall

    DevOps Chat: OPA and the CNCF, With Torin Sandall

    The Open Policy Agent (OPA) was accepted for incubation by the Cloud Native Computing Foundation. In this DevOps Chat we spoke with one of the founders of the project, Torin Sandall, about OPA and why the CNCF is the right place for OPA. We also discuss the company he works for, Styra, which works with OPA.

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


    Transcript

    Alan Shimel: Hey, everyone. This is Alan Shimel, MediaOps, the people behind DevOps.com, Container Journal, Security Boulevard and DevOps Chat, and you’re listening to another DevOps Chat.

    I’m really happy to have as a guest for this DevOps Chat, Torin Sandall, and Torin is actually one of the co-founders of the Open Policy Agent (OPA) open source project, which recently came under the guidance management of Cloud Native Computing.

    So, let’s welcome Torin. Torin, you there?

    Torin Sandall: Hey, Alan. Yeah, great to talk to you.

    Shimel: Great to have you here, and a pleasure to have you joining us on this podcast. Torin, let’s first start off with, maybe there are people out here who don’t know what OPA is—what Open Policy Agent is, right? There’s some great, if you go to—actually, if you go to CNCF.io, there’s a blog article all about it and I’ll put it in our show notes. But for those who are following along or listening to this in their car or what have you, talk to us—what’s Open Policy Agent?

    Sandall: Yeah, that’s a great question, and it’s a good way to get started.

    So, Open Policy Agent is a domain agnostic policy engine, okay? So, it’s general purpose, meaning that you can kind of take it and use it to enforce all kinds of policies and governance regimes across a wide range of technology.

    So, for example, if you want to say that, you know, all of your containers have to be sourced from an internal image registry, you can express that kind of a policy with OPA, or the Open Policy Agent. If you want to do something like say that certain users can only see certain pieces of data served by a micro service, you can also do that with the Open Policy Agent. And if you want to restrict who can SSH into a server or run a pseudo command on a server, you can also do that with the Open Policy Agent.

    So, the idea is that we give people this engine that allows them to unify policy control across various pieces of their stack.

    Shimel: Excellent. And you know what’s interesting? I was talking to someone the other day and we were talking about, you know, how does Kubernetes fit into this whole Cloud Native thing? Because Cloud Native and the CNCF is bigger than just Kubernetes. And they gave me a really good analogy. They said, “Think of it as like, you know, a fleet of warships or, you know, a U.S. Navy fleet and maybe Kubernetes is the aircraft carrier. But there’s more to the Navy than the aircraft carrier. There’s more to a fleet than an aircraft carrier. There’s battleships and cruisers and destroyers and subs and frigates and amphibious landing ships,” and you know, I’m not a Navy expert. [Laughter] But there’s all these different elements that make up the fleet—and it’s a huge fleet.

    And so, you know, when I look at OPA, you know, Open Policy Agent—and we’re gonna talk about joining Cloud Native Computing Foundation—it’s a necessary ship in the fleet, right? That really makes it easier and more practical to use a lot of the tools that are not only in the fleet, but a lot of the commercial tools that kind of exist on the periphery as well. Fair?

    Sandall: Absolutely, yeah. The CNCF is a collection of projects that provide a lot of value within the overall ecosystem, and there are a few things that kind of bind them together, and those are kind of high level principles. So, you know, they’re all open source, they are all, you know, they’re oriented around containers. They’re oriented around very dynamic systems that you need to manage at scale.

    And so, one of the interesting things about a lot of the projects within the CNCF is that they are kind of building blocks. You can think of them as libraries or building blocks for the overall system, right? And so, you know, they integrate together, you can plug them into other systems and so on. And so, that’s how we kind of look at OPA. That’s how we think about OPA, is as a building block or as a library for enabling rich, fine grain control across a variety of parts of your environment.

    Shimel: Absolutely.

    Sandall: And, yeah, and so, policy is particularly important when you start to talk about adoption of technology within large organizations, right? As Kubernetes has matured and enterprises have really started to run with it and deploy real production workloads on top of it, they’ve recognized the need for not just simple best practice kind of security measures, but much more sophisticated and rich and fine grained rules and constraints that need to be enforced in a system in order to keep everybody safe. And so, that’s where OPA fits into Kubernetes.

    Shimel: Yeah, absolutely. You know what? I realized, and I apologize, I really didn’t do a good job of letting you introduce yourself to our audience on top of [Cross talk].

    Sandall: [Laughter] That’s okay.

    Shimel: So, Torin, I apologize. In addition to you being one of the co-founders of the project, why don’t you share a little bit about what you do in your day job and the rest of your life?

    Sandall: For sure, yeah. So, I think what’s relevant here is that I’m the co-founder of the Open Policy Agent project. I’m also a software engineer at a startup called Styra. We’re the makers of the Open Policy Agent. We founded the project about three years ago—a little over three years ago, actually, and yeah, so we’re kind of like the stewards of the project today. That said, we’re starting to see a lot more people from the community kind of come in and start contributing to Open Policy Agent and related kind of projects in the ecosystem.

    So, that’s sort of what I do. My focus is kind of on Open Policy Agent, but I’m super interested in the overall Cloud Native ecosystem and security and policy and all that kinda stuff.

    Shimel: So, you know, and I should also mention—I did a terrible job laying this one out, Torin, I apologize. We should also mention that the big news coming out—I guess it was this week, or maybe late last week—was that OPA, Open Policy Agent, has now become or come under the auspices of Cloud Native Computing Foundation (CNCF).

    Sandall: That’s right, yeah. So, we actually, we joined the CNCF as a sandbox to your project last year, in 2018. OPA was added into the CNCF sandbox. So, the CNCF has multiple tiers, and right now there’s sandbox, incubation and graduated.

    And so, this year, basically, they do a review of projects, you know, every year, and they check in on how the projects are doing and how they’re growing and how their communities are evolving. And that’s just useful, right? To kind of maintain, kind of, you know, good hygiene within the ecosystem. But this time around, we felt that—everybody kinda felt that OPA was growing quite a bit and it kind of deserved to move up to the next level incubation within the CNCF.

    And so, the move from sandbox to incubation is really a reflection of the progress that we’ve made over the last year in terms of both production users as well as proof of concepts and integrations, and new external contributors joining the project.

    Shimel: Got it. And, you know, I will just mention that, you know, CNCF has really done an amazing job of shepherding these projects, from sandbox into incubation, and then from incubation into graduation. I forgot the number, if it was five or six projects they’ve graduated now.

    Sandall: Yeah, I think there’s about five graduated projects today. You know, Kubernetes is one of them, it’s kind of one of the flagship projects, and there are others. And so, yeah, so, they’re really doing a good job of curating a very important set of building blocks, like I said, that are gonna help organizations get to cloud native.

    Shimel: So, let me ask you a question—and I think this is something our audience would really enjoy. How did you, as a co-founder of the OPA project, right, what was your sort of motivation for, you know, bringing it under the CNCF?

    Sandall: So, yeah, that’s a great question. What we found was that after, you know, the project had been around for over a year, or rather over almost two years, I guess. And what we found with talking to users and potential users was that they wanted to see OPA as part of a kind of vendor neutral organization, right? So, Styra, the company that I work for, had kind of built OPA, and it’s been open source since day one, but people really like to see these kinds of projects, these kinds of core infrastructure components a little bit decoupled from, like say, any particular organization.

    Shimel: Mm-hmm.

    Sandall: And so—

    Shimel: Well, not decoupled from any particular organization. Decoupled from any one particular vendor.

    Sandall: One vendor—yeah, sorry. One vendor.

    Shimel: There’s not a single vendor.

    Sandall: Yes. And so, you know, we looked around and we looked at the CNCF and we really liked what they were doing and we figured that that was the right place for OPA to be.

    So, you know, the CNCF basically provides us with this kind of vendor-neutral home for the project, and it allows us to kinda create a rallying point around policy in the cloud native ecosystem. So, that was the main, high level motivation for joining CNCF.

    Shimel: Got it. And it makes perfect sense. I mean, I’ve gotta tell you, you know, I don’t know if you’re familiar, but recently, the CNCF launched—not the CNCF, excuse me—the Linux Foundation, right, which is kinda the parent of the CNCF, right?—

    Sandall: Right, yes. Yes.

    Shimel: —launched another foundation called the CD Foundation, Continuous Delivery.

    Sandall: Yes, yes.

    Shimel: And CloudBees, the folks at CloudBees and the Jenkins project was given under to the CD Foundation. Jenkins had Jenkins X, Netflix put in Spinnaker and Google put in—I forget its name now, with a T.

    Sandall: Tekton?

    Shimel: Tekton. They put, you know, put Tekton into the thing. And I had a good chance to interview some of the CloudBees folks with this, and I asked them the same kinda question I just asked you. You know, and it was a very similar answer, that not only do end users perhaps shy away from a single vendor supported project, but it’s very hard for a project to break out of that mold and get other vendors or talent at other vendors to contribute, because they think they’re doing it for the benefit of one of their competitors.

    So, by putting it under a neutral party like this, you know, not only is it more palatable to your end users and to the community as a whole, but it’s especially more attractive to that segment of the community that are made up of vendors. And whether you hate vendors and you think they’re all commercial slime who sold out to the man or not, the fact of the matter is, those are the people who have the resources to put into these projects and to move the needle and to keep that ball moving forward and push the rope up the hill and all of that. So, can’t live with ‘em, can’t live without ‘em, and this is a great kinda middle ground.

    Sandall: That’s a good point, and I think that, you know, what we’re starting to see are more and more security vendors getting interested in OPA or Open Policy Agent. I like to call it OPA. It’s hard to call it O-P-A when you’ve got that OPA word that you can use, but anyway—

    Shimel: Yeah, yeah, yeah. [Laughter]

    Sandall: [Laughter] But yeah, so, we’re seeing more and more security vendors get interested in OPA and, you know, that is gonna be instrumental in the long run to achieving the goal of unifying policy control across a number of different systems, right? There’s never gonna be one vendor that rules everything and there’s always gonna be an amalgamation of different technologies. And so, you know, the best that we can do, I think, is provide this building block that can be embedded all over the place and that has, like, the fundamental kind of groundwork that enables unification. So, very exciting times.

    Shimel: Absolutely. So, I’m gonna ask you now to put on your entrepreneur’s hat, right? As a co-founder of your company as well, and let’s look at it Torin from that point of view. How is this helping—and I’m not familiar with your company, so I’m gonna apologize in advance. Say the name for us, again?

    Sandall: Sorry, the name of the company is Styra.

    Shimel: How do you spell that?

    Sandall: S-T-Y-R-A.

    Shimel: Got it. So, how does this help Styra?

    Sandall: That’s a great question. So, yeah, when the founders—I’m not a founder of Styra, I’m an employee at Styra.

    Shimel: Oh, I’m sorry. Okay.

    Sandall: But anyway, when the founders of Styra started the company, one of the things that they observed was that, in order to unify enforcement of policies across a wide range of technology, there would need to be kind of like a language based approach applied to the problem domain.

    And so, that’s one of the things that the Open Policy Agent provides—it gives people this high level declarative language that they can use to codify policies. And so, that was kind of recognized as something that would be needed, and what you quickly kind of—the conclusion you quickly arrive to is that, this was in 2016, 2015, and even more so today, it’s true, but what you quickly arrive at is the realization that that kind of a technology needs to be open source, right? It’s unlikely that organizations are going to want to adopt a proprietary, closed source language. It’s just not going to happen.

    And so, right from the very beginning of the company, it was recognized that an important part of the technology was going to be open source. And so, that’s how the kind of project sort of got started.

    Shimel: Got it. Got it, got it, got it. You know, I don’t wanna put you on the spot, but a little Styra background—Styra’s venture backed or bootstrapped, or?

    Sandall: Yeah, we’re venture-backed, and we recently did a bit of a launch at the RSA Conference a few weeks ago.

    Shimel: Really?

    Sandall: And so, that was very exciting, yeah. And so, you know, you can think of Styra as a control plane for policies. So, OPA kind of acts as the data plane, right? It’s this thing that you can embed into applications, you can embed it into Kubernetes, you can put it all over the place. But, what you need is also the ability to kind of manage those OPAs that are running all over the place.

    And this is what we see within the OPA community—the people that are using OPA building it into their systems. Companies like Netflix that have built an internal security platform around OPA, what they’ve ended up doing is creating a centralized management plane for policy and for security.

    And so, that’s what we’re doing at Styra is, we’re helping people kind of think about distributed enforcement of policy and centralized management of policy.

    Shimel: Got it.

    Sandall: So, we’re focusing today on Kubernetes and you can check out the website, we’ve got a bunch of information on there, but yeah, that’s the high level.

    Shimel: Excellent stuff. As a matter of fact, just looking at the website, I didn’t realize this but Styra is Bill Mann’s company.

    Sandall: That’s correct, yeah, he’s the CEO.

    Shimel: So—just to show you how old I am. I’ve known Bill Mann a really, really long time, like, I remember the day he joined CA.

    Sandall: Bill knows a lot of folks, yeah. [Laughter]

    Shimel: Yeah, he gets around. Bill’s been around, and so have I.

    Sandall: Yeah.

    Shimel: I don’t know if that’s a good or a bad thing, you know? But hey, we’re still kickin’. So, tell Bill I said hello, he’ll get a chuckle out of it.

    Sandall: Yeah. I will do that, yeah. And we’ve got a great founding team. They are some of the folks that did Nicira, which is one of the very, you know, basically, the first SDN kind of company, right? They [Cross talk]—

    Shimel: Yep, I remember that one as well.

    Sandall: Yeah. So, we’ve got a deep background within the security and policy space, and we’re kinda taking that and really bringing it into the cloud native ecosystem.

    Shimel: Very cool. You know, I don’t wanna make this about Styra because we really wanted to concentrate on OPA and CNCF, but maybe we’ll still, maybe we’ll schedule something, a second one, and we’ll talk—we’ll dive more into Styra.

    Sandall: Yeah, that would be great.

    Shimel: You guys are gonna be at KubeCon in Madrid—or I mean, in Barcelona?

    Sandall: We are gonna be in KubeCon, yes, in Barcelona in May. There are going to be a bunch of talks about Open Policy Agent. There’s gonna be, I think there’s at least three or four sessions that are happening. There’s also a little thing called Cloud Native Rejects the weekend before. [Laughter] These are the talks—like, the BSides Talks, basically for—

    Shimel: Yes. Well, that’s how Security BSides started.

    Sandall: Yeah, exactly. And so, there’s gonna be a session there with OPA content in it. So, yeah, it’s gonna be a great event.

    Shimel: Excellent.

    Sandall: And, of course, we’re gonna have a Styra booth at the event, so.

    Shimel: So, we will have a, you know, Digital Anarchist is our video platform, and we’ll have a Digital Anarchist set there where we’ll be doing videos. So, be sure—we’ll talk offline, but we’ll get you guys in for a video. We’ll follow up more on that.

    Sandall: Perfect! Yeah, looking forward to it.

    Shimel: So, is there a timeline for graduation from incubation at CNCF, or that’s kinda open?

    Sandall: It’s open. So, you know, they do a yearly review of the project, and it’s kind of up to, you know, the community and CNCF and everybody to kind of decide when that’s right. And so—yeah, so right now, one of the main criteria for graduation is around external contribution. And so, you know, over the next year, we’ll see how external contribution around OPA evolves and if it’s in the right place, then we’ll go ahead with that.

    But we’re really happy right now just with the move to incubation because it brings more visibility to the project, it lends more credibility to the project—you know, in addition to all the people that are using it in production, having it more prominently represented within the CNCF is great. So, we’re really happy with where we are today.

    Shimel: Fantastic, man. Hey, Torin, I had promised you we’ll do this in 15 minutes, and that was 25 minutes ago.

    Sandall: [Laughter]

    Shimel: So, I apologize for running over, but I thought we had a good conversation here.

    Sandall: Yeah, yeah. Thanks a lot, Alan. Yeah, I appreciate the time to talk about OPA and Styra and I look forward to—

    Shimel: Oh, it was really my pleasure. I’d like to—we’ll continue this at maybe KubeCon in May. But before we sign off—so, Styra is Styra.com, S-T-Y-R-A.com. The OPA project, right, is—

    Sandall: Yep.

    Shimel: —OpenPolicyAgent.org?

    Sandall: That’s correct, yep.

    Shimel: And, of course, you can find more information on it at the CNCF.io site, right?—

    Sandall: Absolutely, yeah, and it’s on GitHub and we also have a blog if you go to blog.OpenPolicyAgent.org, you can find out more there. So, yeah, check it out, and—yeah.

    Shimel: [Cross talk] It’s all good. Hey, Torin Sandall, co-founder of the OPA, Open Policy Agent project, which is now being incubated by Cloud Native Computing Foundation, as well as an employee at Styra—for my friend Bill Mann.

    Sandall: [Laughter]

    Shimel: So, good to have you on there. Say hello to Bill for me. Best of luck with OPA.

    Sandall: Will do.

    Shimel: And look forward to seeing you in May at KubeCon.

    Sandall: Looking forward to it. Talk to you later. Bye.

    Shimel: Alright Torin, thanks. Hey, this is Alan Shimel for DevOps.com, Container Journal and Security Boulevard. You’ve just listened to another DevOps Chat.

    — Alan Shimel

  • 7 Big Digital Transformation Trends

    7 Big Digital Transformation Trends

    As enterprises continue their rush to digitally transform their organizations, they’re investing big in retooling their software development pipelines, new artificial intelligence (AI) and robotic process automation (RPA) technologies and low-code development platforms, as well as putting considerable money into customer engagement software. Yet, the extent of success following these investments remains unclear and varies significantly from industry to industry.

    To shine a light on the digital transformation efforts currently underway, as well as the degree of their success, we’ve collected a number of fascinating trends in the most essential areas of digital transformation.

    Investment in AI, Machine Learning and RPA Technologies Hitting an Inflection Point

    According to the consultancy KMPG, enterprise investments in AI, machine learning, and RPA will rise to $232 billion by 2025 from $12.4 billion in 2018. “Nearly two-thirds of respondents indicate plans to fully implement RPA within three years. Another 18% plan selective use. As for cognitive automation, nearly half noted intentions to use these approaches at scale within 3 years, while 29% indicated selective reliance on cognitive automation capabilities. Some 10% said they would launch pilots and proof of concept projects,” according to the report.

    DevOps is Just Getting Started

    While we’ve been writing about the enterprise move to DevOps for years now, the investment in DevOps is just setting itself up to truly soar. According to the market research firm Market and Markets, the DevOps market will grow 24.7% annually, to $10.3 billion by 2023 from $2.9 billion in 2017. “The demand for DevOps solutions and services among enterprises is expected to gain huge traction, due to the increasing need for fast application delivery with high quality,” the firm said.

    Digital Transformation Spending to Top $1 Trillion This Year

    In research firm IDC’s “Worldwide Semiannual Digital Transformation Spending Guide,” global digital transformation spending will reach $1.18 trillion this year, rising nearing 18% from 2018. “Worldwide DX technology investments are expected to total more than $6 trillion over the next four years,” said Eileen Smith, program vice president with IDC’s Customer Insights and Analysis group.

    For 2019, the two industries expected to invest the most into digital transformation are discrete manufacturing and process manufacturing, which will invest roughly $222 billion and $124 billion, respectively. According to IDC, the top digital transformation spending will be in smart manufacturing, which will be supported by autonomic operations, manufacturing operations and quality. The retail, transportation and professional services industries will follow closely behind.

    IT and Business Leadership Chasm Widen

    According to research firm consultancy Capgemini, there appears to be a growing disconnect between the CIO and senior business executives. Capgemini’s research found that while in 2012, 65% of organizations believed that the CIO and senior business executives possessed a shared understanding of the role of IT in their organization. In their most recent survey, that figure dropped to 37%. Additionally, Capgemini found, 59% of enterprise respondents in 2012 believed that the CIO and senior business executives had a shared understanding of how IT could be used to increase organizational productivity. That figure also declined precipitously, hitting 35% in 2018.

    Low-Code Development Continues to Gain Higher Ground

    The demand for enterprise software seems to have no bottom. And no matter how hard they try, developers can’t code software quickly enough. This is why more enterprise software needs are being met by low-code development platforms.

    According to research from ResearchandMarkets.com, the global low-code development platform market will grow to about $27 billion by 2022, up from $4 billion in 2017 and at an annual compound growth rate of 44%.

    Digital Transformation, Customer Engagement Software Grow

    Digital transformations don’t mean much if they don’t reap increased revenue, land new customers and improve relationships with existing customers. And how enterprises engage with their customers is one of the most rapidly evolving aspects of enterprise technology today, from AI and machine learning to IoT devices and ubiquitous adoption of mobile devices. Customer engagement software ranges from staid CRM systems to customer self-service software. This class of software was a nearly $13 billion market in 2017, but will likely reach $22 billion by 2023, an annual growth rate just shy of 10%, according to market research firm Mordor Intelligence.

    Digital Transformation Success Grows Harder to Come By

    The success rate for digital transformation efforts is persistently, and dismally, low. According to research from McKinsey and Company, over time fewer than 30% of digital transformations succeed.

    And that failure rate appears to be growing worse, not better. McKinsey’s 2018 survey results show only 16% of enterprises believe their digital transformations will improve organizational performance over the long term. “Even digitally savvy industries, such as high tech, media and telecom, are struggling. Among these industries, the success rate does not exceed 26%. But in more traditional industries, such as oil and gas, automotive, infrastructure and pharmaceuticals, digital transformations are even more challenging: success rates fall between 4% and 11%,” McKinsey found.

    While enterprises are clearly investing into their digital transformation efforts and the desire to succeed is high, the high digital transformation failure rate says enterprises either aren’t taking the right approach to these efforts or they are not executing properly.

    Whatever the reasons for the high rate of failure, with the vast amount of business capital on the line and the increasing risks upstart businesses pose to those established in their markets, more enterprises better figure out soon how to get their transformation efforts right.

    — George V. Hulme

  • AIOps: Supporting Reliability at DevOps Speeds

    AIOps: Supporting Reliability at DevOps Speeds

    AIOps looms large as a way to help push the DevOps envelope. How can organizations prepare?

    As organizations journey down the path of DevOps maturation, sustainable IT operations and IT service management remains a challenge for many. Even advanced organizations that have managed to speed up deployment rates and improve software quality struggle to maintain the resilience of the infrastructure that supports those applications. To support DevOps speeds, a growing number of organizations are turning to AIOps—the use of artificial intelligence (AI) and machine learning in IT ops—to speed up analysis of IT problems and better automate incident handling.

    A new study out this week from OpsRamp shows that ops pros are able to reduce mean-time-to-resolution of incidents by as much as 50% through the use of AIOps. The use of AIOps is still infrequent, but analysts say its prevalence will grow quickly. Gartner says about 5% of organizations were using AIOps tools last year, but that by 2023 the deployment rate will shoot up to 23%.

    But as DevOps teams lean on AIOps tools, management will need to harness a new set of skills to get the most out of the types of operational automation AIOps will afford. In the coming years, experts believe AIOps will change the complexion of the IT ops workforce. Fewer people will be needed in the network operations center (NOC) to manually sift through alerts and respond immediately to incidents. More people will be needed to curate data, scrub it and train the algorithms that will do the heavy lifting of event correlation and determining the root cause of problems.

    As organizations and individuals plan out how they’re going to future-proof themselves for the changes in IT ops wrought by AIOps, experts say they should increasingly see the need for the following three roles in IT organizations.

    AIOps Architects

    Expect to see more job postings in the near future looking for AIOps architects and automation path designers, said Will Cappelli, CTO of Moogsoft and the former Gartner analyst who’s known for coining the term AIOps.

    “(AIOps architect is) essentially a software development job involving the construction of meta-algorithms that guide the flow of control of the AIOps systems,” Cappelli said.

    Potentially falling in this umbrella could be roles such as machine learning and AI designers that focus on designing the algorithms themselves, and interaction designers that focus on designing the automated workflows. According to Brendan Caulfield, co-founder of ServerCentral Turing Group, these roles already exist in other business capacities. With AIOps, these design jobs will start to be applied specifically to IT operations as well.

    To prepare, veteran IT ops experts should start thinking about how they can bolster their skills, and management need to recruit and train accordingly.

    “Mathematics and an end-to-end understanding of how modern IT systems behave will be critical,” Cappelli said.

    ITOps Data Scientists

    AI depends upon good, clean data and sound modeling to work effectively.

    “The most sophisticated and expensive AI tools are useless if a company isn’t able to feed them with a high volume of high-quality data, in a format the system can digest,” said Rajesh Kalidindi, CEO of Leva Data.

    This was corroborated by the OpsRamp report released this week that showed maintaining data accuracy is the No. 1 challenge cited by organizations deploying AIOps today. Many organizations will need ITOps specific data scientists to attend to this problem.

    “Building high-volume, high-quality data sets will be increasingly important, and it requires a lot of human effort,” Kalidindi said. “AI has a long way to go before catching up with human reasoning (let alone surpassing it), and it can’t make any progress without people developing data models for AI to work with.”

    Augmented Intelligence Analysts

    According to Caulfield, algorithm training and support by domain experts in operations will become increasingly important at most organizations.

    “No matter how ‘smart’ an algorithm is, or how well its designed, there will be exceptions that are unique to a business that will need oversight and tuning,” he said.

    Kalidindi concurred that human intervention will be needed for a long time to augment and validate the insights and actions driven by AIOps, noting that this will lead to the rise of a new role for ops analysts.

    “Especially in the early days of machine learning, humans are needed to judge whether an algorithm is leading to the right judgment,” he said. “For example, if we were to apply AI to analyzing the problems the IT Help Desk encounters, a human would be needed to judge whether the algorithm made an appropriate recommendation. If not, IT and data science needs to work with the human’s recommendation to better train the AI model on how to handle that problem in the future.”

    One thing that most experts agree about is that the rise of AIOps will not diminish the need for IT pros. In fact, they say that domain expertise will be more important than ever. However, it will need to be bolstered by additional knowledge of data science, how AI works, and systems architecture.

    “They need to retool themselves from admin-oriented activities to scripting/reporting-oriented tasks, and they need to be more application aware than ever before as infrastructure becomes a commodity,” said Ravi Raghavenderrao, vice president of service delivery at NetEnrich, of IT ops professionals in an AI-enabled future.

    To those who have adjusted to DevOps transformations, this should all sound very familiar.

    — Ericka Chickowski

  • Digital Transformation: Digitally Resilient Organizations

    Digital Transformation: Digitally Resilient Organizations

    While some are growing weary of the term “digital transformation,” the reality is, it’s here to stay. Digital transformation isn’t just a buzzword or a transient phenomenon. Enterprises are digitizing themselves as rapidly as they can and automating what can be automated, improving customer experiences, leveraging data for machine learning and improving customer experiences.

    These levels of transformation are underway across vertical industries—manufacturing, retail, transportation, health care, telecommunications and government. Research firm IDC, expects worldwide spending on digital transformation products and services to reach $1.8 trillion in 2019, a rise of 18% from 2018. IDC expects that figure to rise to more than $6 trillion over the next four years.

    “Strong DX technology investment growth is forecast across all sectors, ranging between 15% and 20%, with the financial sector forecast to be the fastest with a compound annual growth rate (CAGR) of 20.4% between 2017 and 2022,” said Eileen Smith, program vice president with IDC’s Customer Insights and Analysis group.

    The two industries that will invest the most, according to IDC, are expected to be discrete manufacturing, at $222 billion, and process manufacturing, at $125 billion. IDC said the top priority is smart manufacturing, supported by significant investments in autonomic operations, manufacturing operations and quality. Retail will follow closely behind, which in turn will be followed closely by transportation and professional services.

    As hard as it may be to believe, the four pillars of transformation—DevOps, cloud, AI and IoT—are still in the nascent stage of deployment. The most popular digital transformation use cases this year, according to IDC, will be freight management ($60 billion), autonomic operations ($54 billion), robotic manufacturing ($46 billion) and intelligent and predictive grid management for electricity, gas and water ($45 billion). Additional use cases that will see investments higher than $20 billion in 2019 include root cause, self-healing assets and automated maintenance, and quality and compliance.

    Those organizations that excel in their digital transformation efforts will find that they’ll reap tremendous benefits. However, excellence here isn’t about short-term wins or one-off projects. Excellence in digital transformations is about properly tooling the enterprise for digitization so that the organization is as productive as it can be, cost-efficient and technically agile enough to seize new business opportunities as they arise and successfully endure or even thrive through market, geopolitical or other adversity. It’s about building an iterative, generative, agile digital platform that positions the business for long-term success. This is digital resiliency.

    Most enterprises aren’t close; according to the 2018 Global CIO Survey from Deloitte, about 70% of the 1,400 executives they surveyed don’t even have a digital enterprise strategy.

    The digitally resilient enterprise has built a business-technology platform that is elastic and agile and can position itself correctly depending on current business demands; it’s reasonably secure from cyberattacks that threaten data. The digitally resilient organization is also continually learning from its data and making adjustments as markets, its workforce and its customers demand. The digitally resilient organization has eliminated the bulk of its technical debt, and it innovates, so competitors don’t disrupt it with a better idea, execution and understanding for what customers want.

    In the weeks and months ahead, I’ll be sharing more stories, case studies and insights on how organizations can build the digitally resilient organization that positions them for success over the long term.

    — George V. Hulme

  • Mainframes: The Cloud Before the Cloud

    Mainframes: The Cloud Before the Cloud

    Here’s something to think about: Despite the fact that IBM stopped manufacturing personal computers in 2005, deciding instead to focus on higher margin business services, the company continues to produce mainframes and by all estimates will continue manufacturing them well into the future. The question is, why? The answer: because there is still significant demand for this type of hardware.

    The fact is that a mainframe is a monster when it comes to computation and processing transactions. One mainframe can process 2.5 billion transactions daily. That’s the equivalent of 100 Cyber Mondays in a single day. To give you a clearer idea of the immensity of scale, keep in mind that Cyber Monday sales in 2018 were $7.9 billion. This translates into a mainframe being able to handle a bit more than three-quarters of a trillion dollars in transactions each day, which is almost twice the yearly GDP of Austria!

    As I said, the mainframe is a workhorse. Yet, its power and potential are hidden from most people who work in the modern cloud. This is surprising because there’s a good argument to be made that, given its power and scalability, coupled with its support for a large number of concurrent users, the mainframe was the cloud before there ever was a cloud. However, the technology is practically unknown among younger developers, mostly due to cultural reasons and a lack of historical awareness. That more people are not taking advantage of the tremendous opportunities at hand is a misfortune. When it comes to mainframe computing, there’s a lot of interesting tech to be learned and a good amount of money to be made. It’s just a matter of increasing awareness to do this. A good place to start is to redefine the narrative.

    Allow me to elaborate.

    A Special Club

    When mainframes appeared on the commercial landscape, few people interacted with computers and even fewer worked with them directly as programmers or system administrators. Just as in a modern data center, the machines were isolated in climate-controlled rooms to which few had access. Access to the actual physical machine was restricted to a special few. But unlike today, when restricted access is due more to security concerns because there are a lot more people around who are potential black hats, back then access was also restricted due to the exclusivity of the profession.

    In the 1950s, 1960s and well into the 1970s, not just anybody could program or be a systems administrator. You could go to a technical school to learn to become a computer operator, which meant you could work at a terminal as a bank teller or travel agent. Or you could learn to become a data processing clerk and work in a back office at a brokerage firm. But to learn to program, you had to go to college. Then after college, you had to go to work for a company or organization that actually used computers in day-to-day operations. These were banks, insurance companies, major manufacturers such as General Motors and General Electric, airlines, very large retailers and government. Computing was a club and you had to be well-educated to get in and be well-liked by the organization to keep your membership. Yes, there were the outliers—Gates, Allen, Joy, Wozniak and Jobs—but for most people, the career path to being a programmer was college and then into big business or government.

    As a result, computing had an air of mystery and magic to it. Remember, until the mid-1980s, most people had never touched a computer. It was the stuff of moon landings and election night predictions on network TV. Then the PC came along and changed everything. Within 10 years computers became commonplace. Even elementary schools had them—at least, those that had the budget and foresight. The power that business applications such as the spreadsheet program Lotus 1-2-3 brought to small business motivated even the dry cleaner on Main Street to plunk down the thousands of dollars it cost to buy a PC. The productivity boost was worth it. Also, since the dry cleaner actually owned the machine, the dry cleaner’s kid could learn to program on the box unencumbered, when it wasn’t being used during business hours. Remember, the Microsoft DOS operating system that shipped on every IBM-compatible PC came bundled with the programming language BASIC. You didn’t need to go to college to learn to program; all you needed was a book.

    So, PC programming took off. Instead of having to go through the effort required to get into the special club the mainframe programmers belonged to, PC programmers started their own clubs and anybody could get in. All you had to do was show up. PC programming became a meritocracy. Also, it became extremely lucrative work. There were a lot of PCs being shipped and the appetite for applications to run on them was enormous. The unlikeliest of people, such as Lotus Software founder Mitch Kapor and his sidekick, Grateful Dead lyricist John Perry Barlow, became wealthy, thanks to the PC.

    The PC became cool and programming for it became cooler. But there was a fact that got obscured as the popularity of the personal computer grew: Compared to the mainframe, the PC was a toy—a productive toy, a liberating toy, but a toy nonetheless, very much in the same way that a go-kart is a toy compared to a Formula One race car.

    Feature for feature, the mainframe ate the personal computer’s lunch. The IBM System/370 Extended Architecture Mainframe released in 1983 was a 31-bit machine that could support up to 8MB of memory with a processor running at 38 MHz. By comparison, the IBM PC-XT, also released in 1983, was an 8-bit machine that shipped with 128KB of RAM and an 8088 processor that ran at a speed of 4.77 MHz.

    But, as the saying goes, “You should never underestimate the value of cool,” and the PC was very cool. It got a lot of attention while the mainframe stayed hidden away in climate-controlled rooms in the basements of banks and insurance companies. Yet, the mainframe was more powerful, and whereas the PC was meant to meet the needs of a single user, a mainframe can service thousands.

    Built to Scale Built from Inception

    Mainframe computers from the start were designed to support hundreds (if not thousands) of users. However, more importantly, mainframes were and are designed to support millions of concurrent transactions. When you think about it, while it’s possible for a high number of user requests to exhaust CPU utilization in a typical commodity machine—which is the reasoning for being able to scale up CPU count by increasing VM allocation in the cloud-based computing cluster—the real burden on the CPU is not so much the request count but the computing burden that each request incurs. For example, one request getting a .JPG of a cat will incur nowhere as much burden as a request that needs to convert an audio file in .WAV format to MP3.

    The need to alleviate request burden has been around since bank tellers working in the various branches of a big bank had to make deposits and withdrawals at the same time. Mainframe engineers addressed the problem decades ago. Technologies such as batch processing and message queues, which make computational activity asynchronous and are optimized to fully utilize CPU capacity efficiently, were and are commonplace in the mainframe landscape.

    IBM’s 360 mainframes supported batch processing in its OS/360 system starting in 1964. Batch processing allows thousands of instructions to be performed on terabytes of data at pre-scheduled times (usually “off-hours”), all without human intervention.

    Message queuing allows processes to take data in the form of a message stored in a message queue and perform computational activity according to the data in the message. Processing is performed independent of a request in an asynchronous manner. When processing is complete, a new message is created and sent on to another queue, where another process will do more processing or create a notification indicating that work is complete. IBM MQSeries was an early message-queuing technology first used in 1993 at State Street Bank well before the internet became commonplace.

    The reason that support for user and transactional concurrency was possible in mainframes is due to a technology that is commonplace in today’s cloud environment but was unheard of among PC users back in the days when most data was exchanged between standalone PCs using floppy disks. That technology is virtualization.

    Virtualization Takes Mainframe Computing to the Next Level

    Today we take virtualization—the capability to have software simulate hardware—for granted. Without it, we couldn’t have native cloud providers such as Amazon Web Services, Google Cloud and Microsoft Azure. These services rely on virtualization to provide the segmentation and computational isolation required to meet the needs of the modern computing. Yet, as essential as virtualization is in the world of commodity cloud computing, putting a layer of virtual machines on a commodity PC is a fairly recent event in the history of computing. VMWare, VirtualBox and KVM became mainstream in the mid-2000s. On the other hand, virtualization has been part of mainframe technologies since the mid-1960s. Virtual memory appeared in the mainframe in 1965. Machine virtualization was introduced on the IBM 370 mainframe in 1972 and is still an important part of the mainframe computing experience today.

    Every single person who logs onto the mainframe when working in a native mainframe operating system gets an identical address space. You can think of each address space as a standalone virtual mainframe system. These address spaces are created instantly and are protected from interfering with each other. Also, many companies create logical partitions of their hardware called LPARs (logical partitions). The logical partitions are controlled by a native firmware hypervisor called PR/SM (pronounced Prism).

    The value that LPARS provide is a further separation between environments. This means not only can you separate users, but you can also create distinct computing environments such as those created when virtualizing X86 machines. For example, you can have a shared development environment as well as environments for testing, staging and production. You can allocate resources and security access to a particular environment based on need, just like you would in a data center full of commodity machines. This means you can configure production systems to be more secure and have higher execution priority and more resources such as memory. In fact, according to the U.S. government, from a security perspective, virtual machines created on the mainframe are considered distinctly separate machines.

    LPARs running on the same hardware or different hardware under the native mainframe z/OS operating system can be linked together as a Sysplex for redundancy and to easily provide additional capacity. Dynamic Virtual IP Addressing (DVIPA) is used to dynamically route IP traffic across multiple LPARs in a Sysplex. This is analogous to being able to tie together a variety of web servers behind a load balancer or organize them within a Kubernetes cluster. Being able to tie computers together is an important feature for making systems scalable. Also, linking computers across geographic regions increases performance. It’s always faster to work with a machine that’s closer to you than one that’s further away. As mentioned earlier, being able to scale systems up and down is a key feature of cloud-based computing. Dynamic connection, which is part of mainframe architecture, is critical for scaling to work.

    The important thing to understand is that the stuff we consider to be modern in terms of the machine virtualization that we rely upon to make the cloud work has been in play for years on the mainframe. Also, virtualization on the mainframe makes it possible for programmers and system administration staff to work in a variety of operating systems and programming languages as we’ve come to expect in commodity cloud instances. Machine virtualization allows mainframes to support Linux. Whether the computing environment is virtualized Linux or native mainframe, developers can code in Java, C/C++, Python, Perl and a variety of other languages, including something as new as Swift. But, then again, the mainframe was always intended to support many programming languages.

    Even back in the ’60s and ’70s, programmers could write in COBOL, PL/I, job control language (JCL) and Customer Information Control System (CICS). Also, writing low-level code in Assembler has always been possible. Clearly, the versatility that modern developers enjoy programming in a variety of languages in a cloud environment has been part of mainframe computing for a while. Yet, the benefit has never been at the forefront of developer awareness. Maybe it’s time to change the narrative.

    Changing the Narrative About Mainframe Computing in the Cloud

    As I stated at the beginning of this article, IBM continues to make mainframes because there’s a growing demand for the technology—particularly as smartphones and IoT devices proliferate worldwide. Netflix might be spinning up containers on a commodity machine in a data center to let you view past episodes of “Orange is The New Black.” But when it comes time to pay for your Lyft ride using your iPhone, that credit card transaction will most likely be processed on a mainframe that’s providing service via some sort of API gateway.

    There is little benefit to arguing that mainframes should or can be used interchangeably with commodity servers. That’s like saying a fleet of automobiles can be used interchangeably with a city bus. You can do it, but it doesn’t make much sense. Each technology has benefits that when used together, make the overall transportation system more efficient. The trick is to understand where and how the technologies fit together in the big picture. In this case, the big picture is the cloud.

    The old narrative around mainframe technology is based on perceptions that are no longer applicable. The modern mainframe is no more centralized than the single building that houses a regional data center. In terms of programming languages, mainframes moved beyond FORTRAN and COBOL decades ago. Current mainframe virtualization technology makes it possible to run programs written in just about any programming language. And, mainframe emulators, such as ZD&T, make it possible to get the hands-on experience necessary to get familiar working in a mainframe environment.

    The Perceptions of the Past are No Longer Applicable

    The modern mainframe is a powerful resource that provides extraordinary benefits for cloud computing. The new narrative is that the mainframe is modern, adaptable and well-suited to accommodate a very high volume of transactions at lightning-fast speeds. And, it’s a good way to make good money.

    As the current workforce (which is admittedly aging) approaches retirement, a new breed of mainframe developer will be needed to continue the work of making the mainframe a mission-critical resource in the modern cloud. In addition to understanding the essentials of mainframe computing, these developers will need to be well-versed with the modern tools and techniques that drive cloud computing. It’s an investment that I’ve urged many up-and-coming developers to make.

    Putting It All Together

    Let me share a piece of personal history: A while back I needed to do some programming. So, I went to my desk, logged into my system, wrote some code and ran it. It worked like a charm! I saved my work, finishing up just in time for dinner. A while later, it was again time to program. I went back to my desk, logged into the system and coded away. Just another day of slinging the code, right? Well, not really.

    My first coding session was in 1975. “A while later” is today. Forty-four years have passed. Back then, I was working on a mainframe that was 50 miles away. Today, I logged into an online programming environment that was also miles away, maybe even halfway around the world. That’s how it is with cloud computing: The resources are any way at any time.

    Interestingly, despite the passage of a significant amount of time, my current developer experience is not that different than the one I had decades ago. It’s still just me and a terminal. Back then, the terminal was a screen full of green characters. Today, my terminal is able to accommodate a variety of media and input devices. But, at the other end of the wire, who knows what’s going on? For all I know, I might still be connecting to the same mainframe I used back in 1975. Which is my point.

    Much of what we consider new and wonderful about cloud computing today has actually been around for a while in mainframe technology. In many ways, the mainframe was the cloud before the cloud. And, it’s still a powerful resource for what we have come to know as modern cloud computing. Given its power, versatility, scalability and support for modern DevOps tooling, the mainframe is a perfect resource for today’s and tomorrow’s cloud computing infrastructure. It’s a computing resource that we’ll do well to take advantage of as we move forward in our development efforts on an increasingly connected planet.

    — Bob Reselman

  • Keeping NoOps From Going Rogue

    Keeping NoOps From Going Rogue

    “We’re NoOps—everything is in the cloud and we have no infrastructure to manage.” Before running that victory lap and shifting everyone to the dev side, consider several NoOps risks carefully. I’m really thinking about teams using all-SaaS stacks, especially in martech, edtech and other areas. However, the rise in microservices and serverless means more teams are leaning toward NoOps. At least a few people on your team should always watch for rogue issues on the ops side of the equation.

    Locked-in Vendors

    Risk: Cloud-based tools in the same category rarely have the same functionality. Once one is selected, you’re committed to its specific features. Moving away from a tool may mean dropping a popular application feature or changing workflow with coding to recreate functionality.

    Mitigation: Evaluate unique features and customized data fields carefully before use. Solving data format differences is relatively easy for common fields. Look for tools with well-documented APIs and integrations or connector support for analytics. If there are no integrations out there, that’s a red flag.

    Ghosting

    Risk: Lock-in becomes a big problem if the vendor ghosts. SaaS startups often meet one of two fates: they are acquired or they crash and burn. A tool critical to your workflow may disappear overnight. In the acquisition scenario, you may have some time and support in migrating from your tool to its successor.

    Mitigation: Always have a Plan B for every cloud-based tool in your stack. Competitors are introducing new tools frequently. A trade study done two years ago may be completely obsolete on today’s fast-moving landscape. Proactive migration to newer solutions may reduce vendor risk and improve features.

    Limited Observability

    Risk: Overheard in a conference recently—Those who develop the code are more motivated to build in useful observability for those in operations if those folks are the same team. In NoOps, that’s not in play. If a cloud-based tool in your stack is down frequently or providing strange results, it may be very difficult to tell what is happening. Observability is often replaced by faith that the SaaS vendor has done its job and you aren’t experiencing a corner case it hasn’t tested.

    Mitigation: Observability and monitoring aren’t the same, but when you don’t have observability inside SaaS tools, monitoring helps. Application performance management (APM) tools are emerging with new ways to build instrumentation around microservices. Create test cases with synthetic data to check your functionality—you’ll need these to provide evidence for the vendor in any bug report.

    Unoptimized Workloads

    Risk: You’re also often at the mercy of the SaaS vendor when it comes to speed of results. It’s a common tripping point to pilot a SaaS workflow with a few users and test cases, and then find out it doesn’t scale when everyone is brought in.

    Mitigation: This is one the biggest NoOps risks where ops expertise pays off. Where is the problem, exactly? Application problems may be candidates for workload acceleration—such as running on a GPU (or FPGA) enabled cloud instance. Reporting problems may be better-suited for an analytics tool, which can be run offline with extracted data.

    Tangled Analytics

    Risk: Every SaaS tool reports different metrics in different ways. Worse, users in a multi-cloud environment face learning and visiting multiple applications to look at data. Different applications report similar facts using different terms. As the tool stack and data sets grow, it takes longer and longer to analyze data.

    Mitigation: Dashboards pay off early with one destination for data across the stack. Earlier, I mentioned the need for integrations or connectors—this should be a requirement for tool selection, both in the stack and the analytics tool. Deciding on which KPIs to track in the dashboard also focuses conversation and minimizes digging.

    Closing NoOps Risks

    There’s also the big topic of multi-cloud security and compliance, probably worth a series of posts by themselves. An Ops team working proactively in tool selection can comprehend many security risks before committing to tools and exposure. More value unfolds over time, as the security posture evolves with discovery of new threats.

    The tech pendulum is always swinging. For many organizations, NoOps swings the pendulum a bit too far from DevOps and leaves risks open. A better philosophy is MinOps, where a small team is deployed, watching for and even anticipating problems.

    I’d be interested to hear if you’ve tried NoOps and been successful over time, or if you reverted to a MinOps approach.

    — Don Dingee

  • DevOps Chat: Digital Transformation with Exadel’s Jonathan Fries

    DevOps Chat: Digital Transformation with Exadel’s Jonathan Fries

    In this DevOps Chat, Jonathan Fries, VP of Engineering and Digital Transformation at Exadel, tells us about the new Innovation Lab by Exadel—a place for organizations to accelerate their transformation. We also talk about the state of IT in general from his perch at Exadel, a company with 20 years of empowering IT.

    You can find out more about the Innovation Lab at exadel.com/innovation-lab/.

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

    Transcript

    Alan Shimel: Hello, everyone, it’s Alan Shimel, DevOps.com, and you’re listening to another DevOps Chat. This episode of DevOps Chat features Jonathan Fries of Exadel. Jonathan, welcome!

    Jonathan Fries: Hi, Alan. It’s great to be here.

    Shimel: Hey, it’s great to have you here, Jonathan, and I wanna thank you. It’s always nice to have a new company coming up on our chats here, so it’s—you know, some fresh blood for the audience. I assume most of our audience is not familiar with Exadel, so why don’t we start with that, Jonathan? Tell us a little bit about Exadel.

    Fries: Sure. So, Exadel is a global software engineering services firm. So, we help our clients write software. We have—we’re a global company, so we have offices in Eastern Europe, Belarus, Lithuania, Poland being kinda the big ones where we have our offices in Europe. And, you know, we help clients in a variety of areas. Probably our big verticals are health care, finance, transportation, media and entertainment, and high tech. And, you know, we have some really good clients in those areas. Health care, McKesson is one that people have heard of. Finance, we work with Deloitte. In the high tech world, we have HP and Google as our clients.

    So, we’re doing offshore development for a lot of it. We have teams that are either all in Europe or usually a hybrid of some people here in the U.S. and some people in Europe. We’ve got about a thousand developers in Europe, so that’s where a lot of our work gets done. We’ve been around for 20 years, and so yeah, that’s a bit about Exadel.

    Shimel: Another overnight sensation, huh?

    Fries: Pardon?

    Shimel: I said another overnight sensation.

    Fries: [Laughter] Yeah, it’s been a gradual sort of buildup of working with clients and, you know, getting to work with a lot of interesting companies and them recommending us to others.

    The name of the company actually comes from a combination of excellent and delivery. I always think that that’s an interesting fact to bring up, and I think it’s an important part about kind of who we are and where we come from and how we got that list of clients. You know, we’re all about building really great products, software products for our customers, and that’s how we’ve grown the business.

    Shimel: Sure. So, and Jonathan, you know, kidding aside about overnight sensation, that’s the right way to build the business, right? You don’t just—I mean, yeah, everybody wants to be a unicorn, but unicorns are mythical, right? [Laughter]

    Fries: [Laughter]

    Shimel: [Cross talk] the world and all of that, so good for you guys. But you know what I didn’t mention is, what exactly—and just sharing with the audience, what’s your position with Exadel?

    Fries: My title is Vice President of Engineering and Digital Transformation. So, my background is in the software development world doing software development, leading teams, eventually sort of managing engagements and things like that, and also today heading up the digital transformation practice inside of Exadel.

    So, my background comes from the technology world and software development, and that’s why I’m proud of—I’m proud of our engineering capabilities and what we’re able to do for customers.

    Shimel: Good for you, good for you. So, Jonathan, you know, digital transformation is such a buzzword today, right?

    Fries: Yep.

    Shimel: We’ve all heard it, you know, and the one thing I’ve learned is that, for many organizations, you know, digital transformation is hard, right? I’ve heard so many people say, “Well, this wasn’t as easy as it was made out to be.” And I think one of the issues is, is that, if you can’t define something, how can you achieve something? Right?

    Fries: Yeah.

    Shimel: And so, it starts with, “Well, what exactly does digital transformation mean?” And so, I’ll throw it back at you—what does digital transformation mean to you?

    Fries: So, digital transformation for us is about helping our clients with the—you know, the doing and the engineering work of doing digital transformation. So, it’s about software development—you know, in particular it’s cloud development today—QA automation, and DevOps. I mean, those are really the big three areas of expertise within the company that we’ve really brought together under the digital transformation sort of heading as well as our agile methodology expertise, and so, bringing kind of those four things together. And they completely make sense together, because, you know, DevOps is really kind of the technology reflection of agile methodology and agile methodology is kind of the methodology reflection of the DevOps technology mindset. And QA automation is so tightly wound into DevOps and really the way that we’re delivering software and the way that our DevOps solutions work are very much married a lot today to cloud development.

    And so, we’re bringing all of those things together, which are all things that Exadel had lots of expertise in, but figuring out how to make sure that we were weaving those strands together, if you will, in a really sort of explicit way and building up some solutions for clients. Not just, “Hey, we’re really good at those things, and we have people who can be really good at those things for you,” but we can bring all of our best practices together and some technology solutions together.

    So, that’s what it is for us. It’s very much, you know, we’re a software development, software engineering firm, so we really—you know, we’re not sort of going after the cultural transformation part of that, or the, you know, the change management. I mean, we certainly have experience with those things, but for us, it’s really about the development side of it and our expertise in helping clients take on hard projects and succeed.

    Shimel: Absolutely, absolutely. Let’s talk a little bit about something new that Exadel recently delivered, and that’s the Innovation Lab. Talk to us—what exactly is the Innovation Lab?

    Fries: Yeah, the Innovation Lab is, it’s a new offering that we’re bringing to the market that combines some things that we already have into one thing. So, you know, we’ve all heard about the importance of innovation and even innovation labs. You know, some companies have them or are creating them. Exadel’s Innovation Lab is sort of more of a virtual innovation lab as opposed to, say, a physical place that we help someone create.

    So, we already have something called Appery, which is a cross-platform, low code development environment for creating cross-platform mobile apps as well as, like, a low code backend that runs behind that. So, that’s a way to build software very quickly to create real, working software.

    We already have a lot of expertise in agile development, as I mentioned before. And so, that’s also part of what we do. We have really great resources, all of those developers that we have, you know, in Europe and some here. And we have some packaged solutions that are a part of those practices.

    So, we’re bringing those all together to help our clients innovate. So, you know, what we wanna do is help our clients who are looking for a way to move faster, experiment, try something, get some features in front of customers or business stakeholders more quickly, and the Innovation Lab is our sort of packaged solution for doing that.

    So we can, we bring all of those things together—low code development, agile, on-demand resources when there might be something. Since a lot of what people what to experiment today are things like artificial intelligence and blockchain and how can we make those things work for us, so that’s—you know, often, we might have to bring in, you know, we might have to bring in an expert to help out with that as well.

    So, it’s really, it’s all of those things to help our customers and new customers innovate more quickly.

    Shimel: Got it. So, you know, and to me, when I look at it, Jonathan, you know, we talk about digital transformation, and what I said before about how, if you can’t define it, how can you be successful, and even once you define it, it’s an experiment in a lot of ways, right? It’s kinda that classic DevOps where you deliver, you learn, you get feedback loops, you iterate, you reiterate, and you keep reiterating.

    And an innovation lab is kinda the perfect place to kinda have that sort of learning that propels, that helps you define and then succeed in your digital transformation, right?

    Fries: Yep.

    Shimel: You know, you don’t wanna practice, I guess, on live TV or stuff like that. But you need—you need these labs to push the envelope and find out what works for you and what doesn’t work for you.

    Fries: Yeah. I very much view it, you know, as an extension of the product owner, you know, life cycle from scrum. You know, there’s the regular sort of software development life cycle within scrum where you’re doing your sprints and you’re delivering software.

    Shimel: Mm-hmm.

    Fries: But a big part of what the product owner should be doing is developing the product backlog which includes, you know, testable hypotheses. That’s kinda the way that the scrum community talks about it.

    And so, the Innovation Lab is a way for product owners to test some hypotheses that they might not be able to test, you know, if they already have a product. Like, you may not wanna do all the work to develop it and test the hypotheses over here, or that hypothesis over here. You may wanna use something like the Innovation Lab where we can use some of the tools at our disposal to create something that you can deliver and test out one of those—you know, test a hypothesis kind of on its own, if you will—but with working software. Which, you know, as we know is also a big part of agile and DevOps. You know, wireframes and requirements are great and they have a place, but they’re not the best way to show people what you’re doing or get feedback, and this really allows us to help clients do that and do it more quickly.

    Shimel: Got it. I agree 100 percent. Interesting—great idea. Moving off Innovation Lab, there’s other stuff going on at Exadel. You wanna share with our audience a little bit?

    Fries: Sure, yeah. We just launched the practice areas. As I mentioned, I’m the head of the Digital Transformation practice, and we also have a Digital Marketing Technology practice and a Products and Platforms practice that, much like digital transformation, the other two are also things that, you know, in places where we already have a fair amount of expertise and were kind of collecting all of that together in one place.

    So, for Digital Marketing Technology, we have some pretty significant clients for whom we’ve done work with Adobe Experience Manager to build global, localized, large scale websites. And since we had really done that several times, the Digital Marketing Technology practice is all about packaging that solution and delivering that to other clients for kind of building those large scale worldwide type of websites with Adobe.

    Products and Platforms is—you know, given that we’ve developed Appery, which really is, you know, it’s not just an application, it’s a whole platform for building other applications, and we’ve done that both for ourselves with Appery as well with several of our other clients like GHX where we’re creating a lot more than just an application, it’s this whole ecosystem. And so, that Products and Platforms practice sort of brings together the best of our knowledge base about developing those really sophisticated, large scale platforms.

    And Digital Transformation, of course, which is mine, is all about DevOps, cloud tech, QA automation, and agile. We have a solution that we’re putting together within the Digital Transformation practice that is a cross-cloud Kubernetes implementation that’s all done with Terraform and we’re actually getting ready to use that with the first customer now. We’ve kinda been just doing our internal dev on it, but we’ve shown it to some people and they’re pretty interested in that. The first customer will probably just use it on Azure, but it’s got some really sophisticated—you know, deploying Kubernetes with Terraform, autoscaling, a lot of really cool tech for containerized application development. So, I’m pretty excited about that.

    Shimel: So am I. I mean, it’s an exciting time to be alive in IT. I mean, from a developer point of view, from an ops point of view, there are so many options and so—you know, such power at your fingertips.

    Fries: Yeah.

    Shimel: It really is, you know, it’s a golden age to be into this kinda stuff.

    Fries: Yeah, I agree. I mean, I just—I think it’s an amazing time and, you know, I think there’s so much opportunity. There’s so much opportunity out there in what you can do and so forth and then how easy it is now to, you know, to bring computing solutions online for stuff, you know, and it’s what can be done.

    It’s awesome, and I know that, you know, it’s a lot of change and it can be hard on people sometimes, but I’m definitely an optimist and an “all ships will rise” type of guy, so, you know, I see all those opportunities out there and it’s like—you know, yeah, there’s an awful lot exciting going on.

    Shimel: Well, you know, Jonathan, I think in our business, either we can be optimists, or we can be cynics.

    Fries: Yeah.

    Shimel: I got into it yesterday, some guy, I don’t even remember his name, but he tweeted, “Oh, those DevOps people selling snake oil! There’s no such thing!” I think they reach a certain age where they just feel like there’s nothing new under the sun, and therefore, they’re just gonna bad mouth, right, whatever new comes along, and—hey man, you know, there’s a place for them on Earth, too, I guess.

    Fries: Yeah, and I mean, I think there’s always, I think, a real reason to be concerned about automation and the changes that that brings to not just our industry, but all of society. I mean, you can look around and see how much automation is impacting everything and, you know, as somebody with—you know, I have kids who are grade school aged kids, and it’s like, the world’s gonna look a lot different 20 years from now, so here’s what you need to spend your time thinking about and learning. Because, you know, if you really wanna do this kinda job, it’s not gonna be there 20 years from now.

    Shimel: And I have kids in high school and college and I’m telling them the same thing, man. It’s a crazy world. But you know something? To me, you know, we talk about being optimist, pessimist—Jonathan, the flip side of digital transformation is disruption.

    Fries: Yeah.

    Shimel: Right? And so, you get to the haves and the have nots. You have the empowered people who embrace transformation and are accelerating their business, and you have the laggards who don’t, and they may very well have to die off, right?

    Fries: Yeah.

    Shimel: I think that’s the choice that we—you know, that it’s nice to talk about this golden age, but that’s also the choice out there is, you can get with it or fall by the wayside. It’s compete or die. And, you know, that may be harsh to some, but that, I think, is the way it is.

    Fries: Yeah. It’s kind of been true for, you know, for a while, honestly. Industrialization automated some things, and like I said, I think, at the end of the day, the new businesses that will be created by digital transformation, the businesses that will be completely transformed by digital transformation will create, you know, even more opportunity, and as long as you are looking at it through the lens of those things, even though automation can be—you know, it can be scary.

    I mean, like I said, I came from—I was a developer and worked in IT and things like that, and you know, there was lots of things even 20 years ago, where it’s like, “Oh, these things are gonna change everything and jobs will go away” and it’s like—you know, that’s—

    Shimel: [Cross talk] Doesn’t happen, doesn’t happen. Anyway, Jonathan—

    Fries: No, it happens.

    Shimel: – when we started, I told you, the 15 minutes goes really quick, man. [Laughter]

    Fries: Yeah.

    Shimel: And we’re way over already. I apologize, but I didn’t wanna stop you, you were on a roll, and I thought it was a good conversation. So, but we’re gonna need to pull the plug on this episode of DevOps Chat. Jonathan Fries from Exadel, thanks for being our guest today.

    Fries: Absolutely, Alan. It was great. Thanks for having me.

    Shimel: Alright! This is Alan Shimel, DevOps.com, and you just listened to another DevOps Chat.

    — Alan Shimel

  • DevOps Institute Brandjacking: When Imitation is Not the Sincerest Form of Flattery

    DevOps Institute Brandjacking: When Imitation is Not the Sincerest Form of Flattery

    “There can be only one”    ~ Duncan McCloud, Highlander

    They say that imitation is the sincerest form of flattery. Often it is absolutely true. But stealing, ripping off and/or trying to trade on the name of others crosses the line between right and wrong, legal and illegal. As a co-founder of the true, one and only DevOps Institute, I was appalled to see the efforts of another company, whose name I won’t even dignify in this article, trying to launch “the DevOps Institute.”

    If you told me that this company perhaps did not know that there was already a DevOps Institute (it’s not like we hide it), I would say OK, maybe it was an honest mistake. But no. In this case, the company in question actually reached out to DevOps Institute—us—and had several conversations/interactions regarding becoming a registered education partner of the DOI. What the company reps were actually doing was fishing for information as they sought to launch their own version of DevOps Institute. So this is certainly not a case of an innocent mistake; rather, it’s a deliberate attempt to misappropriate the name, assets and hard work of another. Where I come from, the streets of NYC, we call it stealing.

    You have to ask yourself: Knowing what we know of the situation, why would these people commit such an unethical, illegal act? I can only come up with a few reasons:

    1. They are seeking to deceive and confuse the public by literally trading on DevOps Institute’s—our—good name to make a quick buck.
    2. They are part of those in the world who do not respect intellectual property, seeking to sell out the back door anything they get their hands on from the front door.
    3. They are unscrupulous thieves who are incapable of building a business by themselves.

    No matter whether one or all of the above, none of the reasons are very good.

    In generally acceptable business practices worldwide, there are more than several acceptable ways for companies to imitate the business strategy and models of others. More power to them—after all, competition makes us all up our game.

    In the DevOps education training and education space, there is certainly no shortage of competitors. Just do a Google search of DevOps Institute and look at the companies buying that ad word or otherwise using SEO to get listed. Lots of competitors, for sure. Remember, this isn’t even a generic “DevOps training” search, but actually searching for DevOps Institute.

    Taking another’s name crosses the acceptable boundary. So now we have to lawyer up to protect our rights and property. No one likes to throw good money at lawyers to go after bad actors. But protecting one’s brand, reputation and IP is that important.

    For those of you familiar with the DevOps Institute, you know that the team has worked hard for more than four years now to lead the way in curating content for bringing DevOps training, education and certification to the market. It hasn’t always been smooth sailing. When DevOps Institute launched, we faced strong headwinds from those who thought a training/certification program around DevOps was wrong. We listened, we learned, we set up the feedback loops and we iterated (like good DevOps should). We have won over many of our critics; they saw the good work we were doing.

    More than that, they saw DevOps Institute try to be stewards of and active participants in the DevOps community. We are not in this for the fast buck or the quick hustle. The executive team has plowed our revenue back into the company and community, expanding the association’s offerings and reaching out to DevOps communities throughout the world. Today, DevOps Institute has ambassadors in Europe, South America, AsiaPac and of course here in North America. We go wherever DevOps goes.

    Recently DevOps Institute has tried to build a greater DevOps community based on the Humans of DevOps and our SKILS framework (Skills, Knowledge Ideas and Learning). We have worked with the leading names in the DevOps industry to do research and help bring greater understanding of DevOps. We have sponsored and spoken at many of the DevOps events you have attended. In fact, I am satisfied to rest on our laurels.

    If you are not familiar with the real DevOps Institute (and that is at https://devopsinstitute.com, btw) check it out for yourself. We have nearly 200 partners around the world who deliver training for our certifications. We have a healthy global community and active engagement with industry thought leaders. We obviously are doing something right.

    Finally, I wanted to speak to my entrepreneur friends in the audience: Those of you know who know me, know that this isn’t my first rodeo. I have founded and helped several venture-backed startups through IPO and exit. I have had my share of wins and my share of losses. I am not one to whine or back down from some good competition, but this kind of shadiness has no place in the business world.

    We put a good chunk of our own blood, sweat and tears into our businesses, and for someone to swoop in and steal the fruits of our labor is just plain wrong. Brandjacking is stealing. I started this article off with the quote from “Highlander.” So if you see me walking around with a severed head or sword in my hand, remember: There can be only one.

    — Alan Shimel

  • Insight IGNITE: DevOps, Cloud and Cyber From Iceland With Love

    Insight IGNITE: DevOps, Cloud and Cyber From Iceland With Love

    I had the pleasure recently of attending my first Insight IGNITE event, which was held at the ION Adventure Hotel in enchanting Iceland. It was also my first trip to Iceland. These two new experiences combined to deliver an excellent learning and networking experience, resulting in me realizing more than several new insights (pun intended) around DevOps, cloud and cybersecurity, as well as mindfulness and contentment.

    The agenda for this particular IGNITE event featured some great examples and discussion around DevOps, cloud migration and infrastructure and cybersecurity, among several others. All three of these were right in my wheelhouse, so I really enjoyed the presentations and discussions. I couldn’t type fast enough to keep up with all of the insights I was soaking in. Of course, I was also trying to contribute to the conversations, which are held in a very open, communal manner under Chatham House Rules.

    You may not be familiar with the Insight IGNITE Innovation Roundtable Series. They are the brainchild of Insight Partners’ Emmet B. Keeffe III. Emmet is beyond passionate about digital transformation (among several other passions including Formula One racing, world peace and now mindfulness/contentment). Utilizing his vast network (and it is vast), Emmet founded Insight IGNITE, an innovation program that delivers Innovation Briefings, the Innovation Roundtable Series and Growth Advisory Board opportunities to global IT leaders. I know that sounds like marketing speak, but let me explain.

    Basically, Emmet holds about one of these events a month at some of the most fascinating venues on earth. Each one has ~50 people. There is a mix of C-level executives from some of the 200+ Insight Partners portfolio companies, along with executives past and present from large global enterprises, sprinkled in with a mixture of technology experts and subject matter experts (I guess that is what got my ticket punched). The agenda is an exhilarating mixture of roundtable discussions and presentations on subjects touching on Digital Transformation, along with exciting activities that allow attendees to experience the local venue.

    The events are open to Global 2000 executives and other business and technology experts who think they could both benefit from this type of experience as well as have something to offer.  You can reach out to Emmet’s team if you are interested in attending one of these events.  Most attendees have to cover their own airfare/hotel. While not cheap, it is well worth the money, and the IGNITE team, who are extraordinary, do an amazing job of keeping it fresh, fun and challenging.

    The real special sauce of the IGNITE Roundtable Series, though, is the passion, caring and love that they receive from Emmet’s team. It is infectious and spreads to the attendees as well. I have attended hundreds of conferences over the years and don’t remember one where I made as many connections, had as many great side conversations and really felt part of a group. I am sure many of the people I met at this event I will be in touch with and doing business with in the months and years ahead.

    I met Emmet about three or four years ago in London (where he lives with his family now) and was invited to a previous event or two but was unable to make it. Since then, it seems Insight Partners is investing in so many of the companies that we work with here at MediaOps in DevOps, containers and cybersecurity—including Tricentis, JFrog, Aqua Security, Firemon and others. If you can’t beat ’em join ’em, as they say, so I decided to take Emmet up on his kind invite and check it out.

    The IGNITE event in Iceland had several great presentations about disrupting your own company product by spinning up the disruptor internally. We heard from “a queen of transformation” who has led transformations at several large multinational and government agencies. Another presentation focused on how an energy company keeps transforming as it stays ahead in today’s ever-shifting market and sets the bar for what the energy company of tomorrow looks like. In addition, there were some great panel discussions on the current state of DevOps and Agile, another on the state of cloud migrations, hybrid cloud and next-generation infrastructure. Also on the agenda was a great discussion regarding what is happening in cybersecurity and how critical it has become as part of any transformation. All of these were great, but what made them better was the great discussions they sparked among the attendees.

    That was not the full roundtable agenda, though. We also had a private briefing with the first lady of Iceland, discussions on some new fintech companies and technologies, AI/ML and more.

    But perhaps some of my favorite presentation and discussions were on a new passion of Emmet’s called the Contentment Foundation. This is a breakthrough effort to bring a new take on making education better for the world of today and tomorrow. Led by Dr. Daniel Cordaro, it recognizes that children are truly our future. How can we make them more content and mindful, better equipped to handle the world of tomorrow and the challenges they will face? The Contentment Foundation has developed a curriculum that is available to just about any school in the world. If you know a school that you think could benefit from this, I encourage you to reach out to them.

    All work and no play would make for a boring event, though. My trip to Iceland at the Insight IGNITE Roundtable was far from boring. We visited the famous Perlan Planetarium (which, unfortunately, was as close as I got to seeing the Northern Lights on this trip); ate in a Viking-themed restaurant; and rode ATF vehicles through the rugged, lava rock-strewn, stream-filled Icelandic countryside. We explored a lava tube cave and more. Unfortunately, the weather didn’t cooperate, so we had to cancel snowmobiling, whale watching and dinner on an island off the Iceland coast. I stopped off before heading to the airport to explore a bit in the capital of Reykjavík, which is a great little city with great cafés, shopping and sights.

    Even the social activities provided some great bonding and networking opportunities. It is rare for me that I not only make business acquaintances, but also form friendships at events like this. To me, this was yet another unique feature of the IGNITE Roundtable: People were there genuinely to share their experiences and discuss the burning topics at hand.

    All in all, one of the best events I have attended in a long time. I highly recommend attending at least one of these IGNITE Roundtables, if this sounds like something you may be interested in. As for me, I am already looking at what is the next one I will be able to attend. Once I have had a chance to digest and percolate on some of the insights I experienced, I will share a follow-up article to share them with you.

    Thanks, Emmet and IGNITE team, for a great experience.

    — Alan Shimel

  • The DevOps Institute Has Been Brandjacked

    The DevOps Institute Has Been Brandjacked

    Sadly, another organization has decided to brandjack the DevOps Institute name. Quickstart, an e-learning organization based in Austin, Texas, recently approached DevOps Institute about becoming a channel e-learning partner. Instead of joining our partner community, Quickstart chose to stand up another “DevOps Institute.” Since they were in communication with the actual DevOps Institute as late as March 9, I can only assume that this was an intentional act to confuse the market into believing that they are somehow associated with (or are) the actual DevOps Institute.

    They are not.

    Since 2015, the DevOps Institute has spent countless hours, attended numerous conferences and invested significant resources in advancing the human elements of DevOps. We were the first stand up formal association to focus on DevOps learning and certification as DevOps was emerging in the enterprise space. We are known and respected by many of the key DevOps thought leaders and vendors. We recently fielded the “Upskilling: Enterprise DevOps Skills Report” with the support of Electric Cloud, CloudBees and Lenovo. We not only talk the talk, but we also have demonstrated time and again that we are committed to walking the walk and are heavily invested in the goals of the DevOps community.

    To be clear, we have no issue with fair competition, particularly in a space that is growing as quickly as DevOps. That’s the nature and risk of running a business. Competing on products or offerings—that’s expected, and it ultimately helps the people within the industry succeed. Hiding behind another organization’s brand, though? That’s not only unethical, it defies every value that is at the heart of DevOps and established business practices.

    I thought long and hard about whether to give Quickstart and www.devopsinstitute.io visibility by exposing their actions. The easy way would be to stay quiet and let the lawyers sort this out (which they certainly will). However,  the real DevOps Institute stands by our moral obligation to the DevOps community and we, therefore, cannot let an imposter bully us into silence. The dictionary definition of an imposter is “someone who pretends to be someone else in order to deceive others.” Quickstart is an e-learning company masquerading as a well-respected DevOps association, presumably for commercial gain. What do you think?

    Please do not be deceived by imposters that falsely attach their services to DevOps Institute in the hope of benefiting from the goodwill we have established with our brand in the DevOps community.  There is only one DEVOPS INSTITUTE (www.devopsinstitute.com) and we are wholly committed to advancing the human elements of DevOps through our SKIL (Skills, Knowledge, Ideas and Learning) framework.

    Buyer Beware!

    — Jayne Groll