PurePerformance - Practical Platform Engineering vs the Marketing Hype with Maurico (Salaboy) Salatino

Episode Date: August 14, 2023

Codifying Golden Paths that ideally don't need you to build a K8s Operator! This is what Practical Platform Engineering should look like!In our latest episode we learn from Maurico (Salaboy) Salatino who has been contributing to open source for the past 12 years. Tune in and learn from his journey of designing and built platforms. He shares his opinion on the Platform Engineering skillsets, how to design for self-service, how to pick the right tools out of the 160+ CNCF project options and shares some of his favorite tools (including Crossplane, VCluster, Argo, OpenFeature, Keptn ...) that should be part of a modern cloud native platform.Links discussed in this podcast:Salaboy on Twitter: https://twitter.com/salaboySalaboy on LinkedIn: https://www.linkedin.com/in/salaboy/Upcoming Book: https://www.salaboy.com/book/Cloud-Native Snapshots: https://www.salaboy.com/cloud-native-snapshots/Diagrid: https://www.diagrid.io/

It's time for Pure Performance! Get your stopwatches ready, it's time for Pure Performance with Andy Grabner and Brian Wilson. Hello everybody and welcome to another episode of Pure Performance. My name is Brian Wilson and as always I have my co-host Andy Grabner with me today. Andy, how are you doing? I'm very good and I'm surprised that you don't just make a comment about me making funny faces when you're doing your intro. Well, I assume our audience is smart enough to know that you're doing that. You know, maybe that would be a good reason for a video episode so people can see the harassment I get from you every time.

It makes me feel like a... Maybe this is why you always have these nightmares that you tell me about. Yeah, I haven't been dreaming lately. I got to work on that. You know, if I start writing down my dreams, I might be able to start getting back up with lucid dreaming. Oh, wow. If I start doing lucid dreaming

and you're in the dream, I can take over and take control. And I won't let you bully me in my dreams then. Look at that. That would be amazing. But we're not here to talk about dreams, you know. You know, no, that's That would be amazing. But we're not here to talk about dreams, you know. Are we? You know, now that's not a platformer.

I was going to make a reference to an old dream I had when I was playing Super Mario Brothers on a big screen TV and then I went to sleep dreaming of Super Mario Brothers and I was going to try to do a fancy segue about, you know, it being a platform game, but it's not a platform game, is it? It's a side-scroller. But I was on a platform this Monday, actually.

I was on a platform today. This Monday, actually, I was on a platform speaking about platform engineering. Believe it or not, I was at KCD Munich, Kubernetes Community Days. And now, finally, we release our guest because it's about time that he can speak for himself and not just listening to us.

I'm really happy that Salaboy Mauricio Salatino, I hope I pronounced all this correctly. I've been practicing my Spanish for four years with Duolingo and hopefully some of my pronunciations I get correct. I'm so happy that you're here. We met a couple of months ago, I think in London at a conference. And we then met again in Barcelona at DevPCN, where we both spoke about aspects of platform engineering. But without further ado, Mauricio, would you do me the favor and introduce yourself, who you are, your background, so that people know a little bit about you and also get a sense on why we're

inviting you today to this podcast. Perfect. Yes. Thank you very much for having me, folks. This is an absolute pleasure. I met Andy, as he mentioned, a couple of times already, but I've been following him for a while now. Yeah, my name is Mauricio Salatino. You pronounced it correctly. I have a lot of issues also pronouncing my own name in English. It's a pretty complicated name from English speaking people. But yeah, that's why I have my nickname Salah boy that I've been using since I used to play Counter Strike in my high school times. But yeah, so I've been working on this software, you know, in engineering industry for quite a while now, more than 15 years, and I've been doing open source for the last 12, full time.

And my passion is usually about helping developers to be more productive, and for that I just created tools, frameworks, libraries, projects, and contributed to a bunch of things that basically push the industry in that direction. And I guess that that's the main reason why I'm currently invited here, but also why I got into platform

engineering, and platform engineering specifically on Kubernetes, on the cloud native space. And yeah, it's an absolute pleasure to be here. I've been doing a bunch of stuff in tons of different projects, so we can actually talk about all that stuff, or kind of all the side

projects and all the other stuff that's going on right now. So first of all, I need to make more reference to your name because every time when I try to find you, I always make the mistake to write Salsa Boy because I'm a passionate salsa dancer and I always BS. I think we found a nickname for you, Andy. There you go. I've heard that. It's not the first time that I've heard that.

There is also Salad Boy as well. There's a bunch of variations that tend to get into people. When you're typing it, it's going to automatically complete something. So what I would really love to talk about is, let's pick the topic platform engineering, because this is how I think met you when you were at WTFS SRE in London. And then I really, I think platform engineering, and this is the way I opened my talk in Munich this week. I had the pleasure to have the opening keynote and I was talking about the dilemma that we are currently facing in platform engineering or in the CNCF space.

