Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Api gateway : To be or not to be

14,315 views

Published on

In this presentation, we're discussing whether we need API gateway or not on Micro-Services Architecture. We'll see pros and cons of several ways how clients access to services.

[Updated : 13 Jan 2015] Additional cons of API gateway is added, as commented by Hyunsik Kang(강현식), Coupang.

Published in: Software
  • Hello! Get Your Professional Job-Winning Resume Here - Check our website! https://vk.cc/818RFv
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • good stuff man
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Api gateway : To be or not to be

  1. 1. API Gateway : To be or not to be? Platform Architecture Team SK Planet
  2. 2. Synopsis • You’re developing based on MSA(Micro- Services Architecture) • How do the clients access the individual Micro-services?
  3. 3. #1 : I don’t care for clients, DIY Client A (Web) Client B (App) MS-A MS-ALB MS-A MS-BLB MS-A MS-CLB MS-A MS-DLB Security Logging Version … Security Logging Version … Security Logging Version … Security Logging Version …
  4. 4. #1 : I don’t care for clients, DIY • Clients need to access individual Micro-Services by themselves • Pros – No SPOF – No cost for developing API Gateway • Cons – Clients need to know endpoints of Micro-Services – If Micro-Services changes something(ex: LB VIP), all clients need to update – Each Micro-Services needs to handle these by themselves • Securities to protect their APIs (Auth, ACL, IP Blacklist, Rate Limiting, …), Versioning • Logging, Analytics, and any requirements from clients (ex : Batch APIs) – You’re adding another security path whenever new Micro-Service is added – If there is no API standard nor API spec sharing point between Micro-Services, clients will go to hell – Cannot handle composition scenario to prevent REST chattiness problem – You need to place Load Balancer in front of each Micro-services and consider fail-over of LB, too
  5. 5. #2 : Wrapper (Library/SDK) Wrapper * Wrapper * MS-A MS-ALB MS-A MS-BLB MS-A MS-CLB MS-A MS-DLB Client A (Web) Client B (App) * Wrapper could be created by individual Micro-Services Security Logging Version … Security Logging Version … Security Logging Version … Security Logging Version …
  6. 6. #2 : Wrapper (Library/SDK) • Clients use Wrapper(Library/SDK) to access Micro-Services • Pros – No SPOF – No cost for developing API Gateway – Higher Abstraction than REST APIs, so easy to use • Cons – Clients Wrapper needs to know endpoints of Micro-Services – If Micro-Services changes something(ex: LB VIP), all clients need to update Wrapper needs to be updated, QA, and re-deployed – Wrapper is responsible for backward compatibility – Each Micro-Services needs to handle these by themselves • Securities to protect their APIs (Auth, ACL, IP Blacklist, Rate Limiting, …), Versioning, Logging, Analytics, and any requirements from clients (ex : Batch APIs) – You’re adding another security path whenever new Micro-Service is added – If there is no API standard nor API spec sharing point between Micro-Services, clients will go to hell You need to update Wrapper document/manual, provide download location, manage achieve, maintain release notes, send notices, and maybe cause forced-update of your app – Cannot handle composition scenario to prevent REST chattiness problem, but need to update/re-deploy your wrapper – You need to place Load Balancer in front of each Micro-services and consider fail-over of LB, too – Becoming big burden if you need to support polyglot clients
  7. 7. Checkpoint • It’s all about level of “Abstraction” – Provide it as REST APIs – Provide it as Wrapper (Library/Wrapper) • Higher abstraction – Makes client happy (but only if you maintain versions/backward compatibility well) – Makes Wrapper developer unhappy – Even worst if API Provider != Wrapper developer • Common RoR problems – If client fails, who’s responsible for investigate it? While stacktraces says problem is raised on the Wrapper, they will call Wrapper developer even though client mis-use wrapper or server fails 
  8. 8. API Gateway #3 : API Gateway Client A (Web) Client B (App) MS-A MS-A MS-A MS-B MS-A MS-C MS-A MS-D Security Logging Version …
  9. 9. #3 : API Gateway • Single endpoint for clients, handle requests proxied/routed to the appropriate service (or service instance) • Pros – Can solve most problems – Separation of Concerns • Micro-Services focus on business features • API Gateway provides protection/common feature layer – Minimize/Isolate services’ change impacts • Cons – Possibility of SPOF/bottleneck – Performance tradeoff due to processing time in API Gateway and more network hops – Need to manage routing rule or APIs – Needs Service Discovery/Registry – Cost for developing API Gateway – Additional Hardware/Network/Management cost – Risk of management bottleneck
  10. 10. SPOF/bottleneck : Scale-out API Gateway Client A (Web) Client B (App) MS-A MS-A MS-A MS-B MS-A MS-C MS-A MS-D Security Logging Version … API Gateway Security Logging Version … LB
  11. 11. SPOF/bottleneck : Partitioning API Gateway Client A (Web) Client B (App) MS-A MS-A MS-A MS-B MS-A MS-C MS-A MS-D Security Logging Version … API Gateway Security Logging Version … LB API Gateway Security Logging Version … API Gateway Security Logging Version … LB DNS/ LB A or B C or D
  12. 12. SPOF/bottleneck : Partitioning API GatewayClient A (Web) Client B (App) MS-A MS-A MS-A MS-B MS-A MS-C MS-A MS-D Security Logging Version … API Gateway Security Logging Version … LB API Gateway Security Logging Version … API Gateway Security Logging Version … LB
  13. 13. Performance Tradeoff • Network hop/latency depends on network topology • API Gateway processing time depends on what you want to do in API Gateway • Consider Tradeoff : What’s more important? • Some Tips – Don’t parse request/response body if you don’t need it – Caching on API Gateway
  14. 14. Managing Routing Rule or APIs • Routing Rule-based Control – Define Coarse-grained routing rule – Gateway knows MSs but don’t care for specific APIs – Micro-Services need to resolve APIs and validate whether they are valid request • API-based Control – Register APIs want to be managed in Gateway – API Gateway resolve APIs and validate request/response with exact match – Gateway should know APIs
  15. 15. Managing Routing Rule or APIs Client A (Web) API Gateway MS-A /A/InvalidResources with ValidCredential /InvalidResources 404 Not Found404 Not Found Security : Passed Client A (Web) API Gateway /A/InvalidResources with ValidCredential 404 Not Found Security : Passed /A/* -> MS-A /A/ValidResources -> MS-A/ValidResources - params : … - result: … MS-A /A/ValidResources?invalid with ValidCredential 400 Bad Request (Invalid Parameter) /A/ValidResources?invalid with ValidCredential 400 Bad Request (Invalid Parameter) /A/ValidResources?invalid with ValidCredential 400 Bad Request (Invalid Parameter) Routing Rule Based Control(per MS) API Based Control (per API)
  16. 16. Managing Routing Rules or APIs • Routing rule based is preferred when • Clients are 1st parties • Coarse-grained control is enough • You can provide API spec/document from Micro-Services directly • API is changed frequently • API based is preferred when • Clients are including 3rd parties • Minimize Micro-Services’ overhead from invalid request • Fine-grained control is needed • If you require mediation or some manipulation per APIs • You need to provide API spec/document from API Gateway • Recommendations – Use routing rule based control primarily, then append API-based control as you need
  17. 17. Managing API specification • You can manage it – Deeply coupled with API Gateway API-based Control requires for API Gateway to know API specification – Externally (ex : Swagger, ProtocolBuffer) Both Routing Rule-based and API-based control • If you have a API spec, – Client developer can create client codes (even wrapper) – Server developer can create server codes
  18. 18. Service Discovery/Registry MS-A Container API Gateway UI UI MS-A HA Proxy HA Proxy HA Proxy Service Registry Service Agent MS-A Container MS-A HA Proxy Service Agent MS-B Container MS-B Service Agent MS-B Container MS-B Service Agent
  19. 19. Cost for developing API Gateway • Depends on what you want to do with API Gateway • Simple requirements = Simple API Gateway (nginx/HA proxy might be enough for you) • Node.js is a good start point to implement • But going complex – If you need to consider 3rd parties and Open API since Developer portal and Onboarding process is required – If you want some GUI and management console (= Publisher portal) – Consider API Gateway as Silver Bullet (ESB?)…
  20. 20. Additional Hardware/Network/Management cost • Another tradeoff : What’s more important? • Depends on how you implement it and what you want to do • Cost could be issue – If you consider adopting commercial products – If you consider doing a lot of manipulation in API Gateway
  21. 21. Risk of management bottleneck • If API Gateway is managed by single team, there are risks of management bottleneck – API Gateway team has primary responsibility for changes/failure/backward compatibility, … – API Gateway team could be a bottleneck (going worse if you do a lot of manipulations in it) • Recommendation : separate managements – API Gateway itself (API Gateway team) – Services on the API Gateway (each service teams)
  22. 22. API Gateway: To be or not to be • Consider your scenario • But generally, API Gateway is a good choice… and it begins API Managements of your organization • To adopt it, start with simple one – again, nginx/HA proxy might be enough for you – Consider complex product/solution later
  23. 23. Send a feedback var you = {}; if (you.like||you.dislike||you.suggest||you.request) { var url = "https://www.linkedin.com/in/lancersahn"; linkedin.contact(url); }

×