Tech Unboxed
Stay ahead of the curve with BBD's Tech Unboxed, the podcast that unpacks the latest trends, innovations, and transformative digital solutions driving tomorrow's world.
Tech Unboxed
The Platform Engineers' Cookbook
Platform engineering is transforming how organizations manage infrastructure by creating standardized "golden paths" that enable developers to self-service their infrastructure needs through a single API.
• Platform engineering emerged as organizations outgrew traditional DevOps approaches
• Kubernetes serves as a universal and extensible cloud-native API, not just a container orchestrator
• Crossplane acts as middleware between developers and cloud providers, enforcing security and governance
• Using the restaurant analogy: developers order from a menu (API) while platform engineers handle the kitchen (infrastructure)
• Compositions in Crossplane are like recipes that combine infrastructure ingredients
• Standardization is crucial for successful platform engineering implementations
• The API-first approach is essential for building scalable internal developer platforms
• Larger organizations with hundreds of engineers benefit most from platform engineering investments
Check out our website to learn more about BBD Cool and how our platform engineering services can help your organization create efficient, standardized infrastructure that empowers your developers.
Welcome to another podcast, bbd Tech Unboxed. My name is Koen, I'm your host and I'm today together with two persons from BBD, andre and Nicholas. Can you both introduce yourself?
Speaker 1:So my name is Andre Stotts. I'm a platform engineer for BBD Cool. For BBD Cool, Our main focus in life is making developers' lives easier by abstracting a lot of the complications of hyperscalers infrastructures In general, we have a. Well, my main focus in life at the moment is specifically Kubernetes. Yeah, Nicholas Cool.
Speaker 3:Nicholas. Hi, my name is Nicholas, or Nick for short, and, just like Andre, I'm also a platform engineer at BBD. I've been working in this space for roughly the past three years now, thoroughly enjoying it, and, yeah, I like playing around with a lot of cool tools that enable us as platform engineers to, like Andre said, make developers' lives easier, and most of these are really tools, like Andrzej said, in the Kubernetes space.
Speaker 2:Oh cool. Would you mind if we step back a little bit and if you could maybe explain to me what do you mean with platform engineering?
Speaker 3:When we think about platform engineering, I think we should really take it back first to how we used to manage infrastructure in the past. So previously there used to be a big, a lot of silos where you had the ops teams people responsible for taking code and deploying that onto on-prem infrastructure. Later on, with the introduction to popular hyperscalers like AWS and Azure, we started seeing the emergence of new ways of deploying our infrastructure, more in a software-oriented way. Tools, ise tools, infrastructures called tools like Terraform and Pulumi started to emerge, and really what these tools enabled organizations to do is put together DevOps infrastructure teams to essentially, in an easy way, deploy their developers' source code onto these cloud infrastructure. Now, really, with the rise of cloud and also the scale at which some organizations are operating, at the amount of different engineering teams, this has actually started to become an issue and the whole DevOps paradigm has really started to break down as the organization starts to grow and more and more specific platforms like AWS and Azure start to get used.
Speaker 3:So, with platform engineering, it's really a term that emerged more than five years ago and what platform engineering aims to do is really to deliver so-called golden paths which platform engineers build, and they are essentially there to enable developers within an organization to self-service themselves.
Speaker 3:So if platform engineering, rather than having DevOps teams perform ticket ops and take care of making user developer requests being output, the platform engineers essentially provide them with a sort of self-service capability so they can request what they want through some sort of portal or interface. Yeah, so that's pretty much what platform engineering is, and platform engineers are another product team within the organization. However, the core distinction is, rather than building a product where, in a traditional software sense, the product is the software that you are providing to end customers of your organization, platform engineers deliver a product where the end users of the product are the developers within the organization of the product are the developers within the organization. So our customers are the developers and that is where we get our requirements from what we have to build and where we get feedback on how to improve our products.
Speaker 2:Yeah, I noticed that both of you in your introduction you mentioned Kubernetes. Where is that coming in and what does that entail?
Speaker 1:So Nicholas has a very, very nice definition of of kubernetes.
Speaker 3:Um, yeah, that he needs to share yeah, so I think, a definition of kubernetes I like to coin or talk about a lot and which I really like to explain. Kubernetes, as is traditionally. When a lot of people who are have an idea of what Kubernetes is, they like to think of Kubernetes as something that runs my containers or orchestrates my containers, but it's really more than that and I think a term that sums up Kubernetes really well in this current state of where it's at, in its, you know, overall software life cycle is a universal and extensible cloud-native API that happens to come with a container orchestrator baked in, and I think that's really crucial because that allows us to think of Kubernetes not as something that runs my container, but really a universally acceptable API standard that everybody can agree upon. And, as a matter of fact, the Kubernetes API is, to date, the only universal API in the whole cloud-native ecosystem that everybody can agree on.
Speaker 2:Yeah, and where does Crossplane come into play then?
Speaker 3:André, do you mind?
Speaker 1:Yeah, so Crossplane comes into play based on the fact that, as Nicholas said, Kubernetes is a hyper-extensible API with a standard, so what cross-planning allows us is to utilize those things. So cross-planning allows us to define resources in the AWS world which might be an instance of database and then make it conform to a standard set of API rules when an end user needs to consume them.
Speaker 1:There's a standard set of rules and he just needs to follow those rules. He does not have to be aware of the specific API layout of AWS or AKS or even of Memstor. He just needs to be aware of the Kubernetes API. It makes it extremely flexible and also easy to transport that knowledge across multiple teams, and that is where Crossplane shines, in a large part because of Kubernetes.
Speaker 3:Yes, and also from that with Andrew just described. It's really from a developer perspective, the fact that the API is one API that they have to communicate with. Obviously, that takes care of abstracting well of the complexities of these high-fidelity APIs offered by, for example, aws or Azure Azure. What a platform engineer is then responsible for doing with Crossplane as their platform orchestrator tool is to develop Crossplane compositions, which are essentially how they tell Crossplane. It's essentially how they configure the logic of the API. So once an instance of an API is created or updated, how does Crossplane take that form of the user's request and translate that into actual, real-world resources in external vendors like, for example, aws?
Speaker 2:Is my reading correct that it almost sounds that there's a lot of empowerment to the developer, almost like a self-service? If this is the case, I'm wondering are you not giving too much freedom? Because how does that actually compensate against security governance rules that you apply as a company?
Speaker 1:So that's one of the most fantastic things about Crossplane, if you look at Crossplane's lifecycle. First of all, we do well-architected golden paths. If a developer needs a database, for example, we've already architected a database setup that is compliant with the company's security and risk profile. A user cannot step out of that. That's one of the main things. And, as Nicholas also will describe now, the end user not. There's no information leakage, so the user does not receive any information that is not pertinent to him.
Speaker 3:Nicholas can describe the old terraform way of of why you also see a lot of information yeah, so traditionally with isc tools like terraform, like Anjo just said, there is domain-level knowledge that gets leaked onto developers when you, for example, create an instance of a Terraform module.
Speaker 3:What I refer to that is that developers are still, in theory, directly interfacing with the hyperscalers as APIs directly. Like we mentioned before, these APIs are high fidelity but they give people the freedom to do pretty much whatever they want, so there's not really any guardrails put on top of those APIs. With Crossplane. What we want is we don't want developers to add all interface with these APIs. What we want is we want Crossplane to be the middleman in front of these cloud vendors and, like André said, these golden paths that have the security and risk profiles baked in to make sure that these building blocks we're building with Crossplane using compositions are compliant within the organization and that they are production ready. That way, developers don't need to go and figure out how to make their infrastructure production ready and compliant. They only create an instance of these custom APIs that are exposed over the Kubernetes API.
Speaker 2:Would you mind to, because there's a lot of jargon in here, and one of the things that stood out for me was that term compositions in cross-plane. What does that actually mean?
Speaker 1:So I think we have to step back a wee bit. Right, we're Going back to platform and engineering and use analogy for it. So if we think of platform engineering as a restaurant, you as the end client don't want to come in and then select your salad, your bread, your sauces, actually have to go to the farmer, get the milk and the bread and all of that. You, as an end client, want to actually walk into a restaurant and get a curated menu for you. That is the role of platform engineering essentially is creating these curated menus for you to be easily consumed. So now we're going to think about compositions At a base level.
Speaker 1:In CrossPen you get things called providers. Providers you can see as the ingredients for my recipe. So if we're making a salad, it might be the salad itself, the sauce on the salad, the tomatoes, the cheese. They are the fundamental building blocks. Then we take a composition. Composition is basically our recipe. It tells us we're going to need so much cheese and we're going to need it in this order and that step to get our final product. That is a good analogy for what a composition actually does. It's a recipe with our base ingredients to get our final product delivered to our client and in your example, the Caesar salad would be the product.
Speaker 2:Yes, yeah, in your example, the Caesar salad would be the product. Yes.
Speaker 3:Yeah, so if we consider the API the API in Crossplane's case, that is, I suppose, of the Kubernetes API we could refer to that as the waiter, the person taking the request Under the hood, the stuff happening in the kitchen, that's the stuff that the platform engineers takes care of configuring, building up the recipes in the kitchen. That's the stuff that the platform engineers takes care of configuring, Building up the recipes in the form of compositions and configuring cross-plane with the providers, the ingredients, like Andre said, to orchestrate the stuff in the external providers like, for example, aws. So yeah, from a developer perspective, the developer is the person coming into the restaurant, looking at the menu, saying they want X, y, z. They make the request to the waiter in this case the API under the hood, the composition and the configurations that the platform engineers have done. In other words, the kitchen staff take care of preparing that and, lo and behold, out comes your requested items.
Speaker 2:Super interesting. I was looking at Hal's kitchen from Gordon Ramsay and obviously in every kitchen and every analogy there's like pitfalls. So what would be the most common pitfalls in a setup that you just explained?
Speaker 3:So I think first thing that I want to mention when it comes to Crossplane is that an organization wanting to adopt it has to consider the initial investment and skill required and able to maintain and operate Crossplane effectively. As we know, crossplane is built on top of Kubernetes and Kubernetes by itself is a beast, is built on top of Kubernetes and Kubernetes by itself is a beast. It does require a lot of experience and skill to run a Kubernetes cluster in production at scale, but also Crossplane as an additional learning curve. So for me, I would say larger organizations with hundreds or even thousands of engineers would benefit from having a platform backed by this orchestrator, in which case we're referring to crossplane just because it's a cloud native tool, um. But if you are an organization of like 10 engineers, um, the investment of adopting crossplane would not be worthwhile because the value add and putting together a team to maintain that isn't going to be justifiable given the size of the organization.
Speaker 3:So that's number one, and I then also think care needs to be taken to make sure that the people maintaining it are well skilled and are trained to be able to run with this sort of setup in a production environment.
Speaker 1:Now using your Hell's Kitchen analysis, one of the pitfalls you see in Hell's Kitchen is generally the lack of standards and the lack of skills in the staffing, which is where Gordon Ramsay comes in and tries to fix everything, standardize it and all that. And that's the same with Crossplane, since Crossplane is immensely malleable it is meant to fit everyone's needs. You sometimes fall into the trap that basically everyone goes off and does their own thing. So the chef or someone thinks he's making a Caesar salad, but meantime it's actually a lasagna.
Speaker 1:Big difference though yeah, so one of the big difference though so one of the key concepts that makes one of the pitfalls, but also to to fix that is, to start standardizing on your implementation of crossplane is deciding on a core, core key concepts that you can apply on crossplane company one. This makes that knowledge sharing as well could becomes a lot easier, since everything is standardized.
Speaker 3:Yeah, I also want to add on that analogy quickly and I want to refer to fast food chains like McDonald's. Let's quickly consider and I heard this the other day when watching a video on YouTube, but a guy was basically saying why is McDonald's so successful? Why do people eat McDonald's if it's not as great as, maybe, making a home-cooked meal themselves or going to a five-star restaurant? Well, number one it's cheap. Number two, it's fast. You get your meal fast, but also it's consistent. That's important. You get a consistent experience. You can go to McDonald's at X location or Y location, but you'll get the same food and you know what you've had is going to meet these sort of statins. You're happy with that.
Speaker 2:Predictability.
Speaker 3:Predictability exactly. You know what you're going to get. So that's why it's so popular. So that's why it's so popular If we consider how McDonald's does things. If you've ever watched the movie the Founder, there's the scene where he's basically they're on a tennis court and they're laying out how they want to structure the restaurant to make sure that the time in which they can pump out you know, food for their customers is as fast as possible. You know the efficiency of the overall kitchen design is as smooth as possible. You know the efficiency of the overall kitchen design is as smooth as possible, such that they can serve their customers at a much faster pace. That is, in a sense, if we had to take into account what platform engineering is trying to do. That's what we're trying to do. We're trying to make our developers get their infrastructure and related services created at a record speed, and that was, if they have this, then the question is yes, they can go to AWS directly and create this stuff, but now they have this McDonald's interface, if I were to call it that.
Speaker 3:That's consistent, that's reliable and they know it works and that's cheap. So they would a lot of people would start using that and, yeah, I think it draws a lot of inspiration from one like the fast food industry, but also even just like the automobile car production industry, Like, for example, how Henry Ford revolutionized the automobile industry with his way of constructing cars at a record pace and selling cars or producing a large amount of cars in a small amount of time.
Speaker 2:Guys, we're almost at the end of this podcast recording and I learned a lot today and I'm wondering if each of you could give like a one tip to the audience. What would that be?
Speaker 1:I would say standardization. It is probably your greatest ally of all times. A good example for that would be actually the Industrial Revolution itself. So one of the greatest things that came out of the Industrial Revolution was the metric and imperial systems for standardization and that created. So if you had a bolt that was broken, you did not have to custom make it, you could just go to the shop and buy it. And that in general is the best advice for platform engineering. It is creating standardization throughout the organization for easily transferring knowledge between people.
Speaker 3:Yeah, yeah, For me I think, like André just said, to add on that, I think it's important for a guy considering a career as a platform engineer to realize that he is building a product and he needs to make his product as easily usable as possible for their customers, which is developers.
Speaker 3:So he has to think of how can a developer use my platform to do his job and get his things requested in the easiest way possible? Now, another thing I want to add is a common pitfall we see with a lot of our clients that are trying to start building internal developer platforms or portals is that they are not trying to follow what is the community has now pretty much coined as the so-called API first approach platform. They are really relying on current trends and tools of basically having IAC tools like Terraform with pipelines fronted by some form of portal, maybe backstage, and really this starts to break down again at scale. Having this API in front of all your external platforms is really the key for building a scalable and secure internal developer platform. So I think anybody that wants to build a platform with an organization always go API first. That's one thing I want to make sure people are aware of.
Speaker 2:Gentlemen, thank you very much for your contribution and all these nice words about platform engineering. Thank you very much, everyone. Stay tuned for more updates in BBD Tech Unboxed.
Speaker 3:Thank you very much, everyone.
Speaker 2:Okay, thanks, thank you.