API Management with Docker and Mulesoft Anypoint Flex Gateway

How many APIs exist inside your organization? Dozens? Hundreds? How are you keeping track of access, security, and policies on those APIs? Are you getting consistent alerts if any of those services go down? If you are trying to manually manage each of those individually, you may wish to consider using an API management solution. API management is a critical component to your suite of integration capabilities which allows you to centrally monitor, secure, and deploy your organizations API connectivity and is essential to reliably ensure maintain, monitor, and secure your APIs.

Currently, Mulesoft offers three ways to manage APIs:

  1. Mule Gateway – Mule runtime built in light API management features, such as basic authentication or message handlers.
  2. Anypoint Service Mesh – Istio based API Management for your micro-service architecture, including non-Mulesoft apps, all in a single control plane.
  3. Anypoint Flex Gateway – API management for services running anywhere (Linux service, Docker, Kubernetes). Seamlessly integrates into existing DevOps workflows.

We will not be discussing Mule Gateway, or Anypoint Service Mesh, but it is important as a Mulesoft developer or architect to be aware that these options exist and the pros and cons of each for your specific application architecture and to decide which is the best fit for a given use case.

So what is Anypoint Flex Gateway? Flex Gateway is a performant API gateway that you can use to manage your Mule or non-Mule APIs. When your APIs are managed with Flex Gateway, the gateway can enforce policies, give you observability and monitoring, and enable CI/CD workflows more seamlessly. You can run it in one of two modes… connected or local. Connected mode uses the API Manager UI in Anypoint Platform to give you a single view control plan to observe and manage. Local mode allows you full control and flexibility (but no control plan) via configuration files. Instances of Flex Gateway can be deployed as a Linux Service, Docker container, or via Kubernetes (see below).

Ok, so that sounds great, right? You get all of those API management capabilities, what are the next steps? Using your Anypoint login (including a trial version), you can navigate to Management Center > Runtime Manager > Flex Gateways. (Note: You may be prompted at this point to choose your environment, go ahead and choose Sandbox). Once here, you’ll see the option to define (or view your previously configured) flex gateway. Select “Add Gateway” and the screen below will be presented to you. Rather than repeat their instructions (which may change), please work through the steps listed here.

Important note: Before we get started, let me preface by saying that I discovered through experimentation that the docker image for mulesoft/flex-gateway does not run natively on ARM processors (i.e. M1/M2 Macs) as of the time I wrote this post. I ran these steps through a UTM with Ubuntu VM on my Mac and realize the issue still exists since they both utilize ARM64 architecture. I ended up creating a free-tier EC2 instance and used Visual Studio to SSH into it which worked great! Don’t forget to prefix your commands listed above with “sudo” in that context. This is probably a more valid production setup as well.

Slightly less important note: Currently (as of this writing) you cannot remove a previously created Flex Gateway on the list screen via the Web UI. You may need to just accept these will exist here for a bit until that feature gets added. I believe they are removed automatically if they are in a disconnected state for 30 days.

Once your API Gateway is running inside your Docker container, you will see it listed as active on your Flex Gateway listing screen (along with the number of replicas you configured). The next step is for us to assign one of our APIs to utilize this gateway. Head over to Runtime Manager > API Manager > API Administrator and select “Add API”. You will be prompted with the screen below, and note that “Flex Gateway” is one of the options for our runtime.

At this point you can either select an existing API from Anypoint Exchange, or you can create a new API. If you don’t already have an API ready for this exercise, go ahead and select “Add New API” with name as JSONPlaceholder and type as “HTTP API”. The only field on the next screen you need to set is the implementation URL, and go ahead and set that to “https://jsonplaceholder.typicode.com” (this is a generic API endpoint, which supports requests such as https://jsonplaceholder.typicode.com/users/1).

Note here how we are managing an API which is not inside Anypoint Exchange as a Mule API. You could use this example to showcase how perhaps you have an API which is local on the machine you are running your Flex Gateway, and is not publicly accessible beyond the current machine. You could also gradually route and onboard new customers through your gateway to your already public APIs.

With the API defined (screenshot below) you will see we can now manage: alerts, contracts, policies, and SLA Tiers for this API. You could, for example, enforce a rate limiting policy of 50 calls per minute. Also, at the bottom you’ll see we have observability on the performance. All of the management capabilities we need to support and manage our API have been enabled by connecting it to our Flex Gateway.

One other piece to highlight here is you can setup Flex Replicas to help distribute load and to add redundancy. The process to add a flex replica is provided in the same location as the instructions for initiating the gateway.

To summarize, Flex Gateway has a lot of upside as a new Mulesoft feature to help you gradually move your organization to a cloud native architecture and to split up your monolithic applications. If you do not already utilize a centralized API management to monitor, govern, and secure your organizations connectivity, this can be an excellent way to centralize not only your Mule resources, but also your non-Mule ones as well.

 

Kyle Ballard