Api gateway : To be or not to be

API Gateway : To be or not to be?
Platform Architecture Team
SK Planet

Synopsis
• You’re developing based on MSA(Micro-
Services Architecture)
• How do the clients access the individual
Micro-services?

#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
…

#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

#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
…

#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

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 

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
…

#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

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

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

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

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

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

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
404 Not Found
Security : Passed
/A/* -> MS-A
/A/ValidResources -> MS-A/ValidResources
- params : …
- result: …
MS-A
/A/ValidResources?invalid
400 Bad Request
(Invalid Parameter)
400 Bad Request
(Invalid Parameter)
400 Bad Request
(Invalid Parameter)
Routing Rule Based Control(per MS)
API Based Control (per API)

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

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

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

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?)…

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

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)

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

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

Api gateway : To be or not to be

Recommended

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Api gateway : To be or not to be (20)

Recently uploaded (20)

Api gateway : To be or not to be