The Rings of Software: DevOps, SRE and Platform Engineering – DevOps Unbound EP 37

Hi. Welcome everybody. Welcome to another DevOps inbound episode.

We have a great topic here. My name is Mitch Ashley, CTO o with Textron Group. Alan Shimmel, c e o is, uh, off on assignment with some other things happening today.

So I'm flying solo with the team here with the, with the panel. Uh, and before we get into the discussion, wanna also say, uh, DevOps inbound has, has, has been since we started it actually over two years ago and continues to be sponsored by tricentis. And, uh, we really appreciate you working with the team there and collaborating ideas and finding great people to be part of these, this discussion really on a thought leader level.

And, you know, thought leadership to me has kind of evolved to people with opinions. I know we want to hear about what they have to say, right? Just take, take a position and let's explore what, how we all look at things from a diverse, diverse perspective.

So, before we get into our topic, which is the rings of software, DevOps, s r e Platform Engineering. Yeah. Taking a little bit of a to approach here, uh, let's, uh, take off with some introductions.

So, um, Adriana, would you start us out, introduce yourself, tell us a little bit about where you, what you do, and where you work? Sure. Um, my name's Adriana Valla.

I am a senior developer advocate at LightStep. Um, I focus mostly on, um, observability. I'm, I work in Open Telemetry, so I'm part of the hotel end user working group.

Um, but, you know, I, I love talking about DevOps, s r e, reliability, pretty much anything in between. Great. Pick.

Who's gonna go next? Oh, um, I'm picked Tim. Thank you, Adriana.

I'm Tim Banks, uh, lead developer advocate at Dell Technologies. Um, kind of operating around obviously the, the, the DevOps, uh, area as well as SRE platform engineering, um, finops, uh, a lot of finops, uh, as well as, uh, general engineering practitioners, uh, both in DevOps and outside of DevOps. Uh, and let's go with Brian today.

Alright, so my name is Brian Cole. I am the director of customer engineering here at tricentis, specializing in Neo load, our performance testing solution. I've been in the performance engineering space for many decades at this point.

Uh, and quality's an interesting place to start having an engaged conversation about DevOps. There's been a lot of, we want to go fast, but that doesn't mean we want it to not work at the end of the process. We want something good coming outta the end of that, and how quality has evolved in the face of these challenges.

That has been something that I've been intimately involved with for many years. Uh, let's go with, uh, Rihanna next. Uh, Taylor, that's where you can jump.

Jump. There you go. No worries.

First Time. First time caller. Longtime listener, right?

Taylor? That's Exactly right. No, I'm very happy to be here.

Hi everyone. My name's Taylor Pache. I'm currently the head of product for Compass within Atlassian.

Atlassian's been around for, uh, over 20 years. Builds a lot of products that you may know, like Jira, confluence, um, uh, and really thinking a lot about how software teams collaborate. And I think as we've seen that kind of evolve over time, DevOps plays a big role in that.

And then now using a lot of my time being spent on the actual developer experience. So how teams build out platform engineering. So excited to speak about that and how we can, uh, contribute to that goal.

Nice. Great. You all, you all bring a great perspective into parts of, or multiple aspects of that kind of, uh, workflow pipeline lifecycle, software delivery.

Well, let's jump into this. I mean, I think we're all pretty comfortable. Dev DevOps has been around.

It's not a new thing. It's certainly evolving and, and, uh, more organizations have started adopting or have, have been using DevOps techniques and technologies and approach. Um, it's interesting, you, you might say that s r e in some ways kinda rose out of DevOps.

You could, you could take another path to that. And certainly platform engineering has evolved more recently, let's say in the last couple of years, is something more visible to folks. I think one of the reasons kinda getting back to I think maybe Tim, you've said, I've heard you talk about is getting back to kind of the developer experience.

We forgot the developer in the DevOps process, so how do we make things easier for them? So I'm really curious, um, how, how each of us sees these three things connected. Are they a Venn diagram or No, I kind of see them as their own thing, and I don't really think that they're that connected.

Are they three separate rings or? We've got three of the five Olympic rings hanging together here. So Tim, I referenced you.

