devopsy.kinsta.cloud

Author: Alan Shimel

  • Growing Adoption of Compliance as Code and Policy as Code – Techstrong TV

    Growing Adoption of Compliance as Code and Policy as Code – Techstrong TV

    As DevOps has matured and more organizations have adopted an infrastructure as code methodology, alongside an increased importance of security, we are seeing compliance as code and policy as code being adopted by many organizations. Progress Software’s Chef products are helping lead this trend. The video is below followed by a transcript of the conversation.

    Alan: Hey, everyone. Thanks for joining us on another TechStrong TV interview. I’m really happy to have – well, it’s the first time I’ve interviewed him here on TechStrong TV, but Charlene has had the pleasure of having Prashanth on before. Let me introduce you and I’m gonna do my best on his name, I apologize. Prashanth Nanjundappa. Is that close, Prashanth?

    Prashanth: Yes. Prashanth Nanjundappa. That’s close. 

    Alan: All right. Prashanth is with Progress Software, where he’s a VP of product, isn’t it? 

    Prashanth: That’s correct. 

    Alan: And we’re going to talk a little bit about today, we’re gonna talk a little bit about, you know, compliance’s code, you know, in this shift left kind of mode, but also the whole maturation of the DevOps space, etcetera. But you know what, Prashanth, as we spoke about off camera, this is your story to tell. Right? This is your kind of thing. Let’s, you know, talk about things that are important to you. Why don’t we, you know, tell us what what’s kind of important to you these days? 

    Prashanth: First of all, let me thank you. Thank you, Alan and TechStrong TV. This is a great opportunity to actually talk to many of the people who are using our products. Right? I am currently leading the head of product management for one of the business units in Progress, which is managing Chef line of business. We acquired Chef on board about 1.5 years ago. And this is my first foray into managing or building DevOps and SecOps tools. And that was a disadvantage, and also an advantage. 

    I got to talk to about 150-odd customers because I didn’t know much about this space. So the best way to learn about it is talking to our customers and talking to people who are experts in this domain. And that kind of got me really, really knowing about how these large enterprises are even tech companies are investing a lot in automating their day-to-day needs and adopting DevOps and their SecOps as technology practices, bringing those practices in their organization, and using tools like Chef to make just not their teams efficient, but also to increase time-to-market and reduce the risks of their business. 

    And the reason I’m talking on this, I think your target audience are the people who listen to this stuff. Your videos are the kind of practice notes that I talk day and day out all the time. They give the feedback which has helped us graph out the roadmap for years to come with Chef product line. 

    Alan: Absolutely. And you’re right. That is our audience. Right? Quite frankly, you know, when I launched DevOps dot-com eight years ago, Chef was one of the giants in the – you know, pioneer in the DevOps space, and that was our audience. But you know, over the years, we’ve seen this shift, if you want to call it shift left. It’s not necessarily a shift left, but we’ve seen an increased emphasis on security. And, you know, security’s partner in crime in many ways is compliance. 

    But as we’ve automated more, as we’ve gone faster and try to be better, faster and better, right, we’ve recognized the same way we’ve automate in DevOps deployment, we need to automate more when it comes to security and compliance. Right? And that’s been painful at times quite frankly. It’s not necessarily easy. 

    Prashanth: Oh yeah.

    Alan: Let’s talk about, you know, where the kind of hard parts are and how companies like Progress are helping us overcome that. 

    Prashanth: You’re spot on. It’s hard. It’s unnecessary evil as some people say but I think that is changing. So before that, taking a step back, why is security and compliance required? I think the need of security is well understood, but compliance data has been historically three primary reasons. Either they are regulated bodies who keep looking out who is complaint, who is not complaint. Every few months or ever few years, they publish a new set of standards, which give a perception to companies or tech companies that they need to adhere to that. 

    And that then get complemented by either the regulated sectors like banking and financial, credit card, or hospitality, healthcare, where security, privacy, all these things that are of most concern. And they look back at these regulatory bodies who have been publishing these specifications. These two kind of go hand-in-hand. And I tell you, there is a third-dimension, who are the customers who are using the products. They look at these regulatory bodies who turn out the specifications and also the regulatory. They say if I want to buy a product from you, I want it be certified. I want it to be compliant to this. 

    So these complaint as a need to operate in such industries. But I think it is moving a little from the basic necessity of, you know, being compliant to making sure that my development is fast-paced. Today, if you look at every – there are so many companies, Uber or something, Airbnb, or something, Yelp or something, and this used to be in the consumer sector, but it also coming into regular segments like banking, financials like that, Robinhood like companies have normalized trading, and they have made sure that anyone can launch a product. 

    So even tech chains, they have to adapt to this fast-paced market and bring their products not just fast into the market, but also adhere to the compliance standards, compliance specification, and make sure that whatever they launch is secure. And that is where automation comes. And that is where as a code paradigm came. You’re quite familiar with the evolution of how infrastructure as code and DevOps involved. There the codification of infrastructures have involved because they wanted to make sure that whatever gets developed is automated, and they test well in advance. 

    I think the same mindset is coming here because are there different bodies, developers, Ops team, and security teams. All of them generally speak in completely different languages, but if you want them to bring together to actuate the time-to-market, they need to speak one code, one language, and code seems to the most common, most acceptable language. And once they make a code, it falls into the DevOps sector. You can test it. You can repeat it. You can make sure there are checks and balance to make sure you flag, you audit everything. 

    But I think that mindset, and also DevOps has made compliance as code acceptable. And we are seeing more and more option. And that is ability of success for the traditional organizations to move in a fast pace. And new companies, they don’t even see other options as options. They take it as default option because this helps them past development. I don’t know if it makes sense. 

    Alan: No, it makes perfect sense. I mean it’s also a life a lot of our people are living day-to-day right now. Right? So the security person in me, and Prashanth, I was in security infosec, as we called it before, cyber sec, whenever I worry about compliance, I hear about compliance, I immediately start thinking, you know, am I dumbing down my security for compliance sake? Right? Because sometimes when we do compliance, it’s kind of, you know, I could call it least common denominator security. It’s like the lowest bar. Right? 

    Prashanth: Right.

    Alan: And a lot of people say, “Okay. I’m compliant. I must be secure too.” But they’re not. Just because you’re compliant doesn’t necessarily mean you’re secure, whether you’ve, you know. Compliance, as they say in Las Vegas, it’s a fine beginning. Right? But it’s not the mean to the end. So how do you, you know, as a compliance’s code type of provider, how do you make sure that your customers understand, okay, since you’ve done step one, but you still need to do step two and three. 

    Prashanth: Exactly. This is a very important distinction we also took a while to realize. Right? So there are three pillars: infrastructure, compliance, and security. So infrastructure is basically – I mean we can argue what is foundational, but you build your application and that’s where automation is required of infrastructure. Right? And then if you want to operate in regular tech sectors, if you want to be – not lose the competitive advantage with other players, you need to be compliant. 

    But security is something, which is fundamental. Right? You don’t realize until there is a breach, or until there is an impact on business. But, you know, these days, unfortunately, that is not very uncommon. We are seeing so many companies being exploited because of very, very basic mistakes like opening their port 80. Right? Exposing a port 80, or leaving their S3 buckets unencrypted. Right? 

    So many of these things are misconfigurations, or many of these things would have been covered or not happened if they had held to some of these standards. Two such bodies which offered a large specifications of best practices. Of course the primary takers of that is compliance. But those act as a foundation to security infrastructure. So we help our customers in obviously infrastructure and compliance, but we have started helping them in secure infrastructure as well. 

    Well, they have to look at infrastructure whenever an application passes through the CI/CD pipeline at each point in sort of just checking for the functionality using the right tools, some of the tools that we built, and some of the tools are available in their ecosystem. They can secure it. It can harden an image. For example, within Progress, there are teams which are using our Chef software to make sure that every image that gets into Artifactory, the Docker container gets into Artifactory isCIS specification, and other qualities that are specific. They don’t let it get into Artifactory without going through this. 

    So I think that is very much possible, and that is the education that we are giving and helping our customers, and that’s a two-way process. Right? Because we maturing in security. So as we engage with our customers, we are learning some of the shortcomings and the tools, and we are bringing back in the quality as code approach that we have been working in 2021 is based off this exchange, information exchange. 

    And also working with our customers, we realized that we’ve gotta go beyond infrastructure as well. Compliance and code, but two qualities a code where we help organizations define their government’s police, which is heterogenous and across organizations, sub organizations. But codify them and help them automate that process. 

    Alan: Exactly. So here’s an interesting thing from where I sit. Right? Sitting here running DevOps dot-com seven-eight years now. We can’t even have this discussion. We couldn’t have this discussion until we reached a certain level of maturity in the way we approach. Let’s forget compliance for the moment, but infrastructure as a code. 

    Prashanth: Yeah. 

    Alan: Right? Because you can’t start talking about compliance as code, and policy as code, and security as code until you got that infrastructure kind of down pat. Right? And so the fact that we are even having these discussions, right, and thinking about it, and implementing tools around it, you know, it was almost the proof on its face. Right? “Prima facie” as they say in law in school. Prima facie. That we are, we have matured, right, in the way we’re deploying our infrastructure, the way we’re automating infrastructure. So I’m calling infrastructure as code. Right? 

    Prashanth: Okay. 

    Alan: What do you think as we look ahead to 2022 and 2023, that continued maturity, what does it mean for policy as code? What’s next in other words? 

    Prashanth: I think a slight deviation from that is you said that is that you said about infrastructure expanded to DevOps methodology. Because I think that is the mindset shift that needed to happen for people to actually add up infrastructure as code, and then subsequently compliance and other paradigms, which would help them in automation. I think that is the foundation and we are seeing more and more companies seeing this as tables takes. 

    And again, they’re also – it has been a – there is a mindset shift that from where I see, it used to be a play for cost or optimization because of their bottom line. They wanted to reduce their development cost. They wanted to reduce the cost of having a breach. They wanted to reduce cost of finding a defect late in the cycle. But these days, I think is fight for spotlight because every – there is so much competition that is emerging, and there is no choice but to make your product available to your end consumer as soon as you can. 

    If you don’t do that, someone else is going to grab that opportunity for you. This makes it very, very important for organizations to take this learning that we talked about, which is a testimony that we are talking about compliance and security, but take the previous learning into their foundation. So that is what’s happening. Every new start-up that I talk about, I tell them in DevOps, these are something that they don’t even think as non-optional. Right? These are table stakes. 

    And from that point, they go on beyond, okay, I got my deployment automation. But hey, I have the security issue. I operate in a finance market. I operate in a banking sector. I operate in a hotel business. I operate in healthcare business. How can I make sure that I stay competitive? I make my data secure? This mindset of having faster time to market is making them add on these things very natural. And policy as code, whatever we are seeing, I think this is one of the common factors day one to stay competitive. 

    Alan: Got it. Excellent. All right. Prashanth, unfortunately we’re closer to 20 minutes now than we were to 15 that I told you we would do. Hey, we could continue this conversation though, but I think we’re in the right place. I think it’s something that resonates with the audience. For people wanting to get more information on Chef and Progress around this, where do they go? 

    Prashanth: Of course, we have a very vibrant community for Chef. So Chef community can be found on Slack. That is where us and other practitioners also hang out. And of course many of us are super active on LinkedIn as well. So these are the two places I think we can engage faster, and communities like this is probably the fastest to engage in Chef product, and engineering folks. 

    Alan: Okay. Hey, thanks for coming on TechStrong TV today. We’ll see you again soon. Best of luck to all the folks across Progress and Chef. 

    Prashanth: Thank you. Thanks for having me. 

    Alan: Okay. Bye-bye. All right. We’re gonna take a break. We’ll be right back. 

  • Plutora Releases Test Environment QuickStart Bundle – Techstrong TV

    Plutora Releases Test Environment QuickStart Bundle – Techstrong TV

    Bob talks about Plutora’s new “Test Environment QuickStart Bundle”. It provides an easy, immediate fix to the Achilles’ heel of software development: environments that cause delays, produce bugs, and waste time and effort. The video is below followed by a transcript of the conversation.

    Alan Shimel: Hey, everyone. Welcome to another Tech Strong TV segment. I’m really happy to be joined today – I don’t know if he’s actually been on Tech Strong TV with us, but I’ve spoken to him many times; it’s my friend Bob Davis from Plutora.

    Hey, Bob, how are you? 

    Bob Davis: I am great, Alan. It’s so good to be here. I haven’t had the pleasure of being on the Tech Strong TV spotlight and it’s great to be here.

    Shimel: Fantastic to have you. So, Bob, our audience has been fed a steady diet of Plutora for years already, right? So most of them know Plutora, one of the leaders in the value stream management space, a DevOps pioneer leader. But I don’t know if they really know you. I’d like to introduce them to Bob Davis. 

    So why don’t we start there? Give them a little bit of your history, Bob.

    Davis: Sure thing. Alan, I’ve got a few years under my belt, and I started in the semiconductor business back at Intel as a chip designer. And I ultimately said, “Gee, you know, I think I understand why I want to build things bigger, better, faster and cheaper, but I don’t understand the business.” So I went and got an MBA and I moved into more of a product marketing orientation, and from there became a serial entrepreneur. 

    This is, Plutora is my tenth startup. I never joined another large company after I joined Intel, but I found my way into some through acquisitions and so forth: Novell, CA. Always on the software side, always on the, you know, typically the infrastructure, you know, a lot of enterprise IT, networking, compression, security, a lot of that, and ultimately back up in recovery and continuous data protection and those kinds of things, which ultimately led me to really understanding, wanting to understand more about the developer side. 

    And so about five or six years ago I found my way into Plutora and I became chief marketing officer and away I went. Along the way I became a pilot, I play golf, and love the water. So I’ve got a lot of things. And six grandchildren, so good stuff.

    Shimel: Six children. God bless you, man. Whoo. You know, I’ll tell you off camera; I don’t even want to get into it now.

    But anyway, that’s great, man. It’s great to have you here. And it’s interesting, ’cause you know what, a lot of people will hear “Bob Davis, CMO Plutora” and say, “Ah, he’s a marketing guy.” Well, yeah, but you’re a marketing guy who started off designing chips at Intel when a lot of people watching this were playing computer games, not even computer games, Show & Tells or whatever the heck they were. Right?

    Davis: Yeah. Well, I’ve always been on the product side and I’ve always been more on the “What’s the next idea?” In fact, the best example of that was right around 2000 – you know, we started Kaseya. 

    Shimel: Oh, I remember that.

    Davis: So I was the original founder of Kaseya and started that in my kitchen and it’s …

    Shimel: Really?

    Davis: Yeah. To being what it is today. And there wasn’t even a managed service provider market at the time.

    Shimel: No, I remember that early on. Because I had started a company called StillSecure and in 2005 we pivoted into MSSP. ‘Cause I just thought MSSP was the way to go. It was too hard for too many companies; they needed an MSSP. Actually Kaseya bought friends of mine, Carl and Billy Austin, they’re serial entrepreneurs as well. They were acquired by Kaseya. And then of course Kaseya was acquired, what was it, a year or two ago maybe? 

    Davis: Yeah, Inside Venture Partners bought Kaseya in 2013, which is when I left actually.

    Shimel: Right. Oh, okay.

    Davis: That’s when the new management came in. And we sold the company and kind of went off on our own journeys. I went to a company called Atlantis, which we were doing hyper-converged storage, and then ultimately Dalibor Siroky, CEO of Plutora, found me and brought me over to Plutora in 2017. 

    Shimel: Very cool. So, Bob, we were talking off camera a bit. We’re at an interesting sort of boundary layer here again. I think many of us are let’s call it cautiously optimistic that we are going to emerge from our kind of COVID cocoons and venture out again en masse. 

    Davis: Yes.

    Shimel: Many of us are already.

    Davis: Yes. 

    Shimel: The interesting thing is the world we left two years ago is a different place today than it was two years ago. We’ve learned a lot of things, we’ve experienced a lot of things. Digital transformation – no pun intended – has transformed many a business – many a business model. For us in the tech industry, for our audience, you know, the way they shop for products, try products, use products, measure flow in terms of value stream and stuff like that, it’s really changed in two years. They’re different. You can’t put your foot in the same water twice, right? And so companies like Plutora – someone once said that, I’m pretty sure. 

    But companies like Plutora, they’ve had a change. You’ve had to adapt. And you guys have. You have that sort of a whole new program you’re coming out in market with. Let’s talk about it.

    Davis: You bet. You know, in the beginning, right in the beginning of the pandemic, early pandemic, early 2020 we saw as the world was trying to find its axis again we saw an incredible increase in people wanting to learn. So they spent the first part of that 2020 just in this learning mode. And value stream management was one of the things that people were really focused on learning. And the notion of being able to say “Wow, if I could really see a pipeline, a value stream from the beginning to the end and understand if I’m getting better.” And that was really the question that the CIOs were asking, “I’ve spent millions of dollars on these tools. Am I getting better?”

    The point I’m making is that everybody was trying to understand how they could tell if they were getting better. And all these flow things became almost an MBA project or a PhD-type project to really understand all that’s possible. And that was awesome and we got a lot of interesting traction from that. 

    What we found, however, is that that transformation is a daunting transformation and the world changed around everybody. We went from distributed teams to distributed teammates. So now that autonomous team was distributed in and of itself, and the communication and collaboration became very difficult to achieve. So processes, organizations were changing. So many things changing all at once that people were really slowly doing like they’d be happy to go to an event, sit on a virtual show. What do I need to understand to get better?

    That’s not what’s happening today. Some of it, sure. Some of it still happens. But people are moving to more execution. They want to get value. They want to start seeing the value of that journey and they want to see the value in real-time. They don’t want to see it a year from now; they want to see it right now, this year. So we have seen our customers struggle with saying “How can I get started in value stream management? I may not even want to go all the way to the end of the value stream management journey, depending upon my specific tastes.”

    So we’ve developed an entire program around doing just that. How can we get people into a value stream process mentality, into a value stream platform, and do so quickly so that they can value right away. And so we have this program called the Quick Start Program and we released in January the first of several Quick Start products. This one is on environment management, which is a core component of value stream platform that Plutora sells. And in so doing we’re able to provide people solutions to a very complex test environment problem in three or four weeks, whereas today it can take 30 days just to configure and make an environment available on some of the prospects that we’re talking to.

    So in the time it takes to get an existing manually configured test environment ready for a test event you can have a full test environment management program and go from manual management of test environments to an automated process very quickly. Now I see value. Now I can see value in terms of the efficiency of utilization of expense and test environments. I can see better quality. I can see saving tons of money. 

    We find that people with average levels of releases, well UMA did a study and they came out and said the average number of releases in an enterprise environment was 76 a year. That was in a survey. They did a survey and they came back and said that was the average. There was certainly a distribution, but that was the average. And if you’re manually managing your test environments you’re losing money. They determined based on all the issues of managing these things almost $1.5 million a year you’re wasting. 

    And so we can save you that with a product like this. So imagine I’ve got a bottleneck in my DevOps tool chain, the Achilles’ heel of my tool chain is waiting for test environments as I shift left and try to test earlier. I solved that problem, I removed the wait states there, I become more efficient, I save money, and I can do that in about three to four weeks worth of setup. And now I’m rolling. Wow, I’m getting value. Now I go to the next problem and so forth. And I get quick starts, I can come into the platform pretty soon. I’ve got a full value stream management platform down the road. I’ve gotten value every step of the way and I never had to really think about the prospect of doing the whole thing. It’s like one step at a time; every journey is one step. So it’s like let’s give people the ability to get value in that same way, one step at a time. 

    And that’s really, it’s been met with tremendous success already. We’ve seen a lot of responses, a lot of people wanting more information, and our SDR team is very busy fielding calls on it. So it’s been a real successful launch so far.

    Shimel: That’s great. You know, Bob, I think part of the reason for its success is there’s two kind of trends you’re riding there. First of all it’s this, I call it “deliver delight,” but I mean that’s just two words, right? It goes to when I was an entrepreneur founder of companies we were hiring enterprise salespeople who sold to the C-levels and all that stuff. In today’s world we hire DevRel evangelists, and the idea is get the software into the hands of the people who are going to use it, deliver delight, and if it works they’ll tell their bosses and so forth to buy it. So it’s a different sales model. But it’s become dominant, especially in DevOps cloud native, you know, the kind of markets we play in. So this really is kind of playing into that. 

    Davis: Totally.

    Shimel: It’s delivering delight. Because synonymous for delivering delight is delivering value. 

    Davis: Yes. Well, that’s the point, right? Now it’s the whole point of value stream management in the first place. You know, it’s interesting; it’s really an agile approach to delivering the value stream management solution. There’s a parallel there. You know, saying “I’m going to buy a value stream management platform and implement it” is a little like deciding I’m going to build a waterfall process. ‘Cause it’s everything at once, this is what I want to do.

    Shimel: No, it’s like trying to eat an elephant.

    Davis: Exactly. 

    Shimel: You’ve got to eat it one bite at a time. [Laughs] That’s the only way you can eat it.

    Davis: Right. Well, you’re crossing – you know, by the very definition value stream management embraces both, you know, everything from the ops person on the far right to the strategic planning office on the far left, and so you’ve got lots of people, you’ve got lots of moving parts. It’s hard. We actually have found hard when we market the product we get the interest from the pain point, I’m having trouble. In this case I’m having trouble managing my environment. If you’re selling the entire platform that environ manager, in order to take advantage of that feature, has to sell the platform to the planning person, to the ops person, ’cause they’re all going to get affected. 

    There’s value there, but they’re like, “Show me.” Now we’re giving them a tool they can do that. It’s an on ramp into the platform, a smaller bite of the apple, as you said, an agile approach to delivering value stream management and value at the pain point level. And so we’re doing everything around it to make it super-clear if you have this pain, this is what it looks like in our product when you solve it, and you can get there by the end of the month. Does that sound reasonable? And it’s way cheaper.

    And so that’s the other thing, these platforms can be expensive. But what if I can buy something that’s in my sign-off authority, so it’s more approachable to me? The whole notion of S-a-a-S is all about product life growth and let me get something in my hands for free and try it out and then I can grow from there. That’s the beauty of what so many people have enjoyed with S-a-a-S-style software products. 

    Value stream management is hard in that sense, ’cause it’s complicated. There’s integrations into the tool chain, there’s process changes as people evolve from more legacy processing to DevOps tool chains and DevSecOps tool chains and so forth. There’s that. There’s organizational change, budget-holder changes, people moving from silos and project-oriented things to product-oriented things. So we’ve run into prospects that get so frustrated, they want the solution but there’s a lot going on in the organization. We’re answering that question.

    You can each have had a success, show the value, and go from there. It’s a great on-ramp. It’s a freemium approach almost in a complicated environment and its value stream management, and we think it’s really going to be awesome when people can have multiple. We’ll do probably deployment, we’ll have a quick start for master deployment plans. You know, Jeff was on in November talking to you about our progressive release management and some of the new stuff that we did with the Insights dashboard. That’s another screaming for of Quick Start, “Hey, wouldn’t it be cool if you could get this up and running very quickly?” 

    So all of those things is where we’re headed. We started with environment management and it was made available on the 18th of January and it’s already in the market, so we’re excited about it.

    Shimel: So no pun intended, but where can we get a quick start on this Quick Start? [Laughs] Where can we go, Bob? 

    Davis: Well, we have, there are online demos. You know, there are all kinds of spots on our website. We have a spot where you can say “Talk to me and you can sign up for that and have it by the end of the month.”

    Shimel: So just go to Plutra.com and check out the stuff for Quick Starts. 

    Davis: Yep. There’s a banner right on the top of the home page that will take you right to the information on it.

    Shimel: Love it. Good stuff.

    Davis: Yep. It’s all right there.

    Shimel: Hey, Bob, we’re about of time. I want to thank you for coming on and telling us about the Plutora Quick Start program. You know, the first one, as you mentioned, came out the 18th. Any timeframe on subsequent quick starts?

    Davis: We’re going to bring out the next one in the beginning of the next quarter, so right around April. 

    Shimel: Excellent, man.

    Davis: So you heard it here first, Alan. 

    Shimel: Well, that’s why we’re here. Thank you for letting us know. We’ll be watching. Good luck with this one. Maybe we’ll see you show up on one of the Plutora webinar workshops that you guys do with us so often. Love to have that.

    Davis: We’re going to do that.

    Shimel: Cool stuff. All right. Bob Davis, CMO Plutora here on Tech Strong TV. We’re going to take a break right now. We’ll be right back with our next guest. 

  • NewOps? AIOps? NoOps? Just Don’t Call Me Late for Dinner

    NewOps? AIOps? NoOps? Just Don’t Call Me Late for Dinner

    Once again, we are seeing an uptick in the use of the term NoOps. I always felt that NoOps was a misleading and, in fact, empty phrase. I don’t care what magic you think you have; you are never going to eliminate the need to operate your software, applications and infrastructure.

    I first heard the term NoOps early in the maturation curve of DevOps. Back then, the idea seemed to be that Dev was going to absorb Ops. Between that and the cloud, there really wasn’t a role for traditional Ops to deploy. Managing apps would be easy with the cloud and automation. At least, that was the pie-in-the-sky thinking—but I never bought that.  

    There were other terms that popped up, like NewOps and AIOps, though that became something else entirely. But really, I think the rise of the systems reliability engineer (SRE) role put the NoOps movement in its grave (where it probably belonged). SRE became the shiny new identity of the Ops crowd and SRE continues to be one of the most popular topics here on devopsy.kinsta.cloud.

    This latest incarnation of NoOps seems to be a little different. From what I have seen, it is not really NoOps; instead, it is more of a “not your Ops to worry about” movement. It is shifting who is responsible for Ops from the company developing and using the apps to a service provider (or SaaS provider) who is responsible for Ops. It is more a “MyOps” not “YourOps” movement, but there is still most certainly an Ops there.

    In my neighborhood growing up, we used to have a saying, “I don’t care what you call me, just don’t call me late for dinner.”  Originally, to me, NoOps was very much like that. We changed the name of something, but it didn’t go away or fundamentally change the thing itself.

    Now, we still have Ops, it is just a question of who is doing it. That is not NoOps to me. It is “somebody is doing MyOps for me.” 

    We saw a similar pattern in security. The idea of outsourcing security was never called “NoSec,” because the idea of no security is, frankly, downright scary. Instead, it just meant relying on a cloud vendor or an MSSP to handle your security for you; it was outsourcing your security. An important lesson learned from that was that you can outsource your security ops, but you can’t escape your security responsibility. That is to say, when your customers’ information is breached, saying “We had someone doing this for us!” did not absolve you of responsibility.

    The same thing holds true for this new “OutsourceOps.” The outsourcer may do a better job than you at Ops. They may give you SLAs and SLOs that give you reasonable expectations of performance and remedies if those SLAs and SLOs are not met. But it is still your company’s name and reputation on the line.

    So is what we seeing as NoOps really NoOps? No, it is Outsourced Ops. But as we said in the old neighborhood, I don’t care what you call it, just don’t call it late for dinner.

  • Techstrong TV: Styra Declarative Authorization Service

    Techstrong TV: Styra Declarative Authorization Service

    Styra’s new launch of Styra Declarative Authorization Service (DAS) for Cloud-Native Entitlements. With this solution, IAM teams can move to cloud-native technologies while still using existing systems-of-record as well as scale to the level that their organization requires. The video is below followed by a transcript of the conversation.

    Alan Shimel: Hello, everyone. Thanks for joining us on another TechStrong TV segment. Oh, I’m happy to have back on TechStrong TV today our friend, Tim Hinrichs, from Styra.

    Hey, Tim, welcome. How are you? 

    Tim Hinrichs: I’m doing great, Alan. Thanks for having me back on.

    Shimel: Yeah, it’s a pleasure to have you here. Tim, we always enjoy actually having the Styra folks on, whether it’s Bill, or you, or anyone else. Of course, Styra is a company that in the cloud native space has really kind of made a name for themselves. But though our audience is a cloud native audience and technical, they may or may not know Styra. They probably maybe have heard of Styra. They probably heard of OPA, but why don’t we kind of make sure everyone’s level set, Tim, and give them a little background?

    Hinrichs: For sure. Yeah, great. So, yeah, what Styra does is we help enterprises by providing them a unified solution to authorization. And so for folks that don’t know and don’t work on authorization every day like I do, just remember that authorization is this problem of controlling what actions that people and maybe software can take within a piece of software.

    So let me give you an example or two here. Every time I log onto my bank online, I can see all my bank accounts, but I may not be able to see my wife’s bank accounts. I may not be able to move money between her bank account and mine, and so that’s an authorization problem. It’s controlling what actions I can take. Can I withdraw money? Can I deposit money? So on and so forth. And so that’s one kind of authorization that we work on at Styra.

    But another good example is sort of at the developer level. So those websites that we all use every day, those are built by developers and developers are also taking action. And so one kind of action that they might want to take is they’re upgrading the software, or they’re deploying a database, or they’re changing some network configurations. Again, all of those are actions and there needs to be authorization controls in place to make sure that the right actions are being taken by the right people at the right time.

    And at Styra, we provide software that helps an organization sort of manage all of those permissions, all of those authorization policies across all those different kinds of decent software.

    Shimel: Excellent. Love it. And we might as well get it out of the way while we’re here, Tim. People who want to get more information on Styra, it’s Styra, S-T-Y-R-A, and it’s styra.com, correct?

    Hinrichs: Absolutely, yeah. Definitely check that one out.

    Shimel: Cool. All right, we’ve gotten that. Oh, you know what else, Tim? We didn’t even tell them about what your position at Styra is. We should give them that, too.

    Hinrichs: For sure, yeah. So my name’s Tim Hinrichs. I’m the CTO and co-founder at Styra and I spend part of my time working on our commercial product offerings, but then I spend the other part of my time on our open source efforts. And one of the things that we do in open source is we started the Open Policy Agent project, or OPA, as we like to call it, and then we donate it to the CNCF. So I’ve got a foot in both of those areas of work.

    Shimel: Love it. Hey, Tim, are you gonna be out at KubeCon in Spain in May, or planning it, not sure yet?

    Hinrichs: Not sure yet, but yeah, it would be great. I’d love to get back out, and start going back on that conference circuit, and seeing people, chatting with them about policy and authorization, and just seeing folks, again. I think it would be great.

    Shimel: We are currently planning on being there. We’re going to hopefully try to do some videos but a different sort of setup. I forgot what they’re calling it, something topist talks or something, so short, little, smaller segments. Again, assuming the world is right, we’ll be there.

    Anyway, but Tim, let’s focus in on what we want to talk about today, which is you guys recently announced a new offering. Tell us.

    Hinrichs: Yeah, for sure. So the new offering that we just released a little while ago, we call it the Entitlements Offering as part of our normal product called the Declarative Authorization Service. And so the idea behind this new offering is that it’s really designed to help organizations take custom applications and migrate them from on-premise data centers into the cloud more effectively, more quickly.

    And so the problem we kind of saw happening over and over was that if you’ve got one of these on-prem applications, especially an application that’s focused around helping your employees interact with each other or the organization as a whole, these employee-focused applications, a lot of those apps are dependent on what folks will call an on-premise entitlement service. So that entitlement service is often backed by LDAP, or Active Directory, or something, and it’s sort of just those applications sort of need to know which groups that employees are a member of in order to sort of grant permissions within the application.

    And so the challenge when you’re mind reading those kinds of applications into the cloud is that the cloud, what you don’t want to be doing is having an application running on the other side of the world and having to make a request all the way back to your on-premise LDAP or AD. The roundtrip time, the availability, the performance and availability, are just too poor. It’s sort of an anti-pattern in the cloud. And so these folks that we’re talking to are struggling because they want to migrate these applications in the cloud, but in order to do that, they also have to migrate those on-prem entitlement services to the cloud.

    And so this new offering from Styra really makes that easy. You sort of just hook it up to your LDAP or AD and then you can deploy that thing in as many cloud regions as you like.

    Shimel: Excellent, excellent. Back at the end of last year, I told our team here and I think we said it on our predictive that I thought IAM was going to be the battleground, the most important thing for us to be focusing on, especially as it relates to cloud native, and security, and stuff like this. Of course, this was before the software supply chain builder management, and the ransomware, and a lot of the stuff that we’ve seen come down.

    But I still believe that IAM is the kind of the soft, white underbelly. It’s where cloud security gets down in a lot of ways, right? You have cloud providers who are investing billions, literally billions of dollars, into their infrastructure and their security, and we count on them to deliver the security to a certain level of that stack. The rest of that stack, through a good chunk of it, is protected by our IAM.

    I mean, I’m not blaming anyone, but just this week, we’ve seen Okta with a problem, and I’m not blaming Okta. Any one of us can be the next Okta, or the next Solar Winds, or the next take your pick. We’re all vulnerable, at some point. But it goes to show you how vulnerable we really are through the IAM stuff.

    Tim, what made you guys kind of go down this path? I mean, obviously with what you do, it was kind of adjacent and it wasn’t out of left field, but what made you say, hey, we need to do this?

    Hinrichs: Yeah, there are a couple of things. You mentioned a whole bunch of things and one in which I want to respond to before I get to your question.

    Shimel: I’m sorry.

    Hinrichs: I think that the recent stuff around Okta was interesting because I think one of the things that should remind all of us of is just this idea that there are two kinds of companies in the world, those that have been compromised and those that don’t know they’ve been compromised, to your point.

    Shimel: Exactly, yeah.

    Hinrichs: And so this thing with Okta just I can highlight this idea that once you sort of understand and sort of internalize this idea that you’re gonna be compromised, the only sort of thing you can do is put defensive in depth in place. And so authentication, proving that you are who you say you are, which single sign-on vendors have done a tremendously good job of, is that first level of defense. But then authorization is that second level where what you want to do is sort of control the amount of damage that is done once one of those user accounts is compromised and that’s the notion of authorization. You limit the amount of permissions that every one of those accounts have.

    And so that’s, to your point, one of the foundational principles of security, that you layer levels of security in place so that when any one of them gets compromised, you have several others to put in place.

    Shimel: Absolutely. We hear the term zero trust getting thrown around and it’s funny, with zero trust, to a lot of people’s idea, I do my single sign on, so now I know Tim is Tim. And now, Tim, here’s the keys to the castle. Have at it. But I think what people miss is with zero trust, is just because Tim is Tim, Tim doesn’t get the keys to the castle. Tim should get just what Tim needs, not what Tim may want. He doesn’t get everything. So if Tim is compromised, I still limited my exposure.

    And, again, to me, that’s really when we start getting into the permutations of zero trust and how we do IAM, it’s so important that we have that. Not everybody’s access is created equal.

    Hinrichs: Right. I totally agree and I think, well, one of the more interesting things that we’ve seen is that part of why I think a lot of folks end up with maybe more permissions than they need is just that these authorization systems today traditionally have been hard to use. Every product, every project, every service on the planet has a unique way of solving authorization.

    So if somebody needs additional permissions for some small period of time and I’m the admin, well, I’ve got to go poke around and figure out how to give them additional permissions and then there’s this back and forth. “Okay, I gave you more permissions. Did that work? No, okay, I’ll give you more permission. Did that work? No.” And at some point, you just say, “Forget it, you’re an admin.”

    [Crosstalk]

    Shimel: You know what? I’ll give you everything.

    Hinrichs: “You’re an admin.” And then what happens is you’re supposed to pull those permissions back a week later, but then you forget because you get busy. And so I think there’s this very real notion of permissions creep where people just have more and more permissions over time. Because everybody’s definitely gonna ask for more permissions when they need them to do their job. Very few people are gonna say, “Oh, you know what? I’ve got too many. I don’t need those, anymore.”

    And so I think one of the things that we do at Styra, by trying to provide a unified solution, a foundational solution for authorization, is help with this. Because we say, look, there’s one collection of tools and technologies you need to learn in order to deal with permissions. If you can apply those to all your 57 different products and services, well, you just are more conversant with being able to give rights correctly and being able to revoke them. And so I think that speaks well to why in part we’re doing what we’re doing at Styra.

    Shimel: Absolutely. So if you don’t mind, Tim, let’s talk a little bit about kind of the business aspect of this new offering. How’s it packaged? How’s it offered? How’s it priced? Is there a free open source version, that kind of thing?

    Hinrichs: Yeah, and maybe I’ll also offer the answer to the question about why did we end up doing this ’cause I didn’t get to that.

    Shimel: Yeah, please.

    Hinrichs: Yeah, so it’s one of these nice things that because we have an active user base in the open source world and because we have active customers on the commercial world, we can just watch what they do all the time and then when we see a pattern emerge where we see the same people having to address the same kinds of authorization problems, then we realize, well, that’s a systemic problem throughout our community and organizations. And so then we can go ahead and put the energy into building a new offering, and that was exactly what happened with this entitlements solution.

    We just saw a number of our open source and commercial customers and users having to solve this problem and using OPA and DAS to do that. And so then we just realized, well, hey, if they’re kind of piece-mealing things together, why don’t we just put forth a real offering around this design specifically to solve this entitlements problem. So that’s how it came about.

    To answer your second question, how’s it packaged, and priced, and all that good stuff. Well, so typically what we do is this is another feature, so to speak, or a solution, or sometimes we call it a use case, for our product, our declarative authorization service. So that declarative authorization service was designed to provide a unified solution to authorization. It helps you with Kubernetes authorization, with microservice authorization service mesh. It helps you with public cloud through terraform, and now entitlements. And so in that sense, it’s yet another feature, so to speak, in the product that exists.

    And so in that sense, if you’re just using DAS, then you can kind of just pick that out of a list and put it in place. DAS is available as a SAS offering so everybody can run it and you can sign up for free, as well, so I definitely suggest if you want to try it out, go log in and do that. We do, for the enterprise version, also offer an on-prem solution. And so if folks want to actually run DAS on prem, it doesn’t have to be on prem. It could be in their private cloud accounts, then they can do that, as well.

    Shimel: Excellent. Once again, proving the old axiom, it’s not a product, it’s a feature, and it’s good when you can have a product, whether people can’t decide, well, it’s a platform, not a product, but you have a product that has multiple features like that that handle this kind of thing.

    Tim, it’s available now? So I assume it’s been beta tested, hardened, gotten the feedback, and it’s ready to rock and roll.

    Hinrichs: Yeah, it’s one of our earlier releases, for sure, but yeah, we definitely want people out there trying it and giving us feedback, for sure.

    Shimel: How do people go sign up and give it a whirl?

    Hinrichs: Yeah, just go to styra.com. There’s a signup link, and then when it drops you into the product, you’ll get to pick from one of several quick starts that help you sort of walk through putting stuff in place, and you can kind of kick the tires.

    Shimel: I love it. Tim, thanks for coming on and telling us about this exciting new feature in the Styra product line. Looking forward to hearing more. I do hope we get to see you at KubeCon in May in Valencia, hopefully, fingers crossed.

    Hinrichs: That would be absolutely fantastic, and thanks. It’s been a pleasure chatting with you, again, Alan.

    Shimel: All right. Say hello to all our friends at Styra. Tim Hinrichs, CTO co-founder at Styra here on TechStrong TV. We’re gonna take a break. We’ll be right back.

  • Techstrong TV: Scratching the Surface of Testing Through AI

    Techstrong TV: Scratching the Surface of Testing Through AI

    Mark, Torsten and Alan discuss the findings of the “Disrupting the Economics of Software Testing Through AI” report. The report identifies critical factors that hinder software engineering and DevOps teams including the escalating costs of quality control, and growing complexity associated with the increasing release velocity, number of smart devices, operating systems, and programming languages. The video and a transcript of the conversation are below.

    Announcer:                 This is Digital Anarchist.

     

    Interviewer:                Hey, everyone. Welcome to another segment here on Techstrong TV. I am really happy to tell you, introduce our guests for this next segment. First of all, he’s a returning guest with us. He’s from our friends at Applitools. It’s Mark Lambert. Hey, Mark. How are you, man?

     

    Interviewee 1:             Fantastic. Thank you, Alan. Great to have you – for you to have me on. Yeah, great to talk to you.

     

    Interviewer:                Absolutely. And then joining Mark and I today is Torsten Volk. Torsten is – I just drew a blank – EMA, right? Enterprise Management Associates?

     

    Interviewee 2:             Yes, exactly.

     

    Interviewer:                Yep. And we were talking off camera. Torsten is actually a friend of our friend, Andi Mann, who he knew or was his predecessor at EMA 11 years ago.

     

    Interviewee 2:             Yeah.

     

    Interviewer:                And, Torsten, welcome to Techstrong TV. It’s great to have you on.

     

    Interviewee 2:             Thank you very much. It’s awesome to be here.

     

    Interviewer:                Thank you. So, guys, look, Applitools, leader in visual testing. We’ve had, beyond Mark we’ve had many Applitools people on over the last almost two years now of doing Techstrong TV, so I think our audience is familiar. But just in case people aren’t, Mark, how about a little quick Applitools backgrounder?

     

    Interviewee 1:             Sure, yeah. So Applitools is known for inventing Visual AI, so helping software development teams accelerate their releases by mimicking the human eye and brain and how we as humans analyze computer screens, highlighting differences and issues within your UI so you can do not only visual testing, but also fundamentally change and modernize your functional test automation. So it’s really the glue that plugs right into your existing practices, so Selenium, Cypress, we support over 50 SDKs. There’s a free account as well, so you can get in there and get going, kind of feel the water, so to speak. But what we’re seeing is that it’s helping leading brands accelerate their digital experiences, and really it ties directly into the research obviously that Torsten’s been doing around AI and how that can help organizations disrupt the economics of software testing.

     

    Interviewer:                Love it. And, Torsten, look, I know EMA from before 2010 even, but for those folks who maybe, you know, a lot of our audience are technical people. They may not necessarily follow the analyst beat. Why don’t you give them a little EMA background?

     

    Interviewee 2:             My boss describes it always as the industry and analyst firm for enterprise grade solutions, and in the beginning – I’ve been here for a while. In the beginning I was always a little bit wondering, you know, what does that really mean? And what it at the end of the day means is we have all of those emerging technologies coming up, especially in the area of artificial intelligence and cloud native applications and intelligent automation, and what we are looking at is really how can we leverage those capabilities within an enterprise setting. So once the dust has settled and we’ve all gorged ourselves, you know, by consuming the leading edge of all of those tools, the question then is how do I expand that footprint of those tools across the enterprise so that the enterprise as a whole is more competitive in the end. So basically projecting those constraints of all of those cool new products and technologies into the enterprise, that is really what EMA is all about. And my specific practice is focused, as you can see in the background here, as one of my research graphics is focused on looking at machine learning, deep learning, reinforcement learning, and how those capabilities can enhance the enterprise.

     

    Interviewer:                I get it. Great use of the background, Torsten. Thank you. All right. So, Mark, we’ve got all that out of the way. Let’s jump into what we really want to talk on today, and I’m gonna let you kick it off if it’s okay.

     

    Interviewee 1:             Yeah, I’d love to. Thank you. So yeah, so recent report from EMA, and Torsten is the author and I’ll kind of throw the ball to him very quickly, obviously, but really talking about how artificial intelligence and machine learning is revolutionizing the software testing space, and is really important right now because there’s so much buzz around AI, machine learning, and kind of where it comes in. You want to understand where does the rubber meet the road? What is impactful today? What’s impactful for the future? And then what’s, what are the drivers that are getting us there? So I mean, Torsten, I’ll turn over to you, and maybe kind of like talk about some of the capabilities that you talk about in the report and the challenges that they, that you’ve seen come into play.

     

    Interviewee 2:             We started that report by looking at the key pain points, like we start almost all of our reports. Right? What is not sustainable anymore in a specific discipline, and in this case it’s test engineering. And we have pressure factors. One of them is that we, the business needs us to release software a lot more often, and in a really granular manner where somebody’s asking for a feature capability and the software development team is expected to release that thing very quickly, ideally in an ongoing manner. So that is one part, and the second part is that the end users are very, have become very much more diverse than they even were in the recent past, where we have multiple charts where we show the escalation of the number of devices with different screens, different processors, a different network connection, different interfaces for your fingers and for voice control. And all of those things make testing much, much more difficult, and one of my favorite parts always is the little war stories that you get told. Right?

    So in the beginning when we look at al the material that we have, we talk to a lot of developers and test engineers and DevOps guys, and my war stories or their war stories always started with, “Oh, yeah, regression testing, Torsten. That is really not doable anymore. This is kind of a dreamland that you are living in as an analyst if you think that we can regression test all of those releases. It’s just too much, and it would take forever to be able to do that.” So if we can’t regression test, we are running a significant risk, Mark, that something goes awry. Right? We always are sure that in theory things should work, but in real life there are combinations of technologies, of code functions, that they then don’t work. And that’s where we start with artificial intelligence and this whole pair of eyes, Mark, that you are describing, right, where you say, “Oh, yeah, my test engineers don’t have to be that pair of eyes that check through dozens of boxes and just say yes, yes, yes, yes, yes everywhere, and then also overlook some things.

    But that pair of eyes is something more. It’s something that has a certain degree of – when I say understanding, I think I’m gonna embarrass myself, but it has a certain degree of ability to comprehend – maybe that’s the same word – but to pick up things of a similar character and to categorize and cluster things in a manner that makes sense for human beings then to review, Mark. Right? And that is –

     

    Interviewee 1:             Yeah.

     

    Interviewee 2:             – where a tool like Applitools is very interesting, and also unique in the marketplace, right, where it’s a pair of eyes that you guys are building.

     

    Interviewee 1:             Yeah, and I think that talks – I mean your research touches on several different areas where AI comes in, and visual inspection, which is obviously where Applitools fits, is really a highly impactful and the most impactful today of those techniques because it does so many different things. So first of all, obviously there’s the streamlining of the manual review effort. Right? So I’ve got this explosion of devices. How do I check them all? Well, because of the high level of accuracy of Applitools Visual AI, and it’s been trained on over a billion images and has got four nines of accuracy, so what that means is as a human I don’t have to review tens or hundreds of screenshots. I’m just focused in on a very small subset. But that’s just the first part of it, because then you layer on top of that and this explosion of release velocity, increasing device combinations, and as well as the, just the complexity of the application and so many things out of your control, you need help in reviewing the volumes of data and really saying, okay, all of these things kind of look like the same.

    So and then bringing them together. I talk about basically sorting your visual review into different stacks of paper, so for example I might have 76 screens that have a visual defect, but I can break those down into two categories of 40 and 36. And those types of techniques go beyond just the basic pixel dipping approach, which is the one that would be a traditional visual testing technology, and really the ability to categorize that you talk about, Torsten, is the key driver that, or the key foundation that all of these things get built on top of. So it’s a really powerful technique, and as I said earlier plugs right into existing, so you don’t have to rip and replace. That’s one of the things that a lot of AI technology today is say, okay, it’s great, but you have to build it all new in this track. The thing that is really powerful with Applitools is we plug right into your existing frameworks, open source as well as third-party commercial tools, and then we elevate the process with the dashboard to really enable cross-team collaboration. So it’s not just your testers or your test automation or developers that are engaged. Your domain experts, even other parts of the team like UI, UX design, for example, get to be involved in that collaboration process.

     

    Interviewee 2:             Yes, and we see often that communication is key, and it’s not happening in testing where we have those more and more decentralized product teams that are doing their own thing with their own toolkits and pipelines, but they’re not really benefiting from what other teams are finding. And so coming back to that horrible list approach, right, where you have, you check those boxes or you don’t check them. Right? So it’s a very monotonous affair as a human being to review this, but then once you’ve reviewed it usually it comes back to you again and again, and then it comes back and hits other people in that organization because there is no communication and there’s no unified platform to retain that knowledge. Right? And with reinforcement learning, you can teach the system what it needs to come back to a human with, and then what it shouldn’t. So if one team makes decisions, all the other teams are benefiting from that and it’s less and less of this toil type of task where you just also as a human tend to make mistakes and it’s just not scalable. Right? So that whole scalability aspect is an interesting one that deep learning and reinforcement learning brings us there, Mark.

     

    Interviewee 1:             Yeah, you hit on the key things. Right? You’re scaling to meet the current demands of release velocity, shorter release cycles. But the other thing I always think about when I think about AI machine learning and how it can help us from a software quality perspective, it’s an assistive technology so you’re reducing or removing mundane and repetitive tasks, which in themselves are error prone. Humans are great at creative work. We’re terrible at boring, monotonous things  because we miss stuff. Whereas leveraging AI, and especially Applitools Visual AI, it’s highlighting those things. So that same example I talked about, 76 screens, you’re gonna miss stuff. If you’re looking at them all and you’re like, oh, it’s the same. It’s the same. It’s the same. But the Visual AI will identify key differences between the 76 images to really kind of like focus and improve the efforts.

     

    Interviewee 2:             Yeah. And that gets even when you look a little bit into the future, Mark. I know that you can’t share roadmap items, but that whole idea of having a Visual AI can go even beyond just user interface testing, right, where you can do sanity checks in certain areas, where you say, “Oh, yeah, no, that number can never be a billion because of what I know about the data in the background.” Right? And a lot of the things that come through that we continuously see coming through when you release and then you don’t want to be the one in the test team to hold off a, to hold back a release in the middle of the night.

    It’s funny that when I was young and had a ton of hair still, that was what happened, and it’s still happening today just as much, right, where people think, “Oh, no. I shouldn’t be the one who says that. I think it’s all fine. Let’s sign off on that.” Right? So the release data kind of getting mushy and mushy and mushier in those areas, and that ability to say, “Oh, yeah, I had somebody look over it, and something horrible had happened,” some compliance violation or some crazy numbers in the shopping cart that can never add up. Can be even simple things where it’s, oh, this cost a billion dollars, or it’s euros instead of dollars but we are in a certain country. Those are things that you can catch more and more.

     

    Interviewer:                Fair. Guys, I feel like you didn’t let me, I didn’t get much of any words in here –

     

    Interviewee 1:             We feel the same way.

     

    Interviewer:                – but it’s okay. You know, I would – but I try to be a good host and let the guests talk, and you guys had it. Right? This is something, Torsten, you’re obviously very, very passionate and involved in and, Mark, it’s kind of, it’s your life. Right? And so I let it go. However, we are just about out of time, believe it or not, and we went on here for 15-plus minutes on this. But –

     

    Interviewee 1:             Can I just let people know where they can get the report? Would that –

     

    Interviewer:                That’s what I was going to ask you.

     

    Interviewee 1:             Sorry, I just wanted to make – yeah. So –

     

    Interviewer:                Go ahead.

     

    Interviewee 1:             – yeah, go to applitools.com/ema and you’ll be able to download the full report and access all the information there. So yeah, thank you, Alan.

     

    Interviewer:                Thank you, Mark. So it’s applitools.com/ema.

     

    Interviewee 1:             Yes.

     

    Interviewer:                Which also happens to be where Torsten works, at EMA, Enterprise Management Associates. Guys, it sounds like it was a really worthwhile research project here with some really good results and really good findings and insights. Look, this whole, there’s a reason Applitools has been as successful as it has. The whole idea of AI and testing is like peanut butter and chocolate in some way, and we can – but we barely scratched the surface in a lot of ways, right? There’s so much more yet to be done, and looking forward to hearing more about it in the future.

     

    Interviewee 1:             Yeah.

     

    Interviewer:                All right.

     

    Interviewee 1:             Thank you, Alan. Look forward to talking again soon.

     

    Interviewee 2:             Thank you.

     

    Interviewer:                All righty. Excellent. Torsten Volk, EMA, of course Mark Lambert from Applitools here on Techstrong TV. We’re gonna take a break and we’ll be right back with our next guest.

     

    [End of Audio]

  • Cloud-Native: It’s One Thing

    Cloud-Native: It’s One Thing

    This Wednesday, August 10, 2022, starting at 9:00 a.m. ET, Techstrong Group is hosting an awesome virtual conference: CloudNativeDay. I am sure most of you already know a lot about the many cloud-native solutions out there; are familiar with the great work the Cloud Native Computing Foundation (CNCF) does and that you have Kubernetes clusters running in your environments. But for me, at first, the interest and enthusiasm people showed for anything and everything cloud-native defied my understanding.

    We do about one virtual conference a month here at Techstrong Group. That may sound like a lot, but when you divide it up among topics in DevOps, cybersecurity, cloud-native and digital transformation and then further segment who in an organization is targeted by those events, it doesn’t give us a lot of room to dive as deeply into some topics as we would like. We pick the topics of our virtual events carefully and we depend on feedback from you, our audience, to guide us.

    Tim Hockin, Principal Software Engineer: Kubernetes, GKE, Anthos at Google

    This is the fourth year we are producing a cloud-native virtual event, so the topic has obviously resonated with many of you. But it wasn’t until this past year that I had the “Eureka!” moment and realized why.  You see, to discover the reason why cloud-native was so popular, I looked in the usual spots: Software, applications and solutions. I felt confident that Kubernetes’ popularity was one of the reasons cloud-native was so popular. Over the last 24 months, observability burst on the scene. Maybe that was driving the continued popularity of cloud-native. Heck, the CNCF has over 40 projects; perhaps the sheer quantity is what makes cloud-native so popular. But none of that felt exactly right—yes, all of these things drive cloud-native’s popularity. But they aren’t the key driver.

    Once again this year, I had the pleasure of recording a fireside chat with Tim Hockin. If you don’t know him, Tim is a principal software engineer at Google and an original member of the team that brought Kubernetes out from Borg (if you don’t know Borg, then you need to learn some cloud-native history). This is the fourth year we have Tim keynoting this virtual conference, and chatting with him is always a highlight of the event for me.

    Tim said something in our conversation this year that finally made it click for me. Suddenly, I had found it. The “one thing”, in the immortal words of Curly from the movie City Slickers.

     

    You see, the secret to cloud-native isn’t how great and powerful Kubernetes is; it’s not what observability or service mesh or any of those great cloud-native or CNCF-developed software tools can do for you. Cloud-native is a state of mind. As much as it is about software, it is also a state of mind. Cloud-native is about building powerful, applications at scale using the entire ecosystem that was created as a result of that state of mind.

    Sound a little too zen for you? Well, I hope to change that thinking. You do not want to miss my conversation with Tim Hockin that kicks off our show this year. We’ll discuss the belief and help you understand why cloud-native is a state of mind. And, while you’re listening, Tim and I also talk about what is new in fleet and multi-cluster Kubernetes.

    The entire virtual event program is chock full of great sessions. Head over to the event site and see for yourself. Panel discussions, speakers, demos. Great exhibitor booths you can visit and ask questions. Games, prizes, a DJ, a mixologist and more. We can’t wait to see you there!

    And if you remember anything from the event, let it be this one thing: Cloud-native is a state of mind.

  • Developer-led Landscape & 2022 Outlook

    Developer-led Landscape & 2022 Outlook

    Tyler leads the firm’s developer-focused investments and publishes the industry’s most comprehensive market landscape each year. He discusses the developer-led landscape and the 2022 Outlook. The video is above and a transcript of the conversation is below.

    Interviewer:                This is Digital Anarchist.

    Hey, everyone. Welcome to another Techstrong TV segment. I’ve got a first-time guest on Techstrong with us, but he’s a guy, you know, a gentleman who has his kind of finger on the pulse of what’s happening. I want to introduce you to Tyler Jewell. Hey, Tyler, how are you?

     

    Interviewee:                Ah, good morning, Alan. It’s good to be here.

     

    Interviewer:                Cool. Tyler, you know, I said you have your finger on the pulse, but I purposely didn’t give your whole title, affiliation, background, ’cause I was kind of saving it for you. Why don’t you introduce yourself to the audience.

     

    Interviewee:                Oh, I’m happy to do so. So, Tyler Jewell; I am a managing director at Dell Technologies Capital, which is the VC arm of Dell Technologies. We invest about $300 million a year across disruptive companies in the datacenter and enterprise space. You know, previously, I spent 25 years as a product operator and software executive in developer tools companies, including at Stenset, Red Hat, Oracle, and being a CEO of three different startups that have all gone pretty well. And I’ve been an investor, as an angel and VC, for 15 years, across 15 different companies, again, in the developer tools and developer landscape. And starting in 2009, I built a database around companies that make products for developers, and I published it online in 2019, and it now has 1,100 companies in it.

     

    Interviewer:                That’s fantastic. And what is that database, by the way?

     

    Interviewee:                We call it the Developer-Led Landscape, and, you know, we show you the trends in which segments are happening in the developer tool space, which products are gaining steam, which ones are losing steam, and, you know, general insights about how the market is shifting and evolving.

     

    Interviewer:                I love it. What’s the URL? If you don’t mind [crosstalk].

     

    Interviewee:                Oh, it’s at my Substack, so tylerjewell.substack.com.

     

    Interviewer:                Excellent, and that’s a great resource – people should check it out. So, you know, it was interesting, Tyler, I spoke to a few CEOs, already, this week, and a common thing – and a few VCs, I might add. And a common thing I’m hearing is, are we seeing a change in the market conditions, right before our very eyes? One of the large, you know, public PE firms or – you know, we live in a world, today, where the distinction between VC and PE is increasingly blurring, right? It used to be very clear what was a VC and what’s a PE, but one of the large VC/PE firms, look, they took a big hit, this week, on their stock price, right? What effect is that gonna have? Is that gonna put a chill?

    By the same token, Tyler, last week, I interviewed four startup CEOs who all raised $150 million or better, and achieved unicorn status, right. So, it was the best of times, it’s the worst of times, right? [Laughs] I don’t know, look, if I knew, I wouldn’t be sitting here, I’d be off on some, you know, South-Pacific island or something. But, you know, where are we headed? What’s going on? Are we seeing a changing of the landscape? Is it to be expected, an evolution? What’s your take?

     

    Interviewee:                Well, you know, let’s deal with some hard math, to begin with. First, there’s well over 900 companies that have achieved a unicorn status on paper. But when you look at the past year, there was only a handful of companies that were able to get an IPO, in a year, arguably, where the demand for IPOs has been one of the hottest in a long time. And, you know, and then when you look at the global PE market, again, there’s only about appetite for maybe a dozen PE acquisitions in that unicorn range. So, you know, if you’ve got a hot market and 30 companies can get liquidity, really, either through a strategic buyer, an IPO process, or private equity, and you’ve got 900 companies at that valuation range, you’ve got a 20- to 30-year backlog for all those companies to get their liquidity. Or, you know, you’re gonna have, potentially, a correction if those companies need to raise some more cash.

    Now, the flipside of this is that there’s a tremendous amount of cash on the sidelines. Most of these VC funds, private equity funds, have recently raised significant amounts of money; their goal is to deploy that money. They oftentimes have deadlines by which they can deploy that money, and so, there is, you know, a valuation and sensitivity that comes from those companies that, you know, need to deploy the money into what they perceive to be high-quality companies or early-disruptive companies. Now, what we do at Delta Capital, you know, we think of ourselves as early-stage venture capitalists, you know, seed through Series B is our first check-in, and, you know, for us, it really matters that is it gonna be a high-quality team, is it gonna be an emerging and important market, is the product heavily differentiated.

    And in that situation, I think we’ll be a little bit less – we are more valuation-sensitive, meaning, you know, we’re not gonna be as insensitive as some of the others who have a large amount of money to deploy. ‘Cause we don’t have any minimums, you know, so we have the ability to look for quality deals and to, you know, pay what is appropriate given the market conditions that are out there.

     

    Interviewer:                Yep, agreed, you know, I don’t disagree with, frankly, anything you said. You know, but when one hears that number of 900 unicorns in a market of 30, you really get to see, you know, it takes me back to when I first started doing startups in the venture world, right, where, look, nine out of ten venture-backed startups, or eight-and-a-half out of ten, you know, didn’t succeed. They were lucky to get some of their money back, right? [Crosstalk]

     

    Interviewee:                Well, I mean, venture is definitely a boom-and-bust cycle, you know, when you’ve looked at the history of it over the past, you know, it’s been 35 years that we’ve now got a venture capital out there. And taking it back down, you know, to more narrow, what happened in the developer landscape, you know, we were speculating on the potential that we’ve hit peak dev ops as a market condition here. And one of the datapoints that we cited is, last year, in the 1,100 companies that we track, which just, you know, make products for developers, they had, collectively raised $16 billion, last year, across all those companies. And at the same time, that same cohort only had $35 billion in liquidity.

    Now, you could sit there and go, “Okay, well, $35 billion out is better than 19, you know, the $16 billion in,” but really, that number should’ve been 5 times larger, if these things were in balance. You know, that $16 billion maybe purchased, you know, 10 to 15 percent of those companies. And in that $35 billion in liquidity, that was only a handful of IPOs, and the rest was, you know, like, 23 of that 35 was from IPOs, and the rest were from acquisitions. And a lot of those IPOs have been underwater, now, at the beginning of this year, right? So that $35 billion number might actually be a lot closer to 17, at this point in time.

    So, you know, the math just doesn’t add up; something’s gonna have to give at some point in time. You know, that’s certainly one factor. The other factor, you know, facing the developer landscape in particular, when you _____ _____ _____ companies, is that it’s just gotten really complicated to build software, over the past two decades. And, you know, it’s a confluence of a number of factors that are out there. One, you know, the wage growth for software engineers hasn’t grown as fast as the demand for software. It’s pretty remarkable, you hear about all these software engineers who are supposedly making a lot of money, but when you look at the Bureau of Labor Statistics, you know, from the federal government, on what engineers make, it’s been a pretty steady four or five percent linear increase, for the past two decades, on that, and it really hasn’t changed much.

    And as a result of that, there’s been a pretty linear increase in the number of engineers available to work. So, programs aren’t spitting out more talent, companies generally aren’t hiring more talent. So there’s a disconnect between the demand for software, which has been, arguably, on a logarithmic exponential curve, and the supply of people who can do it, right, which is [crosstalk] on that front. So the intersection of this is, “Hey, let’s have a bunch of tools. Let’s have 1,100 tool company out there, to try to help with the productivity of all this.” And as a result of that, we’ve created an ecosystem and an industry that’s really complicated. You know, agile processes are complicated, microservice architectures are complicated, cloud, cybersecurity, you know, huge surface area of attack. And then you’ve got a talent population with only linear wage growth, and this is gonna be an issue, here, this is not sustainable.

     

    Interviewer:                So I gotta play devil’s advocate, if you don’t mind.

     

    Interviewee:                Be the devil, that’s okay, I’ll be the angel.

     

    Interviewer:                [Laughs] Right? It’s a good role. So, number one, I think things have grown more complex, and I think, you know, that is due to an evolution, you know, the continuing development of this whole software development universe we live in, things tend – you know, as you build more things on top of more things, I don’t know if they necessarily get simpler. I think they do get more complex. I also think that the needs of the – the requirements put on the applications that we’re developing, the requirements for what we need this software to do have grown exponentially. And so, as a result, that’s part of that complexity, too. But certainly, developing an application on a microservices architecture deployed via Kubernetes and the cloud is, you know, when we talk about things that are hyper-scalable, right, there’s sort of the mainframe stuff, which is very hyper-scalable, right, probably the most, one can argue, you know, penny for penny, dollar for dollar.

    And then, you know, the scalability offered by these architectures, you know, and you can get into the thing that it’s only the unicorn, you know – I mean the real unicorns: Google, Facebook, Twitter – that need that really hyperscale, right, there’s a handful. But clearly, these are the architectures that do that. And in terms of the amount of developers, I mean, look, unless GitHub is blowing smoke up everyone’s butt, you know, they – something, I think it’s almost, like, 50 million GitHub accounts, today, that developers, if they were a separate country, would be the fastest-growing country on earth. You know, not just US, obviously, you know, I’m talking about global. And then, in terms of compensation, look, I’m not a big believer that the Great Resignation is due to the money being paid to software developers, or cybersecurity people, or dev ops folks, or what have you.

    But I know enough of those people to know they’re making good livings, Tyler. You know, my friends who are CTOs and VP of engineerings are paying good software developers a quarter-of-a-million dollars, and more, and more. And not just those guys in Silicon Valley. New York, Boston, Austin, down here in Miami – you know, we’re in Boca, but –

     

    Interviewee:                There is, you know – you know, first of all, I think GitHub has something like 78 million repos now, right, [crosstalk] probably even claiming 50 million accounts. You know, but there is a massive disconnect between the data that Microsoft and GitHub gets to report and what the BLS statistics, you know, share, right. Which is, you know, the indication of people who are professionally paid, you know, who give themselves some sort of software engineering title.

     

    Interviewer:                But maybe the proliferation of titles says something – I know, Tyler, in our mailing list, you know, we try to mail based on title, sometimes. If I showed you the titles people have, it’s crazy.

     

    Interviewee:                Yeah, you know, look, there could be some title proliferation, but the BLS doesn’t let proliferation, you know, proliferate. And also, it doesn’t reflect international trends, as well. But just in general, when, you know, there’s a lot of struggles and there’s a big gap that exists between people who are professionally paid as talent workers to create software, you know, versus an even larger population of people who aren’t, you know, who have software development skills. And they may contribute to opensource and they may contribute to GitHub, or they may even contribute to some project, you know, but they’re not being compensated for the work that they’re doing, and, you know, they’re doing it for some other motivations, right. So that can explain a huge portion of the disconnect.

    But generally, you know, the software that’s produced to satisfy the demand of consumers, right, or businesses on that, it’s usually gonna be a team, that’s under compensation. Because sustainability of that software, maintainability of that, holding against the SLAs, you can’t depend upon people who are not under contract with you to achieve that. You know, and generally the case, yeah, I think that, you know, a lot of software has gotten so complicated, and the media has definitely portrayed a lot of people who have got, you know, outsized compensation, you know, because maybe they have a unique type of software engineering skillset, or they’ve, you know, risen to some sort of CTO or VP of management position. And I think those stories are gonna continue to persist.

    But when you look at the data in aggregate, you know, for people who identify as some sort of quality assurance engineer or a software engineer or a cyber _____ professional, the aggregate data across the United States hasn’t, you know, been on the same curve as what the storylines would suggest on that. And –

     

    Interviewer:                Yeah, but, you know, to be first-world, you know, first-world problems, let’s be clear, for my audience out there, our audience is developers and engineers and so forth. But when you go down the block to your neighbors and you say, “Woe is me, I’m only making a buck-and-a-half a year, you know, as a cybersecurity admin,” or something like that, and the guy next to you is doing something physical and, you know, making $75,000.00 a year, you gotta be careful, you know?

     

    Interviewee:                Look, I think we’re putting the spotlight on the wrong thing, right. I think the bigger spotlight, here, is that there is a $50 billion revenue industry around the dev tools, right? So those 1,100 companies that we track, they generate $50 billion of revenue a year. That’s going up 23 percent, year over year. That’s $10 billion increasing, a year. And I look at most of that revenue, most of those sales, as companies who are trying to provide forms of automation to compensate for the fact that the global size of the professional engineering pool isn’t large enough, right? Now, you know, and this market has gotten _____ fragmented. You know, 5 years ago, there was only half, there was only 550 companies.

    So, you know, that market’s a lot more fragmented, there’s a lot more competitors, that’s adding to the confusion and the issues that are plaguing productivity and the engineers. Now, on the flipside of it, you know, I would also argue that we’re not doing nearly enough on advocacy, in that we should have three to four times as many professionals working in the software space. And there’s a lot of reasons why people are unable to become professionals in the software space, as well. It has to do with STEM education, there’s misogynistic and discriminatory behaviors that keep people out of the space. It’s also the complexity of the technology; there’s still a high degree of math and science that tends to be required.

    And those things are also acting as barriers, here. And so, the flipside of this is, that’s why we have this $50 billion industry, this cottage industry, around trying to make people more productive, because we’re compensating for the fact that there’s just not enough people, and we’re not doing enough to get more people into the industry.

     

    Interviewer:                I don’t disagree wholeheartedly, there. Here’s my take on it, though. There’s two ways of approaching the issue of we need everything – every company’s a software company, right, and we need more software. Either we’re gonna have more people doing software, which is, you know, a big shift, lift and shift, or we gotta, you know, to paraphrase Matt Damon _____ _____, we gotta automate the you-know-what out of it, right? Probably, we need to do both, right? But I would say, also, when you look at – let’s take opensource software, right? You and I have both been around a long time. I remember, you know, talking to doomers at army bases who told me that they were never gonna – you know, they don’t allow opensource software onto the network.

    I’ve been in enterprises where I was told that. Today, 90-plus percent of enterprises are probably running opensource, you know, somewhere in the network. But more than just, like, running Linux or something like that, so many of the components of today’s software are, you know, opensource-based. And you’re right, there’s not a professional opensource – well, maybe there is – is there a professional opensource engineer community today? Is it enough to support it? I mean, I don’t know.

     

    Interviewee:                You know, look, are there individuals who can just be professional opensource contributors and make a living off that? In some pockets, there are, particularly the people who focus on identifying bugs and security vulnerabilities, you know, [crosstalk] a different thing.

     

    Interviewer:                Yeah, that’s a subset. No, but I’m thinking, like, Tyler, look at CNCF, for instance, [crosstalk] Linus Foundation.

     

    Interviewee:                Yeah, but almost of that is professionally paid people, and anybody who, you know, works on a major project, even if you do it for free, at some point in time, there’s probably gonna be a commercial entity supporting that. And that commercial entity is gonna wanna hire the top contributors to that project, right? So there is, effectively, a professional path, you know. Now, whether that individual does not wanna be associated with the commercial entity, that’s more of a, you know, societal or a personal issue that they deal with, there. But, you know, but back to the complexity thing, you know, and a little story, here, for you, you know, it’s great that we – you know, 20 years ago, only 15 percent of software was opensource, right, 85 percent of what was built was coded, 15 percent was composed.

    Now, the statistics show that 85 percent is composed and 15 percent is just, you know, the glue layer that pulls it all together, so it’s a wonderful thing. But, and you talked about that trend of, like, “I’ll never have opensource in my environment,” but the natural conclusion of all this complexity is that we – you know, we are of the mindset that there’s gonna be a bit of a crumbling of the dev ops market as a whole. Because the software process and the architecture has generally gotten to be too complex for a human to reason about the impact of a change. There’s too many moving parts, right? It’s like asking somebody, “What will happen if I walk up to this ant hole and I stick this stick into it? What will occur?” you know, you just can’t predict it, right?

    And so, the only way to reason about that complexity of change is that you have to give it to a machine. You know, machines have the ability to reason about those sorts of changes. So the natural evolution of – and the last thing I’ll say with that, too, on the complexity front is that the prevailing paradigm for how software teams should be organized, for the past 20 years, has been agile. And the fundamental premise of agile is that quick changes and quick feedback make for a happier team and happier end users, right? Well, if you take that to its natural conclusion, you know, you’re making changes all the time, you’re getting feedback all the time, which in theory, you know, gets everybody to be happy. But what ends up happening is that the team gets burnout, _____ _____ gets overload, and then, you know, it turns into this frenetic energy that is not sustainable.

    So, agile is a fundamental part of the program, you know, that we’re gonna lead up to. And instead, we need to focus on a way to have sustainability of the development team, and that we remove the complexity by focusing on machines who do the automation for us. And so, I think that what will happen is, much the way that, in the industrialization, you know, we turned an agricultural society into a machine society, the same thing in the software industry is that we’ll go through a software industrialization, where most of the engineers who are writing code, i.e. they’re farmers of code on that, will turn into orchestrators of machines on that. And so, we’ll have to step back, as an industry, and we’ll be programming bots who will actually write the code, make the changes, give us the feedback.

    And that means, you know, machine learning throughout this whole industry. And then, you know, retooling the software engineering community as we understand it, to become orchestrators of the system, as opposed to, you know, farmers of the code.

     

    Interviewer:                You know, it’s funny, I remember speaking to Luke Kanies. Luke is the cofounder of Puppet. He said there’ll be a day when software writes its own software, but he thought it was 25 years ago, and that was maybe 5 to 8 years ago. Tyler, we gotta run, but here’s what I’d like to do, ’cause this topic needs a wider playing field to play on, and we need more opinions. We do a video show called Dev Ops Unbound. It’s 45 minutes to an hour. We put together a panel of people, anything related to dev ops is fair game. If you don’t mind, I’m gonna have our people reach out to you. Let’s get you onto Dev Ops Unbound. I’d like to get some proponents, opponents, let’s really kick this around.

     

    Interviewee:                Sure.

     

    Interviewer:                ‘Cause I feel terrible we don’t have enough time to really dig into this the way I’d love to, but I think we got people in the waiting room. [Crosstalk], hey, for people who maybe didn’t catch the beginning of this, where was your repository of the dev tools [crosstalk]?

     

    Interviewee:                It’s at my Substack, so tylerjewell.substack.com. You see the Developer-Led Landscape, there. And also, you know, we’re active investors in this space, you know, come check us out at Dell Tech Capital.

     

    Interviewer:                Yup, and Tyler Jewell, for those who wanna know, T-Y-L-E-R, obviously, J-E-W-E-L-L.substack.com. Go check that out. Tyler, we’ll be in touch with you. Let’s continue this conversation.

     

    Interviewee:                Yeah, see you later, Alan. Thanks for having me.

     

    Interviewer:                Thank you. A pleasure. Tyler Jewell, Dell Technology Ventures, here on Techstrong TV. We’ll be right back.

     

    [End of Audio]

  • Techstrong TV: The Future of Cloud Security

    Techstrong TV: The Future of Cloud Security

     

    Check Point Software has announced the acquisition of Spectral, an Israeli start up specialized in automated code security. This further reinforces Check Point’s commitment to cloud security. The video is above and a transcript of the conversation is below.

     

    Interviewer:                Hey everyone, welcome to another segment here on Techstrong TV. I’m really happy to have as our guest on this segment TJ Gonen, and hoping I pronounce that right, from Check Point. Hey TJ, welcome to Techstrong TV.

     

    Interviewee:                Yeah, and thank you very much for having us.

     

    Interviewer:                It’s a pleasure. Is that the right way to pronounce your name?

     

    Interviewee:                No, Gonen is the right way. Yeah. TJ is the name that they changed so no one butchers it.

     

    Interviewer:                Well I hear you. It happens sometimes. Hey I really, as I mentioned to you earlier I like the 49ers, especially in a week where they had a tough game. LA, the Rams are going to the Super Bowl in LA and still it’s close.

     

    Interviewee:                Yeah, they almost made it, almost made it.

     

    Interviewer:                It was close, a lot closer than my team, so who am I to say anything. But yeah I know, good for them. Anyway we didn’t bring you on to talk football unfortunately.

     

    Interviewee:                Of course.

     

    Interviewer:                We’re going to talk security, and maybe that’s better off anyway. TJ, why don’t we start though. Why don’t you kind of give our audience a little bit of who you are, a little introduction. What you do at Check Point, stuff like t hat.

     

    Interviewee:                Yeah, sure. So TJ, originally from Israel. That’s a little bit of the accent, now in the US. I am the Vice President for Call Security at Check Point. So I run the Call Security business for Check Point, and been with Check Point for two years. Actually exactly two years since my company was acquired by Check Point a couple of years ago in the cloud security space.

     

    Interviewer:                Yeah, what company was that?

     

    Interviewee:                So we need to talk about another acquisition so it’s an interesting time.

     

    Interviewer:                Well it’s the circle of life. Right?

     

    Interviewee:                Yeah.

     

    Interviewer:                What was the company that was acquired two years ago, your company?

     

    Interviewee:                Ortega Labs. We were in the servalice security space, yeah.

     

    Interviewer:                Absolutely, and of course servalice is a huge, huge kind of growth area right now. But that was two years ago, as you said TJ, and congratulations to you on that. But we have a new Check Point act, so it’s the way of the world. We have a new Check Point acquisition to announce or talk about today. Why don’t you share with our audience a little bit?

     

    Interviewee:                Yeah, so we just a few days ago we announced the acquisition of a company called Spectral in the code security space, and it’s really our move into the developer first security world, and we’ve been very busy in the code security space for the last four years, Check Point through a series of acquisitions.

     

    Actually to call security business at Check Point started with one acquisition, a company called o9 ______ _____ ______ [crosstalk].

     

    Interviewer:                Sure. I know that 09, who was the founder of o9? Not _______.

     

    Interviewee:                Zor.

     

    Interviewer:                Zor. Yeah, I knew him when he started o9.

     

    Interviewee:                There you go, yeah. So awesome company. So that sort of started the journey, then a few acquisitions later including my company and now Spectral, that’s the fifth acquisition we’re actually doing in the code security space.

     

    So I think one of the things that we found out relatively early is that cloud security is almost trying to reinvent all of security. Reinvent it for the cloud and trying to do 30 years of security in 4 years, and it’s very hard to move without acquisitions.

     

    Interviewer:                Yes it is, and look, quite frankly my background is security, so I’ve been in security 25 plus years.

     

    Interviewee:                Yeah.  

     

    Interviewer:                It’s the reason I started devopsy.kinsta.cloud. It’s the reason I got so attracted to the whole DevOps thing, which was I really felt like it was a fresh chance for us to kind of right some past wrongs. Right?

     

    Interviewee:                Right. Yeah.

     

    Interviewer:                A new beginning, if you will. Now it’s funny, I remember in 2005 or from the first time I heard the term cloud security. The Cloud Security Alliance and Chris Hoff and a bunch of folks at RSI were doing a meeting. And back then we found that cloud security is very sort of one dimensional. Right.

     

    Interviewee:                Mm-mmm.

     

    Interviewer:                And but what we see now is it’s infinite in its variety. There is so many different aspects to securing cloud.

     

    Interviewee:                Very much.

     

    Interviewer:                And it’s important. You know, I was on with I think it was the Palo Alto folks yesterday with their latest cloud, Native Survey. For the first time their respondents, and keep in mind when you’re a hammer everything looks like a nail, TJ. Right? So their respondents are probably people in Cloud Native, because it was a Cloud Native survey.

     

    Interviewee:                Right. Right.

     

    Interviewer:                But they said 50 percent of their infrastructure – at least 50 percent was in the cloud.

     

    Interviewee:                Yeah.

     

    Interviewer:                That’s a big threshold.

     

    Interviewee:                It is a big, yeah.

     

    Interviewer:                Right. When you say okay, half of organizations’ infrastructure is in the cloud today, well cloud security really damn important then.

     

    Interviewee:                Yeah, it is very important. Yeah.

     

    Interviewer:                Yeah, and so it’s part, you know, there is reasons for it to be complicated. This acquisition is a little different than o9 or yours.

     

    Interviewee:                Yeah, it is.

     

    Interviewer:                Why is it different?

     

    Interviewee:                Yeah, so the biggest difference I say is the user, and one of the things that we found out over the last two, three years is there is a few trends that are coming down together. One of them is the shift left turn, which is very clear. That shift left is more of a security initiative. Right.

     

    A security initiative that says hey, if I can fix something, prevent vulnerabilities before they hit the ______ department I should do that. Okay. So now if you want to shift left then you are living – your tools are living inside the pipeline, the development pipeline, and they’re supposed to be suddenly used not by security people, but by developers or DevOps people.

     

    Interviewer:                Yeah, yeah, yeah.

     

    Interviewee:                So these suddenly developed tools that are supposed to be used by people first, not to insure that security is their first priority. That’s number one. Actually it’s probably not their first priority. Even if they care it’s not their first priority. Then number two they just are totally used to different environments.

     

    And you find out that the security company definitely like Check Point that’s been doing security for 30 years and yourself and myself who are older than 10 years old as you can see, at least on my side, is that we know how to develop products for security people.

     

    And to develop  products – security products for developers and DevOps people is just a different genetics. It’s a different DNA.

     

    Interviewer:                No, that it’s a different animal, man.

     

    Interviewee:                It’s a different animal. So we were looking at that and said okay, so one, we think that developer first cloud security is a real thing. I mean it’s very important and it’s going to be a very big part exactly to your point there, of the future of cloud security.

     

    So there is always going to be cloud security – security for security people, which is their own time environment, checking out their actual cloud infrastructure. Making sure that the facts are being blocked and all that good stuff. But when you are talking about developer first cloud security you’re going to have a different type of user. You’re going to need to integrate into different types of tool sets. You need to have different types of genetics.

     

    So that’s what you wanted to sell to Spectral is exactly that. So these guys, you know, I met them first time and I said literally I had a, you know, probably a moment where I said okay, that’s it. These guys just get it. They’ve built a product that developers love. They built a product that developers understand how to use.

     

    Just like the one of their customers told me. They said, you know, I ask him why do you like Spectral compared to the other alternatives like Sneak and maybe a couple of others? And he literally said with Spectral the first time I take the connect to this thing first it took me five minutes.

     

    The second thing, I started to use it, everything was exactly where I expected it to be. And he actually used the metaphor in iPhone, and I totally related to that. Where with IOS everything is you don’t know why, but everything is exactly where you want it to be. You don’t need to think.

     

    So they nailed down the developer experience, and it’s not just the user experience and they integrate with tens of tools right out of the gate. They integrate into the IT environment. It’s also one of the things that we as security people who develop products for security people take for granted that you cannot take for granted in developer world.

     

    I’ll give you just a very simple example. Because we assume we’re selling to security people we assume that they’re going to be okay with us screwing up once in a while. For example, false positives. Something will take a bit more time. It’s okay, because they’re security. That’s their job. I mean they don’t have anything else to do except waiting for you to do your job.

     

    When you are talking with developers and you are going to scan code for example, which is what Spectral does. They started the first was scanning for secrets, hard coded secrets inside code, whether it’s in the I keys and W S keys, fast ______, huge problem. I mean developers who aren’t really fast, they forget keys and secrets inside code. They find an attacker that’s easiest way in.

     

    So now you have tens of repos, hundreds of repos. _______ repositories, S stream buckets, so secrets can be everywhere. If I’m a developer and I’m pushing code and I’m waiting for you to scan, and it’s going to take two minutes I’m going crazy over it. Two minutes I’m going crazy. Five minutes I’m killing someone. Ten minutes I’m out of this.

     

    Interviewer:                I’m not doing it.

     

    Interviewee:                And finding a way to go around this.

     

    Interviewer:                Yeah, yeah, I’m not doing it no more. Yeah.

     

    Interviewer:                So this Spectral technology, that was really their core tech, which is really interesting. So they, it’s like keeping it really, really simple. They have the ability to scan huge amounts of code for problems. Now a problem can be secrets. A problem can be mis-configurations in infrastructure as code templates like _______ can be a bunch of missed spaces, but they can do that really fast.

     

    Literally we scan, when we do the due diligence we scan their entire – our entire repo, the checkpoint repo in seven seconds.

     

    Interviewer:                Wow.

     

    Interviewee:                The entire repo, 30 years worth of repo.

     

    Interviewer:                Oh shit. Oh.

     

    Interviewee:                Seven seconds.

     

    Interviewer:                Holy mackerel.

     

    Interviewee:                I know it’s an oh shit. I had an oh shit moment also. It’s so, and it’s not like that. And they were saying okay, something here is happening. Now and it was also super accurate and they found very interesting things.

     

    So once they nail down the user experience or the developer experience you understand how they work and integrated the tools. Then you solve a real, real problem, because that is a real problem and you solve it really fast. That’s why we totally like them.

     

    So we really looking at them and just to make it even more interesting to the point that we started with how different of a DNA it is. Because it’s such a different DNA we’re acting inside my unit, inside the cloud security unit we are leaving them independent. We are not touching them.

     

    I don’t want them to start talking security to security people. You guys get the developers. You understand how they work. You go,  you do you. Just keep on doing that thing. I don’t want to dirty them.

     

    Interviewer:                I got to tell you, I’m sitting here, you know the word kvelling? Have you ever heard that word in your life?

     

    Interviewee:                Yeah, I – yea.

     

    Interviewer:                Because so I started devopsy.kinsta.cloud in 2013. Right. And RSA I think 20, maybe it was 2015 RSA. I started what we call the DevSecOps Event within RSA. It was Monday of RSA week. Right.

     

    Interviewee:                Right.

     

    Interviewer:                And the idea behind it was to bring the security, the cyber whatever you want to call it, the security community together with the DevOps try with the developers. And I got to tell you the aggravation I had, you know, eight years ago. Security people, they don’t care about security, they’ll never care about security.

     

    Interviewee:                Exactly. Yeah.

     

    Interviewer:                They’re stupid. They’re this.

     

    Interviewee:                They’re the enemy. Yeah.

     

    Interviewer:                Right. And you know what the developers are. All they do is say no, they slow us down. They are a pain in the ass.

     

    Interviewee:                Exactly. Totally.

     

    Interviewer:                It was like this. It took me seven years of build, because I believed – I believed that no, security may never be their number one priority, but no developer I ever met raises their hand and says I want to develop in secure code.

     

    Interviewee:                They don’t care, no. Right. No.

     

    Interviewer:                I like crappy quality. I’m a crappy quality developer. You know what I mean? No one says that.

     

    Interviewee:                Right. Right.

     

    Interviewer:                They all, they have pride in what they do.

     

    Interviewee:                Yes, exactly.

     

    Interviewer:                The problem was, is we weren’t giving them tools that they could use.

     

    Interviewee:                Yeah.

     

    Interviewer:                They’re not CISSPs. They’re not ______ or scanning _______.

     

    Interviewee:                No, no, there were security incidents and try to do for _______.

     

    Interviewer:                No, they’re not compliance experts.

     

    Interviewee:                Yeah, exactly. You found the problem, tell me how to fix it. Be very specific. Don’t tell me how to fix it –

     

    Interviewer:                Don’t fix it because I want the quality. I want the quality. Yeah.

     

    Interviewee:                Exactly. And I think you are touching now on a very interesting point, because when you start to bundle these things or unwrap it actually let’s say, one is you’re right, it’s a new user so we talk about it. I actually think that security people today, and I can tell you now product group, that’s exactly how we think.

     

    We think about the developer and the DevOps guy and the ______ guy as a new type of user. He is a user to the security side. I need to think, I need to cater to his needs. Now what does he need? To your point earlier, he is not going to read forensic reports. He is not going to read the tax batchers. That is not his job.

     

    His job is to write quality code that is not vulnerable as much as possible. Now if you find the problem in what he does tell him how to fix it and tell him in his language. In his language. His language is not a dashboard with a search. It is not his language. It is not just a piece of code telling that piece of code is problematic. If you replace it with that piece of code you are good to go.

     

    Interviewer:                Done.

     

    Interviewee:                It’s such a different mindset. It’s like you all are security people. You’ve been around, I’ve been around. We immediately show dashboards and must moves. Who cares? The Spectral ops guys where they showed us a demo and it’s like your heart attack for any normal security person, because what do they show? A CLI.

     

    Interviewer:                Yeah.

     

    Interviewee:                They open the CLI. It’s like everything black screen CLI. Anyone from a security will say I don’t understand what they are doing, but their customers, that’s exactly what they appreciate. To integrate immediately. You are talking with the ex, that everything is API first.

     

    Yeah, there is a report somewhere that you can see in the background if you need, but everything works inside the development environment.

     

    Interviewer:                But this also goes TJ, and we’re probably over time. I apologize.

     

    Interviewee:                That is okay.

     

    Interviewer:                But this also goes that we need to redefine the relationship between the security team and the DevOps developers and the people who use this kind of tool, because what happens is look, it’s going to be the developer. Maybe the DevOps or the SRE, but it’s going to be those people who are instituting the changes to close down a vulnerability or fix something.

     

    Interviewee:                Right.

     

    Interviewer:                That doesn’t absolve the security team of responsibility. No one is saying hey security team, you’re out of a job. Or hey security team, you don’t got to worry about it anymore.

     

    Interviewee:                ______ no.

     

    Interviewer:                The security team still needs that report.

     

    Interviewee:                Exactly.

     

    Interviewer:                That forensics trail if you will, to say hey, yes this was found, this was fixed and this is how it was fixed. And that again is yet another kind of special talent to make a tool that’s easy enough or is in the DNA of the developer, but still gives the security team, the compliance team what they need to sleep well at night.

     

    Interviewee:                That’s why one of the best sentences I like and we used it also when we announced the acquisition is would invent it, people use it before, it’s security tools that developers love and security people trust. That’s the theme. Right. That is so true.

     

    Interviewer:                I may steal that from you.

     

    Interviewee:                Steal it, _______ it. It’s like ten cents a use, and I know it’s in the –

     

    Interviewer:                Okay. We’ll put you down. We’ll put you down. No, but it’s true.

     

    Interviewee:                That’s what you want. Right. That’s really where you want, because and you just described the part that what does it mean for me as a security person to trust the tool that you’re using, and to trust the work that you are doing with it. And I think it’s a very different – it’s very interesting.

     

    I’m thinking the future by the Allan, and I think you are sitting with devopsy.kinsta.cloud, just right on the money. Because the future of security looks like this. You’re going to have security people. They are going to more and more, that’s where it’s going to go. It’s not tomorrow, but that’s where it’s going to go.

     

    The traditional security people I call it the sandwich model. The traditional security people is going to be at the beginning in defining what is secure, or what does it mean to be? Is going to be at the end validating that security actually happened. The sandwich in the middle is going to be more than ever what in the future, more than today by far developers. It’s going to be cool.

     

    Security is code. Computer security people are going to define what’s needed. They are going to make sure that they are going to validate that it happened. These people in the middle are going to be more and more code people.

     

    Interviewer:                People who make it happen.

     

    Interviewee:                Code people. That’s the new security engineer. The new security engineer knows how to code. And that’s why we acquired Spectral and that’s why we are going to let them lead our developer first spot security initiatives, and we’re super excited about it.

     

    Interviewer:                I’m excited for you, and I’m glad to see Check Point coming out with this. It’s great. Hey, for people who want to get information on Spectral where do they go?

     

    Interviewer:                ______.com website. You are going to find immediately on the homepage a link to the information around the acquisition and you can also go and check out spectralops.io, the website of the company.

     

    Interviewer:                I love it. TJ, man thanks for coming on and talking with us.

     

    Interviewee:                You are welcome.

     

    Interviewer:                It was a great acquisition. We’re going to be watching others go. I think a smart move by Check Point. Hey, we’re going to take a break here on Techstrong TV. We’ll be right back with some more interviews and news and information. TJ, thanks very much.

     

    Interviewee:                Thank you very much. Thanks.

     

    [End of Audio]  

  • This DevSecOps Thing Is Real After All

    This DevSecOps Thing Is Real After All

    Whether you made it to San Francisco, California last month for RSA Conference or not, you don’t want to miss Tuesday’s DevOps Connect: DevSecOps Virtual Summit.

    On Tuesday, July 12, 2022, we are presenting a virtual broadcast of the sessions from our recent DevOps Connect: DevSecOps event at RSA Conference in June 2022. All of the great sessions will be available as well as some bonus sessions that didn’t make it to RSAC.  

    For me, this event was extremely gratifying because it served as validation that I wasn’t crazy all those years ago. When I started devopsy.kinsta.cloud in 2014, I did so because I thought it would be great for security—back then it felt as though I was a lone voice crying out in the wilderness! Now, here we are in 2022 and DevSecOps is real. It is accepted, it is sought-after and it is changing the way software is developed, deployed and managed.

    When I put on the first DevSecOps event at RSA Conference seven years ago, it was a bit controversial. The idea of bringing together the security community with the DevOps tribe was like what I imagine peace treaty negotiations between two warring parties would be. The security folks said no one else cared about security. The DevOps people, like many other IT pros, claimed the security folks were just people who said no to all their initiatives. The lack of trust ran deep. But we kept at it—and while the situation is far from perfect today, so much progress has been made.

    This year’s event featured our best speaker lineup yet. Jim Zemlin, executive director of The Linux Foundation, kicked off the event by talking about open source and security—software supply chain, SBOMs and security, oh my!  Continuing the open source and security trend, CNCF executive director Priyanka Sharma presented a great session discussing cloud-native and DevSecOps.

    And you won’t want to miss two of my favorite sessions. The first involves my friend John Willis asking, “What would Deming do?” in his session at 11:30 a.m. ET. Given the current state of world affairs and the software and security market, what would Edward Deming, the patron saint of DevOps, say and do? John is a bit of a Deming expert himself, so his insights are spot on, I think. And second, Carolyn Wong (who is a superstar) talks at 12:00 p.m. ET in her session about pentesting at scale, pentesting-as-a-service and DevSecOps.

    But wait—there’s more! Chenxi Wang has a powerful session, delivered off the cuff, about the current state of DevSecOps, software supply chain security, investing and more; that’s at 9:55 a.m. ET.

    We’ll also feature two amazing panels: One is made up of the authors of a recent book, Reinventing Cybersecurity. The other features folks from Intel, Mitre, NIST and the U.S. Senate talking about security compliance with an emphasis on software supply chain security and SBOMs (see a pattern here yet?).

    And that’s just the tip of the iceberg—there is even more from this year’s event that you don’t want to miss. So, head on over and register—it’s free. Many of the speakers will be online, live, during their presentations to answer questions, network and offer their guidance. There are also exhibits and sponsor booths and other fun stuff like a yoga class and a DJ spinning great tunes.

    This DevSecOps stuff is real and you will learn a lot from these sessions. We can’t wait to see you there!

    While you’re at it, check out our upcoming CloudNativeDay Virtual Summit August 10, 2022, which is shaping up to be a great event, as well!

  • DevOps Unbound EP 18 – Standardizing DevOps – TechStrong TV

    DevOps Unbound EP 18 – Standardizing DevOps – TechStrong TV

    Alan Shimel: Hey, everyone, welcome to another DevOps Unbound. If this is your first time catching a DevOps Unbound, welcome. DevOps Unbound is a biweekly video series where we talk about relevant topics in DevOps. In addition to the biweekly show, we do, it’s every four to six weeks, a live roundtable show where we invite the audience to participate and drive the discussion with online questions and comments and so forth, so we open it up to a live audience. Unfortunately, this show is not one of our live roundtables, it is prerecorded, but we have a great panel and I think you’re gonna enjoy it.

    I’m gonna get into today’s topic in a second, but before we do, let me introduce you to today’s panel. First of all, I wanna introduce a business partner of mine and my friend, Jayne Groll. Jayne, why don’t you introduce yourself to the audience, if you don’t mind?

    Jayne Groll: Thanks, Alan. Hi, everyone. I’m Jayne Groll, I’m CEO of The DevOps Institute, we’re a global member association and a certification body around topics related to DevOps. I’m really, really excited to be here and I’m hope everyone listening joins us at DevOps Institute and becomes a member.

    Alan Shimel: Fantastic. Welcome, Jayne. Joining Jayne, I’m happy to have Paul Bruce. Hey, Paul, welcome, and if you wouldn’t mind, you know, introducing yourself?

    Paul Bruce: Yeah, hey, Alan. Good to be back. My name is Paul. In my full time job, I work with Tricentis in a number of different areas. I’m historically a performance and reliability nerd. In my off time, I organize a number of events, help to co-organize volunteer things like DevOps Days Boston, just did o11yfest this year about observability, we had that conversation, I think, with Christine Yen a couple months ago.

    Alan Shimel: Good stuff. Mm-hmm.

    Paul Bruce: And generally, I’m a people advocate. I had to pull DevOps out of my LinkedIn title because there were too many recruiters that I don’t need, because I’ve got a pretty good job. But also, because people advocate really describes what I care the most about, right? People are some of the hardest part of the DevOps people, process, and technology, really, software. So, I really focus my time on that.

    Alan Shimel: That’s great to have you back on, too, Paul—good stuff. Next, we have a first time guest on DevOps Unbound today, a new member of the band, Sarah Baker. Sarah, welcome to DevOps Unbound, if you wouldn’t mind introducing yourself?

    Sarah Baker: Thank you. Wonderful. Welcome. My name is Sarah Baker, my pronouns are she and her. I’ve been working in Operations my entire career and I’ve moved into DevOps as something I always—I needed a name for it. I always wanted the people part of Ops and technology and DevOps was that. And I’ve been doing that as soon as I learned the term. And I’ve been moved and started working with Paul Bruce in the IEEE work group 2675, who is trying to create a standard for DevOps.

    Alan Shimel: Fantastic.

    Sarah Baker: I work for—and today, I work as the Manager of Biztech in Airbnb.

    Alan Shimel: Thank you, and thanks for joining us. That sounds like a great place for you to do this. And then the last member of our panel today is my co-host and another business partner, a long-time friend as well, Mitch Ashley. Mitch, if you wouldn’t mind introducing yourself?

    Mitch Ashley: You bet. Always good to have a good panel on with you, Alan. Mitch Ashley, I’m CEO of Accelerated Strategies, an analyst firm that’s focused on DevOps, and also on cloud native, cyber security, and digital transformation. I come to DevOps both as a practitioner and a vendor leveraging it, so very interested in hearing the perspective of folks on our topic today. So, thanks for joining us, everybody, too.

    And by the way, our DevOps Unbound is sponsored by Tricentis. I think you may have mentioned that, right, Alan?

    Alan Shimel: No, I think I didn’t, Mitch, but thanks for picking it up for me. [Laughter]

    Jayne Groll: [Laughter]

    Mitch Ashley: I was trying to give you credit where credit may not be due.

    Alan Shimel: Yeah, no, I don’t wanna take credit when I messed up. Yeah, DevOps Unbound is sponsored by Tricentis, and many thanks to them for their sponsorship. It makes all of this happen.

    So, let’s turn to the topic at hand today, guys. You know, when I first started devopsy.kinsta.cloud eight years ago, I met Jayne maybe a year, within a year of that or a year and a half of that. One of the interesting things about DevOps is, there was no manifesto. There was no hard definition of what is DevOps and what is not DevOps, you know, contrary.

    And ever since then, it’s been a double-edged sword. In some ways, it’s helped DevOps grow, it’s helped DevOps stay current over the last 8 to 10 years as the world has changed, DevOps has changed along with it. On the other hand, though, we’re still dealing with the, “So, what is DevOps?” Right? “What exactly is DevOps and what exactly is not DevOps?” which is sometimes harder than what is DevOps.

    And as we sit here now, August, 2021, there really still is not a quote-unquote standard for DevOps. There is no standard DevOps. It is what you want it to be, right? As I think Andrew Clay Shafer said, “The DevOps you get is the DevOps you deserve,” right? But have we outgrown that stage? You know, that seems like a terrible twos stage of DevOps to some; to others, it’s what kept it cool. Has DevOps matured? Do we need standardization? Will it be something that kills the goose that lays the golden eggs?

    We’re gonna discuss that today, and I’m interested in all of your views. Jayne, as the CEO of DevOps Institute, how many people have taken certified DevOps classes and certifications with DevOps Institute? It’s gotta be tens of thousands.

    Jayne Groll: Yeah, about 25,000 so far. So, it’s a pretty large community.

    Alan Shimel: Mm-hmm.

    Jayne Groll: And if you don’t mind, I wanna kind of just lay the stage, because I’m really interested in the standardization initiative. So, you know, I had a privilege of seeing, going to DevOps Days in 2012 in California. So, if you can imagine, it was in an old, dusty data warehouse, right, and it was at the very, very early stages. And so, one of the reasons DevOps Institute emerged was because there was a lot of really cool things here culturally, from an automation perspective, right, doing things faster, collaboration.

    And so, we started up DevOps Institute because we wanted to make sure the humans were represented. And I love that Paul and Sarah in particular both represented people. The problem with that is, at that point, it was very, very open, it was very kind of organic. You know, it was really a group of passionate people that were trying to just change the way IT operates, right, from a people, process, and technology perspective.

    What happened after that, though, is that there’s so much noise about DevOps that if I were an enterprise CIO right now, my head would explode, right? Now, is there one right way to do DevOps? No. Is it only gonna get you there with automation? No. You know, is there a very, very strong human element—absolutely.

    So, it’s a double-edged sword, Alan, as you said, is that we wanna be able to kind of scale down, right, some of the common language, some of the common definitions. I always say I’m married to a CPA, they have generally accepted accounting principles; maybe someday, we have generally accepted IT principles. But how do we distill the noise, right, and everyone having a different interpretation of how to do DevOps and what it is compared to, let’s get past the, “what is it?” We’ve spent, what, 10 years trying to figure out what it is, to, “how do we do this?” Right?

    Paul Bruce: Mm-hmm.

    Jayne Groll: And it isn’t just one roadway that takes you there. So, I think it’s a challenge. I mean, we introduced foundational certifications around DevSecOps and SRE and DevOps Foundation and DevOps Engineering, really, to create kind of a common vocabulary more than the, “here’s the single way to introduce CI/CD.”

    So, I don’t know if that helps kinda set the stage, but I think it’s a really big challenge right now that, if we standardize it, we run into the risk of what happened with ITIL where it couldn’t keep pace, right, and it became religious. I come from the ITIL space, right, so it’s like, open chapter 1, verse 3 and sing a hymn before you introduce change management to how do we then, on the other end of the spectrum, it’s so open and so undefined that it’s really complicated for legacy, I call them heritage organizations, to be able to move from this step to this step.

    Paul Bruce: Mm-hmm.

    Alan Shimel: The church of ITIL. Paul, what’s your feeling on that?

    Paul Bruce: Well, everybody’s on a journey, right? Your personal journey, your professional career, whatever, maybe you go do a walkabout on a particular topic to learn more about that. And so, we started this venture, there was an early round of, “Who wants to be involved in something like this?” in 2016. I answered a call from Bob Aiello and Lynn Carter, who were kind of forming this idea of, there’s a bunch of people who really care deeply who have practitioner practical experience in the field. And the early part of this process was just learning, kinda level setting on what we have done, right?

    Jayne mentioned that it’s hard, maybe, to have accepted IT standards, even though there are standards, right, that not every organization applies the same way. I don’t think that invalidates some of the general principles that we know to be true, which is, you know, you ship broken software, you hurt people, you hurt yourself, right? But those are high level. How do we break this apart and start to make sense of the world, as you said, the heritage, Jayne, you said the heritage organizations—what is so wrong, what’s going on that we have these kind of security problems, these performance problems, this inability to be competitive in terms of acceleration and stuff.

    And so, I think the purpose of a standard is not necessarily to force people to do something a certain way. I think it’s simply just kind of like, if you’ve ever had the Christmas ornaments or just ornaments box that has the insert that allows for things to be put in careful places and also work together as a unit, right, to provide a normative, not a prescriptive standard, but a normative standard to say, “Look, these processes that you already know? Well, you already followed these from, let’s say, 12207, right?” These processes around supply acquisition, knowledge management, human resources? Right, human resourcing in DevOps is a big problem, at least in the Boston area. Try to hire an SRE—there’s only about 15,000 to 20,000 in the United States, legitimately. There’s a reason for that demand.

    So, how do we think about the processes we already know and start to say, how are these things different because there are some accepted principles and practices around DevOps? Now, the practices are not things that you would ever wanna dictate in a standard. This is not the same granularity level as some other standards that dictate how to encode time formats. That’s very important at that level. But the level that we were working on was how to level set across the things that, especially organizations in high compliance and high risk industries, right, risk-averse industries—how do they take the practices and processes that they know from a process standard and start to go, “I understand how to plug, now, what the DevOps principles are into the standard to encourage both of those practices in a more predictable manner?”

    So, when we did all this work—it’s taken years, right, of a lot of learning collaboration between a whole host of people I don’t have even time to list out, but a lot of people from a lot of various different aspects of software have a lot of experience in those aspects. You know, it took synthesis and refactoring, and I was up nights and weekends just rewriting some of the statements, you know? And each of these, it’s a line to 12207, so there’s multiple processes, process declarations like quality management, quality assurance, verification and validation.

    Like I said, these project enabling processes and then these technical processes, and each of those process sections have outcomes, activities, and tasks. Things that are likely to occur in this area, right, as well as, regardless of how you do this, right, not dictating what the DevOps looks like, it’s outcomes of these things that are auditable, that not compliance but conformance. That you can confirm at various levels to these outcomes to say, if it’s important to get this right, when you hit the piñata, what comes out should be candy, not garbage, right?

    So, I’ll pause there, because I wanna give Sarah a chance to kinda provide perspective, because she’s also been working a lot with us, for all those years. [Laughter]

    Sarah Baker: I think I counted 27 people on the final author list for the IEEE.

    Paul Bruce: Yeah.

    Sarah Baker: And it was many, many weeks of arguing, reading together the exact language. And I agree very much with some parts of what Paul says, and I wanna step back and talk a little bit about how I see, you know, what, to me, was the big shifts. And so, the way we wrote the doc was to kinda look at the 12207 and say, “How does DevOps change it? How has it changed the game? What are the perspectives that you need to have in mind in order to get the outcomes that Paul’s talking about, there?”

    And so, when we were writing it, we were writing it to that. How is this different, and to what extent do you wanna consider these areas? It’s a framework of thinking. At its largest level, it’s a framework of, for me, the value chain of delivery of software. And it’s not—and it uses many of the concepts that come out of learnings of industrial engineering, way back in the ‘40s, ‘50s, ‘60s. But it had never really come into a lot of the thinking of software, because software is different. And the more I was working and kind of digging into what are the concepts underneath DevOps, I came quite aligned with a lot of industrial engineering concepts about how things flow and how things move back and what the peaceful aspects are in that.

    And so, that—actually, if you read through the standard, you’ll see a lot of those flow pieces and all of the pieces that you then say, “Oh, it’s the feedback loops, yeah, lots of feedback. Collaboration, it’s all there.” And it’s just applying a lot of those learnings into software engineering, to me. And it was stuff I was like, “Oh, it’s so wonderful to have this.”

    And the other thing, one of the big learnings that I think I brought into the conversation is how—and Paul will back me up on this—how security for a lot of us changed slightly as we started walking our way through the 2675 work. The terms of risk became a very interesting concept that flowed through the document more than I would have expected.

    Paul Bruce: Mm-hmm.

    Sarah Baker: And so, there was some learning within the totality of our team as we wrote this. It was quite fascinating.

    Mitch Ashley: I’m really fascinated to hear from both of you that have been working on this, because it’s not something I’ve been involved in. I sorta have a mixed history with standards, because I’ve worked in areas like networking and things like that where standards are very beneficial or really fundamental, but I’ve also learned standards are kind of what you’re gonna do, not how you’re gonna do it. Because we ran a test lab that, even though it says we’re gonna do least cost routing in a network device this way, people implement it differently and they don’t always work together. So, it’s not a nirvana, but it’s also not a pariah, either.

    Paul Bruce: Mm-hmm.

    Mitch Ashley: So, what I wrestle with here is that, I think some of the thinking—and Jayne can speak to this, but innovation happens so quickly now. So many things are created without standards; maybe they evolve into standards, maybe they don’t. And it doesn’t bother me that there’s lots of noise around DevOps, because we’ve all seen the cycles, the hype cycles, right? If it’s worthwhile, everyone and their brother, sister, cousin, uncle will all jump on the bandwidth and call what they’re doing fill in the blank—it’s AI, it’s DevOps, it’s whatever. That’s just part of our industry. And it’ll either fizzle—you know, value stream management, is it a real thing? We’ll see. It’ll fizzle or it’ll happen, right, if it’s a real thing. And DevOps has proven itself not only is it a real thing, but other parts of the organization now see an opportunity to play, to participate, to become part of the software creation process.

    Paul Bruce: Mm-hmm.

    Mitch Ashley: And I think that’s what’s so powerful about DevOps—it’s not about a technology, it’s about how we create software. And if you were gonna start out, you know, Jayne, when you went to that meeting in 2012 when you said, “We’re gonna go create a standard for completely doing software differently because we have cloud and we have the ability to automate and we were gonna change the software architecture,” you couldn’t have known how to do that. But being the industry would’ve, you know, the antibodies would’ve crawled all over all of us and stopped it. So, I think there’s a lot of power in the innovative, organic nature of it.

    And I don’t want DevOps to turn into ITIL, [Laughter] because that’s sort of taken on a life of its own, and now it’s trying to catch up and it’s done some good things, too. So, I wrestle with trying to constrain it when I think it’s real power is the innovation behind what we’re doing.

    Paul Bruce: Yeah, so, before I—

    Sarah Baker: If I could take a moment—

    Paul Bruce: – yeah, go ahead.

    Sarah Baker: – I’d like to take a moment and call out something. Part of the problem with ITIL is like, it’s ITIL. And, you know, a gazillion managers said, “ITIL, let us get a hammer and hit you over the head with it.” And DevOps, fortunately doesn’t have that problem. It has, you know, a little fuzzier in its definition, but the great thing about DevOps is that it has that sort of fuzzy edges. You can’t, it’s really hard to beat someone over the head with it. You can try. I’ve seen it happen, you know? Everybody’s a DevOps engineer now, but it’s not necessary.

    And what people talk about is not that, but the work, you know? It’s not, “We’re conforming with ITIL,” it’s like, “We’re doing DevOps.” The doing part is the important part, not the compliance part. So, when you say, when you hear people talk about it, they talk about it differently, and that’s the good thing.

    I use ITIL, I just don’t tell anybody the word.

    Jayne Groll: Which is a shame. It’s such a shame because, you know, I come from the ITIL space, and in the early days, this was not what the intent was to be. It was very much like DevOps in terms of, “Let’s help IT grow up,” right, in terms of some things.

    And, you know, to what you’re all saying, you’re absolutely right. A framework, whether it’s a standard, is a guideline, right? It helps you with the journey, as Paul said. And so, if I wanna kinda check, check, check—you know, I’ve worked with some of the ISO standards, right? So, in the ITSM space, there was ISO 20,000, 27,000 for security, right? And it basically, like, in the one or service management says, “You should record all your changes.” It doesn’t say how to record it, it doesn’t—it’s a really great practice, you should do this.

    The problem, sometimes, with standards—and I’m sure you know this and it’s a risk—the pure intention is pure. The ability to weaponize it, right, from the auditors and from others is a real risk, right? Because we’ve seen that with other standards as well, where it becomes more about the compliance than it is about how having it being a guiding light. So, I think there’s always a risk there.

    And then the other risk is, you know, think about observability, right? So, observability has been trending, what, for a year, maybe two, right? Four—okay, but really mainstreaming, like, talking about observability as kind of a mainstream practice, right? And I will share with you, Mitch, to your point, when we launched DevOps Institute in 2015, we were not welcomed with open arms, right? We were vilified for trying to put some boundaries around this.

    Now, you know, move forward seven years and I think we’ve overcome a lot of those and we have some that were detractors or really great supporters. But I think they were concerned that it would become weaponized or commoditized or whatever.

    So, I’m just gonna say one last thing because I think it’s important. Commoditization of knowledge, which, this is kind of in support of the standard, right? Commoditization of knowledge where we make sure it’s available to everyone, some people see that as a negative—it’s not. What would happen if the whole world, right—every IT organization, every IT professional decided to take this standard and use it as a guiding light, according to the needs of their organization? They weren’t worried about the audit, they got trained, they shared knowledge—wouldn’t that be amazing? But that’s commoditization.

    So, I think the risk of good versus evil on initiatives like this is real, but I also think that distilling it to everybody, kind of like accountants have done, right, is important because IT needs to grow up.

    Paul Bruce: Yeah, well—

    Mitch Ashley: Well, and if you look at the accounting standards, they don’t tell you how to do it, they tell you what to do.

    Jayne Groll: Right.

    Mitch Ashley: It isn’t prescriptive in the how very much, so it’s very much like an IEEE standard or whatever.

    Paul Bruce: Yep. Well, first off, I forgot to mention when we first started—I speak as an individual contributor. If it isn’t abundantly clear, [Laughter] I don’t speak for the IEEE, and I don’t speak for the other people who have spent years contributing to this meaningfully.

    So, when I say certification processes inherit all the exact same things you just mentioned as problems—weaponizing, actually low ROI maybe in some cases—we see these deficiencies and these outcomes that aren’t so great. And if you’re somebody who’s just gonna sit back and say, “I’m not willing to hold myself accountable” to stand up and say, “What does this thing actually mean like a real engineer should, you know, to start to break apart the problem and see what are the components, how does this thing work and how do I want it to work? How does it work best for the people around me as well?” If you’re not willing to do that, then I would call you the nay-sayer, you know what I mean? Like, not any one in particular, but that would be a nay-saying, like, let’s avoid accountability, let’s avoid doing what we know needs to be improved?

    Continuous improvement is a huge element that is all throughout the entire standard. It’s one of the things that’s identified as some of the core principles in an ISO study that was done before we started in on this standard to see what are the common themes of people, when they’re really feeling like there is this DevOps mindset, this culture, these practices—what do they mean by it?

    And a number of things came out. One was a high degree of automation, right? Okay, well, that’s very tactical. No matter how you do it, right—high degree of automation. Duh, right? How about effective communication and collaboration? How about shifting things and continuous everything? The notion of, that these things are not this one time and then three years later, you get to come back. No, no, no. If it’s a good idea now, maybe don’t bite off a three-year apple. Maybe take a bite, but know that you started in, there’s a continuous improvement process.

    I can say, we mentioned earlier about a holy war that might exist when you start getting into what is DevOps and what is not DevOps. Like, I started—the best way I can describe to people, because like I say, half of my day is spent on and off of Slack with people who are actually doing, working this out in a highly statistical, large distribution across the country, you know, and sometimes outside the U.S., too, just time zone supply.

    But I can say, for sure, after seeing the complete garbage Dumpster fire where nobody is willing to stand up and say, “Hey, aren’t these things common and standard?” And oh, by the way, not vendors that have something to push, right? I mean, that’s, I think, Jayne, where you were talking about maybe observability is now a thing. You know, the only reason why it’s a thing for the most part is because it’s in our face now because all the vendors are hash tagging the crap out of it.

    Same thing happened with DevOps five, six years ago—everybody had to get on the bandwagon. I remember CEOs way back then going, “What is this DevOps thing?” Oh, man. You know, just talk to some of your engineers.

    And what I can say, right, I have developed at least an internal personal perspective on what is not DevOps. So, if I can borrow the last 30 seconds of the mic for a second, here are some things I wrote as notes as I’m going back over the standard, re-reading it, going what I violently agree with from both others and myself, we did not have a chance to see this before it went live many times, right?

    So, what I got from one of the higher order sections in Section 5 was this feeling of, like, what is not DevOps. And those things are burnout. DevOps is not burnout. You know, you’ve probably been burnt out if you’ve worked in DevOps before, so where is this coming from? Why is this the case? It’s not burnout, it’s not no help. You don’t get any help, go do this thing, you know? It’s not heroics. It’s not superheroes in capes, right? Single points of failure, as I call them. It’s not cliques—which, by cliques, I mean power silos. Huh-uh, there is no such thing as The DevOps Department, people. There’s no rogue decisions. There’s traceability in decisions. There’s accountability in decisions.

    Leadership thrash—not easy to, if you’re really adopting this DevOps mindset and way of thinking about how to do things better, leadership thrash doesn’t really fit in. Toil and debt, right? One of my biggest things is, you know, I seek to eradicate toil, which is not easy. [Laughter] Just reducing it a little is nice, but it’s, and it’s probably pragmatic to say so, but really eradicating toil from other people’s plates and from your own, that’s a challenge, right? That’s kind of a life goal. And if we do this stuff together, right, if we say these are not the things we want, the question is how do we move towards something that isn’t those things, right, and that is closer to where we all align and agree, like, this is a better way of delivering software and doing it faster, right?

    So, anyway, I’ll pause there.

    Mitch Ashley: You know, one of the things I’d love to hear from both Sarah and Paul is, there’s always sort of that, “So what?” answer—question, right? “If we did this, what is the result? What’s the impact of it?” And I mean that in a positive way, I’m not being critical.

    Paul Bruce: Yep.

    Mitch Ashley: If this standard was widely adopted, how would it improve? How would it—what things are we wanting to improve and change from where we are today? Can you describe that in any way to kinda give myself and others maybe an idea about that?

    Paul Bruce: I just did. People already implemented it.

    Sarah Baker: Well, at the base, there’s the vocabulary, yeah.

    Paul Bruce: Sorry, people are—

    Sarah Baker: At the base, that is part of it. Sorry. Paul and I always get [Cross talk].

    Alan Shimel: Sarah, go ahead. Paul spoke—you go.

    Paul Bruce: Yeah, yeah.

    Sarah Baker: Vocabulary is that first piece, making sure we’re all talking about the same framework. And so that, when we’re exchanging ideas, how did you do it, how did you do it—you know, not any one way to do it is gonna it, but knowing what your options are and talking about it with others and trying something out and figuring out if it works or not in your environment is one way to get everybody on the same playing field. But if you’re not talking about the same thing, you can’t do that.

    So, it’s having the ability for a large corpus of options to apply to your situation. To me, that’s one of the biggest things that it provides, and it also gives you ways of interacting with the rest of the business that is not IT, and kind of, “Oh, this isn’t—it’s not just IT. You’re a stakeholder, you’re a customer.” And it includes all of those pieces for the collaboration and really helps support it.

    So, to me, that’s what the standard brings. It widens the organization’s perspective a lot, and allows that cooperation to seep into the organization across all of these different pieces. Because to me, that’s how it started as DevOps, DevSecOps, DevOps Observation Ops. I mean, it grows because that’s part of its DNA is to include.

    Paul Bruce: Yeah.

    Sarah Baker: And so, it’s very natural that it has done that and it includes other parts of the organization into that basic thought processes. I totally could see DevOps marketing security—I mean, you see all that. That’s what’s, to me, the real advantage of thinking this way is that it includes the entire org.

    Jayne Groll: Well, and first of all, utmost respect to Paul, Sarah, and the other 25 people that are working on this, because this is a gargantuan task, right? Trying to encapsulate something that creates a common framework, that has the purest intention and also, you know, if you think about the heart of why DevOps emerged in the first place, it emerged because we were not collaborating together, right?

    So, you know, in the early days of IT—I always say I’ve been in IT longer than I really want to admit to—you know, there were 25 people that sat on the same floor, in the same office building, and we all knew each other and we went to happy hour. And then, you know, the tree grew and there were lots of branches and other things. So, you know, giving a central source of truth that everybody can kind of internalize, process, speak the same language—you know, IT, we have so many different languages, we’re like countries that are butt up right next to each other.

    And I said, I have so much respect, because this is a gargantuan task. And Sarah, I agree with what you said, the purpose is really to take this need for collaboration and optimizing automation, right, so making automation essentially members of your team, right, and then taking that out into the business because every business is a technology organization, it’s—I’m sure you’re aware of the risks. You know, we’re not telling you anything that you’re not aware of, but as I said, I just have so much respect. Because it’s not gonna be an easy road, right? There are so many different opinions from vendors and from everyone who’s involved in this space that are going to have an opinion or whatever. And I think, you know, that’s something that everybody’s gonna have to deal with.

    Again, the only thing I would suggest is build it in a way that it’s nimble—dare I use the word agile, so that—

    Paul Bruce: So, this is already done, right?

    Jayne Groll: Yeah.

    Paul Bruce: Like, this is not a draft, this is not an initiative. This has already been done for the past four years and is now an official standard. So, the good news is, to your point, I think, about suggestions about how to do this, we are working on the second version of this draft already.

    As soon as it was out, even before it was out, we knew there were things that we just couldn’t—we couldn’t spend the time properly addressing. Like I said before, there was a lot of refactoring, but there was a lot of careful avoidance of not already repeating what was already in a good security standard over here, or in a good risk management thing, or one of the folks that worked with us, Tafline Ramos, works at the ISO, right? And what is it, 29119, right, verification and validation, the processes—that was already stuff that’s already been, and great thinking and not slow, you know? Can fully be put into a modern, unicorn sneeze rainbows and fart sprinkles type approach as well as the large Fortune 100.

    So, just to say, this is already—we’ve already put a ton of, it’s already out there, and the easiest way is, I mean, some people might be wondering, “Oh, yeah, but it’s a standard, so now I gotta pay for it?” Some standards, you do; some standards, you don’t. This one, IEEE, they cover their costs with the standards. The easiest way, if you wanted to get a free copy, become part of the new, the next version of this, right? See what we’ve done, poke holes in it, have collaboration, let’s work on it together, because that’s the point of this is to bring a framework of how we are working together in a more effective manner.

    Jayne, I’m really sorry I cut you off.

    Jayne Groll: No, no, you didn’t cut me off. Just a cautionary tale. One of the reasons ITIL kind of lost a lot of its momentum—and I’ll be very frank, I owned an ITIL training company for 15 years and I was a chief evangelist, but it took 8 years between version 3 and version 4. And so, it wasn’t built, it was a monolith.

    Paul Bruce: Mm-hmm.

    Jayne Groll: And I think that was—you know, in the meantime, lots of other things happened, and I think there’s a cautionary tale. I’m not suggesting you’re looking at eight years, please don’t misunderstand, but this market is so—

    Paul Bruce: No, it’s probably about three, right?

    Jayne Groll: Yeah, this market’s pretty fast. Sorry.

    Paul Bruce: Our target is about three, between where we officially started and now it’s out and the next revision, at most, would be another three, right, that’s our target. It could be earlier or later than that.

    Think about, we’re all citizens of the United States here, right? Or anybody in Canada?

    Alan Shimel: Is that a HIPAA violation to answer?

    Paul Bruce: Yeah, right.

    Alan Shimel: Just kidding, just kidding, just kidding.

    Jayne Groll: [Laughter]

    Mitch Ashley: I’m not showing you my vaccine card.

    Paul Bruce: I ask because, I ask because—

    Alan Shimel: I didn’t wanna go there, but go ahead.

    Paul Bruce: – we all know what the U.S. Constitution is and where it came from.

    Alan Shimel: Mm-hmm.

    Paul Bruce: Do we think that it was perfect and never has to be revised? Absolutely not. That’s what the Amendments are for. And arguably, I people wanna go back to the original version, there are some serious problems with that original version. Same thing with ITIL, same thing—remember with, I think you might have heard about The Agile Manifesto. You know, that was a drunken party with a bunch of white dudes, okay?

    Jayne Groll: I know. [Laughter]

    Paul Bruce: So, yeah, there were some good ideas that were encoded in there, but do they not have to be revised and worked out? Even Dave Thomas says agile is dead, long live agile. Like, what people have taken it to is not the point.

    So, the goal of this is to really get a full perspective. To what Sarah was saying, it’s not just—I’ve talked with a lot of the DevOps Days, various different people from DevOps Days, from a number of different, like, The DevOps Enterprise Summit and stuff, and there are some people out there that are like, “No, DevOps is just about developers and operations and it’s about just these things, and if you start getting biz in there—no, no.” And it’s like, what a narrow perspective, because you know what, you had a good idea and then you screwed it up by not including other people, by not realizing there are meta learnings that come out of what you locally did—maybe, arguably, you did well—that apply broadly. And when they do apply broadly, they bring us back to the same premise, which is, we’re all in this together, right? We all win when we all win. As Tim O’Reilly might say, provide more value than you consume, right?

    So, that’s where we intend on taking this. It’s not to turn into a bunch of agile consultants again or ITIL consultants, right?

    Mitch Ashley: [Laughter]

    Jayne Groll: Framework growers, that’s what we call it.

    Alan Shimel: Yep. Guys, I gotta pull the plug on ya, I’m sorry, guys, and ladies. We are out of time. I think a great way to end this, though, is—Sarah, Paul, where can people get more information on the standard from the IEEE?

    Paul Bruce: Sure. Google it, Google IEEE 2675, you’ll get to that page if you wanna buy a copy.

    Alan Shimel: 2675.

    Paul Bruce: I think without being a member, it’s like 99 bucks—so, look, you know, if you wanna buy it for yourself—

    Alan Shimel: It’s not breaking the bank.

    Paul Bruce: You probably also have, in your organization already somebody’s a member, your Risk and Compliance are probably already members to IEEE.

    Sarah Baker: Yeah.

    Paul Bruce: And again, like I said, the best way to get a free copy is to come work with us on what does the next standard mean. It’s not a huge effort and commitment like Sarah and I have put in. [Laughter]

    Sarah Baker: [Laughter]

    Paul Bruce: You can dip your toes in, see what makes sense, what works for you, and we love to—we include people in that effort.

    Alan Shimel: Great. Well, Paul, Sarah, Jayne—thanks for joining us on our panel today. Mitchell, as usual, great job. This is another edition of DevOps Unbound in the books, check it out. Go check out the IEEE standard. We’ll be back in two weeks with a fresh show and a fresh topic. Until then, this is Alan Shimel, be strong, be well—Tech Strong. Take care, everyone. Bye bye.

    [End of Audio]