DevOps Building Blocks Part 6 – Day 2 DevOps, Operations and SRE – DevOps Unbound EP 43

Hi, everyone. Welcome to DevOps Unbound. I'm Alan Shimmel, your host, and this is another episode of DevOps Unbound.

For those of you who are not familiar, maybe this is your first time watching DevOps Unbound is a biweekly meaning every two weeks, uh, video series that we do here in partnership between Textron Group and our good friends at t tricentis, the worldwide leaders in continuous testing, and we explore relevant topics in DevOps of all. Thanks. Uh, we've been doing this I almost three years now.

We love it, uh, about every third episode of DevOps about, we actually do it with a live studio audience where you guys get to drive the questions, the comments, the conversation. Unfortunately, today's not one of those days. com.

But, or maybe you're watching this even on the tricentis site or YouTube, but wherever it is, we're glad you can join us. Um, we've got a great show lined up for today. You know, the last couple episodes of DevOps Unbound.

We've been on this arc called DevOps Building Blocks. This is the last block in the DevOps Building Block series. It's paid part six, and we're gonna be talking about really cool things like day two, DevOps operations and Ops and DevOps and SRE, which is always a big, big category.

I mentioned this is a joint production with Tricentis and many, many thanks to Tricentis. We couldn't do this without them, not just their Spencer sponsorship in terms of writing a check or whatever, but really they're a full partner with us in every sense of the word here. They, they, they help craft the, the abstracts, the topics.

They help us with guests. They, they've just been fantastic to work with. So a huge shout out to Lanier nor, and the rest of the Tricentis team.

Let me introduce you to a, a great panel that we've got lined up for you today. First of all, he's up in the top left on my screen. I don't know where he is on your screen though.

He's on my good friend formerly of Con Con of Comcast, but he's been with Contrast Security now for a couple of years. He's just a, just a fireball and a, and a great source of knowledge. Larry Ma Macaroni.

Larry, welcome. Thank You. Good.

I'm glad to be here. You know, I tried to, I went skimming over your background, but why don't you fully introduce yourself? Uh, sure.

I mean, so I was the head of application security for Comcast for five years, 10,000 developers, 600 different development teams, lots of different properties. So scaling, uh, development and DevOps and DevSecOps in particular is sort of my, um, my specialty. I now work at Contrast where I help other companies, uh, do this, so, Absolutely, and it's a pleasure to have you here, Larry.

Next up, she's on the top right of my screen. Um, is our friend Adriana, Ella, Adriana, if you wouldn't mind introducing yourself. Yeah, hi, uh, my name's Adriana Ella.

I am a senior staff developer advocate at ServiceNow Cloud Observability. You might remember a former name, LightStep. Um, I have been, um, I started out my, my career as a software engineer.

Got into the DevOps and then, um, just naturally made my way into the observability space, and that's where, uh, most of my work is. I work, uh, with the, uh, with a lot with open telemetry. I'm part of the hotel end user working group, and I love talking about observability, and I also dabble into some platform engineering.

Interesting, interesting, interesting. Thank you for joining us, Adriana. Next up, he, uh, bottom left on my screen.

He, he always, he always have his great things to say comes from his own life experiences. Many years in the performance engineering space. Our friend Brian Cole.

Uh, so hello everybody. My name is Brian Cole. I'm the director of customer engineering for Neo Load here at Tricentis.

And I, my background has specialized in performance engineering, but more broadly in the quality engineering space. So I have seen the evolution going from Waterfall through Agile into DevOps and what has to happen to the quality organization to remain meaningful participants in the process. Excellent.

Thanks for joining us, Brian. Next up, bottom right on my screen, so you can tell I'm going left to right, top to bottom. Right Next up is Anna Margarita Medina.

She's been on with us before as well, and it's a pleasure to have her back. Hi Anna. How are you?

If you wouldn't mind introducing yourself. Hey. Hey.

Happy to be here. My name's Anna Margarita Melina. I'm also a senior staff developer advocate with ServiceNow, and I sit on the cloud observability side of stuff.

