Cloud Native Computing Foundation KubeCon + CloudNativeCon Europe 2022, 2 Jun 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Building Digital Twins for DFDS With Crossplane and Kubernetes - Tobias Andersen & Matthias Luebken

Description

Don’t miss out! Join us at our upcoming hybrid event: KubeCon + CloudNativeCon North America 2022 from October 24-28 in Detroit (and online!). Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

Building Digital Twins for DFDS With Crossplane and Kubernetes - Tobias Andersen, DFDS & Matthias Luebken, Upbound

Constant movement and adaptation to change is the story of DFDS, a logistics company from Denmark. Every ship, truck, or warehouse needs to be fully connected and be able to drive autonomous and smart decisions. At the same time, customer and business demands change constantly, and software development teams need to build and update solutions at an ever-increasing rate. In this talk, Tobias and Matthias like to introduce DFDS’s decentralized and distributed problem space and how they have mastered this challenge by introducing Kubernetes based Digital Twins. They will talk about how to align software teams from all over the organization, and how a platform build on top of Crossplane and Backstage can guide and accelerate teams.

A

Welcome everybody, so uh the next presentation will be around the kubernetes and cross plane and we'll have 35 minutes. uh If you have questions at the end, we'll try to take them as well, and if you're watching online push push the questions as well via the chat so we'll we'll try to get those as well. So the floor is yours. Thanks.

B

B

Hello, hello, hello, do I have to do anything now sounds like we're here. Oh my god. This is awesome right. uh We're back. I've heard seven thousand. I didn't make the keynote this morning, but I heard that seven thousand, so are you all excited to be back in in in person? I had so many.

B

So many awesome conversations already it's like yeah, you get. You can do this virtually, but then you know you do it back in slack and it's like I'm actually meaning persons for the first time as like I'm actually trying to map the zoom window around them to recognize them.

B

So, first of all, it's awesome that you're all here we're super excited to talk about it and there's one thing that I've done in the past and I haven't been doing since I don't know gazillion years is a selfie with the audience. So if you I know you know it's like getting up, but but if you could like a little bit of like show your pure enthusiasm while we do the do the selfie with you folks, all right are, you are you? Are you there.

B

Awesome awesome right thanks a lot for coming, um so uh I'm matthias, tobias gonna, introduce him in a minute uh super excited to talk about our our. You know things that we've been doing um in the last. uh You know last little bit um so we're gonna talk about uh digital twins that we're building it's a nice fun concept and you know being kubernetes and crossplane nerds like it was obvious. That's that's the only technology solution that you can find for doing these.

B

So we're going to talk about that. A little bit. uh One sentence about myself: I'm matthias out of germany and working for a small company called upbound and we're uh the major contributor behind crossplane. So you know, come by grab a sticker, hit our booth and happy to talk all things about crossplay. This conversation. What we do here- or you know general building, building platforms and uh yeah and another note. I want to see you all for beer later uh so stop by. I want to cheers with everyone every single one of them.

C

Cool so yeah now matthias is done, selling your stuff, so I can geek out. My name is tobias anderson. I work for dfts. We are a danish logistics company. I've been around for quite a while, and about a year and a half ago I started looking at crossplane as a way to manage some of our.

C

We had a lot of requirements for setting up some service brokers for a lot of our cloud native workloads and we sort of stumbled onto to crossplane and from there on it just became a love story that have led to this point. Where now matthias is my bff, you know we talk every day on slack, we call each other and soon he doesn't need to remember the frame to see my face.

C

He dreams about me every day and hopefully, within you know a few years we will be able to get to a point where we can try to frame some sort of subset of cross plane that can deal with the concept of digital twins, because digital twins has been on our roadmap as an organization for over five years.

C

Now, if any of you work for other logistics companies, you will probably know that you've also been looking into these things, because the future is automation and in order to facilitate this automation, we need digital twins to sort of interact as ms series on our behalf in cyberspace.

C

