JAXenter: At APICon 2018, you will have a talk about microservices and API gateways. Let’s start with the latter — What is an API gateway and how does it work?

Jussi Nummelin: An API gateway provides a single, unified API entry point across one or more internal APIs. Rather than invoking different services, clients simply talk to the gateway. In other words, it insulates the clients from how the application is partitioned into microservices. It also adds an additional layer of protection by providing protection from attack vectors.

JAXenter: How does an API gateway influence the development of microservices?

Jussi Nummelin: The API gateway enables support for mixing communication protocols and decreases microservice complexity by providing a single point to handle cross-cutting concerns such as authorization using API tokens, access control enforcement, and rate limiting.

JAXenter: What advantages does an API Gateway bring to microservices?

Jussi Nummelin: The biggest advantage is the ability to handle cross-cutting concerns in a single layer rather than having to implement rate limiting and such in each service separately. The second big benefits is that API Gateway hides all your internal microservice architecture completely from the clients. The clients do not see each microservice, they just see single point of access for many APIs.

JAXenter: You are specialized in container orchestration. How does an API gateway help you in your daily work with containers?

Jussi Nummelin: We’re running an API Gateway a spart of our hosted offering, Kontena Cloud. It helps us to handle for example authentication and authorization in a single place rather than having to implement those in each microservice separately. It also allows us to move some of the APIs around without any changes needed on the client side. All the implementation details are „hidden“ behind the API Gateway.

JAXenter: In your talk, you will show some deployment techniques how to easily manage an API Gateway in the deployment pipelines. Can you give us an example?

Jussi Nummelin: I’ll give a practical example of running two different APIs, configuring an API Gateway in front of them and one way to handle the configuration dynamically during deployment. Everything running in containers and deployed with a container orchestration platform. Kong is used as API gateway component. An example of the dynamic configuration code looks like this:

desc "Register API to Kong"
task register: :environment do
  puts "Starting to register /products API"
  upstream_url = ENV['UPSTREAM_URL'] || 'http://api.products-api.demo-grid.kontena.local:3000/'
  hosts = (ENV['API_HOSTS'] || 'demo-api.kontena.works').split(',')
  # Create products API
  products_api = Kong::Api.find_by_name('products-api')
  unless products_api
    products_api = Kong::Api.create(
      name: 'products-api',
      hosts: hosts,
      uris: ['/products'],
      strip_uri: false,
      upstream_url: upstream_url)
 
    puts "/products API registered succesfully"
  end

hooks:
      post_start:
        - name: sleep
          cmd: sleep 10
          instances: 1
          oneshot: true
        - name: register Kong API
          cmd: bundle exec rails kong:register
          instances: 1
          oneshot: true

These together allow me to configure everything pretty dynamically and also automatically during the deployment.

JAXenter: Thank you!

The interview was conducted by Marcel Richters