Since MuleSoft announced Universal API Management last year (2021), we started working with multiple customers use cases and requirements. There have been multiple ways in which we have sorted out very specific needs. One thing is very clear, Flex Gateway, that is the muscle behind Universal API Management, is very flexible and effective to adapt to very specific requirements, based on the customer application landscape.

In this article, we are summarising some top patterns that we have utilised when installing Flex Gateway. For each pattern, we will cover when it applies, advantages and potential limitations that you need to be aware of.

Before we start, we need to establish a solid baseline. Let’s recap on the top 3 most important aspects of Flex Gateway:

1. Flex Gateway (part of Universal API Management) is based on Envoy, a CNCF graduated project and by far, the fastest and most mature Service Proxy in the world.
2. Flex Gateway is a lightweight Cloud Native Enterprise API Gateway, known for the simplicity in which it can be installed anywhere, including any Cloud Provider, on-premise data-centres, virtual machines, bare metal, hybrid deployments, kubernetes clusters, etc. 
3.  Flex Gateway can be registered in 2 modes:
   • Connected Mode: The configuration of the Gateway and all API Telemetry (metrics and log aggregation) is managed entirely by the Anypoint Platform. No need to install any other tool or software.
   • Local Mode: The configuration of the Gateway is managed locally using YAML descriptors, aligned with the standard way in which cloud native workloads are managed today. Also, all API telemetry (metrics and log aggregation) can be pushed into 3rd party software, e.g. Prometheus, Loki, Grafana, Kibana, SumoLogic, Splunk, NewRelic, etc. 

For any more information, tutorials or demos, please refer to the MuleSoft website.

Introducing Flex Gateway Deployment Patterns

Now, that we have established a baseline for Flex Gateway, we know that there are always 2 options on how to register a Flex Gateway (i.e. Connected or Local), let’s now introduce potential deployment patterns.

These patterns will vary depending on the customer needs and application landscape. For example, in some cases, the applications to be protected by the Flex Gateway might be a monolith application, a modern SAAS application or distributed nano/micro-services running in some Container Orchestration platform, e.g. Kubernetes. In some situations, the customer has already invested in establishing API Telemetry dashboards, using 3rd party technologies, in other situations, the customer does not have established any API Telemetry dashboard and they would prefer to offload that responsibility to Anypoint Platform.

Based on each of these characteristics, one deployment pattern would make more sense and provide higher value than another. Let’s analyse each of these deployment patterns and characteristics:

Single Layer:

1. Flex Gateway “Ingress Layer” – Connected Mode
2. Flex Gateway “Ingress Controller” – Local Mode

Hybrid Layers:

3. Flex Gateway “Ingress Layer” – Connected Mode +  Flex Gateway – Local Mode
4. Flex Gateway “Ingress Controller” – Local Mode + Flex Gateway – Connected Mode 

Let’s analyse one by one.

Single Layer Deployment Patterns

1. Flex Gateway “Ingress Layer” – Connected Mode

Application Landscape and Flex Gateway deployment

This pattern is applicable when we want to fully manage the configuration of the APIs leveraging an existing Platform as a Service. In this case, all the configuration of the APIs and policy enforcement can be done using Anypoint Platform, either via the web console or using internal platform implementation APIs. Also, all the API telemetry is sent by default to the Anypoint Platform.

In the diagram above, we are drawing the Flex Gateway inside a kubernetes cluster, which can give us the option to privately route internally to microservices running inside the cluster too. However, if the applications to be protected are not running in a kubernetes cluster, then the installation of the Flex Gateway can vary. It can still be inside a cluster, leveraging the high scalability and self-healing characteristics of Kubernetes, but also Flex Gateway could be running in separate VMs/BMs. As long as it is the closest to the application as possible, so that we reduce the network latency  and potential security man-in-the-middle threats.

Advantages

• No need to install 3rd party software to analyse API telemetry and Log Aggregation.

The full API life-cycle for Mule and Non-Mule APIs can be run within the Anypoint Platform. This allows, with simplicity, a high level of visibility, discoverability, reusability and consumption of APIs, both at design time and at runtime. This can be achieved using Anypoint Platform components, such as Anypoint Exchange, API-Catalog CLI, Design Centre, API Manager, Runtime Manager, API Monitoring, API Governance.

• Flex Gateway can still be deployed in a Container Orchestrator (e.g. Kubernetes, Docker Swarm, etc) to simplify its runtime scalability, resilience and self-healing.

