Platform Engineering on Kubernetes

Platform Engineering on Kubernetes accelerates development of cloud-based systems with vibrant open source tools of the Kubernetes ecosystem. You’ll use powerful open source projects like Helm, Tekton, Knative, and Crossplane to automate your projects from testing through delivery. Learn how to package services, build and deploy services to a Kubernetes cluster, and combine different tools to solve the complex challenges of CD in a cloud native environment.

Join author Mauricio Salatino as he goes through key topics from the book together with Thomas Vitale.

Introduction

Thomas Vitale: Hello, and welcome to another episode of the "GOTO Book Club." I'm Thomas Vitale. I'm a software engineer at Systematic. And today I'm here with Mauricio Salatino, open-source software engineer at Diagrid and author of the book, "Platform Engineering on Kubernetes." Thanks, Mauricio, for joining us.

Mauricio Salatino: Thank you very much for having me here. Happy to talk about the book and the other stuff that is going on.

Thomas Vitale: I'm curious, how did you get into the cloud native and Kubernetes space?

Mauricio Salatino: That was like a long time ago, and I was working at Red Hat at the time. I was a software developer there working on all the Java, middleware solutions that they provided. And I've been working as an open-source contributor to some of their projects, really, with workflow engines, rule engines, and middleware like around application servers as well. I remember my first contribution was around, identity management and, single sign-on, that kind of stuff, that was pretty new to me as, a university student, but then I got into contributing more, and for that reason, I got hired.

I was working there like at JBoss, and I noticed that this team was working on a project that was called OpenShift. And they had kind of, an implementation, but then, at some point, they decided to switch to a completely new project called Kubernetes and build that on top of it. I started working with those teams trying to figure out how to move Java applications into Kubernetes and that took me to containers and to learn kind of, this fascinating world that we are living in today.

Open-Source: The Gateway to Continuous Learning in Software Engineering

Thomas Vitale: And you're very active in the open-source community. How is it contributing to the open-source and being part of the community? Do you have, perhaps, even some tips or suggestions for people who would like to start contributing to this amazing space that we have in the cloud-native environment?

Mauricio Salatino: Sure. I think that today there are, tons of opportunities to do so, right? Even for students, you can get into contributing to open-source without actually understanding the entire, ecosystem. I got started with it because I had a very good teacher at university who was already contributing to the Linux kernel. I quickly realized that Linux, in general, was too low-level for me, but I wanted to go more into application development. That's why the first thing that you should do when you want to contribute, to open-source projects is find a project that is close to the things that you're interested in. I was new at the time and I really wanted to build more and more applications. And the more applications that I build, the more I realized that, usually, you don't build a single application, you build multiple applications, and then you need to connect them together.

That's why my first contributions were all about that, identity or integrations, system integrations kind of tools. And I think that I found, my space. I felt comfortable with the idea of integrating multiple applications together. I found a couple of projects that were in that space and then I reached out to maintainers and said, "Hey, do you have something for me to work on?" Usually, reaching out to people that are working on an open-source project will give you access to a lot of tips, and a lot of tips are specific to those communities that are building these tools. First tip, find the project that you're interested in and then reach out to people, join Slack, join the Discord communities and just get in touch.

Thomas Vitale: That's great. That's also how I started. It was projects I was interested in that I was using. I needed some functionality, extra functionality, and then I started contributing with something small just to understand how the community works, the process of contributing, and then also contributing more and more. And it's really a great way for a software engineer to...

Mauricio Salatino: Just to get started, right?

Thomas Vitale:  To get started, to improve, to learn new things, and just to give back to the community.

Mauricio Salatino: Something that I found out quite early in my career was that I needed to keep learning after university. And I think that open-source gives you that space where you just keep learning based on your interests. You're not forced to learn something, but you can find things to keep learning. I remember at the beginning when I was fresh out of university, everything felt like magic, right? Things happen automatically and you couldn't understand all the layers of software. But then the more you get into projects, you understand more, and more, and more. And I think that open-source is great at just being kind of like an open university where you can keep learning.

Mastering the Cloud-Native Ecosystem: Insights from a Kubernetes Expert 

Thomas Vitale:  Open-source is one of the key aspects of the cloud-native ecosystem also. In your journey then, working with distributed systems, and integrating different applications together, then you finally ended up working with Kubernetes and writing a book about it. Let's talk about the book also. Why did you decide to write the book? And also, how did you choose a title? I know that before the book was originally called "Continuous Delivery on Kubernetes" and now it's called "Platform Engineering on Kubernetes." I'm curious about the thoughts behind that decision.

Mauricio Salatino: That was a very tough decision. But I guess that the reason why I wrote the book initially was that I was collaborating with a lot of open-source projects that were doing different things. But for me, coming from, that developer background, I needed a way to actually have, a perspective on how do I use these tools for different purposes, right? So, the whole, TOC, the table of contents of the book, it's pretty much a journey on how do you pick different tools as more, as a developer or an architect that is building a distributed application?

I guess, that the main reason for writing a book, it was because I had too many lessons learned that I wanted to share. It wasn't about, saying I want to write a book, and then I started thinking about how it would look. It was more about I already have, 10 different things that I want to say, so I would just put that in 10 different chapters. It is not a very common book because it actually tackles almost, 10 different projects, 10 different CNCF projects, and some projects that are even outside the CNCF, but part of the cloud-native space, and how do they relate to each other. And that was pretty difficult because nowadays, projects tend to appear and disappear in less than a year. And I've been writing the book for longer than that. Some of the projects that I started working with, they are no longer around or they are no longer relevant for the cloud-native space, and for that reason, I needed to do a lot of rewrites and all that stuff. 

Thomas Vitale:  That must be challenging because the ecosystem keeps evolving, keeps changing. But I read the book, so it's currently available as a draft version for early access. It was really interesting, also, the decision about targeting developers as readers. We both come from an application development background and then got somehow into platform engineering. I particularly like the focus on developers and helping developers understand this new way of working and also how to interact with maybe more specialized teams working with platforms and infrastructure.

Navigating the Cloud-Native Maze: A Developer's Guide to Tools and Ecosystem

Mauricio Salatino: Exactly. I think that's a great point, right? When I started using Kubernetes back in 2016, so many years ago, I quickly realized that these kinds of tools will be a pain for developers. Since then, I've been working on companies and projects that basically try to help developers in some way or another to get, more efficient using these tools. And for that same reason, I decided to write a book and just aim it to architects and developers that are, looking into this space. Sometimes they are forced to adopt Kubernetes, sometimes they are the ones pushing for the Kubernetes adoption. And when you are in those positions, you actually need to understand the entire ecosystem, not just Kubernetes.

Thomas Vitale: I really like the story also here that the reader takes on because it's so confusing at the beginning. There's the famous Cloud Native Computing Foundation landscape with all these tools around. How to get started? But your book, I feel like it really helps because you selected some of the most used and popular tools and the reader can understand why are they used and how they fit together in the full pictures of, moving applications to production, how to work with containers on top of Kubernetes, and how the environment works overall.

Mauricio Salatino: And it's, a continuously evolving space, right? Today, we are talking a lot about platforms, right? As you mentioned before, the book was titled "Continuous Delivery on Kubernetes." I think that it was titled like that, first of all, because the term "platform engineering" in the cloud native space wasn't that popular back then. I wanted to focus on the reason why you adopt Kubernetes because you want to deliver more software more efficiently, right? That's the why you adopt it. And I think that now with the term "platform engineering," we are focusing more on the what are we building to enable people to deliver more software, right? I think that continuous delivery and platform engineering are extremely related, right? They are two things that go by hand. But because of now in the CNCF, we are formalizing, more what a platform is, what it means, and what pieces we need to include in a platform, I think it made a lot of sense for the particular story that I'm writing in the book just to focus on that.

Thomas Vitale: We both contributed to this platforms working group in the CNCF, writing a white paper about platforms. Perhaps, we should say what's a platform, just to help people new to the concept, what we're talking about because the platform is quite a generic term. But in this case, it means a very specific thing when we talk about cloud-native and Kubernetes, right?

Mauricio Salatino: Exactly. I think that in order to explain what the platform is, maybe I can just share the journey that we go into the book, right?

