Architecting Platforms at SKILup Days 2024

Good afternoon, good day. Uh, Buenos diag, wherever you might be in the world as joining us in this Skill Day presentation as we talk about platform engineering. Uh, again, this is the skill up presentation from, uh, people Cert as their new development and what used to be the DevOps Institute, or continues to be the DevOps Institute as part of People Cert starting out.

My presentation today is about architecting platforms. We've been talking a lot about platform engineering. What I want to talk about is some of the basics of that architecture.

I'm Dr. Mark Peters. I work for a company called Brain Go that does platform engineering, and today I am a value stream director for those engineering operations.

Some little tidbits about me because it always helps knowing who the, the presenter is and who the uh, director is. So as I said, I worked for BrainU. I did 22 years in the US Air Force, working in the intelligence field, working at ways of getting, uh, good things and good software technologies into the operational side.

I am a DevOps junkie and I've been an institute ambassador for the DevOps Institute for about four years now. Um, I do have a doctorate in strategic security and I have another, the doctorate in it with cybersecurity information assurance. So security is my first home, but don't hold that against me.

Uh, I have two dogs. I enjoy my family martial arts and that in my spare time. But with that, let's get into what we're really here to talk about today.

Let's get into the basics of platform architecture, platform engineering, using that architecture. So first off, we wanna say, why would you use platform engineering? Why is it important?

Well, as we do DevOps, we know in DevOps we've spent years figuring out the right way to do things. We go through these cycles and we build things fast. We get them to the right person.

We accelerate forward and we accelerate in the motion of what has to happen as we drive to those events. When we drive to those events, we identify the work, we find out how to automate those small deliverables and we create customer value. So the question I have for you is, when we've automated all that, we figured out our ways to do infrastructure and configurations code.

Why haven't we brought that back down into using a platform that's either built by someone else or that we built and generically leave there? We try to configure too many of these platforms as snowflakes, as individual thinks. So what we should be doing is using that existing platform to address the lessons learned, taking that knowledge we have from the basis figuring out whether we need to build our own and have a platform that exists for a long period of time, or to spare the infrastructure work by renting or buying a platform and getting directly to the app delivery.

What we want and what we usually want for our customers is how to get that software out. They don't care about what our tool shop looks like. They just wanna know that they can get the tool they want.

A common analogy I use in platform engineering is, it's like having a wood shop. If you need to build a shelf for your house and your significant other sends you out there and says, Hey, you need to build a shelf. You go to the tool store, you buy some tools, you buy some wood, you come back to the house, you get started, you realize you forgot something, you go back to the hardware store and you buy something else, and then you come back and start it again and then life interjects and you don't get to it.

And that shelf doesn't get built for four weeks or six weeks or a month. It's the same with the platform. A platform offers you the opportunity to have that fully built wood shop, to have all those tools right there so you can start doing what you need to do.

Now you wanna select the best wood shop, and that's really what platform architecture is about. We know that you can build your own and everybody can build their own. 'cause we're all skilled developers in 12 to 18 months, or we can use the knowledge and we can pick from what's already out there and we can select the big best wood shop that's on the market and rent or buy those existing options.

Now, I know that doesn't sound good. We're in the the DevOps Institute and everybody wants to do it on their own, but you still have to have that basic knowledge to be able to pick. And with that basic knowledge, we started the very basic levels of platform engineering.

Hopefully at this point, everyone has heard something about the four Cs. We build everything from a cloud, a cluster, a container, and a code getting more and more granular and more, more defined. As we work down with a platform, we're normally operating inside of a cloud or multi-cloud.

So what we're worried about is those clusters and those containers and then the code within those to drive forward. We use those code and we use those containers to build through an OSI model that all people seem to need, uh, data processing, right? Application, presentation, session, transport, network data, link and physical, all those things are important, but we move some of those things away when we concern ourselves with a platform, we're really concerned with the metal three, the session, the transport, and the network.

How do we build things in the right area? How do we get them where they need to go, and how do we make sure the network continues that application? That presentation becomes part of the finalized delivery.

What we have when we send something to somebody else or when we use it through there and the data link in the physical is well behind the scenes for anything we want to consider for a platform. Another good element to consider when we're building an architecture or looking for an efficient architecture as we drive forward is the solid architecture model. If you haven't heard this before, this is a very good acronym to get you to all the things that you need when you build those architectures.