So a little bit about our agenda today. First we're going to give you a big picture. Talk of what this digital twin concept is all about. In my world, it's still very undefined. There are many different views on it, but slowly we are getting to some sort of consensus and hopefully that the tooling will follow along and make it a lot easier. Then we will matias will talk about our use cases.

C

I will talk a bit about what we or how we view digital twins internally in dfds and how we work with them and then matias will go through a demo that we prepared on how we could potentially go about building digital twins with crossplane and kubernetes.

C

So moving on to the big picture at some point in time there was somebody who sent the spaceship into space called apollo 13 and in order to fix that mess, they ended up building some mirrored systems to salvage apollo and that was sort of the uh genesis of digital twins.

C

As we know it, and then we can move forward to the 90s, where a guy from procter gamble was like yeah incident of things is a thing and that sort of started that whole ride and then eventually michael grief, started discussing the theory of of digital twins at university level and over time industry started coming in and hp started working with.

C

I can't remember who it was, but they started actually building some of the first digital twins and then nasa eventually coined the term uh digital training, a report that they put out there and now we're at a point where looking at the audience, we are clearly seeing growing interest for the concept of digital twins.

C

I think all of us will, within the next five to ten years, be working with that concept in one way or the other, as we help our different businesses on board this whole industry 4.0 what the thing so yeah, but moving on essentially for us. From our point of view, a digital twin is a digital representation of a physical asset in our world that could be a vessel like a ship or a truck. uh It could be a trailer.

C

It could also be a sensor for that matter, and the the thing with digital twins is that they mimic the behavior of the physical assets, so we can interface with it digitally in real time and thus do cost correction. If our truck is about to hit some person in a terminal area or what not right- and this then bridges into the whole realm of 3d game engines and so on, because how do you do collision detection between things based on events right?

C

You need something to run the math and we're not quite there yet, but right now we're focusing on sort of the taxonomy within everything and then hopefully over time. We will get more mature, we also sort of view digital twins as a digital control plane for the physical world at the end of the day, this is about controlling robotics and machinery and manufacturing plans and so on, but we want these twins to be able to do that in a secure encrypted manner.

C

Obviously, and the idea with digital twins might go as far as to say that when I buy my nike air sneakers, maybe nike will spawn an instance of a digital twin that will follow that shoe from cradle to grave and you know keep track of where it was and if it got resold to others and so on. So this is for us.

C

You know at a high level what a digital twin is and if you can move on to the next one, if we try to put that into context of a manufacturing plant, you have robotics. This is one aspect of what goes into it, so the ability to have an embedded system that can move. You know an arm based on commands. We have cloud computing services, they give us access to scale and geolocation things and so on. Then we have the whole big data thing right, because our digital twins are inherently stupid.

C

They need to learn over time. This is where big data fits into to teach these twins to become more aware about their surroundings and thus create even better simulations, and then we have the wireless technology that makes this all work right, because in our world we you know, have ships.

C

Trying to you know, bridge an ethernet cable to a ship in motion is impossible, so it's either satellite or something like that right and the last part is then the embedded systems that we often have like a sensor which will have a one-to-one relationship to its digital twin and then the ship will often be an aggregate of twins, but I'll get into that a bit later and obviously the reason why we usdf is doing this is because our world looks very much like this, but we know that at some point within like 5 10, maybe 20 years, the world will look like this right and then all of a sudden, we will have to figure out a way to manage these digital assets as they move around, because in cyber space there are no ships right.

C

There's just a lot of sensor data that makes up a thing and then you have some 3d grids and so on, and then it's like you start understanding that in reality you know when you're dealing with this concept, it's kind of like the matrix right. It's uh it's, not the spoon that bends. It's you that bend and then you start reframing your your thoughts and start saying: okay. Well, maybe the ship doesn't really exist in my system. It's just a collection of sensors that are controlled by some sort of aggregate that can manage this.

C