That means you get to defend yourself. Not that I say anything you need to defend, but once you jump in first. Sure.

So I, you know, I'll, I I think it's very interesting we're having this talk because I've been working, you know, uh, doing a lot of interviews with folks out in the, in the community and within the practice. And, you know, we still asked 15 years later, what is DevOps? And so many people will give you different answers.

Uh, especially in light of things like platform engineering and s R E and, and, and I really feel like DevOps isn't a practice, it's an ideology, right? It's, it's, it's a way of thinking. It's a culture.

Um, and from those, you get the practice of s R E and the practice of, of platform engineering. I mean, these are, these are an application of engineering principles to deliver some sort of experience, right? For a platform you're developing, develop your delivering a developer experience.

SRE are usually delivering a customer experience, right? Um, but these are still all within the DevOps ideology. They're, they're not, um, they can't operate by themselves, right?

Without a DevOps practice. Uh, they're, they're, they're siloed from each other and siloed from other concerns, but certainly, like I said, within the ideology of how, within the ideology of what DevOps is, right? Uh, they're a way that DevOps gets done.

Interesting. Somebody jump in. Yes.

I think, um, oh, go ahead. Oh, Yeah. So the, I view them as they are separate roles.

The DevOps tool chain engineers, the site reliability engineers and the platform engineering teams, but they are tightly interrelated. I often think of the s r E teams as an evolution out of a performance engineering effort where we task the performance teams to know and understand their performance tool and how to create scripts and drive load against the systems under test and monitor them, and then create recommendations on how to improve those systems. And that's a lot, that's a lot of skills to put onto one team.

And the SREs evolved out of that as specialists in how do applications actually use and leverage those systems and the resources being provided by them. How do they optimize the use of the hardware assets, software libraries, all of that kind of thing. Platform engineering is trying to address this other related problem to a DevOps tool chain where the developers love building things and they will grab the newer technologies and they will begin running through with all of this, create a application build and get ready to deploy it into production.

But they did all of their development on the latest version of the database, which is not what the ops team's running in production. So how do you deploy this now? Are you forcing upgrades to your production sense?

And the platform engineering team is evolving out of this need to help provide the systems in time with planned production upgrades to ensure that what's being built to be deployed in the production environment is actually going to work. That there's an alignment between this is the current version and the policies in place, and how these things should be managed here. Is that system develop on top of this so that when you deploy, you didn't write your software to only work if you have super user admin credentials, uh, to the database, that you actually can have security policies in place, that it's gonna be a version matchup all of these underlying problems that are still bumpy parts of the DevOps journey that we're experiencing today.

Yeah. And just to, um, to add to that, like I think what we've seen a lot in kind of Jira software with over a hundred thousand customers now, and just so many different ways that people go about developing these things. We kind of saw the beginnings of DevOps with you build it, you run it, right?

And it kind of kicked off this, we kind of saw agile there, and you're trying to empower all of these teams. And what we see now happen is that we, we kind of did it, we gave them C I C D, we gave them GI ops, we gave them a lot of control at the development level, right? And so now you're kind of wondering, okay, how do I deal with these large complex systems, both technology and teams and people?

And I think SRE takes a very observability role, like reliability perspective on that, which you very much need. And I think I, I've always found it really interesting in the book there that 50% of their time in the Google s r e book was trying to build tooling to reduce toil and to do other things, right? And I think what's platform engineering is coming out is saying, yep, DevOps is this methodology, it's part philosophy, part strategy.

SRE had an opinion on that for observability. And now platform engineering is coming in and saying, cool, my customers are my developers. How do I look across that and the entire life cycle and make them more productive?

Whether it's self-serve infrastructure, whether it's development pipeline and unit tests and like build times, right? Cuz that's, those are small dev loops happening everywhere. Uh, and then you kind of get to the observability side.

So I think platform engineering could be starting to collapse some of those efforts and building the right abstractions for it. And I'd be curious how that that merges with kinda the SRE world. Um, Seems like with fitting, we, we add you in at this point, Adriana, because you, you are in some sense the glue of some of those things in terms of your work and observability and SRE and platforms.

