Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.

Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.

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

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