SREing Toward Platform Engineering: What Happens When SREs Succeed? | SKILup Days 2024

Hello, welcome to SRE towards Platform Engineering. Uh, I'm Mark Blasco. I'm a senior technical staff member with IBM.

Um, I do SRE from Multicloud SaaS platform and a part of the S3 CTO office. So today we're talking about S3 towards platform engineering, but the subtitle is what happens when S3 Succeed, and we'll go into more detail about what that is and, and then why we frame it that way. But first, who am I?

Again? I mark Wasco. Uh, I'm responsible for the execution and adoption and best practice of S3 across IBM software.

Uh, I also teach software engineering and software design, um, in local universities here in Southern California. I reside in Southern California. Um, again, I work for IBM, uh, and I have a nice picture of a Lego, uh, at Walker that is waiting for me to put together, finish putting together in, uh, my garage.

So hopefully I get to that. But just an example of who I am, my interests, um, and, uh, you know, where I'm coming from, from the SRE side of things. Now, when we get into this discussion, uh, we're talking about what are SRE and what is platform engineering and how do we get from one to the other, or where are we on the path to that and things like that.

So it's important to kind of step back and do a terminology reset of what is SRE, right? So SE day in life of sre, what are they doing? What are they dealing with?

What are their responsibilities? For most of us who are doing SRE realize that the primary responsibility, one of the most primary responsibilities is the being on call and dealing with toil. So the whole point of having on-call SREs is they, they are there to be on call to respond to outages, uh, to resolve alerts, uh, while the rest of the SRE team is dealing with engineering, uh, you know, remediations and reducing toil doing, uh, everything they can to make that on-call role as boring as possible is my phrase for it.

So, you know, I I kind of view it as like the on-call. SRE is like a shield for any type of outage, customer events or alerts that come in that would impact the team, but that on-call person is handling it. So the rest of the team can try to prevent those issues from happening in the future.

Um, and it, it, it rotates, right? So the on-call s threes, they go from one person to another, uh, in different rotations. Sometimes there's people on call for four hours.

Sometimes people have a 24 hour or multi-day, uh, uh, holding of the pager as it were. Uh, and sometimes we split between shifts like, uh, different squads. So like, for example, in my area specifically, we have a US squad.

We have an APAC squad, and we have the EU squad. And so they kind of do a follow the sun handoff, uh, through their working hours, handing off from one region to another. Um, and that allows us to be able to, uh, to keep different rotations onto the schedule and be able to on call and have fresh people on call for various alerts.

Now, how you structure that varies depending on the number of alerts you have coming in and number of incidents you have coming in, the amount of automatic remediation you have coming in, if you can get by with having one person on call for 24 hours, you know, the idea is that they don't have as many alerts coming in. There's not as many incidents coming in and, and things like that, right? Um, but you know, that's the whole point of, of being able to have the rest of that team doing the engineering work to enable that to be, uh, to that to be the case.

They're working on automation, reliability, doing postmortems, RCAs and things like that. And just making the, the engineering, the reliability and the product, uh, all the all to make it all the more better. Now, what are the challenges that these ses are dealing with day to day?

So obviously the oncall, that's for sure, but what are we really looking at as SRE as part of this process? Well, the, the primary thing we're looking at is we're looking at better observability. And when I say better, it really means we're trying to make things meaningful, tenable and actionable, right?

Actionable. Because what we want to happen is we want for these alerts and outages that should get triggered, they're gonna trigger like some type of incident that goes to the on-call S3 and alerts them. If an on-call SRE is alerted, we want the on-call S3 to do something, right?

I don't want to alert somebody and just have 'em kind of flail around, not sure what to do. They need to go and take a look at some service and remediate it, whereas reboot it, restart it, redeploy it, whatever it is. But they should be able to tell from that alert what the next step is, right?

So the, the, I won't say the worst case, but like you can tell where there's room for improvement when an SRE gets an alert and doesn't know what to do with it, right? That's always that we never want that to happen. So making sure that we refine our observability, and again, that's what these SREs are doing here as part of the teamwork is they're looking at incidents that have happened, they're looking at better ways to remap that observability so that it's intention and that we can take actions on it, right?

Um, and then looking at efficiency. So we wanna be able to look at ways that we can automate everything that we're doing, uh, you know, make sure we're making cost eff efficient use of all the resources that we have there. Are we running things optimally?