So that is sort of the the big picture, and then I guess I'll hand it over to you mathias to just talk a bit about our use cases.

B

Yeah, so if we're talking about like these digital twins and these sensors right, you there's, you know a gazillion use cases uh that that you can think of, um and obviously me not not being like too deep into the uh to the domain. Like you know, we figured out a couple of initial use cases that way that we that we wanted to support. So I'll walk you through this, so the first one um is obviously uh you know the trailers um and making sure that um we're reducing co2 emissions.

B

um You know it's not not only an a general good thing to do, but obviously also from a fuel consumption perspective. You know uh something dfds strives for uh there's a lot of. You know integrity that needs to be. You know, uh considered cold storage being one of them like making sure that if there's a container that has a certain um guarantee of of how how the temperature is you know, dfds wants to ensure it and make sure that this is also being you know, ensured to their customers.

B

uh We want to also do some predictive uh maintenance right, like you know, working with sensors there's a lot of you know, machine learning involved to understand eventually uh when something needs to go into maintenance and obviously you know global uh supply chains tracking on the shipments itself. So you know we're talking like really different perspectives here it doesn't look good.

C

Did you just lose connection.

B

C

B

All right uh so um on the uh um so, when we're talking about different little twins in different areas and I'll go go and to about a little bit deeper later, but we're really talking about different aspects right, so we're talking about vessels, but we can also talk about shipments.

B

So here we want to reduce the fuel consumptions we want to have you know the management of these iot devices and you know, do some simulation, but we can go further right. We've got, we've got the uh the vessels we've got the ships, but now now we're on the terminals right and again, right, there's a lot of things.

B

Things moving around things are monitored with different iot devices, and you know we want to support the automation of terminal processes, we'll optimize utilization of new facilities, increase the productivity of of individual personnel and generally again, leverage the data to reduce energy consumption um on the vessels and the trucks itself.

B

There's uh some cooperation with volvo that dfds is doing and really really fancies, fancy uh autonomy stuff, but um they're working together right. So there needs to be some interoperability uh between these uh between these vessels and trucks, um the ownership- uh it might not only be the shoes right. It might also be other things that that wants to have a digital ownership um and with the autonomous stuff uh we you know, enable remote control of these systems is obviously a you know, interesting topic to to look into.

B

So this is, like you know the use cases, but let's, let's there's, there's actually some concepts behind digital twins, which uh will to be as well we'll explain.

C

So, basically, the way that we have viewed the concept and initially tried to to implement, implement the poc around it was that for us you know, the digital twin, sits in between the real world and our control plane applications right.

C

So we have business people operating things on their smartphones or their laptops or whatnot, and then we, they interface with the digital twin and the digital twin, is then tethered to a device using secured communication right with certificates and stuff like that, and thus it becomes this sort of gateway to to talk to the to the real world sensors, and this enables all these different use.

C

Cases like co-ownership or you know, moving stuff around or reacting to sensor, data or whatnot in real time to optimize workloads or optimize fuel, consumptions and so on, and the way that we sort of then reason about it. If you can move to the next slide materials. Is that as such, you know, the embedded systems offer this digital tether in the physical world right. So it's basically something that the digital twin can mount on and take. Control of.

C

The digital twin itself sits in between and then you have the applications over on on the right. Can you just move to the next slide? That's fine. I've been through this already, so just move on to the next one and in general, the way that we've tried to reason about this architecturally is that there's, like seems to be three different concepts at play here. The first concept is what we call the digital twin prototype, and this is really the work that goes into researching how a specific digital twin should be implemented.

C

So this is not just a coding job. It's not just some infrastructure thing. It's really talking with business understanding. How does a vessel operate? What sensors are on the vessel? Who are the different parties that might interact with said vessel, and how can we then go about implementing this in a way where we can first simulate things and then, maybe later you know start bridging it into actually controlling the vessels, because initially, I think a lot of this.

C

