 Hello, everyone. I'm Christina Lin and welcome to the YBYOC is the Future of Cloud Architecture. So basically, the idea of this webinar will be talking about what is bring your own cloud architecture and how we implement it in RAPenda. So kind of just to give you an idea of what kind of what we're going to go over today is kind of just going to go over what is BYOC and what the different deployments kind of deployment situations out there. And probably the majority of time will be going over the entire architectural overview of how things were separated and how we take care of things internally within our control plane. And last but not least, I'll walk you through a demonstrations of how our clients can actually connect to the BYOC environment, kind of just show you how things are things work practically in the users in user size, kind of just with that. Next is if we take a look at what streaming services were provided today, you got two kinds of different deployment options that people offer, right? The first one is more like the self-hosted where people would download the software and they would then install the software on top of their own cloud or they will install it in their data centers and they will manage the entire fleet of clusters under all. So this is a very traditional way of how we operate from the beginning of the time. And this is good, but it kind of introduced some of the drawbacks of the longer ramp time because in order for a company or a department to train a person, I really understand all the things underneath the hood, like how your infrastructure needs to be laid and how do you design your cluster to be running, it takes longer for people to understand things. And also there's constraints of resource, you got to have to pre-plan on the number of clusters you need, you probably have to know what kind of CPUs or hardware or disk space that you want to allocate it to this cluster. So there's a longer time of planning. Therefore, the time taken for you to actually get things running will be a lot longer. And of course, there's going to be operational costs because the person that you've trained needs to, you know, this person needs to live, you've got to pay for this person. And of course, this other operating cost on making sure that everything runs correctly and, you know, setting up with, you know, high availability costs and all that kind of stuff needs to be justified. But the benefit of this kind of deployment is that you get complete control of access. So you control where everything is deployed, you control how many clusters, how many brokers in your clusters, you can control how your data is going to be secured, you can control the policy that is applied on top of your, on top of how your system are architected and everything. And because you know where everything is deployed, then you can kind of put everything right next to the workload. So everything is closer. So you can, so the network latency is a lot less compared to the others. And last but not least, a lot of the company already have committed spend with a lot of cloud providers. So they can take advantage of that of, you know, using the promises resource that they were, they were going to use on top of the cloud. So these are the things that people kind of like and don't like about the traditional self-hosted version. But then because of the rapid, you know, software development, people wants to have a quicker way of getting things up. They don't want to spend, you know, six months or, you know, six months of planning and getting people hired, getting people trained on all everything. So what they do is they would ask vendors to create a version to set up that platform for them. So this one is purely hosted by the vendors. The vendor is going to set up the services. They'll provide a couple of end points. They'll give people like where they were installed and then the services will be up and running. So the benefit of that was in increase of flexibilities. You don't have to commit a lot of resource in advance. You can slowly add the resource as needed. You don't have to have a dedicated SRE to understand what the cluster is. You have access to all the experts. Since the vendor hosting that services or the data sharing services in this case has been running this for a long time. So you get access to the expert right away. The problem with these kind of deployment is the lack of transparency and lack of control, right? Because you don't control where everything is deployed. You don't control, you don't see how they were implemented. You don't know how what's going on underneath the hood because all you see is a class where you don't see how everything was kind of installed and how the policy was applied in terms of security. You don't know where everything was hosted. Sometimes they don't give you that. So that also introduced some kind of network latency because you don't know if it's as close to your workload or if it's kind of like an ocean away from your workload. So that's kind of the things that people complain about when they're doing vendor vanished services, right? Those kind of services on service, software as a service type of thing, right? And then there could be a network loophole. If you're not connecting everything correctly, you might open up unexpected connections, then that will introduce problems, right? So that is why we said BYOC has been really taken over in our case. A lot of our customers really like this idea of ring your own cloud. So we always know there's a middle between the self-hosted and the vendor hosted version because this one is that we will as an expert in running the string data streaming platform, we kind of just deployed everything into the client's cloud. So what clients see is that they have completely access control over things because it's deployed in their cloud environments. The cluster is running in their cloud environment. So the data stays within the cloud of the vendors that they get, they get to apply different policies in terms of accessing the platforms. And because the vendors can deploy, so we can deploy our platform closer to a workload so you can decide where you want everything to deploy so you can introduce a lot less network latencies. And I think one of the most people find intriguing especially with a C-level conversation is that you can use the committed span because you don't have to. So you can have your own discount in terms of talking to the cloud providers instead of going through another layers by the vendors. But then you also get the benefit of all the experts that you have from the platforms or from the vendors or from us. So we give you the expertise of, hey, this is how you should install a rep and a cluster, this is how you should patch it, and this is how the infrastructure is going to look like. So you've got all of that in terms of having that running in the client environment. So that's really very good. I think a lot of our customers are looking into this because they want to have the freedom of controlling their own data. They want to have it all in their environment but they also want to have access from the expert. They don't want to invest too much in the beginning of hiring a lot of experts running this platform. So before we dive deep into the architecture, here's a quick overview of what we talk about as a data streaming platform. So for those of you who is already really into the data streaming world, you probably know about Kafka, right? So Red Panda is another C++ implemented version of Kafka. So basically what the client can, so basically we are a replacement of Kafka. The client side doesn't have to know anything but Red Panda can replace Kafka right away because we are Kafka API compatible. So the client can directly talk to a Red Panda cluster. But the difference is that we choose to implement in C++ and it's very, very that you know C++ can have a lot better accessibility of managing and controlling the lower layer of your computer CPUs and memory. So therefore we bypass a lot of JVM garbage collections where it's going to take time to dump the heap out as well as controlling the thread. So the context reaching in the CPU can take a lot of time in nowadays where we're going to avoid all of that by controlling thread, by controlling all the thread, by constantly writing in sequence and kind of kind of fits really well with the you know the Kafka mentalities of everything locked sequentially, right? So you kind of just put everything with the thread into allocated memory and puts things directly into the storage which is going to be either through at MEME storage where it's a lot faster nowadays. It's never the blocking the bottleneck of you know writing data into a storage place. So kind of that's how we see it today and that's why people like most of our customer loved using that and using it to replace Kafka. And so that's kind of just a quick overview of what we do. So we are a data streaming platform that provides data streaming services for all the clients. So we are very cloud friendly, so we can deploy on a lot of cloud environment either with dedicated machines or we can deploy that on the Kubernetes environment. As you can see, so be right before we dive into the architecture, let's start with the first pull. What are you currently using to stream your data? You're using Red Panda, are you using MQTT, Apache Kafka, CallFluent, Pulsar, AWS, and SKS or any other things. All right. So before we dive into the architecture, let's take a look at from our customer's lens. So the way that we wanted to build is to make it as simple as possible for our users. So to make it as easy as it can be for them to have a very smooth adoption of the streaming platform in their own environment. So what they need to do first, we'll give them three steps. That's all they need to do. First of all, they need to provision their appropriate access credentials. So we'll have to, they'll have to give us, they'll have to create a, not give us, but have a credential that allows creation of EKS, creations of setting up networks, setting up storages and all that. There's a more detailed configurations that's in our documentations, but basically this is all infrastructure rights that we need to have in order to set up that infrastructure, but all this are not shared with Red Panda. We don't keep that. So this one is for the user to create, but they also keep that in their own environments. Once they have everything set up, all they need to do is go into Red Panda Cloud and sign up for a account. So we know that you are a customer with us. And then what the customer needs to do is to think about a couple of things, the throughput. The throughput is kind of how we size our clusters. We tend to be very efficient on using the resource, so we don't need a lot compared to a traditional Kafka deployment. But if you think about it, we want to know how much you're expecting, how much throughput, the bigger the throughput, the more worker your need and the more internal traffic that's going to have within, if you think about data streaming. And the second thing is you need to give us your core providers. Of course, we need to know that as well because that also determines the infrastructures of what command that we need to give in order to install your infrastructure. And then the third one that we will ask you, the customer is what is your connection type? Is it publicly available or is it internally used only? So this we use this to configure the networkings. So do we need to install internet gateway or net gateway for internal access or do you want to isolate it within a virtual private connection so everything needs to be connected, configure in order to connect internally. Another thing is where your workload is going to be. So this is going to contribute to your network latency. So you want it to be closer to your workload, as closer to your workload as possible. So therefore we're going to ask you about regions and also availability zones. This will contribute to the high availability strategies that you want to determine. So if you have more availability zones that your full tolerance will be higher. But again, because it's across AZ, so there's going to be a certain cost or a certain type of cost of transferring data between availability zones. So it's going to be a little bit slower. But then it's more fault tolerant. So depending on what you need, we can all cope with that. But in default, what we do is we will, even within the same availability zones, we can use different placement groups to ensure that all the nodes are in different places. So they don't, so when things go wrong, we'll still have that availability for you as well. So that's something that we do underneath the hood that we don't share with the customers, but it's all think about. So once the customer decide on all this, all they need to do is to kick off the deployment. And that's it. They will have a cluster running in their cloud. That's how simple it is. And that's why our customer love it. And that's why we think BYOC is the future. But in order to get everything running, it's, you have to have a lot of nuts and bolts built underneath the hood in order to make it run as smooth as simple from the customer's point of view. And I'm just going to take you over some of the things that we did during the installation. So first of all, the customer will need to obtain a rependa ID from us, from our cloud environment. So basically what they need to do is they just need to register and they'll give them an ID. And they'll have to log into either the AWS account or Google Cloud account. Currently, we provide two cloud, two cloud for hosting their clusters, Google and AWS. So they need to log into that with their credential in their environment. So this is not shared with rependa. And then what I went up, what they need to do is to also download a tooling called rependa keeper, which is a tool that uses to administer, install, you can do whatever with rependa. This is a great, this is the tool set. So basically what then you do is just download the tool and run a command line using the BYOC functions underneath rependa keeper. And this rependa keeper is going to then kick off the deployment from customers, from customers environment. And then it is going to talk directly into the cloud environment of what they have, and then install something called agent. And this agent is also powered by Terraform. It's going to then set up all the infrastructure need to run the clusters. So it is going to first set up the networkings. So make sure that it's in the right subnets, the right VPCs, you know, I'm talking AWS service because I'm more familiar with AWS. But, and then you also have, then we also have to think about the storages. So we'll spin up the storage for that. And then because we want to make sure everything's flexible, it's easy to add another node and all that for the future purpose, we'll install everything on top of the Kubernetes. So, and after that, we'll then install the rependa cluster in the Kubernetes cluster, along with another pretty useful tool, which is rependa console that is going to that users see what's going on inside the cluster. And this is an other small artifacts and utilities in the cluster as well. But mainly the cluster and the console. And that's kind of what happens when the users kick off the environment. And after that, they get to see their cluster running in their environment. And when, so this is kind of what happens if the customer wants to access and take a look at what's going on inside the cluster. So basically, what I need to do is log into the Cloudy UI, which is hosted by rependa. And what happens is rependa is going to show you where everything is. And then it's going inside the rependa UI. We, we added a, we did something pretty clever. So we merge whatever is inside rependa console. And we kind of just, then we stream that information directly from rependa console into the customer site, into the customer's computer. So it's coming from the browser. It's going into directly into customers browser instead of going through rependa. So we don't see anything because inside the console will show you how many topics you have, how many petitions you have. And then inside topics will show all the, all the, all the messages or the events that's streaming, all the data that was streaming into the topics. So we don't want to know that for rependa. So everything is going directly into the browser of yours, doing the Cloud UI, using the Cloud UI login as the single sign-on endpoints. And then it's going to show you what's going on inside the cluster. And if we want to operate, say if something goes wrong or if there's needs to be an upgrade, so something that's really cool about BYOC is that we let the user decide when they want to upgrade their clusters. So it's not up to us. It's up to the users because everybody operates into, in the same, in different pace, right? Some of them were in the slower pace. Some of them were faster. So we want to make sure that they, they can upgrade on their own needs. So that's kind of why we did that. And so whenever there's, whenever the user decided to upgrade their clusters, what they, what happens is that the cloud environment are called control plane. So we kind of divided everything into two different things. The control plane was, is kind of like a control centers where it's hosted by rependa. We decide on the things that can be upgraded, which versions you want to upgrade it to. And the data plane is where the actual streaming platform is operating, which is serving its need of streaming data into, for different clients and stuff like that. So those are the two different planes that we have. And so what happens if, what if you want to patch it? So basically the control plane is going to issue a command and that is going to say, hey, patch to the next version of the cluster. So, and then it's going to break it down into smaller tasks instead of like doing a big patch, it's going to break it down to small tasks. And we'll track all the, all the, all the, all the tasks. And then the agent itself is going to pull. So instead of us sending information into, into the agent, the agent actually pulls. So it can do a reverse, in the reverse directions of pulling the tasks, constantly pulling the task from the you, from the control plane into the data, data plane. So once the data plane sees the command is going to run the command, apply the changes, and then you see everything upgraded one at a time. So that's kind of how it works. And then the, so that's, that's how the command line flows. But we also collect some of the data, the publicly open metrics coming from, we don't see the actual data in the thing, but we kind of collect all the rep and our metrics showing partitions and leaders and see things going both wrong, but that both gets sent back to cloud UI. So we monitor the health of your cluster, making sure everything goes, goes, okay. So the benefit of going through what the benefit of this design, why we go through all this pain of designing it like this is because first of all, by deploying it, by deploying into customers cloud, you get to decide wherever you want to do, you have more visibilities, it's closer to your workload. And if something is wrong with the control plane, something goes wrong in rependa, what happens is it's not going to affect the actual data plane of serving the services, because the agent is doing a pooling. So if it couldn't pull anything, that probably means that I don't have anything else to do. So the control plane kind of just keep doing what it's supposed to do. And if the customer and then if it comes back up, it's going to come back up and start working again. And if the customer ever don't want to work with rependa anymore, they can simply cut off the connections between the two and then still operate on their own. So the isolations of two planes and making sure that the two planes operate independently kind of helps when designing. This is kind of a big concept for us when designing the BYOC. And here is a quick view of how our cluster components were deployed. So we have all our brokers and all our brokers deployed in Kubernetes. Because the hardest part of running a streaming data platform like all the other databases and all the data related product is the data, we don't want to lose any of them to keep them safe, to keep them reliable. We want to make so the hardest thing is to keep the state. You cannot simply spin up an informal pod and hoping that if something goes wrong, it's going to recover. It is going to be hard and it's going to take time for it to recover if it's informal. So what we did is we did that with stable set, making sure that if something goes wrong with the pod itself, your persistent volumes and everything that's stored underneath it can still operate. And we have an operator that kind of looks after all the services running on top of the Kubernetes and upchanging things independently. The console is also deployed into Kubernetes and there's a bunch of smaller software utilities that we kind of run on top of that as well. And we also connected, we also offload some of the historical data back to the S3 to take advantage of that cheaper cloud storage. So everything gets offloaded that as kind of how we deploy our cluster on top of the cloud. So if you think about our control plane, our control plane is in order to actually serve that really independent data plane, there's a lot of things that you need to take consider about. Well, the first thing is different versions because different customers spin up their environment different times. And because we also allowed that user to update, upgrade their services on their own, like deciding on the timing of that. So it is crucial for us to kind of provide them and to understand where they are, versions they have. And because there's just way too many components in the infrastructure side as well, like moving parts. So we have to make sure that everything that we release is a certified one. So what happens inside our control plane is whenever we were developing new features and all that kind of stuff, it goes to a proper CI phase and all that is very simple. That's very, everybody does that. And when we get to the release pipelines, we have a, we have verifications and scans for everything, such as the co-quality, container scans, library dependencies, scans and all that, making sure that it's all running. So it's a certified release. And with this certified release will create a software built materials. And each certified built materials kind of represents a snapshot of how this one is verified and we'll use that for the user release so we know where they are. So when the user comes in and when they were asking for a new versions of Red Panda running on the cloud itself, so basically what happens is it's going to pull from the certified cloud release and looking at what's the most current release what we have and then pull the S-bomb into the software built materials into our control plane API. And this one is going to take a look at it and then store the username with the S-bomb. So we know how they were deployed. And then what happens that is we have a, then we replicate this using CDC. So everything is just kind of stored into a database. Then we use a change data capture mechanism to export all the events, all the things that's happening to a Red Panda cluster underneath the hood. The reason we're doing that is because there's a lot more internal operations. And so we want to have multiple receivers or consumers of these events and kind of react up on their own. But the most important one was the one that goes into the workflow. Because the workflow is the actual control of how we kind of wanted to install and how we want to deploy or patching or change anything in the data plane as well. So this one kind of controls everything. So once this new S-bomb gets sent into the workflow, the workflow engine is going to kick off a new workflow. And that is going to break the entire workflow into different tasks or activities. And then that gets break into our, and then that gets picked up by our agents and then agents going to apply that into the data plane. So that is what's happening in the control plane. And that's kind of what's going on in how do we deliver a more secure and controlled software supply in terms of that. And if you think about the workflow, right? So when the things goes into the workflow, the workflow engine is actually, it's, we use temporal for our workflow engine. But we also build a couple of different like interface in like a proxy interface in front of the workflow server. In case that we, in case that any version change or any API change or anything, we use GIPC as our endpoints as it's easier to convert that into res and all that. So our, we have an agent proxy that is going to be used to talk to our different customers. And whenever there's a new installations or new patching or anything, a new customer coming, they will kick off a new workflow. And each workflow will then deploy, will then be, so they're, they will create each workflow and each workflow, because the way some of our using workflow is like, if you think about how we deploy things into, into our cloud, everything is long running, and there can be problems, right? So if you're spinning up a, say, EKS, right? Sometimes it fails or sometimes it just, it takes a very long time for it to feedback. So that's why this workflow is a staple workflow. We keep the long running, we break down things that we can, if we will run things in parallel, if we can, but there are just some things that were independent on each other. So that's why we need to create a work, a code workflow, kind of just take over things. And, and we kind of, and also taking kind of the complex environment as well. So that's what we did there. And then in the workflow, we kind of break things down by nature. It breaks down into different workers and different tasks and activities, and then it gets put into different queues. And then, so we'll, we'll be able to track where this customer is at each, each customer will they'll get their own queue, and that is going to connect to their agent. And all the queues will then show, okay, so why we have this, we're, this person is at creating the VPC stage and this person got to S3, this person's got, you know, their stuff done and the other ones we patch in. So we kind of seize how everything works together. And that's how the workflow was done in our environment. So for zero trust access, so this is for, this is in the situations if we want to break the glass, right, like there's a lot of times when we needed to access, if something goes wrong, unfortunately, hopefully nothing goes wrong. But if there's some things goes wrong, we want to make sure that we follow the zero trust access mechanic mechanism where everything needs to be authorized and authenticated externally, internally, whatever needs to be authorized authenticated through dynamic dynamically. So it's not, it's not static. And it can only be valid for a certain amount of time. So what happens if the red panda engineers wants to see what's going on inside the cluster, what what happens if they'll have to sign on, the proxy services is going to go ahead and then authenticate against this person and ask for permissions from the customers and the customer, once they permission it, they'll receive a token to access the content. And then the red panda engineers will then use that issue token to access the environment. And everything is, it's, and because this is a reverse proxy, so there's no going in, it's just going out. So as well as authentication services, all the same services where everything they do, every single command they put in will be tracked and recorded. So we want to make sure everything is 100% secure. We're not doing crazy things for the customer, but just helping them to solve problems. And that's kind of what we did there. The other, the last, the last thing that we did for observability point of view is the observability. So the things that we did for is kind of picking up two things, log and metrics. So we use the Prometheus to scrape all the things that we did, mostly seeing the balance, if all the, all the brokers are balanced, if the leaders are balanced across different places, if there's no leader partitions, how are the partitions we're doing, how many were signed in particular brokers. So these are the things that we look for and the throughput rate at P99 agencies, P95 agencies, these are the things I would look for in terms of looking at the metrics and see if something goes wrong, we'll know. And the other thing is we'll use full bid to collect data and that gets, that gets collected from Grafana low keys and then sent to us in the show in the Grafana dashboard. So we have access to kind of the log in the broker itself, but not everything else. So that's kind of what happens in the data plane. Everything was all geared towards providing a better services for BYOC secure, mainly, and automated. And that's kind of what's going on inside the control planes. And this is what happens in the data plane. So data plane is pretty simple and forward, nice and simple, similar to what you were doing in a self-hosted version. So Red Panda will be deployed under in a VPC, right, in a virtual private connection, like it's going to be isolated in that. And so in order for you for the other services to access the Red Panda cluster, you can either access it if you have already configured that as public accessible endpoints, then you can access it through the internet gateways and the clients will be able to access it through with the security, some of the security endpoints with ACL, making sure they create the credentials for the users. Everything will be encrypted through TLS, so everything is secured. In terms of services as internal, running internally with the same cloud, in a different VPC, what you can do is you can use VPC peering. I know Private Link is coming up real soon, so there's all these different ways of connecting to the VPC inside the Red Panda cluster. Other things that you can do, other way that I see people do it is using through microservices as it's, so they'll open up microservices and then microservices are going to do some kind of pre-processing of the data and then that streams into Red Panda clusters and then Red Panda cluster just throw all the information back into the cloud storages or pass it back to other services as well, data storage or data lake, whatever they were using. So that's kind of things I saw for the customer use case. Some of the different ways of how we deploy our cluster is when you choose the public accessible cluster, you will be, the Red Panda will be installed in the public subnet and the Red Panda will be installed in the same subnet as your agent, so we don't have a lot of like unexpected network costs and all that and Red Panda, the traffic skills in between will be in between the brokers that's internal Red Panda replication traffic as well as externally that will be accessing through the endpoints, the clients and the VPC connections that was appearing connections that appeared towards different applications outside. So that's kind of what we did, all the listeners are protected through authentications and authorizations. With the private cluster, this one is a little bit more complicated but I think it's for the sake of making sure that everything was secured, so your Red Panda cluster will, along with all the connectors and the console itself will be stored, will be deployed in a private subnet, so it will be isolated from your agent and the agent will be in a public subnet because it still needs to talk to the external control plane, so that's why we still need this public subnet in order for it to connect, but we want to isolate your cluster so that's why we have it private and public and that's kind of the main difference between the two, so kind of depending on what the customer wants and what would they prefer and this is kind of how we did things. Just to do a quick recap on the traffic that's going to happen inside the entire cluster, so we've got north and south traffic, so that's where the Kafka API, so that's actually the streaming, that's the actual streaming goes back and forth between the cluster and the client, so that goes back and forth, that's the north side of traffic, and you have the bootstrap traffic where it's the first initial call from the client to ask for where all the brokers are, you've got schema registry asking for all the data format of all the topics that you offer, like kind of what the what the data shape is like, HD proxy, if you don't want to use Kafka protocol, there you go, you've got a HDB protocol to put your events in or to retrieve events, and then we've also got you know Red Panda console where it's a GUI interface where you can show everything, also the Prometheus matrix that goes out to to our to Red Panda as well, so that's like the north-south traffic, internally in between inside the east to west traffic, that would be mostly mostly the replication Red Panda RPC, you know how different petitions need to be replicated across different brokers, so they need to replicate things, so that's where most of the Red Panda, that would be mostly the where the east and west traffic would be, of course then you've got some admin APIs where if you're going to do admin stuff, it's going to be both going through that traffic as well, south to north control plane, you need to where this is where the agent is going to pull things from and then break the glasses, sometimes if we want to go into the cluster and look at things for you, this is where the south and north traffic, and the other thing is download the software after artifacts, that's the time when we want to upgrade and patch, this is and this is where it's getting all the informations from our SBOM and download all the right artifacts down into your cluster, right, remember that's kind of the south to north traffic, just a quick summary of where everything's are, all right let's go through the next poll, what are your biggest issues with running a streaming data platform, is it the system complexity, administrative overhead, performance concerns, security and compliance concerns or you don't have just this running a data stream data performance super easy, I don't have any problems with that, all right perfect, so I don't think I have a time to show the entire full demo but I do want to really quickly show you what's going on inside the cluster, so I have a cluster that I spin up, this is a entirely BYOC cluster, so when you spin up a BYOC cluster, this is kind of what you see, you see the Kafka API, so this is a bootstrap URL that you see where the user is connecting to, schema registry and all that, things that you see from the north south traffic, right, so this cluster is actually running in my cloud, right, so if you go to, I'm running everything in my AWS, so as I am the owner of this cluster, I get to see what's going on inside the clusters, I get to decide on, you know, if I see one of these or not, all that kind of stuff, so this, I own this cloud, I see everything, oops, I see everything that I need to run this cloud, right, so and I can also see the different VPCs that it created, right, so, you know, VPCs and all that kind of stuff it created for me, I can see the S3 bucket, you know, the things that it's going to dump all the historical data into it, it kind of just, I can see everything what's going on because I am the owner of the cloud and they were just operating in my cloud and I get to see the instinctive instance, which is also running the agent as well, right, the agent is running here, so I've got some agents running, sorry, I have a bunch of stuff in my here, the old stuff, but you get the ideas, you should just have one, by the way, one agent is running inside and kind of that's really simple and easy and then what you can see here is I'm going to start writing sending data in there, right, so what happens here is I go, I have my own Python application that is running inside this cluster, right, so it's in this cluster, it's in a separate VPC, so what happens is I have a VPC peering created, peering connection, so I can start writing information from my, I can start putting information in my cloud, I'm going to start that application by turning it on and then it's going to start pumping information into my cloud environment and if you look at the topics here, you'll see I'm starting to stream data into here and this is the console that I'm talking about, so I'm logging into Cloud, I'm logging into RepHandat Cloud, but what's the funny thing is that all this information was directly coming from my cloud instead of going through RepHandat coming back, so we did something really smart here where we kind of just inject that the console into the browser here, so I can see what's going on, what's coming into my cloud environment, it's coming here, I can see the data's coming in, so I'm going to start another, so this is what happens, I have a RepHandat WLC cluster running, I have a cluster that's here that is going, that is sending data into the VPC peering and I am going to run the QACA's app where this app is going to start reading information from my cloud and what you can see here is now it's picking up data, from here you get to see big things, I have consumer groups, where my consumer groups are now consuming things from my QACA's receiver and I think this one, probably this one, I'm not sure, this one is my client, so all right, so I think that's all the time I have, let me quickly switch back, just to a quick wrap, the reason why we did bring your own cloud is that it's private, so your data never leaves the cloud and the customer loved it, I don't know if you heard about this data sovereignty issues that people were having, you've had a lot of regulations that regulates people from where their data needs to be located, so and then that privacy preserve interactive experiences, right, and then what people like about, what people like about is that it is hassle-free, right, the user only see three steps and they have a running data platform and last but not least, I think it appears to a lot of the CTOs, the C-level users, is that this is going to cost a lot less compared to QACA because we're just a lot more efficient and you get to maximize your committed spend with the cloud providers. That is, that's it, you know what, I think that's open up for the Q&As, do we have any Q&As? Hi Christina, yeah we have a few questions, the first one is, is BYOC more or less expensive than dedicated? It depends, so for the dedicated you get to kind of work with the vendors and see how they're charging you but for the BYOC I would assume it will be a lot less because, well not a lot less, it's going to be less because you control the budget, you kind of control the hosting size and how you're going to negotiate with your cloud providers, so the better negotiation you can do with the cloud providers the less you spend, so I would assume it's all really up to you and kind of how you negotiate the price and play your budget around, thanks. Awesome and then here's another question, are there any use cases where BYOC isn't a good idea? Isn't a good idea, well I mean BYOC is it's just another way of managing your streaming platform, so I don't think there's a bad case around it really because it's from a customer perspective, so I'm a client, I used to write a lot of applications that talks to a Kafka or Red Panda cluster, for me it doesn't really matter, I can just, whether it's operated whatever I can just use it, I guess from an administrative perspective if you already have a bigger team you have hundreds of clusters running in your environment, maybe that's the best case where you want to do it on your own, otherwise I think BYOC is a very nice intro gateway to intro and medium intermediate users where they don't want to have a lot of training people, they don't spend a lot of time operating that, so it's just different types of things, right, so yeah. Awesome, thank you so much and if there are no other questions we can just go ahead and wrap up, so thank you so much Christina 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, have a wonderful day.