Are there ways that we can save, uh, uh, you know, engineering hours and save compute hours and things like that? Uh, we really need to look at that from the lens of being able to say that that deployment and runtime costs as much as possible. Um, and then, and, and this also gets into things like finops and things like that, where we're really trying to use all the tooling as much as possible to say, Hey, where can we look at utilization?

Where can we look at like periods of utilization? Where can we look at automation to automatically spin down dev and test environments and then spin them up when work hours start again and things like that, right? Um, so that's where that efficiency really comes into play.

And then reliability, obviously reliability, because we're looking to, and reliability in the sense of, we, we really care about reliability for everything, right? I mean, obviously we have to say that, but what we're really interested in is the reliability that our customers observe, right? And so this is the opinion where if a backend service goes down, it's like some kind of batch service, right?

And it's periodically processing, uh, uh, workload, but a customer's unaware of it. It's kinda the tree falls in the forest thing. Does the customer really care that that thing went down, right?

So yes, it's probably important and we need to address it, but in terms of like the, the immediate need and alerting like a sev one outage to an on-call sre, it's probably not something that we need to pay attention to, but the things we need to pay attention to right away for that on-call SRE, meaning that we need to alert them is things that impact a customer experience. And that's things like latency errors that they receive and things like that. And, and better yet precursors to that, right?

So I don't wanna necessarily know that the error that the user is encountering error. I want to be able to observe proactively that we're leading up to that point. Latency is spiking.

This is, uh, a precursor to, to errors arriving and things like that. Um, there's stress on the database, and after we've noticed someone, there's periods of that type of stress that users will get errors, uh, back from their calls and, and things like that if it per, uh, persists for a certain period of time. So being able to look and identify those scenarios where those scenarios are precursors to errors and to problematic, uh, issues in the environment, that's what we really need to alert on and pay attention to.

And so proactively alerting our SRE that, hey, this is gonna happen within an hour, that would be kinda like the, the end goal, right? And then, uh, separating the customer experience from the noise and lower priority events. So, you know, one of the things that we often see that we are often discussing is how do we separate the events that we really need to take action on, right?

Again, actionable events from the events that are, it's nice to know that, but like we can put that into the engineering backlog, right? And so that's where we're really trying to separate the noise from the signal, um, trying to identify what's gonna impact the customers and what's gonna make the environment reliable. It's not to say that like all the other stuff that's going on in the environment, like memory leaks and performance issues and, and errors for backend components are not important.

It's just that what we're trying to say is that with the number of people who are on call, we're really trying to limit it so that it impacts the, the on-call person for the really critical elements. And then the other elements and the other things we have to worry about, we have backlog engineering to go be worked on by all these people who are not on call. You know, there's an engineering team to go and tackle those.

So it, it allows us to more efficiently spread our use resources, um, to where it's needed the most, right? So we're kind of marshaling the resources to onca for critical things, and then all the, the backend engineering work is gonna handle all the other stuff that's not a priority, right? And that's not impacting customer impact and customer experience.

So that's the intent of that. Um, and then how does that differ, for example, from like platform engineering? So in platform engineering, it's, it's, and it's hard, a little bit hard to kind of look at the leap from SE to platform engineering because PLA SRE is really dealing a lot more with, you can see how there's alerts and things like that with SRE, but when it comes to platform engineering there, there's a lot less of that scope of on-call and, and alerts and things like that.

And that's kind of intentional because remember what I said back at the beginning, our journey towards platform engineering is what happens when SRE get it, right? So in our previous, uh, day-to-day SRE experience, what we saw was SRE are there because we, we think things are gonna go down. We think alert's gonna get generated.

Um, we need better engineering for all the stuff that's happening in the background and and related to deploying, uh, uh, changes and things like that in production. And what we're saying is that, well, we've been doing this for so long that, you know, the best case scenarios really happen that that on-call SRE really is bored, right? And that was kind of like, that was Mark KO's like goals.

I want to make that on-call SE as board as possible because it means that we built in remediation, we built in reliable services, we built in enough practice processes and tooling to make it so that that on-call experience is really, you know, kind of a, a, a very boring experience. And that on-call, SRE could actually be doing engineering work. And very rarely do they get called out.

At least that's the intent, right? Because that gets us to this platform engineering type of scenario, right? It gets us to the ability to engineer reliability to the existing systems.

Everything we were using as ses, like the automated processes to push things to production pipelines, infrastructure provisioning and optimization, uh, using our finops tooling, um, and things like that. But it implies that we have all this stuff that's already there and exists. So there is a way to actually have somebody go and schedule this service to go be, run this service to go be deployed somewhere intelligently, right?

