DevOps Mythbusters – DevOps Unbound Roundtable

You hey, good day everyone. Welcome to another devops. I'm down live Roundtable.

Develop some bound is a bi-weekly video series where we explore topics related to devops and we usually can do a pretty deep dive into them and have some great discussions. Excuse me. What makes it great is is of course our guests and panel members about once a month though.

We do this format for devops on bound. Which is a live Round Table where in addition to our esteem panel members. We also invite you our audience to participate.

How do you participate you ask? Well, we use the big marker of control panel. So the big Marco webinar system and as part of that it's within the browser on the right hand side of your browser screen for most of you you will see our Communications panel.

If you look at the top of it, it's more you'll see headings for chat QA polls handouts. Under chat if you look at public. Well, that means that's public chat what you put in there is open to everyone and as you can see a lot of people have already come on.

They I guess they know what we do here and they're telling us hello from wherever they are, Texas New York City, Florida. I'm in Florida too. We've got someone from Italy Chow Chow from Italy, New Mexico, Minnesota.

I hope you staying warm. Oh, we got a whole bunch of people India and and all over the place. So please log in let us know where you're from.

It's always great to see what the global audience it is. But more than telling us where you're from which we do appreciate. We also use this chat to communicate what you would like to discuss or what your thoughts are on what we're discussing with our panel and you could do that in the public chat right in there.

We'll try to we'll try to participate now at panel members are free to participate with it. But also if you want to really ask a question of our panel up at the top of that communication Communications Panel on you in your browser. You'll see a section Mark Q&A and if you go in the Q&A, you could write a question in there at one appear in public chat, but we'll see it and I'll be able to ask our panel.

The question and we'll get your answers on this. So we've got people from Venezuela in Tennessee. Welcome.

Welcome welcome. Before I introduce our myself and our panel. I realize that introduce myself yet even I wanted to just also mention that we are giving away four Amazon gift cards today and I will announce the winners of those from people who have registered and are attending today's.

Um event you see my client is shockingly from Silicon Valley for Brooklyn. Wow, just this is great Romania. I love it.

Um guys, so let me introduce our panel and then we're gonna jump into today's topic as I mentioned. I'm your host. My name is Alan shamol.

com. Security Boulevard container Journal host on Tech strung TV and I'm also a co-host here on devops Unbound devops Unbound. I should mention this graciously hosted by our good friends at tricentes the worldwide leaders in automated testing and many thanks to chase scientists for their support.

For the devops are bound series which is going on now, I think over a year. We've had some amazing amazing. episodes my co-host on devops Unbound is our CTO here at techshire group as well as principal analysts a tech strong research is my friend Mitchell actually.

Say hello. Hello could be here of course and can't wait to talk about some myths about. Yeah, which is today's topic.

We're going to jump into in just a moment and let us introduce you to our other two panel members though. Next up is a good friend of ours. She's in a steamed author a distinguished engineer at IBM, which is something with it takes a lifetime career to to achieve but she's also really good friend of ours who I always enjoy being on a panel with or at a conference together.

It's our friend Rosalyn Radcliffe Rosalyn. Welcome. Hi happy to be here glad to be here and you got the book up faster than I could there's my book you too.

It is Rose what I surprise bug busting for Rosalind beyond the book. Why don't you give us a little bit of your background? So I have been in IBM for 34 years and the last number of years.

I have been responsible for making zos devopsible. One of the myths we can talk about if you want is that zls is not because it is that was my job and I've worked with the products the technology to allow it to do that as well as work with clients and their transformation most recently an officially now. I am actually working in IBM's Ci or organization as the devsecops CTO.

I just want a bunch of letters for my title. Now, you know, you know, no words just title just covered man. You're okay.

Yeah alphabet soup. Yeah, excellent. com eight years ago.

com, but for the devops community, you know, and when the idea of devops and mainframes was a myth or many thought it was a myth. Rosen was out there preaching In the wilderness about how devops and mainframes can work together and she's been proven right so Rosalyn, thank you for that and all you do and thanks for joining us. Last but not least.

I want to introduce and he's been a guest before on devops on down clints. It's proud. I always miss pronounce.

It's from you guys. That's perfect. Perfect.

Welcome back and thanks for joining. Thank you. I'm going to ask you to introduce yourself.