Um, I come from a self-taught background and software engineering. Got into the front end backend mobile development, and I've been focusing in reliability for the last eight years. It all started as I worked in the start reliability engineering team at Uber and then transitioned to doing chaos engineering with the startup call gremlin.

Um, and been focusing on observability the last two years. So just a little bit of, uh, here and there of SRE uh, pillars. Thank you.

And thanks for joining us. Can you say your name again for me? Anna Margarita Melina.

That's, if you say no, mattera matter what? I just can't make my tongue do that. Damn.

That's, that's great. I love it. It's a beautiful thing.

It's great. That is a beautiful thing. I I, I try and try and try and I'm like, ugh.

Anyway, it's a really well though. I, well, the best I can, you know, I I, I'm starting behind the eight ball there, but thank you and thank you for joining us and what a great background. Get some interesting folks from the observability space and you know, one of the things I, in my mind is when we look at where the action is in ops and, and a lot in DevOps at Cloud Native as we'll see in CubeCon in another week or two, observability is, is on fire, right?

Like, we see those little, you know, those, the little fire icons next to stuff. And, and that's a big part of this day too, I think DevOps day two, but, you know, when did you first hear the term DevOps? Day two?

DevOps. I remember when I did, but let me throw it out at the panel. When did you guys first hear the term day two DevOps and what does it mean to you?

Who wants to go first? I'll go all head in first. Actually, before we do, I gotta stop us a second.

I, I messed up. I forgot to introduce my co-host Wonder, and I've done this before. Wonder.

Yeah, no, I, I got so enthralled with the way Anna Margarita said her name that I lost my head. I apologize you, I, I missed it too. Um, joining me as always, my, my co-host here on DevOps.

I'm down Dana Tech Drug Group is my friend Mitchell Ashley, who's our CTO and principal research analyst. Mitchell, say hello. It's a pleasure to be here with everybody thank you panel for joining us.

Thank you. All right, back to it now. So day two DevOps, when did you first hear it and what, what does it mean to you, Brian, you were gonna go on that, right.

Well, I probably heard the term first in 2019, really as a reflection of the, the understanding that DevOps, the conversation that I'd been involved with prior to that was very dev centric. It was all dev. In fact, it was very focused on the CI pipeline.

It was very focused on aligning the development tool sets to help drive the software delivery process through. And a lot of organizations coming to the realization that saying you have a DevOps process that ends when you hand over to quality assurance is not a DevOps process. Uh, and it needs to go substantially further than that and involve the IT operations teams.

Excellent. Anyone else? Yeah, if I may chime in.

Um, I, I honestly can't remember when I heard the term day two DevOps, but I completely agree with what Brian was saying because, um, I did find, and it was around like 2019 where we were at a point where like we got the CI pipelines absolutely nailed. Um, but we were still not getting that velocity that, you know, DevOps promised because we were still stuck on the delivery portion. Um, and I think, uh, you know, I, I think part of it is, is we didn't give enough TLC on to the delivery side.

I think also we had a little bit more resistance, uh, depending on which organization you were in. Like I, I worked at a large financial institution where like everyone was like super gung-ho on the, on the CI pipelines, but when it came time to do software delivery, they're like, just gimme the manual instructions and I will follow the instructions and I don't want to learn any other tools to deliver, and I don't care if you have better tools. This is how I've done my job and I'm okay with that.

And so we really, really need to move past that. Um, I, I think we're, we're starting to, uh, but, but definitely like back, back in 2019, we're certainly stuck at that point. Excellent.

Anybody else? I think for me I'll, Oh, go ahead. Go ahead.

Go ahead Anna. Andy, you went first. Santa Margarita, you go.

Uh, I think for me it was around like 2018 when I was working with like the sales teams at Gremlin. Like they were putting slide decks, do pitches and stuff, and they're like, chaos engineering is one of those perfect things for day, day two operations. And I was like, wait, what does that mean?

Like, I've heard of day zero, day one, but like, what is this? And it was really coming to that understanding of, like, you, especially when we're talking to a lot of startups, they think that by buying tooling they can just check things off. And it's like, alright, we have CICD, we have observability, um, we have this for on-call, but being at, at gremlin allowed for us to kind of be like, well, you have all these things in place, but how constantly are you ensuring that you're practicing them, that you're training folks?

