Organizations today find that multiple cloud regions, and even multiple cloud vendors, are necessary. The reasons range from performance and cost optimizations to customer demand and data sovereignty concerns.
API management across multiple regions and cloud providers isn’t easy. While infrastructure solutions such as containerization are making it easier to deploy the same solution across multiple vendors with varying infrastructure resources, there remain several additional concerns. In this article, we will examine the challenges of multi-cloud API management and some approaches that can help ease deploying and managing your API across providers.
Anyone delivering solutions in the retail space may have encountered challenges when using a competitor’s cloud. One example is Walmart, who prefers that hosted SaaS offerings not use AWS. The initial reaction to this demand may be concerned about placing data on a competitor’s cloud. However, the real reason is more simple than that: they don’t want any operational revenue to go toward their competitor. Those with an existing relationship with AWS for their primary cloud provider may be required by retail companies to use another cloud provider, such as Azure.
To improve performance for customers in a specific region, it may be necessary to place APIs and data closer to your customers. Yet, not all cloud providers support regions in all parts of the world. It may be necessary to deploy your APIs to multiple cloud providers to enable reaching a particular market segment that lives with an unsupported region of your current cloud provider.
Addressing data sovereignty, data residency, and data localization concerns is a challenge that is very real for many organizations. While these topics are complex, they can be summarized as:
Data residency: Refers to where the organization chooses to store their data (usually for regulatory or policy reasons).
Data sovereignty: Refers to a government’s rights of access to data found within its borders. These may differ widely from country to country and may extend beyond a country’s borders based on where the organization resides.
Data localization: Requires that data created within certain borders stay within them, or a copy of the data is kept within the country.
As you examine each of these three factors, you may find that you need more than one cloud provider and associated data store to comply with the rules and regulations of the country. Proper API management requires factoring in these considerations while ensuring consistent behaviour.
Note: Data sovereignty is a complex subject that benefits from the proper legal counsel to ensure you are able to understand and apply the rights of your company and your customers. Be sure to seek the appropriate professionals when it comes to the rules and regulations in the countries you conduct business.
When searching for an API management solution, several factors must be considered:
Managing multiple API instances: Rather than a single cloud provider, your API instances will be scattered across multiple providers. Keeping your API routing rules, authorization, and rate-limiting quotas in sync across these multiple providers become extremely important. This includes the monitoring and reporting of API health across and within each provider and their regions you utilize.
Centralized control plane: Some API management solutions assume a single data center by designing their APIM as if the control plane and data plane are the same, making it difficult to disconnect the management from the actual traffic management. When moving to multi-region and multi-cloud deployment architectures, this becomes even more challenging to keep in sync. Rate limiting may be incorrectly applied, costing you more in infrastructure resources. Worse, your authorization rules may become out-of-sync and result in improper access to data and API operations. Look for API management layers that separate the control plane (management) from the data plane (traffic enforcement) to make your transition to multi-cloud smoother.
GeoDNS and ingress routing: Incoming API traffic needs to be routed to the appropriate region based on who the consumer is, what data they need to access, and where it resides. This may require solutions such as GeoDNS to resolve DNS entries based on where the consumer is, internal data stores that map the data source to the appropriate data center, the use of tenant subdomains in the API base URL to auto-route to the proper data center, or perhaps a combination of these approaches. While this does not directly impact your API management solution, your APIM may make it easier or more difficult to get all of these components working.
No matter the reason, supporting a multi-cloud strategy requires evaluating your API management approach. This includes finding an API management solution that is capable of working in a multi-cloud, multi-region configuration while ensuring a centralized control plane that ensures all instances of the API are in sync with the latest authorization and routing rules. For more insight into the challenges of multi-cloud API management, take a look at the Cloud Native API Management whitepaper.