Thomas Vitale: Yes. Let's do that.

Streamlining Cloud-Native Deployment: Tools, Techniques & Infrastructure

Related video - Inner Development Loop with Java on Kubernetes • Thomas Vitale • GOTO 2022 -

Mauricio Salatino: The book starts with the idea of having a sample application, it's a distributed application that you can deploy on Kubernetes, right? It actually starts by talking about what happens when you deploy something into Kubernetes, what do you need to know, and what tools can you use. And then the next step is, once you deploy something on Kubernetes, how are you going to build all these artifacts? How are you going to deploy them into different Kubernetes clusters? The next step is talking about, all the things that the applications will require to run, like infrastructure, and how do you create that infrastructure? How do you maintain that? How do you upgrade the infrastructure?

And I think that at that point, I felt the need of saying, "Okay. Now I've discussed, five or six different tools, and the combination of those tools, it's very specific to the organization that you're working on." Sometimes you're going to use Jenkins for pipelines or, a managed service like CircleCI or Tekton in Kubernetes, right? In the book, I'm focusing on Kubernetes tools, so I actually talk a lot about, Tekton and also, another project that's called Dagger that it's more like on the cloud native space. But at that point, after talking about, seven or eight tools, it made a lot of sense to say, "Okay. Now you need to encode all these decisions inside the platform that is basically designed for your organization."

You basically encode these decisions, you create an API to obstruct away all the technology choices that you're making, and you're focused on enabling teams to consume all these tools without actually needing to learn all these tools, which I think it's a fundamental step in how we work on the cloud native space. So far, we have been pushing a lot of people to learn a lot of technology that wasn't strictly related to the things that they were working on on the day-to-day, right? If they were Java developers or Go developers, writing features for an application, we push them to learn about containers, and the Kubernetes APIs, and then Tekton, and then, a bunch of other projects, right?

Thomas Vitale: And then it explodes eventually because there are too many tools.

Mauricio Salatino: Exactly.

Thomas Vitale: It's really important this distinction, getting developers the right capabilities to work with these cloud-native technologies, but then having a dedicated platform team that then can serve all these capabilities to developers, and they're responsible for it without developers having to know everything.

Mauricio Salatino: And I think that we are going, up the stack, right? We are now creating an obstruction to encode the technology choices that we are going to build inside of our platform. And then we are just going to make, responsible the platform to decide, what's the organization-specific workflow to take all the changes that developers are making, in front of our customers. And that takes time. It takes an evolution inside an organization to actually achieve all these things. I'm focusing on the book more on developers, more on platform teams, and how they make the choices, and how they encapsulate that. And then at the end of the book, I cover, how they measure how well those decisions are working or not.

Simplify and Scale: Leveraging Knative for Containerized Application Deployment  

Thomas Vitale: Maybe we can mention a couple of tools that are part of the book. For example, Knative, you're also part of the committee and you're a maintainer on the project.

Mauricio Salatino: I'm covering Knative on that part of, the book where I'm talking about platform capabilities, right? Giving developers the possibility to experiment, right? When I used to write applications before, I never had the opportunity of running multiple versions of the application at the same time. And with tools like Knative, you not only get that, but you get a simplification on how you deploy your applications using more like a container as a service approach. But also, you get, advanced traffic management to do different release strategies. And the whole point of using these tools is just to enable teams to just release more software, deploy it, and then let someone else to decide when that new version is ready.

Thomas Vitale: And reduce the cognitive load for developers. I really love working with Knative. You provide a container image and then it takes care of everything else rather than me having to deal with all the details of Kubernetes and all the resources and how to get an application in production. That's really powerful.

Mauricio Salatino: And you said it right there, right? You as a developer, probably, you don't want to learn about Knative. You want to use it. You want to use the features. As platform teams, I think that we are going to a space now where platform teams are delivering features or capabilities to the application development teams and not tools in this case, right, because if I push a developer to learn how Knative works, well, that's not even related to what they are doing, right? They are writing features for a customer for their app. Right? But if we give the developer the possibility to do A-B testing, for example, or using feature flags, this kind of stuff, I think that it's extremely important, and we can train kind of like the new generation of developers to have that, as a base layer, right? They all know how to use feature flags, they all know how to do different release strategies so they can keep releasing software.

