Kong Gateway for MuleSoft Users: Taming the Gorilla

Introduction

I've worked with MuleSoft for the past decade and consider myself a skilled and experienced integration consultant. However, and I'm sure many of you will agree, although immersion in a single technology has its upsides in terms of skills and career progression, it can have one crucial downside — that being a lack of knowledge and understanding of similar but different technologies (i.e., those considered to be competitors to your main focus).

With that in mind, I decided to examine those other technologies to broaden my knowledge and gain greater insight into Integration. In this blog, I'll examine?Kong API Gateway?to understand what it does, how it works, and how it competes with MuleSoft.

However, please note that this blog is not a battle to determine which is better. Even if I wanted to do that, I don't think it would be helpful or possible — my knowledge is disproportionately skewed towards MuleSoft. Any such statements I made would not be considered unbiased.

I only wanted to investigate other technologies and explain them in a way that would be helpful to other MuleSoft architects and developers.

Why Kong?

I've explained why I wanted to look at other integration tools, but why did I choose Kong?

I'm sure many of you have seen Gartner's Magic Quadrant charts. Below is the chart for?API Gateways. MuleSoft and other familiar names like Google and Microsoft are in the top-right corner.?

But you'll also see Kong.

“Kong is also considered a Leader, but I know nothing about it — let’s take a look.”

First, API Gateways…

First, let's clarify what an API Gateway is and is not. Which part of Anypoint Platform is the API Gateway (Anypoint Platform is technically an?iPaaS?— so it contains many different features and functions).

Understanding API Gateways

At its core, an API gateway is a centralised entry point for client requests to access backend APIs. It streamlines communication between clients and services by providing essential functionalities such as routing, security, monitoring, and transformation. Think of it as a traffic controller, orchestrating data flow between disparate systems while enforcing security measures and optimising performance.

Essential Functions of an API Gateway

• Routing: Directing client requests to the appropriate backend services based on predefined rules.
• Security: Implementing authentication, authorisation, and encryption to ensure secure communication.
• Transformation: Manipulating request and response payloads to match the expected formats.
• Rate Limiting: Controlling the rate of incoming requests to prevent overload.
• Monitoring and Analytics: Gathering metrics and logging data to monitor API usage and performance.
• Caching: Storing frequently accessed data to improve response times.
• Load Balancing: Distributing incoming requests across multiple instances for scalability and reliability.

Example Use Case

Imagine a microservices-based e-commerce application with services like user management, product catalogues, shopping carts, and payment processing. Instead of exposing these services to clients, an API gateway sits in front, acting as a unified interface. When a client wants to view product details, it sends a request to the API gateway, which then routes it to the appropriate product catalogue service. Similarly, when placing an order, the client interacts with the API gateway, which coordinates requests with the shopping cart and payment processing services.

So, to summarise

In terms of Anypoint Platform, we are looking at the API Manager.

