Downloaded 32 times
More Related Content
Similar to Deployment Patterns for API gateways
Deployment Patterns for API gateways
- 1. Gartner AADI Summit2019 Deployment Patterns for API Gateways Sean Maritz July 2019
- 3. 3 1. API managementvs API gateway 2. API gateway deployment patterns 3. Selecting the right deployment pattern for my application Agenda Sean Maritz Technical Solutions Architect s.maritz@f5.com is now a part of
- 4.
- 5. Monolithic Application Architecture • Featuresets coded into the application. • Adapters complicated to interact with. • Rest API available but is an application in itself. • Complicated change management. • Broken code = Broken Application.
- 6. Modernised Application Architecture 6 • Referencethe best in class of code. • Feature Rich or Light Weight. • Interchangeable vendors. • Scalable. • Flexible. • Resilient
- 7.
- 8. API Management 8 Dev &Product Security (App, Net & Ops) Network / DevOPS Operations, Support, Networks, DevOPS, DEVops Product, Billing Marketing, DevOps, Product. Sales.
- 9. API Management • Policy management •Analytics & monitoring • Developer documentation API Gateway • Authenticator • Request router • Rate limiter • Exception handler
- 11. 439 million Total sitesrunning on NGINX Source: Netcraft June 2019 Web Server Survey
- 12. 83% 40%of allhits are classified as API traffic (JSON/XML) of NGINX deployments are as an API gateway Source: Akamai State of the Internet Feb-2019 Source: NGINX User survey 2017, 2018
- 16. Why care? 16 • Latency& response time • Indiscriminate network hops • Expensive layer 7 payload inspection • Enforced scaling dimensions
- 17. Traditional v NGINXAPI Management What makes NGINX unique. 17
- 18. Data Plane Control Plane <scripts> <API’s> RequestResponse Data Plane Control Plane Request Response Manages and Monitors all of your API’s Routes Incoming API Calls Traditional API Management NGINX API Management Manages and Monitors all of your API’s Routes Incoming API Calls A B C
- 19. NGINX Controller High LevelArchitecture API Definition API Deliver y Policy API DefinitionAPI Definition Backend A Backend B Backend C NGINX Plus Backend A Backend B Backend C Backend D API Management (control plane) API Gateway (data plane)
- 21. API Gateway Essential Functions 21 TLStermination Client authentication Fine-grained access control Request routing Rate limiting Load balancing Service discovery of backends Request/response manipulation
- 22. API A API B API C API A API B API C Edge Gateway 22 API A API B API C • TLStermination • Client authentication • Authorization • Request routing • Rate limiting • Load balancing • Request/response manipulation
- 23. Edge Gateway 23 API A API B API C D E F G H • TLStermination • Client authentication • Authorization • Request routing • Rate limiting • Load balancing • Request/response manipulation • Façade routing
- 24. Two-Tier Gateway 24 API A API B API C D E F G HSecurityGateway • TLS termination • Client authentication • Centralized logging • Tracing injection Routing Gateway • Authorization • Service discovery • Load balancing • Rate Limiting
- 25. Microgateway 25 E E F G F H D D D E F DevOps Team- owned • Load balancing •Service Discovery • Authentication per API • TLS Termination • Routing • Rate limiting
- 27. F E Microgateway 27 E E F F D D D • Service discoveryintegration • Obtain authentication credentials • Everything else!
- 28. F E Sidecar Gateway 28 E E F F D D D • Outboundload balancing • Service discovery integration • Authentication • Authorization? Edge / Security Gateway • TLS termination • Client authentication • Centralized logging • Tracing injection
- 29. Kubernetes Cluster F E Service Mesh 29 E E F F D D D ServiceMesh Control Plane Ingress / Edge Gateway All DevOps teams
- 30. Traditional API Management 30 Control Data Control Data Control Data A A A B B B C C C •Complex • Slow • Expensive
- 31. Nginx API Management 31 Data Data Data A A A B B B C C C Control Config Analytics Config Analytics Config Analytics •Simple • Fast • Cost Effective • Resilliant
- 32. Deployment Pattern Options Edge Gateway +Monoliths with centralized governance - Frequent changes, DevOps team-owned microservices Two-Tier Gateway + Flexibility, independent scaling of functions - Distributed control Microgateway + DevOps teams, high-frequency updates - Hard to achieve consistency, authorization minefield Sidecar Gateway + Policy-based E/W, strict authentication requirements - Control plane complexity
- 33.
Editor's Notes
- #4 As well as Internet history, I'll be talking about …
- #6 Here is an example of what a Ride Share or Taxi App may have have looked like in a monolithic type of application. Components braking each other Heavily dependant on the entire ecosystem being available in one Application Server with components from external providers being built into the code base.
- #7 Today we don’t manage our applications in a single location, we rely in specialist apps that are purpose built for a specific function and we connect these into our application. Industry leading CRM apps connected with industry leading billing app connected to notification app or Mapping application and GPS app’s which are brought together to make a mashup of apps to build your own solution. There’s a whole array of benefits to build applications like this including the removal of Vendor Lock in making it a far easier exercise to make the components of your application interchangeable. Google & Maps (Uber EG) Business Functions
- #8 Developing with API’s in a single frame requires multiple domains to be trusted and with the rapid growth of CDN’s and the requirement to increase security concerns when consuming CDN traffic, the need to whitelist a list of 10 domains became an absolute nightmare to manage. Even Alias Domains increased the number of domains and SSL certificates that needed to be managed. I Checked a well known remote management tool & they still have 73 Domain Whitelisting recommendations for firewall configs, some of which are root CDN domains. Security impact is massive. Tracking application behaviours is simplified. CLICK By introducing an API gateway we now have a single domain name and 1 SSL termination to manage.
- #9 Before we get into the guts of the content, there is a clear destiction we need to make between API Management and API gateway. API Management includes these overall concepts which individually have their own standards and rules that individually tend to be a separation of concerns for different personas in the API management lifecycle.
- #10 How many of you already use NGINX as an API gateway?
- #12 Source: https://news.netcraft.com/archives/category/web-server-survey/ From there NGINX grew rapidly and now is used by over 439million websites world wide, including Uber, Netflix, Airbnb, Twitch, Stripe and other innovative companies. NOTE: In “Misc. Extras” section, there is a slide of relevant OSS users.
- #13 This is the result Not to mention how often NGINX underpins the API gateway of commercial vendors. Akamai sources: https://www.akamai.com/us/en/multimedia/documents/state-of-the-internet/state-of-the-internet-security-retail-attacks-and-api-traffic-report-2019.pdf https://threatpost.com/fighting-fire-with-fire-api-automation-risks/141163/ (guest post by Tony Lauro, Director, security technology and strategy, Akami)
- #14 But API traffic is just like web traffic, right? It’s all HTTP after all… Well, yes and no.
- #15 Here’s a conventional API call Kinda indistinguishable from any web request Superficially at least. Web=RO, API=RW Using http for exposing data sets and business logic is much more dangerous than publishing applications that expose a narrow, bounded scope over that data set.
- #16 This one is a little more exotic Same URI But now we care about: Whether this client is permitted to change the price of items? That the payload is JSON That there is a price and currency That someone else isn’t also trying to change the price of this item right now You need to decide how much of that you want to handle at the application, versus how much you want the API gateway to discard invalid requests
- #17 Delivering API traffic puts pressure on your application delivery infrastructure Cannot be accelerated in the traditional way. Caching is partially effective Security needs are different
- #20 Components
- #21 Look at the most common API gateway deployment patterns Starting with … the Edge Gateway
- #22 So first, just as a level-setting exercise Let's cover the 8 essential functions of an API gateway
- #23 Here we have our perfectly polished APIs – A, B and C Follows the classic Application Delivery Controller architecture Clients talk to the API gateway, deployed at the edge of the application infrastructure The API gateway does things As we scale the APIs the API gateway also load balances traffic intelligently across the available instances of each API, and
- #24 It’s the traditional pattern, and it works very well for monoliths What happens when you start decomposing those monoliths? OR introducing microservices Façade routing allows us to publish a single API that is comprised of multiple backend services. It’s fine if we just want to expose more APIs directly, for example service E But when API-A needs to make an API call to service D … We have no security controls, no authentication, no traffic management, no load balancing
- #25 Another common pattern is to use a 2-tier gateway pattern. Security+Routing Now when API A calls service D, it goes through the routing gateway Here we have a nice separation of concerns – independently scaled Notice how the security gateway doesn’t do much in the way of, what you would call, API gateway work. Compatible with existing application delivery controllers, or simple cloud platform load balancers As you get deeper into microservices deployments – when these things are in containers, deployed through automated CI/CD pipelines, and owned by multiple DevOps teams the centralized gateway (1-tier or 2-tier) can become an administrative bottleneck. Typically, these centralized gateways are owned by a different team, whose change control processes are incompatible with DevOps-style, high-frequency, automated deployments.
- #26 Works well with cloud deployments because you can utilize the simple, native load balancer E consumes F in the same way as an external client Particularly good for widely distributed deployments where service E and service F are deployed far away from one another Be careful with authN per API – because you’ll end up with at least as many authN methods as you have APIs
- #27 But there’s one more thing to consider Our application is part of a wider ecosystem - a wider economy - that requires East/West traffic to be successful. Notice that with microservices we expect a lot more service-to-service communication That's simply a function of their size As components get smaller they necessarily depend on other components
- #28 The microgateway pattern is an effective approach for service-to-service traffic but it has some drawbacks: Service E needs to be written or configured to know that service F is available through migrogateway F – and that changes for each deployment environment Also needs to be configured with or dynamically obtain authentication credentials And what if each service implements a different authentication scheme?! Difficult to reliably determine whether service E is allowed to call service F – who owns the policy for that If the microgateway is now responsible for all of the essential functions of an API gateway then it’s not really “micro” any more. Beware of Microgateway solutions that do not deliver the complete feature set.
- #29 To address this we can look at the sidecar pattern Whereby we co-locate the microgateway alongside each service - you can imagine these in a single container. Outbound load balancing is interesting What load balancing algorithm do you use for outbound load balancing? How can you be sure that each sidecar for service E has exactly the same configuration Where do you put the configuration for who can talk to who? Does the sidecar gateway co-located with service E know which other services it may request? Or does the sidecar co-located with service F know which other services may make requests? Or both? That’s a lot to keep track of!
- #30 Now all your essential API gw functions no longer have to fit in a Microgateway have to fit in each service container. All of the DevOps teams share that control plane, using RBAC to avoid making changes to someone else’s application. So you are delegating the sidecar gateway configuration to the control plane.
- #33 So what have we learnt? Each approach has merits…