So it made day two become like an activity of like, how do you get ready to withstand anything that can happen as your business is scaling and being successful? Like, let's ensure that you are going to be ready for those chaotic high peak traffic days. Agreed, Larry.

Yeah, so I mean, the, the sort of traditional definition I've heard for years is when the fun stuff of is over. When when you've got a product that you can get customers to use, then, then, then it becomes a problem for day two DevOps. That, that line though is really very fuzzy though, right?

You, you probably need users in Agile and DevOps world long before you get to that point where you're ready to start optimizing for the ilities reliability, uh, performance, those sorts of things. And I think it's when you get to that point of scale that you really need day day two DevOps. And then that's how I've, I've come to think of it.

You need people dedicated to essentially focusing on keeping it the site up and, and, and keeping it performant for the users and secure users as well. And this is a kind of a context Point that I've had with customers over the years. Understand your application, understand your business.

There's not a lot of value in investing in the rapid delivery of software changes to something like your HR system that isn't customer facing that doesn't require a lot of changes. Like as long as everybody's getting paid, great, don't touch it. Leave it alone versus your marketing engine.

These things should probably be updated extremely frequently. So prioritizing your effort, knowing your business, knowing the levels of risk. To your point, Larry, about security, there's a big difference between, uh, running a phishing supply store and running a large financial institution in terms of the types of attacks that are gonna be coming your way and the level of effort you need to put into hardening your systems and making them secure.

So, Yeah, I mean, and I, I think the, the cloud native movement has sort of helped or, and hurt at the same time, right? 'cause you've got the developers thinking, oh, I don't need an ops team anymore. I can just use my cloud native tools and just push it.

And, you know, the reality is, is that for the vast majority of these small internally facing apps, I mean, enterprises like Comcast have thousands of apps and only a frac a small fraction of them actually call for a dedicated team, SRE kind of team focused on, on optimizing them and keeping them up. Hey Mitch, you wanted to say something I thought before? Yeah, I was just, and I appreciate everybody's perspective.

'cause I think it, it all makes sense to me. It, it seems to me like day two DevOps is a recognition of moving something into production isn't a light switch on or off, right? It, you go through an iterative building up the reliability, the security, the um, resilience of the application performance, all those things.

You know, they don't get to a hundred percent or whatever, whatever measure you want to use, you know, in a few steps. It's an ongoing process. As people start using the applications, you're adding more stuff to it.

And I really like the focus of day two DevOps because it, it, it gives us something to say, well, there's more than just handing over what we created to somebody else to operate, right? Which is very much our old mantra I idea like, uh, hypercare, right? Yeah.

This from the SP space, you release, uh, hopefully everything goes perfectly, but usually it doesn't. It's not, doesn't. And there's time for incremental changes and improvements that are happening now that you're in production, but you Don't.

But that's the DevOps way, Brian, right? Uh, See, i i feedback loop. I kind of don't like that fail fast methodology because wouldn't succeeding fast be great?

Let's go with that approach on things. Yeah, I know. But, but yeah, you, we live in the real world.

I mean, yeah, I'd love to succeed fast all the time. We're not, and and so this is a very similar thing to what we face in security. Larry and Mitchell will agree with me here.

We could put all our eggs in the prevention basket and then when something goes wrong, we got a lot of omelets. Or we could put a reasonable amount of resources towards preventing and have a reasonable amount of resources towards reaction when something does happen. And so, to me that there's a great example.

This really hits to the, to the nitty of day two DevOps, which is we live in a real world. We need those feedback loops. It is one of the three ways, right?

And, and all of that good stuff inherent to DevOps. And it is day two DevOps. And we're going to need that.

That's how we get better. We're never gonna, if we try to live in a world, and I get it as a test engineer, right? We wanna, we wanna make sure we test everything so it works.

And of course we do. But we need to live, you know, to recognize that the world we live in, things happen Shades of gray. Yep.

I, I agree. And I, I love the idea of fail fast and I think like organizations should embrace it. But what happens when you're in a large enterprise where you're like so mired in the approval process, like, it's so lengthy.