And so I don't need S3 to go and figure that out and have a manual process to do that, or even a document process to do that. There's just automated scheduling to go and do that. So the, the, the difference between SRE and platform engineering is that all the things that we would've, uh, done as manual processes or even semi-automated processes, they're all scheduled and automated and able to, to go and be triggered by anyone, whether it's a developer, an SRE or anyone, right?

And that's really important and key because that really kind of shift left the, the scope of responsibility, because it's not just an SRE that has to be there to monitor these things or see whether or not these things get pushed to production. These SRE are now, you know, they're kind of bored, right? They don't need to do that because the developers can use the automated process to go and push services to production, right?

And that's what we're seeing. But then the key thing is that those developers will get alerts, right? And they would get alerts from the testing that we're doing from the, the observability and telemetry we have built in this entire ecosystem to monitor all those published services.

Now, the key part that does this is all these, uh, reliability systems that we have here, I I call these the guardrails, right? And that's just kind of a, a, a short, quick term to, to denote everything that exists in this box. Automated processes, infrastructure provisioning, workload optimization, prioritization, and automated remediation and failures with all of those pieces in there.

Uh, it's just a platform that exists that developers take advantage of and use to publish services. You know, that's kind of like the golden ticket, right? Because that allows us to be able to publish services based on this platform that are automatically, uh, does the workforce to make them ready for production, right?

So all those tasks that Esri would've had to do to get things ready for production, production and our, our previous scenario, um, you know, we don't necessarily need to do that anymore because it's handled by an automated platform. So, and I really can't stress enough how much work would have to go into this platform engineering, uh, box of work on the top left, because that's a lot of stuff. And I, I can tell you how long I've been doing this, and I know other people are in, uh, uh, you know, different journeys and different paths along the way.

Um, we're all trying to get to that because, you know, that's, that's, that's kind of like the, the end goal for a lot of us is that we can automate all these processes that we can use infrastructure provisioning and optimization and better intelligent automated ways to schedule all this stuff. Um, but you know, the key to this is that the, with this platform in place, with these tooling in place, what becomes of the SE team, right? So I said that it, when you get the platform, engineering, SRE really has all this stuff in place, is kind of like a precondition, right?

So the preconditions, all this automation, this platform exists and it's robust and resilient, and we can rely on it, and our developers rely on it to public services rapidly with a lot of velocity for our users. And when issues come in, uh, the developers can go look at the platform and easily fix those, uh, those issues, right? That's where we wanna get to.

So then the question becomes, well, what happens to SRE, right? So if SE isn't doing that because there's a platform there, uh, what is SRE actually doing? So this is where the platform engineering rule really comes in, because when we get to this point, the platform engineers are maintaining the, the existing systems for automation, the platform itself.

They're maintaining that, but the idea is that it's so robust and resilient that there's not a whole huge amount of work to actually like, maintain what we had previously with these sre, right? There's not a huge SRE team here needed for that platform because it's just a company wide platform that's resilient, robust, but that doesn't mean that there's no more work to do. Instead, what we're saying that the platform engineering rule is actually a, a transition to a larger scope of problems, right?

So I always say that when you automate something, it's not that that work goes away, it's just that you just have a different set of work that's waiting for you, a different scope of problems. Now, this is true with platform engineering. So when we get the platform engineering, what these platform engineers are gonna do is they're gonna look to engineer solutions to larger problems, larger scale problems, enterprise worldwide spanning capacity planning, right?

So not just workload scheduling, but like, how can I schedule workloads so that anyone in any development, uh, uh, site anywhere in the world can go and push the service to production and it, and that service can actually go and be deployed or the most intelligent, efficient way among our entire worldwide set of compute platforms, our data centers, right? That is a huge task, right? And we only know of a few places where that's actually happening and being done because the, you know, there's certain companies that have the resources and the maturity to do it, right?

But that's the kind of large scale problems that platform engineering be, would be brought to bear on. And then refactoring the tech stack where needed. We're talking, not that the tech stack is necessarily needs to be refactored just because we want to, but we're looking at ways to make things more efficient, ways to help with capacity planning and better fitting these services where they need to be to be run.

So this could be things like, like, uh, like we have worldwide systems for performing caching and things like that, right? And we have better ways to enable services to take advantage of that. So sometimes we need to refactor that and say, well, there's a, there's a better way for services to take advantage of that cache.

