Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Api gateway : To be or not to be

14.378 visualizaciones

Publicado el

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.

Publicado en: Software

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); }

×