And, and I think that was honestly like such a barrier to, to failing fast. 'cause it, it's so easy when you're in a startup, but like, you know, when, when you're having a deal with like five levels of approval just to get a change into prod, I think that's when you, you get in into trouble. And I think that's why you're, you might not even see like that, that velocity in, in larger organizations.

Yeah. I don't know if anyone's had, uh Oh yeah, no. This is Like, how do you get past that?

Yeah. I would love know, speaking exactly to it, right? Uh, the large enterprises, whenever we are talking to customers about, oh, you want to use cloud-based load generators to run a performance test?

Awesome. Here's how you whitelist your ips. And they're like, great.

That'll be a three week turnaround time with the network security team too. If You're lucky, it's three weeks Lucky. That's Good.

Your velocity evaporates in a hot second. Yeah. You're starting to talk about provisioning these things in one minute to be able to start your test after a three week delay.

com, because in my view of the world, right, moving from left to right, we've done a good job of adopting Agile for the most part, right? It's 25 years old. Yeah, it's pretty well understood.

It's pretty well settled. It was, it was set, you know, they had a manifesto and everything to begin with. It's been 12 plus years on this DevOps kick.

It's more than a kick on this DevOps train. And at this point, you know, it's matured and we've learned a lot of lessons and we, we get a lot of the cultural things around DevOps and we, we understand how agile and DevOps kind of combine and, and we're releasing code faster than than ever. Is it better quality?

I say yes. Is it more secure? I'll say yes.

Is it perfect? Hell no. I think the third, I think the third piece of this continuum is that change management piece.

It is that IT service management and IT, and all of those things that actually are older, older than DevOps, older than agile, but need to be dragged kicking and screaming a little bit into the modern world where we got, we've gotta do 10 x releases. And so the challenge of day two DevOps is making it work with the ITSM models of the world, with the change management, with the its of the world, with the project managements and, and, and allowing us to maintain that velocity without sacrificing quality. That's, That's the key There.

There's a contention, right between the two different organizations. The app development organizations are essentially being paid to change things all the time. Whereas those ITSM processes are there to essentially say, look, if it's not broken, why are we touching this?

Don't make any changes. And it will continue to work. And there's a tension between these two viewpoints that the DevOps message can be used to bridge very effectively, to talk to, look at all the checks and balances, look at the work that we're doing to ensure that these systems are stable, reliable, high quality, all this kind of stuff, and that it will roll in an automated and well understood, well-documented process into your production environment and not break anything.

I mean, Larry, you got your hand up? Yeah. The, the, the, I I, I've read dozens of different studies and, and that, that sort of touch on this at least and some that are directly focused on it.

Um, the reality is, is that the ability to release to production really rapidly, actually dramatically improves your reliability, your security, your performance. Because you've, you're exercising this deployment process regularly, even when you don't have to deploy it fast and you're, you're, you're getting it faster and faster and faster. And then when you do have an urgent need to release something new to production to fix a problem or to address a, a down, uh, an outage or a security incident, you can do it fast.

So, so you're actually more secure. You close the window of risk, the window of exposure, the window of downtime dramatically. Uh, and that, that reacting fast is really sort of the key.

Yeah. The automated deploy, it's Flexing those muscles, right? Yeah.

I'm sorry, a Adrian, I lost what you said. I'm sorry. No, I was just saying it's about flexing those muscles like you get in the Yeah, well, it's about muscle memory too.

Yeah. Doing it and, and so like making it part of that core culture, right? Which I, I think, and that's the hardest part, right?

It's like, I wanna start exercising. Oh, that sounds so annoying. And then like, get into it and like, okay, I can, I can run faster, I can run farther.

Oh look, this is great. Agreed. Well, you know, we've been through this transition a couple times too, or this transformation, right?

Remember the development, Dave, of what we're gonna release once a week, once a day. That that's insane. How, how can we, how could we more or less, why would we subject ourselves to that?

Now it's like, that's, of course we would like to do that, or are doing that. Seems like that's the maturation cycle we're going with day two, right? Is how do we bridge, um, how, how do we help, um, transform our thinking about how operations and development work in this more continuous cycle of delivery?

