Mule SAPI migration to Kong – conceptual overview

Use Case:  Migrate System APIs or SAPIs from Mule to Kong Gateway.  

Models:  There are 2 basic deployment models when using an API gateway and SAPIs.  

1-Gateway + SAPI + Side Car with a connection to the back end service or resource.

2-Gateway with the SAPI, no Side Car, with a connection to the back end.

There are pros and cons to both deploment models.

A side car pattern is often used with Containers, to reduce overhead and latency and to remove non-core code functionality from the SAPI container to a side car to handle observability, rate limiting and authorisation.  The side car travels with the container code/API.  There is east-west communications secured by an Istio or similar service mesh.

There are 3 parts to migrating a SAPI.  First is the process of automation in moving the API from the legacy platform to Kong.  This involves tooling, to convert the API specifications, move the policies and plugins, set up the declarative approach to deploy to the Kong server and setup the back end service.  The second, is setting up the API gateway infrastructure, namely the Control Plane to manage the configuration of the Data Planes and the creation of the side cars in the target platform.  Third, all communications should use mTLS certificates and a process to handle that should be built (repository-reference or a repository-plugin model). 

You can migrate an API every hour depending on the automation, skills and target platform setup and knowledge.