A Tour of Different API Management Architectures

[Music] though okay so this is my chatter for my Twitter feed a couple of weeks ago from a w3c consortium and it shows that yeah unsurprising to be you guys here I'm sure they had the explosive growth of the web since 28 years ago already so I was looking at this and reflected back on drop the mic as I reflected back on my my presence on this timeline I remembered that I deployed a web server back in 2003 I'm sure there were more than 50 by the way and my first web application that she did dynamic stuff was in April 94 so I've been doing this a while my name is liam cruelly I'm a product manager at nginx and as I looked at the this timeline with nginx in mind I it kind of starts around here 2001 so not quite as far back as curl goes but pretty far back and 2001 the yeah web was going through explosive growth continued explosive growth and the the that original first gen infrastructure was struggling to keep up and the idea for nginx which is a web server reverse proxy that can handle huge amounts of load and concurrent connections was the idea of this guy he got SOF he was running as a sre you might call him these days but not back in 2001 and he was looking after a site which was going through growth and it could not handle the load and his approach was to take a new approach to solving at the time was known as the C 10k problem how to handle 10,000 concurrent connections on a single server single Hardware box so you went out did that wrote some software open sourced it 2004 and went on and on to become a very popular web server and reverse proxy today in fact the earlier this year it accelerated and outgrew Apache as being the number one web server on the internet as a whole and just out of interest how many people know about nginx how many people use it in their organization I think that represents some that are pretty well well you may be surprised to learn is that when we survey our open source community and indeed our commercial customers we find that 40% of them are actually running nginx is now a gateway was never designed for this purpose explicitly but hates HTTP traffic and it works pretty well on nginx so if you have a use case you can you change an exploit more often than not and you'll find that lots of the API management vendors will use nginx as their gateway of choice anyway under the cover song so I'll talk about API gateways in particular but just the level set as we kick off I want to just differentiate and let us say Don API management versus API gateway sometimes these two things that mean the same thing or are using two changeably so API management is about setting policy it's about defining you know what needs to happen what should be enforced from a security point of view be able to get visualize that stuff get analytics on it and of course provide documentation developer portal so people can find your API is consumed your API s-- the Gateway its job is to actually run the traffic right so take those policies and it enforces them so it does the things like repair negation and rate-limiting and routing requests to backends and yeah the unsung hero of all this is exception handling super import on use case that doesn't show up in a lot of data sheets so before we look at how we deploy API gateways some load level set on some essential functions for what you want an API gateway to do and at this point usually somebody argues with me that there's another five essential functions but 80 on the slide so we have a keyless emanation you want to handle HTTP end to end or terminate it up to you client authentication making sure the requests coming in to our application environment our API environment are from genuine clients and then fine-grained access control in those requests authorization can an API request actually consume this API or indeed can this API client actually consume this endpoint rate-limiting authentication load-balancing is another because you probably gonna have more than one thing deployed so that comes part and parcel and so discovery goes hand-in-hand with this like what are the available backends for a particular API service and if you really need to if you have legacy needs or if you just need to provide a stable interface between the clients and the endpoint you might just do some transformation either of headers or god forbid or so bodies so let's look at some deployment patterns for API gateways I will start with a simple one of your edge classic edge gateway so if you've ever deployed a load balancer or even maybe a reverse proxy this looks kind of familiar so we've got an API client it makes a call the API gateway sits in the middle sends requests to the right place and if we were to scale these api's out then of course we get some seamless load balancing as well we'll send the request to the least loaded server everything works terrific so let's imagine these polished beveled api's are out of monoliths and we want to introduce some micro services to this we might be taking some functionality away and building a micro service for that thing or we might be building new services that's great we can do that now everything is being handled by all those functions I say essential functions are being handled by our edge gateway as you expect let's bring the micro C's in and now we can send requests to the micro service is amazing at this point we need to add one more important capability to our API gateway and that is facade routing so our existing let's call it API a now has a new capability and you endpoint that's actually implemented as a mark service I need to make sure the Gateway exposes a nice simple holistic API to the client at the backend it gets distributed the side ruching does that again not too big an ask but what happens when we want Apia to make a call to a PID now at this point there's the rate-limiting place no authentication and if you want to do load balancing and write that logic into and I'm only the KPI then you probably you're in for some trouble so it starts to become difficult at that point so to introduce the two-tier gateway we separate our concerns we put a security layer out from its handling the TLS side the client authentication its screening clients before they come into application environment and it can also do centralized logging and maybe even inject some tracing ID headers at the beginning so that we are distributed applications can get good tracing information in the center we put our routing gateway so it's doing the fine-grained authorization can I access this endpoint it's also is gonna be the service discovery in the load balancing it's got a nice view of all of the services deployed how many they are where they are and it had those how many requests are in flight at any one time it can make a great load balancing decision in the center this is a good a good model it fits very well with cloud deployments or existing infrastructures whereby you'll find lots of the functions on the left hand side here in your cloud load balancer out of the available off-the-shelf or you may have an existing edge load balancer in your data center and you can do all these things at that point without introducing another hop in your overall application environment and that's a good thing because more hops are more latency the other good thing about it is that the left-hand side becomes very stable all it needs to know about is the API and they should use authentication for access to the API it does not need an IT Service Desk ticket every time this new endpoint introduced so if you've got devops teams making high frequency updates if you're owning an entire application and updating it and deploying it you don't need to go back to the IT team who run this edge or run the cloud load balancer for you to have changes made you can do that in the routing gateway add the routes for the new endpoints you're creating and it's a nice separation of concerns and different teams can learn different parts of the infrastructure and that's great to a point and the point that that starts to break down is when you've got multiple develops teams each owning their own applications and wanting to publish and update their own api's with their own policies and they end up trying to do the same thing on the same piece of infrastructure and that central routing gateway becomes an administrative bottleneck and actually you end up with the same kind of IT Service Desk hell as you were trying to avoid in the first place so for that and if you've got high frequency changes and you're doing DevOps style processes we can look at another model the nice thing about this of course is that when a equals d it does so going through the Gateway so it's got a full view it can do the syndication it could do the fine-grained access control and it can do this load balancing so DevOps style we could have got micro gateway pattern and in this model the DevOps team get to own their own little gateway now this means they can update the gateways when they like they can deploys frequently these alike they can have the authentication policy that suits that particular API so you might have an API they services out to public clients and for that you might have something like oh or Thor Jason look token validation going on at that gateway you might have an internal facing API and that might have maybe so legacy shared secret API key or maybe it's even better using client certificate authentication between services you get to have each team pick the round with indication model although if my experience DevOps teams that means you'll get one two three different types of authentication schemes in your application environment so be careful with that one so what's going on here is that we've got those kind of edge functions still sit outside we've got T left emulation happening at the edge routing to each individual API is quite simple and rate limiting can also happen as a security function at the micro gateway we're doing the load balancing between each of those instances of the application code we've got the authentication per API works pretty well and what works even better is we can now have services service calls for example equals F going through the Gateway for F and these individual application environments perhaps run by different DevOps teams maybe even different pieces of the infrastructure mean that there's maybe hopefully no network connectivity to allow e to contact F directly so we solve one of the earlier problems and this brings up the point of east-west traffic so the api's don't live alone the live is part of an API ecosystem if you like and the more you move towards more eco services based applications and api's the more things get distributed and the more likely it is that one service relies on another service such a function of their size so let's look again at the the micro gateway model so we've got a calling F going through the Gateway of F brilliant so some challenges start to appear in terms of where does the access control rules live and a healthy earth indication happen so application e now needs to either be hard-wired some Sociedad code your configured with authentication credentials to access service F or it needs to obtain them dynamically somehow either by through a sort of token issuance or a certificate ephemeral certificates so that's an additional workload to me to put on the application code but notice that when equals F as if it were an external client the micro gateway F needs to do everything else TLS rate permitting service discovery load balancing syndication maybe do some transformation as well so when you have a micro gateway it's it's micro in terms of its name but the functionality you need is as rich as you would need from a centralized or an edge api gateway so beware of micro gateways that are micro in terms of feature set so it becomes challenging is configuring how he can get to eff and health indication potentials get propagated and the possible solution to that is to look at a slight car gateway so in this model we have an API gateway co-located with every service so an e called F it now does that by going out through the gateway of E and in through the gateway of F and it is great it offloads a number of challenges related to the application so the application now long no longer has to have authentication credentials or implement service discovery that stuff can now be configured in the gateway the application code is stable or doesn't have to be changed and you can move towards this kind of pattern without having to touch the application code itself you simply need a DNS name or something for each of the services you want to access but this highly distributed pattern throws in some additional challenges so first of all that server discovery north indication credentials they now need to be configured in the Gateway it's an easier problem to solve but it still needs to be done we have the edged layer doing all of our TLS the client certificate indication so external requests are coming in and they're getting properly screened before they move into the application environment all these sidecars but notice that for an outbound call from E to F we also need to make some discovery and load balancing decision so we're calling F there are three F to choose from great we can pick one of those but what if service a B C and D are all trying to call service F at the same time which phone do they choose how do we avoid them or deciding upon the same instance of F here as we've got on the diagram so load balancing is how we've normally solved that but load balancing usually is predicated on the fact that there is a central load balancer that knows about everything is happening in the network we've now distributed that and so we need to do outbound load balancing or which requires a different different approach altogether and one which is very very difficult to do as well as you could when you have a single centralized view so another dependency that we're putting on the gateway is that it needs to outbound load balancing as well as it does its internal advancing the other thing that's difficult to solve is where do you put the configuration for where the e is allowed to talk to F so there's that fine grade access control either server to service or service to endpoint needs to be configured in the gateways and the only that that each of those gateways needs to be configured with it in a consistent way keeping all that stuff in sync and managing that through automated CIT D processes is entirely possible but it's also a difficult thing to get right and it's quite prone to error so into the service mesh so it's another pattern for api gateways it takes that micro gateway model but instead of trying to manage each of those gateways in turn and by different devops team's individually doing their own thing with their own gateways and their own style we now have our edge gateway edge gateway which is a more than likely your ingress controller the edge of your qpx cluster and then you've got a service mesh control plane so it's responsible for configuring the gateway so you don't do that you're directly anymore and then all the devops teams use the same control plane so that they configure with what they want to do who can talk to who authentication is required or access control is required and it goes through one place and the control planes responsible for then applying those changes and that configuration across your entire application environment solves a lot of the distributed governance problems and introduces a huge amount of complexity in the control plane to get all that stuff right - I think everything at the right time and to do so in a seamless way through a nice convenient API or CLI toolchain available in the service mesh control plane so it's promises a lot today is a lot of complexity and we're not quite ready for primetime with this model so let me take you back then to the nice simple to tear gateway and look at that same use case a service a calling service F II just needs to know where one gateway is any API call I want to make talk to the the routing gateway it and then the original gateway knows all the services all of their current state all the access control rules in one place so unless you have high distributed requirement for distributed governance across all these different teams updating things different times so as a bunch of problems however doing all that stuff in one place can it's like a bottom line right imagine we had a thousand services smoke so sheís not an unreasonable number and that we had maybe ten of those each in this count out environment so there's 10,000 services talking to 10,000 other services a lot of traffic it looks like a bottle thinking but what if we consider those 10,000 clients actually as externals of internet clients what if we had 10,000 clients trying to access 10,000 services behind one gateway well egor solved our problem well over 15 years ago on fifteen-year-old hardware by the way so in the reality is unless you're at the scale of someone like a Netflix or an uber this two-tier model actually works pretty well a long way forward and I won't talk through the pros and cons of each approach there you should have their own their own benefits but I will mention that the most the biggest deciding factor in what I see customers choosing what pattern to go with always comes down to security governance who's responsible for the security and if it's one place if you're a high regulated industry that is gonna be a centralized thing and distributing that out across lots of teams become something which is almost impossible to manage so if you don't have those constraints distributed models look great if you do have security governance requirements like do you care about everyone having the same set of TLS lifers then centralized wins out so with that thanks and I'll see you for Q&A after next session [Applause]

Channel: Nordic APIs

Views: 8,469

Keywords: API Management, API Strategy, Liam Crilly, NGINX, F5 Networks, 2019 Platform Summit, Nordic APIs

Id: oj3GD2xX0FY

Length: 19min 37sec (1177 seconds)

Published: Tue Nov 05 2019