Sure. So again, my name is Clint sprou. I'm with tricentus been with tricentus a year and a half now been in the software development as well as the software quality assurance and testing industry.

So it's seeing different viewpoints of devops and a lot of myths. So this is one of those topics. I'm really excited to get into I'm really a really talk about so thanks for having me again.

Always a pleasure to have you on Clinton. Thank you. All right, let's get started.

So today's Roundtable discussion is devops myths. com there have been these myths. Associated with devops part of it I think is self-inflicted because we never had like an official.

Manifest or an official definition or official anything. It's kind of made up as you go and part of it is because devops is become somewhat of an umbrella term that You know encompasses so many different things, but you know. the kinds of myths I'm talking about when I first started there was this idea of you know devops is only for startups.

Because only startups really need to be that Nimble agile. You know to to appreciate devops and that what I always thought was interesting in the case of dueling myths there was another man. Oh boy.

Sorry. There was another myth. I don't know how to shut this off.

But I'm going to just oh right here in there was another myth that Not only was devops just for startups, but then there was one that said devops is just for big companies for large Enterprise. So you couldn't be both electric or startup that was also a large Enterprise immediately, right? But so they were kind of diametrically opposed but and over time.

as often happens with myths these things work their way out. So I'm gonna ask Rosalind if you don't mind. Let's talk, you know what devops myths that you think have been proven true or maybe proven to be, you know, full of hot air.

Well, I I think almost all of the it's only Force it's only for the inner. It's only you know, it's only for unicorns. Actually.

It's probably the ones the most annoying one. It's only for that startup team or it's only for the front and team. That's another one that I still here.

The reality is it's a way of working I mean devops is culture. I actually think the biggest problem it's not just the myths. It's the it's the people say devops equals.

And anytime almost every time somebody says devops equals they have it wrong because they usually say devops equals cicd or devops equals something in particular. It's only for these teams or whatever all of those things take away what devops really is which is culture. It's a way of working which can apply to anybody which isn't any particular technology or any particular thing.

It's that culture of working together and breaking down the silos and all of those devops equals. all cause a problem agreed agreed. The only four is the only thing that it's really only for is anyone who wants to do it?

Okay. It's for everyone right? But fair, you know excellent.

Excellent point Clint. How about you? Yeah, I think for me the biggest myth is the fact that there's Really only one way to do devops, you know, we talked about the whole fours and all of this but what really gets me is there's this assumption that everyone's doing devopsy exact same way.

Right? So if you're not doing it the way a Silicon Valley startups doing if you're not doing it the way this large manufacturing that has some little offshoot group that's doing it that you're doing it wrong and every company is just so vastly different. They have different knees they have different application types and systems that they still have to maintain that are still, you know, really bringing in revenue.

And so when I talk to customers when they talk about okay how you address devops or how do you quote unquote do them? Right I go back to it's really about letting me understand your organization your needs your skill sets. What do you have in your organization?

And how can we best help you? Because if I go in there and say hey you got you must do it. This way be so direct it just turns everyone off.

So I think everyone needs understand that you like you said, it's more of that collaboration and less about you must do it this way or you're doing it wrong and everyone has successes in the various ways that's been implemented. Fair Fair Mitchell You know, there's a lot to pick from if I had to pick a group of them devops means we won't have these jobs anymore fill in the blank operations testing. Yeah.

It's not only need developers. Right? Of course, we do need developers.

No doubt about that. If anything it's elevated the role of operations. It's elevated the role of testing.

We have some research back this up that because devops has helped people come together together and work more closely and collaboratively as teens sort of the two beats a team concept or whatever you want to use. It's actually helped bring everybody kind of into the same fold and work together instead of what you're a square and you're a triangle and you're calling but we don't mix right, you know and squares are the best ones the rest are The Milani we just just to kind of cause a problem with that sentence. I I agree, but I think everyone becomes a developer is the difference in devops-ish and I got to be really careful when I say this.

I really think we need to start focusing on the mentality of storing artifacts having pipelines using automation for repeatable tasks. Whether or not I'm operations test or developer, I think those things that we used to say were developer activities or actually everyone's activity and devops. It isn't that we don't have operations or we don't have test people.

It's that everybody works like a developer. In this new kind of world. So I absolutely agree.