There's a more optimal way, uh, push out new patterns or new services to help, uh, teams onboard to that. But it's also like, where can we save, uh, like memory on like small granular scalers scales that scale to huge workloads. So for example, if we can analyze things and say, Hey, there's a certain pod that's using a little bit too much memory, it's operating a little inefficient, we can make a change so that it impacts the entire platform of deployed services.

That's a huge savings in terms of the amount of memory we have across the entire world, right? And it saves a ton of money. There's numerous examples where US teams and services have optimized like small bits of the, the tech stack to reap huge benefits across the entire deployed platform.

And that's the kind of scale that we need to look to now, uh, the other part of that though is looking at, you know, once we have this platform in place, and once we have these guardrails that allow developers to go and publish services rapidly, we need to make sure that we're, we're making that, that set of tools in the guardrails that we're, we're feeding it, we're keeping it vital, we're keeping it relevant, we're making changes as needed, we're adding new features, and we're, um, having a roadmap of new features become available to that platform. So just as platform engineering denotes we're engineering reliability and rapid velocity into that platform, uh, into those guardrails and into those toolings and practices and processes. Um, and, and the other thing that we need to keep in mind is we have to integrate new tools and practices and make sure that it's, it's relevant and that it's actually speed and velocity.

When we have to take a look at the guardrails and then the platform, make sure is it actually doing what we intended it to do? Is it getting in the way? Is it, is it contributing to rapid velocity?

Is it being utilized, right? So we have to measure things like adoption, things like usage, and make sure people are actually using these. The other part of the though is that we also need to make sure that are there bespoke things being spun up?

It is not to say that we don't like innovation, but like, we don't want like three different types of testing frameworks for not, it's not needed, right? Like maybe we're just duplicating it because this group didn't know, Hey, there was this shared, uh, testing framework you could use out there that you could go and pull in. Now, I know that's kind of controversial reversal because it's like, if it wasn't invented here, it's not always as relevant to your running service.

And so I know a lot of us as engineers, we tend to see like bespoke tooling, uh, spin up all over the place. And before you know it, we've got like, um, you know, three different scheduling frameworks and automation, uh, flows, uh, flow tools spun up in three different teams, right? And then our job is we have to go and consolidate them because eventually our, our managers look at the efficiency of that and say, Hey, is there a way we can get efficiency and consolidate that, that functionality?

So as platform engineering, we're looking at the platform trying to see if we can get efficiency, but also that widespread adoption and measure that, quantify that and, and enable our developers to, uh, rapidly develop services with increased velocity. That's the goal of the platform, right? So what are the day-to-day challenges that the platform engineers are running into?

Like I said, the biggest part of that is that large scale engineering, it's the scale and the scope that really increases. SE you can think of SRE was dealing with smaller scope. Like I'm dealing with pods going down.

I'm dealing with a service that doesn't, uh, respond correctly. I'm dealing with latency and errors. What we're saying is that as sre, we got that corrected, we fixed it, we addressed it, and now we're at the point where, you know, the only thing the things that we need to care about are those large scale issues like the be able to, uh, increase capacity, increase, uh, scalability and increase our data centers efficiently across worldwide data data centers, right?

And that's a huge scale and scope. Uh, but also it, it denotes that the services and the platform is used by developers and services all and users all across the globe. And that's, that's a huge scale that encompasses a number of requirements as associated with it.

So it's not just like regional data centers anymore, it's like global enterprise wide, uh, concerns in terms of deploying services, running services, looking at efficiency, um, looking at usage patterns and things like that. So the complexity and the scale of this really increases. Um, the other part of this though, because we've now increased that scope, right?

And that scale of what we're doing, what we're responsible for, our risk has increased dramatically, right? And what we've said is that there's so many developers using this platform, there's so many end users who are impacted on it. If it's, if it's down that we have a much wider risk area, our surface area for risk has increased dramatically because there's so much widespread use and so much dependency on our services.

So it, it's, it, it's kind of a feast of riches, right? It's like we, we got exactly what we wanted, but now there's a lot of responsibility for it. And so that, that scale of risk also is another constraint on us in terms of how we can do patching, how we can roll out changes to the platform, uh, that doesn't impact people and their ability to release, uh, patches to services.