Thomas Vitale:  And that's a powerful concept. Now organizations can really, building on top of all these tools that we have in the open-source space, build their own platform that is fitting and suitable for their own needs, for their own requirements, and really provide the capabilities developers need the most.

Mauricio Salatino: Yeah.

Dapr: Empowering Developers and Simplifying Infrastructure 

Thomas Vitale: And speaking of that, perhaps we can talk a bit about Dapr...

Mauricio Salatino: I love Dapr as well.

Thomas Vitale: ...which is the project you work on, because that's really focused on improving the developer experience and providing a lot of these capabilities in a transparent way so that developers can really focus on the business logic without dealing with all the infrastructural concerns.

Mauricio Salatino: Dapr is a tool that I'm really loving because it fits to that space and to that part of the story, right? You enable developers with more and more tools until you reach a point where you can say, "Okay. Most of the services, are going to write data to a database or read data from a storage." Most of the applications that we build nowadays, are like saving files into S3 buckets or any blob store that you can find in the cloud or you're going to consume credentials from a service. All these shared concerns from applications need to be kind of like in a way encapsulated in something. And those shared concerns are actually kind of, the main target of the Dapr project.

As Knative where it's a Kubernetes extension that you can install in your cluster and then now you have all these capabilities that developers can access, using a local API from their applications. And usually, what this gives us, which I think that it's the most important point that I'm covering in the book, is that it helps us to push away infrastructure from the application itself. When you want to write data, instead of having a database driver or a client to access infrastructure, you actually know that you can consume a local API to do that, right? This enables platform teams to wire up, which infrastructure are you going to use? In which cloud provider that it's running? And also, what are the credentials that I need to access to that service, right? Something that a developer at the end of the day shouldn't worry about. They should just know that they can store data or read data, emit messages, consume messages, or interact with other services, which is, I think, a very good value proposition for both.

Thomas Vitale: It really is. And really makes developers more productive and a better way to deal with all these infrastructural concerns.

Unveiling capabilities: Delivering functionality stealthily without tool exposure

Mauricio Salatino: Something that I've been not concerned but thinking a lot about lately it's about that how do we expose all these capabilities without leaking the tools that we are using, right? I want to provide the developer those functionalities without them knowing that that's being implemented by Dapr or by any other tool, right? The same with Knative, right? How do we provide, release strategies as capabilities and not as Knative services, for example?

Thomas Vitale: That's one of the main challenges, also one of the most interesting topics we have right now in this space that is about platform API. What's the right level of obstruction, and how can we provide capabilities in a very transparent way so that developers really don't need to know without leaking all these details from the implementation?

Mauricio Salatino: And it has been happening lately. We are trying to hide away Kubernetes now. And I think that's why, managed services like Cloud Run or container services are growing more because people like the idea of scaling up and scaling down your applications and running in a data center without knowing that there is a data center. I think that, the popularity of these managed services are reflecting where the cloud-native community is going. And we are building more and more tools around that. If you don't want to use a managed container service, what you do is you build your own on top of Kubernetes and then you have the opportunity to create higher-level abstractions. 

Thomas Vitale: And it's interesting how we got here, because initially, everyone was just using plain Kubernetes because it was new, it was exciting new technology, and then we started building things on top of it and realized, okay, maybe we don't want developers to use Kubernetes directly, and then we started focusing more on how can we deliver more value, how can we build features and deliver them faster, which is great because initially, it was really very technical, a lot of hype there. It's great, but now let's build a business on top of it.

Mauricio Salatino: Exactly.

Thomas Vitale: Let's focus on what we do in our organizations to deliver value. And then, of course, managed services are an important part there because we have the opportunity now to build this customized and tailored experience or curated experience for organizations to get the right capabilities they need to work better and faster.

