Mastering Microservices with Kong (CodeMotion 2019)

03/04/2019 mastering-microservices
localhost:3000/?print-pdf#/ 1/36

OO
Context
What is API Management?
Demo
What is an API Gateway?
Demo
Hello, Kong
Demo
How does it work?
Plugins
Why Kong?
Wrap up

W API MW API M

(source: )
“API management is the process of creating
and publishing web APIs, enforcing their
usage policies, controlling access, nurturing
the subscriber community, collecting and
analyzing usage statistics, and reporting on
performance.
Wikipedia

MM
https://pxhere.com/en/photo/1435275

R D 1R D 1
Fro n
Be r AP Bre y AP
/api/beers/{id}
/api/brewery/{id}/beers
Ne d an AP ke !
/api/brewery/
/api/brewery/{id}
Ne d an AP ke !
1. Build a few μ-services
2. Deploy them using Docker compose
3. Observations:
1. Each μ-service has a different address
2. Logic (e.g. security) is duplicated in each μ-service

W API GW API G

(source: )
“Wikipedia does not have an article with this
exact name.
Wikipedia

(source: )
“Amazon API Gateway is a fully managed
service that makes it easy for developers to
create, publish, maintain, monitor, and
secure APIs at any scale.
Amazon API Gateway

(source: )
“Use Azure API Management as a turnkey
solution for publishing APIs to external and
internal customers. Quickly create
consistent and modern API gateways for
existing back-end services hosted
anywhere, secure and protect them from
abuse and overuse, and get insights into
usage and health.
Azure API Management

μ-μ-

RR
(e.g. nginx, Apache HTTPD, Netﬂix Zuul)
Routing (to individual μ-services)
SSL/TLS ofﬂoading
Load balancing

C API GC API G
Authentication
Autorisation (limited)
Rate limiting
Logging
Metering
Metrics
Compression
IP black- / whitelisting
Caching
...
Aggregations and transformations → .backend-for-frontend (BFF)

R D 2R D 2
Fro n
Kon
Be r AP Bre y AP
/api/beers/{id}
/api/brewery/{id}/beers
Ne d an AP ke !
/api/brewery/
/api/brewery/{id}
Ne d an AP ke !

R D 2R D 2
1. Configure Kong:
1. Define a service that points to an upstream.
2. Define a route for that service.
3. Define an upstream with (1..n) target.
SERVICE
       url: http://beer-api.upstream/
       name: beer-api.service
UPSTREAM
       name: beer-api.upstream
SERVICE
       url: http://brewery-api.upstream/
       name: brewery-api.service
UPSTREAM
       name: brewery-api.upstream
TARGET
       target: beer-api:9080

TARGET
       target: brewery-api-1:9080
       weight: 10
TARGET
       target: brewery-api-2:9080
       weight: 20
ROUTE
       paths: [ /api/beer/*, /api/brewery/*/beers ]
       methods: [ GET ]
ROUTE
       paths: [ /api/brewery* ]
       methods: [ GET ]

KK
Based on Nginx
Stores conﬁguration in a database (optional since 1.1)
Two interfaces: public and private

DD
Kong can be deployed in various modes
Standalone
Clustered
As Kubernetes Ingress Controller
On premise, in the cloud — you choose

UU

PP

PP
Open source, enterprise, 3rd party
Implemented in Lua

UU
In general:
Example (rate limiting):
curl http: kong:8001/services/<service name>/plugins
data "name=<plugin name>"
data "config.param=value"
curl http: kong:8001/services/beer api.service/plugins
data "name=rate limiting"
data "config.second=6"

M M PM M P

AA
Authentication: maps credentials in request to a consumer.
Consumers can have multiple credentials
Upstream API receives custom HTTP headers:
X-Consumer-Username and X-Consumer-ID

R D 3R D 3
Fro n
Kon
Be r AP Bre y AP
Ne d an AP ke !
Aut t a co m us AP ke
As i n g o s to co m
Con r & g o s
p o d b Kon
Con r & g o s
p o d b Kon
1. Create consumer
2. Assign key to consumer
3. Assign group to consumer
4. Secure upstream API with key-auth and ACL plugin

CC
You can write your own plugins!
Revelant documentation:
Plugin Development Guide
Plugin Development Kit

SS
├── README.md # Documentation right?! ;-)
└── my plugin # Name of the plugin
├── api.lua # Administration interface for the plugin (REST)
├── daos.lua # DAO's for custom entities inside the plugin
├── handler.lua # Plugin logic, executed upon request
├── migrations # Database migrations
│ ├── cassandra.lua # for Cassandra
│ └── postgres.lua # for PostgreSQL
└── schema.lua # Schema for plugin config

II HANDLERHANDLER
local BasePlugin = require "kong.plugins.base_plugin"
local MyPluginHandler = BasePlugin:extend()
MyPluginHandler.PRIORITY = 1003
MyPluginHandler.VERSION = "0.2.0"
function MyPluginHandler:new()
MyPluginHandler.super.new(self, "my plugin")
end
function MyPluginHandler:access(conf)
MyPluginHandler.super.access(self)
kong.log.info("Hello from My Plugin!")
end
return MyPluginHandler

RR
Plugins can be invoked at various moments:
Kong startup
Serving SSL-certiﬁcate
Request rewriting
API or consumer unknown!
Before hitting upstream
After receiving all response headers from upstream
For each part of the response body
Could be multiple chunks!
After sending the last byte to the client

C : TLSC : TLS

CC
Client
Load Balancer
   (TLS ofﬂoading)
             Request with TLS client cert
      Intrusion Prevention System
             Request without TLS client cert
Kong
             Request without TLS client cert

K -K -
Read the custom headers from the request
Look up cert by subject
Verify other ﬁelds
Add consumer to request and send it upstream

W K WW K W

TT
Cost (e.g. licences)
Developer experience
Documentation
Flexibility / expandability
Maintainability
Support
Functional and non-functional ﬁt out of the box
Future proof (hard to tell, though!)
Replaceability / (vendor) lock-in

WW KK
Kong (OS) seemed like a good choice:
great feature set out of the box
could buy support, if we wanted
active community
frequent releases
good documentation

EE
Changing the configuration is easy and quick
Configuration using API's
Imperative scripting is hard to understand later on
declarative configuration, , or db-less mode
Upgrading 0.13 → 0.14.1 was pretty easy
Lack of GUI might disappoint business stakeholders
or can help
kongverge kongfig
konga kongdash

localhost:3000/?print-pdf#/ 36/36@mthmulders Amsterdam 2019
QQ
Sample code:
→ Help conference organisers: don't forget to rate this talk!
POST /api/1.0/questions
User-Agent: audience/1.0
Accept: application/vnd.infosupport.answer
Content-Type: application/vnd.infosupport.question
"So, how would you "
HTTP/1.1 200 OK
Content-Type: application/vnd.infosupport.answer
Date: Wed, Nov 21 2018 20 00 00 GMT+1
Server: Maarten/1.0
Via: kong/1.0.0
"Well, it depends on "
http://bit.ly/enterprise-beers

Mastering Microservices with Kong (CodeMotion 2019)

Mastering Microservices with Kong (CodeMotion 2019)

Recommended

More Related Content

Similar to Mastering Microservices with Kong (CodeMotion 2019)

Similar to Mastering Microservices with Kong (CodeMotion 2019)(20)

More from Maarten Mulders

More from Maarten Mulders(20)

Recently uploaded

Recently uploaded(20)

Mastering Microservices with Kong (CodeMotion 2019)