Mashape powers API Driven Software with many leading products including Kong (Open-Source API Gateway), Galileo (API Analytics), Marketplace (API Hub) and Gelato (Dev Portals)

Kong

kong

Microservice architecture is nowadays almost a standard for backend development. An API gateway is an excellent way to connect a group of microservices to a single API accessible to users. API gateways are available from cloud providers such as AWS/Azure/Google Cloud Platform and Cloudflare. Kong is a scalable API gateway built on open source and can be an excellent alternative if you don't want to have your system locked into a particular vendor. This tutorial shows an example using Kong API gateway, , and . The illustration below shows you the final architecture we are going to build in this guide Ory Kratos Ory Oathkeeper The full source code for this tutorial is available on github What we will use gateway can be an excellent solution for an ingress load balancer and API gateway if you do not want vendor lock-in of any cloud API Gateways in your application. Kong uses and Lua. OpenResty extends Nginx with Lua scripting to use Nginx's event model for non-blocking I/O with HTTP clients and remote backends like PostgreSQL, Memcached, and Redis. OpenResty is not an Nginx fork, and Kong is not an Openresty fork. Kong uses OpenResty to enable . Kong OpenResty API gateway features acts like an identity and access proxy for our microservices. It allows us to proxy only authenticated requests to our microservices, so we don't need to implement middleware to check authentication. It can also transform requests, for example, convert session auth into JWT for a back-end service. Oathkeeper is the authentication provider; it handles all first-party authentication flows: username/password, forgot password, MFA/2FA, . It also provides OIDC/social login capabilities for example, "Login with GitHub". Kratos and more Building simple microservices Let's say we have two microservices: and . They are pretty simple and serve only to test our API gateway, but you can switch them out for more complex components. hello world The "World" microservice exposes a API endpoint and returns a simple JSON message: /world package main

import (
	"encoding/json"
	"log"
	"net/http"
)

type Response struct {
	Message string `json:"message"`
}

func helloJSON(w http.ResponseWriter, r *http.Request) {
	response := Response{Message: "World microservice"}
	w.Header().Set("Content-type", "application/json")
	w.WriteHeader(http.StatusOK)
	json.NewEncoder(w).Encode(response)
}
func main() {
	http.HandleFunc("/world", helloJSON)
	log.Fatal(http.ListenAndServe(":8090", nil))

} The "Hello" microservice exposes a API endpoint and returns a simple JSON message: /hello package main

import (
	"encoding/json"
	"log"
	"net/http"
)

type Response struct {
	Message string `json:"message"`
}

func helloJSON(w http.ResponseWriter, r *http.Request) {
	response := Response{Message: "Hello microservice"}
	w.Header().Set("Content-type", "application/json")
	w.WriteHeader(http.StatusOK)
	json.NewEncoder(w).Encode(response)
}
func main() {
	http.HandleFunc("/hello", helloJSON)
	log.Fatal(http.ListenAndServe(":8090", nil))

} We now want to secure access to these microservices and let only authenticated users access these endpoints. Okay. Let's start hacking, shall we? Ory Kratos setup Follow the guide to set up Ory Kratos. In this tutorial, you only need a docker-compose file with the following configuration: Quickstart postgres-kratos:
    image: postgres:9.6
    ports:
      - "5432:5432"
    environment:
      - POSTGRES_USER=kratos
      - POSTGRES_PASSWORD=secret
      - POSTGRES_DB=kratos
    networks:
      - intranet

  kratos-migrate:
    image: oryd/kratos:v0.8.0-alpha.3
    links:
      - postgres-kratos:postgres-kratos
    environment:
      - DSN=postgres://kratos:secret@postgres-kratos:5432/kratos?sslmode=disable&max_conns=20&max_idle_conns=4
    networks:
      - intranet
    volumes:
      - type: bind
        source: ./kratos
        target: /etc/config/kratos
    command: -c /etc/config/kratos/kratos.yml migrate sql -e --yes

  kratos:
    image: oryd/kratos:v0.8.0-alpha.3
    links:
      - postgres-kratos:postgres-kratos
    environment:
      - DSN=postgres://kratos:secret@postgres-kratos:5432/kratos?sslmode=disable&max_conns=20&max_idle_conns=4
    ports:
      - '4433:4433'
      - '4434:4434'
    volumes:
      - type: bind
        source: ./kratos
        target: /etc/config/kratos
    networks:
      - intranet
    command: serve -c /etc/config/kratos/kratos.yml --dev --watch-courier

  kratos-selfservice-ui-node:
    image: oryd/kratos-selfservice-ui-node:v0.8.0-alpha.3
    environment:
      - KRATOS_PUBLIC_URL=http://kratos:4433/
      - KRATOS_BROWSER_URL=http://127.0.0.1:4433/
    networks:
      - intranet
    ports:
      - "4455:3000"
    restart: on-failure


  mailslurper:
    image: oryd/mailslurper:latest-smtps
    ports:
      - '4436:4436'
      - '4437:4437'
    networks:
      - intranet Some notes on the network architecture: HTTP and are the public and admin API's of Ory Kratos. :4433 :4434 HTTP for Mailslurper - a mock Email server. You can get an activation link by accessing . :4436 http://127.0.0.1:4436 HTTP for the UI interface that allows one to start sign-up/login/recovery flows. :4455 After running you can open to test your configuration. docker-compose up http://127.0.0.1:4455/welcome Configuring Ory Oathkeeper Now we can start configuring our gateways for this example. Kong is the entry point for the network traffic. Ory Oathkeeper would be accessible from the internal network only in this case. Let's review our architecture diagram from before: Oathkeeper checks sessions and proxies traffic to our microservice while Kong provides ingress load balancing. We can even set up to have a more robust configuration for our service. Here is how we configure the access rules for Ory Oathkeeper: Round-Robin DNS -
  id: "api:hello-protected"
  upstream:
    preserve_host: true
    url: "http://hello:8090"
  match:
    url: "http://oathkeeper:4455/hello"
    methods:
      - GET
  authenticators:
    -
      handler: cookie_session
  mutators:
    - handler: noop
  authorizer:
    handler: allow
  errors:
    - handler: redirect
      config:
        to: http://127.0.0.1:4455/login
-
  id: "api:world-protected"
  upstream:
    preserve_host: true
    url: "http://world:8090"
  match:
    url: "http://oathkeeper:4455/world"
    methods:
      - GET
  authenticators:
    -
      handler: cookie_session
  mutators:
    - handler: noop
  authorizer:
    handler: allow
  errors:
    - handler: redirect
      config:
        to: http://127.0.0.1:4455/login The Ory Oathkeeper configuration: log:
  level: debug
  format: json

serve:
  proxy:
    cors:
      enabled: true
      allowed_origins:
        - "*"
      allowed_methods:
        - POST
        - GET
        - PUT
        - PATCH
        - DELETE
      allowed_headers:
        - Authorization
        - Content-Type
      exposed_headers:
        - Content-Type
      allow_credentials: true
      debug: true

errors:
  fallback:
    - json

  handlers:
    redirect:
      enabled: true
      config:
        to: http://127.0.0.1:4455/login
        when:
          -
            error:
              - unauthorized
              - forbidden
            request:
              header:
                accept:
                  - text/html
    json:
      enabled: true
      config:
        verbose: true

access_rules:
  matching_strategy: glob
  repositories:
    - file:///etc/config/oathkeeper/access-rules.yml

authenticators:
  anonymous:
    enabled: true
    config:
      subject: guest

  cookie_session:
    enabled: true
    config:
      check_session_url: http://kratos:4433/sessions/whoami
      preserve_path: true
      extra_from: "@this"
      subject_from: "identity.id"
      only:
        - ory_kratos_session

  noop:
    enabled: true

authorizers:
  allow:
    enabled: true

mutators:
  noop:
    enabled: true Ory Oathkeeper now looks up a valid session in the request cookies and proxies only authenticated requests. It redirects to login UI if there's no cookie available. ory_kratos_session Adding Kong Now all that is needed is to configure Kong: services:
  kong-migrations:
    image: "kong:latest"
    command: kong migrations bootstrap
    depends_on:
      - db
    environment:
      <<: *kong-env
    networks:
      - intranet
    restart: on-failure

  kong:
    platform: linux/arm64
    image: "kong:latest"
    environment:
      <<: *kong-env
      KONG_ADMIN_ACCESS_LOG: /dev/stdout
      KONG_ADMIN_ERROR_LOG: /dev/stderr
      KONG_PROXY_LISTEN: "${KONG_PROXY_LISTEN:-0.0.0.0:8000}"
      KONG_ADMIN_LISTEN: "${KONG_ADMIN_LISTEN:-0.0.0.0:8001}"
      KONG_PROXY_ACCESS_LOG: /dev/stdout
      KONG_PROXY_ERROR_LOG: /dev/stderr
      KONG_PREFIX: ${KONG_PREFIX:-/var/run/kong}
      KONG_DECLARATIVE_CONFIG: "/opt/kong/kong.yaml"
    networks:
      - intranet
    ports:
      # The following two environment variables default to an insecure value (0.0.0.0)
      # according to the CIS Security test.
      - "${KONG_INBOUND_PROXY_LISTEN:-0.0.0.0}:8000:8000/tcp"
      - "${KONG_INBOUND_SSL_PROXY_LISTEN:-0.0.0.0}:8443:8443/tcp"
      - "127.0.0.1:8001:8001/tcp"
      - "127.0.0.1:8444:8444/tcp"
    healthcheck:
      test: ["CMD", "kong", "health"]
      interval: 10s
      timeout: 10s
      retries: 10
    restart: on-failure:5
    read_only: true
    volumes:
      - kong_prefix_vol:${KONG_PREFIX:-/var/run/kong}
      - kong_tmp_vol:/tmp
      - ./config:/opt/kong
    security_opt:
      - no-new-privileges

  db:
    image: postgres:9.6
    environment:
      POSTGRES_DB: kong
      POSTGRES_USER: kong
      POSTGRES_PASSWORD: kong
    healthcheck:
      test: ["CMD", "pg_isready", "-U", "kong"]
      interval: 30s
      timeout: 30s
      retries: 3
    restart: on-failure
    networks:
      - intranet

  hello: The docker-compose creates three containers db container with PostgreSQL database to store the configuration of services/routes for our API gateway. kong-migrate to run migrations against the database. kong container that exposes port for proxying traffic and port with admin API. 8000 8001 As the last step, we need to create a service for Kong and configure routes. #!/bin/bash

# Creates an secure-api service
# and proxies network traffic to oathkeeper
curl -i -X POST \
  --url http://localhost:8001/services/ \
  --data 'name=secure-api' \
  --data 'url=http://oathkeeper:4455'

# Creates routes for secure-api service
curl -i -X POST \
  --url http://localhost:8001/services/secure-api/routes \
  --data 'paths[]=/'\ Testing You can open or in your browser and there are two possible scenarios: http://127.0.0.1:8000/hello http://127.0.0.1:8000/world You receive (or ). {"message": "Hello microservice"} "World microservice" The browser redirects you to . http://127.0.0.1:4455/login Further steps mutator to have the identity accessible as JWT token for your microservices. Configure id_token the password policy to better suit your use case. Configure . Add two-factor authentication Consider using instead of having an additional reverse proxy inside your network. authentication based on subrequest result can be an excellent plugin to use oathkeeper as a decision API for Kong. Kong auth request

Secure Microservices with Kong and Ory

Since 2003, I have used as my primary tool for developing applications and services. Nineteen years ago, I was impressed both by the small amount of RAM required to use the IDE and the refactoring abilities included with the 1.x release. IntelliJ Developing in Java does not require me to use the IntelliJ IDEA product. Other developers on my current project use Eclipse or VS Code, but these tools are not required. When you can write your components, services, and applications with a simple text editor and terminal session, you’ll end up with the same compiled Java code. So, why do I spend the money on IntelliJ every year? Because IntelliJ IDEA is designed to make things easier for developers—which equates to me being far more productive. For example, right-clicking on a class provides me with the option to relocate the class in a matter of seconds. When IntelliJ finds an opportunity to remove duplicate code, it creates the new shared code and correctly updates the locations that depend on the centralized method. IntelliJ is an excellent source of validation during code reviews too. While this example might seem a little elementary, I wonder why more software engineers are not taking a similar approach when building their services. Spring Boot Services and Kubernetes Let’s assume your feature team has standardized the use of for API services. As a result of your team’s hard work and detailed design, your APIs are viewed as successful by public consumers. Your organization decides to use for these services. Spring Boot Kubernetes For each Spring Boot service your team develops, this is what the high-level lifecycle looks like: A Spring Boot service is initialized, and custom code is added. That service is containerized into a image, which is ultimately deployed into Kubernetes. Docker By using Kubernetes, we get the following advantages: A collection of Spring Boot-base Docker containers are placed into a “Pod” to act as a single application. This allows each Spring Boot service to be laser-focused on a given aspect of the resulting API. One or more Pods can be grouped to form the resulting API service, which can be configured for discoverability, observability, horizontal scaling, and load balancing. Rolling updates and canary deployments are utilized to lead to a stable consumer experience. If you are interested in using Kubernetes with Spring Boot, check out the following URL: Spring Boot Kubernetes Based on the success of these popular APIs, let’s imagine that executive leadership would like to monetize the services to gain revenue from the most active consumers. A free tier will still be available, but limits on API usage will be introduced. While the team could implement some custom logic at the Spring Boot level, this does not make sense. What we need is a centralized way to handle this new requirement. Kong Ingress Controller to the Rescue Last year, I started getting familiar with the product suite as part of a long-term solution state for one of my clients. The scenario I described above mirrors situations I have encountered over the last five years: Centralizing common components is key for a successful microservices implementation. Kong If you want to read more about Kong, check out my publication from last May: How I Stopped Coding Repetitive Service Components with Kong For the use case mentioned above, we could handle the following components at the API gateway level: Application registration (key-auth) Rate limiting Centralized logging Since Kong Gateway is open source and a “leader” in the 2021 Gartner Magic Quadrant for Full Lifecycle API Management, Kong Gateway is a safe way to handle these common components. Knowing that Kong also provides an ingress controller for use within Kubernetes further validates the product decision. You can find everything you need to get started with Kong Ingress Controller (KIC) on this GitHub page: Kong Ingress Controller for Kubernetes The illustration below shows the desired design for the two services: Requests arrive at Kubernetes for API Service #1 or #2. The Kong Ingress Controller intercepts the requests and validates the API key provided. Based on that information, the controller determines if the consumer making the request has exceeded its request limit. If the rate limit has not been exceeded, the request is forwarded to the appropriate service. However, if the rate limit is exceeded, then a 429 (Too Many Requests) HTTP response will be returned. In all cases, the logging module can be easily configured to track all incoming requests, including all the metadata being provided by the API consumer. The Value of This Design When we take a step back and look at the resulting architecture and design, we quickly see the benefits: Spring Boot services are true microservices, each laser-focused on a single aspect of the API. Docker allows the Spring Boot services to be self-contained and distributed at any point within the development lifecycle. Kubernetes provides the ability to group those purpose-driven Docker images into Pods, which act as a single application. Those Pods are then grouped to surface as API services in our example. Shared components—like application registration, rate limiting, and logging—exist in one centralized location within Kong Gateway. Kong Ingress Controller becomes the middleware layer between Kong Gateway and Kubernetes to leverage all shared components. As a result of this model, feature team developers working on Spring Boot services only need to focus on the work provided by their product owner to improve or extend the service. These developers do not need to worry about API keys, rate limiting, or any other shared component managed elsewhere. DevOps engineers supporting the Kubernetes implementation do not have to architect any custom design aspects to handle those shared components either. That’s because Kong Gateway is built to accommodate those needs and works well via the Kong Ingress Controller. Conclusion Since 2021, I have been trying to live by the following mission statement, which I feel can apply to any IT professional: “Focus your time on delivering features/functionality which extends the value of your intellectual property. Leverage frameworks, products, and services for everything else.” - J. Vester At the start of this post, I talked about how I prefer IntelliJ IDEA over a text editor and terminal session. In reality, the core reason ties directly to my personal mission statement. The IDEA product allows me to focus on the right things; meanwhile, it handles the repetitive tasks related to writing original source code. Similarly, Spring, Docker, Kubernetes, and Kong have provided solutions and frameworks to work toward the same mission. Every aspect noted above can be traced to a single source of truth for a given item. As a result, there is no duplication of services or functionality across the application landscape. If you find yourself implementing the same process a second time, it is certainly time to consider refactoring your design. If your service tier falls into a similar modal as I’ve discussed here and you are not utilizing Kong Gateway or Kong Ingress Controller, they should certainly be on your shortlist of products to review when you are ready to refine your service design. Have a really great day!

How to Use Kong Ingress Controller with Spring Boot Services

Cómo usar el controlador Kong Ingress con Spring Boot Services