Because if you're new to the cloud native community, you're overwhelmed with I think more than 160 projects right now. There's so much stuff going on. It's so complex, but it's also a big opportunity. And my opening slide was, why do we need another talk about platform engineering? Because if I Google, I find your stuff, I find stuff from Nana, I find stuff from Viktor Farcic, from everybody, right? There's like a thousand things out there.

Why do we still need content on platform engineering? Why do we need somebody that writes a book, right? I mean, there's people that write books about platform engineering. Because I think we are not there yet. We have a lot of new people that constantly come into this space. Platform engineering itself is, I think, at least not mature enough yet to say we're done and this is the Bible. It's an ever-emerging state. build or to enable organizations to become 10x organizations versus being an organization that needs to hire 10x engineers which we know is not possible and doesn't make sense and doesn't scale

and people are looking a lot for references people are looking a lot for educational material on where to get started and so i think this is why i really enjoyed your kind of talks that I saw. I remember the demos that you always give with how you are easily standing up an environment for developers, just like a simple CAD, and then whoops, everything is up. And that's a great kind of golden path, making it very easy for developers to get the chance to get what they need without needing to worry about the complexity behind the scenes. So this is why I think we need to talk about platform engineering

and have people like you on a podcast to really talk about your perspective because you've been doing this for a while. You've created frameworks. You wrote a book about it. And so therefore, I would like to ask you, what is it that people that are new to this, what do they need to know? What mistakes shouldn't they do?

What is your reference? What is your approach to platform engineering? Yeah, that's a very good question. I have a very opinionated answer for that question. So there's always the industry answer, maybe like also the marketing answer, also like the CNCF answer to platform engineering about like

best practices how do we do things how do we use different projects together why we should kind of push all these projects to actually work together like and integrate and fulfill different use cases but my my vision around these topics is usually more practical vision right we need to demonstrate people how to do certain things so they can actually see things in action instead of just talking about like, you know, two very high level concepts, because that's where we start getting lost, right? That's when we start getting a little bit more marketing related or more like trend related or hype related.

And what we want to make sure that we don't do that, like we should be a little more practical, show people examples so they can make their own minds and actually have something that they can use to experiment. So my approach to platform engineering, I'm trying to go not so heavy on definitions on the book, but much more on, you know, I will show you stuff, then you can make your own decisions about how to use things.

These are the tools that are available today. These are where the tools are going. And these are the decisions that you need to make around these tools to be successful, right? And then you evaluate, you make a decision, and then you just implement different things. Yeah. One of the things that I mentioned in my talk,

I said it's a big hype, right? Obviously, everybody's talking about, but this does not mean that every organization needs to build their own platform don't start with building a platform i think the first thing what you need to figure out is if you are it's like building a product right obviously the platform is a product your users are your customer your internal development teams the question is do you even need to build a product because maybe what your organization needs is already available off the shelf.

Because if the only thing they need is a content management system to build a website, that's it. So I think what I try to also tell them is, you know, put your product manager head on. Understand the challenges that your engineers have right now. And then figure out, is it good to maybe buy something or build something? And if you build something, then you also need to look into what are the skills of your engineers have right now and then figure out is it good to maybe buy something or build something and if you build something then you also need to look into what are the skills of your engineers because every organization is different man we all have different skill levels and then you need to provide a product that helps your users with their current set of skills and mindset to actually get your stuff done yeah i think that i take kind of like maybe

like step up on the abstraction level on that on that sentence on that like point of view that you have and i would say that every company will need to basically glue things together for their needs right like and every company will have different needs different decisions that they are carrying on right like there are some things that the company already have that they will need to use. And internally, there will be teams gluing all these things together so they can actually produce whatever they are trying to produce. And from that point of view,

when I talk about platform engineering on Kubernetes, I always think about like, you know, if you are adopting Kubernetes as your target platform, like as the target place for running your workloads, you're actually doing some kind of platform engineering practice, right? You're already selecting Kubernetes, you're already defining some workflows to deploy applications and to build applications and to make those applications work together. So it's at least from the platform engineering on Kubernetes folks perspective, it's all about that. It's all about you are already choosing Kubernetes as your runtime, so you will need to make a bunch of decisions. And I think that the

whole hype and movement around platform engineering is basically based on the fact that we have figured out that all these decisions are now becoming code, like any other software development thing that we are doing. We will need to deliver extra code for our internal teams to do stuff. And we are just putting a group of people around that and making that group of people responsible for that code and for the maintenance of what we are calling a platform. That's why I think that it makes a lot of sense to talk about platform APIs. Right. It makes a lot of sense to talk about self service in the sense that we are providing an API.

So what you are going to call the API, you will get something out of it. And then it's all about golden paths, like codifying about how the organization will take all the things that are being produced in front of the customers. But again, that's where my definitions are pretty high level. And then I will go heavy on examples. I saw your presentation about observability and measuring platforms and figure it out how efficient are we by delivering these components or this blue code. And I am really passionate about that like we need to actually see what we are doing we uh we just we don't just need to build a platform as you mentioned before right like we just need to make sure that we are enabling teams