And what does that mean and how do you adopt what you do well and what do you adjust to make it flow better? One. I'll go ahead, Anna.

I, Adam, margarita, I'm Brian, I'm coming back to you, I promise. But Adam Margarita hasn't been talking enough. I need to hear from her.

I got this. Um, I think some of it goes with like speaking the same language. So for us, like working in the observability space is like that ITSM team actually does have to be looking at the similar stuff that your SRE and your DevOps day two folks are looking at.

That way everyone has the same information. And I'll go back to my chaos engineering days where, or like low testing days too, where it's like you constantly wanna be running through scenarios in order to know. Um, and I meant to piggyback off earlier when we were talking about like, fail faster, go a little slower.

And you do have to see those moments of uncomfortableness where you kind of get to look for those Oh no, no knowns while practicing those known unknowns that you do have in your infrastructure and your application. So we do have to find ways to get out of our comfort zone, whether it's talking to the teams that are always grumpy at us or whether it's like, Hey, we are not necessarily sure how this application is gonna survive when we scale the load a little bit more, or when we are launching something new. Agreed, Brian.

Yeah. And, and one endemic challenge that I still see across the many customers that I speak with is, how does the IT operations team align with or get development aligned with their tasks as well? One of the big challenges that I see out there is the IT team is looking at their Oracle database and they're planning an upgrade to a different version.

Meanwhile, development doesn't know about that. They're not aware of that change, they're still continuing to work on that. Or worse, they're just using whatever version of Oracle they want with whatever system permissions.

And every development effort is done with full cis admin rights. And then they're wondering why it's not deploying properly in production, not working properly. In that context, there's a huge amount of alignment.

And this came out of the SRE space and has really led to the rise of platform engineering as another discipline on top of and Aside, alongside the DevOps effort. Agreed. Larry, you wanted to go back to something Adriana said.

Go for it. Yeah, so, so, you know, as you know Alan, and maybe the audience doesn't, um, I, you know, my background is development. I, I'm still an active developer, right?

Code almost every day. And primary author of a dozen open source projects, one of which gets a million downloads a month used by every cloud, NA cloud vendor and every cryptocurrency exchange, et cetera. I mean, so I'm, I'm very deep on sort of the developer side, but my day job, what I get paid for is essentially more on the, the operation side, more on the security side of things.

And so I, I sort of have a natural ability to bridge that gap. And, and I, I, I was a agile transformation consultant for years, and I learned essentially that just having a great idea of, of a way to operate is, is just a small part of solving the problem. You have to actually get entire large organizations to transform.

And so I, I talk about, um, organizational pathologies that you have to overcome pathology as in like illnesses, kind of kind of thinking. And, and these are things like, like we hinted at earlier, local optimization, right? The, the ops team is optimized for staying up and change results and going down.

So they don't wanna do that. The development team is optimized for new features. So they wanna, they wanna, you know, ship ship faster.

Things like, um, uh, CYA thinking and leadership, right? Sometimes people know that the evidence, scientific evidence for doing something is strong, but all their peers at other organizations are doing it the old way. And so if I just do it the old way, then I am not, not like, liable if something goes wrong.

But if I try the new way, then I'm more, I'm more liable. So you have to use psychology and sociology and, and, and sort of changing the organizational structure in order to overcome these. And, and that's sort of, sort of, I think the, the key to, to getting at what Adrian was talking about earlier.

You know, Larry, I Would say to add to that, um, you know, the, the, the other thing, and I, I learned this early on in my career where I had like lofty goals and lofty ideas of changing things and coming in and telling people the way you're doing it sucks is Not going, that's not the right, that not gonna result. Yeah. You have to be very gentle about it.

And, and, you know, you have to make friends and you have to be like, look, this is why this is such a great idea. And you almost have to like, you know, find some allies in, in the individual contributors, but also in the executives, right? Because you, you need like that mandate from the executive level, but they have to be bought in.

'cause there's like executives that are told like, thou shalt do this transformation because CTOs said so. And they're like, okay. Um, and, but their, their heart's not into it.

So you need like an executive that's totally into it. You also need some individual contributors that are totally into it. So you have that nice little convergence to make that transformation happen.

