 So, let me just, before we get into this, I just want to say I wrote this session to be beginner level. So, if this is your first time hearing about Istio, you're in the right place. And even if you've used Istio, hopefully I can teach you something new. It's going to be dynamic. It's going to be fun. So let's have some fun. We've got 35 minutes to jam in months of content. So let's have some fun. Keep it dynamic. If you have questions, feel free to raise your hand and I'll answer as I can. Okay. Setting sail with Istio. Who knows what Istio means? You. It's a sail on a boat. So we're in the Greek terminology land. All parts of a boat. Istio is another part of a boat. I think it's a sail. Is that anybody disagree? No? Okay. Great. Great. So, let's ponder this. The Mona Lisa. I took this three days ago. Think about this. Service meshes are the new black. So this whole conference has been service meshes. Did anybody know about service meshes three days ago? Probably very, very little of us. But I looked at this tweet and there was something quite profound in this tweet that I saw. Does anybody see it? Obviously, from Jesse, it's fantastic. What I see is a community that's maturing. So now we're not as worried about being in the details of Kubernetes. Now we're looking at running microservices and applications over time and all the tool kits we need to actually do that. So this is a sign of us as a community maturing and now we're looking at we have a Kubernetes. Now what can we do with it? Kubernetes is growing up. So this is a great thing. So don't be scared of the service mesh. Hopefully I'll demystify it a little bit. But I think this is a really profound statement from this KubeCon and hopefully everybody leaves this room knowing just a little bit more about Istio and service meshes. Two and a half years ago, I was a young little boy with starry eyes looking out the window in my office in San Francisco. My old boss is actually here up the front. I won't call him out. I was looking out the window. I'd heard about microservices. I bought the books. I'd read the blogs. I'd sat in 15 Adrian Cockroft speeches about microservices and Netflix. I was a convert. I had a mission and we were going to do this. What did I do? I went out and I took a look around and we landed on Kubernetes. Thanks to my boss. He'd lead that ship and got to call him out, give him credit. We landed on Kubernetes. We started moving these apps. We started getting into microservices. Things were great. Things were doing really good. This was the platform. We were going to get to microservices. Things were great. Like this picture, right? Things were really going great. We got to our 10th or 11th service and it was a Sunday morning at 3 a.m. We get the phone call. I'm on call. Service is 11 down. I don't know why service 11 is down. I've got no visibility in what's happening. I've got no idea what's going on. Please ring the owners of service 1 to 9 to figure out why service 11 is down. What's going on? I have no way. So soon this bubble bursts and I'm not to say microservices are bad but when we take a look at Istio, we may have some pain relief there. The monolith is over there. This is a comic from the Google container guys. I don't know if you saw this. The folks over there put out this comic. But we've taken that big monolith which we knew about and we knew how that monster worked and we split it up into a million little different gremlins with their own agendas and they're all running in different directions. Let's see how we can apply Istio to this to actually try and solve some of these problems. Can anybody relate? Is this a story? Was anybody else a starry eyed boy or girl looking out the window saying let's do microservices and convince your company to follow you? Yeah, everybody's done it. Good. I'm in good company. I'm not the only one. Thank you. Validation that I'm not crazy. Who am I? I'm lucky. But more importantly, I'm speaking from the perspective that we've been through this journey and are still going through this journey. You're not alone. Most of us are solving this our own different ways. But let's take a look at some tools out there and maybe gather around these tools and start building a community around them. I look at Istio now and what Istio is is something that we tried to build because we saw the need in a microservices platform and we saw the Kubernetes. It's sharp edges. You can't say it's the kernel of the cloud. It's the assembly language it is. It's not a platform for microservices. It doesn't have all the bells and whistles, right? You need to build platforms on top of it. I still help customers with Kubernetes today. So I see a lot of folks working with a lot of folks looking at Istio and looking at solving problems. So I speak from that context. And I wrote the upstream helm chart. So has anybody used the helm chart? Good, bad. You can say bad. Good. Thank you. Thank you. But all this to say microservices are hard. This I think Clayton got up on stage this morning and said we need to start building platforms for microservices, hence seeing all these service messages. But building microservices is actually quite hard. And it's hard because it's completely different to what we used to do. So let's take a look at how we can start digging in. One final quote. It's really complete without a quote from Kelsey. But Kubernetes is a platform for building other platforms. So now we're happy with Kubernetes. We know how it works. We've fiddled with all the knobs it has to offer. But let's start looking at building platforms on top of it. Kubernetes is not the end game. It's just the beginning of our microservice journey. If we look into why microservices are hard from my perspective, is most of us aren't operating in green field environments. This isn't day one of our startup. We have legacy applications and for better or for worse, they are there to stay. They're often making us money. That's paying our salaries. So we're operating with that baggage. We have the big monster. We can either break him up or build little smaller monsters, whichever way we want to do that. But microservices I think is an ecosystem of people tooling and process. And in this equilibrium of those three, tooling is the easiest thing to change. Tool and process take a long time to change. They're hard to change. So tooling, people look at the answer to tooling. And hopefully some tools today that can help change your microservice journey. So these all take time. And what we came to find is microservices exposed all the cracks in our architectures. So everything we had designed to do, now we've split it up and not gone back and rethought a lot of things. So problems that were once hidden in memory that you didn't see inside a heap are now spread across a dependency graph of RPCs across 15 different services. So you've moved a problem, which means once well understood problems change. So production uptime changes. The way you need to monitor and start that. Istio has features for all of this. So we'll take a look at those. And as I said earlier, the great thing about microservices is that they're easy to get on to. You get on, you get your first two or three up, you're feeling good, things are going really quick, you've done it. But things break down when you're at 10, 20, you have this Cambrian explosion of services everywhere. And you have no idea how they're communicating and where faults are. Contract points, SLAs and responsibilities. If we talk about them, developers own services and microservice architectures, they're responsible for contract points and APIs. And when these things fail and they have all their own SLAs, we need to understand where the system is broken and how to fix it. Nacent tooling and bespoke, a lot of this tooling is less than months old. We're working in a very highly dynamic environment. So people are picking up new tools, trying to bolt them in. So you're making this Rube Goldberg machine of tooling. So hopefully something like Istio can help give you a stable base. And you're not yet equipped, you don't know what you don't know. So nobody can tell you what you need to do. And there's no handbook or guide on microservice. You need to learn them in your own environment and what makes sense for your own business. So out of all of this, it's what do we need? This is kind of the laundry list. What do we need? Observability, monitoring, metrics, tracing, traffic management, policy, security, easy. Each developer can do this, right? Yeah, but who does that? And in today's world, and what I've seen is each developer or development group is actually solving a lot of those problems independently, and not bolting them together at the end. So because the expectation is that they all individually solve them, because there isn't a platform they can turn to to solve them. So I want everybody to kind of think about Istio, why you would use it before I give you the goods. Because I think you all need to think about where it fits in your workplace, in your environment, it's not the be all and end all for everybody. And should the platform provide an abstraction? So you've got a lightweight platform that's now portable in Kubernetes. Can we build that up the stack and make that just as portable as Kubernetes? It runs everywhere, everybody gets the same experience. So finally, we're all here for Istio, Istio, round of applause for Istio. But you can give me that at the end. Because if I don't convince you, don't clap. So it's a microservice platform or service mesh, if you like to call it. I call it a microservice platform that provides all those features. And the great thing is if you're a developer, you need to know how none of them work, you get them for free out of the box, which I'll demonstrate. As an operator of the Istio system, you need to know how some of them hang together. It plugs into Kubernetes, so Kubernetes is incredibly versatile. We're talking about Istio in the context of Kubernetes. But Istio is pluggable, so it can plug into Cloud Foundry, it can plug into Messos, it can plug into Kubernetes. It is completely detached, though, so that it's portable across. You'll have the same experience across those different infrastructure providers. But it's not a silver bullet, it is, as Kelsey said, we can start building those next level platform. It's looking at the problem above, right? How do we create a great developer experience in a microservice-oriented world? You with me? Yes, I need a yes. Okay, so just high-level features on the bulletin board here. Traffic management. Traffic management, you've got 10 features deep. When I talk traffic management, this is how you're controlling your traffic flow inside Istio. So when we talk about that, we can do smart routing. We can do fault injection testing. So we can say, please throw away 10% of all these RPCs between services on given intervals. So we can look at how our application stack performs in bad times and start injecting that. We can do ingress routing, which we're all familiar with, but we can also do egress routing. So that's getting on and off the mesh. So I'll talk about that in a little detail soon. Metrics, logs, and traces. Who here is running any distributed tracing? Fantastic, fantastic. You get that for free. Jager and Zipkin, so I'll show you how that works. And security. So we actually can control MTLS. The developers don't even need to know. So we have that level of control to have mutual TLS under the hood on all our network RPCs. So now I'm going to change hat. That was Locky the starry-eyed little boy, and that's Istio. But I want to go into now I'm going to divide this. Istio for operators and Istio for developers. And we're going to get into the weeds a little bit here. So Istio is a microservice platform that is itself a set of microservices. So these all run on the Kubernetes cluster, and they all have different functions we're going to go through now. So Pilot, the head of the ship. If I was to boil down Istio and what it does, it is a distributed control plane for configuring Envoy. Now Envoy wears many different hats, and you've probably heard of Envoy several times this week. Envoy is great. Like an Envoy to Nginx or HAProxy, it's just complete rewrite in C, and it's highly dynamically configurable. Where HAProxy and Nginx traditionally are config file HUP, you can have Envoy connected to a distributed control plane. And in Istio, that's actually what makes up the service mesh. So what Pilot is doing is the control plane for the Envoy instances. It's a system of record for the service mesh. So all the Envoy's are getting a single set of configuration from Pilot that's distributed across there. It's abstracted from the underlying platform, so the way the system is modeled inside Istio is abstracted from Kubernetes, and we have what are called adapters. So the Kubernetes adapter knows how to read the system of record out of Istio and model it onto that platform. And when I say model it, what it looks like under the hood is ingresses and CRDs. So you're working with Kubernetes native resources under the hood, and that's where Istio is actually storing its state, which is ending up. There's no other database other than that as a system of record. It has some very light, pluggable APIs for service discovery, load balancing and routing tables, and there's a client that can actually plug in, and you can change your routing on the fly, move, canary things, black hole things, fault inject things. And these, as I said, what we're talking about is dynamically changing the configuration of all the Envoy, so I'll talk about how Envoy goes there. So just to visualize this, and I'm sorry if it's not big for everybody in the back, I'll put the slides up. So basically you have the API over there to the left. On the top, in the orange boxes, you have all the pluggable adapters, Kubernetes, Messos, Cloud Foundries. You have the abstract model, which is all the data and service types that Istio need, and then you have the Envoy API, and all your Envoy's are finding home to get the config, right? So as the system changes, it modifies. So Envoy is the distributed data plane. Any questions on pilot? Keep moving. Okay, so Envoy, data plane, it lives, where does Envoy live? It lives as a sidecar in each pod. How does it get there? Well, there's two ways it can get there. You can use a tool to inject it, which if anybody knows a pod spec, you would inject a separate container, which is Envoy. Or you can use an initializer. So if anybody's used an initializer, you can have a pod that's running inside Kubernetes, and you tell the Kubernetes API before it accepts the request to shoot it over to that pod, and that pod will actually modify the content. So it's actually putting that sidecar in on the user's behalf. So the user actually doesn't need to know that Envoy is getting injected into their system. I'll demonstrate that soon. Envoy itself wears a couple of hats in the Istio context. It serves as a sidecar for all the data coming in from all your applications. It also serves as an ingress and an egress. So it's all running Envoy just with different configs. So Envoy even inside Istio has many different roles. Ingress and egress, I think this is worth mentioning. So everything's coming onto the service mesh or onto Istio via an ingress. Envoy is then planted. So Envoy knows about all the other Envoy's and Envoy's communicate to Envoy's through their own mesh. They've built a mesh. And your data goes down to your service inside each pod. External traffic goes out via an egress Envoy. And this is important. When we talk about egress, as I've had use cases from customers, how do I get a stable public IP for all my traffic that's going out if I'm sitting in the public cloud behind a NAT or five different IP addresses? How do I get it to come from this geographic location, this IP address with Envoy egress routing? You can actually say everything from dev needs to go through that set of egress routers which have these IP addresses or these public identities and production another set. So you have a way that you can smartly move in a multi-tenant cluster your traffic. Mutual TLS, so in the early days, I think back when I was working with Joe, we implemented something to do this on top of a hashicot bolt. But anybody who's tried to do this, you're not gonna be proud of what you've done. Istio actually makes this really simple. So it's using Kubernetes native primitives. There's a CA that's shipped with Istio that you can turn on or off. So you can enable this functionality. But each service, all their communication and MTLS session will be established between those endpoints for each piece of communication. And the life cycle of all those certificates are managed by Istio. They're laid down as Kubernetes secrets and they have an identity per service that's all handled without the user needing to know. So under the hood, the CA watches for Kubernetes service accounts then creates a key pair and dumps it in as a secret that gets mounted into Envoy and put in its config. Mixer, just to kind of round out the operator piece. So Mixer is the policy engine. So here's where you have all the knobs you can tune. So we can take care of telemetry, billing, quota, tracing, access control and Mixer, Istio gives you long week. Some generic plugins so you get pluggable adapters. So the ones that the ship with out of the box are things like Prometheus. But you could plug in any third party tool and have Istio fire a trigger and manipulate the shape and how traffic is being routed across your mesh. So this information I say the last piece there is attributes. So attributes, because everything is going via Envoy, there's a massive ton of metadata about what's happening in the system and all these attributes get aggregated back up to Mixer. And then you can do what I say to any, create handlers like a Prometheus handler. You create rules and config. So when I see this, do that and modify the machine as it's running. So modify the mesh real time while things are going. You can have human input or you may not have human input. And these are all expressed under the hood as CRDs. So again, we're not leaving the Kubernetes API. Okay, I probably talked enough. Demo time, demo time. Anybody wanna demo? Yeah, right, all right. Okay. Let me just get my screen back here. So what I wanted to show you all and let me know if you can see. Is that big enough for folks in the back? Bigger? Okay, all right. Fantastic. So Istio for operators, I'm gonna show you how to install Istio. So there's no magic here. Let's just prove that to everybody. Cube, cartel, version. I have a Kubernetes 1.8.2 cluster running here on Azure. And what I'm going to do, actually to prove there's nothing else, let's just show you that it's just vanilla here. I'm just default cube system stuff running right now. But what I'm going to do is use Helm. I mentioned the Helm chart. There are installers upstream on the documentation. I will show you where they are. I'm gonna use Helm. Helm just gives me a little more flexibility. So let me just show you how I would express this in Helm. Okay, so I'll grab this and I'll walk you through what we're doing here. All right, so what I'm doing here is I'm doing Helm install. I'm telling it that I want to, let me go to the command here, sorry. I wanna install the incubator in the incubator repo of the upstream chart repo. I wanna install Istio. And I wanna install 0.2.12, which they just released 0.3 last week. And I wanna use the initializer, which we'll go and take a look at in a minute. So what it has done, I'm doing this in two phases. What it has done is installed all these CRDs that the Istio system relies on. So I mentioned them, so you can see a bunch of different types of configs here that can be expressed through CRDs. But all I'm gonna do now is just go back and tell it actually to upgrade that and deploy Istio. The first pass I lay down the CRDs that it needs that are dependent. In the second pass I actually go and install Istio. Now while that is happening, I will pop to this other window. And what I should end up with is an Istio system namespace. Nothing yet. So let's watch that. What I would expect to see is everything that I just spoke about. We should see a CA, we should see Mixer, we should see Pilot, we should see an initializer and a few other bits and pieces like Zipkin, Grafana and Prometheus. So once this installs, we can go ahead. It takes a few minutes to install. It's pulling down the source chart from the upstream repo, unzipping it and then pushing the resources over to Kubernetes. So while that's happening, do I can take questions or I can move on? Any questions so far? I'm gonna show you what we've got. Just so happens that it passed. Question? Yes, yes. So BYO Kubernetes cluster on any provider or anywhere as long as you have a compliant API, you should be fine. And I just installed it straight on. I'm putting it into the Istio system namespace, but you can put it in any namespace. So what you can see here is I have the CA, the Egress, Grafana and Ingress, an initializer, a Mixer, a Pilot, a Prometheus, a Service Graph and a Zipkin. And that has just laid down the complete architecture. It's very lightweight. Istio, for all intents and purposes, is up and running. The only other piece of information that I need is to complete this demo. Get service in the namespace Istio system. Okay, so I should have an Ingress service here that will expose a public load balancer. So I should be able to get on and do that. Okay, so let's go back to the demo here. So now I've spoken about Istio for operators. Now that is all transparent to the folks that don't need to know that. You know how the sausage is made. You know how it hangs together. If you're an app developer, you may not necessarily need to know any of that. So as a developer, you don't need any of that knowledge. So who here has never used Istio? Fantastic. Who wants to come up on stage? Who wants to use Istio? I need a volunteer. Anybody? Come on up, come on down. Give them a round of applause. Can't get anybody up. They don't know what the prize is, but you're gonna be in for a surprise. Okay, so I have, I'm gonna let you drive in a minute, but I have, and this is one of the upstream demos, so you can go and recreate it at home, bookinfo.yaml, which deploys a set of microservices, right? So there's no rabbits in this hat. What I would like you to do is take Bookinfo and put it on Istio, okay? Using kubectl. So you're actually in that directory and it should just be there. So using kubectl, can you please deploy something on Istio that you just wrote? No, use kubectl. Okay, congratulations. You just supplied something to Istio. I think the magic is now. So, okay, what do we see here? And without digging into all the ammo that was there, is everything, there were all single container pods there that we had set up, but we actually have two or two and you see some in pod initializing. So I actually have the initializer running and as I said, the request comes into the API server, it passes it to the initializer, it's putting in Envoy and then it's before it deploys. So we should get everything up and running eventually. Those two will come up, but just to prove what we've got here, if we do a describe on that pod, I gotta give it pod, we should see that we have a sidecar here with Istio and it's running in proxy mode. So this is all transparent to the user, the gentleman that just came up on stage, did it without any knowledge, he just used the standard tools and that has actually been applied. Now what the gentleman that got up on stage here did not know is that he got a whole bunch more things as well. So as a user, what we can now do, and I will pop back to my operator hat, if you're using the Helm chart, it gives you a bunch more information here, but we can actually go and interrogate this app that he just deployed. So I'm gonna take the opportunity right now just to show you the documentation and I'm running through actually this demo right here so you can go and dig in at home. Obviously I don't have time to go through it all right here. But what I'm gonna do is just follow this documentation. All we did was deploy it and we did the automatic injection, not the manual. So there is a tool where you can manually inject in the sidecar. So once we get this list of services, I should be able to in the Istio server, services in Istio system, right? I now have this public IP, right? Which is my ingress from the public internet to get on. I'm just going to take this test. All I'm testing right now is that I can hit the, this app that we just deployed. And I'll grab this curl command. So this is great because you'll absolutely know what to do when you wanna test this out and actually trust that I wasn't messing around. So all this is doing is hitting that gateway URL. I'm getting a 200 back. What I should be able to do here is grab that IP address and throw it into a browser. Not that one, this one. And I should hit web page was not found at address. Did I grab the whole address? Thank you. Yes, got me. Thank you. There we go. So we have an app that's rolled out. I'm actually just gonna go and throw this curl in a while loop here to generate some traffic. So let's just do a while true. Do that. Space, thank you. You can never type when somebody watches, can you? And I'll do a sleep one done. Right, so I'm just running that in a loop to generate some baseline traffic here. Now what I would like to do is actually show you all those platform features that we spoke about earlier. So if I do a helm status, Istio, so a helm will actually tell me a bunch of information around how Istio has actually been installed on this cluster. I'm gonna grab access to some auxiliary tools, tracing, monitoring, and logging, and show you what we get out of the box with that application. And while that is going, probably grab the information here. So all I'm gonna do right here is show you. Okay, yeah, we're good. So all I've done here is grab the .viz, and I'll show you what .viz is in a sec, and I'm just running our port forward through to the pod so that I didn't expose it on the public internet. So what you see here is actually the dependency graph of the RPC is going through that application. So we see here we've got some traffic coming in, we've got how many requests per second, we're hitting this product page, and then we're getting the reviews, and we have three different review applications at the moment. We have a details and a ratings. So if I was to go back to the UI, what those three different reviewers, there's one with black stars, there's one with out stars, and there's one with red stars, and because we have no route rules in at the moment, we're hitting all three of those different back ends, which are V1, two, and three of that review system. And what you can actually model here is you can see those requests going to these three. Right, so now I have a dependency graph on my RPCs that's given to me without any knowledge. I just wrote the app, I get this for free. Would this be useful to anybody? Think I think, I think I like it. Now the other thing I wanna show is let's take a look at some dashboards here. I'll throw this in the background. Again, it ships with out-of-the-box Grafana dashboard, and all the data is being grabbed by Mixer and placed into Prometheus, and Grafana is querying Prometheus. So here we have a nice dashboard, I hope everybody can see, I can zoom in, but we can see how many operations per second, the response rate, how many 500, so I have a serving application here that's running, the responses, where we're hitting, what the time source, the version, we get this wealth of information coming out of Envoy and Mixer without the user knowing anything about this. Because Envoy is intercepting every piece of traffic, annotating it with attributes, Mixer's passing it, and spitting out all this information. So not only do I have some baseline visibility now on my application, I haven't had to go and build it myself as the application developer. So these are all things that Istio is giving you out-of-the-box, you saw me install it, I'm not, this is not prerecorded, this is exactly how it works. Now the final thing that I wanted to show, at least from the back end, is in telemetry. So for those of you folks that haven't used the distributed tracing yet, the way that it works is you actually annotate all of your RPCs and you have these collectors that aggregate the data and push it back up. Now because Envoy is in path of all that, you get distributed tracing. So pick your distributed tracing of choice here. We bundle up Zipkin, but as of last week or the last release, they have Yeager as well, so BYO tracing. I bundled up Zipkin, so I'm going to show you what Zipkin can do. And like this again, I should be able to, can't find that, all right. I'll do a little bit of open heart surgery here. Pardon me, I've got a bad label selector, right. So if I hit this, I should hit the Zipkin UI. So I can say find all traces that went to product page. This always reminds me of the dev console, excuse me, the developer console in Chrome. So you can see your whole waterfall as the RPCs traverse the system, how many milliseconds, microseconds, each call, which path it hit under each API, and how long it took to service that request. Pardon me, I move this over, right. And if anybody has actually dug in and started looking, there's a wealth of information here. And at 3 a.m. on that fateful Sunday morning, I wish I had this information. You could see if you had a cache miss, one service was misbehaving, but you now have your whole dependency graph that was generated off that one call to product page. We can see where this data's going, who's serving it, and how it's being served. Yes, okay, yeah, let me just repeat the question. If people are using other tracing mechanisms, is that gonna be possible to plug it in? The answer is absolutely yes, because this is exposed via mixer, and mixer has pluggable back ends. So zip can, yeah, yeah, I just plugged into that system. You just have to take the metadata and represent it in whatever tracing model you need to represent it, and it should work. So the answer is absolutely yes. So that app only uses HTTP, does anybody got a glass of water? Nobody's got a glass of water? Thank you, save the day. Pardon me, my voice, it's been a long week. That app actually uses HTTP, not GRPC under the hood. So all the calls between on voice get wrapped in GRPC, but the transport underneath for the application is HTTP. Today, Istio supports RPCs in GRPC, or HTTP only, not any other custom protocol, but they're working on making that pluggable. So if you have your own RPC on your own protocol stack, so, but that app is all HTTP between the components. Yes, yes, let me just repeat the question. So everybody can hear it. So if we have multiple environments, some on Istio, others not, is there any way we can span that? Is that correct, which of us? You actually answered it. You can throw Envoy in anywhere, and as long as it can connect back to Pilot, it has the information of the mesh. And as long as you can have point-to-point connectivity to all the other Envoy's, the mesh will work. So you can attach it to the same control plane from your previous infrastructure and not have it on Kubernetes. Just a second, somebody, can I take you first, the gentleman up the back, and then there was another question here, yes? Yes. So are you asking, I think the question, as I heard it, is if you have multiple containers inside the same pod, will they all be subject to the authority of that? Yeah, so Envoy under the hood actually hijacks the routing table inside the network namespace inside the container and makes it the default router. So all the traffic going in and out, outside that, and all the traffic in between, it grabs as well. Yeah, yeah. Finally, just to wrap up, and I can answer some questions after this, there is an Istio community, there are community meetings. If you're interested in learning more, I've just given you just a sane baseline here. Please go, the documents are great. I also have a bunch of links on things I use. You can hit me on Twitter, and I also did a full demonstration on my YouTube channel of all the components up and running. I only showed a subset given the time, but if you wanna go and take a look at all the components, you can take a look at your own pace. But I wanna thank you and thanks for joining. I can take questions.