and measuring how good are we at doing that yeah and i think you know coming back to possibility and what i showed in in barcelona when you saw me and also what I did again in Munich this week. If you're building a product that is used by users, we need to make sure that the product is used. I think from a monitoring, from an Obserability perspective, you really need to figure out, hey, I have three golden paths out there. One for building a backend service, one for a website and something else like a serverless function you need to figure out how many users how many of your internal teams are actually using these templates these golden paths and in the end do they come back and create more

or do they completely ignore it because it doesn't work as expected it's like a product engineering thing right do my users use these features but in order order to know this, I need to also measure it. And also, is my platform, is it available all the time? Is it resilient? What if on Monday morning, everybody comes in and they all start to create new environments and all of a sudden everything falls apart? Then I would say nobody will probably keep using it and then just go to some other offering that is out there. So I think from an observability perspective, this is hugely important.

In your presentation, I remember that you had your custom CODs, right? You had your custom resource definitions for, I think, environments. Is this, and I think you also share all these examples, right? You share it. Is the environment an abstraction layer or a CRD that you recommend or that you see also out in the wild that's being adopted? Like kind of the give me an environment that has a certain spec and then just create it for me. Is this something that people should look into? I think that's a very good question.

For me, that's a very clear example that people understand. When I show them that example, the feedback that I usually get is that, okay, yes, I kind of need that, right? Like my teams nowadays, they want to have environments to do testing or to just basically change the application. And they don't have the fact that I can show that and that happens just in less than a minute. So I can do it live live presentation.

It's something that, you know, it actually gets people thinking about, okay, what other things can I do like that? Right, like environment is just an example, but you know, can I create like a new project and actually template the entire thing in less than a minute, right? And just enable my developers to have access to all these tools, like out of the box, without them needing to worry to

install tools on top of Kubernetes clusters and all those things that it will take them a lot of time and a lot of learning curve to actually go there, be efficient on these tools and installing and managing all these things. So to answer your question, what I've seen in the industry, it's mostly people want to create these automations for whatever they are doing. Most of the times those automations will include a set of like third party APIs. You know, like I want to integrate Salesforce with this other thing, you know, and create a user in this database and then just start this service. So the developer can actually go and change it in a place where it's actually behaving like the real thing.

Coming back to this example, because I was also just as fascinated by it when I saw it in your demos. I think what I would like to understand is what would somebody need? What are the skills of a platform engineer that would build something like this? I guess you need to know how to write operators because... That's a very good question. Yes. So my recommendation are around operators, because what Andy is asking is that the example that I've showed includes an extension to Kubernetes and include this resource that basically represented an interface an extension to Kubernetes, right? And included this resource that basically represented an interface for teams to say, you know, I want to request an environment. I only need to provide the parameters that I want to tune for the environment, right?

If I want to deploy my application, if I want to create a database, if I want to pay users, if I want to have mock data or whatever in the environment, right? But at the same time, my message, and I guess it is included in the book in some way, it's like you shouldn't be building operators. And why? And the main reason why is that if you, I mean, you can extend Kubernetes in any ways you want, but the moment that you decide to extend Kubernetes, then you own that extension and then you need to maintain.

And a Kubernetes extension, it's a pretty complicated piece of component because you need to actually be an expert on how Kubernetes works. Then you need to be an expert on the problem that you're trying to solve with that operator. And then if you are the only person in your company that has that expertise and you leave the company, then the company ends up with the component. It's pretty hard to maintain the example that i've showed there in in my presentation and it's included in the book uh basically it's using crossplane so there is no custom operator being created and all the administration of these extends kubernetes extensions is being handled

by a project that's already done that. And that's being used in conjunction with another open-source project that is called vCluster that allows me to create clusters on demand. And again, I'm going to be using extensions that already exist. So when I'm providing this functionality, like environments, like developing environments on demand, I'm actually not creating any extension internally for me to actually implement that functionality, which I think is a great way. It's highlighting the power of these open-source projects that are already solving common challenges for people, and then also showing and highlighting the limitations that these projects have.

So I'm showing what you can do without going and creating your own components, and at the same time, I'm showing the limitations and where these projects have. So I'm showing what you can do without going and creating your own components. And at the same time, I'm showing the limitations and where these projects are. So you can actually have a clear mental map of, okay, this project is giving me these three things. This other project is giving me these other three things and I can put them together and they actually work. So for me, this is cool.

So what you just said is basically, don't build an operator if you don't really have to. This is kind of the thing that I said earlier. Decide whether you build versus buy. In this case, you don't buy, but you kind of borrow. Right. So borrow what's already there because tools like Crossplane, Vcluster, also Captain, right? We are basically operators that already provide capabilities that through configuration, you can actually provide a platform

that already does automatic provisioning of resources, automatic provisioning of clusters, of vClusters. And then in terms of Keptn, automated validation of the deployments and observability of the deployments. Exactly. The problem with that is that by the end of that sentence you need to know about Crossplane, Bcluster and Captain, right? That's why the platform engineering team will need to basically spend time researching these projects and deeply understanding where these projects are going. So they can say I want these two features of Crossplane. I want big clusters because I want to do this. And then I want to pick up