I, I found that the higher up you go in the executive chain though, the more likely they are to listen to evidence and reason and logic and, and be willing to sort of do experiments. And that's a key lever you have, right? Oh, we're not gonna do this for everything.

We're not gonna do this for our crown jewels. We're just gonna do an experiment. And then you have, that's how you build those allies.

That's how you get the local evidence that it works. That's how you prove that it's safe. For the mid-level managers, it's usually the grassroots people are okay, the high level executives are, okay.

It's the mid-level managers that have the most to lose in change. 'cause their world changes on them. They lose their domain of control.

They, their, their expertise was built basically incrementally as opposed to by, um, you know, being just a, a huge talent. Usually those folks are in the high executive ranks. Um, so, so you, yeah, you, you gotta work from the top down with the executive sponsorship and from the bottom up with the grassroots with these, these experiments And for doing the grassroots and like getting those individual contributors like to get involved.

Like a lot of companies are like, I don't know how to do that. And one of the things that I've seen in the field that I feel like works really well, whether it's for S3 for security doing like championship programs in a way where it's like doing little courses. People come, they learn about the topics and then they start getting interested.

So they can have a little homework of like, how is it that I can take the security learning to my organization and make a little improvement? And then they do like weeks where they do more of these and then they go and the new ics like, go evangelize these concepts to other parts of the organization. So you're getting individuals to go do the work for you.

And they're now using their like political capital, their organization to be like, this is what we should do. And that's how like, new leadership also gets involved of, like, that seems really interesting. I often lament that in my education I took computer science and physics because psychology would've been so much more useful to my day-to-day of cajoling people into understanding that it's not about the technology that you have.

I often tell people, if you don't have 95% of every software platform, you need to run a full DevOps transformation, it's 'cause you have a hundred percent, you may be missing one little thing that you might plug with an open source or maybe a commercial product, but you've got all the tools, you've got your source code, you've got your ci, you've got the, the key pieces that you need. It's about how you use them and the structure and the interaction of the different teams who need to start participating. You'll hear a lot of shift left coming into this where the quality teams in particular all through the 2010s rebelled against this.

And like, no, that's a developer tool. I don't wanna learn how to use a source code management repository or a CI system. Well, the world is changing and we need to change along with it and keep up Amen.

And be meaningful Amen. To participants in the process. You know, it's interesting point.

I didn't know that we would go here, but the theme that I'm hearing over and over is change management skills and, and not change control board skills, change management in terms of people and organizational. And so, so it isn't just delivering code day two DevOps into production. It's helping the different parts, the whole organization be ready or, or start to adapt to the changes that are occurring, right?

Again, it's not just flip on a light switch, we're doing 10 deploys a day or an hour. It, it's a process to get there and it isn't a technology problem. Yeah, no thi this goes, you know, I asked each of you, what is day two DevOps mean to you?

When did you first hear about it? com, I probably heard it maybe before some of you, but probably not. Larry, he's a DevOps renaissance man.

He heard it before me. But, um, when I first started hearing about it, to me it was, it was so damn hard to get DevOps adopted and going not organization or enterprise wide just on a team Mm-hmm. To say, I'm gonna adopt, right?

We're already using Agile or we're moving from waterfall to agile, but I'm gonna adopt this kind of cross-functional approach and we're gonna do software pipelines and we're gonna shift left and we're going to, you know, automate as much as we can and do some continuous testing and, and we're gonna deploy with the press of a button or just automatically. That was such a hurdle that when people did it and not at an enterprise level, very few companies did it in an enterprise level, a small team within an enterprise, a segment, a division that when they got that first piece done, they were exhausted. They were like, they thought they just ran the mar marathon and they needed three days to recover or longer.

And the concept that day two was, okay, now you did that. Now the fun really begins. Now how do we operationalize that, make that our normal, not just the new but the normal?

How do we get it, you know, get it moving? How do we bust out from this little bubble where we're doing it and make it go organizationally across, you know, the entire enterprise? That that was quite a hurdle.

Day two, if, if day one DevOps was scaling Kilimanjaro, day two, DevOps was getting to, you know, uh, the Himalayas K two or, or you know, one of those. And it was, and it's hard. I think it's still hard.