• Flex Gateway configuration and management can be automated using CI/CD pipelines, leveraging the APIs of the Anypoint Platform.

Potential Limitations

• A customer may need to maintain all API Telemetry within their firewall – In which case, an alternative could be to register Flex Gateway in Local mode (see other Flex Gateway deployment patterns).
• A customer may want to leverage existing 3rd party dashboard vendors to analyse API Telemetry and Log Aggregation – In which case, an alternative could be to register Flex Gateway in Local mode (see other Flex Gateway deployment patterns).
• A customer may also require East/West security among services – In which case, an alternative could be to register multiple Flex Gateway layers (see other Flex Gateway deployment patterns).
• A customer may have a large footprint of micro/nano services and may prefer to leverage Cloud Native Custom Resource Definitions (CRD) to locally configure their API Gateways within their clusters, as if they were any other cloud native workload – In which case, an alternative could be to register Flex Gateway in Local mode (see other Flex Gateway deployment patterns).

As said previously, there are no silver bullets. If any of the previous potential limitations represent a big setback or constraint for a customer, then that is when the versatility of UAPIM Flex Gateway comes into play, with the next deployment patterns. 

2. Flex Gateway “Ingress Controller” – Local Mode

Application Landscape and Flex Gateway deployment

When the Application landscape is cloud native rich, it is very likely that the customer has already invested in establishing 3rd party software to analyse their API Telemetry, with dashboards that offer visibility for Traffic, Tracing, Error Management, Log Aggregations, etc. Or simply, the customer may need to maintain all API Telemetry within a firewall, due to a government/regulatory mandate or simply own decision. However, they may still require enterprise API Management protection for all of their APIs.

In those cases, the same UAPIM Flex Gateway can be registered in “Local” mode, that gives the option to the customer to fully manage the API Gateways locally using YAML descriptors, as well as the option to forward API Telemetry and Log Aggregation to existing 3rd party software, e.g. Grafana, Kibana, Splunk, New Relic, SumoLogic, etc.

Advantages

Advantages of this approach include:

• Ability to install and manage Flex Gateway as a standard Cloud Native “Ingress Controller” Custom Resource Definition (CRD), with the full protection of APIs with enterprise policy enforcement. 

• We can redirect any API Telemetry to 3rd party software if needed.

• Simple CI/CD Pipelines to manage YAML file descriptors, aligned with the standard way to manage Cloud Native workloads.

A customer may continue leveraging any software or scripts already in place to deploy, configure and fully manage Flex Gateways, as any other cloud native workload.

Potential Limitations

• The customer will have to install 3rd party software to obtain full visibility of their APIs and API Gateways – In which case, an alternative could be to register Flex Gateway in Connected mode (see other Flex Gateway deployment patterns).

• A customer may still use Anypoint Platform to discover and catalogue assets, but in Local Mode, there is no automated lineage from API Specs in Exchange to be consumed to configure local YAML Files – In which case, an alternative could be to register Flex Gateway in Connected mode (see other Flex Gateway deployment patterns).

• A customer may also require East/West security among services – In which case, an alternative could be to register multiple Flex Gateway layers (see other Flex Gateway deployment patterns).

Luckily, multiple Flex Gateways can/should be installed as part of a solution, so we can achieve a case that can minimise the potential limitations and achieve the largest number of combined advantages from both connection modes. Let’s review 2 hybrid pattern scenarios.

Hybrid deployment Patterns

As mentioned previously, in application landscapes with a large number of micro/nano services running in some container orchestrator cluster, such as Kubernetes, there is likely to be existing investment in using 3rd party software tools to analyse API telemetry, e.g. Grafana dashboards. In these scenarios, it might make more sense to leverage that setup in place and simply add an “Ingress layer” using Flex Gateways in connected mode. This way, we can still route privately within a Kubernetes cluster using internal DNS names and also be able to provide full visibility of all traffic entering/exiting the cluster in Anypoint Platform.

Also, if it is required to add east/west inter service communication policy enforcement, we can add another layer of cluster-deployed Flex Gateways. This second layer of Flex Gateways can be registered in either local/connected mode. Let’s analyse some advantages of using either Mode.   

3. Flex Gateway “Ingress Layer” – Connected Mode +  Flex Gateway – Local Mode

Application Landscape and Flex Gateway deployment

In this Deployment Pattern we are using Flex Gateway Ingress layer in Connected mode and a second layer of Flex Gateways registered in Local Mode.