these three features that will actually make my life easy. I think a lot of this ties into what you were hinting at. I don't know if you were specifically trying to hint at this, Andy, earlier, but when you talked about the hype and people jumping in, there's obviously based on what the conversation you two just in, right? There's obvious, obviously, based on what the conversation you two just had, a level of maturity that is needed. Not just, obviously, with the personnel who are going to be doing this.

There's certain knowledge they're going to need to have and think about, but a maturity within the organization. If you're starting to build a platform, and let's say you're a startup and you don't even know what your developers need and all, and someone says, hey, we should do platform engineering, and you're building a platform before you even know what the team needs and what pains they have, and you're picking and choosing things based on this looks where people say, we're going to pick this because it's the buzzword. And then they're making architectural decisions based on hype versus needs. And your conversation just there really illustrated the fact that the platform design and solidifying of it comes after you've built things up, you find out what's working, and then you can build the platform around what's there. And yeah, it's not just something to jump into.

Yeah, I guess that also like something that I've shown in my example is that clear kind of delineation between APIs and implementation, right? I created that CRD that basically defines what an environment is, and the platform team will decide to use cross-paying and big cluster or even create their own operator to deal with that interface. But that sets the line of saying, teams, as soon as they know how to define these resources and send these to an API server, the platform will take care of provisioning whatever needs to be provisioned.

And in the presentation, I'm heavily using the Kubernetes APIs to extend Kubernetes and send resources, but I've seen a lot of companies that basically write a layer on top, that it's just a normal REST API, nothing related to Kubernetes that allows teams just to consume an API without worrying about Kubernetes authorization and RBAC and all that stuff. It's just another facade on top of it that lets teams to just use the dashboard or something simpler to send these requests. And I think that that's a completely valid solution. I usually focus on the Kubernetes APIs because I think that, as you mentioned,

Kepton, Crossplane, Bcluster, Argos, Cd, a bunch of other projects are using the Kubernetes APIs as the base layer of integration. That's where we integrate projects to work. And I think that it's a great place for doing that. But for some people, that space is too deep or too technical or too Kubernetes specific that they push it away a little bit and write an abstraction layer on top and there you go. One thing you mentioned earlier is that eventually the platform engineering team needs to make very tough decisions because you need to pick tools that actually will solve your problem. Now the thing is there's many tools out there that are that have overlapping capabilities so the the question is like argo versus flux uh do i use opa versus caverno do

i use x y versus c right there's like so many things and uh because just coming back from from kcd munich i can a really encourage everyone that that is in the position where you need to make decisions now or soon to really engage in the community to figure out what's out there. Look at things like how mature our projects, how active are they. There was actually some really good talks also at KCD Munich where they were highlighting tools, but then they say, you know what, this tool didn't have any big activity in the community on the on github for the last year so we don't really know where this is going right so don't just because you see a flashy video and don't just make the decision

then but do your homework and say you know how active is this project also there was one conversation that was that was really interesting it was from victor fargich uh who did a presentation on policy on on the uh on the admission web hook uh and then he looked he showed that uh there's some new core kubernetes capabilities coming in for policy enforcement and then he also made a statement that um you know certain policy agents that are already out there will be easier to convert over to that new standard because they're also contributing versus others it will be tougher if you are on that tool in the future so my point is it's it's really tough right because there's so many tools out there so many different options but some basic homework things like how active

is this community how many git commits come in do they have an active slack channel homework things like how active is this community? How many Git commits come in? Do they have an active Slack channel? And things like this, right, I think is very important just to make at least not a basic mistake to pick a tool that will go away in the next couple of months anyway. 100%. I think that gives me a very good idea for a blog post because it's actually something that you can clearly specify like a platform engineering team that

is basically making these decisions based on CNCF projects. We can actually have some kind of like checklist of saying, you know, if you're choosing any project, first of all, make sure that you can engage with that community. I guess that for me and writing the book and engaging with different communities have given me that visibility on where the projects are going. So it's usually not only important to understand where the projects are today, but also where they are heading, because that's pretty much something that will impact your platform journeys. If you're adopting a tool and you know actually where they're going and where they're focusing specifically, then you know that you can engage in those initiatives and just shape them in the way that will work for you.

Or at least you will expect some output from that community that you can see that it's actually working on something. For me, that usually have given me the edge on knowing where things are going, right? Like I engage deeply with some projects that I believe that are fundamental for these conversations. And then as you just talked about the journey on Kubernetes, because I'm just reading the, I'm just looking at your salaboy.com book. So the book that you wrote on platform engineering on Kubernetes, it actually starts with the platform engineering on Kubernetes book

reflects my journey of navigating the CNCF landscape and the cloud native communities around it. Yeah, it's actually... So everybody, we will... The links to everything we talk about today, all the content that Mauricio has put out, you'll find that in the description of this podcast as well.

I can share a discount code as well. Yeah, that would be awesome. Yeah, for sure. You just failed sales 101, right? Sales 101 is you try for full price and then you give them the discount code. So yeah, this is the thing