Yeah. Um, I think like, I, I liked Tim's definition, um, where like DevOps is, um, the, the kind of the mindset and then where S R E and platform are the implementations of it. I think I, I have to call it the fact that like, one of my pet peeves is like DevOps, a DevOps is like a thing, a a job because I've always been of the, the, the train of thought that like, that it is not a job.

Um, that's a whole other conversation. But, um, I think like in terms of like s r e platform, I think we're generally in agreement that the SRE is concerned mostly with, um, the external customer, the reliability of, of the systems that the external customers are, are dealing with. And then platform is more concerned with the internal customer, the, the developer.

And I think this idea that like, yes, we have to standardize on, on the tooling that we use. And so the PR platform engineer and, and the versions of the tooling, the platform engineers, like creating those guardrails for, for the development teams so that they don't stray off and start doing that thing, doing things that are not compliant. Um, and I think, um, and which is great, uh, but also the platform engineer I think has an important job of ensuring that, um, you know, they're not drowning in like request to service requests, like trying to implement the things, like deliver the things for developers that they need in order to do their jobs, nor do developers wanna be waiting around for those things to happen.

So now we're seeing the rise of these self-service platform engineering tools, which I think are making everybody's lives easier. Um, because, you know, as a developer, I wanna do things myself, but I can probably get carried away with the shiny new thing, latest and greatest and, and kind of, you know, not, not care about security as much as I should. And the platform engineer is saying, whoa, I'm gonna give you the thing that you want, but you're working within these parameters.

Yeah, it's interesting. I I, I, whenever people ask me what is DevOps? I say, DevOps is not a, what, it's a how this is about how we create software and applying some of the philosophies that that helped define what it is.

So I'm in agreement with you about that. It, it's interesting, one of the themes that, that I'm picking up a little bit is, um, well, certainly one is, is platform engineering focusing on helping dev serving developers, helping them be more productive, right? Some people have said it as we kind of forgot about the developer and all the DevOps and all the other stuff.

Maybe, maybe, maybe not. Um, but focusing on making, helping make their job easier. I think there's also a deployment side of this, and you kind of, uh, touched on this, Brian, of I wanna make sure when my stuff gets deployed, right?

It isn't just that I have a platform to, you know, hand it over to, and it's in a certain structure and a certain way. But I wanna know that as we flow software across the, the workflow pipelines, right? Whatever environment is getting deployed in, I don't wanna find out after I'm done testing what I thought I was gonna deploy isn't gonna work in the environment environment I'm going into.

So it seems like platform engineering is also a connection between production and test and dev. Exactly. Agree with that.

The, the effort to control the alignment of the two. So the two teams are fundamentally at odds with one another. If you talk to an IT operations team, their applications are currently functional, which means don't touch it, change nothing, and it will continue to work.

Whereas the entire developer mindset is, I'm constantly changing everything. So bridging the gap between these two needs, you always need this new functionality, yet you always want your operation space to remain 100% available and performant and of high quality. There's a gap between those.

Uh, DevOps is designed to help address a lot of those barriers, and this is through things like visibility and sharing of information between the teams, but the platform engineering, the rise of this as a separate discipline is really focused on how do we help provide to those development organizations the platforms that we want them to use, the end result platform. They're gonna deploy all this new feature that they're building so that it slots seamlessly into that production environment. And we don't have deployment errors, we don't have deployment defects, we don't have a new challenge where the IT operations seems like, well, this is great, we've been told to run this new version of the software, all we have to do is upgrade our entire Oracle instance.

Great. Uh, now we've got a, a major upgrade that we didn't know we had to plan for. And this is all part of the collaboration aspects of DevOps.

Trying to make sure that they are in the loop, that they know what software builds are being worked on and how they're rolling down. More than that, when they plan those upgrades and they wanna upgrade their production environment and the systems they're using, there should be a lead time known to the developers so that at some point, say six weeks earlier, if they have a six weeks release cycle, they start developing for that new system so that as the upgrade happens, the new software that's being delivered to them suddenly shifts to be on those new platforms. And this is where the platform engineering teams can really provide a lot of guidance and support to those teams that are building the DevOps tool chains that automate the process.

