Introduction to HashiCorp Consul

hi my name is Arman and today I wanted to talk about an introduction to console so when we look at kind of traditional architectures for delivering an application well we have is kind of the classic monolith right let me talk about the monolith it's a single application that we're deploying but typically has multiple discrete sub components so as an example suppose we're delivering the desktop banking application it might have multiple sub pieces where subsystem a is let's say they log into the system subsystem B might be showing the balance of our account C might be wire transfer D might be foreign currency now even though these are independent functions right logging in versus showing our balance we're delivering it and packaging our application as a single monolithic app so we're deploying it as a single unit now what we've seen over the last few years is a trend away from this right the challenge with this is suppose there's a bug with our login system we can't just patch that bug in this system and just change a we have to coordinate with all of these groups and redeploy the application as a single unit so to fix this what we'd like to do is instead deploy them as discreet services right so this is what might be called a micro services or service-oriented architecture basically we're taking the same monolithic application and taking all these sub components and now delivering them as a discrete application so now if there's a bug in a let's say our login system we can just patch and redeploy a without having to coordinate across these different systems so what this really buys us is a set of development agility right we don't need to now coordinate our development efforts across many different groups we can develop independently and then deploy at whatever cadence we want so a might want to deploy on a weekly basis while D might want to deploy on a quarterly basis so this has great advantages for our development teams the challenges there's no such thing as a free lunch so what we've gained in development efficiency in many cases introduces many operational challenges for us so let's go through some of those the first one the most immediate is discovery right and what I mean by that is let's say service a wants to call service B the way you would traditionally do this as service B would expose a method market as public and then service a can just call it right there in the same application it's just a function call so when a is calling a function and B this takes nanoseconds we're doing an in memory jump and it's all in process so we don't worry about you know what happened to our data how did the day to get there did we encrypt it right it's an in memory function call all of that changes as we come into this distributed world so now we have system a that wants to talk into system B well where is system B it's no longer running on the same machine it's no longer part of the same application and because we're going over a network it's no longer nanoseconds we can measure the latency impact in milliseconds between these nodes so this first level problem is what we call discovery right how do these different pieces discover one another so there's a few approaches to this historically what we would have done is probably front every one of these services with a load balancer so we put a load balancer in front of every service tier and then we hard-code the IP address of the load balancer so a hard codes the IP of the load balancer and then the load bouncer deals with the fact that there might be multiple instances of B so this allows a to skip discovery by hard coding this address but it introduces a few different problems for us right the first problem is we now have a proliferation of load balancers here it was sort of a different world there was a limited number of applications that were packaging many different units of functionality as part of one app so there was probably still a load balancer over here but we had one load balancer now managing many different services where here there's an explosion in the number of load balancers we have so these are representing sort of additional cost that we didn't have the second level challenges we've introduced a single point of failure all over our infrastructure right and so even though we're running multiple instances of B for availability a is hard-coding our load balancer so if we lose the load balancer it doesn't matter that there's multiple instances of B effectively that whole service has just gone offline the other challenges were adding real latency instead of a talking directly to be a is talking to a load balancer we're just talking to B and the same path on the way back so actually doubling the network latency involved with every hub the final challenge is these things tend to be manually managed the load balancers so when I bring up a new instance of B I file a ticket against the team that's managing the load balancer and wait days or weeks for that thing to get updated before traffic reaches my node so all of these are a problem so the way we think about it in console is how do we solve this by providing a central service registry so instead of using load balancers when these instances boot they get registered as part of the central registry so it gets populated in here so we do a register and now when a wants to discover and communicate with B it queries the registry and says what are all the upstream instances of this service and now instead of going through a load balancer service a can directly communicate with an instance of B now if one of the instances of B dies or has you know a health issue the registry will pick that up and avoid returning that addressed a so we get that same ability of load balancers to drought around failures without actually needing a load balancer similarly if we have multiple instances of B we can randomly send traffic to different instances and load level across all of them so we get those same advantages of failure detection and load leveling across multiple instances without having to deploy these central load balancers the other side of it is now we don't need these manually managed load balancers everywhere so instead of having a proliferation of load balancers and waiting days or weeks the moment an instance boots up it gets programmatically put into the registry and it's available for discovery and traffic routing so this helps simplify doing a service-oriented architecture at scale the second big challenge we run into is configuration so when we looked at the model with what we probably had was the giant XML file that configured the whole thing the advantage of this was that all of our different subsystems all of our components had a consistent view of the configuration as an example suppose wanted to put our application in maintenance mode we want to prevent it from writing to the database so that we could do some upgrades in the background we would change this configuration file and then all of these subsystems would believe that we're in maintenance mode simultaneously now we're in this world we sort of distributed our configuration problem right every one of these applications has a slightly different view of what our configuration is right and so now we have a challenge here which is how do we think about configuration in our distributed environment and so the way consul thinks about this problem is instead of trying to define the configuration in many individual pieces distributed throughout our infrastructure how do we capture it in a central key value store so we define a key centrally that says are we in maintenance mode and then we use it to push it out to the edge and configure these things dynamically so now we can change a key centrally from are we in maintenance mode false to true and push that out in real time to all of our services giving them a consistent view so moving away from having kind of the sharded distributed configuration everywhere to defining it and managing it centrally now the third challenges when we looked at this classic monolithic architecture we would divide our network traditionally into three different zones so we'd have zone one which was sort of our you know wild Demilitarized Zone so traffic coming in from the public Internet then we have our application zone here which was largely receiving traffic from the DMZ through a set of load balancers and then we probably had sort of a data zone behind the - behind us or sort of a private zone and only the load balancer could reach into the application zone and only the application zone could reach into the data zone so we had a pretty simple three-tier zoning system that allowed us to segment our network traffic now as we look at this world this pattern has changed dramatically right now there's no longer kind of a single monolithic application within our zone but many hundreds or thousands of unique services within this application zone and the challenges their traffic pattern is much more complicated now right it's many of these services have a complan an east-west traffic flow it's no longer sequentially from load balancer to application to database right traffic might come into either let's say our desktop banking app or mobile banking app or our API so there might be multiple front doors depending on the access pattern and then these services communicate with each other in a complex east-west traffic flow so this third level challenge now becomes how do we think about segmenting of this network how do we partition which services are allowed to talk to which other services so this third challenge becomes segmentation and the way console deals with this is with the feature we call connect and so again centrally managing the definition around who can talk to who and what this starts with is a few different components first we start with what we call a service graph with the service graph we define at a service level who can communicate so we might say a is able to talk to B you might say C is allowed to talk to D and what you'll notice is we're not talking about IP to IP we're not saying IP one can talk to IP two we're talking about service a can talk to service B the nice thing about expressing at this layer is that the rule is scale independent right and what I mean by that is if I have a rule that says my web server should be allowed to talk to my database that might be expressed simply right I can say web talks to database but if I want to translate that to the equivalent firewall rules well if I have 50 web servers and I have five databases that translates to 250 different firewall rules right and so this is what I mean is that while this rule is scale independent it doesn't matter if I've 110 50 or a thousand web servers it's the same rule firewall rules are the opposite right they're very much scale dependent and tied to the management unit which is an IP so let's elevate that management up to this logical level where we don't really have to be tied to the actual scale the next part of this is how do we assert identity right and this comes from a certificate authority so when we say service a can talk to service B how do we know what is service a and what is service be the approach console Connect takes is to tie this back into a very protocol TLS so we issued TLS certificates that basically uniquely identify these services so we can uniquely say this is service a and this is service B right unlike saying there's an IP and we don't actually know what's running at IEP with any strong guarantee now how do we actually enforce this this translates then into a set of proxies so the way we end up implementing the access control is through mutual proxying so on a box we might have service eight and on that same box we're running a proxy alongside of it this is sort of a sidecar proxy and then similarly for service B it's running on its own machine or its own container and it also has a sidecar proxy and now when a wants to communicate to B it's transparently talking to us proxy which is establishing communication on the other side to another proxy that side terminates the connection and hands it off to B and so this actually has a few different advantages first we're not modifying the code of a and B they're both blissfully unaware that anything has changed they're just communicating the way they normally do the proxies on the other hand are using these certificate authorities so the proxy on side a will use this certificate to say I am a and it'll verify the identity of B and vice-versa the proxy on B side will verify that it's talking to a so now we get the strong sense of identity between the two sides and this is being done with mutual TLS the second advantage of using mutual TLS is now we establish an encrypted channel between them this is becoming increasingly important as we talk about regulations like gdpr so increasingly our focus is on saying you know what we don't actually trust our own network within our data center we can't just assume that by virtue of being on the network things are trusted and so as part of this shift we're increasingly seeing a mandate to encrypt our data at rest so things that we're writing to our databases are writing to our object stores but also data in transit so as data is going in between our web application and our database is it being encrypted right or is it as it's flowing in between different services in our data center are we encrypting that traffic the challenges we probably have many hundreds or thousands of Asians that exist and are not TLS aware and so the advantage of imposing at the proxy layer is now we can get that guarantee of our data being encrypted in transit without needing to re-implement all of these applications now the third piece of this is just because a can prove it's talking to be and become prove it's talking to a that's not enough because it's not clear that should I even be allowed to talk to B and this is where the service graph comes in so then the proxy is call back into the service graph and look for an arc like this is there a rule that allows service a to talk to service B if so then the proxies allow that traffic to take place and a is allowed to talk directly to B and there none the wiser that those intermediate proxy is taking place so as we come back now and talk about kind of this transition right what we really are trying to do is gain a set of developer efficiency by splitting our monolith and developing these services independently right we want them to be able to develop and deploy and be managed independently but we've inherited a set of operational challenges right and this goes back to our no free lunch so as we came into this world we now need to figure out how do we do service discovery how do we configure in this sort of distributed setting and how do we segment access so it's actually safe to operate this distributed infrastructure these set of challenges collectively are what we really refer to as a service mesh right so when we talk about council what it's trying to do is provide this service mesh capability which underneath is three distinct pillars in service of allowing this micro service or service-oriented architecture to work I hope that's been a helpful introduction to council there's a lot more detail on our website please check out our other resources thank you so much

Channel: HashiCorp

Views: 148,720

Keywords: HashiCorp, Consul, HashiCorp Consul, Service Mesh, Armon Dadgar

Id: mxeMdl0KvBI

Length: 15min 15sec (915 seconds)

Published: Tue Jun 26 2018