Many developers and DevOps engineers have been deploying in front of their -based applications. While the extensive library of can add a lot of flexibility and power to your deployments, you might encounter the occasional use case where you need a custom plugin that’s just not found in the library. Kong Gateway microservices built-in plugins Fortunately, you can use Go to create and run plugins for Kong Gateway. This post will cover how to get set up for writing Kong plugins. We’ll look at the parts of the request/response lifecycle that you can tap into, and we’ll walk through an example of how to put it all together. Custom plugins for Kong are achievable using a Go-specific plugin server that uses the sidecar model to load and run a plugin written in Go dynamically. Communication between the plugin and the plugin server is done through a Unix domain socket. Luckily, all of this is made simple through Kong’s (PDK). Go Plugin Development Kit Why would you write your own plugin? Ultimately, the ability to write your own Go plugin and integrate it with Kong Gateway provides nearly limitless flexibility during the request and response lifecycle. A classic example would be simple request and response enrichment: Imagine adding or removing headers to influence request routing or incorporating customized request validation or logging requests for auditing. Harnessing Kong Gateway’s power while building in custom gateway logic for your unique business case gives you the best of both worlds. Enough talk. Let’s get to it. Development setup For this example, we’ll assume that you have already done the following: Installed Go locally on your machine. Installed Kong to manage the service configuration, though you can also configure Kong using the Admin API. Installed decK The first step for environment setup is to create a directory and our Go mod file: $ mkdir kong-go-plugin
$ cd kong-go-plugin/
~/kong-go-plugin$ go mod init kong-go-plugin
go: creating new go.mod: module kong-go-plugin Next, we run and to build the plugin server: go get go build ~/kong-go-plugin$ go get -d -v github.com/Kong/go-pluginserver
go: downloading github.com/Kong/go-pluginserver v0.6.1
go: downloading github.com/Kong/go-pdk v0.6.0
go: downloading github.com/ugorji/go v1.2.1
go: downloading github.com/ugorji/go/codec v1.2.1
go get: added github.com/Kong/go-pluginserver v0.6.1
~/kong-go-plugin$ go build github.com/Kong/go-pluginserver By default, Kong expects to be in , but you can modify this behavior by changing the value for in your Kong configuration. For the sake of consistency, let’s move the newly built binary to the default location. go-pluginserver /usr/local/bin go_pluginserver_exe ~/kong-go-plugin$ sudo mv go-pluginserver /usr/local/bin/ One other default that we’ll want to modify is which defaults to . This is where Kong looks for our Go plugins. For this example, we’ll use , so if you’re following along, you’ll need to update your configuration to match. go_plugins_dir off $HOME/goplugins/ Before diving into the code, one last thing is that consistency issues can occur. They normally manifest as error messages like the following: failed to open plugin kong: plugin.Open("/path/go-plugins/myplugin"): plugin was built with a different version of package github.com/Kong/go-pdk/bridge If you do run into that message, check out the documentation for more info on possible root causes. Now that we set up our development environment, we can start coding our plugin! here Coding time! Our next step is to write the plugin and verify it works as expected. We’ll start with a simple bit of code to add a header to a response. If you’re following along, you can copy this directly into a file called : goplug.go package main

import (
	"github.com/Kong/go-pdk"
)

type Config struct {
	Attach bool
}

func New() interface{} {
	return &Config{}
}

func (c *Config) Access(kong *pdk.PDK) {
	if c.Attach {
		kong.ServiceRequest.SetHeader("x-goplug", "Set by custom go plugin")
	}
} If you’ve worked with Go before, this should be pretty straightforward. That said, you can find more details in the . The documentation explains the structs and functions, and it provides a full list of the phases you can tap into. We’re using the phase at this point, so we can attach the header before it gets proxied to the upstream service. This is useful in cases where you want to add data to the response based on some incoming criteria that the upstream service can use. Kong Go Plugin Documentation Access Next, we need to build our plugin and “install” it with go build -buildmode plugin goplug.go && mv goplug.so ~/goplugins/ After that, we restart Kong to ensure it has picked up our new plugin. ~/kong-go-plugin$ sudo kong restart Now, our plugin is loaded and ready to use, but we still need a service to use it on. I’ve used and added the following to a file to test out the plugin. All you need to do is run once you’ve created the file. decK kong.yaml deck sync kong.yaml _format_version: "1.1"
services:
- host: mockbin.org
  name: example_service
  port: 80
  protocol: http
  plugins:
  - name: goplug
    config:
      attach: true
  routes:
  - name: mocking
    paths:
    - /mock
    strip_path: true With our plugin loaded and service created, we’re ready for a test. Simply make a curl request to the service and we’ll see the plugin in action! ~/kong-go-plugin$ curl -s  -i -X GET http://localhost:8000/mock/request \
| grep "x-goplug"
x-goplug: Set by custom go plugin Success! For good measure, let’s tie into one more phase of the request and response lifecycle. In this next function, we’ll tap into the phase to add a debugging header in case our plugin runs into issues. Response func (c *Config) Response(kong *pdk.PDK) {
	v := runtime.Version()
	kong.Response.AddHeader("x-goplug-go-version", v)
} Add the above function to , then repeat the process to rebuild the plugin. Next, restart Kong. When we rerun our curl command, we see that is included with the request to the upstream service, but it is removed before sending a response back to the client. goplug.go x-goplug $ curl -s -i -X GET http://localhost:8000/mock/request \
| grep "x-goplug-go-version"
x-goplug-go-version: go1.16.5 Let’s draw some parallels to real-world applications. We’ve shown here how you can take data from a request and turn that into actionable information, ready to be processed by an upstream service fronted by Kong Gateway. What’s even better is that all of this background work is transparent to the client. We’ve also shown how you can modify the response to the client. With this ability, you can ease troubleshooting or even pass back rate-limiting data (such as the number of remaining API requests per day or per hour) to keep your customers informed of their utilization. Wrap up In this post we’ve covered a lot, so let’s wrap it up with a brief review. Here’s what we’ve covered: What you need to develop Go plugins for use with Kong Gateway Why you might build a custom plugin rather than use a plugin that’s built-in with Kong Gateway Set up a local development environment that supports creating Go-based Kong plugins Used that local development environment to tap into the request/response lifecycle to modify the data on the fly Now that the process is down, it’s easily repeatable for whatever use case you may have for Go-based Kong plugin development. You can find the Kong documentation for Go support on along with some other . Kong’s website examples and walkthroughs

Kong Plugins as Microservices: Writing a Single-Plugin Server for Kong in Go

Insomnia is a desktop app from that’s great for building, debugging, and testing backend APIs. While ad hoc manual testing is nice, wouldn’t it be even better to include our API tests in our continuous integration (CI) pipelines? With Inso, Kong Insomnia’s CLI tool, we can! Kong Inso allows you to run your automated API tests directly from the command line, which means setting up a workflow with GitHub Actions is a snap. In this article, we’ll create a simple server with Node.js and , write API tests using , and then run these tests in our CI pipeline with and . Express Kong Insomnia Inso GitHub Actions Demo App: A Nintendo Game Database We’ve built a game database that contains info about every game ever published. The app is a server that implements a REST API with endpoints to get data about the games, categories, developers, publishers, and release years. NES You can . find the complete code on GitHub Using Kong Insomnia for Manual Testing While developing an API, rapid feedback cycles help ensure your API works the way you want and returns the data you expect. Kong Insomnia is perfect for this kind of ad hoc testing. To get started with our NES game API, we created a new inside Kong Insomnia. We left the information in the Design tab blank and headed over to the Debug tab to start making requests. Below, we have requests for each API endpoint our server provides. We can run each request inside Kong Insomnia, and the resulting data is displayed in the UI. Design Document Writing Tests with Kong Insomnia Manually hitting our API endpoints is great for ad hoc testing and debugging, but ultimately what we want is an automated test suite that ensures our app is behaving correctly. in the Test tab within the desktop app. Kong Insomnia allows you to write tests The tests are written by selecting one of the requests from the Debug tab and then making assertions about the data the server returns. You can run individual tests or an entire suite of tests. As you can see below, we’ve written tests for each of our API endpoints for a total of 11 tests in our test suite. These tests (and the information in our Design Document) can be synced with Git and included in our code repo. That way, anyone with the Kong Insomnia desktop app can also run these requests and tests. To , simply click the “Setup Git Sync” button at the top of the app. sync Kong Insomnia with Git From there, you can provide the relevant details to connect Kong Insomnia with your project’s Git repo. Syncing Kong Insomnia with your Git repo requires an authentication token. You can easily within your account settings in GitHub. create a personal access token Running Tests from the Command Line with Inso We now have a set of requests and a suite of tests within Kong Insomnia that help us with our debugging and testing. But we haven’t automated the running of these tests yet, so let’s do that now. This is where Kong Insomnia’s CLI, Inso, comes into play. Inso is installable as an npm package, so we’ve added that as a dev dependency to our project: . yarn add --dev insomnia-inso To make running our test suite simple, we’ve created an npm script in our file. The following script : . That means we can simply run to run our tests from the command line any time we want. package.json runs our tests with Inso "test": "inso run test \"NES Games API Test Suite\"" yarn test Integrating Inso with GitHub Actions Now for the culmination of everything we’ve set up so far: running our automated tests as part of a continuous integration pipeline. It’s nice that we can run our tests from the command line, but right now, we don’t have them running automatically for us anywhere. We really want our test suite to be run on every new pull request. Doing so will ensure that the tests pass before merging any new code into the master branch. This is continuous integration at its finest. allow us to configure any continuous integration we’d like by using YAML files. We’ve created a directory and a file inside it. This file is reproduced in full below: GitHub Actions .github/workflows unit-tests.yml name: NES Games API CI

on:
  push:
    branches:
      - master
  pull_request:
    branches:
      - master

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout branch
        uses: actions/checkout@v2

      - name: Use Node.js 14.x
        uses: actions/setup-node@v2
        with:
          node-version: 14.x
          cache: 'yarn'

      - name: Install dependencies
        run: yarn install --frozen-lockfile

      - name: Start server and run unit tests
        run: yarn ci:start-and-test As you can see, our workflow checks out our current branch, uses Node v14, installs our dependencies with yarn, and then runs a custom script to start our app’s server and run the API tests. This workflow is triggered whenever code is pushed to the master branch or a new pull request is opened against the master branch. This script is another npm script we’ve added to our file. Using the npm packages and , we use this script to start our server, run the API tests, and then kill the server once the tests finish. The full list of npm scripts in our file is reproduced below: ci:start-and-test package.json wait-on concurrently package.json "scripts": {
  "ci:start-and-test": "concurrently -k -s=first \"yarn start\" \"yarn ci:test\"",
  "ci:test": "wait-on http://localhost:3000 && yarn test",
  "format": "prettier --write .",
  "format-watch": "onchange . -- prettier --write {{changed}}",
  "start": "node index.js",
  "test": "inso run test \"NES Games API Test Suite\""
}, And now, we have a beautiful working CI pipeline! We can test that everything is working properly by creating a small pull request in our repo. After making the pull request, we can see that our CI pipeline is running: If we click the Details button to see more info, we can see the individual steps of our workflow being run: Once the job passes, the results are reported back to the pull request as seen below: We did it! All checks have passed. The last thing we could do for completeness is require that all checks pass in GitHub before pull requests can be merged. We can do this in the repo’s settings within GitHub: If you’d like to explore another potential CI setup, the Kong team also has their own you can use that installs Inso as part of a job in the CI pipeline with their . example workflow setup-inso GitHub Action Conclusion So, what have we accomplished today? Quite a lot, actually! We’ve created a server using Node.js and Express. We’ve created ad hoc requests within Kong Insomnia to help with the development and debugging of our API. We’ve written tests inside Kong Insomnia and learned to run them from the command line using Inso. And finally, we’ve created a CI pipeline with GitHub Actions to run our API tests as part of every pull request for our repo. Kong Insomnia, Inso, and GitHub Actions have worked together to help us develop our app with confidence. Our continuous integration pipeline has prepared us to deploy our app at any time. Success! To go further, we could merge this workflow into a broader strategy for managing the entire API development lifecycle — design and development within Kong Insomnia, deployment with Inso integrated with our CI pipeline, and management and maintenance with a tool like . Kong Gateway Thanks for reading, and happy coding!

CI for APIs with the Kong Insomnia CLI and GitHub Actions

There are events in our life that seem to be just routine, but then unexpectedly, they have a profound impact on our journey. For me, one event was attending the 2008 Gartner conference in Orlando, Florida. That event not only introduced me to the Salesforce ecosystem for the very first time but also to concepts like: (via an impressive session by Roy Schulte) Service-Oriented Architecture and Web 2.0 Mashups RESTful API Design While I had modest expectations for the event, those few days in central Florida became a key aspect of focus for the next 13 years of my career, far exceeding any expectations I could have ever imagined. Along the way, I learned many lessons from projects and initiatives focused on these very concepts. In this article, I will dive into several lessons learned from projects that placed RESTful APIs at the core of an application’s design. The RESTful API Pitfalls The RESTful API software style provides an easy manner for client applications to gain access to the resources (data) they need to meet business needs. In fact, it did not take long for Javascript-based frameworks like Angular, React, and Vue to rely on RESTful APIs and lead the market for web-based applications. This pattern of RESTful service APIs and frontend Javascript frameworks sparked a desire for many organizations to fund projects migrating away from monolithic or outdated applications. The RESTful API pattern also provided a much-needed boost in the technology economy, which was still recovering from the impact of the . Great Recession Fast-forward several agile iterations into this new development paradigm, and two pitfalls have been repeatedly encountered more than they have been avoided: An outdated application design was ultimately replaced with a very large RESTful API and an equally large Javascript framework. This created challenges with coordinating future features and enhancements; basically, one monolith was replaced by another. A legacy application design employed multiple RESTful APIs and componentized clients utilizing Javascript frameworks, but a single database was utilized. The result of this design led to data ownership conflicts, a higher-than-expected number of database connections, and higher costs to support/maintain a large database. Below is an example of how pitfall #2 played out, with several services competing for resources from a single database: Unfortunately, I have also seen these same scenarios with greenfield development opportunities, where there is a preference to use a single database for an entire collection of microservices. Microservices Should Begin With the Database In most programming languages, it is possible to create a fully functional application using a single file. In Java, everything could be in the same class file and stemmed from simply calling the method: main() public class SingleClassApplication {
    public static void main(String[] args) {
        // Start doing something really cool here
    }
} However, this approach is not very supportable, nor does it facilitate easy contribution from multiple developers. There is also the concept of “ownership” (or system of record) when it comes to aspects of an application. In cases where more than one service or function claims to be the owner of something (like a customer), challenges arise when business rules differ. The same scenario can occur when multiple RESTful APIs claim ownership of a given object. These same concepts translate to the database layer when employing a RESTful API design. Consider the following guideline: A single RESTful API should be considered the system of record for a given aspect of the application. As such, the corresponding data tier should leverage a data store focused solely on that aspect of the application. The illustration below provides a microservices design that adheres to this guideline: A successful microservice design begins with the database. Once in place, scaling to meet customer demand for the given service does not have an impact on any other service. Counterpoint: What About Database Constraints? My recommended approach is to isolate a given microservice with a dedicated database. This allows the count and size of the related components to match user demand while avoiding additional costs for elements that do not have the same levels of demand. Database administrators are quick to defend the single-database design by noting the benefits that constraints and relationships can provide when all of the elements of the application reside in a single database. As an example, a single database design can prevent a request to remove a customer if there are orders associated with the customer queued for deletion. While that is definitely a benefit to having a single database, consider the following points before opting to utilize a single database for all microservices: Compare the long-term value gained by using a single database with the associated costs for scaling a single, large database. What is the expected cost to scale and support a single database design in the future? What is the risk and value of having these constraints enforced at the API layer instead?  Keep in mind that a single microservice would be considered the owner of a given database, so the business logic would not allow things like deleting a customer with active orders. Consider the benefits of using an event-driven (or message-based) design to handle the situations where how one microservice handles a request depends on the response from another microservice. While this is similar to a single application/single database design, the ability to scale and allocate dedicated processing power when needed can be isolated and controlled. Certainly, constraints and relationships should be implemented and enforced, even when the database supports only a dedicated service instance. Common Elements Should Be Abstracted Adopting a true microservices design can lead to side effects if not planned appropriately. The biggest challenge I continue to see is the duplication of common components and the service-tier layer. The list below provides examples of elements that are often duplicated inside each microservice: authentication caching logging monitoring security In fact, consider this illustration, which I introduced in my “ ” article earlier this year. Use the Kong Gateway to Stop Coding Repetitive Service Components Like all aspects of the development lifecycle, we should always focus on keeping things as (don’t repeat yourself) as possible. This includes elements that can be abstracted and processed at a common level or a different level of the application stack. DRY One approach I often recommend is a distributed microservices abstraction layer approach provided by . Kong Placing Kong at the Center of the Ideal Design allows the complexity of service-tier APIs to be reduced to a collection of endpoints (or URIs) focused on meeting a collection of business needs and functionality. Often-duplicated components (like authentication, logging, and security) are handled by the gateway and can be removed from the service-tier design. Kong Gateway With each RESTful microservice maintaining a dedicated database instance and the duplicate components abstracted, a collection of purpose-driven microservices would appear as illustrated below: Inter-service communication is handled via a messaging tier utilizing common , such as: enterprise integration patterns - invoke another service to perform a background action Command Message - request information from another service Document Message - broadcast information to anyone listening on a given topic Event Message - make a request to another service and listen for a response Request-Reply With this design in place, consider some real-life benefits: If the Node.js service experiences higher-than-expected usage, the cost to scale up to meet demands is isolated to the service and dedicated database. If any single service realizes that a data store change is preferred (such as SQL to NoSQL), the new design can be deployed with little (if any) impact on any of the other services—provided the RESTful API URIs are not changed. A change in any of the abstracted layer components (for example, using a new logging approach) can be made at the Kong Gateway layer and have no impact on the underlying services. Conclusion Starting in 2021, I have been trying to live by the following mission statement, which I feel can apply to any IT professional: “Focus your time on delivering features/functionality which extends the value of your intellectual property. Leverage frameworks, products, and services for everything else.” - J. Vester While the primary objective of this article is to move toward a true microservice design that includes a dedicated database, Kong provides core aspects for a true microservice design that are scalable and easy to adopt. In fact, Kong Gateway allows developers to keep things DRY, introducing common components to reside in the distributed microservices abstraction layer. Remember, “microservices” includes the word “micro,” which is often defined as “extremely small.” It is important to keep this basic premise in mind during any microservice implementation. Feature developers utilize packages and classes to group their program code for supportability and maintainability. Within those classes, methods and functions are defined—often employing a rule that each block of code is small and easy to digest. To me, an ideal function or method is one that I can review without ever having to touch my mouse. Microservices should be an extension of the same rules programmers have been following for decades: keep things small, purpose-driven, and efficient … keep things “micro.” To reach that goal, the design must include the database. Have a really great day!

Breaking Up a Monolithic Database with Kong