And to the SRE teams that are doing the analysis of the systems, helping to understand how they're using those resources and tuning them to use them more effectively. I wanna, I wanna complicate the, the notion that the platform engineering team is, is serving the internal customer of the developer, okay? Because in the end, the platform that the platform engineering team is providing is going to be used to provide production products to customers, right?

Mm-hmm. So really in the end, their requirements should be more informed by s r E and the end goal, right? As for the, and, and, and then at kind of as a, as a, you know, afterthought almost then providing a way for the developer to interact with that platform, right?

The platform itself is to be used to build something that's part of the customer experience first and foremost, right? And then we're going to provide an easy and repeatable way for, uh, developers to, to interact with that platform. It's, it's, it's essentially they're, it, the notion is you're building a cloud, you're building what w s did, you know, how many of our years ago, right?

They didn't, it's not that AWS built hardware, not that they were an infrastructure provider. I mean, they are, but that's the least impor, that's the least interesting aspect of what they did. What they did was they provided an experience to developers and operations teams on how to interact with that infrastructure, right?

And so when they developed, you know, there are 17,000 different ways to launch a container, in essence, they were just doing the same thing as they're saying, okay, we're going to provide a way for developers to interact with the platform, but the platform in, in the end, right, has to be something that their, uh, end consumers or the end, the end customers for these development teams need to be able to consume reliably and re and regularly, right? So I, I do feel like the, uh, that platform engineering has to get a lot of cues from s r a has to be informed and, and the, and have their end customer as context, right? So that they can give, uh, the developing development teams the tools that they need to succeed.

Yeah, that's, uh, I wanna add that kind of getting a little bit into dev productivity, uh, which is a kind of an interesting topic, right? Developer productivity versus developer joy or satisfaction or experience. Like we all use these different terms, but I think, um, like if, if you're ultimately empowering these software teams, you have the business goal out there, but it is an underlying platform, so you kind of want your engine running really well.

And I, if you take a really holistic view that I think platform engineering's starting to take, it's not even compute or, uh, operational side, but it's how do you attract and retain top talent, uh, as things get pushed down to the API layer and you're assembling software. How do developers kind of work across where is that API and which team owns that, and how do I contact that team? And like, you know, there's all these like loops that are happening across and, and as we go remote and it's more distributed, we're seeing that become really painful.

And so it's almost having the right abstractions, the right information, um, you can have different tools, but being able to connect that across the tool chain, so to speak, you're getting the right, the right context at the right time for the right person. And that's gonna speed up so much. I mean, there's just so much toil there and I'm, I'm curious how, how you all think about maybe developer productivity in that sense, or, you know, what is success of a platform, you know, developer platform look like.

If I can, if I can go out of turn, just, just to add this to that, it's interesting you mentioned about, you know, retaining or bringing in top talent because the easier you make it for developers to be productive, the less important it is for you to attract top talent, right? We're seeing this now with, with chat G B T and other generative ai, right? You don't have to be top super productive as long as you know how to construct queries or whatever, right?

And if you make a platform that can easily take these things in there, I don't have to have, you know, the, the, the mythical toxic tenants ENG 10 X engineer, whatever, right? I don't have to have the top talent because they don't have to solve these problems as part of their job, right? So I can have a more of a one-to-many relationship as to the top talent, and then many people who are lower on the skillset chain because it's easier for the people lower on the skillset chain to be, to be productive.

Yeah, I think that's a good call out. It's, you know, we always talked about 10 x engineers, right? But if you have things like chatt, PT and co-pilot, uh, and other things, you are also increasing the productivity of, um, everyone.

And so, and maybe everybody's becoming a 10 x engineer. I think our, my stance at the moment is kind of, if you have an, an engineering team over 50, let's say, or a hundred, I just don't see how, how you're not gonna have some type of like developer experience or developer platform that sits across development, you know, build time, uh, environments, putting code onto environments and the operational aspects as you kind of share the operational responsibilities. I just don't know how they're gonna be able to compete effectively because, um, the information will, will be too distributed.

They won't be as productive, they'll start to slow down. And I just don't know how that's, how that's gonna work. So, um, yeah, The part that I found, um, really interesting that you brought Taylor, was about context as well.

