1. Microservices &
API Gateways
Marco Palladino

2. I am Marco Palladino CTO at mashape.com
Core committer at github.com/Mashape/kong 2

3. Topics Monolitich vs Microservices API Gateway Pattern
Kong + OpenResty
Pros and Cons
With real world use-cases
For API Management 3

4. Monolithic Architecture
Client LB
Customers
Orders
Invoices
Database Schema 4

5. Monolithic Application Pros/Cons
Simplicity, for small
Faster early
Easy testing
IDE support
codebases
development speed
Not ideal for growing
Slower iterations in
Steep code
Harder to innovate
codebases
the long term
learning curve 5

6. Microservice-oriented architectureLB
DB Schema
Customers
Client LB
DB Schema
Orders LB
DB Schema
Invoices
Event Handler + Workers 6

7. Microservice-oriented Application Pros/Cons
Better architecture for
Better agility in the
Microservices: easy
Isolation for scalability
large applications
long term
to learn
and damage control
Complex infrastructure
Consistency and
More moving parts
Harder to test
requirements
availability 7

8. Why an API Gateway?
API Gateway
Microservices 8

9. API Gateway Pattern LB DB Schema Customers LB DB Schema Client
Orders
• Optimized endpoints
• Request collapsing LB
DB Schema
Invoices
• And more 9

10. Optimized Endpoints LB Customers LB Client API Gateway Orders LB{
"id": "cus_123",
"customer_name": "Bob", LB
"address": "500 Montgomery St, SF"
Customers } {
"id": "order_123",
"customer_id": "cus_123", LB
Client
API Gateway
"item_name": "Vacuum Cleaner"
Orders } {
GET /customers/{id}
"order_id": "order_123", LB
"price": "99.99"
Invoices } {
"customer_id": "cus_123",
"name": "Bob",
"address": "500 Montgomery St, SF",
"orders": […],
"invoices": […], }
+ extra transformations 10

11. Centralized Middleware Functionality
Public APIs
Available to everybody
Client
API Gateway
Private APIs
Only for internal usage
• Authentication
• Security
Partner APIs
Only for specific partners
• Traffic Control
• Ops
• Logging
• Transformations
FaaS
AWS Lambda, etc
• Etc 11

12. Ops: Blue/Green deployments
customers.service
customers.service
1.0.0
1.0.0
ALL TRAFFIC
NO TRAFFIC
API Gateway
API Gateway
NO TRAFFIC
ALL TRAFFIC
customer.service
customer.service
1.0.1
1.0.1 12

13. Ops: Canary Releases customers.service customers.service 1.0.0 1.0.0
100% TRAFFIC
90% TRAFFIC
API Gateway
API Gateway
0% TRAFFIC
10% TRAFFIC
customer.service
customer.service
1.0.1
1.0.1 13

14. Ops: Load Balancing 1. 2. 3. LB Orders Client API Gateway Customers
Service
• etcd
Discovery
• consul
Orders 3.
Client
API Gateway
Customers 14

15. Ops: Circuit Breakers Customers Client API Gateway Orders Invoices
Too many 50x errors 15

16. Building a microservice!=
Running a microservice

17. 17

18. API Gateways, and Kong, can help
Client •
Authentication •
Security •
Traffic Control •
Ops •
Logging •
Transformations •
Etc
Microservice
Microservice
• API for Automation
• On-boarding
• Developer Portal
Microservice 18

19. What is Kong?
Kong is an open-source management layer for APIs to secure, manage
and extend APIs and Microservices.

20. What is Kong?
Built on top of OpenResty, centralizes common middleware functionality:

21. Kong Plugins Can be created from scratch & extended by the community.

22. Kong: OpenResty + NGINX
• JSON HTTP API
RESTful Administration API
• Extendable by Plugins
• Can be integrated for automation
• Plugins created with LUA
Plugins
• Intercept Request/Response lifecycle
• Can integrate with third-party services
• Either Cassandra or PostgreSQL
Clustering & Datastore
• Optionally Redis for some plugins
• Single or multi-DC clustering
• Underlying engine of Kong
OpenResty
• Provides hooks for Req/Res lifecycle
• Extends underlying NGINX
• The core dependency
NGINX
• Handles low-level operations
• Solid foundation and known tech

23. NGINX Configuration nginx.conf nginx-kong.conf https://getkong.org/
worker_processes auto;
init_by_lua_block {
daemon on; .. }
pid pids/nginx.pid;
error_log logs/error.log notice;
init_worker_by_lua_block { ..
worker_rlimit_nofile 4864; }
events {
server {
worker_connections 4864;
listen :8000;
multi_accept on;
location / { }
access_by_lua_block { ..
http { }
include 'nginx-kong.conf'; }
header_filter_by_lua_block { .. }
body_filter_by_lua_block { .. }
log_by_lua_block { .. } } }
nginx.conf
nginx-kong.conf ..

24. Kong Entry-points $ curl 127.0.0.1:8000 Proxy $ curl 127.0.0.1:8443
Admin API

25. Core Entities $ curl 127.0.0.1:8001/apis
$ curl :8001/consumers
$ curl :8001/plugins

26. Plugins Configuration Matrix
1. Per every API and every Consumer
2. Per every API and a specific Consumer
3. Per a specific API and every Consumer
4. Per a specific API and a specific Consumer

27. Kong Components Kong Kong Core Core DB DB DB KONG KONG
• Kong nodes pointing to the same datastore must cluster together
Kong is bundled with its required
KONG
• Clustering is done automatically by discovering nodes in the main
KONG
dependencies:
datastore
• dnsmasq, to resolve DNS addresses
• Kong nodes in the same cluster exchange invalidation events to delete
• serf, for Kong nodes clustering
the datastore entities that have been cached locally for faster
performance
dnsmasq
dnsmasq
The dependencies are abstracted
• Invalidation events only invalidate the specific database entity that has
away from the final user.
Kong
Kong
been updated/deleted, which will force the node to request the data
again from the datastore on the next execution
Core
Core
serf
serf •
Kong supports Cassandra or PostgreSQL as its main datastore DB •
The main datastore stores all the persistent data required by Kong and its plugins DB DB
• Port 8000 and 8443 (SSL) are the entry points for consumers •
APIs, consumers, credentials, etc are example of data stored in the main datastore
• Port 8001 is the Admin port for Kong (to be secured) •
Optionally some plugins can use Redis to store a subset of the data, like counters for Rate-Limiting
• Port 7946 is the default clustering port that should only be available •
A database cluster (between database nodes) is different than a Kong cluster (between Kong nodes)
between Kong nodes on both UDP/TCP protocols

28. Multi-DC deployment DC1 DC2 API API API API API API API API API API
Data
KONG C* C*
KONG
KONG C* C*
KONG
Invalidation events
• Horizontal Scalability
• Cassandra or PostgreSQL
• Clients consuming Kong can be both internal and external
Client
Client

29. Demo Time

30. Thank You getkong.org mashape.com @thefosk linkedin.com/marcopalladino30
#nginx #nginxconf