First off is we have single responsibility in our architecture. Each object is only has one reason to change and one reason to change only. It does one thing in our process and that allows us to make the right suggestions and the right modifications, but only for certain things, which is our open and closed, that the elements are open for extension, that we can make them bigger, but we don't allow modification.

This goes back into our basic container strategy for immutability. We also have the list of substantial substitution. All class elements can be derived from the parent class and still provide the same results.

This builds heavily into our platform that will show you a number of tools that you can use to link things together, and each of those tools can take from a later element and still provide the same results regardless of where the user's operating. We make sure we have interface segregation with our platform. We're building that model for design.

We're building our wood shop where everything happens. So we wanna make sure that the users only use that wood shop and that they don't go off and build a piece of it in a different wood shop and then try to bring it in while we can do those things and we can make them the best platform architecture and the best platform. Engineered architecture says that we use the interfaces we have and we use them for a good reason.

And then of course, dependency inversion objects depend on abstractions rather than, uh, the inversion of depending on concreteness, if we make them depend on a single answer, it doesn't work as effectively. So what we have is we have to have them depend on that abstraction. Where do we have that class set up rather than where we have the individual thing addressed from those architecture?

We think about what the basic platform architecture for us is. We want to build around connected clusters. We wanna have those clusters be that unique purpose, uh, that they extend and that they're only doing one of those things.

Each of those clusters can have multiple containers running on it. Those containers call for an integrated orchestration, a way to bring the pieces together, a way to make sure they function. When we have those clusters that we build, we purpose build them through the infrastructures code.

The configuration is code. The clusters are built up to do a thing in a particular opinionated way and have an opinionated structure. If we want to only use Kubernetes, we set it for Kubernetes.

If we want to use another expression, if we want to use docker images, we set it for those docker images, but our platform is going to limit the number of options that our customer has. The reason we want to limit those options in architecture is we want to build that defined wood shop. If we build a defined wood shop to build a set number of things, we don't want to expand into considering a metal shop or we don't want to expand into considering ceramics or pottery or how you build those, we wanna focus on the wood shop.

With that, as we drive our platform architecture, we consider two key elements or two key factors to first separate them into the first being a collaboration cluster, which is where your coordination and your development occur. It's not enough to simply go in and build. You have to know what you want to build and have the blueprint and have ways to communicate.

And that all needs to happen in the collaboration fact. By centralizing these things, we make sure that we're getting all the information, uh, through from the start all the way to the finish. It provides a good place to, uh, obtain metrics that we can obtain not just our development metrics, but we can obtain metrics for the business side of the house and our program managers and those other folks as well.

Once you have that collaboration set. Next part is the deployment target. This is actually where we run the code and test and production.

We separate this out from our collaboration cluster so that as you'll see later, we can stand those up or tear those down at any particular point. We can test our wood shop functions out in a, a, a different environment and then bring them back to the wood shop for the fixes that they need, uh, to be successful in driving forward. When we first start looking at our collaboration cluster, this is our spot where our cooperative work happens from the DevOps loop.

If you remember what we do in the collaboration clusters, we concentrate on those plan code and build phases. We want to make sure we have a good plan for what needs to be done. We line out and communicate requirements.

We actually code those things into the initial stacks. We show those, we show those poll requests, we show what can happen, and then we do some of the initial building before we put it out into that deployment target. When I think of a collaboration cluster, some of the key elements you want to have, whether you're building your own platform or you're looking for one, is first some type of communication, some type of asynchronous chat.

As we all work remotely, we know sometimes it is difficult to get somebody on the hook, uh, to answer something or to be in a meeting, but we, if we have the chat, we have the tracking of those messages. Tools like Slack and Mattermost are common for this and provide that initial communication within the cluster. Uh, we also want to have an integrated development environment someplace where they actually do their coding.

Um, this provides a sense where you can share things, where you can do those pull requests, where you can do the merge requests, things like GitHub vs. Code, Anaconda, Jupyter Network. If you have one, you've set those parameters down.

You haven't expand them to use any wood shop they want or any development they want, but you're limiting to the, to the number of options they have so that you can control those later on and get to the best application possible that you can build that best shelf from that integrated development environment. And from that coding, we move on to do work management. How do we do the boards?

How do we do our sprint boards? How do we do our Kanban boards so that we can track what is actually occurring? Most of the tools in the integrated development environment may have some form of this.

