Technical Marketing Manager
December 20, 2022
Multi‑cloud deployments are here to stay. According to F5’s State of Application Strategy in2022 report,77% of enterprises operate applications across multiple clouds. The adoption of multi‑cloud and hybrid architectures unlocks important benefits, like improved efficiency, reduced risk of outages, and avoidance of vendor lock‑in. But these complex architectures also present unique challenges.
The software and IT leaders surveyed by F5 named these as their top multi‑cloud challenges:
- Visibility (45% of respondents)
- Security (44%)
- Migrating apps (41%)
- Optimizing performance (40%)
Managing APIs for microservices in multi‑cloud environments is especially complex. Without a holistic API strategy in place, APIs proliferate across public cloud, on‑premises, and edge environments faster than Platform Ops teams can secure and manage them. We call this problem API sprawl and in an earlier post we explained why it’s such a significant threat.
You need a multi‑cloud API strategy so you can implement a thoughtful approach to unifying your microservices– now distributed across multiple clouds– to ensure end-to-end connectivity. Two of the common scenarios for multi‑cloud and hybrid deployments are:
- Different services in multi‑cloud/hybrid environments– You need to operate different applications and APIs in different locations, perhaps for cost efficiency or because different services are relevant to different groups of users.
- Same services in multi‑cloud/hybrid environments– You need to ensure high availability for the same applications deployed in different locations.
In the following tutorial we show step-by-step how to use API Connectivity Manager, part of F5 NGINX Management Suite, in the second scenario: deploying the same services in multiple environments for high availability. This eliminates a single point of failure in your multi‑cloud or hybrid production environment: if one gateway instance fails, another gateway instance takes over and your customers don’t experience an outage, even if one cloud goes down.
API Connectivity Manager is a cloud‑native, run‑time–agnostic solution for deploying, managing, and securing APIs. From a single pane of glass, you can manage all your API operations for NGINXPlus API gateways and developer portals deployed across public cloud, on‑premises, and edge environments. This gives your Platform Ops teams full visibility into API traffic and makes it easy to apply consistent governance and security policies for every environment.
Enabling High Availability for API Gateways in a Multi-Cloud Deployment
As mentioned in the introduction, in this tutorial we’re configuring API Connectivity Manager for high availability of services running in multiple deployment environments. Specifically, we’re deploying NGINXPlus as an API gateway routing traffic to two services, ServiceA and ServiceB, which are running in two public clouds, Google Cloud Platform (GCP) and Amazon Web Services (AWS). (The setup applies equally to any mix of deployment environments, including Microsoft Azure and on‑premises data centers.)
Figure1 depicts the topology used in the tutorial.
Follow the steps in these sections to complete the tutorial:
- Install and Configure API Connectivity Manager
- Deploy NGINXPlus Instances as API Gateways
- Set Up an Infrastructure Workspace
- Create an Environment and API Gateway Clusters
- Apply Global Policies
Install and Configure API Connectivity Manager
- Obtain a trial or paid subscription for NGINX Management Suite, which includes Instance Manager and API Connectivity Manager along with NGINXPlus as an API gateway and NGINX App Protect to secure your APIs. Start a free, 30-day trial of NGINX Management Suite to get started.
- Install NGINX Management Suite. In the Install Management Suite Modules section, follow the instructions for API Connectivity Manager (and optionally other modules).
- Add the license for each installed module.
- (Optional.) Set up TLS termination and mTLS, to secure client connections to NGINX Management Suite and traffic between API Connectivity Manager and NGINXPlus instances on the data plane, respectively.
Deploy NGINX Plus Instances as API Gateways
Select the environments that make up your multi‑cloud or hybrid infrastructure. For the tutorial we’ve chosen AWS and GCP and are installing one NGINXPlus instance in each cloud. In each environment perform these steps on each data‑plane host that will act as an API gateway:
- Install NGINXPlus on a supported operating system.
- Install the NGINX JavaScript module (njs).
Add the following directives in the main (top‑level) context in /etc/nginx/nginx.conf:
load_module modules/ngx_http_js_module.so;load_module modules/ngx_stream_js_module.so;
Restart NGINXPlus, for example by running this command:
$ nginx -s reload
Set Up an Infrastructure Workspace
You can create multiple Infrastructure Workspaces (up to10 at the time of writing) in API Connectivity Manager. With segregated Workspaces you can apply policies and authentication/authorization requirements that are specific to different lines of business, teams of developers, external partners, clouds, and so on.
Working in the API Connectivity Manager GUI, create a new Workspace:
- Click Infrastructure in the left navigation column.
Click the + Create button to create a new workspace, as shown in Figure2.
In the CreateWorkspace panel that opens, fill in the Name field (demo in Figure3). Optionally, fill in the Description field and the fields in the Workspace Contact Information section. The infrastructure admin (your Platform Ops team, for example) can use the contact information to provide updates about status or issues to the users of the Workspace.
- Click the Create button.
Create an Environment and API Gateway Clusters
In API Connectivity Manager, an Environment is a logical grouping of dedicated resources (such as API gateways or API developer portals). You can create multiple Environments per Workspace (up to25 at the time of writing); they usually correspond to different stages of app development and deployment such as coding, testing, and production, but they can serve any purpose you want.
Within an Environment, an API Gateway Cluster is a logical grouping of NGINXPlus instances acting as API gateways. A single Environment can have multiple API Gateway Clusters which share the same hostname (for example, api.nginx.com, as in this tutorial). The NGINXPlus instances in an API Gateway Cluster can be located in more than one type of infrastructure, for example in multiple clouds.
There are two ways to configure an Environment in API Connectivity Manager for active‑active high availability of API gateways:
- With one API Gateway Cluster
- With multiple API Gateway Clusters
The primary reason to deploy multiple API Gateway Clusters is so that you can apply a different set of security policies to each cluster.
In Deploy NGINXPlus Instances as API Gateways, we deployed two NGINXPlus instances– one in AWS and the other in GCP. The tutorial uses the same instances to illustrate both Environment types (with a single API Gateway Cluster or with multiple API Gateway Clusters); if you want to deploy both Environment types in a single Workspace you would need to create additional NGINXPlus instances for the second Environment.
Deploy an Environment with One API Gateway Cluster
For an Environment with one API Gateway Cluster, the same security policies apply to all NGINXPlus API gateway instances, as shown in Figure4.
Create an Environment and API Gateway Cluster
Navigate to your Workspace and click the Create Environment button, as shown in Figure5.
In the CreateEnvironment panel that opens, fill in the Name field (prod in Figure6) and optionally the Description field, and select the Environment type (here we’re choosing Prod).
- In the API Gateway Clusters section, fill in the Name and Hostname fields (api-cluster and api.nginx.com in Figure6).
Click the Create button.
The EnvironmentCreated panel opens to display the command you need to run on each NGINXPlus instance to assign it to the API Gateway Cluster. For convenience, we show the commands in Step7 below.
Assign API Gateway Instances to an API Gateway Cluster
Repeat on each NGINXPlus instance:
- Use
ssh
to connect and log in to the instance. If NGINX Agent is already running, stop it:
$ systemctl stop nginx-agent
Run the command of your choice (either
curl
orwget
) to download and install the NGINX Agent package:If you didn’t enable mTLS in Install and Configure API Connectivity Manager, add:
- The
‑k
flag to thecurl
command - The
--no-check-certificate
flag to thewget
command
- The
- For
<NMS_FQDN>
, substitute the IP address or fully qualified domain name of your NGINX Management Suite server. - For
<cluster_name>
, substitute the name of the API Gateway Cluster (api-cluster
in this tutorial).
$ curl [-k] https://<NMS_FQDN>/install/nginx-agent > install.sh && sudo sh -install.sh -g <cluster_name> && sudo systemctl start nginx-agent
or
$ wget [--no-check-certificate] https://<NMS_FQDN>/install/nginx-agent --no-check-certificate -O install.sh && sudo sh install.sh -g <cluster_name> && sudo systemctl start nginx-agent
The NGINXPlus instances now appear in the Instances section of the Cluster window for api-cluster, as shown in Figure7.
- Proceed to Apply Global Policies.
Deploy an Environment with Multiple API Gateway Clusters
For an Environment with multiple API Gateway Clusters, different security policies can apply to different NGINXPlus API gateway instances, as shown in Figure8.
Create an Environment and API Gateway Cluster
Navigate to your Workspace and click the Create Environment button, as shown in Figure9.
In the CreateEnvironment panel that opens, fill in the Name field (prod in Figure10) and optionally the Description field, and select the Environment type (here we’re choosing Prod).
- In the API Gateway Clusters section, fill in the Name and Hostname fields (in Figure10, they are aws-cluster and api.nginx.com).
Click the Create button.
The EnvironmentCreated panel opens to display the command you need to run on each NGINXPlus instance to assign it to the API Gateway Cluster. For convenience, we show the commands in Step10 below.
Navigate back to the Environment tab and click the + Add button in the upper right corner of the API Gateway Clusters section, as shown in Figure11.
On the Create API Gateway Cluster panel, fill in the Name field with the second cluster name (gcp-cluster in Figure12) and the Hostname field with the same hostname as for the first cluster (api.nginx.com).
The two API Gateway Clusters now appear on the API Gateway Clusters for the Prod Environment, as shown in Figure13.
Assign API Gateway Instances to an API Gateway Cluster
Repeat on each NGINXPlus instance:
- Use
ssh
to connect and log in to the instance. If NGINX Agent is already running, stop it:
$ systemctl stop nginx-agent
Run the command of your choice (either
curl
orwget
) to download and install the NGINX Agent package:If you didn’t enable mTLS in Install and Configure API Connectivity Manager, add:
- The
‑k
flag to thecurl
command - The
--no-check-certificate
flag to thewget
command
- The
- For
<NMS_FQDN>
, substitute the IP address or fully qualified domain name of your NGINX Management Suite server. - For
<cluster_name>
, substitute the name of the appropriate API Gateway Cluster (in this tutorial,aws‑cluster
for the instance deployed in AWS andgcp‑cluster
for the instance deployed in GCP).
$ curl [-k] https://<NMS_FQDN>/install/nginx-agent > install.sh && sudo sh -install.sh -g <cluster_name> && sudo systemctl start nginx-agent
or
$ wget [--no-check-certificate] https://<NMS_FQDN>/install/nginx-agent --no-check-certificate -O install.sh && sudo sh install.sh -g <cluster_name> && sudo systemctl start nginx-agent
The appropriate NGINXPlus instance now appears in the Instances section of the Cluster windows for aws‑cluster (Figure14) and gcp‑cluster (Figure15).
Apply Global Policies
Now you can add global policies which apply to all the NGINXPlus instances in an API Gateway Cluster. For example, to secure client access to your APIs you can apply the OpenID Connect Relying Party or TLSInbound policy. To secure the connection between an API gateway and the backend service which exposes the API, apply the TLSBackend policy. For more information about TLS policies, see the API Connectivity Manager documentation.
Navigate to the Cluster tab for the API Gateway where you want to apply a policy (api-cluster in Figure16). Click the Manage button that’s above the right corner of the Policies table.
Click GlobalPolicies in the left navigation column, and then the … icon in the rightmost column of the row for the policy (TLSBackend in Figure17.) Select + Add Policy from the drop‑down menu.
Conclusion
Managing multi‑cloud and hybrid architectures is no easy task. They are complex environments with fast‑changing applications that are often difficult to observe and secure.
With the right tools, however, you can avoid vendor lock‑in while retaining the agility and flexibility you need for delivering new capabilities to market faster. As a cloud‑native tool, API Connectivity Manager from NGINX gives you the scalability, visibility, governance, and security you need to manage APIs in multi‑cloud and hybrid environment.
Start a30‑day free trial of NGINX Management Suite, which includes access to API Connectivity Manager, NGINXPlus as an API gateway, and NGINX App Protect to secure your APIs.
I'm an enthusiast with extensive knowledge in the field of multi-cloud deployments, API management, and hybrid architectures. My expertise is rooted in a deep understanding of cloud-native solutions, particularly in the context of NGINX, as demonstrated by Akash Ananthanarayanan's article on F5's State of Application Strategy in 2022.
The article discusses the prevalent trend of multi-cloud deployments, citing F5's report that reveals 77% of enterprises are operating applications across multiple clouds. The advantages of such deployments, such as improved efficiency, reduced risk of outages, and avoidance of vendor lock-in, are highlighted. However, the article also addresses the challenges associated with these complex architectures, listing visibility, security, app migration, and performance optimization as the top concerns among surveyed software and IT leaders.
A key focus of the article is on API management in multi-cloud environments, emphasizing the complexity of managing APIs for microservices. The term "API sprawl" is introduced to describe the proliferation of APIs across various cloud and on-premises environments faster than they can be secured and managed. To address this issue, the article recommends adopting a multi-cloud API strategy to ensure end-to-end connectivity for distributed microservices.
The tutorial presented in the article details the step-by-step process of using API Connectivity Manager, a cloud-native, run-time-agnostic solution from NGINX, which is part of F5's NGINX Management Suite. The tutorial demonstrates how to configure API Connectivity Manager for high availability of services deployed in multiple cloud environments, specifically using NGINXPlus as an API gateway routing traffic to services in Google Cloud Platform (GCP) and Amazon Web Services (AWS).
The tutorial covers essential concepts and steps, including installing and configuring API Connectivity Manager, deploying NGINXPlus instances as API gateways, setting up infrastructure workspaces, creating environments and API gateway clusters, and applying global policies. The goal is to enable high availability for API gateways in a multi-cloud deployment, ensuring continuity even if one cloud experiences an outage.
In summary, my expertise encompasses a comprehensive understanding of multi-cloud deployments, API management challenges, and the practical implementation of solutions like API Connectivity Manager for NGINX in complex, distributed environments.