We don't get rid of those individual skills. But but I do think when we think of devops one of the myth problems that they say it's only for development is because it's all about storing artifacts and having a pipeline and doing and all of these things that people associate with devops which then translates to the developer role and we should go no all rules do that. So it it's changing those how it's of a developer work product within everything we do that's not too Elevate the developer at some sort of alpha.

predator on the list, you know professional testers as our friends at tricentes will tell you are still professionals sres Are professionals they may be doing developer type things. But they're still professionals and I love to dive into Roselyn you and I can do a whole show on this but we got a really active panel a really active audience and I've got you if I want to throw out here. Yeah, we've got some really good comments.

Yeah, no the chat and feel free to chide up the people if you'd like, right we could have five we could multitask in the truth devops style. We can multitask this stuff but you know, so here's another big myth Ravi put up here scaling up and managing complexity is difficult and devops and I could see where this started right because you know, we used to do bubbles of devops. I called it where it was just small teams doing them.

It was we it was a it was a period where moving from the small teams doing devops Pockets within an Enterprise to an Enterprise White devops. implementation You know, there was some lessons that needed to be learned there some best practices that needed to emerge. But I think that's a myth that's been busted agreed panel.

Yeah, absolutely. If it hasn't been then we have a bigger problem because if you don't do devops at scale, then you have an organizational problem you can't do. You starting that way is great, but it's got a scale.

If it doesn't work across an Enterprise then we need it to work across the Enterprise. Yeah. Yeah, and I think that that myth.

Yeah comes because a lot of organizations they just get stuck right they know that hey, these are all the things we need to do, you know, we need to integrate testing into our ci/cd pipeline. We know we need to implement all these different things that the devops gurus that everyone tells us we're supposed to do but when they get stuck they kind of revert back to okay. Well this is working for me.

So therefore devops isn't working. It doesn't scale. So you have to be this unicorn type company to get it to work.

So I think help you know to spell that myth is the fact that every organization because they are so different and they have all these different pieces, you know organization need help to get over that home. So I think when they get stuck and everyone looks at it as if okay, well I can't be like them because they're just doing all these great things like but we're not seeing the things that are happening, you know beneath the iceberg everything that's been going on to get them to that level and I think that would really help the spell that myth as we start. Okay.

How did you do it? How did you go about it or you're more like me in my company set up in profile and and resources how do you do it? And then I think we can help dispel some of that and get to the realities of you know, how different companies can truly Implement devops and organization.

You know, I wonder if it's to your point Roslyn if it's a developer mindset right not being a developer. It's thinking about you know, automating. It's thinking about not doing throw it over the wall.

It's thinking about flow through a process. And we might play in different parts or several parts of that pipeline, right or we have a specialty area that we're part of but it's not an isolated part. It's an interconnected part and you know one of the Best developers I worked with said I said, why are you so good.

He says because I'm really lazy. I don't like to write code. I don't have to write you know, it's like we'll make it easy make the process simpler make it flow easier that kind of thing and that's that's part of that mentality you talked about culture you can think of it as a mindset the developers have that.

I think we're spreading and adopting aspects of that in different roles. Yeah, just add to that. I'm sorry glad I was just gonna say there needs to be a better word for that.

I mean, that's the reason I mean I say everybody becomes a developer because they're a set of tasks that we have Associated traditionally with the developer, but honestly a business person who's riding business process automation needs to follow the same practices and you're not gonna really call that business analyst at developers. So we got to come up with a new word, but that's the type of task and I think that's what I think because of that that's why we come up with some of these myths I mean, are test is absolutely critical and there's some test things that that yeah, they're people that are just really good at it that really yeah, that's really good. That's really important.

But in many ways they're doing a lot of things that developers supposedly do so, you know, how do we change the wording? To help the get rid of the myth that it's only for Developers. Well part of that is the myth that testers are somehow failed developers or not yet developers, right?

That's why I like to use the word professional test said by developer who didn't want it. It wasn't very good at testing. Right?

Why don't we tell you on that, you know here here's another one and it I think I will turn this question around, you know, the the Q&A was devops collaboration between business and it but it's a broader topic which is is devops. Just Devin Ops where where does security fit where does we're not busy we've seen deaf is Ops right some companies run with that. Yeah.

Okay. I absolutely no get up. Yeah.

Yeah. com has been the growth of devops Beyond just pure Pure Play devanops. Right, and I think that's a myth that we busted is that you know devops goes everywhere with this stuff.