GitHub and GitLab offers some tools. Uh, Trello offers additional tools, as does Atlassian, as I'm sure many of you have used, the Jira and Confluence type suite. Uh, this provides not just the, the track of that work, but the knowledge basis that you can use through like a wiki where the knowledge hubs are all in a central point.

Instead of looking for something through multiple avenues, you're going to one central spot that's in this collaboration cluster. That's where all your information is about how to use the cluster as well as the projects you've been managing on the cluster and how to drive forward on those. When we do that work management, we also have to monitor it because we're using those clusters and we're setting up new clusters as their deployment target, we have to integrate that and bring that data back.

When those clusters or containers go down, we need to make sure we have the data that that data hasn't been destroyed or removed. Uh, we can centralize this through that collaboration cluster using tools like Prometheus Cabana, uh, open Telemetry, one of my personal favorites that you can hook into everything and get the right reports. Uh, elastic Stack, one of the paid versions that'll get things out.

But centralizing that information through the collaboration cluster allows you to find those things and allows you to manage them and present them through a series of dashboards or other information to get the right tools. And then of course, from the security aspect, as I said, I'm security at heart. You want to have a single sign on.

You want to make sure that you sign on to that collaboration cluster and that sign on leads you to the other things through federated identity practices. This provides you with a secure access. It distinguishes your different teams as you bring different teams onto the collaboration cluster, and it helps protect the data when you can separate a team and say, team A needs to build this one type of thing, and Team B needs to build this type of thing, but I don't want them to collaborate because they're supposed to be doing independent solutions.

Well, you can protect that. You can stream that out through the collaboration cluster. And then the section of the IDE that they get to, or the section of the work management is only their section.

Some of the tools that help provide some of these things for us that are out there today are tools like Key Cloak, Okta, and Dual. Always use some of the lightweight directory, uh, application protocols, the LDAP type functions, and make sure that you can get to the next steps to make sure that you can communicate that one token, that OAuth token you have through a federated identity to get to multiple plans from that initial collaboration cluster, we want to build through the deployment target where we actually see the application right, where we can run it, where we can test it in our safe space to work our thing That drives us forward into the next step in that DevOps cycle. In the deployment target, we're seeing our tests release and deploy.

We're building this again from the infrastructure as code with clear definitions. We're setting up those samples of what we want to have and only what we want to have in those areas as they stand up. Some of the common samples of these deployment things include things like Kubernetes where we can stand up the containers, some of the Docker images, some of the Amazon machine interfaces that will set up different areas of your cloud in a particular way.

But knowing what we want to have, being able to build those things and have them already set up. So when the cluster gets launched for the deployment target, we know what's in it and we know how it's gonna move forward with that. We talk about the continuous integration, continuous delivery, the end of the pipeline, right?

Everyone wants their pipeline to run forward. Well, we've started our pipeline in collaboration and we've made sure we've had the good code and then as we push it through these deployment tools, through these CI tools and make sure that it's good in that deployment target as well, so that the different set of parameters or the little bit of infrastructures code that may change between the collaboration and the deployment remains similar enough that the tools like Jenkins, GitHub's Circle, CI harness, et cetera, uh, can deploy things to where we want to. We do want to avoid vendor lockin through these things as always, uh, but sometimes we want to be a little bit more opinionated.

So vendor lockin isn't as big of a deal in a platform engineering because we have it all set. We know that everyone is gonna come into our wood shop and they're gonna build their shelves and they're gonna build the bird houses and they're gonna build their little wood race cars, and they may convert them a little bit. It may have more shelves or a different color or more holes in the bird house, but they're all building within that same framework because that's what they want to get to, is to have that architecture deployment built so they can get to the next step with those thoughts.

With thinking about the collaboration, the deployment target, we wanna think about how we scale and secure models. Now what, when I'm scaling and securing, I always use this similar thought framework for myself to think about how I'm doing things. Any app that I have out there, any platform that I have out there, I want it to be stable.

I want it to be secure. I want it to be adaptive that I can make changes when necessary and that I want to be able to either to scale it when needed. Now against those, I run these horizontal layers.

You see support, design, develop, deploy, and operate. When I look at these things in the management framework, I think of these as the relative amount of time I spend doing these things. So you see, support is the largest.

We're gonna spend most of our time supporting an app, supporting something that has actually been done, whether that happens in the development team or elsewhere. We wanna make sure that those support functions are embedded within the platform. We spend a little bit of time on designing.