Mauricio Salatino: You can see software providers now, focusing mostly on delivering those managed services. They use Kubernetes under the hood just to run it for multi-tenant scenarios, but it's still hard. It's not commoditized yet. You just need to build and you need to go through the Kubernetes journey, right? That's something that I'm covering kind of, in the new revision. I try to create a map, a Kubernetes journey so you can actually, when you start, you can say, "Okay. I'm stage four," or something like that. I already know Kubernetes. I know a bunch of tools, but, for example, in my organization, I'm not following any platform engineering practices just yet, or I don't have, a platform API. Now you know where you are and you know what's coming ahead. And I think that that's very valuable nowadays because it's always changing. The more that we mature, we build new milestones. And it's fascinating to see the Kubernetes space, how it grew, and the amount of tools that we have today, and how is that very complicated for someone to just stay up to date.

Thomas Vitale: And I like that you cover, not only strategies and patterns and guide the reader based on where they are in this cloud-native journey, but also, there's a lot of examples in the book. At each stage, you can try things out by yourself and see how you can consume these capabilities. And especially, I like that it's not just about serving or providing capabilities, but also making sure that we are providing the right capabilities. The chapter about measuring what the platform is doing, because the goal is we want to deliver better, softer, faster, more securely. We need to verify that it's actually happening, and either way through the implementation of the platform in order to make sure that we are reaching that goal. I really like that you included that part.

Mauricio Salatino: I think the thing that you read, I think that it's pretty good, the idea of using Dora metrics in order to measure the platform performance. I think that as any, because, we are building software, right? The platform itself is software, it has some APIs. As developers, we are good with APIs, so we should be able to define good APIs for our teams to consume. But as any software, if we don't measure it, we don't know if it's working or not. I'm a very big proponent of, let's make sure that if you start building a platform, you start measuring it from day one. If you need to change some tools, I can actually see, if this new tool that you added to the platform is making an impact or if it's the same. Actually, you're not saving anything.

Thomas Vitale: And you need those checkpoints and continuous feedback so you can continuously improve and refine and tune the platform to provide the best value.

Mauricio Salatino: Going back to the examples. It has been pretty hard to keep them updated because everything moves forward so fast. But the latest revision of the book, and I think that the version that is going to be printed, it's basically focusing more on topics per chapter, and then you have example tools to see kind of, how these concepts apply, right? Because at the end of the day, I don't want to say, "You should use this tool for doing this." It should be more "You should be thinking about these topics. And then there are some tools solving these topics, they have some trade-offs, but you are the one responsible to choose for your own platform." Right?

Thomas Vitale: That's perfect, because once you understand the problem, the capability you want to achieve, maybe you experiment with a specific tool, but then if you understand the concept, you can pick another one in the future since we always get new tools and new options in the cloud-native landscape. It's nice to acquire those skills so that the reader can better navigate then in this landscape in the future.

Mauricio Salatino: I think that in order to efficiently navigate the CNCF landscape, you need to have the right mental model. And that's why I love the paper, is that it's actually trying to come up with some definitions that gives you that mindset to explore this landscape and say, "Okay. Now I'm interested in this kind of tool, so I need to go and see the trade-offs and then just choose one." And it's becoming more complicated, right, because now it's not only about CNCF tools, but also, managed service that are solving those things for you. You don't need to run those tools on your own, which is also important.

Thomas Vitale:.And focus on what really makes a difference or the differentiating activities within your organization. Absolutely.

Mauricio Salatino: It's kind of like an interesting space. I'm pretty sure that we can keep talking about this for hours.

Kubernetes: Is it a boon or bane for your organization? 

Thomas Vitale: The book is currently available, so people can already read it. It's available on the Manning website and will be published later this year.

Mauricio Salatino: That's correct. And if you search "Platform Engineering on Kubernetes," I'm pretty sure that you will find the book.

Thomas Vitale: We'll share the links with the video, also the white paper we mentioned about cloud-native platforms.

Mauricio Salatino: And you can also, check my blog, right, salaboy.com, where I'm trying to cover some of the adjacent topics that I'm covering on the book, right, and the new trends that I'm seeing that are coming. I've been doing this on my blog, which is basically trying to create monthly reports about cloud-native projects, like CNCF projects, but also, the companies behind to try to get some sense of not how successful the project is, because sometimes these projects are large communities, but also how kind of, the company is trying to monetize that project by providing services or a managed service because I find it extremely interesting to see how the whole space evolves. And for analyzing the space, you cannot only focus on the project. You need to focus on the people that it's behind those projects, the investments, the money that it's being put into making this project successful. And also how people move around, right, from one company to the other, you can actually see who is defining the shape of the things that are coming.