One of the issues with all of the vast quantities of data that we see across all the different systems that we're using is that the information can be very tailored to one particular audience. So if I take developer logs out of a CI system and try and present that to an IT operations team, they may not understand the, what they're looking at or how to interpret it, and vice versa. If I take, uh, logs out of a system designed to monitor IT production and give those logs to the developers, the IT operations teams may be saying, look here, right here, here is the error and where it's slowing down.

But the developers don't have the right context to understand that information. The transformation of that detail so that it's consumable by the different audiences is a key part of how these systems need to evolve and the types of, uh, solutions that could be brought to the table. Adrian, And I think platform engineering plays a role there.

Sorry, They're Brian, uh, Adriana, you know, it, it, it seems to me we, we've done some other shows together of the other panels and we're, the word toil comes up particularly in an operational context. Um, but I think what, what Brian was talking about is some of that continuity of what's happening in the system and helping, you know, connect the dots, whether it's through the tools or knowledge of what's happening, also falls really well into the s r e role, right? Because they're trying to develop a more systemic understanding of what's happening and what it can do either to improve reliability or resilience or performance.

Um, so, so I think there's a wealth of information and some of it, you know, head knowledge if you will. What are your thoughts on that? Yeah, I mean, I, it, it is funny cause I was, I was thinking also from like a, an observability standpoint.

And I think it's one of those things that, um, it's not just the SREs concern, it's an everybody concern. Um, whether it's like your s e or platform engineer, it's your QA concern, it's your developer's concern, right? Um, because, um, so your, your developer has to instrument your code so that your emitting that information so that your system is observable, right?

So your s e or your platform engineer can like go and troubleshoot, hey, what, what's going on? Depending on, you know, what, what it is you're building, your QA can take advantage of that instrumentation cuz it'll empower them to troubleshoot, um, whatever's coming out of, of the development team. But also they can take like those traces and create trace based tests, um, so that they can create automated, automated integration tests that are, you know, standardized like no matter what language, um, you're using.

Um, and, and then another aspect, uh, that, uh, I, I've, I've seen some rumblings on, but it's not talked about too much is like observability of CI I C D pipelines where like, you know, CI I C D pipelines often, often are expressed as code, um, and CI I C D pipelines, when they work, they work, but things happen, things fail for whatever reason. So having the observability into C I C D pipelines is super important because you're like, Hey, why, why is this thing failing, right? Um, so bringing that, bringing that power across the board, but making it a concern to, to everybody, not just like one isolated team, I think is extremely valuable.

Um, and it's the type of, the type of like thought process that we have to start having and not treating observability is this like little adjacent thing that's like either, either a separate practice or like just the concern of the s r E Is the whole observability driven design, right? Yeah, exactly. You're designing software so you're, so it is emitting, it's designed so you can enhance it and build it to increase its exactly the value of what it's emitting or, And everybody leverages in a different, in a different way.

Um, I, I think that's an excellent point that you brought up. Like the main branch being healthy and applying observability tactics, tooling, everything to that. I mean, I, I, yeah, observability is kind of how you sense things and one of the, one of the key things I see happening within platform engineering is this idea of scorecards or reliability is code or open policy agent and other things where you're kind of taking, you know, you codifying these practices or, or, or configuration other things, but it's really kind of defining what healthy looks like.

And I find that really fascinating cuz every company's kind of building these out. They may start with high level stuff like DORA metrics, uh, but really quickly they get into their system of saying, okay, I wanna make sure that my main branch is not down for more than an hour every month, right? And people who get to that state, you're, it's like this nice balance between the experts who may codify that and build tooling to enable it, and then giving that somehow to the hundreds of software teams that need to keep that in a healthy state.

And I, I find that collaboration being relatively new, uh, and a lot of value there, a lot of opportunity. Yeah, I would agree with that entirely. The one of the endemic problems that I see is everybody cares about quality.

Quality assurance is not the job of the QA teams. They do quality control. Everybody does qa.

It's at, at every level throughout the entire organization. But I look at a lot of agile backlogs and I don't see performance, uh, specifications. I don't see quality, uh, time allotted for it.

