API Gateway : To be or not to be?

API Gateway : To be or not to be?Platform Architecture TeamSK PlanetSynopsisYoure developing based on MSA(Micro-Services Architecture)How do the clients access the individual Micro-services?#1 : I dont care for clients, DIYClient A(Web)Client B(App)MS-AMS-ALBMS-AMS-BLBMS-AMS-CLBMS-AMS-DLBSecurityLoggingVersionSecurityLoggingVersionSecurityLoggingVersionSecurityLoggingVersion#1 : I dont care for clients, DIYClients need to access individual Micro-Services by themselvesProsNo SPOFNo cost for developing API GatewayConsClients need to know endpoints of Micro-ServicesIf Micro-Services changes something(ex: LB VIP), all clients need to updateEach Micro-Services needs to handle these by themselvesSecurities to protect their APIs (Auth, ACL, IP Blacklist, Rate Limiting, ), VersioningLogging, Analytics, and any requirements from clients (ex : Batch APIs)Youre adding another security path whenever new Micro-Service is addedIf there is no API standard nor API spec sharing point between Micro-Services, clients will go to hellCannot handle composition scenario to prevent REST chattiness problemYou need to place Load Balancer in front of each Micro-services and consider fail-over of LB, too

#2 : Wrapper (Library/SDK)Wrapper*Wrapper*MS-AMS-ALBMS-AMS-BLBMS-AMS-CLBMS-AMS-DLBClient A(Web)Client B(App)* Wrapper could be created by individual Micro-ServicesSecurityLoggingVersionSecurityLoggingVersionSecurityLoggingVersionSecurityLoggingVersion#2 : Wrapper (Library/SDK)Clients use Wrapper(Library/SDK) to access Micro-ServicesProsNo SPOFNo cost for developing API GatewayHigher Abstraction than REST APIs, so easy to useConsClients Wrapper needs to know endpoints of Micro-ServicesIf Micro-Services changes something(ex: LB VIP), all clients need to updateWrapper needs to be updated, QA, and re-deployedWrapper is responsible for backward compatibilityEach Micro-Services needs to handle these by themselvesSecurities to protect their APIs (Auth, ACL, IP Blacklist, Rate Limiting, ), Versioning, Logging, Analytics, and any requirements from clients (ex : Batch APIs)Youre adding another security path whenever new Micro-Service is addedIf there is no API standard nor API spec sharing point between Micro-Services, clients will go to hellYou need to update Wrapper document/manual, provide download location, manage achieve, maintain release notes, send notices, and maybe cause forced-update of your appCannot handle composition scenario to prevent REST chattiness problem,but need to update/re-deploy your wrapperYou need to place Load Balancer in front of each Micro-services and consider fail-over of LB, tooBecoming big burden if you need to support polyglot clients

CheckpointIts all about level of AbstractionProvide it as REST APIsProvide it as Wrapper (Library/Wrapper)Higher abstractionMakes client happy (but only if you maintain versions/backward compatibility well)Makes Wrapper developer unhappyEven worst if API Provider != Wrapper developerCommon RoR problemsIf client fails, whos 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 API Gateway#3 : API GatewayClient A(Web)Client B(App)MS-AMS-AMS-AMS-BMS-AMS-CMS-AMS-DSecurityLoggingVersion#3 : API GatewaySingle endpoint for clients, handle requests proxied/routed to the appropriate service (or service instance)ProsCan solve most problemsSeparation of ConcernsMicro-Services focus on business featuresAPI Gateway provides protection/common feature layerMinimize/Isolate services change impactsConsPossibility of SPOF/bottleneckPerformance tradeoff due to processing time in API Gateway and more network hopsNeed to manage routing rule or APIsNeeds Service Discovery/RegistryCost for developing API GatewayAdditional Hardware/Network/Management costRisk of management bottleneckSPOF/bottleneck : Scale-outAPI GatewayClient A(Web)Client B(App)MS-AMS-AMS-AMS-BMS-AMS-CMS-AMS-DSecurityLoggingVersionAPI GatewaySecurityLoggingVersionLBSPOF/bottleneck : PartitioningAPI GatewayClient A(Web)Client B(App)MS-AMS-AMS-AMS-BMS-AMS-CMS-AMS-DSecurityLoggingVersionAPI GatewaySecurityLoggingVersionLBAPI GatewaySecurityLoggingVersionAPI GatewaySecurityLoggingVersionLBDNS/LBA or BC or DSPOF/bottleneck : PartitioningAPI GatewayClient A(Web)Client B(App)MS-AMS-AMS-AMS-BMS-AMS-CMS-AMS-DSecurityLoggingVersionAPI GatewaySecurityLoggingVersionLBAPI GatewaySecurityLoggingVersionAPI GatewaySecurityLoggingVersionLBPerformance TradeoffNetwork hop/latency depends on network topologyAPI Gateway processing time depends on what you want to do in API GatewayConsider Tradeoff : Whats more important?Some TipsDont parse request/response body if you dont need itCaching on API GatewayManaging Routing Rule or APIsRouting Rule-based ControlDefine Coarse-grained routing ruleGateway knows MSs but dont care for specific APIsMicro-Services need to resolve APIs and validate whether they are valid requestAPI-based ControlRegister APIs want to be managed in GatewayAPI Gateway resolve APIs and validate request/response with exact matchGateway should know APIs