This is the typical situation where there are multiple micro/nano services deployed within a container orchestration cluster and they require east/west policy enforcement across inter-service communication. 

The internal layer of Flex Gateways registered in Local Mode can be grouped or split to accommodate specific micro-services level of granularity. For example, when microservices are further broken down into nano-services, that normally represent a single API endpoint or function, it is likely that each group of nano-services will require similar type of policy enforcement, which can be easily provided if creating a Flex Gateway multi-replica group deployment, operating under the same namespace of the group of nano-services. That way, we can explicitly separate and simplify the type of policy enforcement that is applied to a group of services.

As for the external “ingress layer”, it allows north/south traffic and security management to allow/reject access to the cluster.

Let’s analyse some benefits of this deployment pattern.

Advantages

• The Flex Gateway “ingress layer” provides full North/South protection to the cluster, becoming the gate of any traffic that enters/leaves the cluster. Also all this traffic is automatically pushed out into the Anypoint Platform for API Telemetry analysis and Log Aggregation management.

• The internal traffic for nano-service communication can remain analysed by existing 3rd party software that already analyses traffic API Telemetry for all existing nano/micro services. That way, the internal Flex Gateway layer(s) can be pushed out any API Telemetry into these existing 3rd party tooling.

• We can achieve the same level of “enterprise” security, resilience and performance across north/south and east/west service communication management. 

Potential Limitations

• A customer may need to maintain all API Telemetry within their firewall or using their existing 3rd party dashboards – In which case, an alternative could be to register both Flex Gateway layers as Local.
• A customer may want to offload operations for all API Telemetry to Anypoint Platform – In which case, an alternative could be to register both Flex Gateway layers as Connected.
• A customer may prefer to leverage Cloud Native Custom Resource Definitions (CRD) to locally configure their API Gateways Ingress Controller – In which case, an alternative could be to register the Flex Gateway Ingress as Local Mode.

4. Flex Gateway “Ingress Controller” – Local Mode + Flex Gateway – Connected Mode 

Application Landscape and Flex Gateway deployment

In this Deployment Pattern we are using a Flex Gateway Ingress Controller in Local mode and a second layer of Flex Gateways registered in Connected Mode.

This is the typical situation where there are multiple micro/nano services deployed within a container orchestration cluster and they require east/west policy enforcement across inter-service communication. 

The internal layer of Flex Gateways registered in Connected Mode can provide full observability and auditability to inter-service communication via the Anypoint Platform. No need to install or have in place any existing 3rd party tooling.

As for the external “ingress controller”, it allows north/south traffic and security management to allow/reject access to the cluster using standard cloud-native Custom Resource Definitions (CRD), that allows a very rich path base traffic control.

Let’s analyse some benefits of this deployment pattern.

Advantages

• The Flex Gateway “ingress controller” provides very mature and complex North/South protection to the cluster, becoming the gate of any traffic that enters/leaves the cluster. This traffic telemetry can be potentially consumed by 3rd party software in place, for example, the customer may have a tool like Splunk for all Log Aggregation in place, but they may not require or have in-place any more advanced API Telemetry dashboard tooling.

• The internal traffic of Flex Gateways will be automatically pushed out to Anypoint Platform for API Monitoring and Log Aggregation. No need to install nor maintain any advanced 3rd party software/tooling.

• We can achieve the same level of “enterprise” security, resilience and performance across north/south and east/west service communication management. 

Potential Limitations

• A customer may need to maintain all API Telemetry within their firewall or using their existing 3rd party dashboards – In which case, an alternative could be to register both Flex Gateway layers as Local.
• A customer may want to offload operations for all API Telemetry to Anypoint Platform, including the Ingress layer – In which case, an alternative could be to register both Flex Gateway layers as Connected, so that all API Telemetry is pushed out to Anypoint Platform.

As you can see, Flex Gateway is very easy to adapt to specific use cases needs and requirements. There is no such a thing as a silver bullet, but using a combination of deployment patterns, we can achieve the right level of control and meet the right level operational conditions and application landscape of a customer, whether they prefer to manage it all locally via YAML files and Custom Resource Definitions (CRDs) or whether they prefer to offload all operational responsibilities to Anypoint Platform, so that they obtain full manageability, control and observability of their APIs, without having to maintain dashboards and log aggregators themselves.

I hope you found this article useful. If you have any question or comment, feel free to contact me directly at https://www.linkedin.com/in/citurria/

Thanks for your time.