If you look at what nasa is doing now with funding, a u.s startup with 30 million dollars is to be able to simulate satellites and or simulate satellites in orbit, so they don't have to actually fire it up there to figure out. If it's going to work right and the prototypes, they are used to explore this thing in virtual reality right so we have at our place, we've done quite a lot of work on doing 3d modeling around our terminals.

C

This will open up for us being able to interface with this in both vr, and I are, and essentially that gives an extra dimension to the digital twin, because it becomes much more physical in a sense right. It's just not this service running in the background. It could actually manifest itself in virtual reality if it needed to the prototype itself is not linked to any actual asset.

C

It's more meant like a abstract class or a template, or something like that for you to sort of look at if you have to implement a given twin and the explicit states of these things makes it easier to to create modular systems, because I think, at the end of the day, you need high modularity for digital twin architectures to be really successful, because they're going to be pieced together from all sorts of different suppliers. Right siemens will have sensors.

C

uh You know other big companies will have sensors and then we have to then fit it into our kubernetes stack with crossplane and we use net core for programming at our company. But you know other people use java. So there's going to be a lot of work around making all this work. The next concept that we work with is the actual instance itself, and we like to say that the instance is very simple, because the instance is just the tether between a service and its corresponding sensor and in general.

C

There should always be a one-to-one relationship between this, and the idea is that the instance is linked to a unique physical asset, for instance, my nike air force, whatever they're associated with at most one prototype, to make it easy and they rely heavily on eventual consistency and they need huge amounts of data to actually provide any real value for us over time.

C

Right because I worked for many years before joining dfds with raster and their machine learning, division of 60 people, they spent millions of kroner sort of trying to figure out where all of this was headed and they found that for them. Predictive maintenance was the good the big thing because they had like a terabyte of data coming in and as they started sort of analyzing this they they started becoming capable of building systems.

C

That could predict that if a grain of sand in a windmill engine started making a certain sound frequency, then within three months that grain of sand would make a two inch furrow on the metal that would break the engine right. So this is the the essence of what we want to get to. Is these sort of instances that can tell us that hey now, you need to go clean, your windmill engine and or your ship needs this or your trailer is leaking, so the temperature seal is no longer valid which will destroy the covert vaccines.

C

The last thing is, then, the thing that doesn't really exist right. This is the aggregate. This is the vessel. In essence, the aggregate is simply just a collection of twins right. So, if you think about a dfts, ferry or a ship, we have like sensors for weather. We have sensors for fuel, but we also are now introducing electronic door locks on our cabins right. That means that when truckers they come in and park the truck, we could issue a digital key card for them.

C

That would allow them to control that specific thing, and that means that the ship as a whole is the spoon right. It's not, it doesn't really exist, but it kind of exists. It's just the sum of its parts, and the idea with the aggregates is that they have direct access to all the sensors that they are sort of composed of and thus often you can look at the aggregate as the I don't know, gateway or the control plane or whatnot.

C

But the idea is that it works as a as a mechanism for to facilitating uh command and control. So let's say you wanted to reboot all your sensors on a ship, obviously having to connect to each sensor individually, would require a lot of work having a gateway which just say you know, reboot. All the sensors on this ship is a lot easier.

C

So so these are sort of the three cardinal concepts that that we've been working with and then matthias and I have been sort of trying to fit that into the crossplane architecture. And here I will let mathias continue.

B

Yeah, so um I guess that's the the question where you need to show hands who's, familiar with crossplane, all right, the rest come to our booth afterwards, right, we need to talk so um no crossplane, um maybe yeah, let's start with kubernetes, uh so so, first of all uh kubernetes and has been coined, you know again and again as a platform for building platforms right. So you know when tobias was looking into this um and we talked about it, it was pretty obvious.

B

You know you know, kubernetes being being a good good platform for building this, and this is like, first of all, just the general concept um of this declarative model and this constant reconciliation right of of just making sure that the desired state is, is actually matching the uh actual state um that that was just a concept that that matched very well the distributed problems that that we looked into obviously with kubernetes, and you you tried to you, you saw some of these hints right, the uh our control plane, so the things that are managing all these right they used to be.

