I hope you read the First , Second and Third part of this Microservices Implementation Journey and found them useful and if you didn’t I recommend you do!

Here are the links for the previous parts:

Part 1: https://koukia.ca/a-microservices-implementation-journey-part-1-9f6471fe917

Part 2: https://koukia.ca/a-microservices-implementation-journey-part-2-10c422a4d402

Part 3: https://koukia.ca/a-microservices-implementation-journey-part-3-50f030ba6bb5

Do we need this “API Gateway” thing at all?

Well, Netflix is doing it, so …

But on a more serious note, I think such a layer is required to abstract away some of the complexity and concerns that a Microservices Architecture creates.

I compiled a list of drivers for us to have an API Gateway in a Microservices Architecture:

The way the APIs would provide the data is probably going to be very different from the way the client would need it. Usually Microservices will have very chatty APIs, and for the client to complete one scenario, they need to make several API calls possibly across multiple services. So API Gateway can address this issue for the client.

The data itself is something that might be an issue. For example the data that a Web Application needs or expects from a Mobile App might be different. In some cases we could force different kinds of clients use the same APIs but as you could imagine, it will be the “one-size-fits-all” situation and it is not going to be very efficient for some clients. With API Gateway we can customize the existing API outputs and serve the data that each client needs.

Network could also be an issue, if we use the same API responses for all kinds of clients. Generally mobile networks are much slower that WAN networks and also WAN is slower than LAN. So if we are making multiple API calls in a LAN based application, the performance impact might not be as obvious, but if we do the same thing in a mobile app, the user experience will be degraded.

The number of Microservice instances and their physical host information could change over time and having an API Gateway could hide all those changes from the consumers.

If things change in our Microservices environment, for example we decide that one functionality does not belong to one Microservice, and decide to move it to another one, we could still abstract that change from the clients using an API Gateway.

Some of the Microservices might use protocols that are not web friendly, so communicating directly with web or mobile client can be tricky, but having an API gateway could address this issue.

You could use this layer to make sure your API stays backward compatible. Having backward compatible APIs are very important specially when you have Mobile clients, where you don’t really have much power to force them to upgrade their app if you make breaking changes to your API.

Any drawbacks for using API Gateways?

Obviously there are drawbacks using this pattern. Here are some for you to think about:

We are adding this additional component to the architecture which potentially adds some overhead in terms of management, monitoring, implementing, etc. Basically it is one more thing to worry about!

Any change in the Microservices, would need a change in the API Gateway. Basically we have abstracted away the changes in our Microservices from our Clients perspective, but we still need to make modifications to the API Gateway to accommodate any Microservice change.

Could potentially be a single point of failure. If you look at the Architecture diagram again, it is obvious that every request would go through this component, so if that goes south, we have a serious problem! So we need to make sure that it is the highest available component that we have (Same with our Service Bus!)

Also some might worry that it might not perform very well under load. So we should make sure we do proper benchmark before piking a tool as our API Gateway to be sure that it can handle the scale that we expect from it.

What are my options for an API Gateway?

If you are convinced that having an API Gateway is something you want in your Architecture, let’s go through some of the products that are available out there for us:

Use Azure API Management as a turnkey solution for publishing APIs to external and internal customers. Quickly create consistent and modern API gateways for existing back-end services hosted anywhere, secure and protect them from abuse and overuse, and get insights into usage and health. Plus, automate and scale developer onboarding to help get your API program up and running.

2. Google Apigee API Platform

Apigee is a full lifecycle API management platform that enables API providers to design, secure, deploy, monitor, and scale APIs. Apigee sits in-line with runtime API traffic and enforces a set of out-of-the-box API policies, including key validation, quota management, transformation, authorization, and access control. API providers use the customizable developer portal to enable developers to consume APIs easily and securely, and to measure API performance and usage.

3. Graphql

GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. GraphQL provides a complete and understandable description of the data in your API, gives clients the power to ask for exactly what they need and nothing more, makes it easier to evolve APIs over time, and enables powerful developer tools.

4. Netflix Hystrix

Hystrix is a latency and fault tolerance library designed to isolate points of access to remote systems, services and 3rd party libraries, stop cascading failure and enable resilience in complex distributed systems where failure is inevitable.

5. Amazon API Gateway

Amazon API Gateway is a fully managed service that makes it easy for developers to create, publish, maintain, monitor, and secure APIs at any scale. With a few clicks in the AWS Management Console, you can create an API that acts as a “front door” for applications to access data, business logic, or functionality from your back-end services, such as workloads running on Amazon Elastic Compute Cloud (Amazon EC2), code running on AWS Lambda, or any Web application.

Each of these tools (and many more are out there for sure) have some cool features, and based on your requirements and your special needs I guess you could investigate them and with some POC pick your poison!

Now for this article I am going to demonstrate the Azure API Management and use expose some of APIs through it.

Setting up Azure API Management

Azure API Management is a very fast to get up and running solution for publishing APIs to external and internal clients. It enables you to create API gateways for existing Micoservices hosted on Azure or your own data center.

From the Azure portal, here are some of the API Management features:

Provide API documentation and an interactive console

Throttle, rate limit and quota your APIs

Monitor health of your APIs and quickly identify errors

Bring modern formats like JSON and REST to existing APIs

Connect to APIs hosted anywhere on the Internet or on-premises and publish globally

Gain analytic insights on how your APIs are being used

Manage your service via the Azure portal, REST API, PowerShell, or Git repository

To get started, you can login to Azure Portal: https://portal.azure.com , clink on New, and search for “API Management”, and select the first one from the result, just like the following picture and click “Create”

In the next screen, you can enter the name for your API Gateway, and most importantly the “SLA” or “Service Level Agreement” which is the availability of your API Gateway.

As we discussed earlier, since this component could be our “single point of failure” we should make sure the SLA that we select is aligned with our expectations in terms of high availability.

And that’s it, our API Gateway is deployed to Azure and there is already monitoring in place for it. If you navigate to the service in the Azure portal you will see the service status and the monitoring widget:

Configuring our API Gateway

Now that out API Gateway is up and running, let’s take a look and try to integrate it with some APIs.

If you click on the “APIs” menu in the left pane, you can see that first thing you need to do is to add an API to the Gateway to start playing around.

As you can see in the above picture, you can add an Empty API (for cases where you don’t have a public API available yet), or an API with Open API Specification (formerly known as Swagger enabled API), a REST or SOAP API with WSDL, an Azure Logic App API, API App or an Azure Function.

So you pretty much can mix and match all sort of API that you might have in your system, consolidate them all and provide your clients with a good experience with dealing with just your API Gateway.

Azure API Management Developer Portal

One of the very cool features of Azure API Management is the Developer Portal. With this you can point all consumers of your APIs to that, have them sign up, see documentation and start building their code.

You as the administrator of the Developer Portal can totally customize the look and feel of this portal to make it look like your own company’s theme and brandings.

The following is the default UI that is deployed when you create your Azure API Management: