 Today on the show, we have a founder and CEO, Bassem Tabara of Crossplane. Crossplane is an open source Kubernetes add-on that enable platform teams to assemble infrastructure from multiple vendors. It's a sandbox projects, rocketing towards incubation. I've been a fan of these folks for a long time. Spotlight starts now. Before I bring in Bassem, I just want to do the disclaimer. This is an official live stream of the CNCF, and it's such as a subject to the CNCF code of conduct. Please do not do anything to the chat or questions that would be in violation of that code of conduct. Basically, please be respectful of all. Welcome to Spotlight Live Bassem. How are you? I'm doing well. Thanks for having me, Dan. We've been friends for a while. I've been like, we want to figure out the perfect time to sit down and talk about Crossplane, because you know I've been a fan of y'all because I did a live stream with a Siegdan member, Dan Mangum, and I was like, this project is so fantastic. I was like, I really want to know the background. How did it start? One day you were like, I need to solve the world's infrastructure issues, if you're kind of like, how did you do it? Just talk about that. The Crossplane origin story goes back to probably 2016. I was working on another project then. It was the Rook project that I helped start. If you remember, Rook is essentially a control plane for storage, and it was built on Kubernetes, and it was designed to kind of manage storage infrastructure. And it was so cool, because it was early days. I was looking at kind of Kubernetes and thinking about, this was the year kind of when Kubernetes won the Container Orchestration War, if you remember, and it was kind of starting to emerge as the clear winner. What I saw was not Kubernetes as a container platform. I saw Kubernetes as a generic control plane that could be used in scenarios well beyond containers. And so Rook was a great example of that, because it was a control plane for storage. It was using the Kubernetes control plane, but it was essentially built to manage storage systems. And so I got excited about the whole approach. I saw that this could be... The Kubernetes control plane can be used to manage all things, all things infrastructure and cross-clouds or hybrid or multi-cloud, and then went off and started a company and cross-plane was born at Upbound with a charter of essentially bringing the control plane approach that was pioneered in Kubernetes to the general problem of managing cloud infrastructure. In some ways, you can think of, say, cross-plane as uncontainerizing Kubernetes, which is a silly way of saying it, but it is kind of what we're doing. We're bringing the control plane of Kubernetes to the general problem of managing application and infrastructure. But Sam, do you get this question, though? It's like, wow, so I mean, Kubernetes is complicated enough. I need to have another control plane to control other infrastructure. Do you get that question a lot? Yes, there's a lot of people that, you know, Kubernetes is not known for being simple, but I think if you change the perspective a little bit and think of Kubernetes as not the developer-facing, you know, a platform, but more of a middle layer in between, say, application developers and whatever they consume, whether it's pipelines or consoles or CLIs or however they're doing their work and building their applications. And then you think of Kubernetes as the middle layer that sits between them and the cloud or infrastructure in general. And so in some ways, if you think of Kubernetes as a middle layer, middle layers tend to be complex. They tend to offer a lot of flexibility because people are using them to build their own kind of opinionated platforms and other things on top. And so, yeah, I share the sentiment, but I also think it's a matter of perspective. Understood, so for everybody who's just joining us, again, I have Bassam Tabarra. He's the CEO and founder of Crossplane and we're just going through the motions. I'm gonna ask you this. Love the logo, the ice cream. Look, I mean, you know, like we all love ice cream and we all love icicles. Tell me, explain the logo. Can we talk about Crossplane's logo? So credit for the logo goes to our designer, Matt Heilman. And to be quite honest, I was kind of against it. I, just to be, but the idea was, you know, so we picked the name Crossplane among many other choices that were there. Someday I'll tell you about how many domain names and GitHub organizations I'm hoarding. But so we landed on Crossplane and it was essentially a play on the, both the word CrossCloud and Controlplane. And so we were kind of trying to go for a name that becomes a noun or, you know, you could say, hey, look, I brought in a Crossplane and I connected it up to AWS. And I don't know if that's stuck that way, but that was the intention of that you can basically drop Crossplane anywhere you're using the word Controlplane. And so the Popsicle came kind of fall off that thinking, which is, you know, if it's CrossCloud, then you need, we were looking for something that had multi-flavor in it, multi-cloud, multi-things. And so we ended up with, and we wanted something that was playful. And I think that the idea was, hey, what if it was a multi-flavor, multi-colored Popsicle, every lost Popsicles. So, and so there is your multi-flavored Popsicle and that's how we landed on it. You should see that. I think it was preordained that we would have this interview. I'll provide the alternatives. So, you know, one day we can look at those, but... It was preordained that we'd have this because you had a Popsicle, now you're on Popsc Spotlight Live, you see how it goes? It's all circular, right? It's all circular. There we go. Yeah, it was fate. Yep, it was fate. So Carlos Bernardo asked that question. You nailed it. You got that one out there. And also we have our friend, which by the way, I could spend an hour just talking about Hashtan. That guy, like you, I'm sorry. That guy, you could build 10 companies around that dude. So Kudos to Hashtan. We love Dan. Not a doubt. So let's go back to, again, you're at Ruck and there's this original problem you're trying to solve. And it was like, what are we doing? Like I wanna start a company because I don't wanna have to deal with this shit anymore. Pardon my French, let's go. Yeah, so look, once you get exposed to how control planes kind of help simplify and automate a ton of the toil that we deal with as operations engineers and cloud engineers in general, I mean, you see it. Like when you cube CTL apply and you say, okay, Kubernetes, please run three replicas of this container for me, right? You give it this declarative statement and then Kubernetes goes off and makes sure there are three replicas of the container running. If a node goes away, if a node comes back, it's still managing that on your behalf, you don't have to get involved. If a node goes down that was running one of your replicas, it'll restart it somewhere else. That logic, that approach motivated us to kind of start crossplane and so that we can bring that approach to all of cloud infrastructure and not just containers, right? Like when you want to kind of light up infrastructure, say in AWS, right? You should be able to, in the same way, cube CTL apply it, apply the change and then let the control plane from that point on where to handle the deployment, the provisioning, the scaling, the lifecycle management, handle all of it. That should be an autonomous process and it should be something that humans don't have to get involved in. And so once we saw that happening in the Kubernetes space, we got motivated to kind of say, well, can we bring that, can that be the new way that we manage infrastructure in the cloud? And ironically, like the thing people don't realize, but that's literally how the largest platforms in the world are built. If you peek behind the scenes in AWS, that who are, when you ask for an S3 bucket, what's the entity behind the scenes that's serving that API, that's taking that request, that's deploying, allocating a bucket and essentially allocating to you, doing all the billing, doing all the metering around it, it's the control plane in AWS. Everything in most large cloud providers, everything is split between control plane and data plane. And it was time to bring that approach to kind of to become mainstream in everything that we're doing in the open source community and in enterprises at a large. One of the things, like I said, I did that live stream at Hashtag and he kind of showed me what was going on. I played with it and I'm like, this is incredible. Cause it was before I was like, okay, I go to my cloud information scripts, I would do all these things together. I didn't have to put my applications on top of it. And I'm like, this is great. But like one of the things that here is, okay, why would I use this over say like a Terraform or like Cloudbolt or something like that? Why would I use a cross plane or up bound over other tools? Yeah, it might be useful to kind of just kind of review the differences between the approaches. And so Terraform is in the class of tooling that are commonly referred to as infrastructure as code, right? And infrastructure as code tooling is amazing. Like it's Terraform as well is fantastic and widely adopted project, right? But if you think about the problem being solved there, it was how do we arrive at a declarative configuration that we can reproduce easily reproduce, right? It's designed for a human operator to run. So you're basically saying, look, I wanna describe my infrastructure. I author it as a configuration. Typically it's a domain specific language like HCL or more popular these days are traditional programming languages, Python, TypeScript, et cetera, right? But what I'm doing is I'm authoring a declarative configuration of a set of infrastructure. The design point is that once you have that configuration, you as a human get to apply it, whether it's TF apply or it's run a program, you the human are applying the configuration and you as a human are looking at the diff of what changes are to be made in your cloud provider. And so you're approving these changes and you apply it and at that point, infrastructure is lit up and the tools out of the way, right? And if you wanna make additional changes, you have to come back, edit the configuration, apply, potentially deal with drift and then changes happen, you approve them. It's designed to be a human workflow all the way to applying and lighting up infrastructure. Control Planes work differently. Control Planes, first of all, they serve not a, you can author things in templates or configuration like YAML or you can also do that and whatever, pick your tooling of choice. But the first primary difference is that you, once you author these things, you're interacting with an API. There's an API that represents every resource that you want to configure, deploy, manage, right? Versus, so the interaction is, you're talking to restful endpoints to create the configuration. You're not just authoring the configuration in a template and then invoking and applying the tool. But the more interesting scenarios come in when the human workflows end when you apply the configuration to Control Planes, you're out of the way. You don't have to sit and wait for it to come up or manage the order in which it comes up. Or if you have a scale act or an upgrade act, that can be done autonomously by a set of robots, controllers that are running inside the Control Plan. So the workflow becomes, you as humans collaborate on configuration, whether it's Git, GitOps is a popular term these days. The human workflow ends as soon as you hand it over to the Control Plan. And from that point onwards, the Control Plan is autonomously making changes, applying changes in order. When things go down, it's able to reconcile them and essentially bring up infrastructure and fix it. That is a fundamental difference between infrastructure as code tooling and Control Planes. And so back to your original question. Why would I use this over Terraform? Honestly, it comes down to a few things. One, you can achieve a much higher degree of automation with Control Planes than you can with any infrastructure as code tooling. It's that simple because you're running autonomous controllers. The other is one that's less obvious is that you can actually organize around Control Planes because the unit that they expose is an API. And so you can consume APIs from any tool, any framework, any language. Look at the healthy ecosystem built around the Kubernetes API. It's unbelievable how many tools and consoles and UI and pipelines that have built and taught Kubernetes API on the back end, right? Compare that to any of the popular infrastructure as code tooling and look at the ecosystem around them, right? APIs promote a larger ecosystem. APIs promote organizational boundaries that enable teams to scale. And so, and they come with access control and they come with all sorts of other benefits, but those are the primary reasons I would think of when making a choice between using infrastructure as code tooling and Control Planes. One other thing I'd say that comes up especially in the cloud native world, if you've already adopted Kubernetes and you're running Kubernetes, there is much less friction to use something like crossplane than to figure out how to shell out to some external process and run multiple pipelines and figure out, you know, run infrastructure as code tooling and light up one part of it and bring credentials back and stuff them into secrets. And you can avoid all of that by letting your developer self-service on infrastructure using the same tooling and pipelines and, you know, that they're used to and using today with Kubernetes. That part makes the whole process frictionless. Fantastic. And again, I mean, if I was a TLDR, it's just the, you know, it's a Control Plan over a tool. You have all the, you know, the aspects of that, the authorization, all that that you can bind into, you know, and that's fantastic. And you're touching the APIs directly. You have a question from Carlos Panado. It's a new guy. I've heard of him once a couple of times. Is it possible to import existing infrastructure to crossplane? Yes, it is possible. So every managed resource in crossplane has a notion of an external identity and you could use that to adopt existing resources. We're actually looking into, and we mentioned hashed down earlier, but we're looking into a set of tooling that actually makes that a lot easier so that you can go directly to a account and say AWS and then generate and adopt the resources that are already running there as part of crossplane. And so there are lots of, lots more things happening there, but today, yes, you can adopt existing resources and into a crossplane environment. You mentioned hashed down, of course, he came in. He has a question. Can you talk a bit about the permission model of crossplane maybe compare and contrast with IAC tools? Yeah, so one of the things that is a fundamental difference is that every resource, think of S3 buckets and RDS instances and EC2 instances that all of the resources that are exposed by say cloud providers get their own API endpoints in crossplane. So you can go to a crossplane, you can say, apply a change to light up an RDS instance and you're talking directly to that one restful endpoint. So the beauty of that, it means is that you can now do access control at a resource level, not at a workspace or template or program level. You bet you're able to say team A can deploy RDS instances and team B can deploy EC2 instances. And you can even change your mind about access control without having to change any of the configurations that you have in place. And so it becomes a lot easier to support multiple teams with different separation of concerns or dev sec ops versus dev ops or all within one control plane and set the access control policies and do so without having to artificially put things into smaller modules or have to refactor everything as you change access control. And so that's a power of being in a control plane that you don't see in most other infrastructure as code tooling that where they primarily the unit of access control is an entire workspace or an entire program. And that's a pretty important difference. Awesome. I have a question, but before we get to that you all, if you haven't already, please go ahead and click that follow over there in the top and subscribe to Cloud Native TV on Twitch. We're always looking to subscribe here. You're gonna see a lot of amazing shows just like this and we try to do this all week, but this is for the community inspired the community. So I have a question. Is there like a time where you were like, wow, somebody took the technology we built and they did something so awesome, like your mind was blown. Let's talk about that. There's a lot of actually interesting uses just yesterday. Besides working with Dan every single day and seeing whenever that guy comes up with it. I have to say we have a fantastic team at up end. So I'm like, every day I'm wowed by all the things that we're doing around cross-line and everything else. But the more general question kind of community wise, I think so a project like Cross-Bridge is very central. You have to build a lot of providers and integrations to connect it to different things, right? And so like every day we see or every week we see another integration into cross-line that puts it to use in a domain that we haven't necessarily thought about or in an approach that we haven't thought about. Like just yesterday, there was this massive blog that came out from AWS on integrating Spinnaker with cross-plane to essentially let the whole Spinnaker users now start deploying infrastructure directly from their existing pipelines, which is what a fantastic use case, right? It's like, if you're using Spinnaker, you're happy with Spinnaker, you can now use it to deploy infrastructure and let your team self-service from the same pipelines they're using. More and more of this you'll see, we're seeing on a daily and a weekly basis around the cross-band community. One of the folks that we know is kind of deploying cross-band production, like they're using it in a lot of financial context, we're seeing it applied in all sorts of different segments of the industry. And it's just super exciting to see the adoption, super exciting to see how people are integrating it as a centerpiece of their modernization effort. It's fantastic. And again, because of that easy use, because it's able to touch so many different things at the API level, I just, that's why when he showed it to me originally, I'm like, right now it's amazing. And this was like six months ago or six to eight months ago, it's incredible. We have another question. And what about integration with modern tools like Datadog or Prometheus or anything like that? So there's two things that I think of here. One is does cross-band itself exposes a set of telemetry and tracing that could be used by a lot of tools for cross-band itself. And I think the other way to think about this can cross-plane be used to automate, monitoring systems like Prometheus and Datadog. And I think that would require a provider for Datadog, which I don't believe exists, although I've heard rumors that somebody's working on one. If you use like some of the native primitives of like Prometheus and stuff like that, I think that you originally were outputting to like, just regular like, cube system level logging and all of that kind of stuff. Because I remember I was able to get Sysdig to be able to get some of the data out of it when we were working through it. So I think it's infinitely possible. It's also, again, it's modular. We support a bunch of that today. So you can actually integrate cross-band telemetry into your Prometheus systems and others. There's a question here from Borco. And it's basically, what cloud providers are supported at present one particular cloud better supported currently or is it pretty equal among the providers? Very good question. So we support AWS, we support Azure, we support Google, we support Alibaba cloud and IBM cloud. Those are the kind of providers that are out there today and obviously more of our Equinex is another one that I think has support today and they're more coming. It brings up a really interesting point because like when you think of cross-band for it to be used everywhere, we have to have a provider for every infrastructure vendor out there. And so there are really two ways we're approaching this problem as a community. One, we welcome contributions, we work with the vendors directly, we have a great relationship with the cloud providers and we work with them on generating cross-band providers from their back-end infrastructure. So for example, we're doing this with Amazon and we have a project together that essentially generates a cross-band resources directly from their back-end Go SDKs, right? And we support that effort and it works really well. So it's gonna take time to get to full coverage and we're working on accelerating that as a community but it's also gonna take a village, right? To bring all the missing resources and try to get to 100% coverage of every infrastructure vendor out there, right? The other approach that we've invested in and we're gonna see us do a lot more to kind of get more bootstrapped here is we're wrapping Terraform providers and bringing them into the control plane. And so that's an effort that we started last year. That's how we actually do the VMware provider, vSphere provider today is you can wrap the Terraform provider, not the Terraform engine. So you're not stuck to using infrastructure as code tooling but just the provider itself and then bringing it into the cross-plane control plane and it looks like native CRDs and controllers for them and you don't have to do anything with Terraform. And so with that approach, we think we can get to fuller coverage sooner while still investing in native providers and you'd be able to swap them out in future. One of the things I thought was cool, let's talk about that VMware provider because I remember when they're kind of somewhat kicked off, it was like a Twitter, somebody that said, hey, we wanted to do this and everybody hopped on it. That's the beauty of the community, y'all. It was like, hey, we wanna do this, cross-plane put this out there and then like everybody, some VMware people will jump in and that provider was out there within a week. That's right. And this is the beauty of working with open source projects and especially ones that fall in open governance model like cross-plane and Kubernetes itself. Like there is, you know, when you build something, it's available for everyone to use. Anyone can become a maintainer. There's a ladder level that you can, you know, through based on your- Can we talk about that, Basim? Let's talk about those first thing. How does somebody get involved in just contributing to cross-plane? Like, thank you. Oh, the simplest way is to join our Slack channel slack.cross-plane.io. You can, it's a very friendly community. There are probably 3,000 people now in the Slack workspace. We can help you get started on contributing, whether it's documentation or all the way to writing a provider in cross-plane. And we document, we have a, you know, go to the cross-plane repo governance.md describes the process for how you become a maintainer or even a steering committee member. Again, the project is hosted by the CNCF. It follows an open source model. It follows an open governance model. It's designed, it's by design, you know, for the community, by the people, for the people type project. And it's fitting because it's so central and you, if you're, if we're gonna arrive at, essentially, you know, a control plane that connects to everything, it can't be, that control plane can't be necessarily tied to one vendor or one platform or one company, right? It has to be, it has to be something that we as a community rally around. We put all our effort around and then we arrive at something that is much larger than the sum, much larger than the individual pieces but is much stronger project for it. I just remember like when Autopilot came out, you all had a, you know, a provider in there like in like a day. It was incredible. Even Kelsey was like, hey, you know, within the day you all had it. So that's exactly what you just said because it's just open enough for people to contribute and all that. Let me ask you this. What's the difference? I see an up bound in the, what's the difference between up bound and cross plane just so folks understand the differences? So up bound is the company behind cross plane. We started the project. We donated it to the CNCF and we offer a set of commercial offerings around cross plane. So starting with a downstream distribution of cross plane which by itself is also open source. It's called up bound universal cross plane UXB and then up on cloud, which is a management layer that gives you a single point of control to, you know, essentially all your infrastructure and gives you visibility on what your teams are doing and the up on registry, which is a free offering and is a library for, you know, cross plane providers and configurations. And so we, you know, think of up bound as helping enterprises that are adopting cross plane accelerate time to market. We help them, you know, be successful quicker with control planes. And typically they come to us and say help us get this control plane technology deployed into our environments, help us scale it, help us, you know, be the vendor that we want to rely on. And that's kind of what up bound does around this. Obviously, having started the project we have a lot of folks that work on cross plane. But, you know, there are lots of other companies now and maintainers from all different parts of the industry that are part of it as well. So Basam, let's talk about what's next. So I know, again, we're in the incubation process. You know, I think I was the first one on the PR. I was like plus one, this is awesome. Yeah, you know, I wish they get it tomorrow. It's just fantastic. So, you know, good luck with that process. Thank you. What's next? So on the cross plane side, obviously getting to incubation the vote is imminent. We're at about the kickoff publicly. And the other thing that's happening is that we created a conformance program around cross plane that also is still subject to a vote on the CNCF side. But the idea there was to, you know, enable folks to when they're building providers to ensure that there's consistency across them and that you can become a certified provider for cross plane or a certified distribution of cross plane just like up bounds UXB. And so that effort we think will help bootstrap and accelerate the adoption of cross plane and the ecosystem around it. In terms of a roadmap on cross plane, lots of interesting things coming. We're actually definitely looking into Terraform, supporting more of a Terraform providers and even Terraform migration scenarios that a lot of people are asking for. So you'll see more of that in the future releases. And actually there's a live stream on Monday, on the 12th, around the whole Terraform thing. And then- Where can they see that? Is that, they go to cross plane IO, there's details for that? I believe it's on, we'll put the link on. It's a live stream on YouTube. Oh, okay, got it. It'll be part of our cross plane channel on YouTube as well. So- Got it. And then, so that's, and we're looking at improving composition and all the cool things we're doing around letting people kind of compose infrastructure and expose it, both in terms of the developer experience around it. So it can make it easier for people to kind of author compositions, but also the flexibility and support that's in it. So you'll see more happening in that space as well. And then accelerating provider coverage. So you've heard me talk about this. It's one of our biggest challenges and it's something that we are putting a ton of effort around. On the up bound side, obviously there is a lot of really cool features as well around UXB and up bound cloud. And, but we're mostly focusing on right now trying to get folks to production quicker with cross plane. And I should correct, the live stream is actually today, it's less than an hour. So it's like literally back to back where there'll be an awesome live stream on Terraform from Nick and Victor. Heavy weights, which is like, you all tune in there. So again, if you go to like their YouTube or you can go to crossplane IO or you can go to crossplane underscore IO for their Twitter, it'll have the details for that. Well, Basam, I really appreciate you being on the show today. We tackled a lot of stuff today. Is there any last words you got? It takes a village, so please come join us on the crossplane slack. Again, lots of really interesting things happening in this project. If you're looking for a project to start with or kind of get into open source with, crossplane is a fantastic place to do that. So we welcome everyone in the community to come play with it, contribute, use it. Awesome. Well, thank you so much for being on Spotlight Live. Thanks, Daniel. I really appreciate it. Thanks. No worries. All right, everyone. So again, super fan of crossplane. I'm so happy I got to talk to Basam. So we got, I'll just tell you about the next week. So I'm gonna be off next week. Every two weeks, I'm gonna be off next week. Solid State starts up on Monday with Tim Banks. Again, if you are watching the show, you need to. I mean, it's just great because he's getting underrepresented folks on talking about their journeys. It's great. Cloud Native Latinx, again, Leonardo. It's just a bunch of Latinx folks that are in the community doing great things. You all should definitely check that out. I think that's on Tuesday. Cat's back with Cloud Native Classroom and there's just a bunch of stuff next week. So we had a little lull since the holiday, but then we're coming back strong. Appreciate all of you for following us. Tell everybody about this, everyone. Just go tell everybody about Cloud Native and Cloud Native.TV. Last thing I'll talk about is registration for KubeCon and Cloud NativeCon North America is open and in person. Just make sure you're checking out that and if you haven't registered, please go ahead and register. Lastly, and I'll get a hope to see you all there. I really wanna give you all hugs if that's okay. At some point, just say hello to you all and just remember community to spotlight is on you.