So, you know, you, you don't wanna have a platform that you're responsible for and all of a sudden something breaks and developers can't push changes to production because remember, uh, when we were looking at this model, we said that developers are gonna be the ones who are pushing things to production through automated tooling, through our automated processes, and we need to enable that. And if a developer blocked from doing that, it's we're basically blocked from responding to alerts, responding outages, or anything to that effect, right? Um, and then efficiency at scale is like as we go and do this at scale and we have a wider impact, we also need to look at, like I said, those more where we can actually get more efficient in anywhere in the tech stack from wide, from larger impact to small impact.

Uh, but the key thing is that we need to be able to quantify it and say, okay, this is a small improvement and process improvement, performance improvement, but when it scales to the entire platform, how much are we gonna save? Because what we've seen is when there's small savings that are deployed across a wide set of platform and services and infrastructure, it leads to a large amount of savings. Um, and sometimes, you know, the, the harder part of this is not necessarily like, Hey, here's something we can go and optimize.

It's peeling the onion to see where is that optimization exists. This is things where like performance improvements and, and analyzing memory usage and customer usage patterns and things like that, and the type of data and the frame, the rate of data that's coming in and things like that. Um, you know, it gets into larger discussions like, are we using the right type of database storage?

Are we using the right type of caching and things like that. Um, are developers using it in the right way for all their services? And so it, it, it gives us a very more, much more complex, uh, finops responsibility and efficiency responsibility also goes to things like scheduling and prioritization.

Like where should things be scheduled and prioritized and how does that relate to cost and things like that. Because cost is kind of an ever shifting thing depending on the cloud vendor, depending on your cloud topology, uh, and depending, depending on your resources. Um, the other thing though is that the challenge for day-to-day is that we don't necessarily have a huge amount of, of platform engineers like we did with s with SRE.

And I think that's kind of like intuitive in the sense that remember we said there's not as many on-call and on-call responsibilities as there was before, because through the guardrails we've been able to automate a lot of that responsibility so that alert's gonna go directly where they need to go to, but remediation is automatically taken care of. And telemetry enables us to actually have, you know, direct communication with the, the application that is having an issue. And that's different than the amount of SRE we had on call and, and the SRE team, because we had like almost like an army of SRE to go and, and tackle this problem.

But what we've said is that the problem has become so, so, so fixed and so attack attacked so well, we don't need as many on-call SRE as we don't need as many ses that are doing things anymore. And so, you know, the question kind of becomes, and that's sometimes an uncomfortable question, is what becomes the platform engineering role? Well, the real answer is, it, it depends.

So there's definitely platform engineers, there's engineers who are working on these tough problems, like I said, but there's not as many needed to be as a shield all throughout, right? At least in some scenarios you could still have that and have platform engineering be on call and things like that, but it's not necessarily a requirement, especially for example, if you get things all right and you get that on call SRE role as boring as possible, it doesn't really make a whole lot of sense anymore. That's where you start getting into things like you can carry a pager for like a day, two days, three days, 24 7, and that person doesn't really have to do much, right?

That I think that's where you can start having the discussion and say, well, you know, maybe that on-call isn't really needed as much as we can just alert the developers when the things they push break. And instead we direct our SRE to become platform engineers and work on those tough pro platform engineering problems. Um, and then remember, as sre, we can still engineer services, we can engineer automation, we engineer tooling, we engineer, uh, best practices.

And so we're still doing engineering work. It's just that we're not as directly in the line of fire, uh, for the on-call responsibility because we made the platform itself so stable and reliable. So you could almost say that you need basically a skeleton crew, not necessarily, you could say no oncall is really need it and shift left to the developers and the people who are pushing services.

Or you could say, say you have a skeleton on-call, like maybe one person is on call for the week twenty four seven because there's so little that they would have to do because the platform is so reliable, right? So that's, that's one way to look at it, that's a debatable, uh, topic. I know some people were really, uh, kind of nervous about looking at that, but I could say, you know, the, the, the, the wins of the industry kind of shift depending on the efficiency of this.

If you are seeing that the efficiency of on-call is not really there and the on-call person is gonna be becoming bored, it may be time to look and say, well, you know, maybe we need to re-engineer how we're doing on-call and responsibilities and, and look at how we're staffing that and look at more platform engineering roles as opposed to on-call roles, again, on call. Like sometimes we get so fixated and being on call, we get into the operations mode where it's like, we always need somebody on call type of thing. But remember, we're really trying to make it so that we can engineer a, a totally automated, remedied, remediating process so that we don't need that person on call.

At least that's our end goal. So, um, you know, like I said, we really shouldn't be surprised if we get to that point and we said, Hey, we don't really need somebody on call. That is kind of what we always said.

