Intro to Service Meshes: Data Planes, Control Planes, and More

Video Statistics and Information

Video
Captions Word Cloud
Reddit Comments
Captions
>> I'm Aaron. >> I'm Armon. >> This is The Open Source Show. [MUSIC]. >> I'm Aaron. I'm a Cloud Advocate at Microsoft. >> I'm Armon, I'm one of the founders and CTO of HashiCorp. >> All right Armon. We're here talking about service meshes today. I'm going to confess though, I don't know what a service mesh even is. So, can you school me a little bit on this. >> It would be my pleasure. It's definitely a new concept. I think the way we like to think about a service mesh really is how do we go back to what the problem is that we're trying to solve. In this modern cloud era we have containers, we have our serverless functions, and we have our VMs and we're running this whole collection of infrastructure, but how do all these things talk to one another? I think that the core of the problem is running all of these different pieces of distributed applications, distributed infrastructure but they need a way to communicate. So, a key challenge becomes how do I route and discover to all of these different applications? How did all of these components find each other? Let say I have a web server and it needs to talk to the database to be able to query data. How does the web server even know where the database is running? It's running somewhere in the cloud and maybe my database fails and it moves somewhere else in the cloud? And that's a really simple example, that's just web server to database but you can imagine if I have caching layers and API services and all sorts of backend pieces. There's many, many components that all suffer from the same problem. So, this can scale from like, I just got a little web app that's got a front-end and a database but once I grow and I've got a 1000 person team with all these microservices, to use another buzzword of our time, what does it do for me when I go up to that level as well? This really comes back to the question almost of "when should I use this technology?" So, I think if we start by saying what a service mesh really does is: gives us a consistent way to route between all of our services, discover between them. Then it's like when do I use this? Does it make sense for me to use this if I have two services like a web server and database? I would say not really, it's overkill. Then in the scenario you're talking about where it's like I have 1000 developers, many services, many microservices, that's a sweet spot which is now I have a ton of complexity and I don't want to solve that same problem of how does this thing talk to that thing a 1000 different times? I'd rather solve it once with a central service mesh and then apply it to all 1000 applications. I've heard of this thing. These two things actually in services meshes like data plane, control plane, is like all these planes, it feels like I have to go catch a plane or something. Can you walk me through what these two things are all about? Yeah, I think when we talk about service mesh there's a bunch of these other topics under it and I think control planes are one of them and I think first let me talk about observability because I think that's also an important piece of it. Okay. When we talk about service mesh, again the first level of concern is, how do we route? How do we discover? How do we connect these pieces? But on the second level one is, okay well once you've connected all these pieces, how do we know how much traffic is going from our web server to our database? Is there no requests happening? Is there are too many requests or they're getting errors between them? It's too slow? What's going on? So, I think that opens up this whole question around how do I observe what's happening in the service mesh? So, when we talk about observability then the question is, well how does that actually happen? How do we actually enable getting that data in terms of who's talking to who and things like that? That's where the control planes come in. So, observability is the goal then the questions is well, how do we get any of that data? So, I think that brings us to how does this system actually work? How does the service mesh function? There's these two critical layers of it. Layer one is the control plane which is a central kind of management portal is the way to think about it. So, if I'm the operator or I'm the system administrator and I want to set up a rule that says my web server is allowed to talk to my database or I want to see how much traffic is flowing between those things. I go to the control plane as the central management unit but in some sense if it's the brains, it's lacking the body. >> I see. >> That's where the data plane comes in. All right. So, the data plane is then the flip side of that, it's the body. It's the one that's actually querying data between these things, enforcing who can talk to who, collecting that data of how much traffic are we seeing, all that's done at that lower level. I see, I see the separation but if I'm running the cluster, I'm probably be talking to the control plane mostly? Right. Is that done with a Web UI, scripts, or an API or how does that, or both? I mean how does that work? It's all of the above. So, in some sense, the data plane lives everywhere. So, you run either an agent or a proxy on every container, every VM, every serverless function. So, it's ever-present but it's really talking to the control plane on your behalf so that the only thing you talk to is the control plane. Then you might use the UI, a CLI, and API. You might interface with the control plane in many different ways but then it's the brain that's controlling the rest of the data plane for you. So, then if I'm the app developer, it sounds like I'm not really going to touch the control plane at all, right? To a large degree yeah, it should be invisible to you. As an app developer, you're writing your web server and it needs to talk to the database. You don't necessarily care how it's talking to the database. Right? Okay. So, there's probably some small tweaks you need to do in sense of instead of hard-coding let's say the database IP. You need to talk through the data plane. So, you need to talk to the local proxy or the local agent to make sure data goes over the data plane, but beyond that it's invisible to you as an application developer. I love it when other software that I didn't have to write does all the work for me, that sounds amazing. Then you get all those observability benefits that we talked about plus you get all the code of routing, discovery, and security benefits for free, you don't think about it as a developer it just happens. How do I get started? If I'm running on Kubernetes let's focus on that. How do I get all this goodness into my app, into my cluster what have you? So, we actually have a really good blog on the Azure blog about how do you actually get started with Consul, which is our service mesh tool on Azure, Azure Kubernetes specifically. Then the second piece is that data plane we talked about. That has to be ever present. So, to make that really easy with Kubernetes, there is an admission controller that will automatically inject it into every pod. You don't have to really think about the data plane because it's getting injected behind the scenes for you automatically. Behind the scenes? Yeah, you just submit your pod, it gets added to the pod and it's just another container that's not doing that local routing. Wait, okay. All right. Let's backup. So, if I Helm install my app, I don't change a thing in my Helm, install in any of my templates. This still works? Yep, it's just auto injects the control plane for you behind the scenes. Whoa! That's nice. There's some annotations you can put on to say I want the pod or I don't want it. So, you can opt-in or opt-out if you don't want to make use of that. But in general, the goal is for it to be really, really easy as a developer to consume this. So, you mentioned there's some links in the blog posts? Yes. So, there's some links already on the Azure blog about how do I get Consul up and running on AKS but then beyond that, there's going to be an upcoming Azure Friday video that people can check out. There's a bunch of resources on the HashiCorp site, so you can then go to HashiCorp's console homepage consul.io or learn.hashicorp.com and we have a whole set of walkthroughs and tutorials of how to actually get started with this. Cool. So, check out the show notes below. We've got links to all the HashiCorp stuff and go check out opensource.microsoft.com as well. Thanks a lot everybody. Thanks. [MUSIC]
Info
Channel: Microsoft Developer
Views: 8,598
Rating: 4.8993711 out of 5
Keywords: channel9
Id: CM2Y6B1yuDg
Channel Id: undefined
Length: 7min 27sec (447 seconds)
Published: Tue Jan 15 2019
Related Videos
Note
Please note that this website is currently a work in progress! Lots of interesting data and statistics to come.