, take a back seat, there's a new player in town! NGINX For many developers out there, NGINX would be the primary choice for reverse proxy. However at , our API platform for banking integrations, we moved on to something more exciting! Decentro API development has moved from a single stack monolithic architecture to the majestic microservices architecture. This requires a gateway server that should manage redirection, proxying, and security over multiple requests. This means our old faithful NGINX has become a little outdated. (Let’s not even talk about Apache HTTP Server here!) Even if you run a monolithic application, The API Gateway is still a good pick. Apart from proxying, there are many other benefits. The API Gateways should give us the developer the ability to: Scale: As you grow, so should your application Provide security: Applying SSL is just scratching the surface Have a GUI: This would make life 10 times easier Be Intuitive: Should be self-explanatory “ ” But what does it do? You may ask. Good question. Suppose we have an API stack with multiple APIs spanning over a bunch of microservices. Let’s look at the diagram: Here you can see the API Gateway is the lord and the savior for the application instances running behind it. It proxies the requests to the requisite application instance (as a reverse proxy). Now your endpoint can be independent of the microservice it caters to. So if you want to have multiple endpoints (e.g., /docs, /documents, /documentation) connected to the same application, you can. Just reverse proxy it, baby! Farewell, NGINX! Here at Decentro, we used to work with NGINX as our reverse proxy server. But we grew out of it. We had to log in to our instance to reload NGINX via CLI and had to learn to manage configurations when using NGINX. It didn’t have consumer-level handling for API management. We needed something extra. After logging our heads together for quick brainstorming and crossing the Is’ & Ts’ on the Pros/Cons list, we found the one! Dhumm… Dhumm… Dhumm… Did you feel it? Here comes ! KONG Source: Github As is evident from the image above, Kong provides a lot of features out of the box. No recompilation. No command-line configuration. No extra cost. Kong comes with its own RESTful Admin APIs. It is built on top of OpenResty (an extension of NGINX) and LuaJIT. These provide access to all kinds of configurations that can be made available. We have done another addition on top of it by adding the Konga dashboard to manage Kong via a GUI. Kong API Gateway Structure The API structure in Kong is pretty simple. Services – The logical representation of your microservice or monolithic application Routes – The logical representation of endpoints that are accessible within the service. Consumers – The clients that are going to be using the services.Plugins – This is where the magic happens. Plugins can be applied to either of the above entities mentioned. So let’s talk about an example. We have a microservice that takes care of sending emails.  We'll declare a Service with the name “emails” (Pretty innovative.. yep!). This will contain the details of the application server, which it will reverse proxy for. Now let’s make Routes for this service. So we have two kinds of emails to be sent. Transactional – Sent by the API Marketing – Sent by the marketing department to let the clients know about the new features of our awesome product. Now, we will put an API Key authentication plugin on top of the “emails” service. This will ensure that no bad actors try to get access to our APIs. Rate-limit Plugins We will also add a rate-limit plugin (to limit the number of API hits) on the different routes. Transactional (600 per minute) – Since this API is triggered by other flows, we need a high rate limit. Marketing (1 per minute) – Since this is manually triggered, we don’t need to go beyond 1 per minute In order to further enhance our security, we will allow only certain IP addresses to be able to access our transactional email route as it will be triggered only by our internal systems, and we know the IP address range for our internal systems. We will set it open to the world (Potentially insecure) for the marketing emails as the marketing peeps should be able to access it from any cafe that they wish to work out of. Now we want only authorized consumers to access the APIs, so we will set up a consumer and add the API authentication credentials for them to use. Now our email service is ready to serve consumers. We can integrate it into our code and give it to the marketing peeps for them to use it manually. Wrapping Things Up As you can see, using Kong as an API Gateway is simple and takes the hassle of managing APIs. Kong provides many other features like upstreams, certificate management, request and response transformation, serverless code execution, logging, and CORS, which are very helpful when you wish to develop APIs quickly. NGINX and other reverse proxy servers are simply blown out of the water by the ease of configurability and sheer dexterity that KONG provides out of the box. We rest our case, thus!

Why We Switched from NGINX Is to KONG API Gateway

Por qué cambiamos de NGINX a KONG API Gateway

Kubernetes has become the name of the game when it comes to container orchestration. It allows teams to deploy and scale applications to meet changes in demand while providing a great developer experience. The key to handling modern dynamic, scalable workloads in Kubernetes is a networking stack that can deliver API management, a service mesh and an ingress controller. allows users to manage the routing rules that control external user access to the service in a Kubernetes cluster from the same platform. Kong Ingress Controller This article will look at how you can use for full-stack application deployments with Kubernetes. By full-stack, we mean Kong can handle: Kong Containers Container networking Pod networking Service networking Host networking Load balancing Rate limiting HTTPS redirects Let's get started by creating our cluster. Installing Kind Kubernetes With Kind, you can run local Kubernetes clusters using Docker. It was designed for testing Kubernetes but is perfect for local K8 development like we will do in this example. There are quite a few ways to install Kind, depending on your operating system. If you have a Mac, you can install it quickly with Homebrew: brew install kind If you are on a Windows machine and have Chocolatey installed, the command is just as simple: choco install kind If you have Go and Docker installed, you can run the following command to install kind: GO111MODULE= go get sigs.k8s.io/kind@v0 "on" .10 .0 For more installation options, see the . Kind quickstart Once Kind is installed, you need to create a cluster:: kind create cluster After making the cluster, you can interact with it using kubectl. To list your clusters, run: kind get clusters It should return kind, the default cluster context name. Now run the following to point kubectl to the kind cluster: kind kubeconfig export If you set up Kind correctly, running the following command will give you details about your cluster: kubectl cluster-info Installing Kong Ingress Controller Now that we have a cluster running, we can install Kong quickly by applying the manifest directly with the following command: kubectl create -f https: //bit.ly/k4k8s Now run the following command to get details on kong-proxy: kubectl -n kong get service kong-proxy You will notice that the external IP is still pending. Kind only exposes the Kubernetes API endpoint, and so the service is not accessible outside of the cluster. Since we are using Kind, we will have to run a port forward to do this. This command does not get daemonized, so you will have to open another console window to run other commands. kubectl -n kong port-forward --address localhost, svc/kong-proxy : 0.0 .0 .0 8080 80 Next, we need to set an environment variable with the IP address from where we want to access Kong. This will be localhost since we are using a port forward. PROXY_IP=localhost: export 8080 You can curl the IP now or visit in a browser and should see: { : } "message" "no Route matched with those values" Deploying an Example App Now let's deploy something that will return some results. Kubernetes has multiple example applications available in a . We are going to deploy the with these commands: Github repo Guestbook App kubectl apply -f https: kubectl apply -f https: kubectl apply -f https: kubectl apply -f https: //k8s.io/examples/application/guestbook/mongo-deployment.yaml //k8s.io/examples/application/guestbook/mongo-service.yaml //k8s.io/examples/application/guestbook/frontend-deployment.yaml //k8s.io/examples/application/guestbook/frontend-service.yaml Now, if we run kubectl get services, we will see two new services: We can also query the pods to make sure their status is ‘Running’: kubectl get pods -l app.kubernetes.io/name=guestbook -l app.kubernetes.io/component=frontend To test it, you can run another port forward really quick with: kubectl port-forward svc/frontend : 8000 80 You will find the guestbook running at . We will now set up the Kong Ingress Controller. http://localhost:8000/ Expose the App to the Internet Now we can use the Kong Ingress Controller, so we need to set up a resource to serve traffic. We can create a proxy for our application with the following command: echo | kubectl apply -f - '
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: guestbook
  annotations:
    konghq.com/strip-path: "true"
    kubernetes.io/ingress.class: kong
spec:
  rules:
  - http:
  	paths:
  	- path: /
        pathType: Prefix
        backend:
          service:
            name: frontend
            port:
              number: 80
' Now you will see the guestbook app at . http://localhost:8080/ Using Plugins as Services in Kong With Kong Ingress, we can execute plugins on the service level. That way, Kong will execute a plugin whenever a request is sent to a specific service, no matter which ingress path from where it came. If we want to add rate limits to our app, we can add the rate limiting plugin to our Kubernetes installation with the following command: echo | kubectl apply -f -
kongplugin.configuration.konghq.com/rl-by-ip created "
apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
  name: rl-by-ip
config:
  minute: 5
  limit_by: ip
  policy: local
plugin: rate-limiting
" Once you install the plugin, you can apply the konghq.com/plugins annotation on our Guestbook with the following command: kubectl patch svc frontend \
  -p '{"metadata":{"annotations":{"konghq.com/plugins": "rl-by-ip\n"}}}' If you curl the guestbook app, you will see that rate limiting has been set up. If you plan on testing the Guestbook frequently during this example, you may want to set the limit higher, or you will run into a Kong error that says the rate limit has been exceeded. Configuring an HTTPS Redirect So far, the app is running on HTTP, and we want it to run on HTTPS. If we want to tell Kong to redirect all the HTTP requests, we can update its annotations to HTTPS and issue a 301 redirect with this command to patch the ingress entry: kubectl patch ingress guestbook -p '{"metadata":{"annotations":{"konghq.com/protocols":"https","konghq.com/https-redirect-status-code":"301"}}}' To test this using kind, set up another port-forward with the following command: kubectl -n kong port-forward --address localhost, svc/kong-proxy : 0.0 .0 .0 8443 443 You can now access a "secure" version of the guestbook at . It will not have a certificate, so you will run into warnings in your browser. Let's look at how we can add certificates. https://localhost:8443 Adding the Cert-Manager You can install the cert-manager with the following command: kubectl apply -f https: //github.com/jetstack/cert-manager/releases/download/v1.3.1/cert-manager.yaml Once the images pull down, you can verify that it is running with this command: kubectl get all -n cert-manager You should see something like this: Since we have Kubernetes running locally with a port-forward, the IP address for the Kong proxy is 127.0.0.1. If you weren’t using a port forward, you could run the following command to find the IP address: kubectl get -o jsonpath= service -n kong kong-proxy "{.status.loadBalancer.ingress[0].ip}" But since we are using a port forward, this command will return nothing. If this were in production, you would then set up DNS records to resolve your domain to the IP address you just retrieved. Once that is done, you can request a certificate from Let's Encrypt by running the following, making sure to change the email: echo | kubectl apply -f - "apiVersion: cert-manager.io/v1alpha2
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
  namespace: cert-manager
spec:
  acme:
    email: user@example.com #change this email
    privateKeySecretRef:
      name: letsencrypt-prod
    server: https://acme-v02.api.letsencrypt.org/directory
    solvers:
    - http01:
      ingress:
        class: kong" Next, you will have to update your ingress resource to provide a certificate with the following command, changing the domain to your own: echo | kubectl apply -f - '
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: guestbook-example-com
  annotations:
    kubernetes.io/tls-acme: "true"
    cert-manager.io/cluster-issuer: letsencrypt-prod
    kubernetes.io/ingress.class: kong
spec:
  tls:
  - secretName: guestbook-example-com
    hosts:
    - demo.example.com #change this domain/subdomain
  rules:
  - host: demo.example.com #change this domain/subdomain
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: guestbook
            port:
              number: 80
' Once that is updated, the cert-manager will start to provision the certificate and the certificate will be ready soon. Missing a Tool in Your K8s Stack? Kong may be the missing tool in your Kubernetes stack. can implement authentication, HTTPS redirects, security certificates, and more across all your Kubernetes clusters. Using Kong, you can control your containers, networking, load balancing, rate limiting and more from one platform. It truly is the choice for full-stack ingress deployments. Kong Ingress Controller Also published on: https://dzone.com/articles/kubernetes-full-stack-example-with-kong-ingress-co

How to Use Kong for Full-stack Application Deployments with Kubernetes

It's time to have some fun. Sure, tell your colleagues or your family that you're doing research, experimenting with some new tech—because that is what we'll be doing—but just don't let them see you playing Minecraft! Here's the scenario: You're organizing a full-day class for local STEM students. You need to run your own Minecraft servers to ensure a kid-friendly multiplayer environment, restricted only to your students. One server won't be enough, so you'll run two servers simultaneously, expecting your load balancer to handle sending students to Server A or Server B, depending on the load. Minecraft In this article, we're going to explore port forwarding and load balancing with . We're going to do this by spinning up multiple Minecraft servers, and then placing Kong Gateway in front of these upstream services to handle port forwarding and load balancing. Kong Gateway Before we dive in, let's briefly cover a few important technology concepts. Key Concepts Port Forwarding Port forwarding is receiving network requests on a certain port of a machine and forwarding those requests to a different port. A router, firewall or API gateway usually handles this task. For example, you might have a web server listening on port 3000 and a database server listening on port 5000. Your API gateway would listen for requests from outside your network. Requests addressed to port 80 would be forwarded by the gateway to your web server at port 3000. Meanwhile, requests addressed to port 5432 would be forwarded to your database server at port 5000. Load Balancing Load balancing is the task of distributing multiple requests to a server in a balanced manner across numerous replicas of that server. A specific piece of hardware or software called a load balancer usually handles this. The outside world is unaware that there are multiple replicas of a server running. They believe they’re making requests to a single server. The load balancer, however, distributes the request load to prevent any one server from being overwhelmed. In the case of a replica failing completely, the load balancer ensures that requests only go to healthy nodes. Kong Gateway Kong Gateway is a thin API gateway layer that sits in front of upstream services, capable of performing these port forwarding and load balancing tasks. Whether those upstream services are web servers or databases or even Minecraft game servers, Kong is the front-door greeter to all requests. In addition to traffic control, Kong Gateway can manage , request transformations, analytics, and logging. authentication TCP Stream Support One aspect of our Minecraft project that sets it apart from deploying a typical web server or database is that Minecraft requires an established connection between the Minecraft client (the gamer) and server. Rather than expecting stateless HTTP requests, we'll need to handle TCP connections with streaming data. Fortunately, Kong Gateway fully supports TCP streaming. Our project approach We're going to walk through this project step-by-step: Spin up a single, local Minecraft server without any port forwarding. Spin up a Minecraft server on a non-default port, configuring Kong Gateway to port forward requests to that server. Spin up two Minecraft servers on different ports, configuring Kong Gateway to load balance and port forward connection requests. As you can see, we'll start simple, and we'll slowly build on complexity. What you'll need to get started You don't need a lot of familiarity with Minecraft to progress through this mini-project. Since it’s easiest to spin up Minecraft servers within Docker containers, basic familiarity with Docker may be helpful. actually You will need to on your local machine. Lastly, if you want to test that our project results are successful, you'll need to and log in as a paid owner of the game. The free trial of Minecraft doesn't allow connecting to multiplayer servers, which is what we'll be running for our project. install Docker Engine install the Minecraft game client Are you ready to do this? Here we go! Step 1: Single Minecraft Server with Default Port In this first step, we want to spin up a single Minecraft server on our local machine. We'll use the default port for the server, and then we'll connect our game client to the server. It’s simple to deploy the Minecraft server as a Docker container, with the Docker image found . here In a terminal window, we'll run this command to pull down the server image and spin it up in a container: ~$ docker run -p : -e EULA= itzg/minecraft-server

Unable to find image locally
latest: Pulling itzg/minecraft-server
...

Status: Downloaded newer image itzg/minecraft-server:latest
...

[init] Checking files.
[init] Setting initial memory to G and max to G
[init] Starting the Minecraft server...
...

[Server thread/INFO]: Preparing start region dimension minecraft:overworld
[Worker-Main /INFO]: Preparing spawn area: %
...

[Server thread/INFO]: Done ( s)! For help, type ... 25000 25565 true 'itzg/minecraft-server:latest' from for for JSON 1 1 for -5 1 40.436 "help" As our container starts up, it downloads the Docker image for the Minecraft server. Once the image downloads, it starts up the server, and we see the log messages of the server startup. Here's an explanation of flags and options we provided to docker run in our command: specifies a port on the host (your local machine) that Docker should bind to a port on the container. In this case, our local machine's port 25000 will point to the container's port 25565. By default, Minecraft servers run on port 25565. Typically, you will always bind to the container's port 25565, regardless of the port on the host that you choose to use. -p provides an environment variable that the Docker container needs to use when starting up the server within the container. The Minecraft server application requires that you accept the EULA upon startup. Providing this environment variable is the Docker way to do that. -e EULA=true Lastly, we specify the name of the Docker image (on ), which contains the Minecraft server. DockerHub With our server running, let's see if we can connect to the server at localhost:25000. Open up the Minecraft Launcher client and click on "Play". The actual Minecraft game should launch. For game options, click on "Multiplayer". Next, click on "Direct Connection". For server address, enter localhost:25000. Our local port 25000, of course, is bound to the container running our Minecraft server. Finally, we click on "Join Server". And… we're in! If you look back at the terminal with the command, you'll recall that it continues to output the log messages from the Minecraft server. It might look something like this: docker run ...
 