about books, right? I'm writing a book not because I decided to say, hey, I will write a book and then I started thinking about actually I decided to write a book after going through all this journey and saying, hey, I have too much material for blog posts so I can actually create a book that will save people time. And I don't know how the publishers will feel about this,

but you don't write a book for money. You actually write it because you're just crazy. And I don't think there book for money you actually write it because right you're just crazy and i don't think there's any sane authors out there right yeah exactly yeah not me but but this story kind of reminds me uh brian of our conversation we have with nana from tech world with nana because she started her youtube channel because she had she took so many notes when she started to roll out Kubernetes in the early days at A1, the Austrian Telecom. And then she had so much stuff that she kind of researched because there was no good documentation and information out there.

And then she decided, hey, you know what, I will share with the community. And then her YouTube channel took off. Perfect. That's how it goes, right? like usually if you ask me you know like write 30 pages about something that i don't know it will be pretty hard but most of the chapters were based on my collaborations with different projects right so you know and that basically reflect my journey and then i realized that it's not only my journey it's basically actual like like every company's journey on top of Kubernetes, it's about

making these decisions. And usually in the order that are described in the book, like, how do I build containers? How do I deploy things into the cluster? How do I apply policy? Or how do I provision infrastructure? So that's pretty much what the book is about.

And without revealing who killed, who is the murderer, not revealing the secret of the book is alone yeah and and without revealing who killed who is the murder uh not not revealing the secret of the book but what other things are in the book and what what should people why should people really look into this any other things that you learned that are really essential especially for somebody that is just starting with this yeah so i think that the the main objective of the book is again it's like to save people's time, right? So the main idea here is that if you read the book, first of all, you should be able to go out like after reading the chapters and following the tutorials with hands on, you know, practical

experience on the projects that I mentioned, but also understanding how these projects fit into like the bigger picture. So it's not about cross-playing is great, you should use it, this is how you use it. Tools like cross-playing will help you to solve these problems. This is where cross-playing is, this is how you use it, this is how you use it in the context of the examples that I'm providing in every chapter, and this is how it fits in the picture. You can use cross-playing, you can use something different, but when you're looking at this problem, these are the topics that you should evaluate.

And this is how you come up with a decision for tomorrow. Tomorrow I will start using crossplane. These are the challenges that you're going to face. And if you want to pivot, make sure that you have these APIs, abstractions, and interfaces so you don't get stuck with a single solution. Hopefully that makes sense. Yeah, it makes a lot of sense.

And I'm just looking at again, you have a very you give a great table of contents on all the different chapters. Now, I would like to quickly talk about chapter number nine, even though we hit on it in the beginning. Number nine is number nine. I was doing a Beatles thing from forget it

do it again come on number 9 when you play it backwards it's turn me on dead man which was part of the whole Paul is dead thing probably way over your heads and anyhow chapter number 9 we're going to number nine.

Let's get there. Let's stop my stupid distractions. Chapter number nine is called Measuring Platforms. And in parentheses, draft needs extra work. But no, seriously, it's about the measurement of platforms and how to really make sure that they are successful because that's a big topic i have my opinion i think we have a common opinion a shared opinion but i want to hear it

from you so when people build platforms what are the things you need to measure in order to make sure that your platform is actually successful yeah so again because people talk about like choosing tools uh what i wanted to kind of discuss in the last chapter is how do we measure that these tools are effective on doing what they are supposed to do? So if you're trying to improve how fast developers are releasing software in front of customers, then actually measuring how many deployments do you have and following the DORA metrics, something that you also mentioned in your presentation. It's pretty important. I'm focusing on DORA mostly because it's something that it's also been worked on quite a lot. I haven't seen any tools fully automating all that stuff using standards, like actual standards that

then you can say, okay, if i choose this tool i don't get super stuck with this tool and i cannot change it so that was kind of like my my main focus i tried to build uh something using cloud events uh there so basically just checking my pipelines my delivery pipelines plus all the github stuff calculating dorametrics and showing how people can just actually build that and map those metrics to the software that they are running. I wanted to give readers a small framework so they can tap into the existing systems, emit the events that the tool needs to calculate the metrics, and then just show that people

can actually build that. Yeah, as you may know, after we met, I saw your presentation with Keptn and also calculating some Dora metrics, which I actually think that maps really well to that chapter. So I'm hoping to be able to include some of that while it's still in draft. Yeah, and one thing I wanted to highlight, because I think this is the...

The more I talk about the story and why we built Capitman and what it does, I come to the realization that as we're moving architecturally to obviously smaller and smaller components that make up an app, we must not make the mistake to measure the success of the platform by looking just at how many pods are deployed because we still deploy applications in the end and I think because there's no application concept there's no CAD that defines an application this is also what we are trying to solve with captain because port deployment doesn't mean your application is deployed right the application may consist of two pods five five, ten, seven ingresses, everything that belongs together. And so one of the things we are trying to

