 Cool, so, hello everybody. It's great to see you all here today. It's so cool to see people from all over the place. That's really exciting. Good to talk to every single one of you about this. I come to you from Humanitech to talk to you a little bit about what we've learned from the adoption of platform engineering. And what we originally called this is DevOps is Dead, as you can see with the cool logo. Obviously it's sure up a few things. It stirs some controversy, but I want to kind of dive into what it really is about and what that really means. DevOps isn't dead. We just need to talk about iterating and doing things a little bit better. So let's talk about doing DevOps responsibly. So as I said, my name is Mallory Hague. I'm the director of customer success here at Humanitech. I'm an active member of the platform engineering community as well. You may have seen me at KubeCon if you were there in Detroit in October. My background is actually, I'm a full stack engineer primarily from the e-commerce worlds and text-based online games, whole world in there that I've been doing since I was a kid. I've also been in fintech as well as automotive industry, but I'm actually an anthropologist by formal education. So part of what we're gonna talk today is about this collaboration of humans and technology and what happens and how we can manage that effectively and make sure that people aren't burning out. It's the perfect segue. We're gonna introduce you to kind of today's core theme. You can find me via email or at Mallory Hague. You can also find me by that name on LinkedIn if you're interested. So as a whole, the concept of DevOps as we know it is a victim of misinterpretation and misapplication. It's a bit of both. At its core though, we believe that DevOps is more than just a person you hire or a methodology you employ. It really is at the end of the day about people management and human interaction. It's about culture. It's this idea of you build it, you run it and you just have to suck it up and deal with it doesn't actually work. It ends up burning people out and ends up causing a whole slew of problems. So let's go into how this sort of happens and where it goes. We all know that cloud native is dirty, chaotic and complex. I don't have to tell this group that it's a very familiar group with this place. Developers right now are wasting about 25% of their time operating apps as the complexity increases. So we're looking at 25 more services and infrastructure resources per application in comparison to how things probably were in 2010, which I just realized is quite a long time ago when you think about it. But that's quite a big scale up in how complex things get in terms of services and infrastructure resources. There's also five times more specialist tools in the tool chain to meet the challenges of scaling. And with that also comes a lot more specialist roles including DevOps, SREs, whatever you want to call that role there is things that match this idea of specialized tools within the tool chain that meet the challenges that come with scaling. We're also seeing an increase in the demand and complexity of all of these different things which is driven by evolving global environments within applications. This is just sort of the nature of technology and we all know how this works but at the end of the day cloud native is a really complex sphere. There's a lot of things going on. It changes constantly and best practices are always evolving. So this idea of you build it, you run it at all costs really does not work. It results in burnout for you. It results in burnout for your team. When this was first said you build it, you run it in 2006. We think a lot of companies interpreted that kind of incorrectly and it's resulted in a lot of issues for people at the end of the day. So why are we talking about this now? Why is now the time to start thinking about something like platform engineering? We call platform engineering the logical 2.0 of DevOps. It's about enabling you build it, you run it but doing it responsibly, doing it in a sustainable way. While we have said that DevOps is dead what we actually really mean it's dead in the context of you build it, you run it at all costs. Instead we want to say this is a stage two that is more about enablement, engaging individual contributors in a way that they're comfortable and really just allowing people to grow within infrastructure and cloud native in a way that is sustainable for them. So it's about you build it, you run it but do it intelligently. And don't forget about the people at the end of the day that are sitting behind that computer screen. So this chart is really interesting and the reason I bring it up is because we're seeing a five year lag in concepts within cloud native really catching on and we're starting to notice now that there is a big adoption happening with platform orchestrators and IDPs. Things that are native to platform engineering as a whole. So we'll go into that a little bit but I just like to show this because it just shows that there is fairly predictable cycles of when things start getting adopted. So I suspect we will see this idea of DevOps 2.0 platform engineering as a logical thing more and more in the next few years. More people are talking about it and it's going to keep catching on. So why do we advocate so strongly for platforms and by extension platform engineering as opposed to traditional DevOps approaches? So for application developers we find an enable self-service they're able to do things on their own without resorting to ticket ops which as we all know is a big complicated process that makes everyone exhausted. It reduces cognitive load and by that we mean workload. So cognitive load is all about thinking way too much on things that aren't necessarily the best use of your brain power. It's about stress. It's about anxiety towards things. It's about managing your time. Part of that also lends to this idea of platform engineering reducing the amount that someone has to be abstracted away. We enable abstraction at whatever level someone feels comfortable. So a particular individual contributor may feel more comfortable working straight in their IDE where someone else may feel more comfortable working in their console via command line, curl commands or some other CLI type thing or even directly within a UI. The other thing that happens is that we increase psychological safety in someone's work. And I will talk a little bit more about this in a second once I hit on what happens for platform engineers and SREs. For these guys we allow greater standardization by design which greatly reduces ticket based ops. As you guys all probably know that is a big, big drag to your daily productivity when you're constantly doing every single task for five minutes a million times a day. It allows increased focus and getting people back to what they're doing best. And for platform engineers and SREs you can do a lot things a lot better than just doing ticket ops all day. And finally again, it's this element of increasing psychological safety. So really quickly I wanna touch on that subject because it's getting talked about more and more and it's really important to me that we talk about it as well. So it's the ability for an individual contributor to feel positively about contributing within their workspace. So free of judgment, open feedback culture in a supportive environment that really encourages people to take risks and lead initiatives on their own. In my experience with guiding the implementation of a platform orchestrator in Humanitech as well as platform engineering as a whole and managing engineering teams this is such an important thing and I really wanna stress that today. Helping people feel fulfilled and engaged in their work not only drives productivity and efficiency but keeps people happier. It grows loyalty to your product, to your business and it also helps people establish healthy work-life balance. When you're happy in your job you're more likely to take the time to take care of yourself because you have the time to do so and you have the freedom of thought to be able to be comfortable and in that headspace. So this is really, really important. We've noticed some interesting trends in how organizations implement DevOps. Now we've kind of talked about how it ends up impacting people. Let's look at what actually happens as people evolve around along the life cycle of implementing from standard DevOps to platform engineering. So we decided to use a car analogy for this because I think it makes sense for a lot of people. So an immature organization will tell teams hey, you need to build a car. They'll give you a credit card, tell you where to find a store with the raw materials. When the teams struggle with this they send in people and implement concepts to help them organize around this and we call this DevOps. This is sort of phase one. Phase two is a more mature organization. They tell a team, we need you to build a car. They give them their credit card and tell them where to find the raw materials. Hey, I need you to go to Home Depot or I need you to go to this steel shop to get the steel. They specify things a bit more. When the teams struggle DevOps helps them get a little more organized and CloudOps has helped them find the right material and prep those for them. So hey, we'll get the steel for you and we'll hammer it out into the right shape but you still are responsible for building everything at the end of the day. The most advanced organizations that we have found have said, hey team, time to build a car. So what the platform team does is prepare the platform which is the chassis of the car and has the developers build on top of the work. So this is the body work. This is installing the engine. This is installing the electronics inside and painting the outside when it's all done. DevOps helps them find structure to their work and order in the chaos. So hey, let's put the engine in first before we hook up the electronics or let's paint the car at the very end. Those things that a platform engineering team at an advanced level will be doing. So how do you get there? How do you get started along this platform engineering journey? How do you get your teams into this mindset that will enable them to feel more empowered at work, to have this reduced cognitive load and be able to get back to doing what they do best. We have seven key steps that we've identified along this journey and I'd like to go through these and show you how this works. So the first and most important step in my opinion is you have to go all in or nothing on this idea of your platform as a product. If you treat it with this context in mind, you will have a much more successful time adapting a platform to your organization, to your workflows and to your team structure. So assign a product over owner, even if it's only part-time, even if this person is a product owner for another product or another aspect of the application, have them also work as a PO or a PM for this project as well. Your platform team also needs to have engineers just like any other product team. They should have engineers that are dedicated to working on the platform. A roadmap is also useful and with that comes user interviews. So understanding feedback from your users about what works and what doesn't is going to be really important. And remember your users are actual users. So the people that use the platform every single day should be treated just like a customer, should be listened to, should be respected and their opinion should count. It's really important. So step two is not to fall for the prioritization policy and it's to prioritize your platform experience appropriately. The most common error we see is teams that take the first thing that comes to mind in an application and development life cycle and make this their highest priority rather than looking at everything holistically and saying what actually should be prioritized on the platform. So majority of platform teams will start by optimizing something like the creation of a new application or service. But how often in the real world does that really actually happen? If you take a step back and analyze the net gain of starting an app or service in relation to the total lifecycle of an application, it's really actually negligible. In our research, and you can see some of the parameters we've come up with here, seeing hundreds of setups like this. We've shown the highlighted areas to be the most important procedures to review first, but every organization does different. So be subjective and look hard. So for example, on this spreadsheet, you will see that what actually ends up being the most time for ops, including waiting and errors, is onboarding new developers. And that also is something that takes a lot of developer hours too. So that's something you can optimize really, really quickly. So that's the sort of thing you might wanna look at rather than, for example, spinning up an entirely new environment. It takes a lot of time, but the frequency at which it happens is fairly low. So you have to look at your particular setup and analyze it. And don't be afraid to get a little messy with it. So we'll move on now to step three. It's a little bit of a harsh truth to see on a screen that you will not be able to build a platform for everything, but we as engineers tend to overcomplicate things and want to go all the way 100% from the start. But it's important to know that you need to start with agreeing on the lowest common denominator tech stack to build your platform around it. So your baseline likely gonna be Kubernetes and containers. We will often see these not only focused around a certain Kubernetes distribution and related technologies as sort of the baseline, but also often container registries, databases and messaging that sends to be fairly common across an organization. Chances are if you use it in one place use it multiple. But at the end of the day, what's really important is critical review of your tech stack to find this baseline. This is something we're always happy to sort of advise on too and happy to look at and answer questions on. Step four is we need to identify some evangelists within the teams, especially for platforms. So generally this is a team of innovators with an app that exactly hits this target tech stack, this common denominator or most of the pieces of it and a team that really is ready to move towards platform engineering. So why find evangelists? These are the ones that spread the word about the positives of platform engineering and how it has impacted them within your organization. These are the folks that are gonna show and tell, they're gonna educate, they're gonna help grow the platform to other teams and applications within the sphere and help people get started quickly. They've done the hard work of making a skeleton system so adapt on it. That's part of why starting with the most common denominator tech stack is so important in this context. So creating evangelists is another way of promoting the psychological safety aspect I mentioned earlier within teams. It allows contributors to contribute. Novel concept, I know. And it's such an important thing to allow people to do in this industry. Allow someone to take the reins and be a leader and to be a thought leader within an organization and give them the power to be able to grow that way. It's pretty cool what happens when you do that. Next is to decide what pieces of your application need to be preexisting versus dynamic. I could spend hours doing a lecture on dynamic configuration management and the declarative application model but we have tons of resources on this available at the HumanTech blog that you can review. But really to put it quite simply we need to determine what components were made agnostic across the platform. So between different environments and different workloads and which will be dynamic to a particular workload to a particular resource or to a particular environment. At the heart of this we have the platform orchestrator which is what HumanTech is that mixes and matches the components based on the definitions you set out earlier. So the applications get deployed with very little overhead from manual input, custom automations that break all the time, YAML dumping and exhausted DevOps engineers who have been absolutely worn down by ticket ops. So that is kind of what the process ends up looking like and it's why it's so important to actually follow this declarative application model and the idea of dynamic configuration. We can always follow up with some great resources on this if it's new to you but I thoroughly encourage you to check it out because it's pretty special and really helps this whole model come together. All right, so step number six, finally it's time to start building. Our core recommendations are as follows. So build something that's just 10 times better even if it's small. We all know that iteration is the key to engineering and platform engineering is no different. We'll go into this a little bit more shortly and build where your ROI is. This comes back to effective prioritization from day one. So don't fall for that prioritization fallacy. Understand where the biggest return on investment is going to be for putting in the time to build a platform. Spend way too much time on the first build out of your platform. A solid concrete foundation will hold up a house better than one made of glass and paper. Make sure it is solid concrete, it's earthquake proof and it's ready to grow on top of. Also, make your evangelist team love it. They're there for a reason, build it and they will come. Making your evangelist team fall in love is absolutely key to adoption of platform engineering within your organization and the benefits I mentioned earlier for people. It's one of the most challenging parts but it is also one of the most rewarding. So I encourage you to think deeply about that one. Finally, step seven, it is a very long journey but it is incredibly rewarding one. So like Bilbo Baggins said, it's dangerous business Frodo going out your door but the door in this case and following the journey is a very valuable one, not just from a financial perspective but from a human perspective. The end of this process, your developers are engaged and happy. Your platform team is a group of folks who are now out of ticket ops hell. They're focusing on the more important aspects of their roles and they're growing as thought leaders within their organization. We've also reduced cognitive load and increased psychological safety for everybody in the engineering organization. Remember, iteration will always win. There's a strong community behind you when you're starting to do this, platformengineering.org. Humanitech is here as well. We are happy to discuss this philosophy more with you but we also have platform con coming out soon. You guys can start signing up for that. Now is also, if you're interested in speaking, we do have a call open for speakers and we also have tons of platform engineering meetups. So I encourage you to get involved in those. As I said, we're also happy here at Humanitech to discuss this philosophy with you and talk to you about how these things have impacted direct organizations with platform engineering.