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.


Welcome to the science department at the North Carolina School of Science and Math. My name is Amy Scheck and I am the Dean of Science. Now that you are accepted to NCSSM, you are faced with a tempting chocolate box of courses where you can synthesize molecules, shine lasers, or cross fruit flies. There are many more elective choices than you can possibly sample in your two years here. That's okay. We can't teach you everything you need to know and we want you to leave here hungry for more in college. So what do you need to know right now? You will take courses in chemistry and physics and biology while you are here. I will place you into your core chemistry and physics courses where you will get a solid foundation in these subjects. After you've completed the core, you may take elective courses. Because most of you have already had high school biology, we don't require a course survey course. Rather, you may choose from a variety of specialized biology courses. Now, here's where you need to pay attention. You need to think carefully about which single science is your priority for your junior year. Why does this matter? You will likely use this to satisfy prerequisites for upper level electives and because we honor that choice. For example, if chemistry is your priority, you will take chemistry in your junior year. Your second science might be biology or it might be physics. That will be determined by availability. As a senior, you could take environmental chemistry or organic chemistry because you have met the prereq. Alternatively, you may designate biology as your junior year priority. For example, if you take molecular genetics as a junior, you have met the prereq for immunology in your senior year.  Think about your priority science. Read the course catalog. Plan ahead for one science. Accept that you will leave NCSSM with a solid foundation in laboratory sciences, but there's no way anyone can optimize all the courses we offer. Some of you are thinking, I already had this course. Why do I need to take it again? Can I exempt it? There are two answers. First, at NCSSM, we think we offer an enriching, in-depth, hands-on experience that will be new to you. Rather than checking off the courses done, we want you to live it, be open to the course. Second, you might be able to exempt a graduation requirement. If you think you qualify for an exemption, read the course catalog carefully and follow the directions. Welcome to NCSSM. This is the experience of a lifetime. Here you will live and work together with students who care deeply about learning.