do with Captain is to actually measure the time it takes to deploy the whole app by looking at metadata and based on that metadata, we know which pieces actually belong together. And so because in the end, you get what you measure, I think is a very famous quote. And if you just say, I built a platform and I can now show you that week over week we're deploying more pods, this doesn't mean that we're actually deploying a new version of an application that can be used by the end user. And I think that's a big metric that we want to also bring the awareness to the community. Measure, A, how often you really deploy a new version of an app, and a new version could mean multiple deployments that belong together to one

logical deployment. And the second thing that we also wanted to stress is just because your pods are running doesn't mean your application is actually usable, and it does what it does. Definitely. I think that's one thing, right? Measuring how many changes are you applying in front of your customers might be a very good metric. But from a platform perspective, I'm really interested in measuring platform

capabilities. How many capabilities that the platform team is providing to teams are being actually consumed and being used to something that you mentioned at the beginning, right? If offering you know like release strategies how many a b tests maybe testing baby test deployments are you doing and is that actually working if i give you feature flags how many features are you enabling and disabling every week right yeah those kind of metrics actually show velocity and show how much the platform is being used and show us how much time are we saying to our teams yeah and thanks for bringing this up especially the uh

that's a good one the feature flagging like if you're providing feature flagging as a service or as a capability of your platform are they really adopted and if they're not they adopted and the question is either you don't educate your users about it you don't tell them how to use it right that's one could be one thing or it just doesn't work. But that's the thing with the whole Kubernetes space, right? Like if you give Kubernetes to people, you don't have feature flags in there. So basically, you're pushing your teams to find a solution for that. And usually, large organizations, they will always have a team that will say, we will implement our own feature flagging mechanism. We will do it ourselves, We'll just implement it in there. And that will take a lot of time first. And if you

don't measure how much time it takes implementing that thing for teams to use, then you're not measuring how efficient your platform team is. If you're adopting something like open feature and you have something that it's been provided already for you, how often is that being used will give you an indication of how much of the investment is paying back when you adopt it. I think that we need to start measuring this. Yeah. And there's one more thing I want to talk about is because this is also what I tried to present in Munich.

The platform itself is made up, as you said, of different components, different building blocks. You talked about Argo earlier, you talked about Crossplane. In a typical platform, you probably have some type of container registry. You have, I don't know, there's some Git, something is in there, right? That belongs to the platform platform and my point that i also try to stress if you're building a platform and you treat it as a product then you also need to make sure that this product and all of its capabilities is is available is efficient is resilient so you need to monitor argo caverno harbor whatever you use the same way as you would monitor your business critic labs so for instance what we do internally right we have synthetic monitors set up that backstage is always up and running

because if backstage doesn't work for whatever reason then developers cannot go to their catalog they cannot create a new project based on the templates the same is true with argo if argo isn't running and it cannot sync fast enough all the changes, then, well, things will pile up and eventually fail and then developers are not as efficient anymore, right? Exactly. Yeah, and the same with APIs, right? Like your platform APIs need to be refined as any other software

that you're building, right? Like you need to spend time designing those APIs and making sure that you are maintaining those APIs in a good shape. Like they can evolve, they can just be versioned, you can just create new implementations and endpoints, new functionality for teams to use. While this is the tricky thing, right? You provide these APIs, but you need to make sure when you're talking about Cloud Native and the CNCF space is that if people want to still access Cross-link, they should be able to. And that's why there are lots of conversations nowadays of platform teams creating very strong APIs that people cannot bypass. It will actually slow down some things that actually have that

knowledge already. Yeah. One more thing that I would like to ask on the examples that you always present at the conferences. Are these examples going to be just part of the book if somebody is then purchasing the book? Or are these examples out there already somewhere? Yeah, so those examples are in a repository that is called Salaway. That's my username in GitHub. And then it's slash platforms on gates. Perfect. naming github and then slash platform platforms on gates perfect so i want to make sure we also another link that we get another link yeah yeah that would be awesome now because it's really

great great stuff that you have right and as you said you want to show people something and you are and and your uh platform your reference architecture there or example is just makes makes things tangible, right? You can actually then kind of grasp it. That's the important piece. Yeah, and the book takes it kind of like the next step, right? Like I want people to run this in their local environments. Like I want them to actually create a Kubernetes cluster locally

and run these examples. So I'm actually spending a lot of time. That's why I'm moving most of the examples to this new repository now, where first of all, you can run them kind of like one by one chapter by chapter you can just build up on the example and then uh also like you can separate them as well right like if you're only interested in provisioning infrastructure with crossplane then you have like a separate tutorial like step-by-step tutorial where you go from not having anything to create a cluster, to install the tool, to use the tool, to customize the tool, and then to see the example in the context of the examples

in the book, which I think that are also valuable in the sense that they are just not hello words. You have an application with multiple services, it's working, so you need to expose it, you need to access the application, you need to make sure that it's working and fully functioning. Yeah. One thing that I would like to show you after we're done with the recording is we at KCT Munich, Alois Redbauer, who I think you also know, he kind of, you know, lead it or he was actually the one behind, you know, starting Captain and then also Open Feature. He did a workshop this week in Munich on progressive delivery best practices.

