 Hi, everyone. My name is Boris Kirchiv. I'm a principal solutions architect at Nirmada. We are here today to discuss why recently terms such as platform engineering, platform as a service, internal developer portals, et cetera, have caught much of the limelight in both internal organizational discussions, but also whenever we chat with our peers at conferences. I will introduce what I believe to be a solid foundation for these new concepts and how we can help you introduce them within your organization with as little friction as possible. Let's dive in. The rise of platform engineering is inevitable. Gartner is putting it at 80% likely that any serious software development organization will establish a team of platform engineers by 2025. But before we get to what Gartner says, let's talk about why there is a need for a shared foundation. As you move into the cloud native landscape, being able to enable cross-team functionality is necessary. And definitely a requirement by the nature of how complex software architectures have become. That is where platforms emerge as the natural problem solvers for what is surfacing out of these elastic developmental and delivery expectations that software teams are coming to expect. Somebody has to run these new platforms. And thus platform engineers and generally engineering has kind of burst onto the scene. I believe we've all seen a lot of artifacts being produced by the various CNCF working groups and technical committees, as well as obviously talks, such as the one that I'm giving today. So let's talk about where does a platform fit in in an organization, right? It generally is the glue layer between your underlying low-level infrastructure and your internal end user. Usually those are your product team, your service teams, and your security teams. What a platform does is it ties it all together, ties all the internal tooling from these separate teams into a single working catalog with a single entry point allowing you to consume all of these different disparate tools and allowing you to offer them as a service. Thus allowing people outside of a specific team or outside of a specific part of the organization to be able to leverage the work that others have done. So this kind of middle layer sandwiched in between the actual services and the infrastructure is where platform engineer and platform teams will spend most of their days. Ensuring that no matter who wants to consume what, there is a unified and singular location where they can go and find what they need. All right, so what are the responsibilities of this kind of emerging new class of engineer, right? What does the day in the life of a platform engineer potentially look like? Well, it is complicated. They tend to be responsible for designing, implementing and continuously improving these platforms in order to kind of fit within the demands of your internal customers. So in order to accomplish that, they have to integrate tools to enable all of these different groups to self-serve their needs and be able to consume these cross-team tools at once. They have to provide support for the platform. They have to work with every team in order to establish what does it mean to have best practices as an example. What are the common accepted defaults that we should have no matter where, what and how we stand up a new stack, implement a new tool, introduce a new feature into our catalog. They also have to establish what the security policies are for these platforms and across all of these different tools as in who can do what when and keep an actual audit trail. So when we need to answer these questions, we are able to. Not only that, but with the ever-involving legal side of our world, compliance with things like GDRP, HIPAA, PCI, or if you want to implement NIST 800 series controls as an example, you need to be able to ensure that every tool and everything that you are consuming is actually not falling out of compliance with the standards. If all of these things weren't enough, we need to monitor this new platform and all of its pieces. We need to keep optimizing it in order to fit in the continuously evolving needs of all of these different teams. And if all of that was not enough, we got to keep it all up to date. So, you know, that can be a little overwhelming to think about, you know, oh man, this is a lot of pieces, a lot of moving pieces, how and why are you trying to convince me that this is better than what we have right now? Well, you know, this is definitely one of the most common questions that I get asked whenever I discuss this topic. You know, why does this matter to me? And, you know, one of the central driving tenants of innovation within the CNCF and all of its project is that it can be tied to probably four core tenants, right? We want to reduce complexity in order to save money. We want to increase the rate of innovation within our organization in order to make more money. We want to eliminate any barriers between teams and thus increasing their rate of innovation. And then we want to make sure that whatever resources we're provisioning and paying for, we are utilizing to our maximum, thus reducing the complexity. Tying all of these pieces together is, you know, opening up kind of finally a new space, you know, to where we can use this unified platform to accomplish all of the above. We can bring the, at that point, we can actually start bringing in, you know, risk reduction and some other benefits of beyond kind of the monetary piece to all of this. So what are the requirements of a cloud native platform? So, you know, I don't know how many people go to the landscape page anymore, but I remember back in the day, I'm gonna age myself as a gray beard. I remember when the page will encompass a single screen and there was no need for a zoom button in order to kind of look at all of the, that the CNCF had to offer and all of the different projects. But these days, that is no longer the case. This is a good thing. However, again, it can be a little daunting to look at, wow, that is so many projects. Which ones are the, where should I start? How do I solve the blank page problem? So, by looking at everything that I've talked about so far, it can ultimately be, ultimately be summarized as a need for projects which hit some of the following criteria, right? It should be composable. This means that we are not stuck with a static design. It means that we can change the platform. We can change our design as necessary to evolve and not be kind of confined to a singular space. It does not lock us into a specific low level infrastructure provider. Portability is never something that anybody has frowned upon. It should use only battle tested components from the CNCF portfolio. Having a vibrant community to lean on is a must. Obviously, a lot of companies emerge from all of these projects, but it all starts with having a user base before you have to deal with commercials. Whatever project we use, it should be flexible and extensible. As I mentioned, composable and non-static design is inevitable. That means that we need to make sure that whatever components we are choosing are also as flexible and are able to help us mold with minimal friction the new designs that we may encounter. And finally, it should be Kubernetes native, right? I make this joke quite often at this point, but if you really wanted to, you could run Kubernetes on your phone, right? It is that ubiquitous in our lives, whether we know it or not. All right, so one of the great benefits of the CNCF is the various working groups and technical advisory committees and groups which produce a lot of forward thinking. But more importantly, they unify and give us a common language to use when discussing new concepts and new ideas. The CNCF has purchased, or not purchased, I'm sorry, has created through the app delivery tag a platform maturity as well, a model as well as a glossary. Personal note, I did lend a hand in the creation of both, but they are 100% necessary because there is a need for guide posts and actionable markers to use when navigating a platform journey. This is especially important in these early stages of platform engineering when the lack of common language, as I said, can cause a lot of confusion as different teams are trying to, you know, convey their needs and convey their wants. So with all that said, we need something similar to what the infamous LAPStack did for the early internet age. We need a defined starting point that anyone can run anywhere and by extension, it can provision, update, govern what you're trying to do. Welcome to the back stack. So like the LAPStack, the back stack aims to offer kind of a predefined, cohesive, as I already mentioned, you know, battle tested and vibrant selection of the CNCF project, specifically chosen to serve as the building blocks for modern platforms. This, you know, to bring us back to the question of why does this matter to me? We want to increase innovation. We want to leverage a predefined framework. Developers can focus on building features, and functionalities quicker, instead of like researching and integrating and figuring out how to connect all of these different disparate tools. We want to reduce complexity. The back stack aims to simplify the decision-making process for developers and architects by giving you this predefined set of components. We are leaning into the need for increased interoperability, which the stack, you know, is trying to choose components that are known to work well together, and thus ensuring smoother integration and fewer compatibility issues down the line. And finally, I think I have mentioned this quite a few times now, but like the community support and longevity is extremely important. So we are leaning into well-adapted CNCF projects, thus, you know, benefiting from strong communities and proven track records, which ensure continued support and development of these projects. We are trying to make sure that we are leaning into the top choices from each category we see as very important. All right, so let's talk about the actual individual components. First, we have backstage. If we refer back to the Gartner model, that is your developer portal. That is where your end users enter and view what is available to them to consume. It allows them to pick and choose the blocks that they need for their Lego set, the Lego build without having to know the intricacies of how the implementation details. Argo CD is the de facto GitOps Kubernetes native keeper of truth. We are also leaning into it and ensuring that all GitOps flows up through Argo, and which allows us to ensure a consistent state and auditability trail as we function within the stack. Next up, we have crossplane. It is our orchestrator. It ensures that we are able to provision across any provider that you might want, and thus making sure that you're not vendor locked in to a specific low-level infrastructure, which again, I don't think anybody has ever complained about not being vendor locked in. Excuse me. And finally, we have Kiverno. Kiverno ensures that everyone behaves as expected and desired. Everything from new applications being deployed that have to pass the security and compliance checks that we talked about earlier, such as HIPAA or PCI or GDRP, to being able to access the security and compliance checks to being able to define such things as microsegmentation or zero trust within the different components and different applications that we are running on the clusters. All right. So why the need for a reference architecture, right? We have designed the back stack to not be rigid and or static. It is designed to be adaptable and customizable. Think of it as a toolbox with various knobs and levers that you can use to tailor the platform to use specific requirements. So like while we recommend a core set of tools, you're not limited to them. You can swap specific components or plug new components in in order to fit your needs, right? The, again, the point being to solve the blank page problem. Where do I start? How do I start? Somebody has done the legwork of giving me a proper first building block. We don't think that the back stack encompasses every aspect of a platform. You can integrate additional tools to integrate functionalities beyond the core components. As seen in some of the previous slides and some of the discussion that we've had so far, the landscape is vast, right? There is not one tool that fits all. We chose each component specifically because it offers customizable. You can adjust settings to optimize performance, to fit security models, to augment GitOps practices, to provision and define APIs that do not currently exist. At the end of the day, the idea behind everything that is within the stack is giving you the tools to align better with your environment. So let's put it all together. What does this look like from a technical perspective? We are referring to this as the hub and spoke design. With the idea being that the design is capitalizing on Kubernetes and the elasticity scalability that it provides, which gives us the ability to have a unique set of clasps around the development deployment and data management of your organization. With this central kind of data hub, this is where the hub and spoke begins in AKA the hub cluster. The hub is the single source of truth. It provides foundational data and services to the surrounding applications, AKA the spokes. The spokes can be its own clusters with its own specific applications. The spokes are fully isolated from one another, which means that by utilizing again all of the components with Converno and Argo, et cetera, we can make sure that not only are you able to create micro segmentation of applications within the cluster, but you can also create a segmentation between the specific clusters or group of clusters. So you're never having to deal with noisy neighbors. You never have to worry about, oh, how am I going to achieve multi-tenancy? How am I going to achieve, again, something like zero trust if I want to by providing a base set of policies that we believe everybody should at the very least start with. You are able to know for sure that your journey is in safe hands, if you will. And again, all of it is kind of governed through Git and everything as code. If you go in our repository, you will see that even provisioning and consuming things through Brackstage ultimately end up tying to your Git repository, which is important as we work through the auditability and why did something happen at this particular time. This is also very, very important as you bring in new members, whether it's on the consumption then, AKA your developers and product teams, et cetera, but also on the platform and whenever you have to bring in a new member of the team and have them interact and understand, hey, why, how did we do this thing at this particular moment in time? What was the state of the system, et cetera? All right, so how did you get started? I believe there are a set of logical steps to follow here. Before jumping in and immediately running to our website and downloading everything, assess your specific needs, understanding the problems you aim to solve, will help you customize the back stack effectively. Like consider what level of platform engineering maturity your organization has achieved. Go to the tag app delivery maturity model and go through the process of understanding what level do you believe your organization is at. The back stack is ideal for those that are level two or above. Step two, right? Once you've got some of the requirements that you have, get to know each component of the back stack, right? Explore backstage, Argo, cross-plane, and Convernal. All of them offer on their own a multitude of augmentations, customizations, as we said, et cetera. This will be crucial whenever it comes time to integrate with the non-off-the-shelf components that your organization is consuming, creating, et cetera. You do not have to be an expert in backstage, Argo, cross-plane, or Convernal. However, understanding their purpose, et cetera, and architectural fit will be crucial. Step three and four are kind of a self-explanatory, but obviously just jump in, go to our website, follow the documentation, stand up a sandbox, play around with it, understand it before inviting others to consume what you have done. While you're playing in your sandbox, make sure that you experiment. Break things, play with the different configurations, play with the integrations, use different cloud providers as each cloud provider has their own kind of requirements and flows, deploy some of the add-ons that we have out of the box to spoke clusters, configure some security policies. And then from that point on, once you're comfortable with those things, begin evangelizing. I don't think I can highlight this enough, but you have to ultimately internally become a bit of a salesman, right? You have to find and encourage a select development, select group of development teams to kind of familiarize themselves and try to consume the backstab. Have them start with the built-in workflows, right? More often than not, organizations need cluster as a service to use a very popular workflow that we have. Not one being namespaces as a service to allow you to do kind of multi-tenancy within all these new clusters that you are provisioning. Excuse me. And finally, start hacking away at the stack, modify it, fit it for your organizational needs. And then don't forget to contribute those PRs back to the repository. We are building the community today. We're working on with multiple vendors who are donating time, but we're trying to create a new vibrant community to work with us and help us guide the project as we try to evolve it and add new features and new improvements, et cetera. Come join the conversation. All right. So let's just kind of summarize a little bit of what we've talked about today. Platforms have arrived. Platforms are here to stay. They're not going anywhere. Platform engineering engineers are a new engineering level and title that is tasked with wrangling these new platforms. Platform engineers, due to kind of the, how young all of this is, do need to solve the blank page problem. They need a solid foundation to start with and be able to kind of bring the four pillars that we talked about earlier. Reduce complexity, thus saving money, increase the rate of innovation, thus making money, eliminate any barriers between teams, thus increasing their rate of innovation. And number four, make sure that whatever resources are provisioned and utilized are utilized to the maximum, thus reducing complexity. By embracing the reference architecture, you can actually foster the collaboration, efficiency, secure development of environments that are needed in order to stay compliant, in order to, again, continue to drive those four pillars. Join us, you know, join us on backstack.dev. That is where a lot of our documentation lives. That's where our blog is, where you can keep up with news and happenings on important topics as we are continuing to mature the platform. Join us on Slack, we are on the CNCF Slack under hashtag backstack. Come chat with me and the other maintainers. I love picking people's brains as I, by no stretch of imagination, believe in the smartest person in the room. I like chatting to other smart people that are trying to solve similar problems to me. As I said, hop on my GitHub, throw a PR. We need all the help you can get. And finally, if you're going to be at KubeCon 2024 in Paris this year, come chat with some of the maintainers of the projects. Almost all of us are going to be there. We would love to see people in person and have a conversation. Thank you all for listening and have a great day.