I think it's still too hard. It's not as hard as it was eight, nine years ago, but it's still too hard. And part of that is cultural acceptance, right?

Yes. Mm-Hmm. Where people are getting more familiar with the concept, they're hearing the terms more frequently, they're becoming more understood across the industry, but also some technology changes as well.

Things are getting easier. The tools are getting better to help streamline some of the more egregious problems that we faced in the early 2010s. Uh, dealing with this stuff.

Uh, whether that's through plugins into your CI tool or better command line interfaces or whatever it is, it's just an incremental improvement. And there's never going to be a solid end state that we're all going to achieve and go, great, we're done. That's never gonna happen.

It always, DevOps is Never done. There's always more you can do. And it's not about the destination as much as it is about the journey and the value that you can extract from it.

Uh, there's so much that you can get in terms of benefit to your point, do it with one team and they feel like this is an enormous effort and they're exhausted by it. And then along come people like Brian saying, here's continuous performance. We want you to implement that next, or Larry talking about continuous security, or Anna talking about, let's do observability now, please.

Uh, it's like, there's all these other things that need to go into the process. This is great. You've got job security, everybody.

It's fantastic. Uh, there's so much interesting stuff that you can do. So I I, this, this is, this is an interesting parallel what's going on now to what happened at the beginning of the Agile movement.

I, I was essentially early adopter in the agile movement. And, um, I went to go work for Agile transformation organization, rally software. And, and, um, uh, we said, well, you can't do big bang agile transformation.

You have to do one team at a time. Agile transformation. And then three years later, somebody came in and said, we're gonna do a big bang transformation at Ford Motor Company.

And, and they're like, no, no, it's gonna fail. It's gonna fail. But they're like, no, we'd reached a tipping point where there was enough knowledge, there was enough sort of organic stuff that the Big Bang really wasn't a, you know, a a a huge lift.

And it actually was more efficient to do that way going forward from that point forward. So I think we're sort starting to get to that point. We're still not there yet where we could start to do a big bang transformation to essentially a true DevOps way of operating.

0 was like testing the waters and figuring it out, figuring out how it works. Mm-Hmm. 0.

We're like, okay, we understand how this works. Now there's like more moving parts, right? 'cause we're tacking on observability and, and we're hopefully upping our testing game and our security game, which we should have been doing in the first place.

But, you know, we're, it's a process. But I, I think, um, as we learn how to do these things and, and as was mentioned before, like we have better tooling around it. 'cause I, I think that was like a, a huge problem initially in, in, in dev in the DevOps movement.

It's like, okay, I get how this is supposed to work, how, like, but you've gotta have like all these integrations, right? It's like, I need this part and this part and this part. How do they all play together?

Can you make it easier? Can we codify? So like now we're codifying our pipelines.

Like, you know, these are, these are things that we didn't have before. And which I think make it a little bit easier so that people are less scared of, of DevOps pipelines. 'cause I, I think that was one thing that was I think terrifying for, for some folks is like, oh, what do I, what do I do with this?

How do I do this? I don't, I don't get it. Right?

And I think some of it is not necessarily always more tooling, it's just more success stories. Whereas it's like we had like DevOp days come about and like they have their little unconference sessions where folks get to share the experience of like, this is what it was like to try to optimize our pipeline or how we are onboarding to a new monitoring vulnerability vendor. Or like, how do we actually set up on-call rotations?

Like, like we talked like change management is the hardest part. And how is it a better way to do that? But to have a success story that helps with it.

Or for someone to be like, this is how we did it, our organization. Like, come shadow us for like two, three days and then like learn how to do it. Um, but then I, I also wanted to piggyback off something Adriana said.

0. I'm like, wouldn't that necessarily just be the SRE movement in a way, um, that is like, Some people say it's platform engineering. Some people, people say it's observability, it's all part of DevOps, right?

Mitchell, we need to talk to these folks about DevOps next. We should get some of their views on it. Mitchell's working on a huge report right now.

It's kind of a flagship of for us here at Tech. I'm literally next. I know it's observability.

He's talking Yeah. And it is important. So, but that brings us to, you know, back to the abstract, right?

