 Hello friends from the future! We'd hope to be with you in person for this, but today is not that day. Future versions of us, current day, to those of you watching live, can be found in the chat. We'd offer to answer questions there, though it's more likely that we'll have questions for you, as until a few weeks ago, neither of us had touched cross-plane. And us is... I'm Jeremy Tanner, and I'm joined by... I'm John Luca, and yeah, I never used cross-plane before, so we took a full week of testing, and that's where we are, so feel free to send any questions to us. Yeah, or we'll have questions for you. So, what is cross-plane, Jeremy? Cross-plane? It's right there in the name. Cross-plane is meant to be a cross-cloud control plane. Cross-cloud, so this is for folks who are wanting to do a multi-cloud. The description is, an open-source Kubernetes add-on enables platform teams to assemble infrastructure, multiple vendors, high-level service APIs, application teams, without having to write any code. Being a Kubernetes add-on, it's a Kubernetes system. So, you know this, as cross-plane community day is happening attached to KubeCon, it's very likely that you have some Kubernetes familiarity. And, I mean, if I'm not a cloud provider or a cross-cloud provider person, I'm just using AWS or GCP or Equinix Metal. Can I still benefit from cross-plane or not? Do you need it? No. Is it useful? It can be. Instead of orchestrating the same service across multiple clouds, you could be orchestrating many services inside the same cloud. Some clouds have as many, you know, more than 100 different services. And so, building those Legos together manually instead of by configuration cannot take time. And so, there's still benefit if you're inside a single cloud. So, I want to tell you something. I learned Solstack, Chef, Puppet, and I tried Pulumi. I know what Terraform is, and I also wrote not one, but two cluster API infrastructure provider. So, why is cross-plane different and why I have to learn it as well? You don't have to learn it as well, but it can be very useful. So, cluster API is looking to get Kubernetes running. Cross-plane doesn't necessarily have to be Kubernetes that's running. It can be pretty much anything on the infrastructure that you bring up. Terraform and Pulumi, they create and destroy resources only when they're applied or run. Oftentimes, that's just the one-shot when you're starting up or a rerun when you've changed something. Let me summarize. It works as Kubernetes works for pods. So, when you create a deployment or a replica set, when a pod expires something, a control loop creates my pod again, and cross-plane makes that to happen for way more resources across cloud provider, like S3 buckets or AC2 instances or whatever. And a provider can be anything that has an API that has the provider written for it. So, that can order you a pizza every time it's run or anything with an API. That's a very great use case for having a short cool time. So, I want a pizza every 10 seconds. That's how it's going to work. And you tell me that I don't need to know code much, but what does it mean? Okay, well, the claim was without having to write any code. And then I suppose the debate then is YAML code. And so, I think we fell on. It's serialized data, which isn't necessarily code, but you are going to have to write some YAML. But you're not going to have to write a custom operator, which is definitely something. There's already providers written for most of the infrastructure providers that you'd like to use. And so, I'll label this one mostly true, mostly true. And paste skills here. So, yeah, something cool about infrastructure as data versus infrastructure as code that made me think when I saw these lights, that Jeremy, obviously, you did, is because it's cool because the state where you start from is the one that you declared has to do with POD. But it's calculated because it looks for the difference between what you declared. So, I want, you know, ACQ or I want a pizza and what you actually have. So, did I already get my pizza or not? If not, the reconciliation loop will kick it, will kick the request and send me a pizza or recreate a resource that it's over. So, it's a very nice differentiation to do that I think you made here. Absolutely. So, yeah, I mean, everybody speaks about GitOps and I want to know if I can push my YAML code somewhere. Oh, and so absolutely, there are continuous delivery tools like the Argo project that are Kubernetes operators using the Kubernetes API. And so, yes, works perfectly well. So, the way that you'd be managing containers and the rest of Kubernetes can now manage any sort of infrastructure, networks, machines, storage and the rest. So, what is cool is that it use operators so everything that is in the Kubernetes lands works with cross-plane as well. So, that's very important. But what if I'm not running Kubernetes? What should I do? Ooh, not running as in you don't use Kubernetes? That's going to be super odd if you're a KubeCon attendee, but I'll allow it. Thank you. It's maybe not the tool for you. Not running as in you don't have a management cluster running? Perfect. Upbound, who are the creators of cross-plane? They'll run one for you. That's cool. But yeah, what do, how I can start with cross-plane? Yeah, yeah. So, to get started, you can either use upbound or if you like doing things like us, the hard way, you'll need some Kubernetes. So, Kubernetes and Docker is fine. Just remember to start Docker if you, like me, occasionally kill it to keep your laptop fans from taking off the desk. That Kubernetes in Docker, you can brew install, kind, KubeCuttle and Helm. If you're not using the hosted version, once you have these, you'll install cross-plane via Helm chart into your management cluster. And then you'll take a configuration and configurations are just the setup of the app or the setup of the infrastructure that you'd like cross-plane to bring up. And those will be associated with a provider. And so providers being Equinix Metal, AWS, GCP, Azure that are places where you've given them a credit card, gotten in return, an API key, and are then able to bring up infrastructure. And so, you told me that cross-plane will always do its best to keep my resources as I want. Exactly. That was the thing that surprised me. So the thing to watch out for is to beware of zombies, like the things that you kill don't stay dead. And so if you don't destroy the resources in the right way, they'll come back in around 30 seconds. And so if you create a machine with cross-plane and then destroy it via directly using the API or if you destroy it inside a dashboard, it will pop back up because you have a spec that says I'd like this machine to exist. Cross-plane will notice it not existing and bring it back. So resources forged in the fires of cross-plane can only be destroyed in the fires of cross-plane. So there is no resiliency without control loop in this time. So but what's next Jeremy? What are the cross-plane people working on? We got up to speed using mostly links from cross-plane.io. That's an excellent resource. We definitely have more questions. And so I'm curious how I might bring resources I've created elsewhere on those providers under cross-plane's control. And so if you have a good idea how to do that, please hit us up on the Slack. Or if you think answering many more questions would be fun and you'd like to get paid to teach myself, John Luca and other friends about cross-plane upbound is hiring a developer advocate right now. And so reach out to them. So I think that's it. No more questions for us Jeremy. Yeah, yeah. I'd like to thank everyone for watching. We appreciate your time and attention. And additional thanks to Marcus Johansson from my team for clearing up some of the concepts. And also to the video recorded version of Dan who is a wellspring of information on the cross-plane project.