B

They need to be running everywhere right. They need to be running on the ships on the terminals, maybe in actually in a container itself. So it's like you know, there's a gazillion ways of of of kubernetes needs to is everywhere and it needs to be everywhere for our for our setup. Now.

B

Last but not least, right kubernetes- and you know this better right being at this conference- there's a gazillion tools out there and that's obviously great right, because you don't need to reinvent everything right. You need to, you know, apply standards, standard interfaces, but afterwards you can, you know, just you know, use tools right and I I've named a few here. It doesn't really matter the the point is as you're building up this platform right, you can start, you know, uh stitching building blocks together uh that what works so kubernetes was a was a get-go.

B

It was a pretty. You know we from the get-go. We we knew we wanted to do it, so the next step was was cross-plane. So crossplane in my world are two things.

B

First of all, it's a way of getting a cloud api into kubernetes right, so you can think of like any cloud service that you want to manage, and now you can. You have that cloud service in your in your kubernetes cluster, so not only creating the deployment for creating uh uh for creating your application, but you also have like a cr or a crd that describes a database in the cloud right or a database with a couple of other things, stitched together, and you can basically just create this.

B

So there's this one-to-one mapping and a crossband. We call these managed resources and you can just like hack away in kubernetes really fun now the next thing. uh What crossplane does is that it allows to compose multiple of these managed resources into some abstraction.

B

The usual way of how we see this applied is for developer platforms, so there's some abstract interface. For some databases it defines some abstract properties like small, medium, whatever right and you can. A developer can just create the database and behind the scenes there is, you know something in aws, gcp, azure or whatnot on-prem build up, but the developer wouldn't really know so these are, like you know the rough concepts and I don't know if you kind of like you know getting like talking about digital twins.

B

You kind of already see some of some some of that alignment.

B

So here's an example right a simplified example. Obviously, but you know we talked about the terminal right and all these terminals there's a couple of you know, there's trucks on there and there are ships- um and you know they, obviously you know- uh contain or have containers on board.

B

So if we think about it- and we take one one of it- uh oh yeah, and by the way uh that's the bar code for uh the qr code. For for the example um and I've just updated uh two hours before uh the presentation, I've updated the example. Let's see if it still works um so, but as an example right we have a a composition. So so we have the ship thing right, which we want to use and as to be a set. It contains of multiple iot devices, multiple sensors.

B

So here's just a couple of examples like a gps sensor, fuel sensor, weather sensor that could be, could you know a gazillion, and what we're going to see in a minute is that you know we compose all these together into a composition and that composition is actually on how I say it implementing it, a a a definition, an api that we can then later later use so and we've been arguing about this right.

B

So this is not the next slide, so we definitely need to come back in detroit to talk about it again, but uh I like to think about it. You know, as you know, the um the definition of these things is a prototype right. The xrd is the prototype.

B

The actual composition of these different sensors together um are the is the aggregate, and the digital twin instance is actually the single ship that uses all these these sensors, but again we're walking through different different models. This is how how I'm going to show it in a minute all right. So where are we on time? We've got. I think we're good we're good to go. I'm all right, all right, so.

C

Let me see if you can fail fast, so we can get moving.

B

All right, can you see still my screen is the is the font. Okay.

B

Was that? No, yes, all right all right where, where are we? No ships, no ships in here all right. So basically, what I have is a local kind cluster with um a crossplane installed right. Nothing, nothing, really, nothing really, fancy uh you can install crossplane um and and and you need to talk, uh install a couple of providers and I'll I'll show in a second what it is, but with a plain uh crossplane installed and with with a provider installed, we've got a couple of crds here that are new to the system.

B