Another feature often considered a component of an API Gateway (though not as core as what's already listed above) allows for the discoverability and documentation of APIs. In MuleSoft, we are talking about Exchange and the Developer Portal.

So Anypoint Platform contains an API Gateway, but as I have already said, it's an iPaaS (i.e. a complete integration solution allowing you to design, build, run and monitor APIs). Kong isn't that and doesn't claim to be - it only claims to be an API Gateway. Does this mean that MuleSoft is better??

“Surely, it is, as it can do more!”

No, that is looking at it too simplistically, and we can't jump to that conclusion. It comes down to the use case and what solution meets the requirements under consideration. Think of the following two situations.

• An organisation has multiple APIs written in various languages (non-MuleSoft). This organisation doesn’t need or want to use MuleSoft to build or manage APIs.
• An organisation has multiple MuleSoft APIs deployed to CloudHub and may have other APIs written in different languages deployed elsewhere. They are happy with MuleSoft and intend to keep using it.

So, you can see two different situations here. Both use APIs, but they are built and deployed differently. What would be the best solution for each??

The first organisation could use MuleSoft and Anypoint Platform to manage their existing APIs (via Flex Gateway). But they don’t want to, nor do they need to. They have functioning APIs but only need to control access — a use case suited to Kong API Gateway. All the additional features of Anypoint Platform would go unused. I’d consider MuleSoft to be overkill in this situation.

What about the second organisation? Well, they are happy using MuleSoft and have APIs deployed to CloudHub. They’ll continue to build APIs using MuleSoft. They need to use the Mule Gateway and API Manager in Anypoint Platform. Note, though, if they do have other APIs built outside the MuleSoft ecosystem, that doesn’t mean they need to manage them separately with an external API Gateway such as Kong — they can use Flex Gateway: a bolt-on to Anypoint Platform that allows the API Manager to manage non-MuleSoft APIs.

So, deciding when to use MuleSoft instead of Kong depends entirely on the situation and the most suitable solution.

Kong Concepts

Now, let's delve a little deeper into Kong's functionality. How do we use it? How do we manage APIs? Let's look at this from a familiar perspective and equate it roughly to functionality in MuleSoft.?

Kong Gateway is built around the concepts of Services and Routes. The following diagram from their website nicely illustrates this.

Routes

A Route is the exposed endpoint an API Client would call. It defines the Protocols, the Hosts, applicable HTTP methods and Headers needed in the Request. As Muley’s, we can easily understand this as the endpoint exposed by the Load Balancer.

Service

A Service is a representation of a backend API. It defines the endpoint of the API that will be hit, where messages from a specific Route will be directed. This is not something we need to fully understand when using the Mule Gateway, as Anypoint Platform automatically handles the routing of messages to APIs deployed to CloudHub. However, MuleSoft does explain the architecture of CloudHub very well for those interested.

Consumers

These entities within the Gateway, not shown in the above diagram, help manage access to any particular API. They are fundamental to applying security and other policies, restricting access to authorised clients.

Please think of this as a similar concept to how, in Anypoint Platform, we would Request Access to an API. It generates a Client ID and Secret that would be used when accessing the API.

Plugins

Plugins are a way of extending Kong's functionality. Typically, this is a way of applying security and traffic management policies to APIs, as we would apply policies to APIs through API Manager in Anypoint Platform. However, there are many different Plugins, all with a wide range of functionality (extending beyond security and traffic management). However, some of the functionality of those plugins could and would be achieved in different ways if MuleSoft were used.

Admin API

There is a UI for Kong (Kong Manager) where Routes, Services, etc., can be created, but there are also APIs that can be used to do the same. The concept of this Admin API will be familiar to MuleSoft users, who will be aware of the Platform APIs used to access entities within Anypoint Platform.

Dev Portal

Kong’s Dev Portal will also be a familiar concept. It allows for documentation and discoverability of APIs (similar to MuleSoft’s Developer Portal). However, one difference is that Kong only allows OAS, whereas MuleSoft also allows RAML.

decK

One interesting concept in Kong is decK, a declarative command-line tool that uses configuration files to instantiate Kong Gateway instances — an idea similar to IaC tools such as Terraform. MuleSoft has nothing built into the product to do this, but a community-driven Terraform Provider exists to configure Anypoint Platform.

To sum up

This blog is only a brief look at Kong API Gateway. There is much more to it, such as managing APIs in Kubernetes, but I wanted to avoid getting bogged down looking at every single feature. It's only high-level, giving MuleSoft users only a brief insight.

However, I will say that both Kong API Gateway and MuleSoft Anypoint Platform are potent API management and integration solutions. The choice between them depends on many factors, including the use case. But whether you opt for the lightweight flexibility of Kong or the comprehensive features of Anypoint Platform, investing in a robust API gateway is an essential choice for managing your APIs comprehensively.

PS. I am a Kong Gateway Certified Associate, so this blog is based on the knowledge I’ve gained from passing this certification.