[User Authenticator # /INFO]: UUID player familycodingfun is b4fb92b c6 a-bf32-fea282fc8a25
[Server thread/INFO]: familycodingfun[ 1 of 8 -24 -423 /172.17.0.1:53248] logged in with entity id 282 at (243.5, 65.0, -138.5)
[Server thread/INFO]: familycodingfun joined the game The server notes that a new player (my username is ) has joined the game. Our single game server setup is complete. Now, let's add Kong Gateway and port forwarding to the mix. For now, we'll exit the game and then kill our Docker container with the server. familycodingfun Step 2: Minecraft Server with Kong Gateway and Port Forwarding Next, we'll put Kong Gateway in front of our Minecraft server and take advantage of port forwarding. If you were running a private network, you might forbid requests from outside the network to reach your Minecraft server port. At the same time, you might expose a single port on which Kong listens. Kong, as the API gateway, would listen to requests on that port and then forward those requests to your Minecraft server. Doing so ensures that any requests that want to go to a Minecraft server must go through Kong first. Although we'll be working within localhost, we'll set up this kind of port forwarding through Kong. Just like in our previous step, we want our Minecraft server to run on port 25000. Meanwhile, Kong will listen on port 20000. Kong will take TCP connection requests on port 20000 and forward them to the Minecraft server at port 25000. Install and Setup Kong The first step is to . The vary depending on your unique setup. After installing Kong, we'll need to set up the initial configuration file. In your folder, you'll see a template file called . We will copy this file and rename it as , which is the file that Kong will look to for its startup configuration: install Kong Gateway installation steps /etc/kong kong.conf.default kong.conf ~$ cd /etc/kong
/etc/kong$ sudo cp kong.conf.default kong.conf
/etc/kong$ tree
.
├── kong.conf
├── kong.conf.default
└── kong.logrotate directories, files 0 3 In , we'll need to make the following three edits: kong.conf # PATH: kong/kong.conf

#
# Around line Uncomment and set TCP listening on port #

stream_listen = : #
# Around line Uncomment and set database to off
#
 
database = off

#
# Around line Uncomment and set to a file we /etc/ 368. for 20000 127.0 .0 .1 20000 922. 1106. 're about to create.
#                   Use the absolute path to a project folder
#

declarative_config = /PATH/TO/MY/project/minecraft-kong.yml The configuration tells Kong to listen for streaming TCP traffic. We're telling Kong to listen on port 20000 for this. For the needs of this mini project, we can configure Kong using its style. Kong will not need to use a database (database = off), and all of our configurations for port forwarding and load balancing will be stored in a single YAML file. That is the file path that we've set above. stream_listen DB-less and Declarative configuration declarative_config Write Declarative Configuration File Before we start up Kong, we need to write that file with our port forwarding configuration. In a project folder (that matches the path you specified above), open up a new file called : minecraft-kong.yml minecraft-kong.yml # PATH: ~ necraft-kong.yml

_format_version: services:
  - name: Minecraft-Server-A
    url: tcp: routes:
      - name: Server-A-TCP-Routes
        protocols: [ , ]
        destinations:
          - ip: port: /project/mi "2.1" //localhost:25000 "tcp" "tls" 127.0 .0 .1 20000 In this file, we declare a new named Minecraft-Server-A. The server uses the TCP protocol, listening on localhost port 25000, so we set these values together as the service's url. Next, we define a for the service, which associates our service with a URL path or an incoming connection destination that Kong will listen for. We provide a name for our route, telling Kong to listen for requests using TCP/TLS on the destination that we specified in our file: ip 127.0.0.1 and port 20000. Service entity Route kong.conf Start Up Minecraft Server and Kong We’ve written all of our configuration for this step. Let's start up our Minecraft server in Docker. Remember, we want our host (our local machine) to be ready on port 25000, binding that port to the standard Minecraft server port of 25565 on the container: ~/project$ docker run -p 25000:25565 -e EULA=true itzg/minecraft-server That command might take a little time to run as the server starts up. Now, in a separate terminal window, we'll start up Kong: ~/project$ sudo kong start With our server up and running, we go back to our game client and, just like above, choose "Multiplayer" and try to establish a "Direct Connection" with a game server. We know that we could connect directly to localhost:25000, since that's the actual host port bound to the container's port; rather, we want to test Kong's port forwarding. We want to connect to the supposed game server on localhost:20000, pretending that we're the casual user who is unaware that port 20000 points to a port forwarding gateway. Click on "Join Server." Like Step 1, your connection should be successful, and you'll have entered the Minecraft world. Our TCP connection request to localhost:20000 went to Kong Gateway, which then forwarded that request to port 25000, our actual Minecraft server. We have port forwarding up and running! Step 3: Load-Balancing Two Minecraft Servers We will spin up two Minecraft servers for the final step in our mini-project, listening on ports 25000 and 26000. Previously, when we only had one Minecraft server, Kong would naturally forward TCP requests at port 20000 to that sole Minecraft server's port. Now, with two Minecraft server ports to choose from, we'll need to use port forwarding and load balancing. Kong Gateway will take TCP connection requests that come to port 20000 and distribute connections evenly between Minecraft Server A and Minecraft Server B. Start Up Minecraft Servers If you haven't done so already, terminate the single Minecraft server that was running in the previous step. We'll start everything up again from a clean state, spinning up each server in its own terminal window. In your first terminal window, run the Docker container for Server A, binding the host's port 25000 to the container's port 25565: ~/project$ docker run -p 25000:25565 -e EULA=true itzg/minecraft-server Then, in a separate terminal window, we will start up Server B, this time binding the host's port 26000 to the container's port 25565: ~/project$ docker run -p 26000:25565 -e EULA=true itzg/minecraft-server Now, we have Servers A and B running, accessible at ports 25000 and 26000, respectively. Edit Declarative Configuration File Next, we want to edit our declarative configuration file ( ), configuring Kong for load balancing. Edit your file to reflect the following: minecraft-kong.yml # PATH: ~ necraft-kong.yml
_format_version: upstreams:
  - name: Minecraft-Servers
    targets:
      - target: localhost: weight: - target: localhost: weight: services:
  - name: Load-Balancing-Service
    host: Minecraft-Servers
    protocol: tcp
    routes:
      - name: Load-Balancing-Route
        protocols: [ , ]
        destinations:
          - ip: port: /project/mi "2.1" 25000 100 26000 100 "tcp" "tls" 127.0 .0 .1 20000 Let's walk through what we've done here. First, we added an (arbitrarily named Minecraft-Servers), which functions as a virtual host for load balancing to multiple services. That's exactly the functionality that we need. We added two to our upstream service. Each target has an address with host and port; in our case, our two targets point to localhost:25000 (Minecraft Server A) and localhost:26000 (Minecraft Server B). Then, we set a weight for each target, which the load balancer uses to distribute load. Even though we've explicitly set the weights evenly to 100, the default for this optional configuration is 100. Upstream Object Target Objects Next, we declared our Service Object, which in this case is our load balancer service. Requests that satisfy the routes we establish will be forwarded to the Minecraft-Servers host, our load balancing upstream object. Similar to our previous step, we configured a route, telling Kong Gateway to listen for TCP/TLS requests destined for 127.0.0.1:20000. Restart Kong Since our Kong configuration has changed, we need to restart Kong for the changes to take effect: ~/project$ sudo kong restart At this point, everything is up and running. We have our two Minecraft servers (Server A and Server B) running in Docker containers in two separate terminal windows. We have Kong configured to listen for TCP on port 20000, forwarding those requests to our load balancer, distributing connections across our two servers. Open the Minecraft game client again. Similar to previous steps, we will attempt to connect to the multiplayer server at localhost:20000 directly. As you connect, keep an eye on your two server terminal windows. As you repeatedly connect to the game, disconnect, and then reconnect, you will at times see a connection log message for Server A, and then at other times a message for Server B. And just like that, we have set up our load balancer to distribute connection requests across our two Minecraft servers! Ready to (Play) Work To recap, we slowly progressed in complexity for our mini-project: We started by simply spinning up a single Minecraft server in a Docker container, using port 25000 for accepting game client connections. Next, we configured Kong Gateway to sit in front of our single server to perform port forwarding. Kong listened on port 20000 for game client connections, forwarding those requests to the port on our host where the Minecraft server was accessible. Lastly, we set up two Minecraft servers to run concurrently. Then, we configured Kong Gateway to act as a load balancer. Kong listened on port 20000 for game client connections, this time funneling them through its load balancing service to distribute connections across our two servers. From here, you have many opportunities for adding complexity. You can add more game servers. For example, if some servers run on machines that can handle a heavier load of connections than others, then you can configure the load balancer to distribute the load unevenly. You can configure health check rules for Kong's load balancer to ensure requests are only forwarded to those servers which are presently healthy. You can even select from a handful of load balancing algorithms besides the default "round-robin" strategy. So, we've had a little fun and learned to use some important tools and concepts along the way. We have discovered that load balancing and port forwarding with Kong Gateway is simple and easy to set up. Yet, even with such ease, these features are extremely powerful. Now that you've got a handle on it, it's time to get to work and face the . Ender Dragon Also published on: https://medium.com/geekculture/load-balancing-minecraft-servers-with-kong-gateway-99e7aee1bbcc

The Essential Guide to Load-Balancing Minecraft Servers with Kong Gateway

For the last 10 years, I have been building RESTful services as the feature team member on projects assigned to me via consulting opportunities or as a full-time corporate employee. This represents one-third of my career and is what I have enjoyed the most. However, in all of those years, when the system is part of an application modernization initiative, I feel like I'm learning the same lessons over and over: Don’t replace a monolith with another monolith disguised as a modernized service. Avoid accepting bad data models to be compliant with the modernized system. Never assume that the existing program logic is 100% correct. Security and identity should be abstracted/consolidated into a higher level. Logging, monitoring, and routing should be included in the initial design. Each one of these lessons could be the focal point of a publication geared toward doing application modernization correctly. Rather, for this publication, I am going to focus on supporting applications that are successfully running – despite failures to the five lessons learned (above). The World in Which We Live Years before I took computer programming seriously, there was a song called “The World In Which We Live” by a new-wave band called . The adverse lyrics in that song speak of a world of consequence and the result of our own actions. Many times as a consumer of APIs, I feel the core of that song racing through my veins as I try to navigate non-standard APIs and unexpected experiences. Wang Chung Some of the pain points which tend to make my fingertips numb: Force me to send unnecessary authorization on every request RESTful calls which violate core design standards (GET changing data) Perform supplemental API calls, only because of a legacy system requirement Not having a good mechanism in place to properly debug and troubleshoot issues In fact, many service-based applications today follow a design similar to what is illustrated below: In this example, each service has implemented six common components at the service layer. This leads to duplication which must be managed manually – especially when the underlying source code (as shown above) utilizes different languages and frameworks. As a feature developer, I strive for ways that I can be more productive. I seek ways that I can maximize the amount of time I allocate to meeting acceptance criteria and making business rules lead to successful product enhancements. Most of all, I want to avoid my fingertips becoming numb at my age. Then I Found Kong... What if the illustration above was refactored and consolidated as shown below? In the example above, all of the duplicate components are consolidated into a distributed microservice abstraction layer, which is commonly referred to as an API gateway. In fact, I discovered this very design with Kong’s Cloud-Native API Gateway product – also known as “Kong Gateway”. Kong Gateway The product allows the complexity of my service-tier APIs to be reduced to a collection of endpoints (or URIs) focused on meeting a collection of business needs and functionality. Often duplicated components (like authentication, logging, and security) are handled by the gateway and can be removed from the service-tier design. Kong Gateway In addition to the common components shown in the original illustration, Kong Gateway offers additional functionality: Dynamic Load Balancing Health Checks Service Discovery Serverless Clustering Scalability Performance The best part of Kong Gateway is that it is a cloud-native (platform agnostic) open-source software (OSS) solution, which can be utilized pretty much anywhere. There are also no licensing costs while utilizing the OSS product. Kuma Taking things to a broader level, is another platform agnostic-OSS solution for service mesh and microservice management – with control plane support of Kubernetes, virtual machines (VM), and even bare-metal environments. Kuma was donated to the Cloud Native Computing Foundation (CNCF) by Kong and still actively contributes to the evolving codebase. Kuma While Kong Gateway is a separate layer to sit between the requestor and the services, Kuma employs a “sidecar” pattern – similar to a sidecar on a motorcycle. However, rather than providing extra space for a passenger, this type of sidecar attaches to individual containers – thus forming a “mesh” instead of a separate layer. Kuma leverages – an open source edge and service proxy – in order to visualize any program areas via consistent observability. In addition to an advanced user interface, Kong Kuma includes three key features: Envoy Universal Control Plane Lightweight Data Plane Automatic With Kuma, distributed environments can take advantage of the core Kong Gateway features and functionality while also including aspects such as: Multi-zone support Fine-grained services and traffic policies Horizontally scalable Supports mission-critical use cases Kong Ingress Controller For those organizations using Kubernetes for their container orchestration, Kong created the which implements authentication, transformations, and other functionalities (via plugins) across Kubernetes clusters. Kong Ingress Controller Kong Ingress Controller updates a standard Kubernetes implementation as shown below: With the Kong Ingress Controller in place, the features noted in the Kong Gateway product are accessible via the plugin architecture. Six plugins are depicted in the example above. Kong Gateway (OSS) In Action I wanted to take Kong Gateway (OSS) for a test drive, so I used Spring Boot to create a very simple URI: /accounts – retrieves a list of Account objects (http://localhost:8888/accounts) The data behind this URI will be static and created when the service starts. Within a few minutes the service was available on port 8888 of my local machine: To keep things simple, I decided to run Kong Gateway using my MacBook Pro system and a PostgreSQL database within Docker. Installing Kong on MacBook Pro Using the package manager, I installed Kong Gateway with a couple of commands: Homebrew ╭─john.vester@jvc ~ jvc/kong 
╰─$ brew tap kong/kong
╭─john.vester@jvc ~ jvc/kong 
╰─$ brew install kong /projects/ /projects/ Once completed, the following command was executed to validate Kong Gateway version 2.4.0 was installed correctly: ╭─john.vester@jvc ~ jvc/kong 
╰─$ kong version /projects/ 2.4 .0 Installing and Configuring PostgreSQL Using Docker To get PostgreSQL running via Docker as my database, so I pulled down the latest version of Postgres from : Docker Hub ╭─john.vester@jvc ~ jvc/kong 
╰─$ docker pull postgres /projects/ Once the Docker images were ready, PostgreSQL was started in Docker: ╭─john.vester@jvc ~ jvc/kong 
╰─$ docker run --name postgres -e POSTGRES_PASSWORD=some-password -d -p : postgres a9303b586ea8953717ea6c68fa04437301fe367a5a85b43d5d1fa8523fba6 /projects/ 5432 5432 763 With the database running, elements for the Kong Gateway were added to the running instance: CREATE USER kong; 
CREATE DATABASE kong OWNER kong; The last step of database preparation is to execute the following command: ╭─john.vester@jvc ~ jvc/kong 
╰─$ kong migrations bootstrap -c /etc/kong/kong.conf

... migrations processed executed
Database is up-to-date /projects/ 41 41 Configuring Kong Gateway After the database migrations finished, Kong Gateway was ready to start: ╭─john.vester@jvc ~ jvc/kong 
╰─$ kong start -c /etc/kong/kong.conf
Kong started /projects/ With Kong Gateway set up and ready to go, the next step is to focus on configuring the Spring Boot URI noted above. The first step is to configure the Spring Boot RESTful service as “account-service” using the following cURL: curl --location --request POST \
--header \
--data-urlencode \
--data-urlencode 'http://localhost:8001/services' 'Content-Type: application/x-www-form-urlencoded' 'name=account-service' 'url=http://localhost:8888/accounts' This leads to the following response – referencing configuration data is stored in Postgres: { : , : , : , : , : , : , : , : , : , : , : , : , : , : , : , : , : } "connect_timeout" 60000 "path" "/accounts" "read_timeout" 60000 "name" "account-service" "write_timeout" 60000 "created_at" 1618933968 "updated_at" 1618933968 "tls_verify" null "id" "7ba5d84c-0b4d-454a-83b3-5381d4e52c61" "tls_verify_depth" null "retries" 5 "tags" null "ca_certificates" null "port" 8888 "client_certificate" null "host" "localhost" "protocol" "http" A route is created next for a host called “account-service” which will be referenced whence the Spring Boot service is called: curl --location --request POST \
--header \
--data-urlencode 'http://localhost:8001/services/account-service/routes' 'Content-Type: application/x-www-form-urlencoded' 'hosts[]=account-service' The result of the cURL command generates the following JSON response from Kong Gateway: { : , : , : [ ], : , : , : , : [ , ], : , : , : , : , : , : , : , : , : , : , : , : , : { : }, : } "headers" null "name" null "hosts" "account-service" "created_at" 1618936295 "path_handling" "v0" "id" "d70a3bf2-4a82-4ec5-a644-90806c53f5b5" "protocols" "http" "https" "paths" null "request_buffering" true "response_buffering" true "destinations" null "methods" null "https_redirect_status_code" 426 "preserve_host" false "strip_path" true "regex_priority" 0 "updated_at" 1618936295 "snis" null "sources" null "service" "id" "7ba5d84c-0b4d-454a-83b3-5381d4e52c61" "tags" null At this point the “account-service” route can be retrieved via Kong Gateway using the following cURL: curl --location --request GET \
--header 'http://localhost:8000/' 'Host: account-service' Which returns the expected JSON data from the Spring Boot service: [
    { : , : },
    { : , : },
    { : , : },
    { : , : },
    { : , : }
] "id" 1 "name" "Eric" "id" 2 "name" "Finn" "id" 3 "name" "Nicole" "id" 4 "name" "John" "id" 5 "name" "Sydney" Success! This is the exact same data when hitting Spring Boot directly but passed through the Kong Gateway. Adding the Rate Limiting Plugin Next, I implemented  the Rate Limiting plugin into the Kong Gateway, using the following cURL: curl -X POST http: --data \    
   --data \    
   --data \
   --data //localhost:8001/services/account-service/plugins \ "name=rate-limiting" "config.second=1" "config.minute=3" "config.policy=local" This configuration, although limiting, only allows one request to the account service per second with a maximum of three requests per minute. The submission of this POST yields the following response payload: { : , : , : , : { : , : , : , : , : , : , : , : , : , : , : , : , : , : , : , : , : }, : [ , , , ], : , : { : }, : , : , : } "route" null "tags" null "name" "rate-limiting" "config" "year" null "path" null "limit_by" "consumer" "hide_client_headers" false "second" 1 "minute" 3 "redis_timeout" 2000 "redis_database" 0 "redis_host" null "redis_port" 6379 "policy" "local" "hour" null "header_name" null "redis_password" null "fault_tolerant" true "day" null "month" null "protocols" "grpc" "grpcs" "http" "https" "created_at" 1618947648 "service" "id" "7ba5d84c-0b4d-454a-83b3-5381d4e52c61" "consumer" null "id" "a3d8532a-0464-4117-bbfd-716300966fe7" "enabled" true Now, when multiple calls are made to the following URL: curl --location --request GET \
--header 'http://localhost:8000/' 'Host: account-service' The Kong Gateway throws a 429 (Too Many Requests) HTTP response with the following payload: { : } "message" "API rate limit exceeded" Using the open-source version of Kong Gateway, the following plugins could be easily added following the same pattern noted above: Basic and JWT Authentication CORS and IP Restrictions ACL and Request Size Limitations Invoke Serverless Functions Data Transformations Multiple Logging Options Conclusion If I were to draft a concise mission statement for any IT professional it would be quite simple: Focus your time on delivering features/functionality that  extends intellectual property value. Leverage frameworks, products, and services for everything else. Kong provides products and services to not only avoid service-tier duplication but in many cases abstract common components away from the mind of the feature developer. The result of this approach allows a code-base that is lean and focused on meeting acceptance criteria. Kong follows this same mission statement themselves, allowing aspects from Kong Gateway to be implemented as a plugin in the Kong Ingress Controller product. As a result, components are configured once and leveraged everywhere. Kong employs a platform-agnostic approach, allowing legacy applications to utilize the same services for short or long-term periods of time. As a result, supporting the pain points noted in the introduction of this publication becomes less of an issue. Have a really great day! Also published at https://dzone.com/articles/how-i-stopped-coding-repetitive-service-components

Use the Kong Gateway to Stop Coding Repetitive Service Components

In the previous article from the API Gateway 101 Series, we saw an , understanding the basic know-how. Now it’s time to see an API gateway in action in front of multiple microservices. Introduction to API Gateway We’ll be spinning up multiple mock microservices within a private network (docker network) making them inaccessible from the host. The API gateway will be accessible from the host and all the microservices will be attached to the gateway. Thus any client request needs to go through the gateway first before being served by the actual microservice in the backend. Prerequisites We’ll be deploying the API gateway and the mock microservices using Docker. If you’re not familiar with Docker & Docker Compose then here is a quick link to understand the basics - . Docker Docs For exploring and utilizing the Kong Admin API we'll be using Postman Collections. Postman is an API Client that assists to create, share, test, and documenting APIs. Postman collections are basically a group of saved API requests that are executable. You’ll see that I’ve organized the postman collection for this series in folders making it easy for you to explore saved APIs section-wise. Postman isn’t necessary for this series, you can easily replicate the saved APIs into your favorite API client. NOTE: I’m using Docker installed on a windows machine. In this article where ever I mention , it refers to the ‘docker-machine ip’. 192.168.99.100 Cool, now that once Docker, Docker Compose & Postman are installed, we can move forward to get started. Let’s now get our hands dirty by spinning up some mock microservices and setting up an API Gateway in front of them. Spinning up mock microservices The source code for the mock microservices created for this article can be found on my GitHub repository - adisakshya/api-gateway To get started let’s clone the git repository - git clone https://github.com/adisakshya/api-gateway
cd api-gateway/single-node-kong-gateway Source code for each mock microservice lives in the respective directory named after them. Some services are defined directly in the docker-compose file. All the microservices and the API gateway can be started at once using the following command - docker-compose up -d This will start the respective docker containers in the background of your terminal (aka docker detached mode). You can check the list of containers that are up using the following command - docker ps -a Since we’re running docker containers in the detached mode we’ll not be able to see any logs. But If you want to see logs of a specific container you can use the following command - docker container logs '<<CONTAINER_ID>>' The IP for the internal docker gateway is 172.18.0.1, to get the IP for a particular docker container you can use the following command - docker inspect '<<CONTAINER_ID>>' | tail -n 20 I’ve used the tail command to see the IP address of the docker container, which is found towards the end of the response from the docker inspect command. We’ll need the IPs of the docker containers to attach these microservices to our Kong API gateway. By now you’ll have the following containers up and running - Container Name IP (Docker Network) IP (Host Network) Konga (Admin GUI) 172.19.0.2 192.168.99.100:1337 Kong 172.18.0.9 192.168.99.100:8000-8001 Kong Database 172.18.0.3 192.168.99.100:5432 Nginx Web Server 172.18.0.6 Not accessible Apache Server 172.18.0.2 Not accessible HTTPBin 172.18.0.5 Not accessible Application Server A 172.18.0.7 Not accessible Application Server B 172.18.0.4 Not accessible Kong Gateway APIs Kong can be administered with an internal RESTful API called the . This API provides full control over the kong gateway. Admin API is the default port for HTTP traffic to the Admin API. 8001 is the default port for HTTPS traffic to the Admin API. 8444 Apart from the Admin API, we have another API using which the API consumers can consume the services. This API needs to be exposed to the world in order for the services to be accessible. is the default port for HTTP traffic from Consumers. 8000 is the default port for HTTPS traffic from Consumers. 8443 The traffic from consumers on 8000/8443 is forwarded to the corresponding service based upon the defined routes. Accessing the Admin GUI (Konga) The admin GUI can be found at . Once you register yourself as an admin you'll be prompted to specify the kong admin URL using which the Admin GUI can create objects like services/routes etc on the kong node. 192.168.99.100:1337 The Kong Admin API is found at 1 . Once the Admin GUI is connected to the Admin API you’ll be directed to the main dashboard - 92.168.99.100:8001 Interacting with the Kong Admin API I’ve created a containing the requests that can be made to the Kong APIs for administrating and accessing services from the gateway. Postman collection The Admin API provides a ‘/status’ route that can be used to check the status of a Kong node. The Admin API provides you with complete control over the Kong Node so there’s a lot you can do with this API like attaching/detaching backend services, creating/removing consumers, creating passwords for users, and much more. To get the full list of routes provided by the Admin API you can call the route. I’ve included a few requests in the postman collection for you to explore the Admin API. /endpoint Registering the microservices with the API gateway Having played with the Admin API now let’s attach our already running backend microservices with the API gateway. Every microservice will have a service object corresponding to it on the API gateway that is identified by the service name, hostname (or IP address), and port number. Every service will have defined route(s) which can be called by the end-users. The request to any route is proxied to the corresponding backend microservice and the generated response is returned back to the end-user by the API gateway. To create a service object for a backend microservice, we can send a POST request to the Admin API on the ‘/services’ route with the service name, hostname, and port number (default 80). Having created a service object for all our microservices we can get a list of available services on the API gateway using the Admin API. Having defined the service objects now we need to create the routes to which the API consumers can forward their requests. To create a route object for a gateway service, we can send a POST request to the Admin API on the route with the route name, route path, and list of allowed methods on that path. /routes Having created route objects for all our gateway services we can get a list of all available routes using the Admin API. Utilizing the microservices from the API gateway All the routes defined on the gateway are reachable from port 8000. Let’s hit the routes we’ve created and analyze the response. We’re running a raw Nginx Web Server behind the route , let’s hit it first using the API - /nginx As expected the response returned is the default Nginx welcome page, this means that the backend Nginx web service running on (inside docker network) is now accessible on the host via the API gateway. Now let’s try hitting the HTTPBin service - 172.18.0.6 The purpose of using the HTTPBin service was to analyze the returned response in detail. Focus on the fields named ‘X-Forwarded-Host’, ‘X-Forwarded-Path’, and ‘X-Forwarded-Prefix’, these fields are often referred to as (XFF) HTTP header fields. X-Forwarded-For XFF fields are used for identifying the originating IP address of the consumer who is connecting to the service. There can be more details like UserId and Username of the consumer as part of XFF which can be utilized by the backend microservices. We’ll be exploring them in detail in upcoming articles. Next Steps As you might have noticed already that all the services that we’ve created are open to access for anyone on the host. In the next article, we’ll understand some key concepts about authentication and authorization to secure our backend services. We’ll see how we can restrict access to a particular backend service on the user level. See you there! Contribution Enjoyed the article, found it useful, or learned something new? Consider sharing it so more people can benefit from it! Also, feel free to @ me on with your opinions. Twitter Found a mistake? Feel free to mention it in the comments or at GitHub issues or fix it using a PR at . adisakshya/weblog Also published . here

How to Set up an API Gateway for Your Microservices

From a career perspective, the two things I appreciate the most are solving problems through technology and creating technical publications. The former often drives the latter: results presented in inspired-based publications are derived from a recent problem that I had successfully solved. Along my three-decade journey, I also discovered that I enjoy making lists. Early in my career, I used quad-ruled notebooks to establish lists to work from daily. Of course, those graphically-lined necessities have fallen aside in favor of using derived lists maintained on or boards. For smaller projects, I tend to lean toward using the and text editors. What has not changed is my preferred approach to work from a list. Trello JIRA Sublime Atom Moving From Lists to Outlines For larger initiatives, simply working from a list does not provide enough details. This is often the case with ideas I have for a new publication. In those cases, I introduce sub-items to each core list item. While it is possible to include child items at the sub-item level, I often find that I am getting into the weeds and not focusing on the broader landscape. Once there is good coverage for each item on the list, I figure out how best to order each item. During this step, the list actually becomes an outline, where there is a sequence established to my collection of thoughts or ideas. The resulting product is what I have ended up using for every publication I have submitted since 2015. However, the outline concept has not been limited to my technical writing. I have also employed this very same approach when building APIs. The API-First Design Pattern noted that an API-first approach “treats APIs with importance, as reusable and easily accessible products that client applications consume. API-first means designing products around an API from the ground up, rather than building a product and adding an API later.” Janet Wagner After establishing API standards, the API-first design pattern allocates time at the beginning of the process to produce a solid API design, focusing on high-level characteristics, which include: Resource path (URI) Operation/Request types (GET, PUT, POST, PATCH, DELETE) Inbound parameters/payload Outbound response codes (1xx, 2xx, 3xx, 4xx, 5xx) Outbound response payload (type and data model) Additional meta-data (description, contact, terms of use) When developing these specifications I recommend the following lifecycle: In the illustration above, the first step is to listen to the needs of the API and to repeat any requirements back to the product owner driving the underlying business rules. After achieving that understanding, the design phase begins by leveraging a standards-based specification (like OpenAPI). Finally, consumers of the API can preview it. Often, the cycle does not end there, as questions and challenges arise from the preview phase. At that point, it will require additional time to share these concerns with the product owner, who will provide additional information. At that point, the cycle begins with the goal of providing a more-refined API specification. By employing an API-first design pattern, a single-source-of-truth artifact is documented before writing a single line of code. The specification for the API will live outside the source systems that produce the actual API in a manner that can be easily cataloged and consumed by future client and service engineers. Now, let’s get started and work through a simple use case. Box Finders API: An Example Use Case After recently moving into our new home, I thought of a use case to illustrate the API-first design pattern. My idea centers around cardboard boxes used for moving one’s possessions. Boxes are necessary before you start packing to move into a new home. If you’re like me, finding boxes that are still in good shape and for little or no cost is an ideal situation. Then, after the move is complete, finding someone to take your gently-used boxes is just as important to avoid a not-so-attractive cardboard display in the corner of your garage. Enter the Box Finders API, where customers perform the following operations: GET /boxes - returns a list of available box collections GET /boxes/{id} - retrieves a single box collection POST /boxes - adds a new box collection PUT /boxes/{id} - updates an existing box collection DELETE /boxes/{id} - removes an existing box collection For simplicity, let’s assume the Box Finders API requires the following attributes: Id - unique numeric identifier for the box collection Name - the name of the person to contact Phone - the contact’s phone number Available - the number of available boxes Using Kong Insomnia with an API-First Design Since I had not used the application before, I thought I would give it a try for proving the API-first design pattern. Kong Insomnia Once , getting started with an API-first design begins with using the menu on the left-side of Kong Insomnia: installed Create Upon selecting the Design Document option, the next step is to provide a name. For this example, I entered . box-finders-spec.yaml At this point, an empty design document opens in Kong Insomnia: Now, we are ready to start designing the Box Finders API. Adding General Information At the top of the file, you can add some general information about the specification.   I used OpenAPI version 3.0.0: openapi: 3.0.0

info:
  version: "0.0.1"
  title: "Box Finders API" Adding Schema Information Based upon the current understanding of the Box Finders API, I added the data models (also known as schema components) to the bottom of the file: components:
  schemas:
    Boxes:
      type: array
      items: 
        $ref: "#/components/schemas/Box"
    Box:
      type: object
      properties:
        id:
          type: number
          description: Unique identifier
        name:
          type: string
          description: Person with boxes to give away
        phone:
          type: string
          description: Phone number of person with boxes to give away
        available:
          type: number
          description: Number of available boxes      
    Error:
      type: object
      required:
        - code
        - message
      properties:
        code:
          type: integer
          format: int32
        message:
          type: string Taking this approach will keep the data side of the contract defined in one central location of the API specification. Adding URIs /boxes With the general information and schema sections in place, we can add the /boxes URIs as items following the OpenAPI standards: path paths:
  /boxes:        
    get:
      summary: "Lists all available box collections"
      responses:
        "200":
          description: "200 OK, all box collections"
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/Boxes"
    post:
      summary: "Adds a new box collection"
      requestBody:
        content:
          application/json:
            schema:
              $ref: "#/components/schemas/Box"
        required: true
      responses:
        "201":
          description: "201 Created, a new box collection was added"
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/Box" In this example, I’ve added URIs to retrieve all box collections and create a new box collection under the section. paths Adding URIs /boxes/{id} ** **Next, I added the ability to retrieve, edit, or delete a single box collection as additional paths, still following the OpenAPI standard: /boxes/{id}:
    parameters:
        - in: path
          name: id
          schema:
            type: number
          required: true
          description: "id of the box collection"
    get:
      summary: "Retrieves a box collection by identifier"
      responses:
        "200":
          description: "200 OK, box collection by identifier"
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/Box"
        "404":
          description: "404 Not Found, box collection does not exist"
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/Error"
    put:
      summary: "Updates a box collection by identifier"
      requestBody:
        content:
            application/json:
              schema:
                $ref: "#/components/schemas/Box"
      responses:
        "202":
          description: "202 Accepted, updated box collection"
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/Box"
        "404":
          description: "404 Not Found, box collection does not exist"
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/Error"
    delete:
      summary: "Deletes a box collection by identifier"
      responses:
        "204":
          description: "204 No Content, deleted box collection"
        "404":
          description: "404 Not Found, box collection does not exist"
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/Error" At this point, the 0.0.1 version of the Box Finders API is complete. However, before moving forward, I felt like it was a good time to store this information inside a git-based repository. This way, the design is not limited to existing on my local machine. Connecting to GitHub The Kong Insomnia client allows integration with an existing git-based repository. I created a new repository at the following URL: ** ** https://github.com/johnjvester/box-finders-api Next, I created a__ __ to create read/write access to the GitHub repository. Then, I used that resulting token to set up access within Kong Insomnia for the Box Finders API specification: personal access token At this point, I committed my changes and pushed them to GitHub. Once completed, the changes from Kong Insomnia are now available for others to pull into their own client: Others who wish to review or contribute to the specification can use the option from the menu. Git Clone Create Kong Insomnia Showing Complete API With the changes noted above, Kong Insomnia shows the contents of the API: At this point, the Box Finders API specification can be consumed by service and consumer developers without writing a single line of code. Using Box Finders API For cases where a consumer of the Box Finders API wants to develop their application while the feature team is developing the Box Finders RESTful service, Kong Insomnia provides the entire contract for the new client to utilize: When making a GET request to the URI, the service will return a list of Box objects: /boxes [
  {
    "id": 0,
    "name": "string",
    "phone": "string",
    "available": 0
  }
] Using the API-first design pattern, every client or service tied to the Box Finders API can begin their development before writing a single line of code for the Box Finders service. Deploying to Kong Dev Portal If you’ve to use the Kong Dev Portal, you can use the menu option on the Box Finders specification menu: set up an account with Kong Konnect Deploy to Dev Portal Kong Insomnia will then ask for the connection properties before attempting a deployment for the first time: Conclusion Since last year, I have been trying to live by the following mission statement, which I feel can apply to any IT professional: “Focus your time on delivering features/functionality which extends the value of your intellectual property. Leverage frameworks, products, and services for everything else.” ** ** - J. Vester In this article, I used Kong Insomnia to create a standardized API specification that can be fully documented, vetted, and communicated before writing any source code. This allows teams to collaborate on the design and make changes without requiring any costly service-tier updates. Clearly, this embraces my personal mission statement. Kong Insomnia is a product that allows feature teams to remain focused on extending intellectual property value, contributing to the bottom line positively. Taking things a step further, you can easily deploy the results from Kong Insomnia to , which centralizes API specifications for other consumers to find and utilize in their applications. Kong Konnect In my personal journey, I created lists to help with my daily assignments. In most cases, those lists became outlines, which then led to designs and specifications. The API-first design pattern was a natural progression for me and is certainly a concept I appreciate and embrace. If you are interested in the original source code for this publication, everything noted above can be found at the following link: https://github.com/johnjvester/box-finders-api Have a really great day!