Thomas Vitale: I think that's a really interesting initiative because, you're very much involved in all these open-source projects, so you know how the industry is going, how the different projects work with each other. You have a very unique view and insights into all that is happening. I feel it's really nice to have those reports so that it's easy to get the gist of it, what is going on, what are the options, and why would you think of using a specific tool in your organization and get even some tips or additional information about maybe challenges of using that tool or when it's actually a good fit for your platform because that's also a matter of how do we choose what to... There's so many options that it's overwhelming sometimes.

Mauricio Salatino: And sometimes that's the problem, right? I think that you cannot look into a project and say, "I want to choose that project because I like the project features." You need to also try to understand the community and also the company behind and the motivation behind the project. Because if you don't look into all these factors, you might go into a very risky situation where you adopted something, but it's already fading out, and then you ended up maintaining something that you're using, but you're putting a lot of effort in just making that thing run.

Understanding the space, it's pretty important, and that's the main reason why I'm doing it for both, the book and the reports. It's not that I'm doing it because I really like writing, but it's more because I'm getting all this information and I want to share it with people. I think that the book is pretty accessible, and most of the examples are open-source. You can go and run the examples without buying the book. But the reports are also going to go out for free now for people just to read. And I'm aiming specifically not to developers, in that case, but more like decision-makers where, they need to have a full picture about where a certain initiative is and how risky it is to go and adopt it and how easy it is, right? Because sometimes these decision-makers will say, "Okay. I want to use that project because I really liked it or because I saw it in KubeCon so many times." But then when you give it to a technical person, they will have, three months of learning curve and then it's going to become a problem. So, that's the problem.

Thomas Vitale: That can be a challenge when a current organization decides to build a platform and they start with Kubernetes, and then it's easy to say, "Oh, we have all these many open-source tools, we can put them together and we'll have something done in a month." And then you start actually using the tools and understanding that it's actually a tough job that requires a lot of attention, a lot of research and analysis.

Mauricio Salatino: I guess that's something kind of, on the journey milestones. At some point, an organization realized that Kubernetes is hard. As an individual, you can learn Kubernetes, but when you need to train a large organization to understand how Kubernetes works or how to even maintain Kubernetes clusters, it's a large investment. The Kubernetes journey for organizations is a little bit bumpy. Sometimes they need to actually know why they are getting into Kubernetes and how they are going to tackle those challenges. And it's getting better, right? We have a lot of people doing the right things and we have a lot of materials outside, right? Not only the books, but also, people in the community doing trainings and all that stuff.

Thomas Vitale: And the platform engineering movement, I feel, is really helping organizations understand how to start designing or analyzing the usage of platforms because before, we would start with Kubernetes and then from a very technical point of view maybe start adding tools on top of it and even more tools. But now we realized, hey, we're building software. We know from software engineering all the good practices are building software. Let's start with what the users want. What are the requirements?

Mauricio Salatino: Exactly.

Thomas Vitale: And in this case, the users are developers. Let's start with talking with developers, understanding their requirements, defining a nice platform API that they can use to consume these capabilities, and then think about the technology part. And that was an initial mistake that we've done as an industry, basically, forgetting about developers and then making their lives not that simple.

Mauricio Salatino: Much more complicated.

Thomas Vitale: Now things are getting better. We have a lot of attention and it's great to have your book about it to make people more aware of what is a platform and what's the good way of using Kubernetes because it's too easy to just add additional complexity in your organization and then not getting the benefits out of it and then maybe blame it on Kubernetes, but it's always a matter of how we use the technology, and are we focusing on the right requirements.

Mauricio Salatino: Exactly. And I think that's what we're seeing now in the Kubernetes community. I can see more developers getting into the Kubernetes space, understanding why it's important for them to know how Kubernetes works so they can design their applications to run more efficiently on the cloud and in these distributed setups. But at the same time, I see the Kubernetes space and all the platform engineering movement in the cloud native space to push for more. We are working towards trying to define how do we expose all these tools to developers. How do we give the right tools that they need so they can do their work?" So, I will estimate that in the next KubeCons, we will see more developers popping up, maybe more architects that needs to basically make those decisions for the development teams, right?

Thomas Vitale: Of course, it's important for developers to know about Kubernetes at the high level because we need to know the constraints of the environments where we are going to deploy our applications. But perhaps in the past, they have been feeling a bit unheard or not involved in the decision because they were in this position of having to deal with Kubernetes directly, so it's nice now that we are inverting this direction of designing starting from talking with developers and understanding their requirements and their needs.

Mauricio Salatino: Exactly. I think that it's all about evolution. When you look at cloud providers, usually, they started giving you the possibility to run a virtual machine. And then they started growing up the stack. They were saying "Okay. Now you can run virtual machines, but you can also create databases. And then you can create virtual machines that are configured in a certain way so your applications that you put in that virtual machine can connect to those databases, right? And you only need to focus on the application now. You don't need to focus on the database or the virtual machine's creation and all that stuff." And the same is happening in the Kubernetes space, right? Now you can create clusters where you can run containers, but then how do you configure storage for those containers to use? How do you configure security? How do you configure identity management? How do you configure databases?

And all these things, right, that will start adding up into the cloud native space, we are reaching to a point where we are recognizing that, okay, this is a very good set of building blocks, but we need to build the organizational layer on top, right? No matter if you're using Google Cloud or Amazon, you always need to build that layer, right? Platform engineering is not new, but it's new building platforms using the Kubernetes APIs as an abstractions for gluing all these tools together, right? And it makes it multi-cloud, right, because, the idea of running with Kubernetes is that you can run on any cloud provider. And the big advantage of that is that you can use the same tools no matter which cloud provider you're using.

Thomas Vitale: And we have plenty of very productive tools that we can get access to. That's also one of the big benefits of building platforms on top of Kubernetes. But then it's important to draw that line. We have the focus on the platform API, and then each organization can decide where to draw a line about what to implement themselves in their organization. They want to rely on these external providers, external services.

Mauricio Salatino: Exactly.

Thomas Vitale: That's also an important decision.

Mauricio Salatino: And also my presentations, usually, I show an extension of the Kubernetes APIs where teams can interact with that in order to request environments or whatever, right? But I've seen a lot of companies that doesn't want to let developers to interact with these Kubernetes APIs. They wanted to have simpler APIs that developers can access, right, or portals where they can just click and request stuff, which is great, right? But I believe that there is a lot of value on having kind of that internal platform API based on the Kubernetes APIs because, that no matter which tools you choose, as soon as they follow, what we are doing in the cloud native space, they will actually interact very well between each other, right? You can make decisions, you can glue things together, but all the tools will kind of, follow the same approach. Understanding kind of, how your platform works from an internal, platform team can be much easier, right? You can onboard more people coming with, a Kubernetes background.

Developer experience: Your tools should be enablers for all involved, not blockers 

Thomas Vitale: Just like we build software, where we have perhaps an API gateway where we curate the API and we make it consistent, but then internally in the system, we can have any number of services we want implemented in different ways. It's great that we're getting to that realization that, hey, this is software, so let's focus on the API and then internally, then we can evolve the platform also based on new tools that are coming up if some tools are being deprecated. And without impacting the users, they will continue having a great experience, a great developer experience.

Mauricio Salatino: I think that's why developer experience is being mentioned a lot of time now in the Kubernetes community because we want to focus more on enabling these teams to be more productive. And I always like to mention that we're not only focused on developers, right, but we are focusing on different personas, right? We can also focus on data scientists. And they have a completely different need for different tools, right? But understanding who the main persona who is going to use our platforms is will allow us to make those decisions for them, right?

Thomas Vitale: That's also why I like talking about platforms in more generic terms and not calling it, for example, a developer platform because then, we remember about developers finally, but then we forget about other types of users, data scientists, testers. It's important to have this full overview of what are all the stakeholders, what are all these users, just to get the right requirements in place.

