 All right, good to see everybody. Lots of people coming in from all over the world, which is very exciting. I apologize to the person that was in Calgary where it is minus 42 degrees Celsius today. Yeah, thankfully it's not that cold here, but yeah, we'll get rolling with this. Got quite a lot of things to go through with you guys today, so let me just get started. Here I'm going to wrangle my monitors as one does. So we today are going to talk about the concept of a minimum viable platform and what it means to create one, what it means to conceptualize one and think about one in your day to day and also what it means to think about scaling one. This is a really exciting topic for us at Humanitech, but it's also a platform engineering topic because what essentially happens and how this has kind of come around is by really using the principles of platform engineering and seeing what happens when people start thinking about initiatives for platform engineering inside their organization. So if you don't know me, my name is Mallory and I'm the director of customer success at Humanitech. I am actually a software engineer by background, very old school PHP developer from the early mid 2000s. The odds as it is it were, and I've sort of just evolved over time to also have this kind of deep love and appreciation for cloud native. And I have moved on from PHP. I still touch it occasionally, but I rest assured have grown away from that a little bit. So my job here at Humanitech is to make sure that our customer is not only use the platform, but also fall in love with it. So we're gonna talk a little bit about the philosophy in that way today. You can email me, you can reach out to me on Twitter. I rarely use it, but you're also welcome to find me on LinkedIn. So we're gonna go over a couple different things today, really just four key sections, but there is quite a bit inside each one. First, we're gonna talk about what a minimum viable platform actually is. I think it's important to start here because a lot of people are going to confuse MVP in the traditional sense with minimum viable platform. So I wanna make sure we differentiate. Then we're gonna also talk about why, why you do things this way and why this works. Finally, we'll do some design work. There will be a little bit of actual technical information that comes in here. And then we'll also talk about adoption and expansion. I just wanna make a quick note that the next, I think next week webinar we are having is actually about doing these things. So actually putting things into action, doing the hands-on stuff. So if you start today and you understand the theory behind it and you understand sort of the general principle, you'll be really well-prepared next week to get rolling. So I always like to start my webinars with a question. Why do you guys think platform engineering initiatives often fail? And I'll open the chat here and invite you guys to share your thoughts, maybe in a quick couple of words. Why do you think this stuff fails? Let's see what we can see here. There we go. Management, don't get it. Adoption, yep. No customer focus, failure to collaborate. No, well, not well-defined. Institutional requirements, same idea. Yep, customer requirements not said. You guys are all hitting the right points. And I think this is a testament to the platform engineering philosophy as a whole. And also, yeah, that's a big one inertia. People don't like change. So how do you prevent that from happening? When you look at why things fail, we tend to think about them failing in platform engineering as this intertwined web of culture and process. I think these are three of the primary technical reasons below why stuff falls apart. So you get this concept of speedy complexity. People just go down this rabbit hole of trying to solve every problem and developer experience issue and every request at the same time. This is not going to work. You get pulled into a trap of complexity. You never get anything done. You basically just get stuck. And I call this the it's not perfect yet problem because that's the way it's often described. It's like, well, we can't use it, it's not perfect. But here's the thing, nothing ever is in software engineering. So that is the way to think about it. The second thing I think people get stuck on a lot is tool chain quicksand. So this is basically where you get into this trap of thinking it's all about tools. It's all about infrastructure components. And it's all about what you're gonna use for databases and how you're gonna do Ingress and how you're gonna do multi-cloud deployment and what CDS are gonna use. But at the end of the day, you have to actually build something that developers will use and that they will enjoy using because otherwise you just wasted a ton of your time. The other thing that sometimes happens in this vein is that some platform engineering teams are convinced that they have to do something completely unique. They have to reinvent the wheel as it were. You don't. I know we've said it a thousand times and I know platform engineering has said it a thousand times, you're not special. There's a reason why things work as a standard. It's really important to remember that. The last thing I see a lot of is chaotic focus. So I like to say, if you fail to plan, you're going to plan to fail. If you don't focus in on the actual problems you are trying to solve and the key core problems, not this whole vast sphere of them, but just sort of the ones at the heart of what's going on inside your developer experience and your development lifecycle. If you don't do that, you will get stuck. Teams in this category that fall down this rabbit hole don't actually ship their mindset. They don't think of platform as a product and when you don't do that, this also will not work. The worst part of this though, is that this wormhole is the one that people do where they build tools that no one ever asked for and people just don't use. And it's a huge waste of time and money. There is a little bit more of the nine steps to platform engineering hell. Great article. I encourage you guys to check it out because it is exactly what we see why these fail. So on our side of Humanitech, obviously on the customer success side, we see a lot of platform engineering initiatives. We see a lot of platform setups and a lot of ideas. And what we've been able to come up with is this framework for starting things off the right way. So when you start a platform engineering initiative, this is how you get things rolling. This is how you get eventual adoption and this is how you get buy-in. We call it a minimum viable platform, not to use a short form that's already been used but we think it actually makes sense. So the TLDR of what a minimum viable platform and MVP is, is that it's a way to show the value of a PE initiative very fast. So you do this by identifying pioneering teams that can lead the way, the ideas that they're innovative. It's by building a highly simplified, representative first version of the platform in the context of a hello world. Guys probably all know what that is. It's also having a product like roadmap, for iteration and growth. It's not just throwing things at the wall. It's really planning what a roadmap needs to look like. It's also seeking out influential stakeholders who can drive adoption. It's making sure that those folks are getting on board very quickly and they're excited for the entire time. You keep that momentum going, that train going down the tracks. And part of why this stuff works is because you end up avoiding having to win over every single developer team or adjacent team right away. You can start small and you can build it up from there. It's less resource required. It's a lot less time required and you can get to places very quickly and show value very fast. So why? Why do things this way instead of building out something a little more full-fledged from the start? So I'd say that there's four primary whys that we've come up with so far. The first one is just get wins. Get a concept off the ground quickly that shows value in weeks, not months. When you take it slowly step by step and you start small and you give yourself a timeline that pushes you to get it done very quickly, magic happens and we've seen it time and time again. The other thing is that this path builds groundswell and it builds momentum without the friction that happens when you start having to interact with all the other parts of an organization. When you start really small like this, you're basically building something that ends up gaining so much traction because it gradually catches on person by person by person or by team that these other teams can't say no. So in this context, I mean your finance team can't say no once you start building this momentum and everyone wants it. Old school development teams that are suddenly weeks and weeks and weeks behind on their sprints and their to-dos because they haven't adopted this technology suddenly go, oh, maybe that's not such a bad idea. And with that comes this idea avoiding that platform engineering hell by design. So you're not going to get yourself stuck in a lot of those fallacies because this process was actually designed to bypass those. It was designed with the theory and the philosophy of platform engineering in mind. And finally, I think it's really important that this path inspires teams, increases psychological safety. If you guys have seen me in webinars before you know that is a big topic for me. I think that these pioneering teams that lead the way and innovate within organizations, it adds excitement to the day-to-day for those people. It's an incentive who doesn't want to be seen as an innovator, a big thinker and a big push forward. And a lot of people that get involved in this stuff become very passionate about it. And it's really wonderful to watch from the sidelines as people really engage and fall in love with this concept and essentially shout it from the rooftops. It's very cool. So let's do some design work. So I won't read this slide to you. You were going to get a copy of this deck and the reason why I made it so verbose is so that you can take the time and take the information in. But from a general perspective and looking at the design of these MVPs you should think about them as four key concepts. So they should be representative. They should be representing common resource components that go across your technical estate. So what's the most common database type? What is the most basic CI CD layers that sit underneath your applications? What is your basic application structure? So for most folks that's a front end service, a back end service or two and a data layer. You're also probably going to look at basic ingress in DNS depending on what kind of applications you build. This stuff's really at the heart of probably every single development team within your organization or product. The next thing is that it's repeatable. So the idea is that you're building something that can be repeated again and again and again. And when you go to onboard new applications and new teams to this platform it should be very easy because the baseline is there and the baseline works. Think about it as a quick start for onboarding new applications and teams across your org. The third thing is iterative. So the whole idea is that you start small but you think about the future on the horizon. When you start thinking about this stuff and you allow yourself to start small you don't get caught in that complexity paradox where you're just over complicating it from the start. You know iteration is coming. You know you can think about that stuff and you also know you can confidently say we will put that on the roadmap. And finally, it should be innovative. The teams that work on this thing should be your pioneering teams and they should want to push things forward and engage inside of your internal developer community to push new technology and new ideas. I like to think about this as inspire, don't undermine or undermine, inspire the people internally to do things that are different and to try things that are new but also don't undermine the fact that everyone has unique ideas and ways of thinking. MVPs are not certain things as well and this is sort of where I like to, I will say put my foot down on how things are done and how you design these from a technical perspective. It can be challenging to do some of these things but I promise you if you do think about it this way it will make your life much easier. So MVPs are not high compliance. Instead of looking at very complex security requirements or high requirements of actual compliance and regulated industries, move fast with tools that don't require this to start. So generally how we've done this with our customers is sandbox accounts in AWS or GCP or Azure whatever it might be and demo applications. So there's nothing really proprietary, things that you can just go set up on your own and experiment with that don't require a million signatures. So that is generally how these start. The next thing is advanced architectures. So when we look at this, if you start talking about service meshes, multi-cluster deployments, failovers, customized portals, all this sort of stuff is way too advanced for iteration one. These are roadmap items and keep that in mind because you're gonna want to put those chances on your roadmap. Just start simple and think ahead. Think about what could come and allow yourself to start way before that. The next thing is advanced resource configuration. It's really easy to start thinking, well, I have six different setups for Postgres depending on what application and what workload it is and what environment it is. Just start really simple. Just start with a very common setup. You can't go into thinking about every single edge case at this stage. It's just not sustainable. Limit yourself to like a single tool or a single resource for each kind of component that you're looking at. So one database type, basic app structure, like I've already talked about, very simple ingress, basic CI and CD. Start here and grow. And finally, advanced observability. Set up a basic cluster and deployment monitoring because you're gonna want that. You're going to need that, but don't go overboard with tagging and all the other fun things you can do is stuff like Datadog because it's just not needed at this stage. Match the stage of your observability with the stage of your platform. It also doesn't make sense to put in really advanced logging and tracking on something that's so simple. I will note though, there are always exceptions to these rules. Sometimes you can't get past a high compliance scenario. Sometimes you need to put in a portal for your first integration. These things happen and you should be a little bit flexible on them, but try to maintain the key concepts of speed, time to value and iterative complexity in mind. If it can wait, it probably should. So I talked about pioneering teams and now I want to explain what we're actually looking for here and maybe you're part of one of these teams. These folks are hungry, they're excited by new technology, they're interested in driving innovation and they really want to do new things and encourage others to do the same. Sometimes we see this team actually existing within organizations. So some of the ones I've seen have been called Cloud Center of Excellence, Innovation Team, Developer Experience Team. We've seen a ton of these actually exist and it's very cool that they are part of large and small organizations. It just shows that people are thinking about this stuff, but you don't have to have a team with a fancy name on it. It can also just be a group of people that have a similar mindset, passionate developers, passionate platform folks who like to experiment, who like to inspire and who like to just think outside the box. So this team needs to be comfortable with showing, not telling. I can tell you all day how to do this, but if I don't show you in some way or another, I'm not really being a pioneer. It's really important to give people a example and a way to see something rather than just being told about it. And we'll do that in a bit. They also need to be comfortable being thought leaders. Some people are, some people aren't. They also need to be comfortable thinking small and starting that way and thinking long term. Some people just like to go 100,000% right out of the gate. As I said before, it's not super sustainable. And the final thing they should be comfortable with, which I think I've mentioned ad nauseam at this point, is evangelizing technology. You should really like to overshare about the cool stuff you're playing with. So we have our pioneering team. We have our general concept. Let's start on a technical design. So just remember, start simple, plan ahead. Aim to show value to the stakeholders you define within four weeks. It can only be done this way if you keep it simple. I know I keep harping on it, but it's extremely important. When you show that you can go to value very quickly, not just from a technical stakeholder perspective, but when you look at management and higher levels, executive level even, the faster you can show value in an initiative, the more likely it is to be adopted. So remember too at this stage that the representative application you should look at should follow a similar structure to a majority of your app state. So if you have a ton of microservices and microservice-based applications, that is how you should be showing it rather than just going with a giant monolith, which you only use in maybe a couple legacy components. Don't do that. Start with the representative app. Think about filling the basic components on a reference architecture diagram if you've hung out around Humanitech long enough or you have also looked around Platform Engineering.org enough, you will have seen some of these and I'll show you one in a little bit and what I mean by that. It just sort of helps give you a framework for what you need to think about. And some other considerations is that developers as a whole, and I can say this as a person that is very much like this, tend to respond better to code-based interfaces like SCORE, which is a Humanitech product that's open source. You should check it out if you haven't, but other things like it also are very important here. Don't take developers out of their IDP and version control flow, especially early on. You're trying to inspire them, not scare them. And the other thing is at this stage, you probably don't need a portal. Everyone seems to think they do. You probably don't, I promise. And at this stage, I'm obviously gonna plug this because this is how I think we can do this even faster is combining workload specs like SCORE with a platform orchestrator like Humanitech to move things even faster. It just makes your life easier. And then finally, I feel like this might be obvious, but I wanna say that anyway, it is incredibly unlikely, probably a 1% chance that you would need to go near a production environment with an MVP. So keep that in mind. Right now you can think beyond having to go that way and just stick with your non-production environments. All right, so this is the reference architecture diagram I mentioned. Anything highlighted in red is sort of what you're thinking about right now. So you're gonna look at your version control, how your workload specifications work, if you choose to go that direction and potentially how your IAC works, is it Terraform? You can even start without that, but for a lot of organizations, it just makes sense for them because they're already using it so they might as well continue. You're gonna check out your CI pipeline. So GitHub Actions is the most common one I see in these setups or something similar. A basic artifact registry. We put a platform orchestrator in the middle. Obviously I am biased. I think it's a great thing to do there. And then it goes into your basic CD system. And in terms of the resources you're gonna start thinking about, you're not gonna get too in-depth into services like PubSub and stuff right now, you're just gonna keep it really basic. And I will show you exactly what I mean. So I have a sample application. It is a demo bank. And so often with banks, we have a couple different things we need to think about. We usually have a user interface. We have a way of talking about money or thinking about money inside of our bank and we usually have users, we have account holders. This is very simplified. So I want you to think of your design requirements in three different buckets, applications and services, other infrastructure components and end-to-end flow. So on our app side, we have three microservices. We have a front-end, a money API and a user's API. And these are all connected. You can see we're all using the same container registry, very basic DNS, Nginx ingress and Postgres. Nothing really fancy on the service port side either, just TCP, nothing, you know, not rocket science. On our main infrastructure backbone, we're going to be using GitHub for version control. Our cloud provider is Google. We're using GKE as our Kubernetes distro and we're going to use the Humanitech secret store because it's what's easier for us when we're working with Humanitech. On the end-to-end flow side, this is we're going to think about CI, CD and our starting environments. So we're going to use GitHub Actions to build and push to the Humanitech container registry and then score Humanitech on that push side in order to move configurations over. On the CD side, we're just going to use basic Humanitech deploy at this point. It's very simple and is easy and very quick to get going. So with our starting environments, we're just going to start with dev and we'll start with staging. So now we've got, this is how we do this in four weeks. This is how we've been breaking this up for our users, for our customers in order to make this happen. And I can promise you it can be done in four weeks. So if you actually look at the technical integration, that is only two weeks. It's the two in the middle. You can build this thing in two weeks. You just have to do a little bit of planning on either end. So in the beginning, you're going to look at discovery and design, define your goals, define your outcomes. What does that ideal end-to-end flow look like at this stage? Identify the application you're going to use. Maybe you just push out a hello world inside of a browser somewhere. Maybe you put a little bootstrap front page together. I don't know, whatever you want, something very easy. And do that version 1.0 MVP architecture design like I've just talked about. Week two, you're going to start the platform and environment setup. You're going to put in your infrastructure components. So your clusters, your resources, your networking, get that all done. You're going to make sure that everything connects and that it functions well. In work three, now we start bringing in our workloads. So we implement our applications, our services, and we configure how everything is connected in that way. And then we also finish any end-to-end flow component configurations that we maybe haven't done yet. So perhaps if we didn't look at our CI CD before, this is where we do it. And we also will make sure everything works at this stage. In week four, once you've done the technical work, now you can plan on iteration and you can target your next teams. Your pioneers can start talking to other folks and showing them the magic that they've built. And this is where you're going to want to design a demo flow that focuses on showing the value. And often where we see that most impactful is developer experience and developer metrics. So that is where you will often see with this stuff, things change very quickly. Finally, showcase it to stakeholders. Don't be afraid to run it around and scream it from the rooftops as we like to do here. So finally, we'll just finish up with adoption and expansion. And this is really where people tend to have a lot of questions. How do you actually do this? So I challenge you to think of it this way. By the end of that four-week cycle I showed you, you should aim for an MVP that does two things. It proves it's worth to more than just developers and platform teams. So outside of your technical organization, people should see why this is an important investment from a time and money perspective. And the second thing is you're aiming for something that's ready to grow in a scalable and sustainable way. You're taking it easy to start. You're making sure that you can sustain the development of this thing. And then it's actually something people want to use. I'm sure a lot of us can come up with stories of organizations that have built platforms that no one uses over multiple years, millions of dollars. And that is a real, that's a real time suck and it's a real waste of money to do it that way. If you're doing it this way, it is much more sustainable. And it is way more scalable in terms of finance and time. So one of the next steps after you've built this thing and you've started demoing it out, there's three things that I think are really important. The first is to encourage your pioneers. Get these guys using it as fast as you can and engaging with it regularly. Encourage them to evangelize, promote the concept. They're doing a little Lunch and Learn demo. Maybe they show it in the Lunch and Learn. If you're doing a hackathon, maybe use the platform as part of the hackathon developers. Let your pioneer team shine. Let your influencers, oh wow, words. Your influencers influence. Let them do that job. That's why they are so important. At the same time, you're also gonna gather feedback from all of your stakeholders, technical and not. Maybe you do get some security feedback that says, actually, you know what, this isn't so bad. Can we look at ABC for the next step? And then you think about how you're gonna put that on the roadmap. You're treating it like a product. Take the feedback seriously and just think about this. Build what people actually need and will use. Keep that in mind. And finally, iterate and grow. So like I said, take the feedback. Build your roadmap. Iterate on your roadmap. Don't be afraid to change it. Hublisize it. Treat it like a product. Grow into other teams, other business units. Make improvements that you see as you see them being needed. Never stop showcasing the value of this thing. And that's what we see as really, really amazing at Humanitech is once people have started this process and started moving through, they're just able to show value at every step of the way. Not just financial value, but actual value for time, for people's individual time, for the speed at which they're able to get things done because they're not waiting for stuff. Always be improving, but also always show the importance of what you're actually building. And just some ideas of where your iteration can go. And one of the reasons I put this slide in here is because I think you can look at it and say, oh, okay, this is something I can address later and not get stuck in that complex loophole that people often get stuck inside. So think about more advanced iterative possibilities like automated testing, automated environment promotion that could be based on that testing. We've seen that, that's pretty cool. More complex networking and security protocols. This is definitely something that you're going to probably have to put in at some point. So start thinking about when that makes sense and how you can build it in. Advanced logging and monitoring, also very useful. Complex deployments. So this is where I see people doing things like Blue Green and Canary, other fail-safe type deployments. How does this work? Very, very common to start building in. Portal and service catalog implementation. This is often for a lot of our customers kind of the next step of things. If they do decide to go that way, that tends to be part of the initiative. So that is where we iterate to next often. This is where you'll also start thinking about complex integrated resources and dependencies. So maybe you have interlaced database dependencies or maybe you have a couple of applications that are very dependent on each other and the stage that they're at. This is where you can start thinking about that stuff too. And then finally, probably one of the other big things we get asked about a lot is multi-cloud deployments. It's very easy to do with Human Attack actually. And I've also seen this as sort of a stage two iteration, but it sort of depends on if it's something that works for you guys. So like I said, this is a lot to take in. You're gonna get a copy of this slide deck. And I really encourage you to sign up for the webinar next week that actually gets hands on. Getting your hands dirty with this is probably going to be beneficial. I think a lot of people, once they start actually trying this stuff out and trying to actually build a quick platform in less than a few weeks, you actually realize how not easy is not the word, but you realize how simple it is, how quickly you can get somewhere with it when you don't overcomplicate things. I think as engineers, we're very prone to that. It's easy to over engineer in this space and it's important to keep yourself very on track and to keep yourself honest about what you're building. So that being said, that is the end of the formal presentation.