API Management for Micro-services (Micro-APIs) in AWS
Micro-services is a very hot topic these days. Almost all cloud infrastructure providers now support building and deploying micro-services. Some have their own proprietary tools and some use open source tools. However, despite the label or the name, they have given for the tool or the service, all of these have the same core functionality and operate almost in the same way. For the interest of this article, I’ll be using AWS tools to build up the solution architecture.
The context here is, that we have a set of micro-services that exposes API endpoints, and we need to properly expose these to client applications. Basically, we have an API as a collection of micro-APIs. This is so simple, right? Well, I would say Yes and No. We are talking about production-ready APIs here, and there few concerns when we expose an API in production. I am not going to go into detail about API management here, but I’ll brief few
- Unified interface to connect
- Versioning
- Authorization
- Deploy for different stages — staging, production, etc
- Throttling
- Monitor usage and activity
From the above concerns, the first concern “Unified interface to connect” is the main interest of this article. When we are building an API as a collection of micro-APIs we need a way to expose the endpoints exposed by each service to the client applications properly. And as I see the best option would be to expose a single view to the client applications aggregating all endpoints from each miro-API (micro-service). Because the client doesn’t care that we are using micro-services, and all it needs is less complexity for consuming the API.
Also, the above concerns don’t add much business value to the application but they are best practices for deploying APIs in production. And it’s always a good practice to use a managed service that would provide these features.
Amazon API Gateway is a fully managed service that has support for all the concerns mentioned above. It has the support to connect a variety of services at the back and provide a unified RESTful API at the front. By the time I am writing this article it supports the following integration types.
- Lambda
- HTTP
- Mock
- AWS Service
- VPC Link
You can get up-to-date more information on the above from their documentation here. I am not going into details on how to build micro-services using the above integration types. If you need more information on these you can find them here.
Okay so let’s assume we have multiple API Gateway deployments (Micro-services) ready and we need to expose them as a single interface to the client applications. For this purpose, we are going to use the Amazon API Gateway’s support for “Custom Domain Names”. To use this feature, we need to use two other services also. They are,
- Route 53 — Manage DNS records of the domain (optionally register domains as well)
- Certificate Manager — Provision and manage SSL/TLS certificates
Before I explain the steps here, Let’s look at the solution architecture of what we are going to build. The diagram below shows an overview of how the above services connect.
I think the above diagram pretty much explains what we need to do. But I would briefly explain the steps. Like I said I assume that the micro-services deployed with API Gateway are in place already.
- Register a domain name if you haven’t already (You can do this in Route 53 itself)
- Create a hosted zone for the domain in Route 53
- Provision a certificate for the domain that you are planning to use for the API (Ex:- api.example.com)
- Create a custom domain name in the API Gateway service with the domain name and certificate you created.
- Create base path mappings for each API Gateway deployment and stage as the URL structure would look as below.
<Domain Name>/<Service Name>/<Version>/*
I have added a screenshot of the API Gateway custom domain mapping along with base path mappings for you to get an idea of what to expect at last.
You can get more details about setting up custom domain names in the Amazon API gateway from their documentation mentioned below.
So now you have a unified single view of the API exposed via a structured URL for your consumer applications. I am not going into details about how the other API publishing concerns mentioned above can be implemented using API Gateway since it’s not the interest of this article.
There are lot more other features supported by Amazon API Gateway like API Keys, Usage Plans. And you can find more details on these from the following link.
Hope the information here is helpful. Don’t hesitate to leave comments if you have any.
👋 Join us today !!
If this post was helpful, please click the clap 👏 button below a few times to show your support! ⬇