I hate to use the two oh stuff 'cause it's been cliched, but you know, things like observability, things like platform engineering, things like SRE have certainly extended the dev, the basic DevOps into DevOps, right? If, if, if we could think of it that way. I mean there's, there's more to this than just that CICD pipeline.

There's a lot more. Absolutely. It's about automating the delivery of all the underlying components that the software engineering teams need to do their job and deliver applications into production.

So if I'm a developer, I need a place to do a deployment of my web service, where's that gonna go? Don't rely on me, the developer to come up with the system, have the platform engineering team provide that to me in the same context that we'll be running in production. 'cause right away, if I'm a developer and I try to run it as if it's running in production and it doesn't work, that's fantastic.

The developers love this because now they're not being told six weeks later when there's a deployment window and they're trying to get it to work that it doesn't, and they have to go back and figure out what they were thinking and address it there. They're learning immediately. And that feedback cycle, that really quick turnaround on information exchange is the real valuable part of a DevOps process.

And that's what enables the velocity that everybody's looking for. And, and I would feel fast add to that, um, add, add to that observability. Um, we can use observability, um, to, to really enable that feedback process by having observable pipelines.

Um, and so understanding like when your pipeline is failing, now you have information as to why, um, how long certain steps take, et cetera, et cetera. Sorry Anna, I cut you off. Oh, I was just saying fail fast, but it also goes with the observable like hand in hand.

So here's another thing that I don't think gets enough. Play the whole cloud native movement, where would it be without DevOps and where would DevOps be without cloud native to a large degree, right? Right.

They, they're hand in hand and They go together. I think it's, again, part of that same continuum I've been talking about and I see it play out a Q con, right? I've been going to Q con now since there was a Q con just about right.

And I, I saw a, a shift over the last, let's say two years. Um, at CubeCon where we moved from, it was all Kubernetes all the time. And Kubernetes was about deployment for the most part, right?

To observability and, and, and, you know, post-deployment and, and maintaining and operating a cloud native environment, it's not just about getting my code onto the containers and having the containers deployed. It's about absolute platform engineering are all part of that conversation now, right? Absolutely.

And, but, but it's, it's core to cloud native. You can't have cloud native without this stuff. Well, you wouldn't have, you wouldn't have microservices without DevOps and you wouldn't have containerization without microservices.

So, you know, it's not a chicken in the egg question necessarily, but it's this continuum, that's what I call it the continuum, right? Of, and none of it happens without agile, right? Agile is more of a sort of like a precursor, I'd say.

Mm-Hmm. I'd say DevOps and cloud native and, and you know, we're sort of hand in hand and still growing, um, like this. And, and SRE is sort of, there's a traditional flavor of SRE and I think platform engineering is sort of the new flavor that goes better with that later one.

I, I know that's controversial in some circles, But No, you know what, I, I think we're gonna be doing some work with the folks at Platform Comm Mm-Hmm. On platform engineering. And we're gonna have a panel on that, Larry, and, and folks, I'll reach out to you when we do and when I solidify it more.

But it, it's real. It's, it's all part of, and if we wanna call this day two DevOps, I'm, I'm okay with that too. Just don't call me late for dinner.

Speaking of calling me late for dinner, though, we're about outta time here. What a fantastic discussion this was. I think we could have gone all day, but how long will people sit and watch us?

Um, but that being said, Adriana, Anna Margarita, one day, I'm going to say it like you and I'm gonna be so proud of myself. Larry Bryan, thank you for joining us on this episode of DevOps Unbound. Again, many thanks to our friends at Tricentis for co-producing, sponsoring.

Mitchell has always thank you. Take the last word to take us home. It reminds me of, uh, the whole idea behind DevOps days, which is, it's about sharing, it's the experiences that really benefit each other and learning that from each other, not just the best way to construct a pipeline or whatever the, the task at hand might be.

These kind of conversations is where, you know, the IQ levels for all of us raise. And so thanks for doing that panel. Thank you.

Until next time, this is Alan Shimel for Techron Group and Tricentis. We hope you've enjoyed this episode of DevOps Unbound. Bye-Bye everyone.

Have a great day. Hi everyone.