and I I like to you say devops is a great Twitter handle, but it's not good for anything else. I mean, it's nice and short so it's great. It was a good domain name.

Let me just okay. Yeah. Yes.

You're right. It's very good to me. But you very good Saturday Night Live.

Okay, it's very helpful from that standpoint, but it is not representative of what it is. It really is if it's gonna work, it's Biz Dev QA SEC Ops, but it's the whole Spectrum Spectrum in order to work. So it's it's it's one of those terms that is not representative of what it Should be but it's a great term.

For use because it's nice and short and easy to say and we've got to get past. This devops is devops. That it really is everything.

Absolutely. Well, let me tell you what it's not it's not synonymous with cicd as more than a few people in the chat have put in here, right? I always used to like to say that devops was the symptom.

Cicd was The Cure? right and It but that doesn't make them synonymous. Right?

I think see ICD helped us. I mean think about where see I see the came from from where it was just CI and then we we attached the slash CD and now they're inseparably so sometimes you see them broken up again, right? But cicd is about software delivery devops is about so much more than just that integration and delivery.

So I think that's another big myth, you know pointed out by our audience here that we we busted over these years. What about some others? It there's another one in the chat the regulated Industries one.

Oh God where I learned that that was full of crap. Excuse me, what? You know, I used to go to he's the love going back then was called actually.

What was IBM think before it was thing grosseling? I don't remember something it we had so three or four shows that got combined into yeah. See that's the problem we had with oh head impact and we had something else but we had three we had different events that all the things.

Yeah, you want it and I used to go to with Randy and Celine back in the day. And what I noticed was who who was giving me their devops transformation stories. It was almost entirely Financial companies was it was Banks big Banks big Banks Her Majesty's Tax Service.

It's not African version of the IRS South Africa. you know all of these things and It really, you know taught me that regulated Industries. We're not.

We're not, you know laggards when it came to devops. well and devops how Things that helped devops help regulated Industries because you've got more automation. You've got more tracking.

You've got more they're all sorts of things that make devops and regulated Industries go together really well. And so that's why I think that's one of the worst myths out there because it really is a a tie a correlation in general Yep. Yep.

Um, man, we got some great shot. We could probably spend five days. Well, I'm just gonna throw out there.

I threw out of a sort of well, I'm probably gonna get lambastian for this better up this idea of flow. You heard me talk about this little recent company meeting Alan but it seems like that's what this is in part about it. I may be being theoretical metaphysical Kumbaya for a moment, but it seems like that's what we're about is.

How do we reduce friction? How do we eliminate barriers? How do we make things make the process of creating software from the beginning to the end?

It's security and all the parts. That are part of it and make that flow easier than it happens more and more quickly smoother with better outcomes. And it seems to be for me that I called it an earwig and just keeps sticking in my mind of this idea of flow.

Yeah. Well what if you talk about flow I start thinking about value stream management right quickly in the last year and a half is all of a sudden like we used to think cicd was kind of synonymous with devops. I think people are starting to think flow value stream management.

It's Anonymous with devops. But again, I think it's part of it all of it Sarah. Yeah, I would agree and I think the other thing that kind of don't tells from that not only the flow but value stream management CI CD is the fact that I think with devops we put a huge emphasis on tools.

So people think that if I have this so called devops tool that I'm doing the right things and you have all these different devops stacks and all the sudden you got these hot devops companies that are ipoing and going public and all the other things. So people assume that okay, if I'm using these particular products, then I've got this devops stack. So it's all about the tools and if you don't have this particular one, you're not doing it right and you can't do it.

Even if you're doing developing desktop applications or we're trying to maintain Legacy applications. And so it becomes more about the tool versus the Opportunity to really understand how should we properly go about doing this and that the tool argument probably is the biggest myth that just drives me berserk. You know what I find interesting about this and I'm sure Rosalind remembers this early on when you used to talk about quote unquote devops tools with the devops.

Illuminati as I would call them right the the leaders of the community early on and I used to really irk them. Because devops was not about tools. They would tell you devops was about people devops was about culture.

Not tools not tools and the idea of a devops tools was his asset line to them as a devops engineer. Right, basically great. Yeah, that's oh they reject if you had that in your title, you can't use that in your time devops teams devops devil None of these.

