 How many of you know about Istio? Service Match Istio, okay, quite a few, awesome. And how many of Java developers are here? I wanna know the Java developers. Okay, this is much more than what I got yesterday. So I'm a Java developer. So all my examples are going to be on Java. So other non-Java developers excuse me about that. But these examples are absolutely fine to be used with any programming language. You're not necessarily to be on Java. All right, so today I'm gonna talk about Istio and you can find the links right there, as usual like we have the public. And I keep updating it. You can pull this out from there and then I have my email ID there. You can drop me a note if you have any questions on this session or a couple of more sessions that I'm going to do in the afternoon. So anytime, any questions I have my Twitter handle, GitHub handle, so you can open the issues or drop me a DM or send me a message. I'll be happy to answer your question, all right? Awesome. So many of you are here on this site, I think most of you would have done it already. So in case if you're not done this, I would love you to get on to developers.redact.com because our developer journey is not going to stop with this. So we are going to go further up and tell people like how awesome things we do in Redact with upstream projects and all these stuff. And we have Fortnightly webinars that you can get access to as well. So once you are done with that, this also gives you an access to all of these awesome eBooks for free. So you can just download them. The eBook links are there, probably Burr and others would have shared it already. If you're not seeing this, you can go to those links there, download those eBooks for free, if you're registered for redact.com. The first one is being the service mesh one. This is more related to what you're going to talk today. And you're also getting a new version of it released soon. I think it's already released if I'm not wrong. And it's an Enaga who's speaking on other room like, so he talks about the microservice databases, monolith to microservice database as well. You can also grab that copy of the book. And if you're new to microservices, then you can also have an introduction to microservices, book as well as reactive programming. So all these eBooks for free and more to come. So you can just go to developer.redact.com, register yourself, you get access to all these things for free. All right, great, I'm sorry. How many of you are doing microservices? One, two, three, four, five, okay, quite a few. All right, so the people who are new to microservices, this is the official definition from Martin Fowler from ThoughtWorks, what exactly microservice is. You can just see, I just highlighted a few things on this. The first one is being running its own process. So which means that there's going to be only one process which is going to take care of that. And then communicating with the lightweight mechanism, it could be REST, HTTP, GRPC, anything you want to do. And then the third important thing is that it should have an automated deployment machinery. The principal reason of people going to microservices is that they want to go fast to the market, get more returns on investment, faster feedback, and then keep adding new features quickly and the more agility on that, right? So that's what we do with microservices with this. And then what I want to show to you is a short history. How we actually started with microservices. I was all started with continuous integration with XP 1999. Then we had agile manifesto saying that what's agile programming, I mean agile way of doing things is. And then we had EC2, I need to pin this up because EC2 was a real first milestone with respect to microservice development, all right? So because you were able to spin up computes at your vision will deploy your applications on top of your compute anywhere across the geographies and it was made your life much easier because you don't need to no longer worry about what's mandalang infrastructure is, all right? And then we had Netflix moving into AWS in 2010. That was a real revolution like where Netflix started to do more and more deployments quickly, faster in time, so which made their life easier. And then they also in turn, they also bought a lot of things like you see those Netflix things tagged around. So those are some things which bought in by Netflix to enable microservices based development. You'll see why they are important. Ribbon, Raycon, Estrix. And then you also see the other big movement in this, another milestone is Docker or container images we like to call as the Linux container images. So which was again was another big improvement in the Microsoft's way of development because now we don't need to worry about how do I take my application to production, right? I think probably you would have heard that like if your application is not in production then you don't code. That's a simple thing, right? It's not in production, you're not doing any code. You're not being productive. So that's what Linux, I mean Docker thinks that's like it kind of take you all these things so easily package us Linux container images and deploy them over any kind of cloud provider platform you might have. And after that, we got Springboard which really revolutionized for the Java developers actually how do you actually make Java applications run? You no longer need an application server. I can just do Java dash jar and then kind of deploy my application across wherever I need. So that's something which we made another thing and the thing of the king of the topic today what we are going to speak about is Kubernetes which is kind of a real, real milestone in the way we do the application development. I think it really propelled what we call as cloud native application development. See because with that, with Kubernetes we're able to achieve a lot of things. You'll see what all things we are able to achieve but would have given you an interaction about what things we can do with Kubernetes as well. With that, what I also need to do is like what's microservice? Like we have talked about microservice. We say, how do we do this? And then the principal thing is like microservice is nothing but distributed computing, right? That's pretty much as we don't need, we don't do anything extra super magical thing there. We just make them distributed across geographies, across data centers or across your cloud providers or wherever it is and make them talk with each other over any kind of protocol they want. What we usually call them as APIs. With distributed computing come with a cost which becomes a network of services because each one has to talk with each other. So we need a way for these things to be connected. That's what becoming network of services. The moment they become network of services the problem what happens is that they fall into a lot of constraints, right? So you know how do you communicate? There'll be errors, there'll be failures. You need to start handling all those things. That's something which you're going to see what happens. But before that, anything, what is microservice? That's right, they should have all these little bubbles what I call us to be defined there. For example, the fundamental thing it could be any platform you wish to write. For example, it could be Quarkus, it could be Microfile, it could be Node.js, it could be Spring Boot, .NET, anything we wish to write. The first and foremost thing we need them is a service. So anything we define in a microservice is a service like it's going to give you some service come kind of an API to play with. That's what it does. So the API is first and then once it gives an API we should have a way by which I can discover that, right? That's something which is important. Me defining an API is not going to help, right? Unless I'm going to discover it. So that's what I'm going to do with discovery and once I do the discovery I should know the way how do I invoke it. That's the third thing which we have to do. So a service essentially complies with these three very basic elements. So if I define a microservice then I need to know a way by which I can define it as service, a discovery, and an API, right? How do you do an invocation? All right, so I have a service now but I should also have an infrastructure piece of it, right? Where infrastructure piece I mean that I should have elasticity and resilience there. So what happens when it fails? Because in the last slide we saw that it's a network of services so it could fail in anywhere it wants. Let's go back to the slide. So in this slide if you see it could fail anywhere if you wish to do. For example, it could fail on the last and then the service could be something which is calling from here. So I should know a way by which I need to have how do I recover from the failure? Like what should I do if it fails? That is something that's more important here. So that's what I mean by elasticity and resilience. I got those two things. Since it's a network of services I should know a way by which I need to observe what happens, right? For example, I call from one service, service A to service X. It goes to service B, C, D, something like that. Then if this slow or fast or anything not working correctly or whatever it is then I should find a way by which I need to know what's the problem is. Identify the bottlenecks, right? That is typically done using tracing. Obviously I need monitoring and logging as well for my future records to see what exactly happened around to find out the reason and then fix the problem and do a redeployment. So observability also adds to a bubble meaning to say I should have as a microservice property I should have no service, I should have an infrastructure, I should have an observability but we are enterprise developers. When you're doing enterprise applications then authentication and pipeline also comes into picture. So if you want to have a truly microservice I should use all these characteristics around to make a good microservice for you, right? But what I've been doing so far is that with Netflix OSS I was using Ribbon, Eureka and all these things I was able to get the service related stuff given to me using that and then I was using any one of those cloud providers like AWS, Azure or Google to give me the infrastructure which gives me resilience and other stuff. And then what I've also been doing is that I've been observing using Zipkin. Zipkin is an open, I mean the tracing standards tracing application which can be used. I was using Zipkin to do the tracing for me and then still I was lacking something which is not related to enterprise application. That's something which is not strong because everyone had their own unique way of doing things but you'll see how do we standardize this. That's what you're going to see now so which becomes if you're a Java developer I'm a Java developer so this was my de facto platform to deploy any microservice. So I use Springboard on AWS, Azure or Google Cloud I use Netflix Ribbon for clients at load balancing Eureka for service registry, Zipkin and then Zool for router and Asterix for circuit breakers which means that this gave me probably the most the first primitive or early program for doing microservice development with Java what I call as cloud native Java development, all right? But this is not enough, we have some challenges in this that's what we are going to see now. So I want to go back a slide and then I want to observe this for a second because the drawbacks are going to be on top of this, okay? So just observe that we have AWS, Azure, Google or any cloud provider for that matter I just quoted these common ones and then we have Eureka and all of the stuff here. The basic problem, the first one is that how do I scale, right? So generally what happens with the architecture I showed just now what happens like when I do a scaling I basically scale my infrastructure, right? And I want to scale, I just, okay, I add one more compute node in AWS or Azure or Google but what I really want to do is like I want to scale my application, not my infrastructure, right? Either horizontal or vertical scaling however I want to do, I want to scale my application. The second one is that how do I avoid port conflicts? Any Java application or any common application, right? Let's take an 8080 as an example. So when I deploy my service I make my service exposed on 8080. The moment I do it on 8080, what happens is that I'm going to deploy one more service which is going to run on 8080 on the same VM node just imagine a case. Then what happens? I cannot run this on 8080 because of port conflict then I need to go and change the port to 1990, right? And this, the next step after you change the port is that I have to go back to my infrastructure and security guy saying, okay, I've changed the port 1990. So please go and add this firewall rule to open up 1990 or whatever it is, right? Now it's going to grow, right? If it's microservice then I'm not going to leave it one or two. I'm going to go hundreds of services. The moment I start to go to hundreds of services what basically happens is that I end up with a chaos thing, right? Like a spaghetti and kind of, I mean, I'm probably trying to get a right objective. Probably not easy to maintain kind of stuff which can basically say, okay, I have hundreds of services, hundreds of ports open, I keep opening the port and then your security guys are going to have a nightmare, right? But I should have a bay by which I've always run on 8080 but still it needs to be code deployed, right? The next one is that how do I manage them on multiple hosts? This is a classic example. For example, I have an application which uses the database, right? And then I don't want to go over network. I want to do a local score for any kind of performance constraints or any other thing that we might have. In that case, what I basically need to do is like I want to co-locate the database, right? I want to, when I deploy my application, my application should know the node where I can do a database call over local host and then get it deployed there, all right? So that's something which I also want to do and then what happens if a host is in trouble? This is a very common scenario if you're doing in a production, if hundreds of service are deployed, you might run out of CPU, the CPU pressure, run out of disk, disk pressure, and you may even run out of memory as memory pressure as well, right? And it can happen any time of time and your ops guys has to go and fix it up, give a new node or something like that. But the real problem, what happens here is that when something like that is happening, my application orchestrator, what I mean like this, I'm just starting this new term called application orchestrator, this guy should be smart enough to know where I need to go and deploy. If there is a disk pressure or a CPU pressure or a memory pressure on the node, then I should not deploy it, right? It's like beating a dead man. If you keep deploying, your application keeps failing because you don't have the enough resources to do with it, right? I should have a way by which I can go and say, okay, you keep them, the host is in trouble, go find a new node where I have enough resources, go deploy them there, all right? That is something needs to be done automatically and then how do I keep them running? Probably most of you are Java developers, you would have known about ZooKeeper. I'll take this classic ZooKeeper example. For a production ZooKeeper, I should always have, it should have a fine node quorum, right? I cannot have less than fine node quorum. If one of the nodes goes in a fine node quorum, what basically happens here? ZooKeeper will not work properly unless the fifth node comes up. And this somebody has to check this, some alerts has to be raised, your operational guys has to go check this and then you have to run some scripts to bring up the new node app, right? But the thing is like I want something to new a way by which this can be done automatically. What I mean by this is that we have seen Burstalk saying that decide replicas, what do you call? While you increase replicas and decrease replicas, there should be the desired count and the actual count of the replica should always be same. That was something which we need to make sure so that at any given point of time, whatever failure happens, I'll always have these fine nodes running up for me, all right? And how do I update them? This is something that I was talking about is rolling update. You saw the rolling updates was Burstalk was the example on the last thing where it kind of scaled up a new deployment and then until it came up, your service was still requesting the old one, which means that I'm doing a rolling update. The moment the new one came up, the old one scaled down, right? Which means that you will not have any kind of service disruption, right? That is something which needs to be there always. All right, so how do I solve these things? Let's fit some new things with this. So this is what it's all probably heard about Kubernetes and OpenShift earlier. Both of them are pretty much the same platform and I call OpenShift as Enterprise Kubernetes. Let us see why I call this as Enterprise Kubernetes. How do we fix Kubernetes with this? I go back to my same bubbles. I had Netflix OSS, which was giving my service API registration, discard invocation. I go and replace that with Kubernetes because the moment I deploy anything into Kubernetes and create a service, I automatically get a service URL. I have an API which is given by my application. I know how to invoke it because it's a URL, though I can invoke it the way I want to do, all right? And then what I basically do is like an infrastructure. Here, what I'm trying to do is like, I still have my cloud infrastructure. I'm not doing it with my cloud infrastructure, but where my application is going to sit is on Kubernetes. It's not on the actual phase. It's not dependent upon your underlying SaaS provider or anybody, right? Your cloud provider, basically. And I still have Zipkin, but if you see monitoring and logging, these are, again, super critical features for any given application, which is more enterprise-y stuff. So what I try to do is like, I try to get an OpenShift there as well. So now OpenShift gives me monitoring and logging out of the box. And now what I also do is like with OpenShift, I also bring in authentication and pipeline automatically. So if you're here the whole day, so I have an exclusive pipeline talk at the end of the day to see how pipeline works. So we will see the same application, what I'm going to deploy in this particular demos. It's going to be the same one. I'm going to use it using pipelines in the last section, all right? So now what I did is like, if you see these two side of things, the observability and enterprise side of things, so that's what OpenShift brings you, but still with Kubernetes underlying. So which means that I can safely call OpenShift as an enterprise Kubernetes, right? We give you enterprise-y features on top of existing Kubernetes. Well, what happens? I'm not devoid of any problems still, right? So I want something to do, have a sophisticated discovery. I want to do a distributed tracing circuit breakers and metrics and monitoring as well out of the box. And how many of you have done distributed tracing circuit breakers, metrics and monitoring from within your application? So you use an external library, basically, that's a common scenario. And then I kind of add the logic to instantiate the class or whatever you call in any programming language to do a distributed tracing circuit breakers and metrics and monitoring. Is that any way related to your application? No, right? What application you're writing, the business logic you're writing, it's no way related to the business logic you're writing there, but still we add them because we need to find a way by which I can trace my application, I can find out the issues or how to have my fallback mechanism for microservices. So a simple hello world kind of an example, if I'm going to use all these things together at the very basic thing which I wrote in the Java program, like I had to write 70 lines of code, just to say hello world, which includes distributed tracing circuits and then metrics and monitoring, with all included together. Which means that imagine a case if you're writing a complex program, I'm going to write more lines of code and then you will be having a lot of infrastructure logic inside that and your application logic will be kind of diluted, right? And then it's hard to maintain as if the library changes, if anything changes, then I'm going to really have a problem getting this thing up and running, all right? And I also need to do in the microservices world, so you also need to do these operational requirements. I want to do AB testing. How many of you do AB testing? This or that testing, I call it feature testing on feature toggling or you do, right? That's right, right? Okay, you're changing from A to B, B to A kind of stuff, right? And then we have can releases where we want to introduce features for a small set of people, right? And then see how it works, get the feedback, if it's good, I promote this feature into bigger set of people. And then you also need to do rate limiting. If you are an API provider, writing APIs, then what you basically do is like I start to write those APIs and then give it for service and then you'll have silver platinum diamond customers kind of stuff and then I want to control how much amount of API request each person can make, right? Each category of customers can make, right? That is something on rate limiting. And then I also need to have access policies, right? What I basically mean here is that how the service A can call service B, whether it's authorized, right? And then how the traffic is encrypted. All these things also comes into picture. If you see this, majority of these things are super important on a microservice development, but you'll all be doing this with different libraries, different set of libraries within your application in which case like your application is not doing what it intended to do, right? It's doing something extra, which is not required from that. Living in a DevOps area, like you should never try to do all those things. So how do we solve this? That's where we go with Istio. So what is Istio? Again, Istio in Greek means sailing. And everything related to Kubernetes is all going to be C, sailor and all this stuff. So Istio means sailing. What is Istio does for us that? Istio doesn't add anything new, but it complements Kubernetes. I mean to say like Istio adds additional stuff like whatever we saw here, and then it kind of makes a developer's life easier because slimming your application. You'll see how it simms the application. And then now you see another set of applications which I can add on top of Kubernetes. If my Kubernetes platform is there, I can add Istio on top of that so that I can get all the other constraints which we saw earlier alleviated for us, right? Making your life much easier and you concentrate only on your application development. All right? So what does it mean to me? I left these things out. Kubernetes, Kubernetes, Ager, if you're known of open tracing. Ager is open tracing standards where I can set XB3 headers along with my request to get it automatically traced as well. I have Ager here, and then I have Netflix Reborn remote with Kubernetes. I don't need Zoologin thing anymore. I have Istio with another set of Kubernetes application and OpenShift has my platform, enterprise platform, enterprise Kubernetes platform on top of any cloud pro battery wish to be, right? So this is how I need to do. If you see this, my application platform is just having one application which is like based on Kubernetes. And then everything is sitting on top of that which means that it's easy for me to take in and take a plug in and plug out any kind of application which is Kubernetes compatible. Make sense? Great. Right, so okay. So you want to go back to the changes one thing. Okay, this is your platform, right? So you had Eureka, which is for service registry. We saw that I don't need that anymore so I'm just changing that into Kubernetes. And then I have config servers. I'm just replaying the config match on secrets that's part of Kubernetes automatically. So my properties are controlled with Rbacks as well. I don't need Zipkin. I replay Zipkin with Ager because it's an open tracing standard. So any tool which is going by open tracing standards can read the data from this. I don't need Netflix reborn because it's using for client-side load balancing because Kubernetes gives me all the primitive load balances that I require, right? But we are going to add Istio on top of this to give me more sophisticated load balancing. We'll see the examples in a second. And also I use Istio because I can do circuit bracing and then routing and all these things using Istio. So I don't need another thing like Zool and Istrix, two things together. And if people are aware, Istrix is no longer thing, it's under maintenance mode. So people, there is no bug fixes, no future enhancements will happen to Istrix as well. So we can just go this as well. And then finally, since you are going to develop an enterprise application, so you need an enterprise platform that's hard and Kubernetes is what I call this. That's what OpenShift comes into picture here. We'll see what additional things you get out of OpenShift during my demos. I'll show you that, we saw the pure Kubernetes deployment from Burr. I'll show you like what additional things you can do on top of this as well with OpenShift. And still I need any basic cloud provider but the cloud provider is absolutely transparent for you because as you as an application developer, you need to worry only about how do I depend on my application on OpenShift or using Kubernetes. That's all I need to know. I now need to know how it works on AWS, how it works on Istio or how it works on Google. Typically achieving what we call as hybrid cloud scenarios, all right? Okay, so this is a common question. That's a very good question. Like if ServiceMesh differs from API gateway, ServiceMesh and API gateway are two different concepts, to put it very simple way, ServiceMesh can be think of more technological stuff and API gateway can be think of more monetary and business stuff, right? Because even before you come into ServiceMesh, you'll be hit with the API gateway, right? And then for example, you'll be hitting, getting into the API gateway and API gateway decides whether I want to allow this request or not. The moment it says okay, then it comes into your Kubernetes server, that's where your ServiceMesh comes into picture. So it's two different things. This is technology side and this is monetary side of things. Yes, but if you see this, like we had more of the things into the API gateway than what we had here. Here is basically a routing, a circuit breaking, chaos engineering, et cetera, et cetera. But if you do more things with API gateway, right? More centric around your business, right? This is nothing to do with business. So just do with the logic, application logic. And this is for your offline read, I'm sorry, to do what about ServiceMesh. But if you're Java developer or any kind of developer, you might be knowing that the problem right now with Microsoft's development, cloud native, Java development is all that is Java only. I have to have a library, for example, if I want to go for a polyglot application development, then what happens is I need to remove all these libraries, rewrite these libraries in the respective languages. For example, it's .NET, Golang, or Python, or whatever it might be. I just start writing these stuff again in those languages. Again, it's going to be a maintenance over it for you. Again, right? And also what happens is that if you see this particular application, this we spoke about just before Istio, we saw that on a service A and service B, it's bloated because I am doing load balancing, discovery, tracing, resiliency, everything, using some kind of a library within my application. But that is something we should not need to do. That's what we're going to do here. With Istio, what you're going to do is like, I'm just going to remove all those things into a sidecar. It's on my proxy. It's a Istio proxy sidecar. I'll show you what you can do with the deployment. It's a Istio proxy sidecar that gets deployed and that takes care of doing all this work for you. Basically doing all this heavy lifting of all this infrastructure-related stuff like your distributed tracing, your monitoring, metrics, et cetera, et cetera, it's going to get it automatically done for you and then you just need to write your services alone. So that's what the heavy lifting is being done. But it uses a pattern called a sidecar pattern. There's a first Kubernetes pattern probably you could hear about, a sidecar. So which means that in a pod, I can run two containers. How many of you are running Kubernetes pods today? A few number of people. How many applications you run? One? One container, right? And you'll say people would have said you have to run only one container on Kubernetes pod, right? Is it so? They say best practice, okay, that's a new word, right? I've been hearing this from yesterday, best practice that you run only though, it's not like that way, right? You can run any number of containers you wish to run on a Kubernetes pod. It all depends upon, right? Obviously it becomes a best practice if it's going to be too heavy applications and I'm going to run on this because it's going to consume lots of resources and when you're going to port the application, it's going to become difficult because I have to provision these two resources in those new node as well, right? But really it's not the case. You can have any number of containers you want to have. For example, let's say we took the database example earlier for a microservice, I can write a microservice within a pod, I can have a database running within the pod and I can do a local host call to it. And it's actually, I don't have to need to run a local host database in that particular node. So don't have this myth, just see your use case to see if I can fit any number of containers. This logically makes sense for me to fit these two containers into one pod, then please do it, right? It helps you a lot because it's a share the same life cycle. For example, I might be having service A and service B, both are dependent. And then if service A has to have service B running, if service B is down, there is no sense running service A. If that's the case, why should I run it in two pods? I can run it the same container because they share the same life cycle, application life cycle, I can run them in the same container so that they can go up, go down and I can use a shorter version of local host calls to that particular service. I just an example I'm saying, but you could have many examples like that. Let's just take that thought out, like I can have any number of containers. There's nothing like Kubernetes says the best practice that you have should run only one container, nothing like that. Probably the best practice says that you should run only one process within a container. That's the best practice because containers are meant to run only one application, which means that you should run only one process within a container. That's the best practice in Kubernetes and containers and not that you should run only one container, all right? So that's what we do here. We take two containers here, make these two containers, talk again, making your application much slimmer, smaller and just do what it has to do, all right? So which means that I have a, this is called as control plane with an Istio. So this is a graphic which I picked up from Istio. You can just go to the Istio site to pick this graphic. There is a tip over there. It is, it should be service A and service B, but they have service A and service C there, right? So what basically, these are the three different components. These are called as a control plane. A pilot takes care of all your configuration, Gali again, it takes care of, sends a configuration back to pilot and Citadel is used for your certificates, right? If you want to have MTLS or TLS kind of communication, then Citadel is used there. And then you have adapters. So within a mixture, what Istio has given you, is it has given you plugin APIs to get the data out of these things from your control plane and give it to the tools which can have there, right? Basically it has an adapter API. Tomorrow you have a different tool where you need to send this data from here to that particular tool. Then all you need to write is an adapter implementation of it and then plug it into Istio, then your tools start receiving the data as well, right? But right now we don't, we are not going to see this, we are going to see the out-of-the-box tools like Grafana, Yeager and all these things Kali and all these things comes out of the box. So I don't need to worry about any kind of data sending outside, but I'm just saying that adapter API is used for that. Now you'll be wondering like, I've been saying that all this ability has been done by my sidecar, my sidecar sensor traces, my sidecar sensor metrics and everything. How it does, if you see that thing right there on top, it has service A and then everything is, every call is going through the proxy, right? There's one more extra hop into the proxy, but it's negligible. Probably there is a, obviously there'll be a little bit of latency there because it has to hop through the proxy, but that is okay in this case. And then I can use any kind of protocol, HTTP 1, 2, GRPC. And then since it's going through the proxy, the proxy is connected to the mixture always. It gets synced up with the mixture always in asynchronous fashion, so it keeps sending the data. Like I get a, Prometheus uses containers to get the metrics from the containers, send it to this particular stuff as well. Okay, that's how it technically happens. What I'm going to achieve is that I'm going to go to the next generation of microservice. We'll be seeing like this guy introduced me, microservice just few slides back, now he's talking about that, I'm going to go to the next generation of microservice. So basically the thing is like that we have, this thing is going so fast that thing like when you started to new, you knew it better, that you do it better, right? So in this case, like I can do code independent thing which means polyglot, people who are not, I think not like Java developers like me, you can develop in any language that make those services talk with you there. And then we can do intelligent routing and load balancing. We are going to see that in the demos. How do I do intelligent routing and load balancing? I can do a test as well. Smarter can releases, that's another demo which I'm going to show you as well. How do I do smarter can releases? Obviously, since you are in a microservice world, chaos engineering, resilience and observability becomes super crucial, right? How do I do all these things? Again, I'm going to do all these things as well. And then finally, you can also have a fleet-wide policy enforcement. This is also possible. So these are something which you can add new to your microservices developer and make sure when you use Istio on top of Kubernetes, I'm going to achieve this out of the box. I don't need to worry about these things myself, right? Awesome. So this is demo, which you're going to see today, just the overview of demo. I'm going to have one, three different microservices. All hello world microservices, no nothing big, complex there. I'm going to have a customer which is going to edge service from where things going to flow inside. I'm going to have a preference service. Preference is going to talk to two different versions of recommendation code deployed, right? I'm going to talk to V1 and V2 of recommendation and also play with the traffic distribution. I'm going to do 75, 25 to V1, V2, 10, 100% to V1, 100% to V2. And finally, I'm also going to play with request headers to see like from where it is coming. It's a request header example. You need to say if it's coming from Safari, then go to V2. If it's coming from any other browser, go to V1. All these things are going to be deployed done without code redeploys, okay? Let's get to it. No? Awesome. Let me give you a few links before this. I'm just going to go here. So this is there, right now in there, part of this is tutorial. I think Burr would have introduced that. This is the one of the tutorials we keep and maintain. The links are there in the slides. Don't worry about that. Once you get the slides, you can get the links. So I'm just going to run the commands from this particular tutorial. Don't worry that if you're missing the commands, you're missing something because the commands are right there. You can just go back and redo the commands by yourself as well, right? And I'm going to be on OpenShift. This is my OpenShift deployment, OpenShift 4. And then if you let me quickly go to the Istio system namespace. If you see here, let me show you all these things. What do we have? We have Grafana deployed automatically. The moment I deploy Istio, I got a Grafana dashboard. My Grafana is right here. This is again deployed. I don't have anything. No load is running right now. So we'll not see anything here. Let's go to the dashboard. I don't have any load running right now. And then I have Istio Citadel, the component you saw on Istio control plane. We saw Egress Gateway. The thing is Istio doesn't not only allows it controls the traffic that comes inside. It also takes care of the traffic which goes outside. Right, we can also control those things as well. That's done by Egress. And galley is to control the configuration. And then you have Istio Egress Gateway, like what you had Egress Gateway. I have Istio pilot, the policy for a security and other ACL checks. Sidecar injector, I'll come back to the sidecar injector in a second. I have Istio telemetry to collect the data and metrics. And there is a agar collector, something like what you see here, which gives you the traces. The traces that are collected from the services will be shown like this. So that like whenever I do a trace, I can go from one to end, start to end, showing like where the application started, how many seconds it took there, what happened, et cetera, et cetera. And then once I'm there, I can also have there of keali. Keali is nothing but your service mesh observability. Let me get back to this in a second. Okay, let me log in myself. I don't have anything here because I don't have any application deployed. I'll come back to this in a second again. I have Prometheus to get the data, collect the data from your containers, all your Java application, then how much memory, how much heap, et cetera, et cetera. I can use Prometheus to collect these. So you'll be wondering that, okay, I started with Istio and after some time, I feel okay, I don't need a mesh. What should I do? Go delete this namespace, that's all. There is no complex uninstallation is there. The moment I do delete this thing, everything is gone. And then there's no more service mesh is there, right? Your data will not be collected, you'll not be part of service mesh, which means that I can in a same namespace, literally I can have an application which can participate in a service mesh, which cannot participate in the service mesh, both are allowed, okay? Awesome. So what next? So obviously you can find all the things I'm talking about here on the Istio side. If you can go to Istio.io to find out all these things, and maybe the additional things also, which I'm going to talk today. Let's get back to my CLI. I'll show you what's the application is. So the people who don't know Java, don't worry about this. So I'm not writing anything here. It just says a response of hello world, right? I'm just going to go to preference, custom on the preference and preference recommendation. I'm just saying hello world. People are already provisioned with Java. You see that I'm not writing even a single piece of tracing or metrics collection or any kind of code here, right? Just business logic, in this case, hello world. I'm not doing anything else here, right? People are non-Java people, don't worry about anything here. It just says hello world. It calls another service, that service returns you a hello world again. It calls the final service, it also returns you a hello world. It collects all those response and displays that back to you, all right? Let's do this first. What I want to do is before I deploy this, I'm just going to go and show you the deployment YAML. So Burr showed you this deployment YAML. You just, I think you are aware of what the deployment YAML is. The very important things here is, just need to note about these labels. You have a version label, all the services, customer preference recommendation, everything I'm having a version label. It could be anything. I just call it as version here. And then in this case it's V1. And then if you see here, this is the sidecar injector is equal to true. So this is an annotation, which basically is that when I deploy that on an OpenShift or Kubernetes platform and Istio is deployed, when this is true, then Istio knows that I have to inject a sidecar. Basically, a pods are immutable. The moment I deploy my pod, I cannot change my pod. I have to do a redeployment to do any changes, right? What this basically do is when it sees its annotation during deployment, it injects a sidecar, which means that I don't need to add a sidecar here. Let's do one thing. Let's deploy without a sidecar first and then see what happens and then see what we want to do with a sidecar, right? I'm just going to change this to false so that my sidecar is not injected. Let me go back to the command line and then say I'll wash here. Oh, let's see. Get pod. Okay, I just have Nexus running to cache my application artifacts. I say OC create FNF customer Kubernetes. This is going to do a deployment YAML. When I say this, you'll see this customer pod coming up right now and if you see on the ready column, I just have zero of one, right? Which means that let's go to the console and see what it has in it. So let me go here to the OpenShift console and then go to my tutorial project here. So I have to go a long way because I have a lot of demos. Let me go down to my tutorial project and then I have a deployment created here, which I just do it in CLI and you see there's zero of one pod. Let's click this and go to see what it basically has. It is a pod, it's a customer pod and the customer pod has just one container which is a customer container which is my application container. It does not have anything else right now, okay? So what I basically done here is that I'm deployed that without a sidecar, right? And I don't have the Istio sidecar, just a normal application which you do a deployment. So to make it work with an Istio deployment, what I have to do is like I just go back here, change it to true and then say OC apply, right? Because I already have this deployment here and then the moment I say this, now we'll have a new deployment configured automatically for you in a second and then now you see that I have zero of two, right? That is an init container which gets right runs now first basically to configure your IP table so that it knows how to configure your service mesh and then you'll have to zero of two containers where I have an Istio proxy container and the customer container. So let's go back to the console again. When I go here, I don't have the container yet here. So this is old deployment probably. Okay, let's see the pods. What's the new pod right now? This one should be, let's go back to the containers here. I have two containers right now, your Istio proxy container. This was something which is all on my proxy that got injected automatically, right? Earlier if you've seen Istio from start, earlier like we have to do a manual injection, half late we have what you've done with CRDs, custom resource definitions and Kubernetes where it takes care of mutating your pod as well, right? You should be an admin to enable this. The moment you enable this, it can do a mutating of your pod and this takes care of all your infrastructure related piece right now, right? Let's do one call to the service. The first and foremost difference between Kubernetes here is this. What does enterprise Kubernetes does? I don't have any routes right now, all right? The role of the init container is basically to rewrite the IP tables. For example, what happens Istio does is Istio talks to the Kubernetes API, Kubernetes pods, which has its own IP, won't pod IP, won't cluster IP. It needs to know those details and then route all those things through Istio control plane, right? For that I need to write the IP table, rewrite the IP tables so that the routing happens automatically behind the scenes. Sorry? Annotations is there since almost, what you say 1.7 or 1.6? I think it's... Now it is 1.15 now. Kubernetes is 1.15 now and OpenShift uses 1.13 of Kubernetes because we take three months time to harden Kubernetes and deploy that. Right, I have to take this, make it rebase the images on top of Red Hat Linux and then make the images shared. Kubernetes, I mean OpenShift will not allow you to run any containers that run as a root user because running a container as a root user is a serious security hole, right? The moment I do this, I can reach any C groups on my host and take the complete host down, right? All these things has to be done. Kubernetes, all these things has to be done in OpenShift. Make sure that you're not allowed. You don't have, you have necessary permissions, Rbacks, what we call as, and then you need to do all other things, take the version of Kubernetes, make sure everything works as before, before I release the next version, right? It's not, it's done overnight, right? All right, so now coming back to what the difference between here is that I don't have any service. Probably let me see, I'll create a service as well here, OC. I'm just, this is a typical Kubernetes service. The moment I do the service, I get OC get SVC. I have the service here, but the service is not accessible, all right? Let me take my example of HTTP. This is an example. I come back to this URL again in a second. The moment I do this, I'll get an error because I don't have the service up. The root is not there. I don't know how to call the service. But this is the first thing. Probably in the first example, what Bob was showing, like you are kind of seeing this node ports, right? You're using node ports to call the service, but that doesn't happen the same way in a physical deployment, in a production, right? I need to have a more sophisticated way of deploying my application. So what basically happens right now is that I'm just going to say OC expose SVC customer. What I'm trying to do is I'm trying to create a route. You see this here? I don't have a route, which is for customer. Keep OpenShift has an HA proxy deployed automatically for you inside, and then it has the suffix like the long suffix that you see here. In this case, the demo machine. So I have a long suffix. It could be example.com or it could be anything else you want to have. I can have the suffix. The moment I say this, it automatically creates a HA proxy route, routing you through your DNS server to this particular service, right? So what I'm trying to do right now is I'm just going to create a service here, expose customer. The moment I do this, the service gets created and you get a new URL. This does not happen out of the box in Kubernetes. This is something which we have added on top of OpenShift. That's why we call them a center price because you need a new URL. It's not like I deploy an application, but how do I access an application? That is something which you have done out of the box so that the people who are deploying enterprise applications, they know how to create the URL as well, right? So since it's an edge service, this is the only service that I'm going to expose outside. All other things are going to be from inside. I'm going to call preference from inside, recommendation from inside as well, right? So what happens now? Let's try in working this. Boom, right? I don't have preference deployed yet. So what happens right now is that I just get an error saying that the preference is not available. So how do I call preference? I think I have a similar script these two tasks which we did right now, create a service, create a deployment, create a service, and then I don't expose a service. So what I'm going to basically do right now is that I have a script just to run those commands, deploy a preference, and then say, deploy a preference for you, and then you get one more preference pod. As you saw in this example, I'm going to have customer talk to preference, preference talk to two different versions of E1 and E2, all right? So let's do the other things as well. Let's do, I have the same script to deploy recommendation. I say V1, sorry. And it'll get this recommendation V1 deployed, and then I also have recommendation V2 deployed as well. The moment I do all these things, I'm almost ready to get all these things up and running for me. So let me increase this thing up a bit as well, so that I can start running this script. What I do now is I'll see get pods to see I have all my pods up. I have running, running, running, V1 and V2, all right? So I'm not deploying any Istio rules right now. So what basically happens is that I'm just going to make this window a little bit bigger so that I can keep it scrolling. So let's go back here. I go to the pods. I have a customer, preference, recommendation V1, and recommendation V2, right? To make it a little bit simpler, we go to deployment, customer, preference V1, recommendation V1, recommendation V2. They're exactly the same like what we want to have here. Right, I see only for customer I expose the service. Yeah, so we just, for other things, it's just the services there, okay? The similar service like how do we do the OC create service? The same thing, but it's just a preference service, that's all. So the moment I do this and then I say, I have a Polar, I'll come back to the question, I need to show something, sorry about that. So I start the Polar right now. Right now what happens is that it uses a default primitive load balancing that Kubernetes gives you 50-50, right? 50 to V1, 50 to V2, 50 to V1, and 50 to V2, all right? So now what we'll do is like, I'm not happy with this. What I want to do is like, I want to get everything to V1, right? What happens here is, let me open the file. This is something which we have to see. So this is a virtual service, it's again a Kubernetes CRD. The moment I see what it says is that go to host recommendation. If you see in that, within Kubernetes, the services are within the same namespace, I can just use the service name as my host name, right? That's a Kubernetes thing. And then I say, go to the HTTP route, go to this particular host, and wait is 100%, which means that to divert all the 100% of the traffic to V1. All right, that's what I'm trying to do. You'll be wondering what the subset is. So if you go, let me open the other thing, destination rule, destination rule V1. Let me put this on the other side. What basically happens with the destination rule is that I say, usually in Kubernetes, everything is using label selectors, all right? I want to say in the rule, what I'm trying to say, go to the service recommendation and choose if I'm going to use version V1, then it means to know that it has to go and pick out the services which has label version V1, right? And again, if you want to go to version V2, it has to go and say which of the labels V2 has one, right? This is how we do it. The reason being is that this is logical. So anytime I want to update the labels, I can go and update the destination rules so that your virtual service automatically picks those rules automatically for you, right? That's what I'm going to do here. So what I'm trying to do is like, I'm just going to deploy this, say that try out all my traffic to V1, just watch the scrolling there. It's just still getting V1 and V2. There's no more redeployments here. Once the recommendation is created, in a few seconds, you should start to see everything going to V1 now. Now you see, there is no more V2 now. On your services, everything, the traffic is all going to V1 now. I divert to the traffic, go to V1 because I just set the rule inside my wait for V1 is 100%. Like all the services or deployments which has label as version V1, divert all the 100% of the traffic to that, all right? Now I come back here and then say, okay, I'm not, I don't want to do this. I want to make all V2. Now I just do the same thing again. I just replace the rules. And then the moment I say the replace the rules in a second, you should start to see everything getting to V2 now. All these without code redeployments. I'm not doing any code redeployment, right? In the earlier days, if you're going to do blue, green or canary or any kind of deployment, you have to do code redeployments. I'd have to take the new version of the service deployed, but in this case, I have both the service available within my application deployment in Kubernetes platform. And I just shift using Istio rules, right? I just define the rules, divert the traffic in whatever way I want, right? The moment you also see this, when I go back to my console in Yegor, I think you should start to see some load coming into this as well. So let me go to the dashboard, mesh dashboard. You should see the ops happening here. The data getting scraped up. And then if you go to the service dashboard, it also shows you something here, probably down below. It takes some time to refresh. And then if you go to your workload dashboard, you should also see the operations coming here, right? That's the reason why I keep running those things. You see the workloads also happening, which gives you an overview of what's exactly happening within my system, all right? And also like if you go here and then find the traces here, I'm using the customer service, which is my head service to find the traces. You will see a lot of traces here generated because the service is happening. And then the moment you see here, like I'm just saying the customer is going to preference, preference is going to recommendation, right? You see the complete trace and then it gives you what time it takes, how long it took to respond, et cetera, et cetera. So with tracing, I know, I can easily identify where the bottleneck is in microservices world. So I'm fine with this. So now what we also need to do, I'm just close to close. And then let's go and see what Kali gives me. This is what Kali gives me. And the same tutorial namespace, let me see if I can zoom this up, 150, okay? So now let's play a little bit here. So I'm going to use a traffic animation. So now you see there's all my services are going to V2 and then you see the V1 is disabled there in grayed out. So this is gives you overall view of how your service mesh looks like, like what are the services they have, how what is service getting request, how my request is flowing, all right? And also you see this, all the requests are sending something to the agar collector, right? That's what I was saying to you. There is a Istio proxy behind the scene which sends the data, collects your metrics data and send to the agar collector. That's what is getting displayed on your traces, all right? And then I can also click on any service here. I just go here. Let's say I want to go to recommendation V1 and then I can also find the inbound and outbound metrics here, right? How much IOPS I'm having, what's the request size and what's all these things? You can get all these data because the data is getting collected by Prometheus and the Istio proxy takes care of collecting the data and sending to your telemetry and we extract the data from telemetry to do this as well. Okay? Another important thing what Kiali does is also like it validates your config. For example, I introduced an error there in the customer gateway in case if you deploy a Istio rule and Istio rule is not working. What could be the problem, right? Get into Kiali, click on the configuration and when I click here, this is just a warning here which says that, okay, I have another one which already has this particular combination defined. Just an example, I just induce this error to show you what I can also have this particular stuff here, right? And also like if you see the other cases, my other rules are good. So you see the green there, right? In this way, what happens, right? In case you deploy a rule, the rule doesn't work, get into the config, try to see your rules are green or if you have any warning, click on the warning to see what error it says and go fix back the rules and then come back again, right? So what if if I don't want any rules, I want to go back to the old one. I just say V1 and V2, I delete the recommendation rule. Now what happens is it starts to go back to V1 and V2 here, all right? Any questions? I can take your question now, sir. No, there's no comparison between that. I don't know what's a comparison. I don't know Apache, Spark, are you? No, no, no, come on, this here, the customer preferences recommendation is just a sample application, okay? It's not exactly your recommendation, it's not exactly something related to your technology. It's just a customer service, it's a recommendation service and a preference service, right? Anybody want to answer this question? Okay, so now it's fun, like see, see it takes the time, there is a deployment release lifecycle, which we follow, okay? I'm not an engineering guy, I'm an evangelist, okay? I just know that it takes three months, that's what my engineering people told that to come from one this state to another state because there's a lot of process behind the scene, hardening is not easy job. So they have to do a lot of things, validate this because we have customers who are running OpenShift in production, so any new roll-outs, we have to make sure that they're doing it correct, all right? So the data which is getting script, for example, if you see this particular one here, if you see the Kali graph, so if I enable animation, if you see that all the service are sending some white dots to Yeager Collector, right? Which is being done by a proxy server, your application actually doesn't do that, right? The moment I had XB3 headers, which are automatically added in this case, the moment I had XB3 headers to your request, it collects the request data, these headers, and send it to Yeager, right? So that it knows it started at 10 o'clock in this particular service, and it reached 10, one on this particular service, for example, right? And then that's the reason why you see this white dots going to Yeager Collector. So it's all done by proxy, right? That's the reason why, if you see the architecture diagram, everything goes to proxy. Last demo which you're going to see right now is that on the SmarterCandry, I said I want to distribute this traffic like this, the request coming from Safari has to go to one, the request coming from any other browser has to go to something else. So how do we basically do this? For example, let me open the rule, the Safari recommendation rule. What I'm trying to do here is, let me see if I can bring this up, this side. This is pretty much the same rule. I'm saying that if I have a baggage user agent, right, it could be any request headers. I'm just using a custom request header name, just to say that it can use any request headers you want. And I'm saying that if my request header has this regular expression, right, which contains Safari, right? If my user agent contains Safari, then I say that go to rule recommendation V2, right? The V2 version of the service. That's what my subset says. And then if I don't find this, what happens if the user agent doesn't have, it goes to the fallback and say that I go to this particular version of the service, which is V1. All right? So how do I do this? Let me go and deploy this rule. I'm just going to run the same script again. Deploy Canary. Okay, let me see what script I have. Marta Canary. The moment I see this, if you see once this, I'm just doing a bit of a clearing of all my rules so that it's clean and neat here. And then it'll start to see all my thing going back to V1 because there is no user agent going there. So let's take it, look at it from the browser as well. So let me go here. And this should be the one. Let me open the, what do you call the developer tools and the network tab. And then when I say here, so it goes to V2 here, because it's coming from this, how does it know it has to go to V2? So go back here and then the user agent has Safari in it, right? The regular expression says that, find out the user agent header. If it contains Safari, then take it me to the V2 version of the service. All right? Let me copy this URL and then do the same thing in Firefox. I'm going to do that in Firefox now because it doesn't have a user agent like that. So when I do this in Firefox, it goes to V1 because Firefox say that, let me see, I think this is the thing. Let me do it again so that I know this. And then when I loop back into the user agent here, right here, and then let me zoom this up. My user agent does not have Safari in it, which means that I have to go back to version V1 of the service. All right? Sounds good. I think this is an example, if an API kind of a guy, like then, okay, you can use your customer, let's say it's a gold or platinum or a silver customer, then you can use that header, a particular header to route your service to better nodes or better cluster, right? You can also do those kind of routing as well. So as I told you, Istio is not only getting inside, I can also go outside as well to a particular node, right? You can use egress, different node, different cluster, different URL, I can use anything you want to do. Right? So let's do one thing. So let me also show you the power of Kiali here. So what I'm going to do right now is that I'm going to stop this up, and then I'm going to delete the destination rule. So how do I find my destination rule? OC get destination rules. I got this command, right? I have a destination rule. Let's go to Kiali here, and then find the Istio config. All right? My Istio config is intact, and then I'm going to go OC delete, I'll just copy this to avoid any typo here. I'll delete the destination rule. I just delete this. The moment I delete this, if you go back to Kiali here, it says that something wrong with my recommendation, right? It says that there's a virtual service. This virtual service is not correct here. What's the reason? Let's go back here. Let me zoom this a little bit. I go here, two warnings found. One warning, no subsets found, right? Because the destination rule is deleted. So subset is nothing but a logical name, matching set of labels. So subset is not for meaning to say, like I'm not able to find the subset called as whatever V1, because I deleted the destination rule. So this way you can go identify your issues, right? What issues I have with my deployment? I go and fix this up. The moment I fix it up, you'll see this thing coming back again. So it has another rule saying no subset found for those three things, V1 and V2. Let's do this. I'll go and go here, OC create dash F is to your files, destination rule, recommendation V1. I'll just create one thing so that like V1 and V2 should be there, if I'm not wrong. If I create that, I just have one more minute left. Hopefully I'm on time for you to get your lunch. I create this here, the recommendation. Let's go back and check if the destination rules are there. I have the destination rule here. When I go back here and refresh, mostly I should get it okay, right? Now my recommendation service is good. The virtual service is fixed because I have the destination rule so that the virtual service can look at the destination rule for its subsets. And that's pretty much I have. So probably what I can also leave you with is a set of links where I have the tutorials, the commands which I typed right now, everything is there. So don't worry that if you miss my commands, I want you to get the concept, what's behind the scenes. Go to the Istio tutorial, all these Bitly links, candidate tutorials about serverless. We'll talk about serverless in the afternoon. The demos about basic microservices, all your video training, everything is there. So in case if you have any questions, get to the GitHub issues as earlier on these repositories and log us, probably we'll answer your questions there, okay?