 Yeah, I'm now. Hello, everybody. I'm extremely excited to be here, make my first webinar for Linux Foundation here. So as said, we're going to talk today about inside Kubernetes outside the box and gaining visibility into the whole platform, hopefully your platform with cross-plane. Just a little bit as a starter. As said, I'm actually at Upbound. And we help organizations standardize on a single point of control and visibility for infrastructure and applications across multiple clouds and platforms. We are obviously the company behind cross-plane, right? So this is our popular open source CNCF project. And Upbound is the commercial product that we build it around cross-plane and that really leverages the power of control plane at scale. A little bit about myself. So as said, currently working as principal solution architect, I am deeply involved in cross-plane ecosystem. I am regular contributor to cross-plane, but also maintainer for various providers in the ecosystem. And I have many experience in enterprise environments for different industries, means financial services, telco industry and railways. Normally I was helping these companies to bring their private data center services to public cloud, helping to refresh the infrastructure, building a platform and also adopt a lot of pre-existing services to the platforms, means firewall services, ITSM systems, source control systems, whatever you need to operate a platform and enterprise environments, and now started Upbound and helping the customers around their platform journey. So we're going to talk a little bit about first, about platforms, what it is in general, and then we jumping in the visibility, observability monitoring part of this talk. So in general for me, a platform is an environment that abstracts the underlying complexity of your applications and infrastructure. And this is normally consumed by all of your application engineers, DevOps engineers, whatever you name it in your company. And what basically happened with all of the engineers, normally they need to take care here for standardization in your company. So they need to implement some kind of policies. They need to implement some kind of security guardrails. They need to be aware of costs. So for up and downscaling for your infrastructure, some at some point you are starting the discussion of what is the developer self-service on top of my platform? Is it only an API? Is it in web front and whatever? Then you touching at some point the observability and monitoring part. And what I learned in the past is that normally you're building a platform and the last thing in general is observability and monitoring. Directly before production, there's something like, oh, we need to implement observability and monitoring. And then when your platform is in the company, well known, then normally the discussion starts with multi-cloud vendors. But overall in this area, your platform engineers, they need to make their day-to-day business on this platform and they need to enforce in best practices and the controls consistently across the entire organization in your platform. When it comes to platforms, what we see the last years is that a lot of companies starting first standardizing their platform on Kubernetes because Kubernetes by itself there's a lot of standardization inside, right? So you get API abstraction to run your workloads on a Kubernetes control plane and it hides a lot of complexity in general when you're using this kind of platform, right? But as it is, you not only have this Kubernetes control plane, you have to have a lot of more things in infrastructure in your public clouds or in your private clouds, right? So for example, you have infrastructure in AWS, you have some kind of identity management, for example, in Azure cloud and all the things you need to do behind the scenes, right? So to make it smooth for the consumers from your platform and you have a lot of more interaction interfaces in front of your APIs with some kind of GitOps toolings, front-ends and whatever you want to put in front of your Kubernetes platform. But what you really want is at the end of the day, right? If someone is using your platform, you want to say, here's my API and you want to hide the full complexity behind. You don't want to say you can have here a deployment on the platform in the Kubernetes cluster, but for in firewall, thing you need to create a ticket for something else in the identity stores, you need to open an ITSM ticket, right? So you want to make this completely smooth and you want to make the job very easy for everyone who's participating on your platform. And at the end of the day, you want to have this as quick as possible and you want to have the ability also to change whatever is behind of your APIs, right? So if you're changing, for example, the firewall provider, you don't want to break the interaction with your platform. You don't want to train all your platform consumers again, how to create firewall things, for example, right? So that means when it comes to cross-plane, right? Because this is a basic thing here, it's also a control plane. Let's first talk about a little bit about the basics from cross-plane. So whenever you add in cross-plane as your control plane in the platform, you will get something like an abstraction layer, right? So it helps you how you can create cloud resources in general inside of Kubernetes to the outside. So in cross-plane ecosystem, we say to this abstractions providers, that means with this providers, you are extending the Kubernetes API for all of the resources from the cloud providers and then you can start interacting with them. The next thing what you get with cross-plane here is something called custom abstractions, right? If you're a little bit familiar with cross-plane, you will see very often something we call it composition or composable custom abstractions here, right? It's on the picture here with A and B, so you can start defining your own interfaces for your control plane, your own APIs, and you can thinking about what kind of services you're gluing together, what you offer as an API in front. The next thing what you get with cross-plane is we have a generic package manager that means whenever you're building your own APIs, you can bundle it together, you can put it in registries, you can put it in the marketplace in the cross-plane ecosystem. And at the end of the day, what you get with this, it's something like an app store for your cloud, right? So that means with cross-plane, you can install these kind of packages in your control plane, you can directly create infrastructure out of it with a small configuration about your credentials, but then create the infrastructure on everything as live and you have the first thing deployed and this is normally the starting of building your own platform, right? So if it all comes together and you guys want to build a platform and your company really start building your platform using a control plane, right? So like the large cloud companies, AWS, Microsoft, Google, all they're using control planes the last years behind the scenes, right? So basically when you start interacting with these cloud companies, you're leveraging them, there are control planes and whenever we talking from our control plane with them, we also leveraging their control planes and why not giving all the benefits from a control plane to your company and you building and control a platform in your own company, right? So when we checking a little bit in the past when everything was started, right? So it's a few, few years ago, perhaps before my time, right? So the way back the days we all doing scripting, right? So configuration was sort of comparative. So a lot of things you need to do, you need to hand over some kind of introduction how to run infrastructure, a lot of things, right? The next cool part which started then was infrastructure as code as an error. So like with Ansible and Chef, I know from the past when I was sitting in my first Chef training how easy it was to install operating system, do a few configuration from our organization and put the first HTTP server on it and then it was really a feeling that we are really, really fast to develop or to bring your infrastructure out to the wild. But then you get a lot of hassle around. So with drifts from infrastructure, I don't know, other engineers locked into your machines, you changed something and you had the problem to restart again. So you need to invest a lot of time to think about what does it mean? When we're looking at today, I would say, we see that the era of control plans started a few years ago. So you can see this was really popularized by the public cloud providers, as I said, but also from Kubernetes by itself, right? And what you get at the end of the day, you get something called declarative APIs. The cool part is self-service APIs. That means you can offer this in your platform to your consumers. What you also get, what you also know from Kubernetes is something called reconciliation, right? So for example, if you remove a pot, a deployment will create a pot again and the cool part with a control plan, you get this for your infrastructure. And on top of this, if there's a drift, for example, I don't know, in one of the cloud providers, someone changed a parameter for your infrastructure, then the reconciliation will find us out, correct the drift and everything is again under your control, right? And then it's also very easy to do day two operations here with a control plan, right? So we talked now a little bit about platform and cross-plan and the advantages to get having a cross-plan-powered control plan, right? So we can start jumping a little bit to the interesting part of the talk. So the platform visibility with observability, metrics, monitoring, whatever, and you can think of, and what is really essential for your platform if you start building it and really start building it with this and not after, right? So we will talk about this. So the first question is, what happens with your platform without observability? And I noticed from the past, I saw this very often that we start building platforms without observability parts and at some time, I don't know, one week before production, it turns out we need something called observability, metrics, monitoring, something like this and as fast as possible because we want to go to production. So what you first see is when you go to production without it, you will see something like this. Look at all those broken tables in production, right? And if you have a chance to look, this is really time-consuming now, right? Because you don't have an idea when you really want to start at the cloud provider, at your control plan, at your platform, at the application. So this tooks you a lot of time, right? So and the sentence also, it really shows us why we need observability in platform engineering and really at the beginning of building a platform, right? Because it is like a warning sign, right? So it's telling us that you have big problems because we can't see what's going on in our platform. So the first thing when we implementing some kind of visibility in the platform, we need something called spotting problems early, right? So we need a good observability overall. We need this because we need to find and fix specific problems before they get worse, right? So if it's not only one table in production or one database in production, it's fine. But what you want to do if it's all the databases in production for across your customers on top of the platform, right? So it's even better to know issues before they start causing real trouble for you. The next thing is we need to understand a little bit why things break, right? So the observability or the systems, they need to help us to figure out why these tables are broken in the first place, right? Was it a conflict change on our control plane level? Was it something in the public cloud environment for example, or is it something from our software? So Glitch is too much traffic on the databases. Something like this, we need help to fix the things right away, right? And if you're talking about fixing things fast, we need really some kind of observability to find and solve the problems quickly, right? Again, this is super important because in a production environment where every minute counts, this is really needed because when I was working for financial services, for example, there are some kind of 15 minutes and then your banking authorities will start going crazy. That means you really need this otherwise you're lost between all of your things you offer on your platform. Yeah, and then also really, you need this for learning and getting better, right? So when something goes wrong, the observability tools need to help you to find and solve the problem quickly, but you can also go in the back, really find out the spot when this happens and when it happens, then yeah, checking it out, make it better, make your platform stronger and more reliable for the future, right? Fixing the problems again and you will see this really helps you, right? So if you're looking again at this look at all those broken tables in production, it's really a call to action for the platform engineers in your company, right? It highlights the critical role of observability and it's not just maintaining the current state of your platform, but in the shape of the future resilience efficiency you need in your platform, right? So because without observability, right? Your platform engineering team is often left in the dark completely reacting to the issues instead of preventing them which can lead to cycles of continuous firefighting, operational inefficiencies. So you will see if you invest time in this observability, visibility part, you free them and they can innovate on your platform instead of firefighting for all of these issues which can occur on your platform, right? So and yeah, I really like this sentence if you're checking a little bit for observability and that's the reason why I'm really thinking about observability needs to be part of a control plan, right? So observability is a measure of how well internal states of a system can be inferred from knowledge of its external outputs, right? So let's basically take two things together. I just talked about cross-plane as a control plane and I talked about we need something for observability, visibility and let's see how we can stitch this together, right? And how we really solve some of the pain points, problems and challenges in the platform engineering space, right? So what we get when we stitch this all together we essentially get a control plan. You can see the control plan here on the right side and when we get this control plane we can power the control plan with visibility and then we get some advantages here only to name a few of them. So you can reduce complexity, you can ensure consistency, enable portability, easy leverage and secure operations. If you check what kind of services you're normally running around your control plane, right? So you're starting normally with something like a Git systems, the ICD, you're adding like platform front ends, you're using GitOps systems, you're using authentication authorization internally, you need something for secrets management, you need policy engines, you need continuity management for backup and restore but really the important point here is for all of the things in your control plane you need monitoring and observability per default enabled for your platform owners for your platform users, consumers, right? So as mentioned, really building your platform only with the control plan and not without, you get the ability to create custom APIs and interfaces with the control plan, right? And overall this reduce the whole complexity you see here on the right side, right? Because you can really ensure that only the things you want is other things that you are really running in your control plane and in your platform, right? When you enable portability, it doesn't matter if this Kubernetes cluster, for example, is running in the cloud provider A or B, you can enable it and can change it whatever you want because you're hiding the full complexity behind of your APIs, right? The next thing is easy leverage. That means you don't need to start building the whole platform for your own, right? There's a lot of things pre-created in the ecosystem, right? So there's a marketplace you can pull in a lot of predefined platform references for Kubernetes clusters, for networks. It doesn't matter in which kind of public cloud you're running and you can think about is this what my company needs? And if yes, use it and then start adopting it, right? And this really saves you the bootstrapping time and at the end of the day, you're really fast and you have a faster time to market for your organization and for your company. But overall, this full thing here, right? So the reconciliation is the really interesting part here. So when we orchestrated the whole platform here, right? It's a really complicated pipeline at the end of the day, right? So many things to take care of, right? I don't know, the Git system needs to be first and the GitOps system needs to kick in. You need secret management, then the policy needs to kick in and after a while, your backup needs to be run on this platform and all the things together, you want to operate on top of this secure and efficient, right? This is what normally the idea is of a platform. So really, if you're leveraging a control plan here, you can manage your platform over the entire lifecycle, right? And this is the youth advantage what you get here when you're using a control plan powered by a cross plan. So let's jump in a little bit of more detail. So let's say, or we talked about custom APIs and interfaces, right? So platforms really require abstractions to hide the underlying complexity from your customers for the platform, right? So because at the end of the day, it creates a more intuitive experience for them. And also we need to make it as simple as possible. As you can see here on the right side, we created here an API for a bucket, right? It's a bucket from our company in this case. It's in a region and we have an Boolean here for observability if you want to have a true or false. The idea behind is if you're running in development environments, perhaps you don't want to enable full observability because you're trying something out, right? But what happened in the background is when we're composing this here now together from the managed resource perspective, we creating for example, an S3 bucket in a cloud provider, right? But what you also can do automatically with it, we can create an alert rule in your Prometheus alert manager, right? And we can add some defaults, right? And the next thing what we can compose is an escalation policy for your patcher duty what you're using at the company, right? And all the things here together, it makes it really, really easy if you're doing it behind your API because there's really simplifying the access to observability features in your company. And with the cross-plane CRDs and the composition, you really, this really enables not only the platform builders but everyone was using the platform that you have to unique APIs and you really support observability and metrics and so on and so forth over your entire control plate because you can do it for every resource if you want, if someone is creating these resources, right? So again, this very simple example here, it shows us to leverage the composition in the custom API, right? And we can really again here hiding the full complexity. No one needs to understand how to create an alert rule in the Prometheus alert manager. No one needs to understand how to create a policy in a page duty environment, right? Because this is what the platform builders can do for you and you're only the user of this at the end of the day. When we're talking about configurations, so thinking about observability system in general, they're coming with particular settings for data sources, dashboards, alerts. And if you want to support it for your users on your platform, you can include this fundamental set of these features in every API as I said, right? And you can have this through your entire control plane. If you check, if you see this here on the right side, right? We can define exactly an alert rule here. This kind of alert rule is a custom API as you can see. And we can use this alert rule then for every bucket which is created in our control plane. And this is really extremely powerful because it's like four or five input parameters and the rest is automatically done for you, right? So, and the cool part here is the cross-plane configuration, you can use this in cross-plane configurations then together we can bundle this, you can ship it out, you can give it to other departments in your company and they can directly start using it. It's a clear API, it's a declarative process. If you're checking about abstractions, right? It's the next topic. So in this example on the right side, we really just exposed an internal policy API, right? So you see here the declarative policy, it's just giving you a little bit more of an idea how you can use existing abstractions here. It doesn't matter if someone is using this as an user from the platform, if it's in the background, if it's created in a cloud provider AB, if it's created in a ZARS provider, if it's created in a platform as a service provider, really this whole thing we can hide in our implementation in the control plane. So that means today, for example, you can create this policy in a Patriot environment, tomorrow you can create this in a Grafana on-call environment. It really doesn't matter and you can really, you can be very fast to switching this whenever something in your company changed, right? And I really like this hiding of the underlying complexity for the normal users of the platform, right? So that's a really plus point here. The next thing, and this is last but not least, but this is really in really important point because how we keep now all the things together, right? How we managing the whole life cycle of all the pieces we stitching together. Remember the picture what I showed you, right? So this is an extremely challenging problem normally because all the different components, they need to work together. You have different cloud APIs, you have different ZARS providers, you have different past providers and what comes on top of it, it sounds easy but at the end it is not is what is running in your Kubernetes cluster because inside your Kubernetes cluster, you can running thousands of services, right? And you can stitch other services together if you remember the CNCF landscape, right? So at the end what you want in the whole platform, you build it, you want the overview of everything in your specific platform, right? So really you acquire a control plan and then you constantly orchestrate all the necessary resources, right? So you can deploy them as needed, you can guaranteeing their continuous availability, you can continue to reconcile their state to ensure alignment of your control plan requirements, right? And in case of drifts, cross plan will persistently reconcile the resource and maintain consistent management overall. And yeah, what you can see here, cross plan is also managing then, for example, your observability system and how this can look like. We will see in a small demo now. So I will stop my presentation and I will show you know a little bit of a control plan. Let's have a look how it looks like normally with cross plan. So I'm here connected to a control plan and what we're using here in this control plan, as I said before, use pre-existing platform references. So we can say give us the configurations I installed in this control plan. So you will see we're using a predefined configuration for an AWS network here. We're using predefined configuration for an AWS ECS cluster. We're using some for IAM roles for Kubernetes service accounts and we're using one for our database because we want to find out why the databases in production have trouble with their tables, right? And all this is bundled here together in my platform API. And to give you an overview, what that means, because I'm using a abstracted API here, we can use the Kubernetes CTL, the kubectl command. So let's make kubectl get X network. We will see, okay, cool, it's very easy. It's a network created here. If we want to look a little bit deeper, we can use the new NICI command from cross-plane because this control plan is baked by cross-plane. We can see here after a few seconds what kind of resources are behind my API. And then you'll see now the magic, what happens if you create your own API in your control plan, right? So a bunch of resources are really here created, but also if we're hiding the complexity, we need deep insights. Why, for example, my abstraction is not ready, not zoned, which kind of resource is missing, which kind of resource has trouble at the moment, right? So, and we can do the same thing with an EKS cluster. So it's the same thing, get X EKS. So you will see, cool, some kind of EKS cluster is deployed. We can use the same thing, better trace, the EKS cluster now. And then you will see, cool, there's a bunch of resources for a very basic EKS cluster, EKS cluster add-ons, a little bit OIDC provider, a few roles in AWS, that's it, right? And you can see they have other timings for readiness, right? So perhaps an IM role is faster than a full EKS cluster in AWS. And all the things together you need to investigate later in your observability systems, right? So, and the idea to make it very easy in companies is to use some kind of observability systems, monitoring systems and make this really centralized around your platform, right? So what you will see is, we're using here an centralized Prometoys. So we can say, give us the centralized Prometoys. In this case, it's a managed Prometoys in AWS. You see it's available and we will have something like in managed Grafana. That's the cool part. And what we also can do with our control plan now is something like give us, for example, create us folders in Grafana because we want to organize our internal users in this Grafana, for example. Normally companies that have something like tenant onboardings, customer onboardings. And that means if you have this, you can include, for example, Grafana folders in your onboarding process, then it is clear for them. They get access to this folders. And then the next thing would be unique dashboards, right? And dashboards now could be really something when you're provisioning a database, why not provisioning automatically for this specific tenant, customer user, also Grafana dashboards, right? So that's the thing what we need to think about when we're creating our API abstraction, right? So let's have a look. We also created an SSQL instance. It's the only thing and behind my implementation of an SQL instance now, we creating an AWS and RDS instance, for example, we creating something called DB subnet group, but we also creating for this RDS instance then in Grafana dashboard. And we also creating perhaps something like an SQL day exporter that we get insights from the database by self. And we can now have a look how this looks like before we going into Grafana. Let's have a look how our EKS cluster looks like. So whenever we provisioning now new clusters, this new cluster is connected to our centralized Prometo's installation. So we can say, let's have an overview of the POTS, what we're running here. So the really cool part is, yes, you see in the specific Kubernetes cluster, EKS here, we're running here Prometo's, but the cool part is this Prometo's is only here to remote write, right? So this Prometo's is not persisting data, it's remote writing the data in a managed offering. And for demo purpose, I installed here some cross-plane and providers and also using a service called Xmetric, it's available in cross-plane community. And with Xmetrics, you get a lot of metrics from composites, managed resources. We can have a look how this looks like in the Grafana environment then. So, and you will also see, I created a database. It's called HACRI, LFDemo. And you will see, I created this database in the default namespace. And what automatically happens here is that the MySQL exporter was created automatically. And this SQL exporter is connected to the database because I have from cross-plane the ability to use a connection secret. So I get username and password. And if I use this together, I can instruct the SQL exporter to generate metrics from this database inside. So, and then I can really combine everything together. So now let's have a look here in my dashboard, right? So I prepared this here because otherwise I need to log in. It's a managed Grafana again and I need to log in via my company credentials here. You get this out of the box. So what you see here now is really cool because you see metrics from the database, but you'll see also metrics from cross-plane, from your control plane, right? So, and what you can see here, which is really interesting if you're checking the graph here, you see that my XR from my SQL instance was not ready for specific time. But we will see here that it reached ready at some point. If you're looking to the right in the managed resources graph, you will see that the managed resources was already a few seconds before. And this is expected when, for example, we updating some kind of input parameters from the database, right? Because the database then gets one time not zoned, that is zoned, and then it's not ready, perhaps because the database needs a reboot and we can have a deeper look here. What's going on? Is the problem here because my database is not reachable because at the moment there's an upgrade running or what it is, but what we see here also is from inside the SQL database, we see, okay, the uptime is more than 10 hours. So there was no downtime from this upgrade process here, perhaps, but you can also like very deep inside. You can check your performance schemas, whatever you want. And this is what you can offer per default whenever someone is creating databases from your control plan, right? So you will also see some rates for time to reconcile here for the claim. You will see that we have in general, controller reconcile times for the composite. And you will also like get insights if, for example, the provider, which is responsible for talking with the AWS API had some trouble because of restarts, whatever, right? So this gives you a little bit more ideas what's going on with your database. And really, this is a basic example, but if you roll in this out more and more in your organization, in your company, then you can create really great overviews. You can iterate on top of it. You can create your alerts. You can create your escalation policies. You can think of specific SLO, SLI implementations from all the things you get here, right? If you're talking a little bit or checking a little bit what we also get from this X-metrics, what I said, you, we, or in general, what we get from cross-plane metric endpoints, you will see we get some information of histograms. We get rate of time for reconciling in general for a lot of endpoints. So many resources, composites, whatever. We get controller reconcile time so you can have a look how it looks like. And what I learned in the past, it's also very interesting to monitor or to have metrics for your pods in general because it's the control plane myself and cross-plane is running on the Kubernetes control plane. And as you know, it's expected to be restarted, but you can then have a look, was there something like a rescheduling of my whole infrastructure under my control planes? Is that the reason why, for example, a database took a lot of more to provision that the upgrade was stuck, whatever. All the things you can get out of this metrics here, right? You can also like monitor what kind of additional resources we creating in the clusters in the API service if the API service under pressure because of, I don't know, 10,000 of custom resources here. And it's also great to check CPU and memory usage because sometime you get struggled and then a lot of things go very, very slow and all the things you can have a look at. When we checking what's happening in our Prometoys here because we're getting this metrics, as I said, so we're writing from the EKS Prometoys to a remote sign here, you will get here from all the clusters we provisioned and all the metrics aggregated here. So that means, for example, for RDS, right? You get the information when it gets created, the info, the labels, when it's ready, when it was the ready time, since when is it doing, does it answer all the things what you normally get from the status from an individual resource and crossplane you can find in your Prometoys installation in this case. So this is the really cool part and you can offer this as a service in your platform. So this was a little bit what I wanted to show you here. If you want to build this together, we will have a look how this looks like. So very quickly wrapping this up, right? As I mentioned, I worked at Upbound and Upbound is really all about control planes at scale. It's easy and efficiently when you're using them and we are behind the open source CNCF project crossplane, right? So we created the commercial product called Upbound and this Upbound product that makes it really easy for you to run and operate control planes, right? At a high scale. So not only limited to one control plane, you can run hundreds and thousands of control planes if you want, as I said, at high scale. If you're checking here a little bit about the Upbound platform itself, that means you can use Upbound today to build everything from internal developer platforms. As I said, right? If you have AI developers use this Upbound, if you want to create observability platforms overall, use Upbound, if you have data pipelines, use Upbound, whatever it doesn't matter, right? So in the very core of the offering what we have here, yes, we're running crossplane control planes, but what we're doing here, we're managing the control planes for you and scaling this and they are reliable for you, right? What we're also doing is like we are creating so plugin systems for forget system, source control systems, but also we have a story around monitoring and security stuff for the control planes in general. So that means it's really up to you if you put more things together in a control plane environment, that means more things are under continuous reconciled and at the end of the day, you can orchestrate everything in your control plane, but again, the interesting part here is your visible observability part between inside the box and outside the box, right? You need to have visibility, what's going on in your platform, if it's from your control planes from the outside to find it really fast and that you can iterate on it to fix it in your platform to really create platforms that someone wants to use. So the last thing I see, there was some kind of questions. For example, if you share the repository for the code for the demo, yes, we have some kind of reference platforms here. As you can see, I used one for cluster as a service. Really, if you want to use it for orchestrate Kubernetes cluster as a service across your environment, right? So ensuring seamless scalable centralized management for your containerized application alongside your infrastructure, have a look there. You can also like starting directly in upbound to iterate on this. There's an idea how to run observability in a single control plane. The idea of what I showed you today was more like what you're doing with this control planes, if you have hundreds of control planes with a centralized observability system, then you can have a look here in our configuration for observability. And I think I'm good in time. So that means I want to wrap this up and we can have the last minutes here now for Q&A. If you have some questions, feel free to ask. I try to answer them. Thank you everyone. So let me check. I see only the one open question shared the repository of the code. Yeah, it's part of all the platform references, as I said, right? So you can have a look and that's what we assembled together. So all the parts are available in the open source communities. I don't see any more questions here. I don't know if someone else is seeing something. Okay, I see now one question. So what would be the best link to get started with XRDs? Yes, today it's a little bit not so easy to start creating these XRDs. I think the CrossFit community is working on this a little bit more. But what I normally doing for XRDs is I'm looking at the reference platform implementations and then the other good starting point is checking open API schemas because at the end of the day it's open API and this is what you are creating in your XRDs and offering as input fields for your developers is open API and so you can start iterating on make your platform API abstraction. I think, can we get the replay of this presentation? Yeah, I think this is recorded and this will be available shortly after the webinar. So there's one more question. Does cross-plan address the storage scalability issues with metrics and logging? So to be honest, not per default. So you need to build around what it means if you have storage scalability issues with metrics and logins. What I learned from the past is really think about if you really need all tons of metrics in your systems, right? Or if it's better to filter before, I know there are some software as a service and platform as a service guys outside they're helping you to find out what kind of metrics you're really using in your dashboard and if it's possible to drop the rest. So I don't know, for example, if you really want to have all the metrics from an EC2 instance and if you really want to see if a red LED and the data sender is on or off, I think you can drop this metric but this really costs your money at the end of the day, right? So you need to be aware of this storage scalability things, right? It's nothing cross-plan can save you per default. There's one more question. So is there already an implementation of Prometo's Grafana together with Loki? Yes, we have one available. It's part of the observability configuration we offer in the marketplace. So you can have a look inside this. If not, if this is not enough, I'm also open in the Slack channels for cross-plane. So I can point you to the right sources if you need this. So Candice, I look a little bit in your direction. I don't see any more questions at the moment. Great. If you're ready, we can go ahead and wrap things up. Yeah, I'm ready. Thanks for everybody to participating in this webinar. Thanks for the questions. And as I said, I'm available in this lecture and it's from cross-plan. Ping me there and the rest is up to Candice now. Awesome. Thank you so much, Christopher, for your time today and thank you everyone for joining us. As a reminder, this recording will be on the Linux Foundation's YouTube page later today. We hope you join us for future webinars and have a wonderful day. Bye.