And we all expect it to happen, but then we don't put it in the backlog. And this is probably one of the easiest things I can recommend to any potential viewers of this webinar. Go and take a look and give your developers time.

They'll do what's in the backlog. If you want higher quality apps budget in a little time for them to build unit test, build performance test, build functional tests, build time into, automate that into the tool chain so that your CI system is executing them in an automated and consistent way. And to Adriana's point, if you miss something and you find an incident later, go back and review and figure out what tests you missed and build tests to begin covering that in a consistent, repeatable way continuously throughout.

And that's what continuous quality leads to. It's not a burden. Once you invested the time in building these assets, your applications start coming out fully functional every time.

That's the goal. That's what we want. I think it's, go ahead, I'm sorry.

And then to the, to the notion talking about observability and talking about quality, but I think I wanna bring it back real quick to relate it to something that Taylor mentioned almost in passing earlier, was this notion of being competitive, right? We will game whatever metrics we're measured on, right? So you talk about door metrics, talking about these other metrics, the nine times out of 10, the easiest metric that they're gonna contain people, it's like, how many features did you push out?

How many code measures like that, right? And you're going to be to, to behave in a way that's going to meet those metrics, right? But like Brian said, right, you have to the time to time to build testing in to do quality first to do observe, incorporate input from s r e and your observability stack, right?

Those are investments. Uh, and those aren't gonna come out, uh, in, you know, this sprint as as likely we accomplished all this, then they're gonna come out next sprint. That's a longer term investment.

But the notion of being competitive, right, is what draws us back into very shortsighted thinking. It draws us, draws us into checkers and not chess, right? So we are going to, we're we're telling developers, I need you to work on these features, right?

I need you to have these features rolled out. Why? Because we're trying to compete with, of the boogieman essentially, uh, to, we have to get this thing out, right?

We have to get this thing out. Why? Because sales said we have to do too.

Well, why did sales say we have to do, because business said, why do we have to do? And in the end it's arbitrary, right? So we as thought leaders in the industry, and especially those who have engineering leadership roles, we really need to play chess with what we're doing and understanding that, creating technical debt by ignoring testing and ignoring quality assurance and ignoring security and ignoring, uh, uh, cost optimization for the, for the benefit of rolling out features to compete with nothing essentially, right?

Is cutting off your nose to spite your face. Maybe not this quarter, maybe not next quarter, but it's going to happen, right? And so you have to be strategic about these things, not tactical.

You have to go, you, when you're writing these tests, when you're building your sprint plans, when you're building your epics and stuff like that, you say like, we have to budget in the time to do it correctly. Right? And that will pay us dividends down the road.

It's an invisible cost too, which is the problem when you talk to a lot of business executives, how do you understand the pain? Well, you set up two identical teams and you have one, do it properly and one do it the fast way and then compare costs two years later. Nobody does that, right?

The, the properly structuring out your backlog to include all of this stuff is invisible. You see, all the time you spent in the cost you incurred, what you don't see are the production incidents and failures that you avoided as a result of this. And quantifying that is something that can be very tricky to do, right?

It's a very nebulous sort of thought experiment for a lot of people. And yet there are a lot of news stories of companies in, uh, the news who have had performance failures or security breaches or some other catastrophe that has befallen them. And you definitely don't want that.

It's interesting. I had a conversation, this is earlier in my career with a developer and I, I said, speed performance is quality. And I kind of got the, I have four, you have four eyes, Mitch.

Well, I had glasses on, but actually, you know, I was like, no, from a user perception, that's an aspect of quality is if this thing like kicks back right away and I'm not sitting here, you know, waiting five seconds or 10 seconds, you know, th they judge the quality of the system, whether it's accurate or not. That's also part of it. But, you know, if it's highly responsive, you're like, wow, this thing kills, this is awesome.

I love this product. That that's it. Exactly, exactly.

The change in perception over the years in the year 2000, if that webpage didn't load within 15 seconds, I was out. That's down to two seconds, maybe three if we're being really charitable, maybe, um, one of my favorite sayings is, your software can be ugly and difficult to use and your users are gonna use it and hate you every single day. If it's slow, they're not gonna use it.

