 Well, hello, and welcome to our next live session for DevMation Live. We're going to be talking to you today from Richmond, Virginia, and that's my specific case, or coming out of Arizona for Christian Posta, who is our lead presenter for today. A couple of things you should know about Christian. He is the Chief Architect of Cloud Applications here at Red Hat. He is our guru for all things Cloud Native, specifically around Docker, Kubernetes, OpenShift, and how you build applications and microservices architecture for that type of Cloud Native experience and across the Kubernetes backplate. And there's one thing he's been researching lately, this technology called Istio. It's a new technology, just came out in May of this year, and it does change the game for how you build applications now. So I'm looking forward to this session. It's going to be very exciting. And we're going to get going right now. So Christian, I'm going to actually post a link to your book. So people know that you have a book specifically on microservices, and then you'll be ready to take off and get going. So go ahead and get sharing. OK, then thank you, Bear. Thank you for anybody who's joining or who's watching later after the live broadcast here. But so let me share my screen. Do you see my screen? Yep, looks good. OK, so here's the plan. Well, let me be honest. I just wrote these slides 20 minutes ago. I'm going to try to stick to about 10 or 15 minutes of talking and then use the rest of the time for demos. We'll take questions at the end. But I might be going through some of these slides quickly, just to set a little context for people who are coming up and they're hearing about this idea of service mesh. And I might be thinking, how does this apply to what we've done in the past? How does this apply to the current generation of microservice patterns and thought that we hear about? So I'm going to try to cover as much of that as I can. I'm going to leave some links where I go into that a lot deeper. My name is Christian. Like Bruce, I don't want to introduce myself too much, but there's two things on here that I want to point out. One is my slides. So at slideshare.net, these slides are already up. So you can just go there and get these slides. But then slides for previous talks that I've done are all of my talks that are there. If you want to reach out or start a discussion in my blog or my Twitter or my email are all great places to reach out. And I try to stay pretty active and on responding. All right, so let's get going. So microservices does kind of, and I wrote a book here on microservices. Actually you can go to developers.redhead.com and get a electronic copy of that. And an electronic copy of Ed's and Yenaga's book on managing your data in microservices architectures and so on. So there's lots of great resources there. I highly recommend that. Now this discussion of microservices and services architectures in general, I have lots and lots of talks about going to much more deep, deeper detail about this. But what we're talking about is being able to change our services faster to be able to keep up with the different things we want to try and put out in front of our customers and learn from. Not to be able to change our services faster and architecting our system in terms of dependencies, in terms of technology, in terms of our organization are all very important parts to this. And I won't talk about today, but I do want to make sure that this is stated up front. Because microservices we hear, there's lots of different definitions of it, lots of the benefits that we hear about. Some of these on this list are true. Some of these are plain false, in my opinion. To be clear, things like, or to give an example, things like breaking your service into smaller pieces is going to be, you're going to be more resilient to faults and isolate to faults. Well, you have to architect that explicitly. Breaking one app up into multiple pieces is actually going to increase your susceptibility to faults and is going to increase the possibility of those faults propagating and cascading and is potentially going to reduce your availability. Some of these things that we talk about, once you start to implement them and once you start to go down that path, you're going to face the reality. And there are ways to deal with that that we'll talk about. Because what we're talking about when we break these systems up is these systems have to talk to each other. They have to communicate and share. There's concepts that might be shared across the different services they need to interact with each other in some way. But as we move towards services-style architectures, microservices, so whatever you want to call it, what we're doing is we are, a lot of the stuff that we could assume in the monolith in a single application, we can't assume anymore. The complexity is being pushed out in between these services. And we have to keep that in mind. We have to solve for that somehow. You might be saying, well, I'll just use REST. Just be REST calls. And then that simplifies my integration and everything should be good. Why do I have to worry about any of this stuff? Well, the reality is because we're not just making an invocation of A calling B isn't as simple as this nice yellow line here. It's probably more like this where we're talking over networks. And these networks are packet switch networks that need to figure out a way to get packets more sufficiently from one spot to another. And that could end up with packets being delayed, packets being dropped, packets being duplicated and so on. So we live in this world and this network where these are assumptions that we could just rule out of our monolith but they can't in a services-style architecture. Problem, right? We've been sending requests from RPC-style requests to maybe even stuff like SOAP and REST and any of these that are going over the network, this is not a new problem. In some cases, I've seen people try to solve this and manage some of these issues that you'll face, like how do you find service B? How do you load balance over service B? How do you retries? How do you offload maybe some of this responsibility of the networking that we have to take into account? Well, we've seen different solutions to this. We've seen maybe using message queues to do this where we might send request response or try to do RPC over message queues. And that's quite a heavy-weight bloated way of trying to do RPC. It does kind of solve some of these problems, I guess, if you squint. Another thing we've tried is, well, why don't we just move all of that complicated stuff, including transformation and orchestration and routing and all this stuff into a component in our architecture that's going to solve all that stuff for us. Now, that sort of backfired on us because we overdid that and put too much business logic into those pieces. And if our goal is to optimize for speed in our services architecture, then littering business logic throughout our architecture is going to force us to stop and synchronize and coordinate whenever we need to make a change. That's not the goal. Now, there are success stories of people taking their applications to the cloud and solving some of these problems. Netflix is an awesome, awesome example. They're almost a poster child for microservices and they're awesome because they open source a lot of the technology that they use and they had to build to bring a services architecture into a cloud like AWS. Now, their stack was primarily Java and or at least at the time was and at the time there was no alternatives. The alternatives, the queuing systems, ESBs, all this stuff, these were not good solutions for the cloud. So what they did was they kind of had to hand build all that stuff and this was back in 2009, 2010 and they did and they shared it with us and it was a good example of how to overcome some of these problems. Now that took a tremendous amount of investment to build all this stuff. That's nice of them to share it but it was a tremendous amount of investment and other companies actually like Amazon and Twitter and Google, they all invested a tremendous amount of resources, money, talent and all that into building these sorts of libraries and frameworks. And in some ways, so Google had Stubby and Twitter had Vanagal and Yelp had SmartStack and they invested a lot of money into this. Now, what if you weren't using the particular language that this stuff was built for? What if you wanted to build a service in Node.js or something else? What we saw was since this functionality was built in terms of frameworks and libraries and it was baked into the application, these had to be various application specific libraries. As you can see here, the business logic and the network functions are all kind of commingled into the application and it's scaled, no doubt but now we have to solve the problem of, well now I'm using a different project or a different framework or a different library. Maybe if I'm using Java, maybe I want to use Spring, I want to do the Spring way of doing stuff but now you have to bring in all of these dependencies at the application layer. If you were doing Vertex, same story. Now you need the Vertex specific way of doing some of this stuff. And that, you can surmount that I would say if you're looking just at Java, but what about, right, all of those components? And you have to maintain them. Same thing with Golang, same thing with Python and you get the point, right? So having to invest into these language and framework specific libraries and not just investment, maintain them and keep them up, keep them parity, feature parity, keep them correct. That's a tremendous amount of investment that is not differentiating. You know, we talk about looking at microservices in the cloud and using technology, using IT as a differentiator. These things are not differentiating points. But since we're building these services architectures, we have to solve them somehow. We can't just wish them away. And things like services, so as you can read the list here, there's lots of things, services discovery, retries because services will fail. Now, you also wanna make sure you don't retry add it an item because you don't want these big retry storms. So you need some way of dealing with that. Timeouts, you don't want to, not paying attention to timeouts is a great way to introduce cascading failures into your system. Load balancing and not just simple load balancing but more adaptive load balancing based on request times and maybe even location, where these requests are the services are, maybe they're in different availability zones or different regions and you don't want to stretch across the network to get to them and so on. So having different load balancing algorithms rate, limiting circuit breaking, these are all things that we have to solve for. And having an individual application library for each one of these ends up bloating the application, complicating it with the dependencies that it has, the transitive dependencies that it has now. So that increases the level of complexity in our applications and we kind of want to avoid that. And here's the point. These are all horizontal concerns and they apply to all services regardless of implementation. So what if we could do this? What if we could say, just like, if you think about it in terms of how networking works, right, networking operates depending on which level you're looking at, but say level four operates on packets or segments and the things like reliability, retries, acknowledgement tracking, deduplication, these sort of things are baked in working stack. You don't see applications having to do this for packets, right? Now if we take a level, come up a level and instead of thinking in packets and segments, we think requests, application level requests, we want to be able to do the same thing. We want to build resilience and we want to build this networking resilience into the application, but we don't want that stuff to live in the application. What if we could have a single way, a single library, single binary that we can uniformly apply these to all services and we can allow heterogeneous architectures. We can allow using the right framework or the right library for that particular part of our services architecture. Like maybe we want to use Node.js and the rest of the app wants to be JVM and that's fine, but we do want to use it safely. And we can be very, we can make sure that these implementations are consistent and correct across all the different frameworks and libraries we want to use. So Meet an open source project called Envoy. Envoy aims to be that single binary that you can deploy that is application, language, framework, infrastructure, agnostic. It is a small C++ proxy that lives with your application. So your application is communicating with this little co-located proxy diagram, maybe better subjective, there's lots of colors and drawings here, but in this diagram, the downstream box is our application and I'm using the Envoy terminology here. So if you go to the Envoy docs, this is the terminology that they use. Now the application itself, when it wants to make network calls, it talks to Envoy and Envoy then talks to the upstream services. Now those upstream services may also have Envoy proxies co-located with them, but Envoy does the heavy lifting of the timeouts, retries, retry budgets, these sort of things. So the application doesn't have to have application-specific libraries to do all that stuff. Now the interesting thing about this is that it lives with the application so it can be highly configured specifically to needs. So you could have some same defaults, for example, and if the application needs to tune them, then they can. The config lives with the Envoy proxy. Now this is an interesting deployment model and it works very well in Kubernetes. In Kubernetes we can deploy pods and pods are a way of atomically describing a deployment which maybe consists of multiple containers. Now Envoy doesn't have to be deployed in Kubernetes, so I'm just saying that in the Kubernetes pod model it's a very natural fit that each one of our pods, each one of our application instances can have one of these proxies. Now once you have multiple services and they start interacting with each other and we're able to build this resilience into the service, we need a way of coordinating and configuring that. The control plane comes into it, so we need a control plane to control this. So we look at the proxies and the services themselves as the data plane and we look at a control plane for being able to configure and manipulate the different proxies that are deployed and that's where Istio comes into play. It is a service mesh that consists of a data plane which are the proxies living with our applications and the control plane that allows us to do things like configure the proxies, enforce policies, get telemetry from the different proxies in the data plane and we can do interesting things from a policy standpoint, from a declaration standpoint. We can make sure that any service, whether it's a microservice or a monolith or whatever is running in our cluster, these resilience features built in so that we don't accidentally blow things up by introducing a new service that maybe misconfigures something. We can also do things like security. We can manage security without the application even knowing it. We can say we're gonna do mutual authentication between the services and we'll manage that from the control plane because we have access to the services and we have access to the data plane and we're going to enforce mutual CLS between the services for declarations. Digging in a little closer, the different components that make up the control plane, the Istio pilot is what we interact with from the CLI or from the, we can implement a Kubernetes admission controller that makes sure every pod has these proxies deployed alongside with them. We can implement them in CI CD. The mixer, and I'm leaving links and I'll leave links afterward as I'm trying to speed up as I'm trying to get to the demo. The links go into the documentation at Istio.io goes into a lot of great detail. The last component that I'll talk about now is the mixer. The mixer is a component that the data plane interacts with to decide whether or not it has access to talk to the different services. It has access within a budget or a quota whether or not it really, it might be a lot of access, but it's access that too many times so it might not have quota for that. And these, the data plane can send back telemetry about what's happening at the data plane. So things like metrics that we might want to store into Prometheus or Tracing, distributed tracing that we might want to store into Zipkin. These things can be streamed back to the mixer and the mixer can interpret them based on the plugins that it has, and you can write your own plugins to interpret that telemetry. Okay, last, right. So Istio gives us a point of control to be able to control resilience, to be able to control the flow of traffic. I didn't really talk much about that, but I'm hoping to show that in the demo. The flow of traffic, what services are talking to whom and the security between them. And as we introduce, maybe we introduce new versions. We want to alter the flow of control and so on. So the demo I'm gonna show is, it comes from the Istio.io Book Info demo. So you can go to this page, I'm purposely using this demo, so you can go to this page and you can try this out yourself. The architecture looks like this. We have an API request coming into a product page service and the product page service then interacts with the details, service to get details about a book, and then it will interact with the reviews services and ratings services to get user reviews about the particular product. Now, you see the three different versions here. I'm gonna start off with the three different versions and I'm gonna illustrate how we can use Istio to control the traffic, to finally control it, to which version of the reviews wanna talk to. So without further ado, reach out to me anytime. If you have any questions, check out the slides. We'll check out the links that we'll associate with the talk, but I spent 20 minutes talking instead of 12. Okay, so here we go. I'm gonna walk you through step by step. This is the demo that you can go off and do yourself as well, if you go to Istio.io. We're going to set up the Book Info demo and what that's going to do is set up the different pieces. We can also open up some of the Istio components and some of the plugins that we have associated with it. So we'll open up things like the Grafana dashboard so we can see metrics and the Zipkin so we can see tracing and this distributed architecture diagram as well. Let's take a look at the app. It's defined, so we're gonna run this stuff in Kubernetes, specifically on Minicube locally here. We can see that we have a few objects defined here, the product page object, the reviews, the different versions for the different reviews. If you're unfamiliar with the Kubernetes syntax, I encourage you to take a look. So we have the different versions of ratings, details and so on. Now this is just plain Kubernetes. I will install those components but they won't participate in the Istio service mesh. What we wanna do is add the proxy. We're gonna use the Istio control, a little binary to do a cube inject. Now, if we come back and look at these, we see that a sidecar, an additional container has been deployed inside of each one of our pods. And this little sidecar is the data plan, is the Envoy proxy. So I didn't drill on it too much in the slides but Kubernetes allows us to deploy pods that may contain multiple containers. And in this case, that's exactly what we wanna do. Okay, so let's actually deploy it. We'll apply it. We'll apply it based on that cube inject. We see all of the different services and the different deployments that we have. So if we give that a sec to start up, let's take a look at the services we have. We see, let's give it, make sure that we actually have our pods. Okay, they're coming up. Let's give them a second to come up. Shouldn't take too long. These are all downloaded and should be ready to go. Awesome, they look like they're all up. Okay, so what we've done is we've installed our app, the different components of our app that are defined in Kubernetes resource files. We did cube inject, if you come see right here, using Istio control, cube inject onto our YAML file. And that's what added the sidecar proxies, which make up the data plan that I talked about in the Istio mesh. And those proxies now will communicate and interact with the Istio control plane, which means that gives us a point of entry into the service mesh to be able to control it a bit. So let's see, let's take a look at the pods we have. Everything's running good. We're gonna open the app in the browser and cross our fingers, because this is a live demo. Okay, so we see that it comes up and we see the basics. If I refresh it, what we should see is that the book info, the product page will load balance between the different reviews, reviews version one, reviews version two, reviews version three, like I showed in the diagram. So we should see load balancing, we shouldn't see it fail. So we see the three. So one version has no stars, one version has black stars, one version has red stars. Right now, if we come over here to Gryphon, we should see that we're also taking traffic. We're able to stream these metrics back to our mixer and put them into a metrics collection engine. Now let's continue. So let's set some routing rules. We don't have any routing rules, but we wanna be able to control the traffic in our matchdown. If I do get route rules, there are none, as we expect. We're going to force all of the traffic to version one of the reviews service. So if we remember there's three versions, we're gonna force all traffic to version one that we're going to apply. And so here's the DSL for describing the rules that we want to implement with respect to how traffic is routed in the mesh. We're saying down here that for anybody trying to talk to reviews, send it to version one. So let's implement that. We'll do a create and that should say created the rules. Now, if we come back to our app and refresh, all traffic should be going to the version that does not have any stars. I refresh it a few times here. We don't see any of those in there. Now, I did that. Now we can list our rules using the Istio control binary here. We can see that we have those rules here. The rules are stored in Kubernetes third-party resources soon to be updated to the new CDR custom or CRD, custom resource definitions. So we could get them, we can get the rules out of Kubernetes directly using third-party resources, but nevertheless, let's keep going. Let's say we want to deploy a version two of our service and we want to do a Canary deployment or ad hoc stage deployment, or maybe we want to do AB testing. And so we want to deploy that, but we don't want to send everybody there. We want to send just a fraction of the traffic or just surgically certain requests should go there. So let's take a look at the routing rules for surgically routing certain people to the version two of the review service. Now, remember just super, super quick, let's go back to the diagram that the review services are over here, the ingress, the traffic that's coming in, we're not routing up here, we're routing once the traffic gets into the cluster. So we're able to have fine-grained control over the routing that happens inside the cluster. So we're going to say anybody or the user Jason, when they're logged in, then we'll send them to version two of the review service. So let's create that routing rule. Now, if I come back to our app and refresh, I shouldn't be going to version two. I should not be going to version two because I'm not Jason. But if I sign in, as Jason, Jason, whatever, sign in. Now I'm routed to version two of the service, which is the, now we have stars associated with our service. Star reviews. But if I log back out, then I'm going to be taking the version one. So the routing is very surgical, very, very controlled. I can control what services talk to whom and the details of how that happens. So if we look at the rules, we'll get the rules super quickly. We see that our new reviews task B2 rule was placed in there. If we look at it, that was the rule that we implemented. So I'm hoping this gives you a taste of what we're able to do. I know there's still, I'm running out of time, Burr or anybody else. Can I keep going for another minute or two or should I just stop here? Well, pause right there because there's a really good question from Pete, specifically around the concept of is Istio or is anything manipulating the firewall D, IP tables? What's actually happening from the networking standpoint? So from a networking standpoint, the approach that Istio takes, and this is continuing to evolve in the community. So the approach that Istio takes by default, and this doesn't mean this is the only way or this won't work with other rules, but the approach that it takes by default is that there's a flat network and security is enforced at the application layer, right? And so that's why if I go back to the Istio control plane diagram right here, there's a component here called Istio-off, which is a certificate authority that can manage certificates and control who's allowed to talk to who at the application layers, right? Now, but that might not, absolutely there's going to be policies and expectations to be able to segment the network and firewall the network and so on. Inside of there is, I think it's a network policies implementation and that will more fine-grained be able to control through IP tables and firewalls and so on, what pods are actually allowed to talk to each other. And Istio is continuing to evolve and continuing to try to fit well with that model as well. Now, that's the last thing I'll say is there's some new innovations coming out of the Cilium project, C-I-L-I-U-M project. And so that might not, you might not see that bit for a bit, but that sort of kernel level by processing and filtering stuff might also come into play here. There's also another question. Treat it as a flat network as much as possible and let regardless of whether you're running in private clouds or public clouds or wherever, Istio controls the applications. Yep. Another question, earlier in the conversation you just talked about upstream service and that the proxy sits between you and the upstream. And of course in open source world, upstream means something and downstream means something. Can you really touch on that again? Yeah, so this like I said is specifically using the terminology that Envoy uses in their documentation. And in the Envoy world upstream are the services that we're trying to talk to. The downstream is the actual application front. So this is in terms of Envoy, that the downstream is your application and Envoy interacts with that. And the upstream are the services, the remote services, those could be other rest services, RPC calls, GRPC or databases or message queues or whatever. Envoy mediates that connection. Now in the open source world or at least the way Red Hat looks at how we productize our software, upstream is the open source communities for us. And then we end up curating and supporting the enterprise software that comes from the upstream. The downstream is something that after we productize, so for example, Fedora might be an upstream, REL is our product and CentOS would be a downstream. But so those terms can be kind of confusing but I'm using specifically, if you go to the Envoy docs I'm using specifically their terminology in this slide. One more question that just came in and it's a good one and Christian, you're ideally suited to answer this. Where does Camel fit in this new architecture? Like in this new world where we have these sidecars, we have this proxy in between me and the other service, and takes care of source discovery, takes care of load balancing, and takes care of circuit breaking and tracing, all those microservices capabilities. But where's Camel play and how would it integrate here? Yeah, okay, so that is an awesome, awesome question. I have a blog post that addresses exactly that. I won't dodge the question, but if you can see there's a part how some of the drawbacks to the ESB as conceived and implemented in real life. But how the business logic and things like orchestration, protocol, more advanced protocol, mediation, message transformation, these message splitting and aggregation and these types of things are not the purview of the service mesh. These are still to be done outside the service mesh, ideally in your application services, not in a centralized ESB per se, but inside your service. And that's where Apache Camel comes into play. So Apache Camel is a Java library. So again, this is just for JVM based services, but Camel has the heavy lifting to be able to connect to various different protocols and be able to do message transformation and more complex serialization, deserialization and message orchestration and splitting, aggregating, recipient list, all that stuff, fitting in with stream processing, all that stuff. So that happens at the application layer. The Istio Envoy service mesh stuff happens at, I'm calling it the application networking layer, which involves thinking about the requests that are going over the network and having some basic understanding about them just like the networking does lower levels with IP packets and so on and being able to apply some rules and control at that level, but that's it. We have to draw a boundary, we don't want this to bleed into well, now the service mesh just becomes ESB or whatever. So we want delineation there and really we don't really wanna have to worry about it. We wanna know it's there, we wanna be able to configure it, we wanna be able to configure these resilience and control parameters, but we don't want that in our application code. And so that's where the service mesh is. It is a very good question. I did add a link to your blog so people can go and look at some of these blogs you've written, which are absolutely fantastic and I personally really appreciate them. But we're out of time, but there is one more question from Marcelo that I thought would be good to touch on because you do mention the fact that logging is none of those core principles that's been pulled into the sidecar, pulled into this new architecture. Does that integrate with Fluent D, like we've done with OpenShift and Kubernetes? I would say that things like request level metrics, request level telemetry, so number of requests, which requests are failing, which ones have circuit breakers open, which ones have 500, whatever, well, those things would fit great with in the service mesh. Now, application logging, I would think that's still done the same way we would do it in OpenShift or inside the Kubernetes where Fluent D is pulling down the logs directly from the containers and aggregating them into Elasticsearch, whatever. So now you're tooling for your logging, you're tooling for your metrics. Now, later on, maybe that evolves and maybe the data plane is able to slurp up the logs as well, but right now it doesn't do that. Okay, well, very good. Christian, thank you so much. It's been a phenomenal presentation and we will definitely try to schedule you for the future, maybe a deeper dive into this architecture because it does seem to be that the world of microservices is moving from the old world of Netflix to this new world of, I guess, Lyft and Uber are getting in the game. It looks like. And Google. And Google, yeah. Again, thank you so much. Yeah, my pleasure. I'd be happy to come back and do a more in-depth deeper dive of this, but this is just high level for now. Yeah, and if you guys have other questions, feel free to chase Christian up on Twitter. I gave you his Twitter handle so you guys can find them there. And of course, you can always find me on Twitter or myself on email. So there's easy ways to find us all here at Red Hat Land. So please do reach out to us if you have further questions. Thank you so much. Thank you guys.