First of all, it's about crossplane itself, so you see here a couple of cross plane itself, but if you, if you, if you take a close, look, there's already a new crd here, uh gps types, which I'm going to show you in a second which are the managed resources which a provider did did provide us, um and I can get the providers here all right, so we've got, I've got two providers, a gps and a noaa provider. Just you know for for the example um of what I'm showing all right.

B

So in my in my um uh platform here that I've defined I've basically defined a container a ship, a terminal at a truck, etc. So let's install these right, so you can think of like okay. So far, it's just plain kubernetes and some little bit more runtime and let me install let me install the platform right and now all of a sudden what we, what we have are a definition of of our domain model. Right we've got: we've got ships, containers terminals, trucks, but not not only the definition but how they are made up.

B

So um I can show, maybe not sure if this works ships xrd.

B

I think I should have loaded right. So this is this: is a cross plane definition right. uh So what? What? What is it? What is a ship right? This is our our definition of it.

B

It basically, you know, there's some metadata on how this is called in different different perspectives, there's a way of how to represent it, which which you'll see in a second but most importantly, it has the api definition how to interact with it right- and this is it's just a ship and the um imo, which was a mediterranean organization, international mediterranean organization, something it's an idea to find that ship right.

B

So um I applied these crds right. So so uh I'm not sure. If did we look yeah, so we've also had have a couple of new crds. That's up and running all right. So let's have, let's have actually some some ships uh uh installed. So uh just you know you can look at these ships right. So there's you know pretty. You know pretty simple yaml right. You have a spec that defines a ship with an imo.

B

Here we have containers with some ids terminals, yada yada, nothing, nothing too fancy, but before we install them right, let's, let's, let's, let's, let's look at this right so up here right, we've got terminals and ships and so far none of these terminals and trips have been installed right. There's there's none right, there's no! Currently, currently our current control plane doesn't manage any of these right. So let's, let's install some and what you see now, is that there's uh new ships, new terminals and ships are coming up right.

B

So we've got a couple of terminals: the norway, belgium, yada yada and we've got a couple of ships, and we also have- and- and you should have seen this right- the the different positions of these ships.

B

So these are these different managed resources, these different sensors, these distant gps devices and, as the you know, sensor picks it up it propagates it up to the ship, and now we can we now we can work with it right.

B

So we've got six ships here, one is in hamburg, one is in copenhagen surprise, um and you know you can you can now you can now work with it right and the gps sensor is just one sensor in this demo, but you can like think about, like very other sensors in in also right, like the fuel sensor or uh the weather sensor, that interact and that you can work with inspect and use in your platform as as you go all right. um What what else?

B

So um you know you, can you can query for different things right, so um you know you can query query for all the terminals in denmark. You know, that's that's pretty pretty simple, there's only currently one, um if you, um if you you know just you know, have your standard kubernetes rate. Maybe maybe your you know. Terminal output is not as nice, so the trucks are here.

B

Maybe I actually want to know a little bit more and then you know you do different queries and now I can get all the trucks that are are in copenhagen.

B

um But you know a digital twin, one of it is, is showing the apis uh or making sure that all the sensors data is actually updated and shown in the control plane right. So if, if the gps is updated, now the the the um the ships are currently not moving.

B

That's a because they're, not moving and b, because it's a dummy provider and there's no actually gps divided. But you can imagine that this is you know, actually, you know continuously updated, but you with a digital twin. You want to interact right. You don't only want to see the updates, but you actually want to interact.

B

So you know just just as a you know, simple simple example: um you know if, if the, if the um actual terminal is represented as a label, what we could do you know is just simply update that the humber viking ship is going to hamburg now right, so we can basically just change the desired state uh to to hamburg. Now uh you know we. I talked with dan a little bit about it. He said, like you know, maybe we should we don't. We should actually create a policy that actually updates this.

B

So this is like for our next demo uh the update, but it's uh you know it shows the idea of of of where we're going so to be assessed. I should keep it up um time.

A

Keep the time minutes.

B