It's, I'm gonna push back on this one too, because I can write Good. I can write any software that will return a 200 Okay. To anything you put into it, right?

And, uh, that may make your user happy today, right? When, when they go to go pull the data from that transaction that they sent, and it's not there now, they're upset right? Fast will get you sales reliable, will get you renewals.

And, and I would say on, on that same thread, like, you know, it's easy to, you know, install an app, but it's just as easy to uninstall it. And if that app does not working the way that you expect it, yeah, it's gone. Right?

And, and that's, I think, harder to recover from, right? You, you have that bad application experience, you're like, hell no, I don't want, I don't wanna deal with this again, this is a piece of crap. Yeah.

I don't wanna order something and get the wrong thing. That would be a functional failure of epic proportions. Um, I don't also want to deal with a website where I want to order the thing and it's a 30 minute process To do so.

Yep. It has to be correct first and then you make it fast. Let me ask this just to kind of guide the conversation to another topic.

Um, if there are, what are the friction points with, I'm gonna say DevOps, thinking about, you know, the, the flow of, of how we create software, s r e and platform engineering, what of the things we need to work on to increase flow across all of all of the disciplines? Whether you're creating software, you're creating the pipelines and tools to build software, your s r e and working on, you know, reliability and performance, you're working on platforms, et cetera. What do we need to make this better?

Um, any thoughts on that? First, lemme show, Taylor, why don't you start out here? Yeah, I I, I'd like to take that one if you don't mind.

So I think it goes back to something, um, maybe Brian you said, which is the translation of information from different roles and personas and context, right? I think if you look at, uh, you know, I worked at Atlassian for a little bit, but if you think about abstractions, we always build abstractions in software. And I think what happened with Jira was that you had the right level of abstraction to tie work against a bunch of different roles.

Design could get involved, development could get involved, feature flags and rollouts could get involved, business teams could get involved, and you can talk about this kind of common thing and apply different contexts throughout it. It was, it was a little bit flexible, but it had some structure. It was a really great book on this called, uh, the Box.

I think it talks about like, uh, global trade and how the containers just was like a huge boon to global trade. I, I think about that, that same thing of like, well, what's the right abstraction for what application teams are building against and operating against? And, you know, is it the underlying e c two containers or coup clusters or, you know, there's something that's grouping that there's something that the APIs being applied to.

There's something that support teams are getting requests from and saying, Hey, you know, the boards are down. And then that translates into technology that's becoming more and more distributed. So I, I find like the language and the terminology and the abstractions we use needs to be really thought through for teams.

And I, I find platform engineering is really thinking about that right now. I think for me, like one of the friction points, um, that I see is teams always being in firefighting mode and not focusing on reliability. Like we talk a lot about reliability, but if there is not time made for reliability, whether you're a platform team, whether you're an SRE team, things are just not gonna happen.

And making time for reliability also doesn't mean pulling in another team that has nothing to do with that. To do the things that make your systems reliable. And, and like one of my pet peeves that I talk about a lot is, um, uh, relating it back to observability where like, you know, dev teams will instrument their code to make it observable, but then pulling on, say an s r E team, Hey, you know, you guys make sure, you know, you guys do the troubleshooting or whatever in, in prod, why don't you instrument our code for us?

Why? Like, that's not your code. Like, it's not your business.

Why are you doing that? So making time for reliability, like, you know, um, like Brian said, put that in your, put that in your plan. Um, make it a core part of, of what you're doing, um, and making sure that the right people are are, are responsible for the reliability of your system.

Don't just, you know, shove it off to another team because, oh, this team's too busy. Well, if they're too busy, there's probably a reason. I think you need to take a step back, reevaluate the situation.

It's, uh, it's funny, I come from the performance space and I was joking on another webinar. All of our analogies are extremely dark, so I want to hit on the, everybody's in a firefighting mode. It's like you work at a hospital and every day at 11:00 PM a patient arrives suffering from multiple lacerations and they're bleeding out and you're focused on trying to save that patient.

And never once do you ask the question, what do you do all day? How are you getting to this point every single day? Because there's a lot of value in stopping that be.