We make sure we have the good initial thought because we're testing things out through our flow, feedback and improvement. So we design it, then we develop it, then we deploy it, and then we operate it, we operate it, spending a little bit of time, and once we know we have the operation smooth, that's when we move back to our support phase of how do we continue to support those things. But it goes a little bit further than that as we talk about scalability.

Scalability of course, is the way to go up or down to make sure that we have turtles all the way down, that there's turtles in the stack everywhere, and that we don't get away from using those turtles as we drive forward. These scalability changes is when the platform has to change in size or volume to meet a customer demand. Normally, when we think about scalability, we think exclusively about the factor that we need to scale up.

We need to get bigger and always bigger, but with a platform and with these clusters standing up and standing down and moving back and forth, we also need to consider downwards when we don't have as much use, how do we scale them? How do we make sure that those instances when they come up or go down always look the same to users? That we can show what the metrics for those clusters are across our multiple clusters.

As an example, we may see high user numbers, uh, which trigger our load balancing, which are giving us extra compute and store, but we may want to reduce those during the off hours because we don't want to spend as much money on the cloud. We don't want to spend as much money on the functions. Our clusters, as we designed them in a platform, are inherently scalable.

Using a Terraform or other, uh, YAML function provides a common basis across the clusters that they have a common place they go back to. We can also use generative AI options to support that user scalability, predicting what the demand might be, predicting what might come up in the future, and offering some options to alleviate that. When we do the scaling of the cloud cluster, that should be internal to our support team, to our platform team that we have or to that external platform team.

If we rent or buy these collaboration clusters, support multiple deployment targets that have varying lifetimes, but our collaboration environment needs to be relatively stable. The challenge becomes integrated between the work management and the deployment across teams, making sure that we can maintain a good sense of their work management, of what they're managing and how they're managing it, and then when they're deploying it and how often they're using those deployment access. When we do that scaling as well, we return to that, so that role-based access control, that individuals only have access to what they need and even as it scales up or down, they remain within those same channels.

So they continue to have access to the right functions. Having those right functions and having that right access ties us into our security functions. Security, of course, is ensuring only the approved users can access the approved items.

We may have multiple roles inside one of our IDE environments where only certain individuals can actually move it into the deployment environment, or maybe we want everyone to move it into the deployment environment, but we can change those things through using the OAuth, the open authorization, and as I mentioned, the ldap, that lightweight directory access protocols. We've tied those rule-based access controls to the security in our platform. So security comes first because we don't want anyone wandering into our, uh, our wood shop and walking off with some of the tools.

We want to leave all those tools there for any user that has them as they drive forward. As we consider security, we consider security from three aspects. First, we consider it as a platform access.

How do I get into the platform? So we want to be able to log into the platform. We want to be able to access collaboration.

We want to have those organization, team and individual user structures, uh, built as part of the role-based access so they can get the functions they need and they can use those functions to communicate work as it works, as it drives forward. From that access, we wanna make sure that they can run on the development targets. So those development targets are inherently tied to our security into our platform access of which deployment targets you might be able to get or development target and how you use it.

The second of course is the data access. Uh, and we've hit this a little bit in the platform access of which teams and which organizations. Some of those tools that do some real good, uh, work with managing that rback are tools like DUO and Okta, again, A-W-S-S-S-O, off point SSO, Azure Active Directory if you're a Missouri user.

But each of those make sure that you only have the right things, that you have the right tokens and the right tickets as you drive forward. Third, of course, is data transfer. As we transfer data between our clusters and between our containers, we wanna make sure that we have the right security encryption standards are always preferred, and in using a platform we can maintain that we have the right encryption in common encryption standards that we're not using different FIPs elements between, uh, different clusters, that we're moving from one type of encryption to another and we're losing the data.

We're not able to compute things in the way we want to. This applies both to the data at rest that remains within the platform and the data in motion between that collaboration cluster and the, um, the other deployment targets or other elements of the cluster within the containers. Uh, as it moves back and forth.

And I'd be remiss in my security duties if I didn't mention the data recovery. It's not enough to simply have a good wood shop if something happens, if the rainstorm comes through, you wanna make sure that you can recover. So one of the ways that we recover on software, as we always mention the 3, 2, 1 model, when you're doing data, when you have data, you should have three locations, two media types, and one offsite or offline.

Now with the platform, again, the benefit becomes that you can rely on someone else to do this data recovery for you, that as you do things in the deployment targets, they will automatically back up. They'll automatically go to sections, and you can recover that work as needed in different areas. So with scalability and security considered, one of the other thoughts is about how we move from legacy to cloud.