Mauricio Salatino: That's really important. And the same as, another thing that is happening in the cloud-native space is that, usually, people talk about platforms, they talk about, an internal dashboard where you can access that. But you can have any dashboard and it will actually not work if you don't have the right APIs below that, right? If you craft a good API, then you can make the platform accessible to any developer. They will know how to interact with APIs. You can make it, the API to be self-service. You can actually request stuff, and then the platform will provision some things for you. But focusing only on the user interface, on making it just UI-based, will solve some problems, but it will take you more time, right?

Thomas Vitale: That can also be problematic. And I always like making comparisons with how we build normal software because also in that case, we have an API, and then maybe on top of that, we have maybe an Angular application with the GUI, but then we have a very clear and well-defined and agreed-upon API that we can use also to integrate with other external parties. And if we only focus on the GUI, then we might miss out on a lot of opportunities here.

Mauricio Salatino: Exactly. And I think that's a very important point. We have this project called Backstage, right, in the cloud-native space, very popular from Spotify. It's great. It's the perfect project. But I guess that usually divert the conversation to documentation and, making sure that we have a user interface that is nice and people can use and navigate, different parts of the platform. But for me, it's, if you concentrate on the APIs, you are building the right, base layer for your teams to work with.

Thomas Vitale:  And once you have that API well-defined, then you can use Backstage to build this portal and have a nicer experience to interact with the API via forums, via some more interactive options.

Mauricio Salatino: And now it's super interesting because I'm seeing the cloud-native space going outside of Kubernetes as well. Thinking more about the tools that we give developers to use, right? Tools like DevPod that we saw published a couple of weeks ago, a month? A couple of weeks, I guess?

Thomas Vitale: Yeah, a couple of weeks ago.

Mauricio Salatino: Focusing more on creating kind of these reproducible development environments. I think that those tools are great because at the end of the day, what you want to do is, if you are onboarding someone new to work on a project, you don't want to spend them like five days trying to set up their environment.

Thomas Vitale: I want to get to the code as soon as possible and start implementing new features. That's actually one of the metrics, for example, they use in Spotify that they share, how long does it take for a new employee to use the platform to just have their first pull request approved? That's a great metric. If it's five weeks, maybe there's something that we need to fix if it takes so long to establish a developer environment and install the tools.

Mauricio Salatino: And also make a new developer to wrap their head around kind of the whole organizational process of submitting code and just changing stuff that already exists. I think it's really important. If we focus on those topics, we will add more automation, we will find the right abstractions, and the good thing about the CNCF space and the cloud-native community, in general, is that we are very good at abstracting away problems and having the right interfaces for people to consume. I'm super excited about what's coming and I'm really looking forward to see, next KubeCon what's going to be announced.

Thomas Vitale: It will be interesting.

Mauricio Salatino: We will see. 

Thomas Vitale: In the meantime, we have your book to read. Right now it's available on manning.com for an early access read and will be published later this year.

Mauricio Salatino: That's right.

Thomas Vitale: It's "Platform Engineering on Kubernetes" by Mauricio Salatino. How can people reach out to you?

Mauricio Salatino: Yep. They can follow me on Twitter, @salaboy or salaboy.com, which is my blog. And I'm always open to collaborate with different people or even mentor people into getting into open-source. The only requirement that I usually ask to is that they need to be willing to spend time. If you want to contribute to open-source, you need to put some time and do some work. But once you get started, it's like you will build your knowledge and you will be able to contribute to other projects as well.

Thomas Vitale: That's a great offer. Thanks for all you do for the community. It's amazing.

Mauricio Salatino: It's kind of crazy because I usually do it for myself. That's my way of keep-learning, right? It sounds selfish, but I wrote the book just for my own purpose, for my own learning process. The same with the reports and the same with mentoring people. Every time that I mentor someone new, I realize how much do they need to learn and I try to shorten, their journey and just make it easier. And by just doing that, you actually recognize new opportunities to contribute to other initiatives as well.

Thomas Vitale: That is fantastic. Thank you very much for being here, and thank you all for watching and joining this new "GOTO Book Club" episode. See you next time.

Mauricio Salatino: Thank you very much.