 The Cube presents KubeCon and CloudNativeCon Europe 2022, brought to you by Red Hat, the CloudNative Computing Foundation and its ecosystem partners. Welcome to Valencia, Spain. And KubeCon, CloudNativeCon Europe 2022 is never the end of the day, that's okay. We have plenty of energy because we're bringing it. I'm Keith Townsend along with my co-host, Paul Gillan. This has been an amazing day thus far. We've talked to some incredible folks. You got a chance to walk the show floor. So I'm really excited to hear what's the vibe of the show floor, 7,500 people in Europe following the protocols, but getting stuff done. Well, at first I have to say that I haven't traveled for two years. So getting out to a show by itself is an amazing experience. But a show like this with all of the energy and the crowds here is enormously crowded at lunchtime today, it's hard to believe how many people have made it all the way here. Out on the floor, the booths are crowded, the demonstrations are what you would expect at a show like this, lots of code, lots of block diagrams, lots of architecture. I think the audience is eating it up when they're on their laptops, they're coding on their laptops. And this is very much symbolic of the crowd that comes to Akubacan, and it's just a delight to see them out here having so much fun. So speaking of Lasakol, we have Varun Taro, co-founder of Tetra, but just saw and didn't realize this Istio becoming part of the NCF. What's the latest on Istio? Yeah, Istio is, it was always one of those service mesh projects which was very widely adopted. And it's great to see it going into the cloud native computing foundation. And I think what happened with Kubernetes like just became the de facto container orchestrator, I think similar thing is happening with Istio and service mesh. So, I'm sorry, what's the process like of becoming adopted by and incubated by the CNCF? Yeah, I mean it's pretty simple. It's an application process into the foundation where you say what the project is about, how diverse is your contributor base, how many people are using it, and it goes through a review with TOC. It goes through a review of all the users and contributors. And if you see a good base of deployments in production, if you see a diverse community of contributors, then you can basically be part of the CNCF. And as you know, CNCF is very flexible on governance. Basically is like bring your own governance. Then the projects can basically seamlessly go in and get into incubation and gradually graduate. Another project close and dear to you, Envoy. Now I've always considered Envoy just as what it is. It's a, I've always used it as a low balancer type thing. So I've always considered it somewhat of a gateway proxy, but Envoy gateway was announced last week. Yes. So Envoy is basically one the data plane war of in cloud native workloads, right? And this was over the last five years. Envoy was announced even way before Istio. And it is used in various deployment models. You can use it as a front load balancer. You can use it as an ingress in Kubernetes. You can use it as a sidecar in a service mesh like Istio. And it's lightweight, dynamically programmable, very open with a wide community. But what we looked at when we looked at the Envoy base was it still wasn't very approachable for application developers. Like when you still see like the nouns that it uses in terms of clusters and so on is not what an application developer was used to. And so Envoy gateway is really an effort to make Envoy even more stronger out of the box for an application developer to use it as an API gateway. Because if you think about it, ultimately people, the developers start deploying workloads onto their Kubernetes clusters. They need some functionality like an API gateway to expose their services. And you want to make it really, really easy and simple. I often say like what what Nginx was to like static websites, like Envoy gateway will be to like APIs. And it's really the community coming together. We are a big part, but also VMware and as well as end users like in this case Fidelity who was investing heavily into Envoy and API gateway use cases, joining forces saying let's do this in upstream Envoy. I'd like to go back to Istio because this is a major step in Istio's development. Where do you see Istio coming into the picture? And Kubernetes is already broadly accepted. Is Istio generally adopted as an after step to Kubernetes? Or are they increasingly being adopted together? Yeah, so usually it's adopted as a follow on step. And the reason is primarily the learning curve, right? It's just to get used to all the Kubernetes and it takes a while for people to understand the concepts, get applications going. And then, Istio was made to basically solve three big problems there, right? Which is around observability, traffic management and security, right? So as people deploy more services, they figure out, okay, how do I connect them? How do I secure all the connections? And how do I do more fine-grained routing? I'm doing more frequent deployments with Kubernetes, but I would like to do canary releases to make safer rollouts, right? And those are the problems that Istio solves. And I don't really want to know the metrics of like, yes, it's good to know all the node level and CPU level metrics, but really what I want to know is, how are my services performing? Where is the latency? Where is the error rate? And those are the things that Istio gives out of the box. So that's like a very natural next step for people using Kubernetes. And Tetrate was really formed as a company to enable enterprises to adopt Istio, Envoy and service mesh in their environment, right? So we do everything from run an academy for like courses and certifications on Envoy and Istio to a distribution, which is compliant with various builds and tooling, as well as a whole platform on top of Istio to make it usable and deployment in a large enterprise. So paint the end for me for Istio and Envoy. I know they can be used in similar fashions like sidecars, but how do they work together to deliver value? Yeah. So if you step back from technology a little bit, right? And you like sort of look at what customers are doing and facing, right? Really it is about, they have applications. They have some applications that new workloads going into Kubernetes and Cloud Native. They have a lot of legacy workloads, a lot of workloads on VMs, and with different teams in different clouds or due to acquisitions, they're very heterogeneous, right? Now, our mission, Tetrate's mission is power the world's application traffic. But really the business value that we are going after is consistency of application operations, right? And I'll tell you how powerful that is. Because the more places you can deploy Envoy into, the more places you can deploy Istio into, the more consistency you can get for the value pillars of observability, traffic management, and security, right? And really if you think about what is the journey for an enterprise to migrate from VM workloads into Kubernetes or from data centers into Cloud, the challenges are around security and connectivity, right? Because if it's Kubernetes fabric, the same Kubernetes app and data center can be deployed exactly as is in Cloud, right? So why is it hard to migrate to Cloud, right? The challenges come in the security and networking layer. Right? So let's talk about that with some granularity and you can maybe give me some concrete examples. Because as I think about the hybrid infrastructure, where I have VMs on-premises, Cloud native stuff running in the public cloud or even Cloud native next to VMs, I do security differently when I'm in the VM world. I say, you know what? This IP address can't talk to this Oracle database server, right? That's not how Cloud native works. Right. I can't say if I have a Cloud native app talking to a Oracle database, there's no IP address. But how do I secure the communication between the two? Exactly. So I think you hit it straight on the head. So which is with things like Kubernetes, IP is no longer really a valid noun where you can say because things will auto scale either from Kubernetes or the cloud auto scalers. So really the noun that is becoming now is service. So and I could have many instances of it. They could go scale up and down. But what I'm saying is this service, which you know, some app server, some application can talk to the Oracle service. And what we have done with the Tetrade service bridge, which is why we call our platform service bridge because it's all about bridging all the services is whatever you're running on the VM can be onboarded onto the mesh like as if it were a Kubernetes service, right? And then my policy around this service can talk to this service is same in Kubernetes, is same for Kubernetes talking to VM, is same for VM to VM. Both in terms of access control, in terms of encryption, what we do is because it's the Envoy proxy goes everywhere and the traffic is going through them, we actually take care of distributing certs, encrypting everything and it becomes and that is what leads to consistent application operations. And that's where the value is. We're seeing a lot of activity around observability right now. A lot of different tools, both open source and proprietary Istio certainly part of the open telemetry project, I believe you're part of that project. But the customers are still piecing together a lot of tools on their own. Do you see a more coherent framework forming around observability? I think very much so. And there are layers of observability, right? So the thing is, like if we tell you there is latency between these two services at L7 layer, the first question is, is it the service? Is it the Envoy or is it the network? It sounds like a very simple question. It's actually not that easy to answer. And that is one of the questions we answer in like platforms like ours, right? But even that is not the end. If it's neither of these three, it could be the node, it could be the hardware underneath, right? And you realize like those are different observability tools that work on each layer. So I think there's a lot of work to be done to enable end users to go from top to bottom to make reduce what is called MTTR or mean time to resolution of an issue. Where is the problem? But I think with tools like what is being built now, it is becoming easier, right? It is because one of the things we have to realize is with things like Kubernetes, we made the development of microservices easier, right? And that's great, but as a result, what is happening is that more things are getting broken down. So there is more network in between. So that harder it gets to troubleshoot, harder it gets to secure everything, harder it gets to get visibility from everywhere, right? So I often say like actually, if you are going embarking down microservices journey, you actually are, you better have a platform like this. Otherwise, you know, you're taking on operational cost. Wow, Javons Paradox. The more accessible we make something, the more it gets used, the more complex it is. That's been a theme here at KootCon, CloudNativeCon Europe 2022 from Valencia, Spain. I'm Keith Townsend along with my host, Paul Gillan. And you're watching the QV leader in high tech coverage.