 Hi everyone, welcome to the first platform engineering day. It's quite an honor to be able to open up. This is very exciting. And my name is Abby Bangzer. And I'm Whitney Lee. And sometimes lipstick is exactly what a pig means. So there are three groups of people involved with using internal platforms. First up, we have our infrastructure and ops experts. So they're going to define and optimize potentially complex stuff that our users want to use. So this could be a Kubernetes expert, a database expert, an identity expert. And that brings us to the next group, which are our users. So these are employees. And they just, for the love of sweet baby cheeses, all they want to do is get their work done. So the users want to get this potentially complex stuff that the experts have made. And how do they do that? With these super awesome humans, the third group, they're so amazing, the platform engineers. And we have probably a few in the room. And these platform engineers often lower many hats. You're multi-talented, I know. You may yourselves be users of some of the capabilities. And in smaller organizations, you often are the experts in the capabilities on the platform. But the thing that really defines a platform engineer is their focus on the interfaces. And today, that's what we're going to talk about is how a platform engineer creates these interfaces for their users. And we're not going to focus on the capabilities behind the scenes. But I guess to do that, we sort of have to define what an interface is, Whitney. So an interface is an experience that a user has to go through to get the thing that they want. So this is a big deal. It can make or break the success of your platform. If your users love using the interface, great. If not, you're dead in the water. Yeah, and it can feel really challenging to do that, can it? It can be. It was really overwhelming, actually, to pair their many, many, many, many possible interfaces and many, many, many possible capabilities. So how do you even begin to think of which interface is good for which capability? I think the only possible answer is one of those kind of game show games, where it's just to spin the wheel and see what comes. How else can you go with these many, many choices? There are so many, might as well just spin a huge wheel and do it randomly. So what do you say we spin a huge wheel and do it randomly? Do that? Yeah. So these are genuinely random. Abby and I do not know what's going to come up right now. On the left, we have a big wheel full of lots of possible interfaces. On the right, a big wheel filled with lots of possible capabilities. So let's see what we get. See if it makes a good combination. All right, so the first interface we have is a mobile app. A mobile app? And this is in order to get the capability of authentication. I mean, this is my day-to-day life, right? You have to sign in and get your 2FA code. And I definitely never get distracted by a text message. It's definitely the best possible interface for me. What I do is I like, OK, I need my code. I pick up my phone. I answer text. I put my phone back down. And I'm like, wait, what was I doing? And by then, it's timed out. This is an interface combination that works, doesn't it? We have this. So therefore, randomly pairing is a good idea. And we should keep doing it. Yes, yeah. I think so. I think so. Let's do another combination. See if we continue this winning streak. So what if we had a ticketing system? We all are used to those in order to get ephemeral test environments. I started my career in QA. And so actually, this was very much my life. I would send in a ticket and say, I would like to test this application at this version. Can you please get that environment ready for me? And with an ephemeral one, too, it makes me think it's kind of short-term and kind of casual. And like, oh, I just have this little change. I need to test real quick. Let me call Cindy and wait. Oh, crap, Cindy's out of office. Oh, no, her son's sick. Like, what are we going to do? And like, when she does get back to you, you kind of hope it's the right thing. You don't really know. You have to check it, probably go back and ask for more things. So this is not a great pairing. But can we put words as to why? It feels like what we're talking about is how much I have to depend on someone else. Ah, so what you're talking about is autonomy. Autonomy. Autonomy. So let's use these wheel spins as a way to think about characteristics to consider when pairing an interface with a capability. Makes sense. And with autonomy, what we're talking about is how many dependencies you have to go through to get access to the capability that you need. With high autonomy, it's self-service. And with low, you have a lot of dependencies. I like being in control. I know what I want. I know when I want it. So therefore, 100% of the time, I always want self-service. I don't even know why this is here. Self-service is totally better than waiting on a dependency period. Well, I even have a spectrum, right? Yeah. OK, so then if you want self-service, what kind of interface would you use? I would use a portal. No, no, no, no, no. OK, so a portal. I love a portal. When I want something, I go to the portal. I have capability discovery. I can see what's available to me. Choose the best thing. There's some education alongside that might help me make my choice. Or even as I'm filling out the field, some validation, I feel in control, and it feels great. I love using a portal. But we do have a spectrum for a reason here, Whitney. So maybe we talk about the other end of the spectrum as well, the low autonomy side. And I hope no one has been given any tomatoes on the way in the door, because what I'm going to be talking about is our beloved ticketing platform. Are you advocating for a ticketing platform right now? Looking at me in my eyes, tell me to use a ticketing platform. I know. It feels so wrong. But let's talk about it, right? Because with a ticketing platform, we're able to ask someone for help, right? And sometimes, I'd much rather just ask someone for something, wait a couple days, than have to try and learn it all by myself. That's a good point. If you're not in a hurry for it, then maybe you don't have to bother learning about it. Yeah. And also, sometimes it can be quite scary doing things, things that cost a lot of money or have really high security risk. Actually, being able to go to an expert and ask them to participate in that process. OK. You're changing my mind. You're changing my mind. If something goes wrong, I want to have someone else to blame. No, no, no. Teamwork. We're talking teamwork here, not blame. But I just have to say, as a former consultant, I know it always depends. And I'm just going to say, it depends. I stand corrected. OK. Yes. So let's spin the wheel again. What do you say? Starting to see this spinning wheel is useful. OK. Yeah. Let's come up with something. All right, let's see what we get this time around. So for our interface, we have a wiki. A wiki? And what are we going to get? We're going to get managing authorization. So I bet this is where you're going to have your, as I said, random. This is where you're going to have your wiki and you're going to have your table. And that table is going to have the item of the website you want to give access to and what user groups have access to it. And that's definitely going to stay up to date. 100%. Yes, to maintain it. No, no, not at all. Pretty low autonomy. So this is not a good pairing. No. But can we think about why it's not a good pairing? Like, what are we, what's feeling wrong about it? Well, it feels like when I want to give authorization to something, I know the tool I want to give authorization to, and it's not the wiki. It's the product. It's the website. It's that tool that I want to be giving that authorization to. So you want to be staying within the context where it makes sense. Oh, contextual distance. So for contextual distance, we want to consider where the user is when that light bulb goes off. That's like, now I need this capability. Where's your user at that moment? That makes sense. And I know that I was able to possibly make you think low autonomy is maybe sometimes useful. But let's be honest, flow state is the only thing that matters when it comes to software delivery. That's what we're trying to optimize for in software. And so why would I ever want to have a high contextual distance? I think this one is low contextual distance always. I hear you. I agree that flow state is sacred. But I'm going to make a case for why you might need a higher contextual distance. Make your best case. But I'm just saying, IDE plug-in. Tell me why you love it. I'm going to make the case that an IDE plug-in, when you're writing software, just can't get to be a better contextual distance interface. You're there. You're writing your code. You get your code linting. You get your feedback. You might get documentation and code generation. When you're writing code, how could you ever want to go outside of your IDE? All right. I'm going to answer your question with a question. What do you do when you get stuck? Run it again. Maybe make a commit that says, like, please this time. I don't know. What do you mean? Maybe go ask a teammate. Would you maybe switch your context to get a new perspective? Maybe, sometimes. So human interaction is a great interface for sure, or a necessary one sometimes. And then also, there could be other times to switch contextual distance. So for example, if you're looking at a ton of logs and you want a graphical way to see that information, that can be a great context switch. If you're deep in your microservice, it might be a good idea to step back and look at an architectural diagram and understand how it's relating to other microservices. All right. A taste of my own medicine. What we're learning is maybe there isn't an always. I get it, even if there's a usually. We'll go with a usually. We want to try something else, see if we can find another pairing. All right, let's spin those wheels. And for this time, we're going to have a code template interface. And it's going to be to we'll go with Create Service Catalogs with this template. I think this actually sort of works, right? You want to have a consistent way of displaying your service in the catalog. And I know my service really well. I should be able to define it in code. I think this might be an OK pairing, I think. OK. So I think it's what part of what makes it a good pairing then is because you know so much about the service catalog you're trying to create. Yeah, I'm an expert. If you didn't know anything about that service catalog, then interfacing it with a code template would make no sense. It would be a bit tougher. I think it would be a bit tougher, wouldn't it? But thankfully, I'm a capability expert when it comes to my own service. So having access to that code template, being able to really make sure I can have a deep alignment with my service within that code feels like a good fit. So when you're thinking about the user, you want to think about the user's capability skill. Yeah, so is it for experts or is it for everybody? Yeah, what's the capability skill that's good for experts? Capability skill is the CLI. This is, yes, some beginners for a capability can use CLIs. There's often sensible defaults when they come to it. But these are really built for the experts. You have access to the flags. You have to think about how these flags interact with each other. And I think there's just no better example of how CLIs are built for experts than just the example up here, which is I'm sure everyone in this room's favorite CLI, the Cube CTL, Cube Cuddle. I don't know, I'm gonna get tomatoes this time too. And you look at this, and the beginner level commands are create, expose, run, and set. That feels awfully beginner, right? I think, I love that explain is intermediate. Yeah, who needs a documentation? It's fine. Don't need that until you're at least intermediate. So they're really powerful, but you do sort of have to know how the things work to be able to use them well. Okay, and then an interface where you don't have to understand how the capability works might be a sidecar, which is an interface that's almost invisible or can be invisible to the user altogether. So you might use a sidecar as a way to scale your application. And the person who's actually making an application never has to know about it. Or maybe a sidecar as a way to, oh, I just got nervous and lost my train of thought. A sidecar as a way to scan. So scan for vulnerabilities. And so maybe the user never needs to know unless there's a vulnerability they need to address. Wait, I can have secure code and not have to think about it? Perfect interface, I take it back. Perfect interface, right? Awesome, let's spin another wheel, the last one. I think we got time for one more, let's see. All right, so for our interface we have my beloved expert CLI. And this is to get access to documentation. And we have some examples of this, don't we? That wouldn't have happened, yeah. Run your help command and you can navigate around how to do that. So you don't have to switch context. That's exactly, so you can see some of these things interact with each other and you can talk about autonomy and contextual distance as well. But the other thing about documentation in the CLI is you gotta be pretty good in the terminal to use it, right? You've sort of gotta be able to use less and you have to know how to exit. Is that Q or is it W, what are we doing, right? You gotta have a little bit of experience. Yeah, like my dad could read documentation, my dad couldn't navigate a CLI, right? Yeah, so kind of what you're saying is is that there's another thing to think about which is the interface skill. So this isn't about how much you know about the capability behind the scenes. This is about how much you have to know to just use the interface. Is it made for those specialists or can anyone sort of do it and be used to it? I've learned not to say always and never but my gut really tells me that I wanna make interfaces that have low interface skills so that my capability is widely available across my organization. Seems like a kind thing to do. What would be a good example of that? A documentation. Yeah. Documentation. So documentation is, there's a way that it's almost always laid out. Like on the left-hand side, we have a menu at the top is the beginner's stuff. At the bottom is the more expert stuff. That these days there's probably like a chat bot and the bottom right too and contact information in the top right. So it's familiar. I know where to go no matter what documentation I'm visiting, I have a good idea of how to interact with that interface to get the knowledge that I'm after. Particularly the web documentation, right? Exactly, but on the other end of that spectrum, there are interfaces that are more specialized, right? A good example would be those code templates that got mentioned before. With code templates, yes. Using them can be really simple. You just have a simple Helm's value file. I'm not sure I've ever put those two words together before, but it should be simple, right? And a Terraform module should be simple to use. But when you're really using a code template, you're taking ownership of that code. So you have to not only know how to read code, you have to read someone else's code and everyone knows that's more difficult. And you have to read whatever language they're writing in. So it actually takes a fair amount of skill in the interface to know how to extend that code and make changes to it, and even just read what is possible with that code. So it's pretty expertise. So the reason you might want that, I kind of get it. Like if you're an artist and you paint with oil paints and you can make these gorgeous paintings with perfect carols shading, just like Mona Lisa. And then someone's like, hey, hey, let me help you out. So that's a hard interface. I'm gonna give you a box of crayons. You're welcome. Now you have an easy interface. Just to be clear, I'll take the crayons, but we'll leave Whitney with the oils. She's the mastermind behind our slides. So yeah, it's sort of, it's hard when someone wants to make it easier for you, but you have an expertise you want to use through a specialized interface. So again, a spectrum, no right and no wrong. So we've been through a lot. We started this, or I started this, completely overwhelmed about how to pair up different interfaces with different capabilities. And now I'm feeling much happier because I think we've come up with some really good characteristics to evaluate when making this decision. So let's do a bit of a recap, why don't we? Yeah. The first thing we talked about was autonomy. This is the measure of how many dependencies that you need to go through to get access to your capability. Is it self-service, or do you have to depend on external dependency? And then we talked about contextual distance, which is where you are when that light bulb goes off, that you need the capability, or more importantly, where your user is when their light bulb goes off. Do you want to give it to them the capability where they are so they keep their flow, or do you want to ask them to switch context so they get a bigger picture view? The third one we did was capability skills. So this is whether or not your users need to be experts in that capability they're getting access to, or is this something that anyone can do and anyone should be able to benefit from? And then we have interface skills. So how much expertise does a user need to have in the interface itself? And how easy do you want to make it to use? So it's harder to use, but more powerful, easier to use, but then we're making choices for you. And we didn't just talk about these sliders, we used some examples. And we talked about a number of different interface options. And we have all of these options that we talk about and that fall in different places on those different sliders. And one important thing is it's not a one-to-one pairing. You can have many different interfaces for one capability. Yeah, I mean, I guess I think about cloud providers and I often will go to their web interface and use their console. And then as I want to try and automate things and become an expert, I tend to use their CLI and then Whitney. Abby, we forgot an interface. That's the most important. It's like the most important interface. That's sort of embarrassing. On Cloud from Engineering Day, in front of these amazing... We didn't forget. We remembered it. Oh, good. APIs. APIs are very important interface. They're building blocks that can underpin all of these other interfaces. Exactly. With an API that can hold your logic for both a portal and even a ticketing platform and a CLI and everything else. So they kind of underpin things, but you don't always want to use an API directly, do you? Yeah, APIs can be a little... They're not the prettiest interface, you know? No. They're kind of like a pig. Yeah, maybe. Maybe? So you want to give lipstick to your pig? Yeah. On your API pig. So we have this API pig. This is an important part of the puzzle of interfaces for platform engineering, but it's not always the prettiest thing on the block and it needs a little dressing up. So it might not be a matter of whether you put lipstick on your pig, but more a matter of what color lipstick you choose for your pig to wear. And the best thing about lipstick is you can change it every day. You can change it multiple times a day. Is it an evening wear pig? That's the end of our talk. I'm Whitney. This is Abby. We're two humans who take ourselves very seriously. We have API pig stickers. So if you see us around, please ask us for a sticker and say hello. And please give us some feedback. Thank you so much. Yes, it's time for questions. Thank you for that, Whitney and Abby, that was awesome. We do have a little bit of time for questions. Does anybody have a question? We got all our random out during the talk, huh? No. Okie dokie. Then thank you both. That was excellent. Yeah, thank you.