If you’re reading this post, chances are you’ve already gone through the tedious process of decomposing your monolith into microservices, or at the very least, will be considering this approach in the near future.

For starters, a solution that involves microservices that consume APIs looks like this:

Figure 1: Clients directly communicate with microservice (image credit: microsoft.com)

Right off the bat, we can see issues with this type of solution. Not only is the API dependency approaching spaghetti level but other important questions also arise:

  • What happens when one or more backend APIs change significantly? Do we have to rewrite the API-microservices connection code for each individual microservice?
  • Modern systems consume a diverse variety of APIs – simple REST APIs, OpenAPI (standard language-agnostic REST), WADL (XML-based REST), WSDL (XML-based SOAP). These APIs may be hosted on public cloud, private cloud and, in some cases, even on-premises. Are we going to let each individual microservice handle these diverse set of connections?
  • What about security? Each of these backend services could implement it’s own security protocols. Not to mention that in the flow of data from the microservices to the backend API services, the security is only as good as the weakest link. Spaghetti connections like the one shown above expose a large surface attack area.
  • Logging of messages between the microservices and backend APIs is also a major concern due to large permutations of paths and state of each path.
  • Caching of the calls to the backend APIs is another stress point with each backend API being forced to implement their own caching mechanism.

API Gateways solve exactly these kind of issues:

Figure 2: Clients communicate with microservice via API Gateway (image credit: microsoft.com)

  • API Gateways decouple the backend APIs from the microservices by connecting to the backend APIs and providing each individual microservice with an individual connection to the gateway. The API Gateways enable communication between the microservices and the backend APIs by routing the messages based on path, headers, hostname and other mechanisms.
  • API Gateways could also address the issues with diverse API sources by converting all backend API response to a single format. In some cases, API Gateways allow the responses to pass-through as-is.
  • Besides reducing the surface attack area, API Gateways also provide a single secure entry point into the backend APIs. Additionally, many API Gateways also support token based authentication, OAuth support, OpenID Connect support and similar industry standard authentication mechanisms.
  • API Gateways provide a single point for logging messages between the backend APIs and the microservices thereby making it easy to diagnose issues. API Gateways handle caching in a similar manner.
  • Most industry standard API Gateways also provide mechanisms for rate limiting and billing based on usage.
  • Additionally, most API Gateways also have developer portal support to make it easier for developers to consume the backend APIs.

Some common API Gateway industry-standard solutions:

  • Azure API Management – This is a Azure PaaS solution, hence proprietary (not open source). It provides VNet support, in-built caching and connection to on-premises backend APIs via VPN. Scaling out involves replication of nodes. Works best for solutions on Azure platform with numerous services and identity providers integrations
  • APIGee – This is a proprietary solution (now owned by Google). Instances of this gateway can be deploy on-premises instead of having to connect via VPN. APIGee does require multiple nodes with each node playing a different roles and has no in-built caching (at the time of writing this post).
  • AWS Gateway – This is very similar to Azure API Management but for the AWS Cloud platform.
  • Express Gateway – This is an open source solution and supports on-premises deployment. Scaling happens with multi-node replication. However, a separate datastore is required for caching.

Azure API Management (Azure APIM)

Figure 3: Sample Azure API Management implementation (image credit: microsoft.com)

  • Azure AD: Azure APIM provides out-of-the-box support for Azure Active Directory authentication. You can configure your Azure APIM instance to protect an API, by using the OAuth 2.0 protocol with Azure Active Directory (Azure AD).
  • Virtual Networks support: You can allow your microservices hosted elsewhere to directly call an Azure APIM instance with a virtual network. This allows you to hosted the backend services within a secure VNet and only expose data through the Azure APIM.
  • Multi-region support: Azure allows you to scale your Azure APIM to multiple regions transparently (when the feature is enabled). This ensure business continuity when individual Azure regions are impacted.
  • Rate limiting: Azure APIM provides rate limiting policies that can be applied across the board or for individual APIs. The rate-limiting can also be set at a subscription level or based on source of request.
  • ARM templates for automation: Azure APIM support ARM templates for deployment. This helps with deploying the service and configuration changes through CI/CD pipelines and staying true to DevOps principles.
  • Mocking: Let’s say you’re adding new features to your system. You create the necessary microservices with the API calls but the backend API development team is running behind schedule. You can “mock” API responses for this backend API with Azure APIM. When the backend API is ready to deploy, the wiring up of the live service behind the scene will be almost transparent to the microservices that used the mock API.
  • Versioning and revisions: Azure APIM supports both revisions (non-breaking API changes) and versioning (breaking API changes) for backend APIs. Azure APIM has a robust set of URL rewrite policies that enable hosting multiple API versions.
  • Productize with products and subscriptions: Azure APIM  supports the concept of a product, which contains one or more APIs as well as a usage quota and the terms of use. Once a product is published, developers can subscribe to the product and begin to use the product’s APIs. Products also provide default subscriptions and additional subscriptions which allow for token based access to the APIs.
  • Highly customizable developer portal: Azure APIM has a highly customizable developer portal which can be used to onboard developers to work with the APIs.
  • In-built and external caching: Azure APIM provides built-in caching. Size may vary based on the level of service. Additionally, Azure APIM also has support for Redis cache (preview)
  • Integrated monitoring tools: Azure APIM provides easy one-click integration with monitoring tools like Application Insights.
  • Security – Azure APIM provides token based authentication (subscriptions). Additionally, it also allows for Oauth and OpenID Connect identity service integration and even allows for passthrough of JWTs to the backend APIs.

In summation, if you’re building solutions involving microservices, using API Gateways to communicate with backend APIs is a no-brainer. Azure API Management is a top contender for an API Gateway solution that enables these microservices to backend APIs communication. And if your solution is hosted on Azure, Azure API Management becomes the automatic front runner for API Gateway.

Regardless of where you may be in your microservices journey – whether you’re just getting started or looking for a robust API Gateway to bolster your current architecture, Nebbia Technology – A New Signature Company has the experts in-house to guide you along the way and provide help and training to ensure success.