Three minutes left all right, so the the last thing that I'd like to say, I'm just going to leave that up here right. You can obviously take these crds and move it to another kubernetes cluster right there, the digital twin, the the representation and you can manage it from that kubernetes cluster, but you can also move it to other communication. This is just a very simple example, but you you know you can. Obviously you know we talked about tools. There are probably other tools that you can work with. It's just crds right. That's all.

C

Cool cool. Thank you, matthias for a brilliant demonstration. I have one more slide just to go through before we finish off and take a few questions as we've been working through this for the last, maybe three to six months. You know: we've come to some conclusions that we hope we can share with the audience. If you are considering this, it's still very early days, there's going to be. You know a long period of trying to overcome technology and people challenges.

C

In order to make this a success, they will benefit greatly from the abstraction, because one of the things that truly inspired me for this was the us army strike fighter fighter project where they made. You know an air gap, kubernetes installation inside the plane.

C

So if we think about each vessel having its own cluster, moving a workload from one cluster to another represents the transfer of said acid, from a ship to a terminal or for a terminal to a truck and so on and so forth, and that really provides a lot of out of the box functionality for us in terms of tracking our stuff and they can easily provision things with the with cross plane right. So if I move my twin from one geo location to another, it can have different.

C

You know, strategies for either just remounting the cloud resource or moving that to another geographical location. If the rds that this specific twin needs is too far away and that causes latency or whatnot- and these I think the next steps in our journey to try to look at. How can we implement policy engines? How can we implement even more command and control logic within the twins themselves, so they can be more responsive and- and you know, do the hollywood style call back. So we don't constantly have to pile them, but they will.

C

You know push us and, I think, maybe mauritius in the audience he's been doing some great work on event enabling crossplane and matthias, and I also want to try and build on that, because we see that as an absolute essential thing for this to succeed, we also did some fun work with asia, iot hub that you can find here. This was the initial poc I did before matthias and I started out, and I think with that we will conclude our talk and we will leave it for the audience to ask questions or meet us outside.

B

So there's there's a one or yeah there's one thing to take I'd like for you to take away right. Crossplane is just about using some api right and we're talking about iot devices. So the question for you is like what api are you managing might be a cloud? It might be a cloud and something else. How can I combine this and manage with crossplane?

B

And that's that's, like you know, get that into your head and then you know see see what other nice examples uh we have and yeah do. We do. We have quite time for question. Let's say two questions, any questions.

B

B

Is the mic on? I can repeat the question if it's not on.

B

Do we have a 3d representation? We.

C

Have unity models of our terminals and stuff, but unfortunately I didn't have time to source them for the presentation. So hopefully, when we go to kubecon in north america, we will have those things available. Also.

B

All right there's another question.

A

uh Do you also use crossplane to provision other kubernetes clusters, or just for this api.

B

So uh that's a great question. So generally you know, crossplane is about you know talking to any kind of api and, if you're, if you're a kubernetes developer. The first thing that you reason about is other kubernetes resources and then also other kubernetes clusters. And yes, the answer is yes. We generally do this. We do this for specific cloud clusters like an eks cluster, but also generic general kubernetes clusters. Yes, so both.

A

One more question.

A

B

Noticed that you have a your own custom provider. Yes, how can you build such one if I want to yeah there's a gazillion ways, thanks sammy for the question that there's there's a gazillion ways to build providers, um I've just hacked it all along and that's the other thing. The nice thing. What I love about cncf and open source projects. You can build these right and I'm not I'm a product manager. So I'm not like this.

B

Most seasons go developer but I got it, but I got it running so you can just build it on your own. There's like nice templates, but you can also generate one there's different generator types that you can like use, different sources where you can generate one so there's different different possibilities to create one.

A

Cool, I think, we'll need to to cut it here.

B

All right, thank you very much. uh You you find us at the the different booths at the crossband booth and that bam booth. If you want to grab a sticker, there are stickers up here, have a great conference, and I will see you for a beer.