 Okay, let's get started. We'd like to thank everyone for joining us for today's CNCF webinar, Multi-Cluster and Multi-Cloud Service Mesh with CNCF's Kuma and Envoy. I'm Jerry Fallon and I will be moderating today's webinar. We would like to welcome our presenter today, Marco Paladino, CTO and co-founder of Khan. Just a few housekeeping items before we get started. During the webinar, you are not able to talk as an attendee. There is a Q&A box at the bottom of your screen, so please feel free to drop your questions in there and we'll get to as many as we can at the end. This is an official webinar of the CNCF and as such is subject to the CNCF Code of Conduct. Please do not add anything to the chat or questions that are in violation of the Code of Conduct. Please be respectful of all your fellow participants and presenters. Please also note that the recording and slides will be posted later today to the CNCF webinar page at cncf.io slash webinars. And with that, I'll hand it over to Marco for today's presentation. Thank you so much. My name is Marco. I'm the CTO and co-founder of Khan. And today I'm excited to be showing you the result of many weeks and many months of work that we have done with the community and the users around QMA when it comes to the multi-cloud and multi-cluster deployment of a service mesh. So when we look at service mesh deployments, multi-cluster, multi-cloud, including a hybrid of containers and virtual machines in the same service mesh, this is probably one of the most complex service mesh deployments that anybody or any product can address when it comes to, when it comes to service mesh. Like I said, my name is Marco. I'm the CTO and co-founder at Khan. QMA was initially built at Khan and then donated to the CNCF Foundation as a sandbox project, making it the first envoy-based service mesh to ever, the first envoy-based service mesh to be donated and accepted in the foundation. So today I'm going to be presenting an overview on QMA, what it is, why we built it, what problems it solves, and then we're going to be firing up the terminal. So I want the majority of this presentation to really be a live demo where you can see how QMA can run in a multi-cloud and multi-cluster deployment. And then on top of that, we're going to be doing a few things, like for example, enabling zero trust security, enabling traffic permission ACL, traffic routing across different zones. So let's not waste any time, let's dive into it. QMA was born in September 2019 by Khan and it was donated by CNCF as a sandbox project. When we built QMA, we built it because if you're familiar with Khan, Khan is a connectivity company that started by creating an API gateway, Khan gateway back in 2015. And one of the things that our users and enterprise customers were asking us was to be able to extend the connectivity use case, not just at the edge, not just across different applications, but also being able to support connectivity across all the services that our applications are going to be using to provide the final product. And so as part of that, part of that work, we started working on actually using service meshes that were available out there and integrate them within our offering. And we quickly realized that those existing service meshes were not going to be a good fit for us for a couple of reasons. First, service mesh and service mesh projects out there for a long time have been very hard to use, very hard to scale, very hard to consume. Most of the service mesh products and projects that are available to us are not going to be supporting multiple meshes on top of the same cluster, whereas we are working with users and with customers that do not necessarily always want a large service mesh across every application, across every line of business, but they want to be able to provision different service meshes that are isolated from each other on top of the same control plane without having to deploy one deployment of service mesh for each mesh that they want to create. So they needed a more scalable system to support multiple teams in order to reduce the team coordination that is required to manage all of these meshes, and as well as to improve security so that one team cannot possibly bring down another team's mesh by, for example, introducing a wrong policy. And we needed something that could support not only Kubernetes environments, but also virtual machine environments, as well as being able to mix and match those virtual machine and container environments together within the service mesh, not only on the data plane, but also on the control plane. Long story short, none of the projects out there were working for us, and this is why we decided to build Kuma. Then after building Kuma, we donated Kuma. And Kuma today provides a very unique set of features that we are not going to be finding in any other service mesh available in the landscape and in the market. And thanks to that very unique set of features, today we're seeing lots of adoption when it comes to users adopting Kuma to build their own service meshes in either a single zone or multi-zone capacity, as well as enterprise organizations that are using Kuma to create a service mesh that the enterprise architects can then utilize to provision connectivity across each application and each team that the application teams are building. And the thing about service mesh, it really is that the features that service mesh provides, all the zero trust security, all the observability, all the traffic routing and traffic reliability, these are things that if we do not use a service mesh, are things that we have to build ourselves. And so really by using a service mesh, we can improve the efficiency of the application teams that can stop managing the network and they can focus on the things that they should be working on, the products, the applications, whereas the architects get control of that connectivity so that we can build more reliable architectures moving forward. And so we'll be working with the users, or we'll be working with organizations when it comes to Kuma and we're seeing lots of success into deploying a service mesh that just works in production. Now, before I jump into why Kuma is unique, let's look at why we actually need a service mesh. And usually there is many different use cases but we can sum them up in these three main scenarios. We need to have a service mesh because the more applications we build and the more connectivity we create. And connectivity, it is at the backbone of every modern application. If our connections are not reliable, they're not secure, then our applications are not reliable as well. They're down. And if our applications are down, then our business is going to suffer from it. So it's important that as we build more applications and inevitably we introduce more connectivity as we transition to microservices, as we create more and more of that connectivity, we can connect the services together in a reliable way, in a secure way, and we can then observe all that's happening among these more complex networking topology. And so service mesh has been used to do that, to discover the services, to connect them to enable that reliable connections so that the teams don't have to build that by themselves in a fragmented way, but we can provide that as part of the underlying infrastructure provisioning that the architects are provisioning to the application teams, whenever the teams want to create something, as well as we can enable zero trust security models to assign a certificate and an identity really to every service that's running within our mesh, as well as encrypting the traffic from one service to another. And then finally, understanding what are the traces, what are the metrics, what are the logs among all the services that we are running. And in Cuma, by the way, it is not something that we can use only for traditional APIs or API protocols, like HTTP or GRPC, but we can use Cuma in front of anything that makes or receives a request over TCP, which means that we can use a service mesh, not just for the APIs and the services that we create, but also for services that we adopt. For example, a database, for example, an event collector like Kafka. So anything that makes a request or receives a request is a service for service mesh and Cuma supports that. And if you look at Cuma from a high level overview, Cuma is a control plane that implements the XDS API that Amvoy supports. And so we bundle Amvoy as our data plane proxy technology in Cuma in such a way that in order to use Cuma, we do not need to have any prior experience or knowledge of Amvoy. Amvoy can get quite complex when it comes to the configuration. It's a very versatile networking primitive. And we understand that in order to use a service mesh, learning Amvoy may be a non-starter for some users. And so we abstract away the bootstrap configuration of Amvoy, the entire Amvoy experience into our Cuma data plane process. With that said, there is still a chance for power users to go deeper and change the underlying proxy configuration that Amvoy supports by using what we call the proxy template. So long story short, Cuma is a control plane that supports Amvoy, where we support the sidecar model of Amvoy. We automatically inject a sidecar next to our services, next to our workloads. And we can run these service mesh on both Kubernetes and virtual machines, on both single zone deployments or multi-zone. A zone can be a Kubernetes cluster. It can be a platform, can be a cloud, can be a VPC. We can slice and dice it however we want and we can connect the service mesh across both of these environments. It is built for the enterprise architects that deploys the service mesh once across all the zones that they wanted to support. And then they can create virtual meshes for each application, each team, you know, from one installation of the service mesh. It is easy to install, easy to use, easy to scale. Simplicity really has been a big focus when it came to Cuma. We wanted to simplify how Cuma could be adopted in the community and among the user base. And we really spent lots of time to think of simplicity really as almost as a feature. We wanted this to be simple to use. And because it is part of CNCF, it is built with the same governance, the same neutrality, the same openness as any other CNCF project, like for example, Ammoi, which we support natively. So why Cuma? Let's take a deeper look into the feature set that Cuma provides and then let's look at this feature set live in a demo. So Cuma, like I said, was built in such a way that it would scale across multiple applications, not just when it comes to creating one large mesh, which is the simplest deployment of a service mesh we can think of, but also when it comes to provisioning individual meshes that we can then create for each application, each team, or each line of business. And so really when it comes to Cuma, we wanted to create one deployment that could virtualize all of these different meshes. In each mesh, it is going to be powered by its own certificate authority backend, which means that there is isolation built in among these different meshes. By doing so, we deploy Cuma once and then we can run it as many meshes as we want. It is universal because it runs everywhere. It runs on Kubernetes, it runs on OpenShift, it runs on virtual machine-based workloads and we can also mix and match those workloads. Cuma creates an overlay across our Kubernetes clusters, across our virtual machine-based workloads and on top of that overlay, we can then apply service mesh policies like neutral TLS, like observability, like circuit breakers, like health checks, like tracing, in order to govern how the traffic and the connectivity among all of these different environments it is going to be working. And we can do that in a quite flexible way. Every new service or any new environment, any new workload that is being created in Cuma also supports custom attributes that we can use in order to determine how those policies, for example, like routing should work in a very fine grained way. For example, we're working with some financial users that are going to be running a service mesh across multiple countries because they support applications that have been deployed at a global scale. And so one of the things that they need to be able to do is preventing some traffic, certain traffic path to ever leaving the country. And so they can tag their workloads with a country name, for example, and then they can apply traffic routing policies on top of those attributes that are customized, in this case, the country, to determine how routing works. And because of the built-in multi-zone connectivity, we provide one of the best implementations in Cuma of multi-zone, multi-cluster, multi-cloud support that the industry has ever seen when it comes to a service mesh. And I'm going to be exploring this in just a second. If you're familiar with service mesh, which I assume you are, you know that this has two benefits. First and foremost, the application teams, they stop managing the network. They become consumers of connectivity. Likewise, we're using Kubernetes to abstract away data center operations. We're going to be using something like Cuma to abstract away connectivity across any applications that the developers are building. Before service mesh, the developers were also building that connectivity. They were managing it, they were securing it, they were observing it in different programming languages with lots of fragmentation. And so they become consumers now of that connectivity as opposed to being the builders of that connectivity. And this in turn makes them more productive. And the architects who are provisioning this infrastructure get control on the most important thing that any modern application must do right. And that is connectivity. It is built on top of Envoy. We really like Envoy as a networking primitive. We didn't think we needed to build another networking stack for managing the data plane proxy communication. So we're effectively leveraging the Envoy runtime to do all of that, which as you know, it is very stable and there is the entire industry is rallying around it. So Envoy was definitely the best choice for us when it came to supporting a data plane technology. And we made sure that we could do things in a very simple way. And so for example, we're going to be seeing in the demo enabling Mutual TLS with automatic CA creation and automatic certificate issuance and rotation. It is a one click process with Cuma. One click, we deploy it, we run the Mutual TLS policy and everything else has been taken care of by Cuma. As well as we provide, Cuma provide some integrations with Prometheus, with Grafana, with tracing providers. We also have chips with Grafana dashboards out of the box. So if you want to get some charts real quick, we don't have to build them from scratch. They are coming with Cuma itself bundled into the project. And so this is again, in the context of making sure that everybody could get up and running very quickly. Of course, there is then traffic routing policies that allow us to do blue green deployments, allows us to do cannery releases in a standardized way across every environment. And if you look at the multi-zone support that Cuma provides, this is really where Cuma excels into deploying, into supporting complex networking environments. So first and foremost, when running a service mesh in a distributed way, there is going to be two different challenges. First, how do we propagate the service mesh policies across each one of the zones, the regions, the clusters that we want to support? And second, how do we enable cross zone connectivity from one region to another? And Cuma does that by supporting this global remote control plan separation, which automatically takes care of all of these forests. So we're going to be having a global control plan that we're going to be using for changing the state of the service mesh across every zone. So the global is the primary, if you wish. It's the read-write control plan that is going to be used to apply service mesh policies across any mesh we may have, across any zone we may be supporting. And then we have as many remote control planes as the zones that we want to support. The remote control planes are going to be synchronizing with the global control plane out of the box. So whatever we're pushing inside of the global control plane will be automatically distributed across any remote control plane. And the remote control planes will be the ones in charge of accepting connections from the data plane proxies that we're going to be starting in each one of these different zones. By having a global and remote control plane separation, we can abstract away how policies are being synchronized in a distributed service mesh, as well as we are creating a highly available service mesh in such a way that if one remote stops working for whatever reason, the other remotes are not being affected by it. And when the data planes are starting into each one of these different environments, they're connecting to the remote, obviously using XDS over GRCP and HTTP2. And in order to keep the stack quite similar, we have built our own extension of XDS called KDS, the Cuma Discovery Service, that enables the communication between the remote control planes and the global control plane. Therefore, we're going to be using GRPC and HTTP2 all the way from the data planes to the remote and from the remote to the global control plane. So this has been created with a goal of keeping things quite simple when it comes to this distributed communication. Now, the second problem is enabling the cross zone connectivity across these different zones. And to do that, we have enabled a different mode for the data plane. So you can have a data plane in standard mode, which is a proxy effectively, and you can have a data plane in ingress mode. And when you deploy the data plane, the Cuma data plane in ingress mode, then that can be used as the ingress to accept traffic from another zone into the zone where the ingress is being deployed. So the ingress is effectively the component that out of the box enables these cross zone communication. When a request comes to the ingress, we're doing an SNI lookup to determine what is the ultimate service that we're trying to consume and then the ingress will be in charge of proxying that request to the service that the original source service wanted to use. Now, the ingress alone would not be very effective if it didn't come with a built-in service discovery. And so the remote control plane also comes with its own service discovery that allows us to discover not just the services within one zone, but also it's a distributed service discovery, also the services that belong to a different zone. And so depending on our traffic routing rules, depending on the health of our services, the discovery is going to be resolving our services to either the local zone or to another zone in order to enable these cross zone connectivity out of the box. All of this, it's much harder to explain than to watch and see live. And so I want to pull up my terminal real quick and then show you how these works with live, with a live application or live demo. Now the zones, by the way, can be, like I said, different Kubernetes clusters. They can be container-based, but our zones can also be virtual machine-based zones. And so for example, we can run this on AWS EC2. We can run this on top of any virtual machine, physical data centers. Cuma also supports environments that typically other service meshes do not support, like for example, AWS ECS or Fargate. Yes, you can use Cuma instead of AppMesh for those Fargate deployments and for those AWS ECS deployments as well. And that is thanks to the universal capability that we have built, not just on the data planes, but on the control planes as well. Cuma comes with a GUI out of the box. We're going to be using these quite extensively to look at the state of our resources. It comes with native Kubernetes, CRDs. If we run on Kubernetes, it comes with universal CLIs and HTTP API. We can effectively integrate Cuma with any automation we have built inside of our environments. It comes with policies, policies that implement security, traffic control, observability, and we can also leverage all the underlying policies and filters that Envoy supports by using the proxy template policy that Cuma offers. And so effectively we have available to us all the Cuma policies as well as the entire Envoy proxy, ecosystem and filters, if you want to go a little bit lower level. And one of the things that's quite interesting, when working with the users and the organizations that are using Cuma today, one of the things that we've realized is that Cuma has been used for a couple of reasons. So besides implementing a mesh, Cuma has also been used to accelerate the transition to Kubernetes. Kubernetes is for many users a journey. It's not an end state. So they're moving to Kubernetes, they're slowly shifting and transitioning their applications to Kubernetes. And what we found out was that supporting virtual machine-based workloads in combination with container-based workloads allows for a more gradual transition to Kubernetes, therefore making it easier and simpler for anybody to adopt Kubernetes more and more. And then another thing that we've noticed is that ServiceMesh help some of our users reduce costs in a significant way when it comes to adopting a ServiceMesh. A ServiceMesh implements a client-side load balancing pattern for example. And by using a ServiceMesh, we can remove the enterprise load balancers that we're using today in front of every service, therefore saving a significant amount of money. For some of the users that have been using Cuma, we're talking about a seven-figure, eight-figure cost saving into removing away all those enterprise contracts for load balancers and enterprise load balancers and so on by using a ServiceMesh. And because we don't have that extra hop in the network, the ServiceMesh, even though it implements a cycle proxy pattern, it implements, it improves the overall performance of our systems because if there is no load balancer, there is no extra hop in the network, therefore we can get rid of extra network latency. So we can accelerate to Kubernetes, we can reduce costs and we can improve performance. There is another mode that Cuma supports for the proxy data planes. There is the standard one, then there is the ingress which I've explained and then there is another mode and this mode is called the gateway mode. You know, ServiceMesh for certain use cases, it's not applicable. Let's say that we want to expose APIs to an ecosystem of partners. Let's say that we want to expose it to mobile apps. Well, in these kind of examples, we cannot support a ServiceMesh because we cannot force a third-party developer to install a cycle next to their applications, even assuming that that's even possible. And then we don't want their cycle which runs outside of the organization to connect to our control plane which runs inside of the organization. The cycle obviously requires connections to the control plane to provision the certificates and the policies and so on. So there is, for example, at the edge, you know, ServiceMesh cannot be used as a pattern in a practical way. And so what we're seeing is more and more users more and more customers trying to do this in combination with an API gateway. Now, to do that, Cuma supports a gateway mode in our data plane. So you can use any gateway out there to work with Cuma in order to apply any user governance or onboarding flows you may have on the gateway itself and then enter the mesh, you know, as effectively making the gateway an ingress to the mesh. And of course, Cuma, you know, that built Cuma also is the maker of Cuma gateway which is also open source and we built an open source integration with Cuma but he could be using any gateway really. And if you want to egress the mesh, we also have the same concept that the gateway data plane that can be used as an egress point for all traffic that's going outside of that mesh. So effectively Cuma understands the North, South, East, West requirements that a typical user has, a typical organization has and we try to address that with the gateway data planes when it comes to connecting different mesh together or at the edge and with the ingress gateway when it comes to connecting services inside the same mesh but across different zones. I think that it's time for the demo so we can see how Cuma runs. And so right now I have deployed Cuma on a quite complex environment. So I'm running Cuma on AWS and I'm running Cuma on GCP. It's a multi-zone deployment that is also multi-cloud but the thing is on AWS I'm running on EC2 whereas on GCP I'm running on GKE. So this is a multi-cloud, multi-region, hybrid, containers and virtual machine service mesh. And now we're going to be seeing how all of these works together so that we can enable connections from EC from the virtual machines to different regions and different zones and vice versa. So first and foremost, you can see that there is a Cuma global container cluster being deployed on GKE and this is where I have my control plane running in global mode. The global control plane, it is important so that out of the box without having to build it ourselves we can synchronize the service mesh policies across multiple zones. And then on each one of these other clusters, Cuma East and Cuma West for example, as well as in EC2, I'm running my remote control planes. So if you remember the diagram, the architecture there's going to be one global and then one remote for each zone we want to support. And so there is this zone here with a remote and then there is going to be these different zones here East and West, each one with their own remote as well. And this is running on containers EC2 and this is running on Kubernetes. So let's connect to the global to see what's the state of our resources. So right now I'm connecting to the global GKE control plane and if I look at, so first and foremost if I look at the namespaces we're seeing that the RIS 1 Cuma System namespace and if I look inside of this Cuma System namespace we can see the control plane running. I can now port forward the control plane so that we can access the GUI. And by default it is on port 5681. So if I do this and I open a new browser, by the way the GUI it's running on top of the API that Cuma provides. And so for example, if you go on slash meshes we can see all the meshes that we have there is three different meshes right now but if I go on slash GUI, we can see the GUI. The GUI it's built on top of the same restful API that you can integrate with anything else. So there's nothing that the GUI does that you cannot automate. There's going to be three different zones. There is a zone on AWS, there is a zone on GCP GKE East and then there is a zone on GCP GKE West. And I've deployed a very simple demo application for each one of these different zones. The demo app it's quite simple. It's a demo application backend that provides a front end we can consume with the browser that allows us to increment a counter on Redis. I'm going to be showing you the demo app in a second. It's quite simple. So there's going to be two services, Redis and demo app on AWS as you can see here. So these are the attributes that Kuma automatically creates but we can also create our own. And then there is going to be our demo app and our Redis being deployed on GCP GKE East and we're going to be having the same thing demo app and Redis being deployed on GKE West. So basically each zone has the same demo app and Redis being deployed all over. And of course that is not a requirement. We could have demo app being deployed only on one region and Redis on another. We can really mix and match our workloads however we want. And we're going to be having three different ingresses, data planes, one for each zone AWS, GKE East and GKE West to enable these cross zone communication. As you can see here I have three meshes. So right now if I go on my default mesh I see all my data planes but let's say that we want to create a mesh for another team. These are empty, it's an empty virtual service mesh on top of this deployment of Tuma. So this is really one control plane to support the entire org. So let's go ahead and consume the application so I can show you what it does. If I go on my, on EC2, so right now I'm consuming the demo app that's running on virtual machines. I can see that the demo app allows me to increment a counter on Redis and Redis right now it's also running on the same zone as the demo app. So this is telling us what is the counter value for the Redis instance that we're hitting and what is the zone that we're consuming. Now, because I don't have mutual TLS enabled right now cross zone connectivity it is not going to be working. So let's go back into looking the stats for my mesh. As you can see here mutual TLS is disabled. So let's go ahead and apply the mutual TLS on top of our default mesh so that we can enable this cross zone communication. So let's do that by exploring all the policies that Kuma provides. We're adding more and more policies on every release. So we're very quick into introducing more and more capability but you can find here what you would expect from a service mesh. So let's apply mutual TLS. There is different backend providers that you can support. We can create our own certificate authority automatically if you use built-in or you can provide your own certificate and key. So for each example, there is a Kubernetes example that we can apply with Kube-Cattle and then there is a universal example for control planes that are running on virtual machines that we can apply with Kuma-Cattle, which is our own CLI. So this is for teams that are not familiar with Kubernetes yet but the resource it's quite similar to the Kubernetes one. So in order to enable mutual TLS we're going to be updating our default mesh object with a mutual TLS property that enables the following mutual TLS backend. And this backend is a built-in backend which means we are generating automatically the certificate authority, root certificate and key and automatically we're going to be rotating the proxy the data plane proxy certificates every day. So it doesn't matter how many zones we support how many meshes we have, how many proxies we're running and connecting to the mesh. You may have 100,000 data plane proxies running. Kuma will take care of rotating those certificates for us within all of these different proxies with one resource and this is the resource we're going to be applying. So let's go ahead and update my mesh so that it provides it enables mutual TLS. Now, one of the things that you will notice is that as soon as I enable mutual TLS the traffic will stop working if we do not have a traffic permission policy. So let me show you this live. So I'm going to be auto incrementing, auto incrementing Redis and then pulling up the terminal and from the terminal I am going to be I am going to be applying these resource that we have just the mutual TLS resource for the default mesh. So as soon as I apply this in a press enter we'll see that the traffic will stop working and that is by design. Now that every service has an identity we need to enable traffic permission to determine what service can consume what other service. And we can do that by specifying what source can consume what destination. And so we can use any Kuma tag. In this case, I'm using the Kuma.io service tag. You can find all the tags from the GUI for example. I'm using the Kuma.io service tag to determine that every service must be able to consume every other service. And so I'm going to go here and create the echo command I'm piping inside of Kubernetes inside of the global control plane to determine this behavior. And as soon as I do that two things are going to happen. The traffic will start working out of the box and out of the box without no other traffic routing rule the traffic will cross zones automatically. So if I enter this we create a traffic permission and now depending on the load balancing routing policies we have for now I'm just using the default one. We see how our virtual machine demo application is consuming different Redis instances one for each zone that we support automatically out of the box across multiple clouds across multiple regions effectively creating a hybrid mesh that is also containers and virtual machines at the same time. The counters are going to be different depending on what zone, what Redis I'm going to be hitting when it comes to the increment. And so we're going to be seeing that depending on the zone this is going to different regions. These happens out of the box. Right now once we install the global, we install the remote all of these happens out of the box we create this network overlay that really simplifies simplifies how we manage connectivity across complex networking topologies. Now let's say that for example we want to redirect our traffic to one specific zone. So we don't want these round robin across multiple zones but we want to only target specific zones. That's very simple to do with Kuma. With Kuma we can go and apply the traffic route policy which allows us to determine how we want routing to works across our services and across our zones. So let's go ahead and create a traffic routing policy. Let me make this a little bit smaller. So let's create a traffic routing policy that for these traffic path it is going to be load balancing the request in this way that we're going to be specifying. So let's go ahead and fetch the service name for our demo app. So basically I'm saying I want all sorts of traffic that's being originated by our demo app that consumes Redis, the Redis service. I want 100% of the traffic to consume Redis to consume Redis on just one zone. So I want to consume Redis on let's say on GKE East. So I can do this and then I can echo these instead of Kube cattle in order to apply the resource on my global control plane. If you notice here, the global control plane is automatically propagating these policies across all the remotes. All of that happens out of the box. We don't have to build it ourselves. So if I enter this traffic route after this traffic route is being propagated automatically we should be seeing our demo app only consuming this zone, the GKE East zone. So let's go ahead and create the traffic route. And as you can see, eventually it will be propagated and now we're hitting only one specific zone. Let's say that we want to go 50% on AWS, 50% on GKE. We can still do that by updating our traffic route by having a weight of 50 to GKE East and then I'm gonna just copy paste this and a weight of 50 to our AWS zone. And if I update my traffic route policy and I enter this, we should be seeing AWS coming up half of the times. This is how simple it is to route across different zones, different environments or perhaps even do data center traffic shifting in case we do have problems with one data center and we want to keep the uptime of our application running. So far, we've seen the multi-zone deployment with multi-cloud, there is much more that we can see when it comes to Cuma. As a matter of fact, I also did a presentation at ServiceMeshCon at CubeCon this year. So I suggest you look at that recording as well to see how we can enable observability metrics as well on top of all of this. And then of course you can go ahead and apply any policy that Cuma offers to enable these behavior. This is the ServiceMesh that we have created to support these complex networking environments. And now let's say that there is another team wanting to have its own mesh, their own mesh because they are working on another project or another application. Let's say that they're working on their mobile app, we can easily create a new mesh policy inside of our cluster. Oops. And if I refresh, we're now having our mobile app here and this is a brand new mesh that can support any workloads, any data plane proxies from pretty much any of the zones that we support. So one deployment of our mesh to support as many service meshes as we want. And like I said, there is much more to it that we didn't show the gateway data planes but I'll be happy to accept requests for future demos so I can show these kind of things. All right, so to recap, we are running Cuma on top of multiple clouds, multiple regions, Kubernetes and virtual machines on AWS and GCP. With the term, we have provisioned some applications on both environments that we've seen the zero trust security model with neutral TLS automatically been provisioned. We've seen the traffic permissions. We can also explore the GUI to determine our policies and our routing rules by the way or the CLI. We've seen the traffic permissions ACL. We've seen traffic routing for data, for zone shifting across VMs and containers. And we took a look at the GUI that Cuma provides when it comes to understanding what is going on when it comes to our resources. So thank you so much. And if you have any questions, I believe that now we're starting our Q&A session. Thank you very much, Marco, for a wonderful presentation and demo. We have plenty of time for questions, 15 minutes to be exact. So please feel free to drop any questions that you have into the Q&A box. We have one already. Can we... I forgot, sorry, sorry, sorry, sorry. I forgot, I'm so sorry about this. I forgot about one thing. Starting from tomorrow, we have our CONC summit. It's a digital and free event where we're going to be exploring more and more how technologies like Cuma that are vendor neutral, part of CNCF are going to be working with, for example, the CON gateway. And we're going to be seeing the full stack on how that works together when it comes to even more complex networking topologies. Okay, thank you very much. So we have a couple of questions here in the Q&A box. Can we please see the traffic logs tab or could you talk briefly about the capabilities? Yeah, so for traffic logs, so let me go back to the browser. We can see that traffic log is a policy we can apply on top of our meshes. And by using traffic logs, we can determine what source of traffic, what traffic path we want to log from the service mesh to a third-party system. Like for example, Splunk, like LogStash or like really anything that accepts a TCP connection. So we can log to files, we can log to TCP. But the nice thing about this is that as you can see here, we can also specify different backends for different traffic sources and path. This has been built because some of our users, they are going to be logging traffic that's being executed from different data centers or different zones to different systems, not necessarily always to a centralized system. And so you can determine if you want all traffic to be logged inside of one Splunk instance or LogStash instance, or if you want to segment how logs are being applied across different zones and across different traffic paths, right? And you can also exclude traffic paths from logs that perhaps are too sensitive to be logged. So there is a lot that goes into this, but the logs, they provide, we also provide examples on how to visualize these logs using LogStash. But basically the logs are going to be creating a new line for each request that is being either sent or received from inside the mesh. And usually logs are going to be applied in combination to traffic metrics and traffic traces to have a better context of the observability within the service mesh. And when it comes to observability, there is also default Grafana dashboards that you can use. And starting from the next version of Kuma, we added 50 more charts that allows us to determine what is the state of any mesh may be running on top of Kuma across both the data plane to data plane communication path, as well as the control plane to data plane communication path when it comes to the control plane itself. So there is a lot of work that has been done when it comes to observability. And logs, metrics and traces are basically usually typically being used together to provide the full picture of our traffic. And this is L4. So it is working for any system that's part of the mesh, including databases, including log collectors, anything that lessons or makes requests over TCP. Okay. Kuma seems awesome. I'm wondering about the drawbacks. Is there any overhead due to the global control plane? We are making sure that the overheads are quite small because we, you know, even with Kong, we understood that being able to support smaller instances for our cloud vendors, it is going to be a big component in the overall ROI of using a service mesh. I know that your boss is looking at the overall experience when it comes to deploying a mesh. And so we built this in such a way that it could run on smaller machines and it could be very optimized. For the global, the only thing that we need is a cluster of Kubernetes or virtual machine that is going to be accepting the resources into the global control plane. You can run the global control plane in a highly available way. And the remote control planes and the global control planes can be scaled independently, which means that if you have some zones that have more data planes than others, you can scale them independently. You do not have to scale them all at once the same way. So if anything, it gives us a little bit more flexibility when it comes to running a distributed service mesh across multiple clouds and across multiple zones. So the drawbacks, if I have to find one, it is that we have to find a place to deploy the global. So the global would be yet another component that needs to run, but it's inevitable if we want that automatic synchronization across different remote zones. Other service meshes, for example, they do not provide that automatic synchronization, which means that you're on the hook for building it. With Kuma, you don't have to build it. It comes out of the box and it comes under the form of a global control plane. If we need to control certain data to be in a zone that is different from where the global control plane is, how will that look like? Yeah, so in my demo, the global control plane cluster was not processing any data whatsoever. So we were using the global to apply our mesh policies like mutual TLS, like routing, like traffic permission, but the global per se was never on the execution path of our requests. The requests were going directly from one zone to another without going to the global. And so we are keeping that outside of the global control plane. It is only being used to automatically propagate these service mesh policies in a way to propagate the resources across the remotes. But I'm not really sure if I answered the question. Could you please repeat it? Yes, bring that back up here. If we need to control certain data to be in a zone that is different from where the global control plane is, what will it look like? Yeah, so I think I did actually answer the question. So yeah, so the data never ever reaches the global control plane. The global control plane only communicates with the remote ones. The remote control planes are the ones that are in charge of their own zone and the proxy and the requests are actually never even hitting the remote control planes in the first place. They're going directly from one data plane to another. The remote control planes, if the state of our data plane proxies changes is on the hook for then updating the data plane proxy configuration, which is built on top of Envoy. Okay, now what's the story if the global control plane goes down? Is it a SPOF, single point of failure? I think that's what it's referencing. If the global control plane goes down, the remote control planes are going to be having the latest snapshot of the service mesh resources that we have applied. So if the global control plane goes down, nothing will happen on our remote zones. That is one of the reasons why having global and remote, it's actually comes in quite handy for a couple of reasons. Yes, we get that automatic synchronization, but then also we get a little bit more high availability because each remote control plane is fully responsible of the wrong zone. And if the global goes down, it's not affecting, and if a remote goes down as well, it's not affecting other zones. So effectively it's as if each zone is living independently from each other. But when the global control plane goes back online, then if you apply new service mesh resources, we're going to be propagating those as soon as it comes back online. So the only problem you would have is not being able to change the state of your mesh resources, because we need the global for that. But again, the global can also be configured in a highly available way. And so we can deploy QM and such a way that we can tolerate those kind of failures by distributing the global control plane as well. Excellent. We have about seven minutes left for questions. So if anyone has any last minute questions that they would like to ask, please feel free to drop them into the Q&A box. We have plenty of time. If you want to run the demo, I just ran, you can go on kuma.io slash install. It provides installation for pretty much different environments. Like I said, it's not just Kubernetes, but it's also virtual machines. Of course, it's Helm, OpenShift, and so on. And if you go on documentation and you go on multi-zone mode under deployments, we show the instructions that you can run to install the global control plane, to install the remote control plane, and then to activate the remote control planes. So everything that you've seen can be easily replicated by following the docs. Okay. Do we have any more questions at all from anyone? Today, we've seen a very complex deployment of service mesh. Of course, this can also be used in a standalone mode, which have not been showing, which is the more traditional service mesh deployment in one zone, one cluster. There's only one control plane. There's no global, no remote. There's only one control plane, and then you have data planes connecting to it. So that's also an option. How does kuma behave in a single Kubernetes control plane, the multi-zone data plane? Yeah, so let me see. I think I actually do have, I should have a mini cube running. So let's see, I can show you right now. So this is a mini cube running on my computer. Actually, it's not. Let me show you real quick, but basically you can install it. Where's mini cube? I don't have it actually, I do not have it. So this is gonna take probably a little bit too long, but let's see. I need to restart my mini cube. But basically you can type these one line of, you can use our CLI, you can use Helm charts, but basically if you want to install kuma in one control plane, it's kuma-cattle install control plane. You pipe these instead of Kubernetes, kuma-cattle, and that's it. There is going to be a standalone deployment of kuma within that one specific zone. Now the thing, the difference between standalone mode and multi-zone mode is that in multi-zone, you can add more remote zones, you can add more, you can distribute the mesh, whereas in standalone, you only have one control plane inside of the cluster. You can scale it, you can run it within the context of that cluster, but unless you have a flat networking topology, you're not going to be able to support other zones. Unless, like I said, you have a flat network topology, so you have data planes running outside of that specific cluster that can directly communicate with the control plane. So right now, I do have an empty mini-cube. If I want to install kuma in standalone mode, I just pipe this into, oh, I'm sorry, I think I'm running, I'm running the wrong version of kuma. Anyways, you can do this one sec, let me show you real quick, oh, no, it's not working. It's not working because my environment is messed up. That's quite all right. Yeah, so let me, let's see kuma, let me enable, let me enable this, okay, perfect. Okay, so if we go inside of the kuma, I've just downloaded and I run kuma cattle, install control plane, and I pipe this inside of kuma netis, let's see, this time it should work. There we go. So now we have kuma running in standalone mode inside of my mini-cube, and this will create a kuma system name space, and inside of this kuma system name space, we're going to be having the control plane, which is now getting downloaded and going up and running. And so if I do, if I do the pull, if I do port forward, these local control plane, these local control plane from my mini-cube, we will see kuma control plane. We will see my standalone control plane up and running. I know that it's standalone because if I go to the GUI, it says standalone up here in the top right corner. So this is a standalone, it's a standalone kuma netis that only has one zone, we cannot add any more zones. And so we can deploy, we can deploy the demo application and automatically we'll be injecting the car, and these would be the standalone mode of running the service mesh. If there is any other question, I can answer those questions. In your demo, can you explain why the traffic stayed in one zone before Mutual TLS was enabled? Before Mutual TLS was enabled, traffic from one zone could not leave the zone. So I was consuming my demo application from AWS and it was increasing the counter of Redis that also was running on AWS. As soon as they enabled Mutual TLS and traffic permissions, we enabled security across multiple zones and kuma at that point enabled automatically cross zone communication. Of course you can enable or disable this behavior by then applying a traffic routing rule that determines if you really want that traffic to be happening across multiple zones and if you want that traffic to stay within a zone. And by the way, here we automatically injected the control plane in standalone mode and we can see that the demo application is up and running and the data planes are online. So we automatically inject those cycle proxies for you. And now this is ready to go. So from here, we can now apply Mutual TLS, we can now apply traffic permissions, observability and so on. Okay. Is it possible to change from a standalone to a multi-zone easily? This is a very good question and that it will be, but not now. If we, in order to change from standalone to multi-zone, we effectively have to start a new deployment of the mesh and then make those workloads part of the new deployment of the service mesh. So we cannot so far, we cannot transition a standalone control plane to a multi-zone control plane just like that. But good news, it is something that has been requested before and it's obviously something that we want to change in order to enable a more easier consumption of Kuma for those environments that over time may be growing across multiple zones. So that's one answer. And the second answer is, if you know that you're running Kuma in something that is going to become multi-zone, then I suggest deploying it as a multi-zone since they want. If we think that that could be an option. But we're working on this to make it simple to upgrade a standalone control plane into a global control plane. Okay. Well, that dose about does it for all the time that we have today. I'd like to thank Marco again for wonderful presentation and demo and thank you to everyone for taking time out of their day for joining us today. As I said before, today's webinar and slides will be on the CNCF website at cncf.io slash webinars. Thank you all again for attending today. Take care, stay safe, and we will see you all next time. Thank you, bye-bye.