 Hello, everybody. Welcome to another episode of Cloud Native Live. My name is Mario Loria. I am here with Victor Farsik, and this is a really, really special episode for me. It's going to be my last episode, possibly indefinitely. I don't know. We'll see what next year brings. I'm going to take the fall and soak up the amazing KubeCon that we have coming before us, KubeCon North America and Cloud Native Con. But thank you so much for taking the time today and joining us. Victor and UpBound, especially the cross-plane project is probably one of my favorite projects in the Cloud Native ecosystem because of the focus on shifting left the developer experience and giving more autonomy to developers to provision and handle infrastructure components that they need and depend on, and taking more off-investories. I could talk about cross-plane all day, but that's not what we're here for. Victor is here as a freshly minted advocate for UpBound, the company behind cross-plane. If you don't know what cross-plane is, the one sentence is, you can provision infrastructure with Kubernetes YAML. That's the very thin that you should definitely go to the documentation cross-plane.io. Victor, I know him as a very, very huge member and advocate for the entire Cloud Native community. I was listening to him the other day while exercising for his DevOps Paradox podcast, which he has some great guests on and talks about some really awesome technical and more high-level, maybe even leadership components as well in the industry. Victor is one of my favorite people. I'm so glad to have him today. Without further ado, here's Victor Farsik to introduce and bring us compositions on cross-plane. Thank you. That was so much surprised that my face is starting to get red. That's okay. I'll plan to interrupt you plenty and make your face even red a little later on with my dumb questions. One last thing to audience, please leave in your platformer choice, leave any questions and comments and thoughts on what Victor's talking about today or cross-plane, and I'll stop him and try to have him answer those for you. That would be really awesome. If we can make this interactive instead of me just talking, talking, talking, that would be absolutely awesome. The more you interrupt me, the better. So you already heard the interaction. My name is Victor, I work for a bound with a company behind cross-plane and a few other things, but today's subject is cross-plane. If you're not familiar with cross-plane, the explanation that Mario just gave is essentially correct. It is a way to manage infrastructure from inside Kubernetes. You might be asking, okay, so what is the benefit of that? Why is that better than whichever other tool you might be used to manage infrastructure? The answer is relatively simple, and that is Cloud-native and Kubernetes ecosystem. Almost everything that is happening right now today in an industry is somehow levitating around Kubernetes. That means that if you're managing something, whatever that something is, doesn't matter whether it's applications or infrastructure, this and that. If you do that through Kubernetes, then you get basically out of the box certain features or certain benefits that either do not exist or are hard to accomplish outside. You have automatic reconciliation and drift detection, high availability, and this is my favorite. A single API to manage everything basically. Usually when people talk about Kubernetes, the first association is, hey, I can run containers. My first association is, I have an API that I can use to do whatever I need to do. The top of all the features that everybody knows and loves in Kubernetes, there is the ecosystem. I'm really not talking in general, even though that flows into cross-plane, hey, if you would like to manage your stuff using GitHub's principles, yes, there are tools and they happen, most of them to be Kubernetes-based. If you want monitoring, again, Kubernetes. If you want service mesh, again, Kubernetes. For us, it was very important that the tool that we are building, which is essentially and mostly focused on infrastructure and services. It's hard even to distinguish what is a service, what is infrastructure anyways. Infrastructure and services, that something is done in the Kubernetes-native base, so that we can leverage Kubernetes schedulers, that we can leverage the control, plane, ecosystem, and all the stuff that we learn to love and we are all adopting. Now, on top of those goals, for us, it is very important the idea that we can shift left the workloads, or to put it in other words, that we can enable almost everybody to do almost everything. There are many, depending on the aspect of what we are enabling, there are many different projects and cross-plane falls into that category when we are talking about infrastructure. In general, when we speak about those things, usually either we get something flexible that is hard to understand by everybody, but a few specialized people in that something, or we get something opinionated that is great. Hey, you can pick it up after the box and everybody can use it. As long as that opinionated something fits into what you're doing, which more often than not doesn't too. We are trying to accomplish actually both goals. What I mean by that is something that is extremely flexible for CIS admins, of Ressarys, of DevOps, and I don't know anymore how people call themselves these days, but people who manage infrastructure and services. Instead of having an opinionated tool that could be adopted by everybody, we want to enable those experts, let's say, to create opinions for the rest of the people in that company. We do that with what we call composites. In a way, you can use cross-plane directly and define YAML manifest, and I will show you that in a few seconds, that through which you define your infrastructure, cluster, networking, database, whatever you're having, or you can create a composite that says, hey, I need all these. All those things are unavoidable. I need all those 500 different resources in AWS, for example, but I'm going to also create an interface that will be consumable by others, and greatly simplify how those others are consuming what I created. That's the whole story about, that's the main idea behind composites. I think it works really quick. What you're saying is, as we go on this journey to self-service more intuitive UX-driven products that anybody can use, like you said, and I think about it as, instead of everything being encapsulated in the SRE team, and they have to do this, and they're your dependency, they're your blocker, they have to allow you to do things, or do things for you, you now have control of do that. What you're saying is compositions extends that even further, and actually helps you abstract away that complexity in more of a maybe a templatized version, maybe think of a base common helm chart or something like that. For these compositions and things that you want to provision, or that maybe all your Django services need a database of a certain type or something like that, right? Yeah, so think of it as SREs creating a helm chart, and everybody in the company having freedom to fine tune that helm chart through helm values, right? And, but that team does not necessarily want to deal with all the complexities of everything they find in charts. Chart is kind of, somebody's in charge of creating that chart, and you are tweaking, you have the level of freedom that you need through the, through the helm values, right? Except that we are not talking about helm charts, but the idea is somehow similar that somebody can package. So think of, let's say that your company consumes AWS to say something, and your developers want to use AWS. Now your developers are not going to create VPCs or something that's in the gateway and all those things, but also they do not want to open a general ticket every time every single detail is needed, so that you do it for them. And you probably don't want to do it yourself either, because in my head at least, the job of an SRE or whatever the title is, is not really to fulfill the requests of others, but to create tooling that enables the others to manage everything in a way that is agreed in a way, or simplified to the level that does not provide freedom without complexity that is not understood in a way. Right, that's the clincher right there. That is the statement of the year. That is what SRE teams should be about. They should not turn into, I like to say glorified support teams, they're more so teams that are blockers and dependencies in getting things done in shipping. We should instead build the tooling to automate and provide more power, more flexibility, more metrics to the people that actually own the services, i.e. the coders, the service owners, the developers. So really quick, we have, I think Ahmet who said, hi Victor, following your YouTube closely, great content, got your post on Udemy as well, but it's a bit outdated now. I think that's a call out on you, Victor. You gotta keep those updated. Come on, give us the latest and greatest content. So the reason why it's not outdated is because when you make a course that is like 10 hours long, it takes a year to create it and by the time you can publish, it's deprecated. So I switch to YouTube shorter, shorter kind of like shorter model, and it's up to date now. For sure, keep on that YouTube, Victor. And Ahmet mentioned too, can you talk about how to approach generally having a dev staging production workflows in the same cluster? I'm gonna, let's put that on the table for now, Victor. I want you to get into compositions and we can maybe circle back to what these kind of disparate environments and how these changes that you're trying to test can then bounce through and graduate to production. So I'll shut up. Sounds great. Shall we switch it to a demo? And see it in action instead of me talking, talking, talking. Yeah, okay, I see, there's the screen, right? So let me first show you how I would use cross-plane to manage infrastructure without compositions, right? Directly me with cross-plane without having any SRE or any CS admin or any infrastructure person in between. And it could look something like this. For example, if I would like create a GK cluster with cross-plane, I would create it as a, I would define it as a set of Kubernetes resources, just like anything else in Kubernetes. This is Kubernetes custom resource definitions. And in this case, I would say, hey, I want the GKE cluster. This is the name of the cluster. This is where it's going to run. This is the version that I want of that cluster and I will create a node pool in certain locations. That node pool will be referencing the cluster. So basically it becomes a node pool of that cluster and a few other things like preemptible, machine type, auto-scaling and all the stuff that we all like, right? So this is equivalent to how you would do things with other tools, except that this is YAML and these are Kubernetes resources instead of being whatever else you might be used to. So we are basically assuming that Kubernetes, that you or the potential user has adopted Kubernetes API is the de facto standard to do whatever needs to be done or to be more precise to define the state of whatever is needed through it. So I have that definition. This is essentially simple. I will show you more complex definitions in a second. In a real-world situation, you would not have only those two. You would have a bunch of other things because it looks easy when you create, let's say a Kubernetes cluster using console, click, click, click, but realistically, there are many other things that we need there. But to be starting simple, right? So if I would want to create that, I would do something like this. This is just like with any Kubernetes type of resource. I'm going to apply it, file name is going to be GKE YAML and off we go. Now, nothing here just happened for a simple reason because before I came to this session, I already applied this resource to speed things up. So instead of you waiting for, I think it takes like six, seven minutes until a cluster is creating a GKE. But what I can do is basically, now since those are Kubernetes resources and not some random stuff, I can do other Kubernetes stuff that I normally do, like, hey, get managed, which is a shortcut to get all the many resources managed by crossplane. And here you can see, yes, just like querying pods or deployment or anything else. Yes, I have GKE cluster definition being applied in my Kubernetes cluster. Let's say that we are talking about two clusters now, control plane cluster where I'm running crossplane in a cluster that I have to do. And I have a node pool, I can see the statuses, they're all ready, they're all synced, they're all running, and so on and so forth, right? Now, the thing with that one is that those definitions tend to be complex, right? Not because crossplane is complex or it's not complex, but simply because there's a lot of things that we need to think about when creating infrastructure. And if you want to shift left to enable everybody else in an organization to self-manage, we need to reduce that complexity, but we need to do it in a way that we cannot just buy something off the shelf, reduce complexity, because that would not take into account all the special things that everybody has in a company. But the whole idea is that we can use definitions similar like what I showed you, the GKE YAML, and create compositions and then simplify everything else for everybody. And that simplification can look like this. So this is something that, sorry, wrong one. This is something that developer or anybody else, vast majority, 99% of the people in a company would consume. And this would be something called, in this case, composite Kubernetes cluster. So this is a custom resource that I as SRE defined for everybody who wants to use, who wants to manage Kubernetes clusters in my company, in my organization. And there are a couple of interesting things here. To begin with, I can specify the name of the composition. So in this case, the name is cluster Google, but I also created the implementation of the composition for cluster in AWS, cluster in Azure, GaliBaba, wherever, right? So a potential consumer, the end user of this can just go and pick wherever they want cluster to be created without really knowing the details about that specific platform. And then there are a couple of parameters that my end users can use. There is a size of the nodes version and the minimum number of nodes. Now for the size of the nodes, the values you can see in the comment can be small, medium, large. So this is all custom, right? None of those things come out of the box this is what I created for everybody else in my organization. And the sizes are small, medium, large, meaning that if you use AWS or any other provider, you know that those sizes do not exist, but composition cross-plane itself will make sure that small is converted to something, T2 something, and medium will be converted to something else. But I'm imagining a situation where most majority of people do not want to care about, hey, is it T2, T3? Which type of zillion of nodes in AWS or Azure or Google we are talking about? No, it's simple. Do you want small? Do you want medium? Do you want large? Which version of Kubernetes do you want and what is the minimum number of nodes? I said intentionally minimum because I assumed that the cluster is expandable and that it will start with certain number and it potentially grow over time with cluster outer scaler, so not the specific number of nodes but minimum. Now, those two are commented, meaning that they have default values if you as a developer or QA or tester or whatever you are, if you don't care about version, the minimum number of nodes, you do not need to set, and then this definition would just have the node size or you could leave that to default as well. Do those parameters are optional or not depending on how you design it? And finally, once the cluster is created, I want the Kubernetes secret that it will contain the credentials on how I can connect to that cluster and I'm specifying that it should be created in an A space called TMA and that the name of the secret will be cluster. So this is basically that end result interface that I created and everybody else in my company can consume to self manage their own clusters and limiting themselves to the things that matter while leaving the complexity somewhere else, somewhere outside of all that. Now, if I create that, I would say I could do it something like, I'm now a developer, right? I could use the definition to do just kubectl apply dash dash file name cluster.yaml and my cluster was created and I can watch what's going on by doing kubectl get managed and here we go. And you can see the cluster from before that I created earlier and now you have a cluster, the new one that is right now it's synchronized meaning that crossplane got the information and it is currently working on make provisioning it and it is not yet ready and once the cluster is ready then the node pool will be created and all the stuff that we need around the infrastructure for this specific case, right? So I believe that running in a background because that will take a few minutes and now switch to the point of view or how that same set of features would be seen from an SRE perspective and the SRE would need two things. First is the definition which is this one, right? This is a XRD or composite resource definition that defines the new custom resource in Kubernetes, the one that I showed initially, right? The one that allows everybody to create and manage their clusters and basically what I'm doing here is that I'm saying hey, there will be a custom resource definition that will be called composite Kubernetes cluster or claim Kubernetes cluster. So depending on permissions I want to give to people that can manage their infrastructure with cluster-wide permissions which is most of the time not a good idea or create claims just like when you're claiming volumes and then you're limited within your namespace and whichever other restriction somebody imposed. Now, the important part here is the OpenAPI schema, right? So I'm defining a schema for a completely new Kubernetes resource that will have some parameters and those parameters will be properties with version, node size and min node count. So those are the same properties that you saw earlier when I was consuming the end result of all that. So I defined, as I said, I defined XRD or composite resource definition that defines the interface that everybody else would consume and then what I did is I created implementations of that XRD or composites. I created one for Azure. So if somebody would want to create a cluster in Azure using that simple definition, this is what would happen, right? I would create an AKS cluster. It would have certain parameters that are defined and hard-coded because let's imagine that nobody in my company is changing the region. We are all running in one region, so why would you bother, right? This is the DNS name prefix. This is the default version, the default number of nodes, default size of nodes, and then we have patches. Now this is what gets converted from that interface that I was consuming at the very beginning. This is how we are all writing those values and that's about it. Now Azure is the simplest one. I'm going intentionally from the simplest to the more complex and then we have GCP, which is slightly more complicated, which defines two resources in that composition says, okay, so whenever somebody wants a cluster that is in Google, then it needs a GKE cluster and it needs a node pool and whenever somebody wants the same thing, but in AWS, and this is now going to be painful, this is what we need, right? Whenever we create a cluster in AWS, we need a route table, we need a gateway, we need a subnet and another subnet and more subnets and security groups and VPCs and some other role attachments and more attachments and more attachments and then what else do we have? A node group and finally an EKS cluster, right? So this is... Victor, I love this because you're showing how much work the SRE team is doing for everybody behind the scenes. Yeah, this is what he's talking about. We're extracting the complexity by making some safe general assumptions about the environment we find ourselves in, how we use the infrastructure as a service platforms, AWS, GKE, right? And we're doing that for you so that as a developer, you can just say, I just need a cluster and I need it to be able to support my workload with this CPU memory or whatever it might be, right? Some basic pieces. There are articles I have read on this many, many times on the leveraging of CRDs and creating a sort of like homegrown cross-plane, if you will. There's a great one from Pinterest engineering on building a Kubernetes platform. You can look at even board. It's the actual configuration is incredibly simple for the end user in just getting a workload onto this platform. And that's what Victor is showing here. So very nice. Thank you, sir. I know there is a few mentions here in the chat about Fargate. It looks like Dan Magnum also from UpBound, a co-worker of Victor's a great, great person. I think we've had him on before is handling answering some of those questions and it looks like Fargate is supported in cross-plane so that's awesome to see. Yeah, exactly. Yeah. Yeah, Fargate is supported. And thanks Dan for chiming in. Anyways, so all that complexity, right? We see hundreds of lines of Piazza. This is still a simple solution. Mario probably knows that kind of like it's even more complex than this gets reduced for the end user to this bare minimum. I could actually reduce even those 20 lines to 10. Basically essentially I can say hey, I just want a cluster in Google or AWS or whatever. So, and that solves an important problem, I believe, because either you, Mario, as an SRE would need to do all that work to create a cluster for others because others are unlikely to learn all this and even if they learn that they will want to spend the time to that or others would need to create clusters through some web UI where I don't want to enter by that is bad, right? Anyways, so where was I? Let me see. Yes, yes, yes. So, and finally, once we created completely new resource definition we can use something like kubectl, explain, composite, what is it? Kubernetes Kubernetes cluster that is recursive and if anybody doesn't know which are the parameters allowed you can output this is just another custom resource definition and see, hey, yes, so where is it? The specification is that we need parameters with those three parameters. This is what I can use and off I go, right? It does require some minimal Kubernetes understanding but really, really minimum, right? Now another thing that we get through that custom resource definition is something like get composite Kubernetes clusters and we can see, so this is now the output, this is a completely new resource that never existed before, that was created by that SRE and I as a developer or whatever my role is I can actually skip even looking at VPCs and this and that, I can just go straight into that resource definition and I get a custom output that I defined which in this case and it can be anything hey, control plane, is it running? Yes Not pull, running, yes. Is it already? Yes. What is the name of the composition cluster Google off you go, right? It can get as simple or as complicated depending on the design and agreement between SREs and everybody else. Now another thing that is happening over here is that we can update our cluster. For example, I can do gk.yaml I can say let me see, what should I do here? Minimum number of nodes should be let's say 2 right? In the same way as you would deal with any other Kubernetes type of resource you update the manifest and you do kubectl apply dash dash file name or even better for simplicity I'm executing kubectl apply I don't think that everybody should do even that. In ideal combination you should have that gk.yaml or your definition and you should be modifying it and you should be pushing it to git and from there on tools like argocd or flux or whichever you're using for synchronization between git and cluster would kick in and that would mean that as the end user you would not even need to have kubectl even know about Kubernetes all you have to know is this is the interface, this is the gk.yaml, I push it to git argocd, flux, whatever synchronizes with my control plane cluster and then things just appear but in this case I didn't do that I was too lazy to set it up for this demo so I just did kubectl apply and if I go let's say let me go for example to my gk console just to prove you that that's really happening if I go to kubectl send in you should see two clusters the first one that I created without sorry this one that I created without composites and this one that I created through composites simplified version and you can see it's up and running it's always good that's amazing Victor I just want to stop for a second what he just showed is that as an SRE team if you have a new policy or a new minimum or maximum like he showed or some other change to how you want your clusters to run how you want them to be executed what this means is you can make that in that abstraction that you're defining and the applications will inherit that automatically right and everything will be up exactly everything will be up to up to your desired state pretty much automatically there's a question here really quick Victor as you showed your QCTL commands you got the that cluster composition object there's a question which one which of the CRDs are namespace specific and I actually had a wider question on if we said like a developer a specific namespace let's say it's just their name so I have Mario the Mario namespace could I use that namespace and deploy these these composition objects to just my namespace and kind of be locked so that they're not cube system or they're not just generally in the default or something like that how does that work so when we create a composite resource definition or XRD basically there are two I mean more than two but too important for this question we have the kind which is composite Kubernetes cluster which is the one I was using right now and then there is claim names so typically that type of user would not have permissions in my cluster the one the control cluster to execute anything on cluster level so in majority of cases people would not have the ability to create composite Kubernetes cluster instead I would give them permissions to create claims in specific namespaces and this is I think where crossplane comes shows its strength for a simple reason for being a Kubernetes native type of infrastructure management tool so you would create a namespace you would choose your weapon of choice like either OPA gatekeeper or kaver not to set up policies in that control cluster not the clusters that we are creating control cluster those are the policies those are the namespaces all the stuff that you normally do and give a person or a group of people access to that namespace and say hey this is what you can do in that namespace and nobody else and among other things you would say hey you can create claims in this example for Kubernetes cluster right? okay and you could even one more thing very quickly if you combine it with policy management you could say hey in the namespace A you can create clusters with five nodes and in namespace B you can create clusters with 500 nodes because those are the policies and policies are acting against Kubernetes resources and this happens to be a Kubernetes resource gotcha okay that's incredibly powerful I actually did not know any of that at all so if you ever Victor just said you have that control you can dial in what a namespace can and can't do maybe one namespace can create clusters and another namespace can create RDS instances right whatever it might be in terms of provisioning and cloud resources other Kubernetes clusters when Victor too says a control cluster he's just talking about the cluster like he's interacting with right now where he's creating these custom objects and that cluster is then cross lines running and creating you know the cluster for you that the created object right which is a different cluster obviously right yeah so it's kind of control cluster where the tooling is and then you create the rest of infrastructure around it right right gotcha one last question on that so in terms of access so I've created my cluster with my cluster composition how do I get like how would I go and set up QCTL and all the rest so I can start interacting with that cluster with that resource and this is kind of the same for like if I was creating an RDS instance or anything like that like how do I get the the details I need to be able to interact with that maybe for my laptop is that kind of a more like a more manual set of steps or you know how does cross plane enable maybe that to be a little easier to enable you to access the cluster that you created yourself yep yeah so it's a QCTL cross plane and system no it's not that dash name space cross plane system get secrets right so and again it depends on how you define your composition right let me see I made a mistake somewhere I know I'm using a bound version of it system get secrets right so if you look at what we find it where is it we get an I swear did I put oh yeah almost there team A yep so you see here in the team A namespace I have a secret called cluster and that secret contains all the authentication I would need to use to connect to that cluster either myself or cross plane to do additional actions in that cluster because I could connect cross plane with Helm for example to install some stuff in that cluster through cross plane or me as a user so and now again this secret happens to be called cluster because that's how I define that it should be called in composite definition right and that secret can be anything because and this is important I think you as SRE during total control of what is really happening should there be a secret with authentication or not should it be namespaced or not should it contain this or that yeah now how this is great how you would get it if you don't want to consume it as a secret but in some different way then you would need to create a script or something that I don't know I'll put the secret and send an email and then get fired for sending that on email yeah I was just I was thinking like you could maybe even do something in a pipeline where like the pipe like let's say that you've got a feature branch and you're actually spawning cross plane and you're spawning a ephemeral environment and that is a new cluster right and it's got and then obviously you might want to access that cluster to interact with it during the time frame where you're testing some you know the feature and maybe someone else wants to look at it or you want to play around with some of the processes whatever it might be maybe the pipeline can then surface those credentials to you somehow or send them in Slack or whatever it might be where you can then just easily just send you I mean send you a keep config right and then you can start interacting from your laptop networking and all those other pieces Mavic asked about having two control plane clusters using GitOps syncing on the same repo would it create multiple cloud resources and Dan Magnum came to the rescue and said you know cross plane will kind of assume control of an existing resource but he would not recommend that either I wouldn't recommend that that gets into HA and all that other stuff so Mavic thank you for bringing the hard-hitting questions and Dan thanks thanks for answering those Victor I'll let you continue but this is this is really exciting I did not know that you could easily get it it was just a secret really just the cluster connection details exactly but one thing about that secret my favorite use case is that actually I do not give that secret to anybody ideally if you would be talking about clusters I would create a cluster with cross plane and then with cross plane install and give users brand new repo and say hey you cannot access the cluster you can push that that's the ideal combination nobody gets access to the cluster and nobody gets and everybody still can do whatever they need to do that's true GitOps that is declarative instead of imperative that is some of the core principles of DevOps and SRE I'm going to shut up now Victor continue enlightening us this is really really cool stuff yeah so one more thing actually I will try to keep it short so in case there are more questions I hope that there are but what do they want to do that's not what I wanted to do I didn't want to go to here I'm getting lost where do they want to go go yeah so in the meantime let me see what's the status of my cluster yeah so another thing that I think that this is the last thing that I will show we have also since we are talking about Kubernetes and we are talking about fully automated and constant feedback loop meaning that there is a constant drift detection and reconciliation so if I happen to have access to in this case to google cloud console and I go here this will actually the first question I will ask the audience and I go here edit and change for example this to number 3 and if I enable auto-upgrade and save can anybody guess what will happen nothing so I mean yeah I was going to say nothing I'm speaking for the audience in this case no one said anything but I'm going to be that person nothing should happen right this is the teammate cluster this is managed by crossplane it's more so managed by that core base template configuration that we are talking about that core composition and that composition doesn't say that we are okay to upgrade things right so imperative changes should not get applied that's how I think yes almost I mean they will be applied because I literally applied them in Google cloud but crossplane will undo those changes so something will happen right because I did actually go directly to Google behind cross planes back it's equivalent to let's say that I created a deployment with three pods it would be the same as if I deleted one of the pods I can't delete the pod but Kubernetes will figure out that I did that to three same thing with crossplane and I think that this is something special that hardly any tools in that area have it it's not only that we can create and manage infrastructure with crossplane but crossplane guarantees that the state that we defined is maintained always if you would use any of the CLI based tools then if I change the state directly that tool would undo those changes only the next time I execute that CLI which could be an hour later or a month later nobody knows right so crossplane is inherently just like Kubernetes in this case a reconciliation loop right it is always looking at the current state and trying to apply or get to the desired state which is incredibly powerful correct next one let's see whether there are more questions yeah I think Mavic was just asking about single points of failure for infrastructure provisioning okay well yeah now is the time like if anybody here is like what does this even mean why does this make sense what am I trying to do with this we have some time here for questions so please share them no question is stupid I had a bunch of dumb questions for Victor before we started this and so yeah just ask and I know Dan is doing a great job while we're waiting crossplane.io you can check them out on Twitter as well at crossplane underscore IO Victor is also on Twitter Twitter is where it's hoppin for the cloud native community you gotta be on Twitter on that feed you'll get some great news and thoughts and comments and philosophies as well Victor is at the Farsik you should absolutely check out the DevOps Paradox podcast as well that he does yep yep our names are wait wait wait got it at DevOps Paradox that's a great podcast in addition to I'm sure the Kubernetes podcast and others out there that are fantastic is crossplane going to do its own podcast or is it working on one I know there's a YouTube yeah there is not yet podcast as if only audio but I took over part of YouTube so if you got to I don't know the others but if you got to up bound the YouTube channel you will see me there at least once a week something new wow that's awesome yeah I see it here it looks like there's a Google group as well and of course the Slack channel for crossplane oh wow yeah there's lots on the YouTube actually this is very cool there's some great talks and great live streams there's some great QCon talks as well on crossplane which I think is how I got a little bit more pointed with it back in gosh 2019 North America in San Diego I think gosh such a great time I can't wait for LA hopefully it happens Mavic comes in again sorry for too many questions do not be sorry we like questions is there any way I can validate the composition specification so I think this is kind of on the open API spec you were talking about a little bit Victor right yeah I'm not sure that might correct me I don't think that there is a way to kind of like a tool that says Validate this you I mean if there is an obvious that it doesn't fulfill specification you will not be able to create it in the first place a Kubernetes API but on the other hand whether you've wrote version or whatever that's going we don't have a tool for that and then after the specification when you create a composite it would fail or not depending really on what the error is gotcha question as I'm looking at the upbound website again for those that don't know cross-plane is a project by the company upbound of which Victor is an advocate for and so I know upbound recently announced the universal control plane kind of the upbound cloud Victor can you give us kind of the TLDR on what that is and what problems upbound is trying to solve and maybe more so how it's making cross-plane more flexible and easier to use so yes we have built to begin with the web UI and a SAS service so if you go to cloud.upbound.io basically you get cross-plane as a service and we are about to release that same I'm not sure about the naming yet but Enterprise cross-plane self-managed so you can self-manage it or you can consume cross-plane as a service among other things you can get hosted cross-plane so instead of me creating a cluster where cross-plane is running you just have two clicks and you have cross-plane up and running for you instead of setting it up yourself there is there is a web interface through which you can see all the resources graphically all the things that I was doing with the console you can see it graphically and there is also a way to package your compositions and configurations and everything gets containers and then push them there and from there on use it in any way you like and on top of that you know support basically we are building Enterprise version of cross-plane in a way that's very very exciting that's awesome that's really cool I think we're gonna my team at least is gonna be trying to look at that Q1, Q2 of next year when we have a little bit more of our tech deck crunch and we're not we're not so busy we you know I think we and many others many other people I talk to are thinking about this how do I get SRE out of this churn of these ad hoc requests just kind of the maintenance of things at a certain level and how do we get to like you mentioned before so eloquently Victor building automated systems self-service tooling and more insights and observability around our systems and providing that as a service as a product to the very engineers that depend on our infrastructure right and then thus the SRE you know monitor becomes something different in what it is in so many organizations which is kind of a glorify dev ops CD sort of team that operates very similar to the way it did 10-15 years ago right so yeah this is awesome you know the best it is what AWS or whatever your provider is is to SRE is what SRE should be to everybody else kind of like you don't send an email to AWS saying I need three nodes right AWS created an interface for you to create three nodes which is just the level that you need and now it's your job to create an interface for just the level that everybody else needs exactly yeah it's all about that new abstracted interface I mean I am not someone who's not like encountered this like I mean months ago solving for ticket like seeing your ticket that said create already an instance for service X Y and Z right I mean like this is this is a common thing it's more prevalent than you think I'm not seeing any more questions Victor so I'm going to give you the floor is there anything that you've been thinking about around crossplane leveraging this or what is your next what is the next thing that you know on the roadmap for crossplane and you know what is what is kind do you have any special announcements or major areas of usability that you're focusing on for the kind of the next iteration so I hear major announcements which I cannot announce but of course if you watch if you watch the and follow a bound or crossplane anywhere you will see it in approximately a week from now I would get fired because I don't I still want to stay in that bound but apart from big announcements what we are working on right now there is a strong huge focus on provider coverage so that what the amount of providers in the coverage you have with crossplane is close to 100% of what major providers give you know AWS Azure, Google, Alibaba whatever there is and that's on top of there is a lot of providers that are contributed by community and what's or not like Siebel the other day but the major focus now is to be as close to 100% as we can okay got it no that's a big one for those that don't know providers are just the providers IE AWS or maybe in AWS like supporting elasticash right providers are just the interface to crossplane to interact with those sorts of resources and be able to then provision them manage them for you through crossplane and again through the compositions you saw today so that's awesome I know providers that's huge maintaining those providers has got to be painful so for those that don't know crossplane is an open source project donated to the CNCF I'm not sure what stage it's actually at right now it's got to be not sandbox anymore maybe I don't know bad for a week okay I'm going to stop talking honestly either way you can file issues if you find in GCP there is a resource that's not working well or it's not managed by crossplane like it should be you can help make that happen make that a reality I know that BioNTeen is doing so much work to keep these things maintained and make sure that whatever you're provisioning there is kind of full support which is definitely tricky so that's awesome that's kind of I think important thing crossplane is open source so whenever somebody wonders who is maintaining this it is an open source project so the community around it is maintaining whatever is being maintained upbound as a company let's say you have a dedicated number of engineers working on open source but it is open source so whoever asks who is maintaining I would say you come to the repo yeah and Dan kind of answering Mavic on what kind of how's the provider working more details there definitely check out what is the I think it's just crossplane IO is the GitHub and you can find all of this on upbound.io website as well I think upbound.io is the company website I think it's time to sign off we've covered a lot of ground here again check out crossplane crossplane.io my name is Mario Loria you can check me out mario loria.dev for now this is my last cloud native live we'll see I might make a return in the future thank you so much to Victor and the upbound team Dan Magnum as well who's been answering those questions and Victor who's kind of newly minted there and already doing great idea I was hoping to get him caught on like some things he wasn't quite sure on because he's so new but Victor is kind of evangelist and loves his stuff just as much as I do so it's great to talk to you again Victor today this was fantastic thank you to the CNCF Bill Libby and others who have made this happen and thank you so much for taking your time in your busy day to tune into another episode of cloud native live we'll be back next week thanks everybody have a great rest of your day and week talk to you later bye cheers everyone