Okay, cool. All right. Welcome to redefining burnout, redefining productivity during burnout. All right, let's get this started here. I'm going to kick it off with a little story time. Once upon a time, there was a good little dog who built websites and loved solving problems. She was a hard worker and loved her job. But after working so hard and so long, things begin to change. When she woke up in the morning, her heart would race and her mind would race through all of the things she had to do. And she did not want to get out of bed. Every morning, she would go for a run around the neighborhood. But she found that she couldn't breathe before she even started. When she spent time with friends, she had trouble focusing and being present in the moment. And dogs are known for living in the moment, right? At work, she started finding it difficult to think or solve problems. And as I said, problem solving was her thing, like her superpower. It was like trying to work in another language. She thought, something is wrong with my brain. Maybe a brain boosting supplement will fix my brain. A very illogical thought for a very logical puppy. Then one day, she sat at her desk. She was a lead developer estimating, creating tickets, doing backend development on three projects. Project A had one front-end developer every other week for four hours, and the client just asked for a new feature with a quick turnaround. Project B had a team of developers, but an endless cycle of new complex features and quick deadlines. And Project C had one other back-end developer, but there was a fixed, impossible deadline. She was also three weeks away from Drupal Camp-Bashville, where she was lead organizer. Our poor puppy was frozen with so many competing priorities. She didn't know what to do.  But in the words of Barack Obama, you can't let your failures define you. You have to let your failures teach you. Our puppy didn't fail alone. It wasn't all her fault. She wasn't set up for success, but she did say yes to too many things, and she wasn't managing her stress. Yes, the puppy is me. Hi, my name is April Sides. I am a senior developer at Lullabot, and I'm also the lead organizer of Drupal Camp-Bashville. And today I'm here to talk about burnout. So what is burnout? There's a great resource at helpguide.org where I fold a lot of the basic information about burnout. So you should check that out. The help guide page states burnout is a state of emotional, physical, and mental exhaustion caused by excessive and prolonged stress. And I want to emphasize excessive and prolonged stress. It occurs when you feel overwhelmed, emotionally drained, and unable to meet constant demands. So what does it feel like? There are physical signs and symptoms. Like feeling tired and drained most of the time. Lowered immunity. Frequent illness. Frequent headaches or muscle pains.  My jaw pops. My jaw is all tight. Change in appetite or sleep habits. You know, I have a tendency to eat to avoid work or I have trouble going to sleep at night and then waking up in the morning. And I added a couple here too. Shaky hands and eye twitches. Like I'll be, if I'm like doing too much at one time, my hands will physically start shaking. I'm sure everybody's at some point felt the whole eye twitching thing. That's a really weird thing. And then this feeling like you can't breathe, right? You start doing these big sighs.  You're just dying. You just can't breathe. And there's emotional signs and symptoms. You have a sense of failure and self doubt. You feel like you're not good enough. You can't cut it. Everyone else can do it, but I can't, right? Feeling helpless, trapped and defeated, you know, like you don't have control or there's no end in sight. There's not enough time for all the things. And detachment feeling alone in the world. Loss of motivation. You know, if I'm really stressed out, I had times where I just do not want to sit at the computer. I'll do anything to not sit at the computer. Increasingly cynical and the negative outlook. You know, there's nothing I can do about this. Decrease satisfaction and sense of accomplishment. In lack, I've added this lack of emotion or emotional regulation. So your emotions can be very flat where you just kind of like don't feel anything.  Just the lack of emotional control. And then there are behavioral signs and symptoms. To be withdrawing from responsibilities. And this could even mean like withdrawing from your home responsibilities of like keeping a clean house or that sort of thing. Isolating yourself from others. Procrastinating, taking longer to get things done.  So it takes longer to do things. Using food, drugs or alcohol to cope. You know, this could be relying on stimulants to be productive or relying on the presence to go to sleep at night. Taking out your frustrations on others.  And skipping work or coming in late or leaving early, you know, just avoiding the stress and avoiding the environment where you are stressed. I often tell people when I'm burning out or sort of trending toward burning out that I'm treading water. Right. So I'm going to go into a little bit deeper here with you and say we're treading water in the middle of the ocean with nothing in sight. And it feels like you're sinking. That's what burnout feels like for me. And definitely being in the ocean and feeling like you're sinking is very you can't breathe so that kind of associates it with I can't really breathe in this moment. So who is a risk, perfectionistic people, right, a person who refuses to accept any standard short of perfect. Someone who is pessimistic, you know, thinks negatively, or even has negative self talk. You know, controlling or you need to be in control or you have this need to do it yourself. High achievers are hardworking and successful give 110% no pain no gain, right. And then I added a couple here, people pleasers, you know, they want to make and keep others happy. And selfless and caring people, you know, people who put others before themselves, or they take one for the team, right. And all these characteristics are not horrible in and of themselves right and you may have one or two or you're like me and you have them all and that's okay right. Because you're predisposed not predetermined right just because all you have some of these characteristics doesn't mean that you're destined to burnout you're just more likely than someone who doesn't have these characteristics. So what are the causes.  Lack of recognition or reward for good work. Unclear or overly demanding job expectations, you know, I find that when I work remotely I have a hard time knowing if I'm doing too much, or if I'm not doing enough and trying to get that kind of gauge as well. I'm working in a chaotic or high pressure environment, and there are lifestyle causes. Working too much without enough time for socializing or relaxing. Lack of close supported relationships. Taking on too many responsibilities without enough help from others. And not getting enough sleep. So then there are a few things that have been causes specifically for me, which I call counterproductive productivity. You know, these are things that we think make us more productive, maybe in the short term but actually make us less productive in the long term. Notifications, you know notifications are great in moderation. So our brains have been conditioned to receive a dopamine rush or a or a stress response. Every time we receive a notification, you know, we want to know everything now we want that immediate gratification. But every notification breaks our focus and it takes about 25 minutes to regain our focus after the distraction. Everyone loves a good slack integration, but this is one of the things that really, I think affected me when I was burning out is that we had automated notifications going into slack and slack is a chat app if you're not familiar. We had automated notifications coming in from like when people would create tickets or close tickets and things like that. And they were in the same channel as discussions with the team and so I would spend all day playing slack a mole between my three projects, and it affected my ability to focus. I would get back notifications on my watch and my phone during my morning run I would receive work notifications during your stress response and it was just no good. So we want to manage our notifications right, we want to remove frequent notifications. I've cut back a lot of notifications like email I don't need to know that I just received spam social media I'll only keep like the badge icon. So when I pick up my phone I know I have messages or whatever. I still have calendar notifications on to remind me about cause going to calls and very recently though I turned off the badge notification on my laptop for slack, because I have slack up. And if I don't want to see slack if I want to focus. I don't need to know that I'm getting messages in my doc. I will go and look at slack when I need to know that so that was kind of a cool thing I found recently. I'm used to not disturb mode. So I also use the bedtime setting on my iPhone, which will enable do not disturb mode during my sleep hours that are set. I also have enabled a setting that automatically turns on do not disturb mode when I start a workout, which was the best thing ever to work out and not be triggered by stress right. So when you, when you need to focus disabling notifications is a great place to start. So try website and app blockers you block yourself from websites and apps that you find yourself distracted by or now you can set up limits for different things. I've been playing around with that on my phone. You do it works for you make adjustments as needed. Task switching. Okay, there is no such thing as multitasking. There is no such thing as multitasking. Okay, there's only the illusion of it. Our brains are not designed to multitask. So we task switch right and so even computers tasks which they just do it really really fast. So what do we do when our computer slows slows down or the batteries low, we start closing all our browser tabs, our applications, etc. Right, when that doesn't work we have to repair or replace the computer. So task switching requires energy and causes wear and tear and doing it a lot can cause damage to computers and the human brain. So if we want to think about the, the replacement cycle of technology, you know the smartphones. It's about two and a half years for laptops between three and five years.  What are the effects of task switching? Task switching can cause damage to the brain in the region of that is responsible for empathy and emotional control. Just like notifications, it causes interruptions and time is lost and regaining focus. So that's lost productivity. Right. It reduces concentration and focus. The switching causes a dopamine addicted feedback loop.  They can't stay in one place. I can't stay focused. Or I'll have disjointed conversations where I switch topics after every sentence. It's kind of weird.  It causes stress, anxiety, overwhelm, and guess what, burnout. It affects your impulse control and your decision making. It also affects your creativity because creativity requires concentration. So don't freak out yet. We'll talk about how to repair the brain with self care. So I used to think I was most productive in my office with my laptop screen and my second monitor. So much room for so many activities. Right. We think we if we need, we think we need a wall of monitors to be the most productive. But what happens is we'll think I can put slack over here and I can put email over here and this dashboard over here. So then when I'm working, I can keep up with everything. It just creates more distraction. Right. You just set yourself up. You're feeling your screen with distractions. Right. Or we think, well, I can do something on this screen while I'm compiling or building or whatever on this machine. I can do something over here while that's doing that and you feel more productive. But if you keep doing that, you still have to check on it. Like you still have to be aware of it. So multiple monitors can be useful when you do need to maybe compare when you're doing the same task.  Things like that are where it's helpful or like being creative and you need more space for drawing and things like that. But when you start to feel yourself task-switching, try to downsize to one screen. It becomes very apparent when you're task-switching and then makes it a lot harder to do so because you actually have to cover up each thing that you're working on. It's not all available to you. So yeah. So how do we avoid burnout? First, self-care is so important. The best self-care comes in the form of good habits. So start by taking an inventory of your current habits, your good, neutral and bad habits. And then focus on one change at a time. You know, don't try to change everything at once. So pick a bad habit to remove or add a new self-care habit. And then I highly recommend Atomic Habits by James Clear. It's an excellent book. In the book, he talks about how to build good habits by making them obvious, attractive, easy and satisfying. And then breaking bad habits by making them invisible, unattractive, difficult and unsatisfying. He also talks about habit stacking. Kind of like an if, this, then that. But it's more like after this existing habit, then do the new habit. And it makes it a little bit easier to start a good habit. All right. So we need to form good habits to take care of our body, right? So we need good sleep habits. Getting enough sleep, adjusting your sleep schedule. You know, right now I'm retraining myself to get up to an alarm and not snooze for an hour. And also not social media scroll before getting up in an effort to get my work day started before noon. It's a process. We also want good nutrition habits. All right. Healthy eating and hydration, the frequency of eating and portion size. When I recovered from my burnout, the story that I told previously, I turned eating two fun size Milky Way bars after lunch every day and to have an afternoon strawberry banana smoothie, because I wanted to add more fruit to my diet and I could take a break from the computer in the afternoon. And right now I am well aware that I need to work on my snacking habits. So we also need good exercise habits. You know, this could be as simple as going for a walk. You could do strength training, yoga, sports, cardio fitness. When I quit my high stress job, I should have the stress in about 10 pounds just after quitting. And I was able to add multiple hills to my run and beat my times. It was amazing how much the stress was holding me back. All right. So we also need to form habits that will take care of our minds, right? Relaxation habits are very important. You know, this could look like an adult coloring book. You know, the new hotness of the adult coloring books, be listening to music, you know, watching a movie, journaling, meditating, whatever relaxes you. And I just want to point out that meditation doesn't really look like this to me. Not that there's anything wrong with that, but you do what works for you, right? So instead of the perfect sitting posture in the perfect outdoor location, I prefer to lay on my back for better body relaxation. I can meditate my bed and the couch, my office, wherever. I once meditated on an airplane and in an airport. Remember those things? So when I meditate, I imagine this is what it looks like in my head. You know, it's not about having a perfectly clear head and focused mind. It's a workout for your brain, building your focus muscles. Every time a thought pops into your head, stop it or kick it out. That's one repetition, right? So you can meditate for as little as one minute. So I like to not even track the time because time is kind of a stressor for me. So maybe you want to count those repetitions if that's the way you want to go. The key to remember is that when you breathe in through your nose, expand your belly, not your chest. You know, we have a tendency when we're stressed out that we, you know, we want to get a deep breath into our chest. But what actually happens is that you're stimulating the fight or flight response system and it makes your body more tense and increases your stress.  It relaxes your muscles, it calms your nerves and helps release endorphins in your body that reduce pain. There are a ton of apps out there like Headspace, that was probably the first one I checked out. Calm Fitbit now has a mindfulness feature. My Apple Watch reminds me to breathe several times a day when I don't dismiss it. So while I don't have a meditation habit right now, this was very helpful for me when I was recovering from task switching and induced burn out. And I do it as needed when I feel unable to focus. Meditation is something that can heal the brain when we were talking about damaging the brain with the task switching. So we also want to incorporate play into our lives. You know, it's a great way to manage stress. I like to play video games or build Lego. You could play board games with friends and family, put together a puzzle, things that have like problem solving, just free play with your kids or pets, you know, whatever sounds fun. And we also want to build connection with the world around us. You know, we want to spend time with people, spend time with pets and animals, be in nature. And if you can't get into nature right now, consider getting some houseplants. And then you can also find spiritual connection and whatever that means for you. So in addition to self care, we can learn to work smarter. And we can start by building caring relationships with the people we work for and with. And this will make it a lot easier to raise flags when something's wrong. You know, I have a tendency to be very shy with people that I don't know very well. So when I started at Lullabot, I made an effort to get to know my manager, because I knew it would be easier for me to speak up and be honest when things weren't okay. Right. But it also makes it easier for others to see when you aren't your normal self, because you don't know your limit until you've reached it. And it's sometimes hard to know that you're burning out when you're in it. So build the caring sport, the caring support you may need to check in on you. Right. I highly recommend. Oh, I didn't hit my buttons there. Highly recommend checking out radical candor. It mostly focuses on the manager perspective, but there's a lot of great stuff in there for everyone. Like realizing you can't be ambitious at work and outside of work. That's another recipe for burnout. So we can also manage our time and energy. So we want to schedule time blocks for work and self care. This will help you avoid test switching and make self care another part of your day. I highly recommend the book, Deep Work. It has great tips on working without distraction. A few of these things came from that. Don't respond immediately to emails and messages. Right. Let your immediate response be the exception, not the rule in times of emergency. At the same time, don't expect others to respond immediately as well. Right. That's a hard one. But I think it creates a culture of humanness and leave work at work. So Deep Work talks about having a shutdown routine that signals the end of your day. Set boundaries and say no. There's a whole chapter in 13 things mentally strong people don't do about how to say no for my fellow people pleasers. I know you're out there. The book says if yes has become your automatic answer, start saying, I'll have to look into that and get back to you. Then take a few minutes to consider what you want to do before you make any promises. Right. So for the record, I struggle a lot with these things because time is the stressor for me, but I'm always working to get better. So we want to manage our product projects too. So this is like a project management perspective, but also like if you are freelancer or you're doing your own project, things to think about. You make sure you have clearly defined deadlines and milestones and that your team is aware of them. Manage the pace of work to ensure that you and your team don't burn out. Consider using agile software development methodology. So agile development is all about iteration. You plan in sprints that are usually about two weeks. You plan the work and then probably most important for preventing team burnout is retrospectives because you can adjust the rules of development as you go and then ways that work best for the team for the project and the team. So it might be that you need to work really hard on one or two sprints to meet a deadline, but you can follow up with one or two easier sprints to give the team a break. So if you're not familiar with agile, there are a ton of resources and certification trainings available on the interwebs. All right.  Right. The quickest way is to stop everything. Right. It's not always ideal. It's not always an option, but for extreme cases where your health is compromised, you may not have a choice. If you can't stop everything, we want to identify the light at the end of the tunnel for when you can schedule time off. And this may require working with your manager or client. So you can start by reviewing your priorities, find one focused, you know, top priority to focus on and delegate or postpone the other responsibilities. You know, if it happens to be home responsibilities, you know, think about having a house cleaner or dog walker, something like that. If it's work responsibilities, delegate your work to your team or consider paying a contractor. Right. And think about this as being temporary. You know, this is just to get you through to your time off. Also determine what and when is done.  Deadlines are great, but they can be moved if they're arbitrary. If you need a Band-Aid fix, see if you can take a long weekend. You know, I did that a couple of times this summer because I couldn't take a full week off. So recovery takes time. So the more time you can take off and focus on self-care, the faster the recovery.  All right. So once you've identified the light at the end of the tunnel and you've identified your top priority, you're going to communicate with the team, right? We need to let the team or our manager or clients know our plans. And ask for help with tasks from their heart. This was actually a recommendation from my project manager this summer when things were getting a little wild. I have a tendency to do it myself, right? But asking for help really is a sign of strength because it allows the problem to be solved faster and cheaper. So you can reach out for help in your work slack. You could use the bad camp slack now if you've joined that. Other community slacks like Drupal Slack. You could also try codementor.com. It provides a network of folks that can help you. And you can request nondisclosure agreements when you work with them. And you can hire them by the hour. So I recently helped someone understand Git and how to set up her development workflow. And it was kind of cool, right? It's also embrace flexibility in your schedule and environment. I'm speaking to managers here as well to allow your teams and employees flexibility when things are rough. For your schedule of work hours, work in the morning or work at night, you know, whenever you feel most productive. And don't spend your wheels solving a problem, right? Take a break, go for a walk and you return with a fresh perspective. That was something that I've learned in the last year and it's great. And for your environment, a lot of folks are probably still working from home. I work remotely so it can be a little bit easier for me to relocate. So you can work from the patio, the kitchen table, the couch, outside of coffee shop, wherever it is that you feel most productive, you want to work there. And you want to practice self care as you're able to. You know, you don't want to take on habit management when you're in burnout. For example, this is not the time to stop smoking, right? Take breaks because time away improves productivity. Do relaxation activities as you're able. So, you know, the meditation we just talked about one minute, three minutes more. This can help with the feeling of not being able to breathe. It also helps with focus. But know that it can be harder to do when you're stressed. You know, consider watching a movie or an episode of a show. You know, this was my go to this summer. It allowed me to relax, put my computer and phone away and just get lost in the Marvel Universe. And most importantly, use positive self-talk. Okay, I often beat myself up over arbitrary standards like getting to work early in the morning. Doing that adds stress and makes things harder. So once I embrace the flexibility, I was able to get things done. So just remember, this is a journey of imperfection. Okay. There are a ton of books, articles, tips and tricks out there. Whatever you do, do what works for you and what helps you be the person you want to be. So I have some resources in the slides. The slides are actually already on the session on the website. If you want to download that, we've got the health guide. There's also this site called Thrive Global. Mariana Huffington of Huffington Post actually experienced burnout. She fainted because of exhaustion and hit her head on her desk, and it was kind of a wake-up call for her. So she started this company and this website to help people not burn out, to help people have better work-life balance and things like that. So it's a really cool resource. And then these are all the books that I mentioned throughout. I don't see anything about them. These are all links in the PDF. And then one of the first books that I read after I burned out was by Sarah Knight, Get Your Stuff Together, or something like that. She has a lot of great books. It's really funny if you're okay with a little bit of saucy language. I highly recommend that. She has some other books that are great as well. And The Myth of Multitasking was a great book. Very concise, so I couldn't summarize it so well. But I highly recommend that. It gives you a lot of the statistics about what multitasking does to you, right? All right. So thank you. And if you have any other questions, I'm here. Let's see, Amy June, are you going to help me with questions? Or there we go. I didn't see any in back scroll. Just lots of comments. Cool. And there's Mike joining the session late, as always. Like, okay. You should get royalties for selling the book. I did not. They are Amazon links, but I did not put affiliate links in there, I promise. I need to get my website. I need to redo my website. You know, the one that's still from like 2005. And I can share all the books and all the resources that I have on there. One day, Sunday. Here's a question. The question is, how do you notice when a relaxation or play habit is being harmful? Procrastination rather than helpful. Right. And like, if my play habit is playing video games, you know, video addiction, video game addiction is a thing as well, right? That's kind of a hard one, right? So at some point you do have to return to your computer and do the work, right? So I have a tendency where I'm like, oh, I'm going to go for a walk and I'm going to solve the problem in my head. And that actually doesn't work. But breaking away from something and thinking about other things and then coming back, actually helps you see things with a fresh perspective and solve the problems. I think you just have to pay attention to like that moderation, right? Everything's great in moderation except moderation.  And what sleep schedule works for me? For me? I end up, I can't go to sleep at night and I can't get up in the morning. That's just the gist of it right there. I tried going to bed earlier, but you know, I also have dogs and the dogs like to get up at 4am and the dogs like to go out late at night. So it just kind of happens and it's just something I'm trying to fix. I'm working on it for sure. I did set an alarm at 9.30 every night one time to remind me to let the dogs out and let that be sort of like the shutdown routine. I guess like the, the, okay, it's time to go to bed and get ready for bed. And I set the Amazon. Okay, I don't think I have her in here. I said Alexa and everybody else might hear it. I said Alexa to play who let the dogs out at 9.30 every night to remind me to let the dogs out. It's kind of funny too, but the wife wasn't too happy with that after a while. But yeah, as Tori says, it's a journey of imperfection, right?  It's like, if I sleep, I sleep. I do focus on getting sleep because I know that I require it. Nope. This scene looks like I've started playing who let to let the dogs out on Donna's Alexa. What headset do I have? I have the Jabra. What is it? The Jabra's 370. It's a wireless thing. It's wireless and you can plug it in, which is what I like. So if it starts to die, just plug it in and it starts working. Thanks Jordan. I actually had to replace my headset because my cats were chewing on the cord. Darn cats, can't have a ball.  Yeah, so I think that's all the questions unless anybody has anymore. Can always reach me on the Twitter.