Exploring the API-First Design Pattern

Let’s say we are building an application that uses the microservices architecture. These types of applications provide API delivering a specific use case. Additionally, the number of running service instances or the number of services in an application itself can change, which should be hidden from clients. So how do the clients of Microservices-based applications access the individual services? The client application would need to interact with multiple different services to get the required information for the user and any update in a service should be hidden from clients. This is where the concept of API Gateway comes into the picture. It follows the literal meaning of a . “Gateway” - the place which you must go through to get to somewhere else The API Gateway acts as a single entry point to the available backend services in an application for all the clients. It can also implement security, e.g. verify that the client is authorized to perform the request. Just like a security guard standing in front of the gateway and verifying if you are allowed to go beyond the gateway. In this series, we’ll understand what these gateways are all about and get our hands dirty by setting up an API Gateway in front of an application that uses the microservices architecture deployed on Kubernetes. But one step at a time. API Gateway 101 What is an API? Firstly we need to understand what exactly an API is? Application Programming Interface (API) provides a blueprint that specifies how application services in a software system should interact with each other. It acts as a bridge between different services and abstracts away the underlying complexity to present it as a well-defined product. Cool, now let’s get started and understand - What is an API Gateway? What is the difference between API Gateway, Load Balancer and Reverse Proxy? What is Kong? What is the use of an API Gateway in a microservices environment? What is an API Gateway? At the most basic level, an API follows a request-response cycle i.e., the API service accepts a remote request and returns a response. But this isn’t that simple, let’s think about various concerns when we host large-scale API - We want to protect our API services from overuse and abuse, so we should use an authentication service and rate-limiting etc. We want to understand how people use our APIs, so we’d like added analytics and monitoring tools. Over time we’ll add some new API services and retire others, but our clients will still want to find all our services in the same place. The challenge is to provide the clients with a simple & dependable interface for enabling them to interact with our system and manage remote requests in a centralized manner. An API gateway is an API management tool that sits in front of the backend API services and acts as a single entry point for all clients wanting to consume the services. The gateway intercepts all the incoming remote requests and can apply a variety of necessary checks and functions. API Gateway vs Load Balancer vs Reverse Proxy At this point, an API gateway might sound pretty similar to a load balancer and reverse proxy. These applications sit between the clients and backend servers, accepting remote requests from the former and delivering responses from the latter. To understand the difference, let’s explore when and why they’re typically used - Load Balancer Load balancing helps prevent the overloading of individual systems & prevent failure due to the same. A load balancer offers the ability to distribute incoming remote requests across multiple backend services. Say, we are running 5 instances of a backend service behind the load balancer. The incoming requests will be distributed between these 5 servers following the load balancing strategy like round-robin, least utilized, etc. If any of these 5 servers fail due to any reason then the load balancer would distribute the incoming requests to the remaining operational backend services. Reverse Proxy A Reverse Proxy acts as a mediator between the client and one or more backend services. It can rewrite the URLs, so the client will not know who is sitting behind the reverse proxy. Its responsibility is to forward the remote request to the appropriate backend service that can fulfill it. A typical reverse proxy can be used for - : it offers the ability to distribute incoming requests across multiple backend servers. Load Balancing : content is often kept in a place called proxy cache. So for recurring requests, it can answer autonomously in less time. Caching : it can be configured to decrypt all incoming requests and encrypt all outgoing responses. SSL Encryption API Gateway We can think of the API Gateway as a superset of a Reverse Proxy. The gateway hides the backend architecture from the clients. It addresses some common utilities like - Authentication and Authorization: It can control who can request what Example - It offers the possibility to control the access to specific backend services based upon the plans that the API consumer have purchased. IP Whitelisting: It can grant the ability to use the API services only to specific IP addresses Rate Limiting, Throttling, and Quota: A limit can be set based on how many requests the backend servers can handle for a certain unit of time. Looking at the commercial aspect, it offers the possibility to control the traffic that API consumers are using based on the plan they’ve purchased Logging, Tracing, Correlation: It can gather all the logs for each specific remote request. Differences at a glance - Function Load Balancer Reverse Proxy API Gateway Balance incoming requests ✅ ✅ ✅ URL Rewrite ✅ ✅ Caching ✅ ✅ Prevention from Attack ✅ Protocol Translation ✅ Authentication ✅ IP Whitelisting ✅ Rate Limiting, Quota ✅ Logging ✅ Tracing ✅ Health Checking ✅ Dynamic Config Updates ✅ What is Kong? Kong Gateway is one of the most popular open-source API gateways. It securely manages the communication between clients & backend services via an API. Kong sits in front of backend services and extends these APIs using to provide extra utilities like authentication, rate-limiting, etc. Plugins A typical Kong API Gateway setup looks something like this - Once the architecture is deployed and running, every remote request to the backend services will hit kong first thus becoming the entry point for any API request. If you want to deep dive into working of Kong then you can refer to this - https://konghq.com/faqs/ What is the use of an API Gateway in a microservices environment? In a microservices architecture, each microservice exposes a set of endpoints with specific functionalities. Client applications usually want to consume functionality from more than one microservice. If there is a direct Client‑to‑Microservice Communication, then the client application would need to handle multiple calls to the backend microservice endpoints. When the client application is linked with the internal endpoints then evolving the microservices would mean updating the client application too. But ideally updating internal APIs should have minimal impact on the client application. This is where the API Gateway comes to the rescue, it encapsulates the backend services architecture and provides an API that can be customized for each client application. Next Steps We’ll get our hands dirty in the next article where we’ll Spin several microservices Setup a Kong API Gateway in front of the microservices Access the created services them using the gateway See you there! Contribution Enjoyed the article, found it useful or learned something new? Consider sharing it so more people can benefit from it! Also, feel free to @ me on with your opinions. Twitter Found a mistake? Feel free to mention it in comments or at . GitHub Issues Thanks for reading! Also Published Here