I mean so devops culture and the only reason I'll admit that I didn't quite object to having devops in my title, which you know, my first reaction was wait a minute. Let's come up with a better title was that my role is to transform the culture. Within the cio's organization for and so it I'm okay with saying we want to change the culture and that's what we're driving but having a devops team that does devops and everyone else Works differently it.

Using devops in that way just confuses everything and devops tools are actually one of the worst because having devops in your product name you kind of go. Well, what does that mean you do? Hey if devops is culture, how do I have a tool?

And so if if we could get around them get out of the myth because there are lots of tools depending on what you're doing. And and there are you know, there are people that are helping change the culture and I get that but let's make sure we're using the terms the right way if somebody's a cicd engineer or their cicd team. Why aren't they called see ICD not But devops is so cute.

It's just a better name. That's why yeah. No, it's it's these you said to catchy social media title a good domain name and it's about effects, right it also it also helps on LinkedIn for a lot of folks, right?

Oh, you know we had We obviously around a few different linkedin's group LinkedIn groups and it just amazes me the amount of traffic and people join it. I'll tell you another myth that I was glad to actually really really glad to see broken. And again, this one was personal to me when we first started doing devsecops.

Right. I didn't know what to call it. At first.

We called it rugged devops, right my friend my friend Rich movie. It's wicked. Well, it was James Wicked who started the road.

That's right James. Did you write? Yeah, and you know rich rich in those guys adopted it Josh Corman a few others, but so many of our friends Mitchell in the security industry where like oh, yes, right.

There's no such thing. It's all just devops and putting a second. It's just marketing mumbo jumbo blah blahs.

We can't wear the people who say no God darn it like the knights who say me, you know strawberry right here. I'm doing right But anyway showing my age here, but you know over the years we've seen devsecops. is real the idea of Shifting security left the idea of asking developers and testers and everyone involved in the software delivery to care about security to make security part of their responsibility has really caught on.

It's really caught on and I will tell you in spite of software supply chain attacks and everything else. We've lived through these last couple years our security on applications today. Is many times better than it's ever then.

It was prior to deaf secops now is devops responsible for that. Maybe partially but you you it's hard to argue that our security posture today is is improved versus where it was seven years ago. And and I think devsecops is part of that.

Big part of it. Anyway, I'll get down off my soapbox on that way. I think I think devops culture of trying to bring people together trying to automate trying to improve the reliability of the system all of that.

The only thing it could do was bring security and everyone else along because if you don't include security, you don't have a solution. Anyway, you can't you can't have a devops culture unless security is part of it. And I think the reason we do death sack UPS now is is so that people think more about security because reality is there's there are too many things going wrong.

I mean the log for J. Thing that hit there are lots of Open Source packages that are having things happen that people need to remediate quickly. There's lots of considerations and I think security is just one that everybody needs to be thinking about more and that's why it got thrown in.

I I sort of wondered why it didn't first become Dev. QA Ops or something? We needed to get that.

A devops culture doesn't work unless testing is part of it. And so security being thrown in is because security is such a central Focus that everybody has to think about but somehow we have to make sure everybody remembers all of these pieces are part of it. Really?

I think that also influenced all of this is the evolution of our software architectures refer to it as models now and so for service oriented architecture now Cloud native as things got smaller and smaller that'll let us allowed us to deliver smaller and smaller components and do many of those faster than one thing that three or six or nine months to deliver. Well that that now that you can do that in small increments. You've kind of got to rethink about how I'm going to do that.

you know in the environment where I also have really a lot of resources available to me in the cloud as opposed to you know fixed set of Computing and storage and network assets that all that all also helped create this environment to how do we automate how do we create workflows and automation across all of that and deliver things that more than you know once a week or once a day so it seems like it's not just a devops thing. It's also the environment that this is growing up. Yeah, and I think the other reason that probably QA didn't get added to the middle of that is because I think there are a lot of organizations.

They assume that QA is just doing the traditional old school UI testing although, you know, everyone assumed that you're doing unit testing they look at okay you got this UI testing UI test is gonna slow us down. So just cut it out. But there's a lot of things that really Define quality that I think that's left out.

You know, you have feature Flags, which is a part of quality is not testing per se but it's software quality. So we look at quality overall. I think those are the things that cause that this as to there's no testing in davops or one does testing or you only doing unit testing that nature but no, it's just in terms of how the with the rapid Pace things have been changed things that modified but that assumption that okay if I'm Or UI testing is way too slow for us to be able to implement this and we can't do it.