Hello and welcome to the session. In this session we will discuss the following question and the question says, solve the in equation 3n plus 5 is less than 21 where n belongs to the set of natural numbers. Draw the graph of solution set. Let's start the solution now. We are given the in equation 3n plus 5 is less than 21. Now we subtract 5 from both the sides so we get 3n plus 5 minus 5 is less than 21 minus 5. The inequality remains the same because same quantity is being subtracted from both the sides. Now 5 and 5 get cancelled so this implies 3n is less than 16. Now we divide both sides by 3 so we get n is less than 15 by 3. This implies n is less than 5.33. We are given that n belongs to the set of natural numbers so the solution set is all the natural numbers which are less than 5.33. We know that natural numbers less than 5.33 are 1, 2, 3, 4, 5. So this is our solution set for the given question. We now draw the graph for the solution set. Let us first draw the number line. So this is our number line where the numbers to the right of 0 are all positive numbers and numbers to the left of 0 are negative numbers. Now we will show the solution set on this number line that is we will plot the points 1, 2, 3, 4 and 5 on this number line. So this is the graph of the solution set and it consists of the numbers 1, 2, 3, 4, 5 only and no other numbers are included. With this we end our session. Hope you enjoyed the session.


Hi Red Hat developers. This is Jason with the Red Hat developers program. Welcome back to the DevZone at Summit 2017. Today with us we have Nicholas Grenier from 3Scale by Red Hat and he's going to show us to talk to us about revolutionizing hackathons at today's Code Starter. So really glad to be here. It's my first summit and as Jason said I'm part of 3Scale. We've been in the Red Hat family for just a year. So today we're going to talk about the different hackathons and specifically something that's happening tonight, the Code Starter. So I'm Nicholas Grenier. I'm a developer advocate, developer evangelist at 3Scale. You can find me on the different social media through my username and as we're developers you can find me on github as well with the same username. And I work for 3Scale. So 3Scale I'm sure you've seen it this morning. We do API management and we have announced a bunch of stuff today through on-premise and containerization. So if you do stuff with APIs you could be really interested. By a sense we are all hackers. The whole developer community around here and in our company we love hackathons. We love doing stuff with APIs through our own APIs through people APIs, our clients APIs. So we've been to a ton of other events. We've run few events. This is one of our spring hack. It was our internal hackathon. But it's a typical hackathon, right? It's an open subject. People come with ideas of what they want to hack on. As this one was internal we're encouraged to do stuff with the product and try to find extension, trying to find an interesting use case for the business. But you're used to this format. So usually it takes two days. There's a sense of competition. You don't really limit what you have to do with it. So there are no specific guidelines. You don't know what you're going to get from it as a hacker. You don't know what you should expect to learn, what you're going to expect to achieve. And also there's something that could be annoying if you go to hackathon is the unfair judging. So I may do an awesome app on mobile. But if the judge panel is not really interested by mobile, they're more into the AI stuff. Although you've built a great thing, you might not have a chance to win this.  So you're not guaranteed that people will try your API. They're not guaranteed that they will give you feedback on the tool. So we decided to come up with a new format called Speedhack. So that's a format that came three, four years ago. And we decided to put that for our partners at our API conference, the API Strategy Conference.  So it benefits both the attendees and the sponsors. Also it benefits a conference because before, if you wanted to do a classical hackathon, you will ask people to come maybe two days before the conference, which is usually super hard. And if you do it during the conference, people will miss the interesting topic, the interesting content they came for. So instead, we decided to take it short, just a three-hour period of time, and having different challenges. So we did six to eight challenges. They should take 15 minutes each. And the team that solves most of the challenges win points and get a win award. There is a sense of real-time competition because during the event, we had a leaderboard. And so as you were progressing to the challenges, you were getting up in the leaderboard and you were able to get points. And so there was a sense of urgency of like, we had to get better than the other team. And for the sponsors, you were guaranteed that your API will be tried by hackers and they will stop at your table asking for feedback. And so you had a better engagement with the developer community. We've done it three times at different places, Chicago, Berlin, and Paris. This is an open format, so we'll be happy to do that in other places.   So the Twilio guys, for example, they did a game where it was entering random numbers and calling random numbers, super fun stuff. So a bunch of fun and a lot of learning from the developer perspective. But we can still innovate on the format for hackathons. There's still a big room to come with something new, get people engaged, get people excited, and provide a fun experience. And you will see that through what's going on right now in the hackathon scene. So people will just say, OK, the only way to innovate will be changing the space where we're doing this. So people will say, OK, we should do a hackathon on a plane, which is fun. We should do a hackathon on a bus, which is also fun on a train. I've done bus and train so far, missing the plane. But it's still the same format.  And you don't have real guidance. And again, you don't know what you're going to learn from it. So instead, we decided to try to do something better. And that's going to be for you tonight at a world premiere. As we announced on the developer blog before the conference, we're going to do tonight at Red Hat Summit, 6 PM, room 210A.  So imagine a really nice trailer. We're going to launch and do the first API escape room. And while I'm talking, I have two colleagues actually play testing the game, making sure the game works. And actually, it seems harder than we thought. But I'm sure you're going to have a lot of friends. We have three hours to solve the escape room. If you're not familiar with the escape room, it's usually a physical game, a physical puzzle. So you get close into a room and your goal is to escape with your team. And you're going to try to get all the clues that are around you. You're going to open the books. You're going to turn on the lights. You're going to find a locker. You're going to tear down the whole room to find clues and make progress. We're going to do the same thing. But as we're API people, as we're developers, we're going to put some API in it. And I'm not going to spoil you the whole game, but come later tonight and you will get a chance to see it. We're going to have food as well and beers and a bunch of prizes for the team to win if this succeeds to be one of the first. So you can check out API escape room. Once we're done with the event, we're going to tell the story of how we've built it. We're going to tell the story of how it went. Hopefully people find the solutions. And hopefully people will find it exciting. If you have any questions about how we run those events, if you are interested to run a similar event and get your community engaged, come talk to me.