Managing Routing Rule or APIsClient A(Web)API GatewayMS-A/A/InvalidResourceswith ValidCredential /InvalidResources404 Not Found404 Not FoundSecurity : PassedClient A(Web)API Gateway/A/InvalidResourceswith ValidCredential 404 Not FoundSecurity : Passed/A/* -> MS-A/A/ValidResources -> MS-A/ValidResources - params : - result: MS-A/A/ValidResources?invalidwith ValidCredential 400 Bad Request(Invalid Parameter)/A/ValidResources?invalidwith ValidCredential 400 Bad Request(Invalid Parameter)/A/ValidResources?invalidwith ValidCredential 400 Bad Request(Invalid Parameter)Routing Rule Based Control(per MS)API Based Control (per API)Managing Routing Rules or APIsRouting rule based is preferred whenClients are 1st partiesCoarse-grained control is enoughYou can provide API spec/document from Micro-Services directlyAPI is changed frequentlyAPI based is preferred whenClients are including 3rd partiesMinimize Micro-Services overhead from invalid requestFine-grained control is neededIf you require mediation or some manipulation per APIsYou need to provide API spec/document from API GatewayRecommendationsUse routing rule based control primarily, then append API-based control as you needManaging API specificationYou can manage itDeeply coupled with API GatewayAPI-based Control requires for API Gateway to know API specificationExternally (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 codesService Discovery/RegistryMS-A ContainerAPI GatewayUIUIMS-AHA ProxyHA ProxyHA ProxyServiceRegistryService AgentMS-A ContainerMS-AHA ProxyService AgentMS-B ContainerMS-BService AgentMS-B ContainerMS-BService AgentCost for developing API GatewayDepends on what you want to do with API GatewaySimple requirements = Simple API Gateway(nginx/HA proxy might be enough for you)Node.js is a good start point to implementBut going complexIf you need to consider 3rd parties and Open API since Developer portal and Onboarding process is requiredIf you want some GUI and management console (= Publisher portal)Consider API Gateway as Silver Bullet (ESB?)Additional Hardware/Network/Management costAnother tradeoff : Whats more important?Depends on how you implement it and what you want to doCost could be issueIf you consider adopting commercial productsIf you consider doing a lot of manipulation in API Gateway Risk of management bottleneckIf API Gateway is managed by single team, there are risks of management bottleneckAPI 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 managementsAPI Gateway itself (API Gateway team)Services on the API Gateway (each service teams)API Gateway: To be or not to beConsider your scenarioBut generally,API Gateway is a good choice and it begins API Managements of your organizationTo adopt it, start with simple oneagain, nginx/HA proxy might be enough for youConsider complex product/solution laterSend a feedbackvar you = {};

if (you.like||you.dislike||you.suggest||you.request){ var url = "https://www.linkedin.com/in/lancersahn";

linkedin.contact(url);}