We can't do it properly. So I think that's probably the main reason it was left out. And then the goal was to really Target a lot of these organizations through the developers and lessen the testers because they're trying to go where the money is.

So I think that's the economic piece plays a huge part in that. Okay, so Here's another one. I saw mentioned the chat.

Well, they and they mentioned one aspect of the but again, it's a Gemini right where there's this it comes out from both sides at the same time. And that is that devops cannot succeed without top-down support. So it has to be it's not originated at least supported.

By the very highest levels of your it organization or the organization itself. And then the the flip side of that though is that any devops implementation that is kind of forced down the throat of developers and operations people is bound to fail. You must have the support of the people down here.

In order for it to succeed because you can't change what those people do they do what they want or they'll get other jobs. Hey, maybe that's the reason for the great resignation. But well done that argument.

Do you think that people who started doing devops went and got approval from the sea levels to be able to do it not originally water originally. I think there's two side. I mean, I I think there's a reality in the middle.

I I really think you need both. I think you need people who want to change and you need some level of support from the top because it's really well depending on the company. It's really hard to actually change and put in up, you know a devops culture in just one team if they don't have some support.

To make some of those changes if I don't have permission to deploy into production. I'm not going to get it without. Getting permission.

So so there's probably the myth is wrong because you can't start either where either place but there is some amount of I need some level of support. Maybe it's not sea level. I mean that might be way too high.

I need some level of support high enough that lets me change the way of working because I'm changing the ways of working but I haven't seen many successful that didn't have people at the bottom wanting to do it. I mean unless you had teams who really wanted to change. I haven't seen many so I'll give you caveats.

There's some that have they've come from the top and been successful. So That's a tough road. Yeah, that one's a lot harder.

You usually have versus volunteers is that Right here you ask for the volunteers from the top so it didn't come from them, but you get them, you know. But yeah. you know interesting we see a a reference in the chat around log4j.

Yeah, or you know, hello 4J I haven't. I don't think that was a devops problem per se but I I think what's happened is quite frankly, you know log, we build these modern apps and infrastructures using open source components and in terms of supply chain, you know the virtual mimics the real life, right? We found out what happens when you rely on one country to supply all of your surgical masks.

Right, and then that country stops exporting surgical masks and you don't have any. Well, it's the same thing when when all of our infrastructure or absolute depend on one piece of code and that code then has a defect. Right.

We all pay the price. And but I don't. I don't know if that's a particularly or specific a devops problem.

Are we pinning that problem on the devops donkey sale? Or is there a devops solution to it? I I would can Tend that those organizations or teams that were farther down the devops cultural transformation could deal with a log4j thing faster than those who were not.

so if if you were if you had enough Trent and honestly actually even if you didn't have a devops culture, if you at least had a cicd pipeline you were more likely to be able to fix it faster than if you didn't and and I and I do I do think technology and the pipelines the devops does not equal pipeline pipeline is a critical part of a devops transformation and that automation does make handling things like log4j easier, but you have to You have to be looking for it in the first place. I think I think log for J. Hopefully triggered the thought process.

I need to be scanning. I need to be paying attention. I need to be thinking.

I'm I'm not I know when I learned about development. We didn't go out to the internet and pull code in the same way. but when we did share code ideas between us we thought about the code that we were bringing in with these open source packages.

You don't think about the code in the same way and I think that that cultural change to thinking about the code that you're bringing in is also really important. You know like for Jay. Jump to the top of the list not because it was a vulnerability for logging in.

Yeah, it was impactful. It's the huge breath the impact because of where log4j was used the widespread use of it. And you know, I think maybe we should think about maybe devops as part of our resiliency.

Just like we think about our sun architectures being more resilient vulnerabilities are going to happen. No matter what we do apply AI to it, you know, you name it it is still going to happen. And it's our ability to respond to it.

Whether it's as you know widen deep is large for J. Or you know in our own app that not is that a part of code that didn't get executed. And we have to be able to respond to those.

So I think maybe that's part of where you were going Rosalind Rosalind is it's our ability to respond in that process wherever it happens is what kind of matters now, yeah, I I don't think we can necessarily Stop Those. type of defects Vulnerabilities, but we can we can pivot quicker and respond to them quicker, you know with the devops mindset if you will devops culture. Hey, I wanted to just take a quick minute guys in announce.

