Api gateway : To be or not to be
Download as PPTX, PDF120 likes16,247 views
The document discusses different approaches for client access to micro-services in a micro-services architecture, focusing on DIY clients, wrappers, and API gateways. Each solution has its own pros and cons regarding complexity, security, manageability, and performance. Ultimately, while API gateways can introduce additional costs and potential bottlenecks, they are often recommended for better management and organization of service interactions.
Api gateway : To be or not to be
- 1. API Gateway : To be or not to be? Platform Architecture Team SK Planet
- 2. Synopsis • You’re developing based on MSA(Micro- Services Architecture) • How do the clients access the individual Micro-services?
- 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. #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. #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. #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. 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. 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. #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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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); }