And he actually also created a new workshop where you can stand up your own cloud native platform by just using Argo, where Argo was first used to stand up the platform, installing all the different tools, and then also providing a reference on how to deploy apps that are enabled with open feature. So I think I would also be interested to forward this to you and to see what type of feedback you have on that and how we can also join forces so that not everybody has to create their own kind of template architecture for everything. Yeah, exactly. And I think that again, like having examples that you can install and change, right? Like I'm really pushing people to say, you know, you just run the example, but these are all the other things that you can do. Just make sure that you go and change it and experiment with it, because that's the only

way that you will get up to speed to make the right decision. Mauricio, as we're getting to the top of the hour here almost, I know you have a new thing going on, or at least you mentioned this when we were exchanging some messages. It's called Cloud Native Snapshots. What is this all about? Yeah, so I'm... Because again, I have too many requests of writing this. It's like I decided to, because I've been focusing for the last five years

on contributing to different open source projects. But what I'm seeing now is that because the cloud space is reaching to a very good state in maturity where projects now, we know that projects work. And we know that projects are being adopted for production workloads and all that stuff. But the next step is, as you mentioned before, like platform engineering teams,

they need to know a little bit more about how sustainable the project is. Like, you know, how, if the project is going to last for some time or not. Right. So I've been kind of trying to write these reports where I'm summarizing what I'm seeing around like open source projects and the companies behind them. Right. I want to make sure that, you know, if a project is being well funded by a company that is pushing, that's a good thing, but if you see that the project

is well funded and there are like multiple companies pushing for that project to be successful, most of the time that goes really well, because first of all, it's not a single company pushing for one thing that they think it's right, it's just the entire industry backing that up. And then also gives me the reassurance that I'm not alone in just adopting this. There are other projects and other companies actually putting not only money, but also like very smart people to solve these problems. For me, that's key. And I haven't seen anything, mostly because CNCF, politics, and open source projects, usually money doesn't tend to be mentioned in these spaces

when you evaluate the open source project itself. But for decision makers, you actually need this information. I realized that from a foundation point of view, talking about these topics sometimes is not that easy. So I said, okay, let's write some of these reports showing both things right like i'm also kind of like the things that i'm seeing when i'm going to conferences and when i'm talking to people right this company is well funded the project is good there's a big community around it that's a good sign then it might be kind of like a good snapshot for you to say okay i can make a decision on this

tomorrow if not you need to go out i can make a decision on this tomorrow if not you need to go out and actually meet a lot of people to get to gather that information and then come up with the decision once again i'm just trying to save people some some time and money but you know like reports takes time so i'm just trying to do this kind like in an open way and trying to get some supporters trying to get some sponsors around it. But I'm committed. I will keep doing this for sure. That's awesome. I see you have the two, May and June, are already out there, right? Obviously the tools that you are

also using in your workshops, so Crossplane and vCluster, which I also agree with you. I mean, these are the two tools for these two kind of capabilities that we see out to the most and also the great community, big support by different companies.

Yeah. Yeah. And again, I'm focusing like in these two cases, like companies were funded around the project, right? Like they had an idea and then the companies were created. They are like a couple of startups. But then when you see who is actually contributing to the project, you see larger and larger organizations joining.

And for me, that's a good sign. If larger organizations are joining, then that basically means that I can adopt it. And I know that if I go a little bit deeper on the projects, I can see where the projects are headed. Mauricio, did we miss anything that the platform engineering community needs to know

besides obviously signing up for your book and once it's ready consume it and look at your GitHub repositories with all the samples, what else did we miss? I think that no, I think that we covered pretty much everything, as I mentioned

again like the book and my snapshots and everything is based on my community involvement. And the more that I get older, the more that I try to help people to follow a similar journey. If people want to get into open source, if they are passionate about something, and if they need mentorship, feel free to reach out at Salaway on Twitter.

My email is pretty easy to find as well. So just get in touch if you're interested. I'm always happy to help people. And if you see me around in conferences or anything, I'm more than happy to have a chat or sit down and code something new. Yeah. Maybe that's actually typically, Brian, that's the question that you always ask in the end.

But he just kind of hinted at it. Where will people see you next? That's a very good question. Do you know where you are in terms of conferences? So, KubeCon North America, I will be definitely there. I applied to Shanghai as well because I really want to go to China. That's a very selfish and personal thing. That's a very good question.

I don't know if there is anything else in between. Hopefully not, so I can just actually finish the book and we'll do the stuff that I need to do for the company that I'm working for. Something I didn't mention, I guess that that's also really important. I'm currently working for a startup that's called Diagrid. We are very developer focused. We are building tools for developers. We help teams to run their applications in production on top of Kubernetes using a project that's called Dapper.

And yeah, I'm super happy with the company, to be honest. I'm really happy to be working in a fast-paced environment where we are contributing to that CNCF space and trying to figure out how to help developers, how to get them there faster and again how do we fit into the Platinum journey. So yeah, besides that we are hiring as well as usual. If you are interested in that space, I'm happy to answer questions. Yeah, we'll definitely link all this information as well. Because I think we want to make sure that if people are building great tools for developers that make their life easier, that's good.