We have we have four Amazon winners as I mentioned at the beginning the winners today are Joe a Maureen G Dave S and old the so congratulations to the four of you for winning Amazon gift cards spend it. Well, enjoy it. Thank you for registering in attending today's Roundtable.

We have a as I said earlier we can go on for days just with what our audience has put in here. So but I wanted to start bringing this thing in or wrap up. We usually do these for 45 minutes is around table, and we're at 45 minutes now, so we'll take some time to wrap up but You know, first of all Clint I want to thank you because you know what whenever whenever we we ask you always answer the door for us, right and I appreciate you coming on here.

So I wanted to give you I wanted to give you the opportunity to start our kind of wind down, you know. With what? What do you what can people take out of this?

You know, you've we've had a robust discussion. What do you want them to remember and take out of this? Great question and thanks again.

I would want the audience to really take away from this is that you're not necessarily doing it wrong. When it comes to devops, but really take a broader view of what it means to your organization, right? Everyone's different.

I have two kids. They they couldn't be more opposites than you can imagine and I think we have to approach devops in that same manner and we have to look at our organization. So what I would suggest is, you know, don't necessarily compare yourself to how company a is doing it.

But look at what is going to be best for my team and my organization and how can we get through this? So that's what I'd like to be the biggest takeaway for everyone. A great good stuff right there Rosalind.

And again, thank you for all not only what you do with us, but for the community at Large But what do you want people to take out of this and remember and take home? But I think I absolutely agree devops is the culture that you make it it's the culture or that you're trying to transform your organization to and you can't copy company a or Company B, but we need to learn from each other and the devops community is really good at sharing. This is just one example, all of the things that you all do are examples of that sharing of best practices.

We need to hear and learn from what other people have done. So we don't necessarily make the same mistakes. You can't copy exactly company a but you can hear what they did and you can take that and take those Lessons Learned you don't need to start at Ground Zero.

We've you know, we've got 10 years 20 how many every years of devops practice sorry, I think devops started long before the term devops existed. We've had this for a while this automation, but this Culture learn from the community and share in the community and work in the community because the more we share the more we all learn from each other the better off. We're all going to be because love for Jay.

Yes, it was big but it's code. It's software. We can't write there's no perfect software.

I mean, sorry, there's no there's just not gonna be perfect software. So we all have to work together to make sure that we're improving because software is now everywhere and our world depends on it. And so it's really important that we get it good enough.

So that lives don't aren't affected as they could be. Absolutely Mitch before I go to you. Someone had asked they didn't hear the fourth name.

Well, so the more winner was Olga V like Olga korbit that said too old for most people to remember old, but it was unique 76. Anyway, that's going back. Let's go.

I was a little boy myself but way back all good job opportunity. There was devops then too. We just didn't call it there just didn't call it.

Oh no back then that's probably pushing it a little sorry. Right and also before which because I want to Echo what Mitchell put in chat, which is you know, these round tables are only as good as the audience makes them and this was a great audience. I loved having every single one of you on here participating.

I appreciate it. Keep coming back, please. But Mitchell go ahead you give it to you.

You know, I think it's about not being the smartest person in the room. You're never gonna be the smartest person room because everybody is smarter at something that you are and just like this conversation, you know devops being a multi-discipitary cross-functional team same thing here. We're having some great conversation and I would argue some of the comments or as more profound than anything.

Certainly I said here maybe others on the panel too. There's just some fantastic view points and ideas and ultimately we're on a journey and you can you know go fast alone, but you can go far together. So appreciate everybody being together with us on this journey.

Absolutely, and we appreciate tricentis sponsoring devops up down. We couldn't do that. We couldn't do these shows without them.

So great. Thanks to our friends at tricentes check them out. We will be back I guess in another week or every other week.

So two weeks won't be alive Roundtable. It'll be a devops Unbound video session. com after that and always good stuff there.

Guys, I all three of you. Thank you so much. Thank you to our audience.

I thank tricentes thanks to our engineering team behind the scenes who makes this happen earlier and the team appreciate it. Thank you all for attending. We we couldn't do any of this without an audience so until next time, this is Alan Schumer wishing you all to be well be strong Tech strong.

Take care everyone, bye-bye.