 There's some really great synergies that go on between Red Hat and IBM, and you're about to hear some of them and get some great demos as well. Brian is going to be with us, he's going to do the front load this talk, and then he's going to disappear because he's going to call. And then he's going to come back. We have here. Absolutely. Absolutely. So I'm going to let him get started, and if you want to try to get started. Cool. Yeah, Steve will probably need the podium mic for tapping and doing everything at the same time. I am a far less intelligent and less talented portion of this. I am the one here to just sit and tap dance and talk about the technology. Steve is going to handle the show, I'm the tell. So speaking of the tell, we're here to talk about the idea of service meshes and where they're going, kind of the beyond piece of everything from here. So the big question, of course for most people is why is steel? Of all of the various things that we could be working with in terms of a service mesh, why is steel? And honestly, this kind of comes down to the area of kind of how is steel is actually designed in the context of being a service mesh itself. So with is steel, we've kind of learned especially through the kind of evolution of open stack and Kubernetes that there is a good mechanism of handling the design of a distributed system which is to say that there is a control plane and there is a data plane. So the control plane is, wait for it, is there to kind of ensure that the command and control of all of the actual pieces continues even when there is a failure within the control plane does not affect the actual configuration or data path of components within the data plane. And Istio is actually designed in that way. The way, what we actually have here, a number of control plane services like pilot, mixer, citadel and galley, which are all there to kind of handle discrete components of the way that Istio actually operates and then another component called Istio proxy which is actually derived from the CNCF project envoy. So with this, we collocate a number of containers together within a pod within Kubernetes and then that collocated sidecar for envoy actually executes much of the kind of functionality of Istio in concert with the control plane itself. So we're going to be talking about a number of major areas of functionality, the first of which is the idea of the connection between services. So historically with a service mesh, part of the purpose was to glue the inner communications between services together, handle a lot of the discovery and kind of rerouting of traffic. And with Istio, we are able to achieve that same similar goal. The connectivity between services actually is provided by the various discovery services that are available. There's been a bunch of work behind the scenes for abstracting the different discovery services into something called incremental XDS. But these are all used to kind of make sure that all of the glue between things, between your various service components are able to be scheduled together and consistently so that you don't need to go, what's the connection to or what's the host name for my database or how do I connect to Redis or things like that. The second major area that we really start to dive into with a bit more detail is the securing of services. And the primary mechanism of securing services within Istio is the use of mutual TLS. This is a combination of the AAA services, so the authentication and authorization provided by the combination of Galli, pardon me, Citadel and the Kubernetes API server, where the service account is used to actually provide the principle for a running workload. And then for that principle, we can actually get certificates which are short-lived generated by the Istio control plane, which then can be used by the different proxy components to decide whether or not inbound requests should be authorized. This is also, can be used with JSON web tokens and other mechanisms to give you a really rich framework for how you actually allow communications into the services. And this, it's that use of JSON web tokens and the kind of spiffy and spire type mechanisms that allow you to make the decisions about whether or not, again, inbound communications are allowed. The biggest piece for my side to talk about though is the control aspect. Istio's primary function is the control of how traffic is flowing between components. One example is the Canary deployment. You've got that small team of individuals working in Boston and then everybody else. And you want to make sure that that new version of the service that you're going to deploy works, but you want to test it on a small group of people before you just shotgun blast roll it out. So here we take Dan Walsh and everybody else in Boston, you know, we make them run the new version of our service, make sure that everything looks good before we roll it out. We can take this a step further though and actually use more of an AB deployment model where once we have established through the use of our Canary that everything looks good, we can treat this kind of like an oven knob and we can dial the number of traffic back and forth between our new version of our service and our previous version of the service, which allows us to, as we have a higher degree of confidence that our new service actually operates the way that we expect it to, that we are able to then roll that out to more and more users. As an aside, this is part of how we did the actual deployments of software within Container and Linux as well. So it's nice to see the sort of mechanisms that, you know, I've seen and used in production for years now becoming available to everybody else. Transparent to our individual services though, we also have the idea of circuit breakers. So this is taking and making decisions about how traffic should fail. Much in the same way that you wouldn't want to take a circuit within your house and just run 400 amps through it because you will burn it down. We don't necessarily want to just kind of endlessly flow traffic to our services because they seemingly, or they similarly could fail as well. So circuit breakers allow us to kind of make decisions about the ways that our services should fail and do this independent of the actual code. It also allows us to kind of improve response times where we can say, you know, in this case, you know, we've got a call chain of service A to B to C, you know, if we were to have a kind of failure between service B and service C or there's some kind of increased latency, we can make a decision about whether or not to just drop that request. Potentially it's not actually a critical path for the rest of our services. So it's better to have that service fail and keep everything running smoothly to keep our customers happy rather than just kind of having one slow node kind of pull everything down for the folks who ever worked with HPC systems and had to deal with MPI problems. But next up, timeouts and retries. Similarly, rather than having to implement timeout and retry logic within our applications, now we can do that at the actual proxy level. We can make decisions about, you know, should we, how long should we attempt to do the timeouts? And, you know, for how many times should we attempt to redo the request rather than kind of having to embed that logic in each bespoke language in each individual application? This also then coupled with the circuit breaking and the timeouts and retries allows us to do a lot more with rate limiting as well. So through the rate limiting, we can make deterministic decisions about, you know, do we care about the number of concurrent requests? Do we only want a service to see a maximum number of inbound connections so we can kind of make decisions there? We can also use these then to kind of take and flip that idea on its head. Now, instead of just kind of making decisions about what happens when things fail, we can introduce failures intentionally. You know, Mike Tyson famously said everybody has a plan until they get punched in the mouth. So this is the opportunity to allow you to actually, in a very safe space, have that sparring where, you know, you test what will happen when things fail and then know that your operations teams have that runbook established and know exactly what they're going to do. So beyond just kind of introducing time-based problems, we can actually introduce protocol-specific errors as well. You know, what will happen when there's a 400 error versus a 500 error? You know, will it attempt to do the retry because it's a transient error? Or does your application just always think that, you know, any type of error is permanent and that it shouldn't have to? So this allows us to kind of really make sure that everything operates the way that we would expect it to. The last area of functionality to talk about is observability. So for observability with Istio and specifically in the context of OpenShift Service Mesh, we mean two things. We are talking about the idea of tracing of our applications, generally through the use of Yeager, but also collecting and scraping of metrics out of the actual proxy components with Prometheus. And we can then visualize those with a number of tools that are available. But before we get to the metric scraping, the distributed tracing piece actually refers to making a request across a call chain, graphing the latency between all of those, and actually even capturing header information for the requests in a sampled manner. And I'm intentional about saying sampled manner because I've talked to customers who go, ah, great, this is basically like a PCAP. I'm now just going to record all of my traffic. And that means that you now need infinite storage to capture all of those infinite requests. So again, you should be sampling things and then taking a look at the overall patterns to make decisions about how your applications are operating. By capturing this information, though, and having the data in Prometheus available and the data in Yeager available, there's a net new project that Red Hat created called Kiali, whose purpose is to visualize the total running of an application. You know, in here we have the standard Istio Book Info service with the graph of all of the call chains with multiple different versions of the services involved. And for anybody who's interested in talking more about Kiali, we actually have the PM for Kiali Maltron here who will raise his hand. So if you want to go bug him a bit and ask questions, you'll be able to as well. But this gets into why OpenShift service mesh, why specifically? And this is that we have taken and glued a bunch of these components together that we think any administrator is going to need to have a well-running service mesh and coordinated this through the operator framework. So while, yes, you could just take the upstream Helm charts and slap them onto a cluster. The value of OpenShift is providing the automated updates, the management through CRDs, the overall kind of life cycle of all of these components and gluing it together in a sensible way so that you, the administrator, are able to focus on the things that matter, which is the actual workloads you need to run and not the infrastructure itself. So we take this and we actually present it as a layer of infrastructure provided by OpenShift. You know, this is now a new layer. It's a little bit of a different model than what some of our users are used to. But this is included with OpenShift Container Platform version 4 and above. So, you know, there is not any additional components that you need to license or anything in order to use this. So at this point, I want to switch things up a bit. I have the pleasure of being able to stand on the stage with one of the leaders of open-source development and specifically cloud-native development within IBM. He's been focused on Istio most recently. But Mr. Steve Dake is going to come up here and talk to you about Istio multi-cluster and where this is going in the future, both kind of with things you'll see now and talking about the overall direction in a really high level. So thank you much. So, hello. Oh, cool. Nice. Okay, cool. So folks can hear me. I'm an environments work group lead for Istio. I'm also a maintainer. I've been working on Istio for about, sure. I've been working on Istio for about two and a half years. My main responsibility inside of Istio is installation, automated operations, and multi-cluster. Installation and operations are well-understood problems. Multi-cluster isn't, and this talk is about what's beyond service mesh. So the purpose of this section is about Istio multi-clustering and what's beyond service mesh in the future. I'm gonna talk a little bit about multi-cluster. I'm not even gonna try to pronounce this manifold, but this is how we think of multi-cluster today in Istio. There's six dimensions. I'll get more into the six dimensions later. But this is how you would visualize this. How physicists or mathematicians would visualize this. If you study this diagram in detail, I can guarantee you your mind will be boggled. Mine is. So I try not to study it too much. It's just a cool diagram. It's an interesting way of representing six diagrams on a 2D display. So for our modeling of Istio multi-cluster, we've really got six different vectors. And we call them A1 through A6. A1 is networking. A2 is clusters. So these are the Kubernetes clusters we may have. We've got control planes, which is what we refer to as A3. We've got identities and trusts. Now another way of thinking of identities and trusts are policies, security policies, for example. We've got meshes. That's the concept of combining multiple meshes together. So one service mesh with another service mesh that is independent. They operate completely independently and securely. And then there's tendency. This is the idea that there's multiple tenants available in your service mesh. Now Red Hat OpenShift service mesh, I think the same in the product, does support multi-tenancy already. So they've got one of these, my display went. They have one of these multi-cluster vectors handled already. So we're good here. I think it just came back. So the six vector model, I spoke a little bit about the six vector model. The problem with the six vector model is whenever you have a vector, it goes from 0 to infinity. So one of the things we're trying to do in the future is figure out how to make it not go to infinity. And when you have six of these things going to infinity, that's a big problem to solve. So what we've started to do is what's called compactization. I think that's how the mathematicians pronounce it. The idea of compactization is that you can press things down into smaller compressible chunks that you can then model. Now what we want to model with this work, you can read the slides for what we think are the best practices. But really what we want to model is how Istio would be deployed across the world, sorry about that, across the United States, across APAC, across Amia, in different clusters with different tenets from one description language. So that's what we're after with this six dimensions. We want to compress this into one description language. So this is cool. I'm going to show a demo of how one very small part of this works, which is networking with security with TLS. So multiple networks, I'm going to demonstrate. And we'll give it a go. Hopefully it works. I'm certain it will. Maybe. We'll find out. I can get my display in there right to try that. So true story. I had this demo working. I spent about 40 hours getting it working the first time. And it was working great. And I was so tired at the end of that I didn't file a bug for a defect. And then guess what? I spent like the last 40 hours getting the demo working again, going through the same thing because I forgot what the problem was. So key to all the engineers, always file a defect. Very important. You probably know that already. I should have known better, too. So I've got this script called go.sh. What this does, let me kind of point over here. So I'll just talk a bit about it. What this does is this deploys the first section, CL1, CL2, CL3. That selects a cluster we want to run on. So cluster one is in the US. Cluster two is in Europe. Cluster three is in APAC. These are running on IBM Cloud, which is regular Kubernetes, not OpenShift. We deploy a certain set of services for this demo. So we deploy. There's 11 microservices in this demo. We deploy three in one cloud, three in another, and then five in another. And these microservices all communicate over the internet with security with the mutual TLS to connect with each other. The first part of the script deploys the manifest, the services, and the deployments. So that's what the first part does. The second part deploys something called a service entry. A service entry is a way of specifying a service that is external. This is very detailed. But a service that is external to the mesh in which you're operating. So what we do is we basically connect the SCs up to the different services and wire up the services across the mesh. So I'm going to give this script a run. By the way, this is the hipster shop demo. So Google has kindly put this demo available for free on the internet with the ASL2 license. Assuming my internet is working, this will start going. The way this hipster shop demo works is it's like a shopping cart system. And I don't think I have internet. Oh yeah, there we go. It's starting. It's just slow. A lot of people using the internet. So right now we're deploying some of the services on US. And then we'll deploy some services on Europe. And then we'll deploy some services on APEC. It's going to take a while. I was expecting it to be a little faster. It's a little faster than typically. It'll get there. Come on. I know you can do it. So what this is doing is it's actually deploying these parts up here. This first little part. And now we're getting into MIA. So it's deploying the MIA manifest, which is on a different cloud in a MIA. And now we're going to apply a manifest in APEC. It's like watching paint dry, it feels like. The internet is slow, such is life. I almost used my phone for the internet, but I might have. I had one bar. So I'm like, eh, I don't know. Yeah. I'm getting like, denial here. Denial services going on. OK, so we're getting the, I think we're getting APEC here finally. Excuse me. We're getting APEC. And normally, if you were to deploy this from your laptop, it would literally take about 40 seconds to get all of the services deployed and started. That's how long it takes me at home or in my office. So the next step is we'll deploy the SCs for each of the regions, or for each of the zones in different regions. Each of the clusters in a different region. So right now, we're deploying the SCs for US. And then we will deploy the SCs for Amia, guessing how long this is going to take. So the SC is up for region? There you go. That's exactly how an SC works. And since we have three clusters, we need to deploy two sets of SCs, one for one cluster and one for the other. And that allows us to route to those other clusters. That's one of the key important factors of how this works. Actually, that's a good point. Maybe I should take questions while this thing is deploying if there's any in the audience. Yes. SC, it's called a service entry. It's much like an endpoint slice. So within SCO, we just approved, I just approved actually, the integration of endpoint slice into SCO. So we're going to replace SC with endpoint slices, which is a new Kubernetes feature, although we can't do it quickly because it just came out. So we're very close. I feel it. It's coming. I feel it. Yeah, I'm feeling lucky. What's really cool though is I'm really impressed because the internet is clearly bad. No offense, Diane. You've done a great job putting it together at the event. But Kubernetes and kubectl are actually deploying correctly. It's awesome. It's really cool. So OK, we're done. Let me go to cluster two. And I'm going to get the services on cluster two. And the reason I'm doing this is there's a load balancer that's created by this demo by the software, the manifest. And I need the IP address from the load balancer so I can access the service. So if I just copy it, so it's right here. It's this line right here. I'm just going to copy this external IP. And then run this. OK, so I'm going to open this up. And a hipster shop demo. This is cool. Hipster shop. I hope this works. OK, it worked. Cool. Hipster shop on three clouds in three different regions. It looks pretty cool. So thank you. Brian made this all happen. It was all Brian. So real quick, I want to show some of the different features of the hipster shop because I think it's a really cool demo. Google did a great job on it. I'm not a hipster, but I'm really into Hi-Fi. So this vintage record player is looking kind of cool. I'm digging that. I'm going to click on that. Let me see what it is. What do we got here? Oh, wow, it's a Thorns. So this is probably like a $5,000 or $10,000 record player new. And it still works. So I'll buy that and probably sell it on eBay or something. I'll buy four. One's guaranteed to work. I'll add that to my cart. And these microservices are all communicating with each other across the internet, the 11 different microservices. I'm going to browse more products. Now I've got one item in my cart. We see that up here in the view cart. It's a little slow because we're going across regions. Normally you may not set an application up in this way. Typewriter. Maybe my typing can use some improvement. So typewriter looks good in your living room. It doesn't say anything about whether it works or not. It just looks good. I don't know. What's cool about it is you have to really press the keys hard. So let me add that to my cart. I'll just add it. It's not that much. 67, it's not the end of the world. So I'm going to place my order. And then all this stuff gets filled in automatically as it would in a normal form. And then your order is complete. So I paid $147 for nothing there because I'm not going to get shipped to anything because you can see down here this website is hosted for demo purposes only. So thank you. I appreciate your time. Brian appreciates your time. If Brian's still in the room, I'd like to ask him to come back up for questions. He had a call, I think. OK. I'm trying to process your order. Yeah, maybe. Who knows? Does anybody have any questions? Yeah. Sure. OK. Good question. I'm glad you asked. Yeah, the question was, how are these things wired up? How are they connected together? Really good question. So here's the single cluster hipster shop anatomy. This is how a hipster shop comes from upstream. This is, in fact, a cut and paste of a diagram from upstream. You see the front end is what we connected to. Internet's where everything comes in from. And this is all different services that the front end communicates with. So what I've done in my kind of hacking of this manifest, this was one manifest, what I've done for this demo is I put things into three different clusters in multiple regions. And the clusters are just in one zone. So for example, North America, I've got the email service, the payment service, the shipping service, and so on. Now these are all protected by TLS. So we've got US, we've got EMEA, and we've got APAC. The diagram's a little more messy. So if we do an AB, that's what we've got deployed. That's what it looks like on a single cloud. So you have to be really intelligent about how you structure your applications. There are a ton of use cases for this work, a ton of use cases. But you do have to be careful about how you structure your applications. And I want to make something clear too. Thank you for the question. It's a great question. I want to make something clear that we're in very early stages and we spent two years figuring out these six dimensions. So this is like one of the dimensions, like networking. That's one of the dimensions we've solved so far. We've got solutions for everything else. What we haven't done is integrated them into one solution. And other service meshes are kind of following us in this way, issues leading in multi-cluster, multi-cloud, whatever you want to call it, networking across clouds. Istio rocks for that. And I'm really proud of the team that's put this work together. Are there any more questions? Yes, sir. Yeah, oh, that's a great question. So today we already support that. We supported that in 0.9 or 0.8. It's called mesh expansion. You can connect Istio to a virtual machine. That works today. Now in 1.4, which is the latest version of Istio, we released a new functionality to add services to the mesh without a bunch of hassles. So you say Istio cut will add to mesh and you give it the name of the service and you're off to the races. That's all there is. In the past you had to do a lot of work to get that to work well. Now it's very well automated. I'm really impressed with it. Person at IBM did most of the work. Her name is Iris. Fantastic job. So thank you for the question. Any more questions? If not, we'll keep you here a little bit longer and we'll make you come up for the AMA session and we'll have microphones that we can run through the audience. So if Jeremy Yeater is here too, you got any final words? No, thank you. I just want to thank everybody for their time and Brian does too. I know he would because that's how he rolls. Yeah, thank you. We really, I'm very impressed.