An Introduction to API Gateways

APIs come in all different shapes and forms. In this tutorial, I’ll show you a Kubernetes Ingress gRPC example. I’ll explain how to deploy a gRPC service to Kubernetes and provide external access to the service using Kong’s Kubernetes Ingress Controller. And to hype you up a little bit about the upcoming live-action movie, Dune, based on Frank Herbert’s book, I created a Kubernetes service that delivers Dune quotes. It’s arguably one of the most outstanding science fiction books ever written…what do you think? Let me know on Twitter. @GAMUSSA Before we dive into the code, let’s review a few basics. How Does gRPC Work With Kong? gRPC is a procedural framework initially developed by Google in 2015. Based on HTTP2 protocol for transport and Protocol Buffer (Protobuf) as the interface definition language, gRPC has seen growing adoption in recent years. gRPC has several capabilities that traditional REST APIs struggle with, such as bidirectional streaming and efficient binary encoding. supports TCP streams and can proxy any protocol built on top of a TCP or TLS. We felt that native support for gRPC would allow a growing user base to leverage Kong to manage their REST and gRPC services uniformly. Kong Now that we’ve covered the basics, let’s take a look at the Protobuf definition of my . Dune Quote service Protobuf Definition My Protobuf definition contains a quote service that uses two methods. One method is to deliver a simple quote on any gRPC request. That method doesn’t require any input parameter, so we’ll be using the Protobuf empty type. And as a return, it will have a quote message that will include a message field. And another method that I have here is a GetQuoteStream method that also doesn’t require any parameters to provide. In this case, I also used an empty type. But in this case, I’m returning a stream of these results. syntax = ;
 
package io.kong.developer.quoteservice; ;
 
option java_multiple_files = ;
option java_package = ;
 
service QuoteService {
 
  rpc GetQuote(google.protobuf.Empty) returns (QuoteMessage) ;
  
  rpc GetQuoteStream(google.protobuf.Empty) returns (stream QuoteMessage) ;
 
}
 
message QuoteMessage{
  string message = ;
} "proto3" import "google/protobuf/empty.proto" true "io.kong.developer.quoteservice" 1 I’m using Java to generate a server-side implementation of the service. However, you can take this proto file and implement this service in any language that you use. Protobuf comes with various tools in different languages, including some code generators that support your language of choice. Let’s take a look at the deployment for our Dune Quote service. Kubernetes Deployment Review I’m using the same image in my deployment, but my active service will be using version 3. ---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: dune-quote-service
spec:
  replicas: selector:
    matchLabels:
      app: dune-quote-service
  template:
    metadata:
      labels:
        app: dune-quote-service
    spec:
      containers:
        - image: gamussa/reactive-quote-service: imagePullPolicy: Always
          name: dune-quote-service
          ports:
            - containerPort: env:
            - name: GRPC_SERVER_PORT
              value: - name: GRPC_SERVER_SECURITY_ENABLED
              value: - name: GRPC_SERVER_SECURITY_CERTIFICATECHAIN
              value: - name: GRPC_SERVER_SECURITY_PRIVATEKEY
              value: volumeMounts:
            - mountPath: rpc-cert-chain
              name: grpc-cert-chain
            - mountPath: rpc-pk
              name: grpc-pk
      volumes:
        - name: grpc-cert-chain
          secret:
            secretName: grpc-cert-chain
        - name: grpc-pk
          secret:
            secretName: grpc-pk 1 0.0 .3 9001 "9001" "true" "file:/mnt/grpc-cert-chain/server.crt" "file:/mnt/grpc-pk/server.key" /mnt/g /mnt/g My application will be running the GRPC_SERVER on port 9001. And this port will be available to the service to expose this inside my Kubernetes cluster. My service has security enabled. And I do provide some certificates in the gRPC server private key. name: dune-quote-service
          ports:
            - containerPort: env:
            - name: GRPC_SERVER_PORT
              value: - name: GRPC_SERVER_SECURITY_ENABLED
              value: - name: GRPC_SERVER_SECURITY_CERTIFICATECHAIN
              value: - name: GRPC_SERVER_SECURITY_PRIVATEKEY
              value: 9001 "9001" "true" "file:/mnt/grpc-cert-chain/server.crt" "file:/mnt/grpc-pk/server.key" I’m using a self-signed TLS certificate in this example. You’ll need to use a certificate signed by a certification authority that you trust in a production use case. I created the secrets. After that, I mount those secrets as files in my deployment. volumeMounts:
            - mountPath: rpc-cert-chain
              name: grpc-cert-chain
            - mountPath: rpc-pk
              name: grpc-pk /mnt/g /mnt/g Service Review My service will use port 9001 as my target port. Pay attention to Line 6, where I have the limitation: . It will respond to gRPC as a protocol because my service has security enabled, and I need to notify my Kong Gateway that my service understands gRPCS protocol. konghq.com/protocol ---
apiVersion: v1
kind: Service
metadata:
  annotations:
    konghq.com/protocol: grpcs
  name: dune-quote-service
  labels:
    app: dune-quote-service
spec:
  ports:
    - name: grpc
      port: targetPort: selector:
    app: dune-quote-service 9001 9001 And last but not least, I need to create an ingress. Ingress Setup You see some familiar things like that corresponds to my open-source Kong Ingress Controller. Now, I also have an annotation here: ingress.class konghq.com/protocols ---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: dune-quote-service
  annotations:
    konghq.com/protocols: grpc,grpcs
    kubernetes.io/ingress.class: kong
    kubernetes.io/tls-acme: cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
  tls:
    - secretName: kong.gamov.dev
      hosts:
        - kong.gamov.dev
  rules:
    - host: kong.gamov.dev
      http:
        paths:
          - path: "true" /
            pathType: ImplementationSpecific
            backend:
              service:
                name: dune-quote-service
                port:
                  number: 9001 It’s an ingress configuration that allows Kong Gateway to understand what kind of incoming clients we expect. In this case, we’re creating this ingress for gRPCS because we’re expecting gRPC clients to connect to the service. We’re using gRPC or gRPCS protocols. Before deploying the Kubernetes service, we’ll need to set up Kong Ingress Controller and Kubernetes cert-manager. Ingress Controller and Cert Manager Setup I’ve already installed the Kong Ingress Controller. If you haven’t, follow along in my previous . getting started tutorial I configured my cluster to use cert-manager. I will be using certificates issued by LetsEncrypt. In Kong’s documentation, there is a that allows you to configure your Kong Ingress Controller and your API Gateway to use automatically issued certificates for TLS. getting started guide for cert-manager Next, we need to follow the . Kubernetes cert-manager documentation Then, we’ll be able to request the TLS certificate from the certification authority. And after that, the application will use port 443 TLS to communicate with external clients. That’s why I have this annotation, , to use an automatic certificate management extension enabled for my cluster. I’m using the LetsEncrypt server production version to receive the certificate. kubernetes.io/tls-acme kubernetes.io/tls-acme: cert-manager.io/cluster-issuer: letsencrypt-prod "true" The next thing is to configure my ingress. I need to specify that I’m using TLS for my ingress and issue a certificate for this domain name. This domain name corresponds to the external IP address that Google Cloud Platform provided. spec:
  tls:
    - secretName: kong.gamov.dev
      hosts:
        - kong.gamov.dev It’s the same configuration rules for the particular path. By default, that will correspond to my Dune Quote service. - path: /
            pathType: ImplementationSpecific
            backend:
              service:
                name: dune-quote-service
                port:
                  number: 9001 Inbound traffic will listen on gRPC or gRPCS protocols. My Kong Gateway and Dune Quote service will also use the gRPCS protocol because I deployed my service using gRPCS. konghq.com/protocols: grpc,grpcs
   kubernetes.io/ingress.class: kong
   kubernetes.io/tls-acme: cert-manager.io/cluster-issuer: letsencrypt-prod "true" The next thing is to configure my ingress. I need to specify that I’m using TLS for my ingress and issue a certificate for this domain name. This domain name corresponds to the external IP address that Google Cloud Platform provided. spec:
  tls:
    - secretName: kong.gamov.dev
      hosts:
        - kong.gamov.dev It’s the same configuration rules for the particular path. By default, that will correspond to my Dune Quote service. - path: /
            pathType: ImplementationSpecific
            backend:
              service:
                name: dune-quote-service
                port:
                  number: 9001 Inbound traffic will listen on gRPC or gRPCS protocols. My Kong Gateway and Dune Quote service will also use the gRPCS protocol because I deployed my service using gRPCS. konghq.com/protocols: grpc,grpcs
   kubernetes.io/ingress.class: kong
   kubernetes.io/tls-acme: cert-manager.io/cluster-issuer: letsencrypt-prod "true" Deploy the Kubernetes Service Before we can deploy, we need to provide two secrets. We can provide the secrets with the below script. It generates a self-signed certificate and, after that, applies this certificate and key as my secrets. openssl req -x509 -nodes -subj -newkey rsa: -sha256 -keyout server.key -out server.crt -days kubectl create secret generic grpc-cert-chain -- -file=server.crt=server.crt
kubectl create secret generic grpc-pk -- -file=server.key=server.key #!/usr/bin/env bash "/CN=gamov.dev" 4096 3650 from from Next, let’s restart the deployment and bring up our service. Test the Service Once our service is up, we can use to hit the service. Insomnia In Insomnia, let’s upload our proto file. Once that’s uploaded, we’ll see two methods, GetQuote and GetQuoteStream. When we hit GetQuote, we get some quotes from Dune. It works! Next, let’s see if streaming works by switching to the GetQuoteStream. When I click , my response contains 10 responses from the gRPCS server. Nice! Start And my implementation has an interceptor that will log all the calls to my service. That’s a Wrap! In this article, I showed you how to deploy a gRPC service to Kubernetes and expose it outside of the cluster using Kong Ingress Controller. Once you’ve finished this Kubernetes Ingress gRPC example, you may find these other Kubernetes tutorials helpful: Configuring a Kubernetes Application on Kong Konnect Managing Docker Apps With Kubernetes Ingress Controller Implementing Traffic Policies in Kubernetes Have questions or want to stay in touch with the Kong community? Join us wherever you hang out: ⭐ Star us on GitHub 🐦 Follow us on Twitter 🌎 Join the Kong Community 🍻 Join our Meetups ❓ ️ Ask and answer questions on Kong Nation 💯 Apply to become a Kong Champion

Building a Dune Quote Service Using Kubernetes Ingress gRPC

A common architectural design pattern these days is to break up an application monolith into smaller microservices. Each microservice is then responsible for a specific aspect or feature of your app. For example, one microservice might be responsible for serving external API requests, while another might handle data fetching for your frontend. Designing a robust and fail-safe infrastructure in this way can be challenging; monitoring the operations of all these microservices together can be even harder. It's best not to simply rely on your application logs for an understanding of your systems' successes and errors. Setting up proper monitoring will provide you with a more complete picture, but it can be difficult to know where to start. In this post, we'll cover service areas your metrics should focus on to ensure you're not missing key insights. Before Getting Started We're going to make a few assumptions about your app setup. Don't worry—you don't need to use any specific framework to start tracking metrics. However, it does help to have a general understanding of the components involved. In other words, how you set up your observability tooling matters less than what you track. Since a sufficiently large set of microservices requires some level of coordination, we're going to assume you are using for orchestration. We're also assuming you have a time series database like or for storing your metrics data. You might also need an ingress controller, such as to control traffic flow, and a service mesh, such as , to better facilitate connections between services. Kubernetes Prometheus InfluxDB the one Kong provides Kuma Before implementing any monitoring, it's essential to know how your services actually interact with one another. Writing out a document that identifies which services and features depend on one another and how availability issues would impact them can help you strategize around setting baseline numbers for what constitutes an appropriate threshold. Types of Metrics You should be able to see data points from two perspectives: Impact Data and Causal Data. Impact Data represents information that identifies who is being impacted. For example, if there's a service interruption and responses slow down, Impact Data can help identify what percentage of your active users is affected. While Impact Data determines is being affected, Causal Data identifies is being affected and why. Kong Ingress, which can monitor network activity, can give us insight into Impact Data. Meanwhile, Kuma can collect and report Causal Data. who what Let's look at a few data sources and explore the differences between Impact Data and Causal Data that can be collected about them. Latency Latency is the amount of time it takes between a user performing an action and its final result. For example, if a user adds an item to their shopping cart, the latency would measure the time between the item addition and the moment the user sees a response that indicates its successful addition. If the service responsible for fulfilling this action degraded, the latency would increase, and without an immediate response, the user might wonder whether the site was working at all. To properly track latency in an Impact Data context, it's necessary to follow a single event throughout its entire lifetime. Sticking with our purchasing example, we might expect the full flow of an event to look like the following: The customer clicks the "Add to Cart" button The browser makes a server-side request, initiating the event The server accepts the request A database query ensures that the product is still in stock The database response is parsed, a response is sent to the user, and the event is complete To successfully follow this sequence, you should standardize on a naming pattern that identifies both what is happening and when it's happening, such as , , , and so on. Depending on your programming language, you might be able to provide a function block or lambda to the metrics service: customer_purchase.initiate customer_purchase.queried customer_purchase.finalized statsd.timing( ) # ...
end 'customer_purchase.initiate' do By providing specific keywords, you ought to hone in on which segment of the event was slow in the event of a latency issue. Tracking latency in a Causal Data context requires you to track the speed of an event between services, not just the actions performed. In practice, this means timing service-to-service requests: statsd.histogram( ) statsd.histogram( ) # ...
  end