Why are you constantly in this state of trying to save the patient? And that is fundamentally one of the big problems that I see and a source of major friction between all these teams. There's, there's no, if there's time to get it wrong, there should also be time to get it right.

Why weren't we just going to allocate some time into the process flow to say, yes, please build some tests. Yes, please build in a reliability strategy. Yes, please build in a proper platforming strategy.

Uh, and we won't see a direct result of that because we don't experience the production outages and understand how much that would've cost us now that we're avoiding them. But boy, is it, does it pay off? Um, and that pays off in a lot of different ways in terms of competitive advantage, brand perception, uh, quality can be a very subjective assessment by a lot of end users.

So there's, there's definitely problems quantifying that. What is a fast application? What is a high quality application?

You're gonna get a lot of different answers if you ask a lot of different people. So there's, there's definitely an emphasis on trying to get it right that I would, uh, advocate for. That could be as simple as just adding a backlog entry for doing some testing.

I think to tie it back to what Taylor said originally, I think the biggest source of conflict and friction we have there is that folks are operating different contexts. Uh, I don't want to give it a, a morbid, uh, analogy, so I'll give it a better analogy. It's like working in a restaurant, right?

Your waiter is incentivized to do, do something differently than the kitchen is incentivized to do something, which is different than maybe the bartenders incentivized to do something right? Now, obviously, all of them act together to deliver a customer experience, right? But they're gonna have different mindsets and different motivations because they're incentivized differently, right?

The waiters gonna be very, very sales focused, right? That's gonna be more like your developer developers, roadmaps, something like that. Almost always tied to sales, right?

Uh, you know, you've got the kitchen who's gonna be, we'll say, we'll say that the s r e, right? Cuz they're kind of delivering on like, Hey, we made this thing, we need to get it out, whatever, whatever they're focused on like operational goals and things like that. Whereas your platform team is kind of tied, their motivations are tied to keeping the developers happy more so, right?

To the extent that they have different motivations, they're always gonna pull in different directions, right? Sometimes that tension's good, sometimes that tension's not so good, right? So you do have to balance that out.

But in the end, I think to get people all moving in the same direction, you have to have one overlying context that drives everybody what that is gonna vary from organization. Organization. But that's why leadership is an art and a skill, not just management, right?

Um, but that's the thing. How you figure out, uh, to have more cohesion in the team is to incentivize everyone so that they also always have the same context. Well, I think with that, we're just about at the end of our time, I want to thank each of you for contributing not not just one perspective, but I think each of you kind of looked at all dimensions of it and try to apply your perspective to that.

And I think it's a really healthy conversation. You know, just to leave a parting thought, what, for all of us people come back and talk about this another time, is one way to help things flow or help people work together is ask each area of what could you do to help the other parts of the organization improve their work or their workflow, make their job better. Whether I'm in development and I can help s r e by instrumenting code or I I'm in, uh, platform, here's what I can do to, uh, you know, make the whoever's life better.

And that's, that's also a way of you start putting your, that context, your context into other people's shoes and other parts. I'm, I may not be the expert in those other things, but I certainly can help do what I can to make that better. So, parting thought for everybody, um, Brian, thank you so much.

Appreciate, uh, you and Tricentis team and Lenore and also Jody from our team for producing the show. Uh, Adriana, welcome again. Great, great to have you on and, uh, uh, doing, doing a fantastic job of bringing the s r e perspective, uh, to the table.

And Tim, it's, it's great. You know, we don't think of Dell as a software company, but it is a software company too. And getting that, and Taylor having you on as well too, I'm like a longtime j Atlassian user, so I kinda get where you're coming from as well.

So thank you everybody for joining us on this episode. Uh, the, the, uh, the rings of software, DevOps, SRE and engineering, we hope you'll tune in. Be sure and check out other episodes of DevOps Unbound on Techstrong tv.

You'll find it under the series tab. There are all kinds of great stuff. com and those are also engaging cuz the audience also gets to participate.

So thank you everyone, appreciate you listening in and being part of our conversation, and thanks to all of our panelists and their respective companies for being here today.