Native legacy or platforms are inherently a, a cloud function because we have this cloud, have these containers and they work better. Uh, it doesn't mean you can don't have to do it or can't do it if you have a legacy system, but it comes a little bit more difficult to work the connection between the functions. Uh, we mentioned the six Rs and going to cloud native, and of course, hopefully, again, I you think you've heard these, uh, full discussion of these is kind of a topic too large for this presentation at the time.

But to rehost, uh, to move, which is moving from one to the other to re-platform to move from one platform to another, to repurchase buying something new, to simply keep what you have to retire what you have, or to refactor it entirely. Uh, going from a Kubernetes to a Doctor Docker might require refactoring as we have to change the baseline code. We have to drive to that next step, uh, with platform, depending on these cloud solutions, uh, the legacy is possible, like I said, but we, it reduces the ability to use some of the shared resources to get to some of those external things, some of those dependencies that you may wanna hook out into a dependency or a database that's not residing on your platform, but just for the purpose of that app, uh, this can also impact remote users with how they can get into it or how much security you need to maintain their access to these legacy things if they're simply an on-premise solution.

From that, we get to what I have as some of the basic platform structures. As you look at this basic platform architecture, the real, uh, core point, kind of the, the meat of how this presentation goes is how do I build it? What do I wanna look for in that platform?

And I see these as three basic setups. We have a, a permanent, a transitory, and an ephemeral of which we'll talk a little bit more on these following slides. So first off, the permanent design is designed for long term.

This has multiple clusters that are always present. Once you set up the cluster, once you set up that collaboration cluster and those deployment targets, they're always there. You can pre designate them for certain purposes.

You can make the pathways and the frameworks between those. You can use the session and the transport, uh, to get you to where you need to be. This deprecates some of the collaboration load balancing in favor of a stable configuration that it always remains the same, that you always have a set amount of computer store instead of going up or down all the time, you're kind of tying it to a known thing.

This works really best when the expected usage is known. I know how much I have to want. I'm going into a set organization, I'm building a wood shop because I know the customer wants shelves and they want shelves.

Uh, and the turtles all the way down. They want shelves from now until the end of time. As that variability occurs, I can build them, I can change from a shelf to building a bookcase to building a desk, uh, but I still know what the kind of that general expected usage is.

A permanent design gets us a, a benefit of a known configuration that has proven maintainability because it is so stable, we know exactly what we have to maintain and how to version update. We can do blue-green changes between the different clusters, and we can adjust them as needed as we get version changes to other things. It also provides us with a clear training and outlines.

We have set how-tos on how to use the structures exists with very little variability between one user to the other on the system. Their changes are coming in that team and organization framework, not in their individual framework of how they use the system. This gives us the ability to firmly set in place as part of our configuration as code some of those rest APIs, some of our no-code applications to help beginner users and to integrate with tools like cross plane, which converts everything into a Kubernetes API or Istio is a sidecar security tool.

Then of course, you have the difficulties if it's permanent, it can be difficult to change rapidly. It may be tough to change from tooling for a wood shop to tooling for a house or tooling for a shed, uh, that the, the capacity just doesn't exist. So we have to make sure that we're, we're not changing a lot, uh, when we put these forwards.

Some of those new versions can change migration challenges, uh, not just new versions within those containers, but if it's a new version of the platform itself, how do we take things from the old platform and migrate them into the new platform? Uh, making sure that we have the right monitoring tools in place so that we can visualize those resources as we use them stable. We tend to depend on the fact that they are stable and we tend to scale down a little bit from how much we view those me metrics and those things on a regular basis.

But they're still important to see and they're an important metric for us in terms of our overall operability, maintainability. And then of course transportability. If it's permanent, uh, it's gonna be difficult to pick up and transport to somewhere else.

If I want to go to a multi-cloud environment, if I want to use both AWS and a w those and have the same platforms linked together, uh, it can be a little bit difficult where they're set up permanently in one set. So as we look at the permit model, we think we can solve some of those designs. If we go to a transitory design, a different type of architecture, this only calls the resources when needed.

It is load balance, but has that dt uh, cluster creation on demand. It would use metrics to scale as time usage demand, but those metrics would be preset when you stand up that deployment target. It only exists for a set amount, uh, based on the metrics you have, and those metrics would be set at the platform level.