That's what we need, right? Yeah. It's all about that. Like, platform capabilities, it's pretty related to some of the stuff that you mentioned. You know, feature flagging, helping developers, APIs. So I'm happy with it. I'm very picky.

And if I'm happy, I think that a lot of people will be happy. But what you can do, if you ever want to come to Austria, you should take the opportunity. And we have KCD Austria coming up in September. So Kubernetes Community Days end of September. And the CFP is still open until the end of July. So we got about 12 days left to put something in. And Austria is pretty close.

I'm based in the UK, in London, so it should be like a two-hour flight. Maybe? Yeah, exactly. Direct flight with Austrian Airlines or whatever airline you prefer. But yeah, it's a two-hour flight. And you suddenly have commercials for Austrian Airlines.

Yeah. The sponsor. Is that the sponsor? Yes, the sponsor. Perfect. Please send me the sponsor. Perfect. Yeah. Please send me the link. I will take a look at the CFPs. And, you know, if they are interested in platform engineering,

I will be more than happy to go there and talk about it. Yeah. They definitely are. And I will be the host of that KCD. So, yeah, that would be lovely to introduce you to the audience. Nice. I'm building a very cool demo for the book now to extend the thing that you saw in Barcelona. And I think that this is actually the next level. Thanks.

Oh, yeah. Yeah, I'm happy. I'm happy with it. Then get your CFP in. I want to see you on stage. There you go. That's good. So a couple of last thoughts for me. First of all, I'd say Mauricio, with you saying

being selfish about going to Shanghai, I think if you're sharing all this information and doing all these conferences, there's no selfishness in picking where you want to go at all. It's great to have had Salaboy and Salsa Boy on the same podcast together. Andy,

speaking of salsa and all this, I think you should start an airline. Well, not even starting an airline, but have you ever salsed on an airplane, like mile-high salsa? Something to consider. It's interesting. I need to talk with Gabi the next time we're on the plane.

But I did want to bring it back to something you said in the very, very beginning, Andy, about why do we need to keep talking about this? Do we need to keep having conversations about this and obviously you and I and the podcast have had been starting this conversation not starting but we've been having these conversations for the last few months right but I've recently mentioned platform engineering to my team right and none of them hurt so Mauricio we work with in pre-sales for you know Dynatrace obviously and you know we interact with customers, new prospects.

And on my team, we see a lot of the more startup styles, like smaller companies that are usually a lot more nimble. But no one's mentioned the platform engineering yet. So obviously, yes, we need to keep pushing this stuff because I'm sure there are individuals in these companies that are aware and that are exploring and trying to get into these places. But in terms of corporate adoption, where they start officially moving over, that's still way behind.

We're not seeing big pushes of it. So by all means for you, for anyone else we've been talking to or anyone else listening who's part of the platform engineering community, keep getting the word out there, keep spreading it because I think it's going to only help. And you mentioned the idea of hiring 10x developers. This is where my mind starts thinking in more crazy areas,

but there's this looming threat of AI taking over development roles, at least at some level. So if you can make your developers much more efficient and useful as opposed to requiring a ton of, you know,

just like code sweatshops, you know what I mean? That's going to make it less attractive to try to replace by AI because you're going to have developers who can just get in there and focus on writing really good code and in some cases creative code and finding new ways to contribute. So it's

a double whammy of benefit to bringing that platform. So anyway, those are the final thoughts I had there. Yeah, that's pretty good. When I talk about AI, I usually don't focus much on AI because I believe that AI might be another tool that the platform team can give teams for them to produce stuff. And by applying all these platform engineering concepts that we have been discussing, I think that you are basically constraining the space where the AI can help developers, which is something good. You're giving a framework where these tools can be used instead of

just giving people AI and they would generate whatever. Right. So I think that that's a pretty good point. When I think about AI on platform engineering specifically, right? Like how do we glue all these tools together and how do we apply them? I see it like that's very company specific and very human centric right now. We need people making these decisions and having all this knowledge in their head and experience. It's pretty hard for me to think that we can automate any of these decisions, but we will see what happens.

Yeah, and I think with anything with automation, all this stuff's going to come down to what are the things that you repeat over and over and over again? That's what you can then start assigning to that bit, which frees up people to do the next level stuff. Right. So if we have that approach and people are working smarter and it's going to be less, you know, just even from the selfish point of view. Right. A company is always going to be looking at where can we save money? Do we need all these developers or can I just get chating it to a degree, but into places where it's the mundane tasks, then you're ahead of the game and it's a little bit more job protection too. But all benefits anyway. But that wasn't even the main point I wanted to make. But yeah, no, I think it all plays into this.

Anyway, thank you so much for being on. Really appreciate the time you took with us today and hope everyone enjoys the links. I'm going to go check out the books. I definitely want to get more information about this myself. And, uh, yeah, thank you so much. Thank you. Thank you. Bye-bye.

Thank you. Bye-bye.