The ultra-high
performance API
Gateway with
middlewares

What is an API
Gateway?
TL;DR
A REST service that exposes
endpoints with use cases

What is an API
Gateway?
TL;DR
It’s also an entry point for clients to
your microservices

What is and what
is not an API GW
Extended version
https://medium.com/devops-faith/an-
api-gateway-is-not-the-new-unicorn-
303a3863f2a6

And a
Middleware?
TL;DR
An application that wraps the
original application, adding more
functionality

Introducing KrakenD

Project overview
- Started Nov 2016
- Product built in Go language
- Concurrency
- High performance
- Coded after facing problems with unreliable APIs in production
- 3 core developers. More contributors are joining.
- 100% Open Source

Direct consumption of (micro)services?

API Gateway

KrakenD is a PURE API Gateway

Why KrakenD? There are many API GW solutions!
Yes, there are, but:
- Most of them cover features beyond an API Gateway
- Do not perform well or have poor performance
- Unfortunate architectures (e.g: share state between nodes)
- Single points of failure
- Paid, expensive and very limited. Monthly plans including X calls/month.
Convert that to reqs/sec!!
- Need complicated coding to make them work
- Not really extensible

The KrakenD
principles
- Reactive is key (even failing fast is
better than succeeding slow)
- The simpler, the better
- Everything is pluggable
- Each request must be processed in
its own request-scoped context

The Reactive Manifesto
http://www.reactivemanifesto.org/

Features

Features overview

KrakenD features
● Aggregates information from many sources into single endpoints.
● Manipulates responses and allows you to group, wrap, rename...
● Filters and shrinks responses, hiding unwanted attributes or selecting them
● Throttles (rate limits) connections against KrakenD and against backends
● Protects your backends with circuit breakers and implements all kinds of
security measures.
● Discovers your service instances by integrating with your SD provider
● Extends your ecosystem as it supports a myriad of middlewares and plugins,
such as OAuth or security layers.
● Speaks different encoding formats and protocols.
● Fine control of manipulations, validations and filtering with DSL configurations

Security features
● User quota
● Support for SSL
● OAuth client credentials grant supported
● Restrict connections by host
● HTTP Strict Transport Security (HSTS)
● Clickjacking protection
● HTTP Public Key Pinning (HPKP)
● MIME-Sniffing prevention
● Cross-site scripting (XSS) protection

Use cases
● Increase user experience in apps. Less data consumption and faster responses
● Instant creation of a new REST API
● Add APIs in legacy systems
● Unify data coming from different sources and encodings
● Publish a fixed interface, let the backends evolve and change contracts.
● Quick Microservices adoption
● Create aggregated views from a lot of services
● Build MVPs using data from anywhere (bonus: backend for api2html)
● Smooth transition over different API version releases

Performance

Performance
Requests per second in equal conditions. See benchmarks

Response time distribution
(real example)

Without KrakenD
~30% responses under 300ms
~60% responses between 300-1250ms
~10% responses over 1250ms

With KrakenD
~35% responses under 100ms
~55% responses between 100-300ms
~10% responses over 300ms

Do one thing and do it well.

KrakenD ecosystem
● KrakenD CE: KrakenD distribution ready to use.
● KrakenD framework: the core of the KrakenD is an open sourced library that
everyone can use, extend and modify. The project has several examples for
the integration with other third party libs (gorilla, negroni, gin, etc)
● KrakenD Contrib: A collection of components and middlewares to extend the
functionality

Designer (UI)
Try:
http://www.krakend.io/designer/
- No coding required
- The UI produces a
configuration file ready to
serve

How KrakenD works?
KrakenD uses two different states: building and working.
Building: When the service is initially being prepared to serve the requests,
prepares all the middlewares and defines the pipes. Each pipe is binded to an
endpoint via their outer common interface, resulting in a HTTP handler function.
Only when the configuration is parsed and the service being prepared.
Working: The router maps every request to a HTTP handler function and triggers
the pipe execution. As HTTP handler functions are built in the previous step,
KrakenD doesn't penalize the performance depending on the number of endpoints
or the possible cardinality of the URI requested by the users.

Architecture from
30.000ft

Composed of a set of go packages designed as building
blocks to create pipes and processors between an exposed
endpoint and one or several backends resources
CONFIG ROUTER PROXY

Components
Service definition Endpoints exposed
to the clients
Processing and
backend interaction
CONFIG ROUTER PROXY

The config package
The config package defines the entire service.
In the building stage, all the pipes are defined, with their tasks, helpers and
generators. Each pipe will be binded to an endpoint via their outer common
interface, resulting in a HTTP handler function.

The router package
The router layer is responsible for setting up the HTTP(S) services, binding the
endpoints defined by the config and transforming the HTTP request into proxy
requests before delegating the task to the inner layer (proxy).
When the internal proxy layer returns a response, the router layer converts it into a
proper HTTP response and sends it to the user.
This layer can be easily extended in order to use any HTTP router, framework or
middleware. Adding transport layer adapters for other protocols (Thrift, gRPC,
AMQP, NATS, etc) is in the roadmap.

The proxy package
Where most of the KrakenD components and features are placed. It defines two
important interfaces, designed to be stacked:
● Proxy is a function that converts a given context and request into a response.
● Middleware is a function that accepts one or more proxies and returns a single
proxy wrapping them.
This layer transforms the request received from the router into a single or several
requests to your backend services, processes the responses and returns a single
response.

Middlewares
Middlewares generate custom proxies that are chained depending on the workflow
defined in the configuration until each possible branch ends in a transport-related
proxy.
Each of these generated proxies is able to transform the input or even clone it
several times and pass it or them to the next element in the chain.
They can modify the received response or responses adding all kinds of features to
the generated pipe.

Middleware examples (open source)
● Balancing: uses some type of strategy for selecting a backend host to query.
● Concurrent: improves the QoS by sending several concurrent requests to the
next step of the chain and returning the first successful response using a
timeout for canceling the generated workload.
● Logging: logs the received request and response and also the duration of the
segment execution.

Middleware examples (open source)
● Merging: a fork-and-join middleware. Splits the process of the request into
several concurrent processes, each one against a different backend, and to
merge all the received responses from those created pipes into a single one. It
applies a timeout, as the concurrent one does.
● HTTP: completes the received proxy request by replacing the parameters
extracted from the user request in a defined URL Pattern.
● More middlewares and components:
https://github.com/devopsfaith/krakend-contrib

Live demo

KrakenD Playground
https://github.com/devopsfaith/krakend-playgroun
d

Get it
KrakenD:
http://www.krakend.io/download/
- Source code (compile yourself)
- Tarball
- Debian package
- RPM package
- Docker image
- Brew Formula

Install and run
Mac:
brew install krakend
krakend run -c krakend.json
---
Linux:
docker pull devopsfaith/krakend
docker run -p 8080:8080 -v $PWD:/etc/krakend/ devopsfaith/krakend

Give us a star if you like the project!
https://github.com/devopsfaith/krakend/stargazers