You can have an extension of the wood shop, but we're only extending it for 24 hours or 72 hours or until you reach, reach a certain amount of compute, and then we're gonna pull back down again. This gives us the benefit of having controllable costs that we can disable that new cluster at any point. It removes some of those unused resources and excels when we have items that we know are gonna be a defined period of time when we're supporting retail sales and we only expect something to go up or we expect a sudden increase where we're working on a clear project where we have to build a very specialized thing.

I'm building a wooden dinosaur for the front of my, you know, two year old's birthday party is something that we have, and then we know we're gonna tear them down and go to something else 'cause something else comes next. Uh, disadvantage is some of the information may disappear if we don't have the right practices in place around when we stand them up and when we pull them down. Information that is actually running on one of those targets, uh, may not be saved.

Uh, it may also be difficult to manage operations for how long do you transit? If you're depending on an operational metric for your organization and the cluster that you are monitoring for that operational metric goes away, uh, it can cause odd changes and things. Um, one of the examples being, uh, if you race, uh, a lot of people manage development from when the time started and they start something, but then they never start working on it and then, uh, they start and finish, but they figure it wasn't the time they initially started working on it, but the time when they actually became involved with it, that matters, right?

So they only ran a mile out of the marathon, so they want to take that marathon, that one mile time and apply that to their entire marathon, uh, and say that it's a good time. Uh, but you can't really do that if these things transit. So you have to be a little bit more prepared, uh, and also do those clusters stay as long as you expect when you're doing those type of things.

That security of that data analysis. Uh, if the cluster goes away with the associated information that's been on it, if you've been using to support a retail sale, how do I make sure that I get that information back? So that can be a disadvantage, but it is one that we can solve with monitoring and operations.

The last set is the ephemeral design. While this looks similar to the transitory, there's a little bit different interpretation. The collab remains stable, but users build on the commit with a set expiration.

This transfers the time for setting up those deployment targets, uh, from the overall platform to the individual user to decide how long they want it up for. Now, this allows more user control. You can still, uh, kind of control it from a program level by saying there's a, a set parameters or set functions that you work through, but it does provide a little bit more of a metric based based execution.

The benefits, of course, are you can use to check things with high demand, uh, and then deprecate. You can do an operations management to end up a high use operations tool that's gonna do a lot of things and run it off from everything else, get all your data, get all your information, and then tear it back down again. Uh, that short nature helps support some of the tight budgets.

Uh, if we don't have a lot of money for cloud usage, if we don't have a lot of money for these things, uh, it can help. And as I said, because it has that specific you could control, uh, it supports both new and experienced users. It's not real good for people who are still kind of finding their way around, but it can stand up for a new user to do a very specific thing or an experienced user who knows exactly what they want and they only want it for that particular time, uh, and then it's done.

That becomes a disadvantage though. If you need to know exactly what you want to be able to support this and allow that type of user control, it can be difficult to scale properly. Uh, if you're standing them up, you could get a whole team standing a whole bunch up at once to do similar things.

Uh, so you have to know what you want and how that interacts between the different areas. And it can be a challenge in having enough templates, uh, if people are trying to do different things on a smaller basis and want to use a variety of templates. So those are our three basic designs, uh, for looking at an architecture, whether you're renting, buying, or building your own, uh, I think platform engineering is an excellent step in helping us reach the next step.

In DevOps, we build our platform architecture through that solid structure using those collaboration deployment targets to support how we structure the ideas. Scaling and security are primary benefits within a successful platform because we can scale up rapidly, uh, and we can make sure that they're secure by having a common user basis having those common user tokens. Some of the sample models we talked about just recently were the permanent transitory and ephemeral design.

So this is a growing field. There are, I these are ideas to move forward. Obviously this isn't the end of the conversation, but the beginning of the conversation and I'm always interested in hearing further approaches and further, uh, ideas about how we can grow our platform engineering.

If this presentation was interesting, I have to point out Gotham ppa, who's another, uh, DevOps ambassador, and I have an upcoming book from Packet coming out September, October, talking about platform engineering from DevOps covering this as a well, a range of other additional topics. But overall, thank you for your time today. If you have any questions, you can hit me up at a tiny cyber on Twitter or tiny DI on Peters ii at gmail is my address.

Or you can find me on LinkedIn at uh, tiny Cyber as well. Thank you very much for your time and I hope you learned, uh, what you intended to get outta this. Thanks again.