We were, our goal was, right? So it's, it's kinda, we have to keep in mind that we as SE said that we were actually engineering towards this, right? Platform engineering is the answer to what becomes if SE as f if SRE gets it all, right?

Right. We've engineered a resilient environment and we can support the rapid velocity of services. Now, in order to do that, like in order to have that skeleton crew or even nobody on call and shift left to somewhere else, to be able to be able to do that require a lot of engineering work.

And I can't stress that enough. It's not just something you just flip a switch overnight and you're there. There's a ton of guardrails that's a combination of policy processes and tooling and automation to make that happen.

There's a ton of automated remediation for almost every scenario that comes in. So everything that we've got that has pinged an on-call, SRE, our SRA team has gone and looked at automated remediation to make sure that we don't have that happen again, that we get alerted to that way, way in advance. And that it, that issue doesn't hit us twice, right?

And then we've made, because we've done that, our on-call responsibilities have become boring, uh, essentially, and it's been so easy to push changes to production or roll them back or fix things, right? So SRE as an on-call, uh, you know, first line firefighter, it is really kind of not as needed as much, like I said, the skeleton type crew. Um, and because we have those automated processes and everything in place, our compliance and security go hand in hand.

So that's things with, um, automatic patching access control and things like that. And it could be little things like, um, uh, like, like just using the platform gets you into the automated process of having good best practices and honestly remitting a lot of the issues you would have down the road anyway. So like a good example is like when you go to create a Kubernetes cluster, right?

Um, in this ideal world platform engineering, the platform has a way to do it. It's an opinionated way to automatically go and create those clusters that is secure for our environment. It uses our access control and it, it, uh, automatically aligns it to compliance scanning and tooling and things like that.

You don't have any more of like a developer needs to spin up a cluster so they just spin up a random Kubernetes cluster. Right? Now you have a snowflake cluster, you have a bunch of AppSec and certs that you need to go and track and, and scan and things like that.

You make sure that they're compliant with controlled guardrails. But, you know, the problem that I was, I always worry about is like, well, what if they didn't intend to like, have it follow all these guardrails 'cause like it's too much time or too much of a waste to go and do this. I'm just spending up a test environment for like an hour.

I don't need to do all that, but it still shows up on my radar and I still have to answer compliance reports for it. So by having one way that the platform automates to be able to do this task eliminates all that technical debt of somebody doing as a one-off or a snowflake. Um, similarly, if you need to make a change in production, a good example for that, uh, if you need to make a change request, but someone doesn't follow the process, right?

Well, what if the platform didn't allow them to have permission to make a change in production unless there was a change request, unless it was approved, then you don't have permission to write anything in production. That was always a worry of mine is like, sometimes you could have change requests that get created, but like what if the person didn't create a change request and they still have that access control, right? So it's kind of like an honor, your honor type of thing.

So I always says this, make sure that your access control is gated, uh, by your change requests so that we know exactly when a change is going in permission was granted, and we can zero in on that, right? Um, as what it'll look like when we get this all automated is, and we get to the edge of SRE and platform engineering is we're gonna have well automated systems and tools, resilient services, cost efficient use of resources, proactive, proactive remediation. But we're gonna start asking these questions of what is SRE are we doing SRE, right?

And where do we go from here? That's how you know when you're on that cusp of SE to platform engineering, right? Because you're almost at the, the the step of what are we, where do we go from here?

And, uh, you can almost think of this as a spectrum of there's many processes and tools and practices that you can put in place then you can adopt. There's no one set or bar that you meet that says, Hey, you're now platform engineering. I think, you know, that's always one of the, the, the issues that we've had when we're in the industry is that, you know, it's hard to know when you're doing this thing, when someone slaps a label on it.

You just kind of realize when you get to this point that hey, we're doing more mature stuff, larger scale stuff, uh, but we have to be proactive about it, right? So we have to be able to see how SRE is gonna evolve and not just wait for people to tell us that, Hey, you're platform engineering now we should take the reins and be in charge of defining what that means for us. We're taking the next step in calling our organization platform engineering because we've determined that we're mature enough that we have enough tooling in, in place, then we can actually make that next step as an organization.

Um, I hope this was insightful. If you have any questions or you want to follow up in the discussion, you can reach out to me on LinkedIn. Uh, you can follow my blog and definitely, uh, continue the discussion.

Thank you, and I hope this is insightful. Thank you.