How to Migrate a MuleSoft API to Kong Gateway in 5 Minutes

By on October 19, 2021

How to Migrate a MuleSoft API to Kong Gateway in 5 Minutes

These days, a lot of companies are moving towards cloud native applications and declarative configurations. This is also true for the traditional API gateways (e.g., MuleSoft, Axway, etc).  Customers are looking for new technologies which fit better in their cloud environments and also are faster and cheaper.

The main challenge here is how to migrate the existing APIs to the new platform. A lot of companies are spending thousands of hours building migration tools or performing the API migration manually. These approaches are expensive, error-prone and time-consuming. 

In this post, we will demonstrate how to migrate a customer API running MuleSoft API Gateway over to Kong in a few simple steps. Before discussing the migration process, we would like to discuss the fundamental differences between legacy integration solutions such as MuleSoft and cloud native architecture. 

Cloud Native Architecture and Legacy Integration Solutions

As mentioned earlier, companies are looking for new technologies which are better, cheaper and faster to implement their APIs. Legacy integration solutions such as MuleSoft were built prior to cloud native. Therefore, they tend to limit the users to certain technologies instead of giving them the freedom of choosing what tools and technologies are suitable for their organization. In order to demonstrate this point, let’s take a look at the Mulesoft application’s structure. 

How to Migrate a MuleSoft API to Kong Gateway in 5 Minutes

Each Mulesoft application consists of three parts: API Gateway, Logics and Connectors. 

API Gateway: API developers can apply the policies which come with API Gateway or build their own custom policies. These policies can be for security (e.g., OIDC, OAuth), QoS (e.g., rate limiting, caching) or other categories such as transformation, troubleshooting and compliance.

Logics: The logic section of a Mulesoft application is used for implementing integration solutions and microservices. 

Connectors: API developers use connectors to connect to the backend systems. 

Is this the right architecture for companies that are embracing cloud native? The short answer is simply…no. Here is why:

  • API Gateway: Using legacy API gateways such as Mule, API developers need to learn Mule-specific language to build a policy. If a company has excellent javascript developers, they can’t use their skills and learn Mule-specific language from scratch. This slows down development and demotivates developers because their skill is not used, and the new skills they are learning are only limited to one software vendor.
  • Logics: Cloud native services offer hundreds of different ways to implement logic in an application or a microservice. For example, developers can use AWS lambda or Azure functions to implement business logic. Another example is using Node.js or Spring Boot to build microservices deployed and managed in AWS, Azure or GCP clouds. The flexibility of using different technologies to build the logic and minimum maintenance overhead makes cloud native services a much better solution for building the logics.
  • Connectivity: A decade ago, connectivity to monolithic back-end systems was a big challenge. Since then, there has been a significant shift in the market. Most software vendors made significant investments in their products to break away from monolithic architecture and redesign their systems with connectivity and microservices as a top priority. These days, most back-end systems provide a rich set of APIs that other systems can consume.           

As you can see, there are compelling reasons to move away from the legacy API gateways and embrace cloud native architecture. In the new world, logics and connectivity are implemented using cloud native services. 

The only thing remaining is the API gateway piece, which we’ll show you how to migrate to Kong’s API Gateway.

Migrate a MuleSoft API to Kong Gateway

In this section, we will migrate a customer API from MuleSoft API Gateway to Kong. This API does the following:

  • Validates the OAuth tokens using OAuth 2.0 policy
  • Limits the number of requests to five requests per second

Our use case focuses on the API Gateway section of the Mule application, so there is no logic or complex connector.

If you have worked with MuleSoft Anypoint Platform, you probably know the Design Center. API developers can use Design Center to create API specifications. In the Design Center, we created the Customer API specification.  

This API specification is created using RAML. MuleSoft recently started supporting OAS as well, but because RAML is still more popular, we also used RAML. If you are using OAS, the migration process is even more straightforward, as you will see later in this section.

To migrate APIs from MuleSoft to Kong, we only need a few things: API specification, policies and a back-end service URL. In this case, we have them all. Now let’s see how we can use this information to generate and deploy a Kong service, route and plugins automatically. 

The first step is to export the API specification. This can be done quite easily using MuleSoft Exchange. Just locate the asset in Exchange and download it as OAS. The result is a zip file that contains the customer API swagger specification. 

We can automate searching and downloading API specifications from MuleSoft Exchange with the Exchange APIs.    

mulesoft migration to kong

In the next step, we need to convert the Swagger file to an OAS 3.0 yaml file. The Swagger.io website already has APIs to convert a Swagger definition to the OpenAPI format. Run the following command to create Customer API OAS specification. 

Use Insomnia or a text editor to open up the customer-api.yaml file. We used Insomnia because it makes it so easy to work with API specifications. At this stage, you need to add some metadata for the Kong plugins to the API specification. 

We will use this metadata to generate the Kong plugins in the next steps automatically. Please keep in mind that this step is optional; there are other ways to create Kong Plugins (i.e., Admin APIs, Kong Manager or manually creating the declarative configuration). 

We also need to change the server’s URL to point to the back-end service. In this example, we used Mockbin to create a mock endpoint.           

Your customer-api.yaml file should look like this:

We have placed x-kong-plugin- metadata in different locations in the API specification; OAuth 2.0 is applied to the entire service, but rate limiting is only applied to the  GET  /v1/customers resource. 

The final step is to install inso CLI and Kong decK, and use them to generate declarative configuration and push it to the Kong server.

That’s all you need to do. All the services, routes and plugins have been automatically created.

To test your API, run the following command:

You should see the following response: 

This means your API is up and running and secured with the OAuth 2.0 plugin. Please take a look at this link for more information about using the OAuth 2.0 plugin. After getting the access token, you should be able to call this API successfully.

You can also see the rate limiting attributes in the header as well.

Conclusion

Migrating from a legacy integration platform to a cloud native architecture might be daunting and scary initially, but it is a lot simpler than you think. Kong uses declarative configuration and APIOps to automate the API lifecycle. Kong’s innovative approach to API lifecycle management is helping thousands of customers to:

  • Migrate from legacy API gateways to Kong faster
  • Automate the API lifecycle 
  • Embrace cloud native architecture and a multi-cloud strategy
  • Deliver and manage APIs and microservices at scale

In this post, we only focused on migrating one API. You might think, what if I need to migrate thousands of them? The answer is automation. Because everything is automated, we can run it for one API or thousands of APIs.