Scalable Microservices with gRPC, Kubernetes, and Docker by Sandeep Dinesh, Google

my name is Sandeep I'm a developer advocate at Google Cloud I like buzzwords so I threw them all on a single slide I like alliteration too so I try to pick ones with all M microservices machines more and more with containers and G RPC so before I get started how many of you know what docker is see if I ask that question like two years ago everyone be like huh are you talking about so I like that a lot I don't have to go through what Dockers anymore how about kubernetes very cool cool and G RPC okay very cool that's exactly what I expected hands keep going up more every single time ask that question which is really cool so if you follow me on Twitter if you want to add some finish but what I want to talk about is our Lord and Savior micro-services who has heard that micro services are going to save us from from everything from all our development hell right it's going to save us and you know everyone thinks that because everyone's searching for it on Google if you've ever been to another micro services talk which talks about the philosophy of micro services and what it does to your organization you know you know that you're really what you're doing is you're taking a lot of complexity in your code and you're moving into your organizational structure now sometimes it's easier to scale one than the other it's a decision you have to make my you know micro services what is it you write a program that does one thing and it does it really well and then you composing together right so instead of having a very big monolith that does everything which makes it hard to tweak and deploy instead you have multiple smaller applications that communicate and are deployed independently yadda yadda yadda it's the typical you know UNIX philosophy so why micro services again there's a ton of reasons continuous deployment robustness polygit development maintainability scalability blah blah blah but what I really want to talk about more is how micro services and specifically how one way we at Google that we kind of prescribe to the people the peoples that are you and me so how many of you have heard of borg wow that's surprising how about stubby that is not surprising so Borg is Google's internal containers right so around 10 years ago we decided to use containers inside Google and no one was using containers outside Google so we had to write our own stuff so Borg is how we actually schedule pretty much every single application at Google from your little side project that you want to run in a cluster to like Google search and save all these containers running around in production they had to talk to each other right they have to have some sort of RPC framework to actually communicate with other services right you're the gmail user service has to talk to the auth service which talks to the data service I'm just making things up those are not real services what it uses is a system called stubby the stubby's our RPC framework now what we could have done is taken Borg and stubby and put on github and been like ah we've open-sourced we are good community members and then people have been look at it and be like this is the worst code I've ever seen because it's literally tied so deeply into our infrastructure that no one could understand it I don't think anyone at Google can understand the whole thing so instead what the idea was let's let's do a from scratch reimplementation of these things starting in the open-source community right so kubernetes 100% rewrite of borg is like third-generation canaan your scheduler written and go and G RPC is very close to stubby but it's using HTTP 2 and protocol buffer 3 but that's all just buzzwords let's take a look at what these two actually give you when you're running microservices so kubernetes so a lot of people here know what kubernetes is for those of you don't know what kubernetes is right so you have a docker container has your code is running it's great on your local machine now you want deploy it to your production cluster or whatever and now it becomes more complicated right you've just you're doing the same thing as before your SSH into a machine docker run and then keeping it up with some like no help or something like that terrible terrible things you haven't really done anything except made your development a little bit easier with kubernetes it manages an orchestrates those containers on your cluster for you right so you're no longer dealing with machines instead you're dealing with the cluster and the kubernetes api which is way way easier to manage so it looks something like this you have an app you put on a docker container it's great right docker eyes now it can run anywhere alright so but let's actually run it in kubernetes is an idea of a replication controller in this case that deployment and the replication controller is actually a really cool concept basically you tell kubernetes I want this container and I want four copies of it that's all you tell it and it just says ok and it starts running it on your machines for you you don't have to tell it which machine to run on you tell it if it crashes please bring your backup it's all automatic so it can be like alright I want four okay you have four one crashes it'll spin it back up on another another host a host crashes it'll redistribute all those containers to another host and you don't have to worry about any of that stuff you just tell it what you want and it'll do it but of course if you have these random pods and containers spinning up on random computers in your cluster you have to have some sort of layer on top that can route traffic to the correct docker container right and that's where our service comes into play so a service is a static IP address and a DNS hostname that'll route to a dynamic number of these containers running on your system so one or a thousand it doesn't matter you just hit that one service in the load balance traffic to the containers in your cluster basically take all of that and it becomes a micro service right so you have your code running in the containers and your service endpoint that's a static IP address and everything it gets bundled up and that's your micro service so this is an independently deployable piece that's pretty much it that's kubernetes 101 in like one minute and the thing is because it's just one cluster you can actually run multiple micro services on the same cluster right that's the whole point increased resource utilization so you can say I want to run these four micro services I don't care where the actual code is running I just tell it like I need this much memory I need this much CPU I don't want to be running with this container or whatever and kubernetes will take care of scheduling it for you right so yeah for you can scale one up independently if the others scale one down independently of the others roll one up without any downtime and then basically you create the Microsoft Office logo which is the goal software engineering all right so in the few minutes I have remaining let's actually build some stuff this is my machine learning application called hello world everything we do at Google is machine learning and basically what I want to do is deploy it right so my first step is docker build as you all know is how you build a docker container I'm going to give it a tag called GCR that IO project front-end 1.0 and so GCRs our container registry it's a secure place where you can store docker containers quite out IO docker hub through similar things and then g-cloud docker push will securely push that container up to the cloud so the first thing is the front end service so what this is going to do is it's actually going to create that static IP address and it's going to forward traffic from port 80 to port 3000 which is our app is listening and it's going to select every single container with the name front-end and then this type load balancer is going to going to spin up a Google cloud load balancer so we're going on AWS you'll spin up a ELB on Google Cloud with cinnapup Network load balancer things like that so let's actually deploy this so I can go cube CTL deploy apply print and service animal so I'm going to do is read in that file and then hit the Q Bernays API so I already have a cluster created in the background ahead in the oven ready to go so now I have the service created so if we can go cube CTL get service and you can see that I have a front-end service up when running the cluster IPs at internal IP address and the external IP is still pending so spinning up that load balancer okay so now we have that static IP now we have to actually run our code so here is how you do that again it's simple llamo file we have two replicas that we want to run you can change that later the name is front-end so that is the tag for our container and give it any arbitrary key value pair the image is that same image I pushed up with that g-cloud docker push and I'm opening up for 3,000 ok so let's do that [Music] sweet so now that go cube CTL get pods so pod is a collection of container to only have one in this case so you have two of them running in our cluster sweet now if I go back to the service still pending we will give that a second up of course the moment I do complicated stuff at hands up so if I go to this external IP we can check it out so I have the front inverse ROM code anyway it's it's up and running at at this IP address the code is not what I showed you that's what happens when I don't test this out so we had the controller and the service running so the next step is really this communication part right so we need have multiple micro services running in your cluster communication actually becomes the most important part right you can schedule as many containers as you want if they can't actually communicate with each other it's kind of pointless to have micro services right you have to have each one communicates very quickly because your end user is just hitting this one endpoint and it has to go through Zion stack of network calls to get anything back out right looks something like this if it's simple Microsoft's a talking see talking to be talking to a talking to D whatever you don't know and then only one of them has a public endpoint right so they all have to talk to each other and get that data out good quote biggest issue in changing a model into a micro service lysing changing the communication pattern this goes way deeper than code I mean it's changed in communication pattern with your teams and all that stuff too but just trying to like take your monolith and just breaking it randomly arbitrarily at any point is not going to work you have to know what points you have to break it up in which parts can go over the network right you're going to add a lot of latency no matter what you use but what you use is actually really important so at Google we have like something like ten to tenth which is a really really big number our pcs per second we really like our pcs so we invented this thing called G RPC which stands for G RPC remote procedural calls yes not Google I don't know where you got that idea from um basically it's a collection of different things that all make building our pcs way better right so the first part is protocol buffers how many of you have heard of protocol buffers before so tree OPC is using protocol buffers v3 which is way better than the previous versions because those were not as good it's a Texas IDL which is basically a way of defining your data data model right your API spec and it's also a wire format so when you write your data into a protobuf it's all binary and compressed which is nice which is important when you're making a lot of calls the next thing which is my favorite part is it uses HTTP 2 how many know what hpq is versus HP 1 okay so the TLDR is speed right HTTP 2 is way faster than HP 1 actually have another talk where I go really deep into like JSON RPC versus G RPC and I was really surprised at just how much better G RPC was in most of the use cases so yeah HTTP 2 makes it really really fast I think like multiplexing so it opens a single TCP connection and then sends all the packets over that HTTP 1 which is most people are using further calls opens a new TCP connection every single time which is a lot of overhead bi-directional streaming is my favorite part because you don't have to do polling our sockets or server sent events you can just do bi-directional asynchronous streaming on the same TCP socket super easily like surprisingly easy reach your RPC and flow control right if you have congestion in your network things slow down you need to be able to slow this upstream services down as well and of course multiple language is very very important here's a few of them writes a Python node Java PHP go blah blah blah when you're running a micro services you don't want to be restricted on what kind of language you can use so the more languages your platform can support the better obviously if you have something like Lua that we don't support you have to fall back to rest but for the 11 or so languages that we support ERP works great and for node.js is literally npm install g RPC which is really nice and mobile first so this is simon says how many people know what this game okay good I like this game it's fun at a co-worker named Mark who also like this game and so what we did is you made it Internet connected because that's what we do how many people have played with Johnny Five it's like a nodejs library for IOT stuff okay I'll Johnny five is amazing fear to start with IOT really recommend Johnny five it makes it super easy if you know just a developer so what I did is I wrote some Arduino code using Johnny five and I connected that physical box to the Internet it's great mark my coworker wrote a go server and a Java client on the Android phone right if you have three different languages that we're using to build this demo and so here's our proto file it's pretty straightforward it's a request it sends a bunch of stuff since a bunch of colors things like that I'm running out of time so I'm up and I'll go through this too deeply basically it looks like this right so no js' guy plugs it in starts it up it says request to join I'm one two three four five the phone says hey I'm one six seven eight nine zero very random IDs the server says okay I have two people joining a game both of you guys up again it's your turn to start node and it's your turn to stop Java right so the node person says yellow you press the yellow button and then the server says light up yellow on both and then your turn is over it's now the phone's turn whoever's playing on the phones really bad at this game they put red so it's going to say light up red and you lose and you win right so the really simple game but it takes a lot of it has to be real time right when I press yellow on my thing it has to light up yellow on his device very quickly add so Jo PC seemed like a really good fit for this so what I'm going to do is a quick demo of this right here I don't have the physical device because I literally forgot it at home I'm not going to make any excuses so what I'm going to do is actually run a node.js server on this machine just going to proxy it to the web interface so here let me turn up my brightness I'm going to connect to the server on my phone and it's going to say your turn and I'm going to refresh this page right here all right so I'm going to click blue so it's the other players turn and I'm going to click blue yellow and so you can see it coming up here so I can just cheat and read the screen but you know blue I'm really good at this game and then let's click red other players turn ok blue yellow red and green right so it's almost instantaneous and this is over conference Wi-Fi which is always fun I'm just going to lose real fast red oh you lost and you want ha ha I'm so good I always win and lose um but that's pretty much gr PC in a nutshell and the cool thing is that server let go server it's actually running in kubernetes with the Redis database running in kubernetes and it's all just being scaled automatically I have three minutes left so I'm going to see what we can do so let's the upgrader app to use g RPC this is not going to work because I have the wrong front-end deployed that's okay so this is our RPC that I'm going to upgrade our app to and it's packages geo is one RPC call it takes a point and it returns a distance points are just a two point origin destination or two floats right at distance it's just a float so you have all these different data types that you can define and this gets compiled down to a very very efficient binary format by protobuf so you have this is this is a synchronous RPC call right so it takes a request and returns a response you can do single side streaming so the server can stream to the client the client can streams the server or both can stream to each other like we were doing in the Simon Says demo so what we do in our back-end code is we require the G RPC NPM module we load that part of a file which defines our API service and then we just build that geo service that we saw in the previous slide so our server geo service what we're going to do here is just define the the different RPC calls so distance between is a function call callback and it's going to call the get distance function which is it's going to use the hammer sign formula to find the distance on the well between two latitudes and longitudes and yeah like I said have a sign formula interesting stuff and then we just listen on port finder 51 which is the default directory port you can listen on whatever port you want and then serve it up listen that's basically it now we have our G RPC server up and running few lines of code again we build that push it and now we had update our server a front-end code right that's going to call our back-end service so again it requires your BC loading that protobuf and here's a cool part because we're using kubernetes I don't even have to hard code an IP address or anything like that I can just say new geo service back in : 551 and back-end will use the kubernetes dns to automatically resolve the correct back-end without having to do any sort of like environment config or anything like that it's just all using DNS which is nice we sent in a request like this and we just json stringify the output getting from our back-end service that's basically it build it push it here we go back in deployment looks exactly the same as a front-end deployment the only difference is we're opening up port fighter 51 and we're using the backend container and I want four replicas because why not I can launch it like that back in service you might notice here I don't use type load balancers so it is an internal service and it's going to port port forward finder 51 to fire 551 right know sort of remapping needed launch that service and I'm just going to show you this real fast because I'm literally out of time I wanted to say cube CTO okay so again we have our two front-end pods running the cool thing is like into a cube CTL edit deployment front-end and it'll actually pull up the running deployment Youell now I don't really recommend this because it's weird I like checking my animals in the source control and doing it that way but I can if I wanted to just go here and update this to 2.0 I have no idea what this will do just the best let's see I don't even know if I have this container pushed it's edited all right get pods so you can see it turned off those old containers and then spun up the two new ones right and they're already up and running which is really cool so twelve seconds ago that they start it up and so that's like a zero downtime deployment and if I want to go back I can actually go cube CTL history the phloem and rent and I really hope is this correct deployment history can't spell spelling is hard it's what computers alright I am out of time i panicking now kit get his three friends and no this is all wrong I forget but if I remembered what you can do is actually get the history of that deployment so it'll show you that first version we launched the second version we launched and you can actually roll back to any previous version right so deploying forward is important but I think rolling back is equally important because everyone makes mistakes except me right so yeah it's very very easy to roll back again it's pretty much instantaneous because it caches all the containers on the hosts which is nice that's all I really have time for I don't want to take the next speakers time so they just if you want more information links Google container engine it's a hosted kubernetes it's great one-click come to our booth we're doing code labs you want to try this out yourself we are more than happy to help you and you can win cool prizes and links I'll leave that up there thank you all so much

Channel: node.js

Views: 36,720

Keywords:

Id: xsIwYL-N4vI

Length: 21min 24sec (1284 seconds)

Published: Thu Dec 15 2016