end 'customer_purchase.initiate' do 'customer_purchase.external_database_query' do This shouldn't be limited to capturing the overall endpoint request/response cycles. That sort of latency tracking is too broad and ought to be more granular. Suppose you have a microservice with an endpoint that makes internal database requests. In that case, you might want to time the moment the request was received, how long the query took, the moment the service responded with a request, and the moment when the originating client received that request. This way, you can pinpoint precisely how the services communicate with one another. Traffic You want your application to be useful and popular—but an influx of users can be too much of a good thing if you're not prepared! Changes in site traffic can be difficult to predict. You might be able to serve user load on a day-to-day basis, but events (both expected and unexpected) can have unanticipated consequences. Is your eCommerce site running a weekend promotion? Did your site go viral because of some unexpected praise? Traffic variances can also be affected by geolocation. Perhaps users in Japan are experiencing traffic load in a way that users in France are not. You might think that your systems are working as intended, but all it takes is a massive influx of users to test that belief. If an event takes 200ms to complete, but your system can only process one event at a time, it might not seem like there's a problem—until the event queue is suddenly clogged up with work. Similar to latency, it's useful to track the number of events being processed throughout the event's lifecycle to get a sense of any bottlenecks. For example, tracking the number of jobs in a queue, the number of HTTP requests completed per second, and the number of active users are good starting points for monitoring traffic. For Causal Data, monitoring traffic involves capturing how services transmit information to one another, similar to how we did it for latency. Your monitoring setup ought to track the number of requests to specific services, their response codes, their payload sizes, and so on—as much about the request and response cycle as necessary. When you need to investigate worsening performance, knowing which service is experiencing problems will help you track the possible source much sooner. Error Rates Tracking error rates is rather straightforward. Any 5xx (or even 4xx) issued as an HTTP response by your server should be tagged and counted. Even situations that you've accounted for, such as caught exceptions, should be monitored because they still represent a non-ideal state. These issues can act as warnings for deeper problems stemming from defensive coding that doesn't address actual problems. Kuma can capture the error codes and messages thrown by your service, but this represents only a portion of actionable data. For example, you can also capture the arguments which caused the error (in case a query was malformed), the database query issued (in case it timed out), the permissions of the acting user (in case they made an unauthorized attempt), and so on. In short, capturing the state of your service at the moment it produces an error can help you replicate the issue in your development and testing environments. Saturation You should track the memory usage, CPU utilization, disk reads/writes, and available storage of each of your microservices. If your resource usage regularly spikes during certain hours or operations or increases at a steady rate, this suggests you’re overutilizing your server. While your server may be running as expected, once again, an influx of traffic or other unforeseen occurrences can quickly topple it over. Kong Ingress only monitors network activity, so it's not ideal for tracking saturation. However, there are for tracking this with Kubernetes. many tools available Implementing Monitoring and Observability Up to now, we've discussed the kinds of metrics that will be important to track in your cloud application. Next, let’s dive into some specific steps you can take to implement this monitoring and observability. Install Prometheus Prometheus is the go-to standard for monitoring, an open-source system that is easy to install and integrate with your Kubernetes setup. Installation is especially simple if you use . Helm First, we create a namespace: monitoring Next, we use Helm to install Prometheus. We make sure to add the Prometheus charts to Helm as well: $ kubectl create namespace monitoring $ helm repo add prometheus-community https: $ helm repo add stable https: $ helm repo update
$ helm install -f https: //prometheus-community.github.io/helm-charts //kubernetes-charts.storage.googleapis.com/ //bit.ly/2RgzDtg -n monitoring prometheus prometheus-community/prometheus The values file referenced at https://bit.ly/2RgzDtg sets the data scrape interval for Prometheus to ten seconds. Enable Prometheus Plugin in Kong Assuming you are using Kong Ingress Controller (KIC) for Kubernetes, your next step will be to create a custom resource—a resource—which integrates into the KIC. Create a file called : KongPlugin prometheus-plugin.yml apiVersion: configuration.konghq.com/v1
kind: KongClusterPlugin
metadata:
  name: prometheus
  annotations:
    kubernetes.io/ingress.class: kong
  labels:
    global: plugin: prometheus "true" Install Grafana Grafana is an observability platform that provides excellent dashboards for visualization of data scraped by Prometheus. We use Helm to install Grafana as follows: $ helm install grafana stable/grafana -n monitoring --values http: //bit.ly/2FuFVfV You can view the bit.ly URL in the above command to see the specific configuration values for Grafana that we provide upon installation. Enable Port Forwarding Now that Prometheus and Grafana are up and running in our Kubernetes cluster, we'll need access to their dashboards. For this article, we'll set up basic port forwarding to expose those services. This is a simple—but not very secure—way to get access, but not advisable for production deployments. $ POD_NAME=$(kubectl get pods --namespace monitoring -l -o jsonpath= )
kubectl --namespace monitoring  port-forward $POD_NAME &
 
$ POD_NAME=$(kubectl get pods --namespace monitoring -l -o jsonpath= )
kubectl --namespace monitoring port-forward $POD_NAME & "app=prometheus,component=server" "{.items[0].metadata.name}" 9090 "app.kubernetes.io/instance=grafana" "{.items[0].metadata.name}" 3000 The above two commands expose the Prometheus server on port and the Grafana dashboard on port . 9090 3000 Those simple steps should be sufficient to set you off and running. With Kong Ingress Controller and its integrated Prometheus plugin, capturing metrics with Prometheus and visualizing them with Grafana are quick and simple to set up. Conclusion Whenever you need to investigate worsening performance, your Impact Data metrics can help orient you on the magnitude of the problem: it should tell you how many people are affected. Likewise, your Causal Data identifies what isn't working and why. The former points you to the plume of smoke, and the latter takes you to the fire. In addition to all of the above, you should also consider the rate at which your metrics are changing. For example, say your traffic numbers are increasing. Observing how quickly those numbers are moving can help you determine when (or if) it'll become a problem. This is essential for managing upcoming work with regular deployments and changes to your services. It also establishes what an ideal performance metric should be. , which is a must-read for any developer. If you're already running Kong alongside your clusters, plugins integrate directly with Prometheus, which means less configuration on your part to monitor and store metrics for your services. Google wrote an entire book on site reliability such as this one

4 Key Observability Metrics for Distributed Applications

is an open-source API client that helps you test and debug GraphQL, gRPC, and REST API endpoints. As powerful as Insomnia is, sometimes you want to extend its functionality even further, which you can do with . Insomnia plugins There are many great plugins available on the , all contributed by the open-source community. Even more exciting, if you’d like to contribute, you can build your own plugin! Insomnia Plugin Hub In this article, we’ll explore a plugin I built and then show you how you can build an Insomnia plugin of your own. Plugin Demo My plugin is a simple addition that allows you to initiate all the requests in a folder and then displays a desktop notification once all the requests have been completed. If you’re a habitual multitasker like myself, you probably rapidly cycle through several apps at a time while you’re working. Your IDE, your terminal, your browser, and Insomnia may be a few. In the event that you have a large number of requests in your folder and don’t want to wait for them to all finish, you can move on to something else while you wait, and then be notified once the job is complete. You can or . find my plugin’s package on npm view the GitHub repo here Plugin Installation You can install Insomnia plugins through the settings page in your Insomnia desktop app. Simply click the gear icon in the top-right corner of the app, then choose the “Plugins” tab. Search for any plugin name in the text input, and then click the “Install Plugin” button to add the plugin to your app. In the case of my plugin, the name is . insomnia-plugin-requests-desktop-notification Plugin Usage Once you have the plugin installed, you’re ready to start using it — no need to restart your Insomnia app. There are several variations of plugins. Some add behavior to various hooks, like . Others in the app. You can even install a via a plugin. request hooks or response hooks add new items to dropdown menus custom theme My plugin adds a new item to the dropdown menu for a request folder. To see it in action, you can navigate to the “Debug” area of your Insomnia app. Then, create a new folder and add some requests to it (or use an existing folder if you already have one). Next, click the dropdown trigger button to the right of the folder name to open the dropdown menu. Among the default menu items, you’ll also now see a custom menu item that my plugin adds: “Send All Requests.” Select that menu item to send all the requests in your folder. Once all the requests have been completed, a desktop notification will appear on your machine. Ta-da! How to Build an Insomnia Plugin So, how did I build this? Well, it’s actually quite simple! The plugin is a small JavaScript app that consists of a file and a file. For the desktop notification functionality, I used the npm package. main.js package.json node-notifier When , you can bootstrap your plugin by navigating to the settings screen in your Insomnia app, clicking the “Plugins” tab, and then clicking the “Generate New Plugin” button. creating a new Insomnia plugin This will create a new directory for your plugin and place it in a folder in which Insomnia keeps all of its plugins locally. It also creates the and files for you automatically. main.js package.json From there, I wrote the following code in my file. Look how short it is! main.js const notifier = require('node-notifier');
const path = require('path');

module.exports.requestGroupActions = [
  {
    label: 'Send All Requests',
    action: async (context, data) => {
      const { requests } = data;

      for (const request of requests) {
        await context.network.sendRequest(request);
      }

      notifier.notify({
        title: 'Insomnia Requests Complete',
        message: `Finished sending all ${requests.length} requests!`,
        icon: path.join(__dirname, 'insomnia-logo.png'),
        sound: true,
      });
    },
  },
]; Let’s walk through this code together. First, it requires the two dependencies that we rely on: and . is a built-in module, but I needed to install by running in my terminal. path node-notifier path node-notifier yarn add node-notifier The main part of the code adds a new entry to the array. This is what creates the new menu item in the dropdown menu for our request folder. The is the menu item’s text, and the is what code we want to run when someone selects that menu item. requestGroupActions label action In the action function, we do the following: Gather all the requests in the folder. Send them. Call once all the requests have been completed. The , , , and properties all configure our desktop notification. notifier.notify title message icon sound That’s it! The plugin really is that simple. Once I wrote this code, I was able to navigate to the settings page of my Insomnia app, then the “Plugins” tab, then click the “Reload Plugins” button to reload the latest changes. After that, the menu item appeared in my request folder’s dropdown menu. Publishing to npm After writing my plugin, I had everything working nicely locally. But I also wanted to share this plugin with the broader community. In order to do that, I needed to publish it to npm. To do so, I pushed the latest code to my GitHub repo, logged into my npm account with , and then published my package using . npm login npm publish After publishing the initial version of the package, I was able to make a few updates to the code, generate a new package version with , push the tags to GitHub with , push the code to GitHub with , and then publish the new package version to npm with . npm version <major|minor|patch> git push --tags git push npm publish Once my package was published in the npm registry, it was automatically added to the Insomnia Plugin Hub within the next 24 hours. Conclusion There you have it — how I built my very own Insomnia plugin and how you can too. To recap, Insomnia is great for building, testing, and debugging APIs. Plugins let you extend Insomnia’s functionality. Building your own custom plugin is easy — you can add new functionality with just a few lines of code!

How I Built My Own Insomnia Plugin

Asia is one of the biggest crypto markets on the earth, among the European Union and the USA. Hong Kong became the first jurisdiction on this continent to approve Bitcoin and Ethereum ETF. Regulators can give investors access to Bitcoin and Ethereum ETFs in two ways. The first option is to allow qualified investors to invest in foreign Bitcoin ETFs, which Thailand already did in March of this year. And recently, Thailand approved a local Bitcoin ETF in May. Let's talk about a few more countries in the region where ETF approval may affect the overall crypto market capitalization. It looks like the most prospective countries for crypto ETF approval now are South Korea, Taiwan, and maybe Japan and Singapore. South Korea This country has a wide level of crypto adoption. Just one fact to mention - in the first quarter of this year, the Korean Won was leading in crypto to fiat trading volume on centralized exchanges ($456 bln), it has even surpassed the US dollar ($445 bln). Despite that, this January, the local regulator rejected local Bitcoin ETFs. But the situation changed in April - then, the Democratic party declared ETF approval as a part of its сampaign - and this party won elections in the local parliament. However, crypto ETF approval in South Korea at least needs some legislative actions based on local experts. Also, there is a sign that Korea continues to tighten crypto regulations - local regulator FSC is tightening its approach to the NFT. With this in mind, it is still not very clear how the ruling party will fulfill its promises if the regulator has a different stance. At least don't count on the rapid adoption of Bitcoin ETFs in Korea, although it is quite possible in the medium term In July, the Korean Act on the Protection of Virtual Asset Users will come into power. The new ruling party has just gained control of the parliament, so we'll have to wait to see how their approach to crypto regulation changes after the election. Japan The adoption of Bitcoin ETFs is a gradual process - one indication that it is likely is the regulator's loyalty to the purchase of Bitcoin by large publicly traded companies. This is what Microstrategy did in the US, and now Metaplanet is doing it in Japan - it has publicly disclosed its Bitcoin savings. The stock price jumped 127% for 1 week in May. Metaplanet's rise is a sure sign of demand in Japan for a Bitcoin ETF counterpart before it officially exists. The approval of Japan's own bitcoin ETFs is still on the table. As in Thailand, Japanese stock exchanges need regulatory approval to make U.S. Bitcoin ETFs available. And there's no information yet to make it happen. But the growing demand and high elaboration of crypto regulation in the country, and competition with other Asian exchanges, primarily with Hong Kong, may push the process this year. Taiwan Approval of crypto ETFs as investing products in Taiwan is likely to happen in 2024, but still stays uncertain. Currently, this jurisdiction still has some gaps in its crypto regulations for VASPs and AML. New rules for crypto probably will be presented only in September 2024. Any decisions on crypto spot ETFs for the local market will probably be delayed up to this date. However, currently in Taiwan, it’s already possible to buy US crypto ETFs for residents of Taiwan using local brokers. But there has yet to be a resolution from the local regulator on this. Last but not least, the Taiwanese ETF market is now booming with more than $123 bln in capitalization. This means that regulators have a relatively innovative approach to crypto regulations and can approve crypto ETFs, too. Singapore The approval of Bitcoin ETFs in Singapore depends on the local finance regulator, the Monetary Authority of Singapore (MAS). This March, the regulator published a notice stating that it doesn't want to give retail investors access to crypto ETFs. Local brokers follow this approach, either giving access to US spot Bitcoin ETFs for retail investors with special notice or not giving it at all. At the same time, Singapore has a significant demand for Bitcoin ETFs. Based on an Independent Reserve survey this March, about one-third of locals would like to invest in Spot Bitcoin ETF. So Singapore likely won't be the next jurisdiction according to the position of the local authorities, but again, the high activity of crypto asset lobbyists and the level of adopting institutional investors is forcing regulators to accelerate. UAE The United Arab Emirates has a good crypto regulation framework and may be classified as a crypto offshore of Asia. At the same time, there is no evidence that this jurisdiction plans to introduce Bitcoin ETFs this year. But there is a high demand for it - according to Bitget research, 72% of local users are interested in cryptocurrencies. So currently in Dubai, there are available crypto futures derivatives, but not ETFs. Also, local regulators need a clear policy about Bitcoin ETFs. Next Wave: India and Other Large Economies? India and Indonesia are the only countries in the world, which imposed tax on crypto transactions and basically have an unfavorable approach to crypto regulation. At the same time, these countries have a relatively high level of stock market capitalization. Moreover, in India, local investors have a right to invest outside a country up to $250,000 per year and purchase securities. They already can invest in foreign crypto ETFs by this rule. So probably after leading in fintech innovation countries like South Korea, Japan, Singapore, and others approve Bitcoin ETF, India may join. Also, there's a chance that mainland China will get access to crypto ETFs at some point. Roughly, the same can be said about the positions of regulators in the Philippines and most Arab Asian countries - they will see how ETFs trade in other jurisdictions in the region and only then join. Probably these jurisdictions won't approve any crypto ETFs in 2024. Conclusion With the growing demand for crypto in most of the major economies in Asia, we can likely wait for crypto ETF approval in South Korea and 2-3 more Asian jurisdictions this year. The main reason why this can happen - the presence of ETFs in other countries such as the US and Hong Kong. The absence of Bitcoin ETFs on local exchanges will provoke an outflow of crypto investors' funds to jurisdictions where such investment instruments are legal Asia is one of the biggest crypto markets on the earth, among the European Union and the USA. Hong Kong became the first jurisdiction on this continent to approve Bitcoin and Ethereum ETF. Regulators can give investors access to Bitcoin and Ethereum ETFs in two ways. The first option is to allow qualified investors to invest in foreign Bitcoin ETFs, which Thailand already did in March of this year. And recently, Thailand approved a local Bitcoin ETF in May. Let's talk about a few more countries in the region where ETF approval may affect the overall crypto market capitalization. It looks like the most prospective countries for crypto ETF approval now are South Korea, Taiwan, and maybe Japan and Singapore. South Korea This country has a wide level of crypto adoption. Just one fact to mention - in the first quarter of this year, the Korean Won was leading in crypto to fiat trading volume on centralized exchanges ($456 bln), it has even surpassed the US dollar ($445 bln). Despite that, this January, the local regulator rejected local Bitcoin ETFs. But the situation changed in April - then, the Democratic party declared ETF approval as a part of its сampaign - and this party won elections in the local parliament. However, crypto ETF approval in South Korea at least needs some legislative actions based on local experts. rejected Also, there is a sign that Korea continues to tighten crypto regulations - local regulator FSC is tightening its approach to the NFT. With this in mind, it is still not very clear how the ruling party will fulfill its promises if the regulator has a different stance. At least don't count on the rapid adoption of Bitcoin ETFs in Korea, although it is quite possible in the medium term In July, the Korean Act on the Protection of Virtual Asset Users will come into power. The new ruling party has just gained control of the parliament, so we'll have to wait to see how their approach to crypto regulation changes after the election. Japan The adoption of Bitcoin ETFs is a gradual process - one indication that it is likely is the regulator's loyalty to the purchase of Bitcoin by large publicly traded companies. This is what Microstrategy did in the US, and now Metaplanet is doing it in Japan - it has publicly disclosed its Bitcoin savings. The stock price jumped 127% for 1 week in May. Metaplanet's rise is a sure sign of demand in Japan for a Bitcoin ETF counterpart before it officially exists. The approval of Japan's own bitcoin ETFs is still on the table. As in Thailand, Japanese stock exchanges need regulatory approval to make U.S. Bitcoin ETFs available. And there's no information yet to make it happen. But the growing demand and high elaboration of crypto regulation in the country, and competition with other Asian exchanges, primarily with Hong Kong, may push the process this year. Taiwan Approval of crypto ETFs as investing products in Taiwan is likely to happen in 2024, but still stays uncertain. Currently, this jurisdiction still has some gaps in its crypto regulations for VASPs and AML. New rules for crypto probably will be presented only in September 2024. Any decisions on crypto spot ETFs for the local market will probably be delayed up to this date. However, currently in Taiwan, it’s already possible to buy US crypto ETFs for residents of Taiwan using local brokers. But there has yet to be a resolution from the local regulator on this. Last but not least, the Taiwanese ETF market is now booming with more than $123 bln in capitalization. This means that regulators have a relatively innovative approach to crypto regulations and can approve crypto ETFs, too. Singapore The approval of Bitcoin ETFs in Singapore depends on the local finance regulator, the Monetary Authority of Singapore (MAS). This March, the regulator published a notice stating that it doesn't want to give retail investors access to crypto ETFs. Local brokers follow this approach, either giving access to US spot Bitcoin ETFs for retail investors with special notice or not giving it at all. At the same time, Singapore has a significant demand for Bitcoin ETFs. Based on an Independent Reserve survey this March, about one-third of locals would like to invest in Spot Bitcoin ETF. So Singapore likely won't be the next jurisdiction according to the position of the local authorities, but again, the high activity of crypto asset lobbyists and the level of adopting institutional investors is forcing regulators to accelerate. UAE UAE The United Arab Emirates has a good crypto regulation framework and may be classified as a crypto offshore of Asia. At the same time, there is no evidence that this jurisdiction plans to introduce Bitcoin ETFs this year. But there is a high demand for it - according to Bitget research, 72% of local users are interested in cryptocurrencies. So currently in Dubai, there are available crypto futures derivatives, but not ETFs. Also, local regulators need a clear policy about Bitcoin ETFs. Next Wave: India and Other Large Economies? India and Indonesia are the only countries in the world, which imposed tax on crypto transactions and basically have an unfavorable approach to crypto regulation. At the same time, these countries have a relatively high level of stock market capitalization. Moreover, in India, local investors have a right to invest outside a country up to $250,000 per year and purchase securities. They already can invest in foreign crypto ETFs by this rule. So probably after leading in fintech innovation countries like South Korea, Japan, Singapore, and others approve Bitcoin ETF, India may join. Also, there's a chance that mainland China will get access to crypto ETFs at some point. Roughly, the same can be said about the positions of regulators in the Philippines and most Arab Asian countries - they will see how ETFs trade in other jurisdictions in the region and only then join. Probably these jurisdictions won't approve any crypto ETFs in 2024. Conclusion Conclusion With the growing demand for crypto in most of the major economies in Asia, we can likely wait for crypto ETF approval in South Korea and 2-3 more Asian jurisdictions this year. The main reason why this can happen - the presence of ETFs in other countries such as the US and Hong Kong. The absence of Bitcoin ETFs on local exchanges will provoke an outflow of crypto investors' funds to jurisdictions where such investment instruments are legal

Hong Kong and Thailand Approved Crypto ETFs: Who Is Next in Asia?

**HONG KONG, Hong Kong, June 5th, 2024/Chainwire/--**Web3 Foundation, the entity supporting the growth of the Polkadot ecosystem, has awarded a grant to PolkaPort East. The Decentralized Futures (DF) grant is designed to help further decentralize Polkadot while spearheading technical, community, and broader ecosystem adoption. PolkaPort East is an independent entity leading investor relations and growth initiatives for Polkadot centered on Hong Kong and the Greater Bay Area. The DF grant from the Web3 Foundation is the first such award to be received by an organization working in Asia.The grant will support PolkaPort East’s goals of leading investor relations and growth for Polkadot in the region. Its mandate also includes promoting Polkadot and its technology, and acting as a key regional driver of capital into the ecosystem. Max Rebol, co-founder of PolkaPort East and CEO of Harbour Industrial Capital, a Polkadot-focused VC fund, said: “The launch of PolkaPort East comes at a crucial moment for Polkadot. It represents a critical step towards increasing the network’s decentralization while strengthening the ecosystem’s strategic position in Hong Kong.” Thibault Perréard, also a co-founder who heads up strategy for Bifrost, a leading Polkadot parachain added: “With the support of the DF grant, PolkaPort East will be tapping into the thriving innovation hubs of Hong Kong and the Greater Bay Area while engaging and fostering relationships with local governments, global enterprises and capital allocators of the region.” Vincent Chan, the third co-founder of PolkaPort East who formerly led growth initiatives at Parity Technologies, explained that following the receipt of the DF grant, the initiative will seek to attract participants to the Polkadot ecosystem across Asia. These include projects and developers looking to build on Polkadot, Polkadot-native VCs, funds, and capital allocators, as well as general web3 investors. It will also target Asian university blockchain collectives and associations, fintechs seeking to enter web3, and local government exploring the use of blockchain technology. Speaking on behalf of the Web3 Foundation, David Hawig, the Director of Ecosystem, stated “The Web3 Foundation is thrilled to support the Polkaport East initiative through a Decentralized Futures grant. This project exemplifies our commitment to fostering decentralized access and innovation within the Polkadot ecosystem. We believe Polkaport East will play a pivotal role in enhancing connectivity and empowering the community in Hong Kong, driving forward the vision of a truly decentralized internet.” About Decentralized Futures The DF initiative developed by Web3 Foundation is designed to kickstart independent teams and initiative that will drive Polkadot’s success. It was established in 2023 following the restructuring of Parity Technologies which offloaded responsibilities for investor relations, growth and marketing to focus solely on technical development. Through the DF program, funding is available for Polkadot-focused organizations that aim to generate profit, as well as for non-profits that have a strategy to secure ongoing financing through Polkadot's onchain treasury system. An initial $20M plus 5M DOT tokens have been allocated to Decentralized Futures to expand the Polkadot ecosystem. About PolkaPort East Based in Hong Kong, PolkaPort East is an organization tasked with spurring adoption of the Polkadot ecosystem in Asia with a focus on Hong Kong and the Greater Bay Area. By working with different entities ranging from developers to investors, PolkaPort East will help to fuel adoption of web3 technology and onboard new users to Polkadot. Contact DIrector Thibault Perréard Polkaport East contact@polkaporteast.xyz This story was distributed as a release by Chainwire under HackerNoon’s Business Blogging Program. Learn more about the program here. **HONG KONG, Hong Kong, June 5th, 2024/Chainwire/--**Web3 Foundation, the entity supporting the growth of the Polkadot ecosystem, has awarded a grant to PolkaPort East. The Decentralized Futures (DF) grant is designed to help further decentralize Polkadot while spearheading technical, community, and broader ecosystem adoption. PolkaPort East is an independent entity leading investor relations and growth initiatives for Polkadot centered on Hong Kong and the Greater Bay Area. The DF grant from the Web3 Foundation is the first such award to be received by an organization working in Asia.The grant will support PolkaPort East’s goals of leading investor relations and growth for Polkadot in the region. Its mandate also includes promoting Polkadot and its technology, and acting as a key regional driver of capital into the ecosystem. Max Rebol, co-founder of PolkaPort East and CEO of Harbour Industrial Capital, a Polkadot-focused VC fund, said: “The launch of PolkaPort East comes at a crucial moment for Polkadot. It represents a critical step towards increasing the network’s decentralization while strengthening the ecosystem’s strategic position in Hong Kong.” Max Rebol, co-founder of PolkaPort East and CEO of Harbour Industrial Capital, a Polkadot-focused VC fund, said: “The launch of PolkaPort East comes at a crucial moment for Polkadot. It represents a critical step towards increasing the network’s decentralization while strengthening the ecosystem’s strategic position in Hong Kong.” Thibault Perréard, also a co-founder who heads up strategy for Bifrost, a leading Polkadot parachain added: “With the support of the DF grant, PolkaPort East will be tapping into the thriving innovation hubs of Hong Kong and the Greater Bay Area while engaging and fostering relationships with local governments, global enterprises and capital allocators of the region.” Thibault Perréard, also a co-founder who heads up strategy for Bifrost, a leading Polkadot parachain added: “With the support of the DF grant, PolkaPort East will be tapping into the thriving innovation hubs of Hong Kong and the Greater Bay Area while engaging and fostering relationships with local governments, global enterprises and capital allocators of the region.” Vincent Chan, the third co-founder of PolkaPort East who formerly led growth initiatives at Parity Technologies, explained that following the receipt of the DF grant, the initiative will seek to attract participants to the Polkadot ecosystem across Asia. These include projects and developers looking to build on Polkadot, Polkadot-native VCs, funds, and capital allocators, as well as general web3 investors. It will also target Asian university blockchain collectives and associations, fintechs seeking to enter web3, and local government exploring the use of blockchain technology. Speaking on behalf of the Web3 Foundation, David Hawig, the Director of Ecosystem, stated “The Web3 Foundation is thrilled to support the Polkaport East initiative through a Decentralized Futures grant. This project exemplifies our commitment to fostering decentralized access and innovation within the Polkadot ecosystem. We believe Polkaport East will play a pivotal role in enhancing connectivity and empowering the community in Hong Kong, driving forward the vision of a truly decentralized internet.” Speaking on behalf of the Web3 Foundation, David Hawig, the Director of Ecosystem, stated “The Web3 Foundation is thrilled to support the Polkaport East initiative through a Decentralized Futures grant. This project exemplifies our commitment to fostering decentralized access and innovation within the Polkadot ecosystem. We believe Polkaport East will play a pivotal role in enhancing connectivity and empowering the community in Hong Kong, driving forward the vision of a truly decentralized internet.” About Decentralized Futures The DF initiative developed by Web3 Foundation is designed to kickstart independent teams and initiative that will drive Polkadot’s success. It was established in 2023 following the restructuring of Parity Technologies which offloaded responsibilities for investor relations, growth and marketing to focus solely on technical development. Through the DF program, funding is available for Polkadot-focused organizations that aim to generate profit, as well as for non-profits that have a strategy to secure ongoing financing through Polkadot's onchain treasury system. An initial $20M plus 5M DOT tokens have been allocated to Decentralized Futures to expand the Polkadot ecosystem. About PolkaPort East Based in Hong Kong, PolkaPort East is an organization tasked with spurring adoption of the Polkadot ecosystem in Asia with a focus on Hong Kong and the Greater Bay Area. By working with different entities ranging from developers to investors, PolkaPort East will help to fuel adoption of web3 technology and onboard new users to Polkadot. PolkaPort East PolkaPort East Contact DIrector Thibault Perréard Polkaport East contact@polkaporteast.xyz This story was distributed as a release by Chainwire under HackerNoon’s Business Blogging Program. Learn more about the program here. This story was distributed as a release by Chainwire under HackerNoon’s Business Blogging Program. Learn more about the program here . here here

Polkadot Enhances Decentralization in Ecosystem Growth With PolkaPort East Launch In Hong Kong

Exciting news! 🏆 Debt Hunter won the trending Startups of the Year in Hong Kong, HackerNoon's Startups of the Year 2023. Huge thanks to everyone who nominated. Your support means the world to us! 🥂 What does it mean for you to win this title? Hi everyone! My name is Obis Tsang, and I am the founder of Debt Hunter. I am delighted to be here and share more about my team! Winning the Hackernoon Startups of the Year 2023 award is an incredible honor for Debt Hunter. It's a testament to our team's hard work, dedication, and commitment to providing exceptional debt collection services in Hong Kong. What sets you apart from the competition? Debt Hunter stands out from the competition by combining psychology, technology, and legal expertise to achieve optimal recovery rates. Our team of 20+ professional personnel utilizes advanced techniques and exclusive credit databases to locate and negotiate with debtors effectively. What do you love about your team, and why are you the ones to solve this problem? Our team is passionate about protecting the rights of SMEs and ensuring a secure business environment. Their unwavering determination, expertise, and ability to balance 'legality' and 'effectiveness' make them the ideal team to solve the problem of commercial debt collection in Hong Kong. If you weren’t building your startup, what would you be doing? If I were not building Debt Hunter, I would be pursuing a career in the legal profession. My passion for justice and protecting the rights of others would drive me in these fields. At the moment, how do you measure success? What are your core metrics? We measure our success by our recovery rate, client satisfaction, and the impact we have on the business environment in Hong Kong. Our core metrics include the percentage of debts collected, the number of satisfied clients, and the reduction in commercial disputes arising from payment delays and quality issues. Tell us how your startup is changing the world. Debt Hunter is changing the world by providing SMEs with a reliable and effective solution to recover unpaid debts. We empower businesses to protect their financial interests, maintain cash flow, and operate with confidence. How do you or your company intend to embrace the responsibility of this title in 2024? As the winner of Hackernoon Startups of the Year 2023 in Hong Kong, Debt Hunter will continue to uphold the highest standards of ethical and professional conduct. We will strive to innovate and enhance our services to meet the evolving needs of our clients. What goals are you looking forward to accomplishing in 2024? In 2024, we aim to: Increase our recovery rate by 5%
Expand our team to meet the growing demand
Develop new technologies to improve our debt collection process Which trend(s) are you most excited about in 2024? Share your reasons. We are excited about the trend towards increased automation and data analytics in the debt collection industry. These technologies can streamline processes, improve efficiency, and provide valuable insights into debtor behavior. 2023 had been another crazy year, especially in tech, with layoffs and the Generative AI takeover! Which trend are you most concerned about? Be as brief or as detailed as you like. We are concerned about the potential impact of Generative AI on the debt collection industry. While AI can enhance certain aspects of our work, it's crucial to ensure that it is used ethically and responsibly to protect the rights of both creditors and debtors. Share your biggest success so far and/or your biggest failure so far. Our biggest success was recovering a significant debt for a small business that was facing financial hardship. The recovery allowed the business to continue operating and avoid bankruptcy. Our biggest failure was an unsuccessful attempt to collect a debt from a debtor who had intentionally concealed their assets. We would love your feedback on HackerNoon as a tech publication! How has your experience been with us? Our experience with HackerNoon has been positive. The platform provides valuable insights into the latest tech trends and offers a great opportunity to connect with other startups and industry professionals. Any words of wisdom you’d like to share with us? Never give up on your dreams. Embrace challenges as opportunities for growth. Surround yourself with a supportive team, and don't be afraid to ask for help when needed. Contact Debt Hunter today to solve your bad debt troubles! ➡ https://www.debt-hunter.com/en 收數公司做法係點？喺香港搵收數公司要注意啲咩？ ➡ https://www.debt-hunter.com/blog/2023011301 Exciting news! 🏆 Debt Hunter won the trending Startups of the Year in Hong Kong, HackerNoon's Startups of the Year 2023. Huge thanks to everyone who nominated. Your support means the world to us! 🥂 Exciting news! 🏆 Debt Hunter won the trending Startups of the Year in Hong Kong, HackerNoon's Startups of the Year 2023. Huge thanks to everyone who nominated. Your support means the world to us! 🥂 Debt Hunter What does it mean for you to win this title? Hi everyone! My name is Obis Tsang, and I am the founder of Debt Hunter. I am delighted to be here and share more about my team! Winning the Hackernoon Startups of the Year 2023 award is an incredible honor for Debt Hunter. It's a testament to our team's hard work, dedication, and commitment to providing exceptional debt collection services in Hong Kong. What sets you apart from the competition? Debt Hunter stands out from the competition by combining psychology, technology, and legal expertise to achieve optimal recovery rates. Our team of 20+ professional personnel utilizes advanced techniques and exclusive credit databases to locate and negotiate with debtors effectively. What do you love about your team, and why are you the ones to solve this problem? Our team is passionate about protecting the rights of SMEs and ensuring a secure business environment. Their unwavering determination, expertise, and ability to balance 'legality' and 'effectiveness' make them the ideal team to solve the problem of commercial debt collection in Hong Kong. If you weren’t building your startup, what would you be doing? If I were not building Debt Hunter, I would be pursuing a career in the legal profession. My passion for justice and protecting the rights of others would drive me in these fields. At the moment, how do you measure success? What are your core metrics? We measure our success by our recovery rate, client satisfaction, and the impact we have on the business environment in Hong Kong. Our core metrics include the percentage of debts collected, the number of satisfied clients, and the reduction in commercial disputes arising from payment delays and quality issues. Tell us how your startup is changing the world. Debt Hunter is changing the world by providing SMEs with a reliable and effective solution to recover unpaid debts. We empower businesses to protect their financial interests, maintain cash flow, and operate with confidence. How do you or your company intend to embrace the responsibility of this title in 2024? As the winner of Hackernoon Startups of the Year 2023 in Hong Kong, Debt Hunter will continue to uphold the highest standards of ethical and professional conduct. We will strive to innovate and enhance our services to meet the evolving needs of our clients. What goals are you looking forward to accomplishing in 2024? In 2024, we aim to: Increase our recovery rate by 5% Expand our team to meet the growing demand Develop new technologies to improve our debt collection process Increase our recovery rate by 5% Expand our team to meet the growing demand Develop new technologies to improve our debt collection process Which trend(s) are you most excited about in 2024? Share your reasons. We are excited about the trend towards increased automation and data analytics in the debt collection industry. These technologies can streamline processes, improve efficiency, and provide valuable insights into debtor behavior. 2023 had been another crazy year, especially in tech, with layoffs and the Generative AI takeover! Which trend are you most concerned about? Be as brief or as detailed as you like. We are concerned about the potential impact of Generative AI on the debt collection industry. While AI can enhance certain aspects of our work, it's crucial to ensure that it is used ethically and responsibly to protect the rights of both creditors and debtors. Share your biggest success so far and/or your biggest failure so far. Our biggest success was recovering a significant debt for a small business that was facing financial hardship. The recovery allowed the business to continue operating and avoid bankruptcy. Our biggest failure was an unsuccessful attempt to collect a debt from a debtor who had intentionally concealed their assets. We would love your feedback on HackerNoon as a tech publication! How has your experience been with us? Our experience with HackerNoon has been positive. The platform provides valuable insights into the latest tech trends and offers a great opportunity to connect with other startups and industry professionals. Any words of wisdom you’d like to share with us? Never give up on your dreams. Embrace challenges as opportunities for growth. Surround yourself with a supportive team, and don't be afraid to ask for help when needed. Contact Debt Hunter today to solve your bad debt troubles! Contact Debt Hunter today to solve your bad debt troubles! ➡ https://www.debt-hunter.com/en https://www.debt-hunter.com/en 收數公司做法係點？喺香港搵收數公司要注意啲咩？ 收數公司做法係點？喺香港搵收數公司要注意啲咩？ ➡ https://www.debt-hunter.com/blog/2023011301 https://www.debt-hunter.com/blog/2023011301

Stories, News & Mentions about KONG

Kong’s Stories on HackerNoon