In the last few years Microservice Architecture pattern becomes popular because decomposes a large and complex application into a set of services with the advantages, for example, that individual services are easier to understand and can be developed and deployed independently of other services.
Thanks to Docker it became simpler for developers to take advantage of emerging technologies (frameworks, programming languages, etc.) to develop and deploy polyglot code both on services as part of microservices architecture and on client side with web and mobile applications.
- Number of items in the shopping cart
- Order history
- Customer reviews
- Low inventory warning
- Shipping options
When using the microservices architecture the data displayed on the product details page is owned by multiple microservices and product details data is spread over multiple services:
Figure 1: Before implementing an API gateway
How do the clients of a Microservices-based application access the individual services?
A better approach rather than direct client‑to‑microservice communication is know as API Gateway that act as a single-entry point for all clients and encapsulates the details of the microservices. The API Gateway is responsible for request routing, composition, and protocol translation. All requests from clients first go through the API Gateway. It then routes requests to the appropriate microservice. The API Gateway will often handle a request by invoking multiple microservices and aggregating the results. It might have other responsibilities such as authentication, monitoring, load balancing, caching, request shaping and management, and static response handling.
Figure 2: After implementing an API gateway
A great example of an API Gateway is the Netflix API Gateway which expose a client-specific adapter and handles billions per day requests (from devices including televisions, set‑top boxes, smartphones, gaming systems, tablets, etc.) and each request invoke on average six to seven backend services.
As you might expect, using an API Gateway has some drawbacks:
- Increased complexity because it is yet another highly available component that must be developed, deployed, and managed
- Increased response time due to the additional network hop through the API gateway (however for most applications the cost of an extra roundtrip is insignificant)
If you are an AWS customer and you are developing a microservices application based on Lambda and/or EC2 container, API Gateway becomes the custodian of your services reducing drawback impact: with a few clicks in the AWS Management Console is easy to create, publish, maintain, monitor and secure APIs through Amazon API Gateway.
Figure 3: Source: Amazon
There are many reasons/benefits to consider Amazon API Gateway in the context of microservices deployed on AWS.
Elastic, Self-Service and pay-as-you-go
Instead of launching EC2 instances, installing and configuring gateway software, you can implement an API gateway for existing backends in few minutes through AWS management Console. With open source Swagger importer tool you can easily import Swagger API definitions into Amazon Api Gateway.
Figure 4: Create new API gateway
API Gateway is elastic which can scale-out and scale-in dynamically without manual configuration to handle the amount of traffic your API receives and provide the lowest possible latency for requests and responses.
Amazon API Gateway has no minimum fees or startup costs because you pay only for the API calls you receive and the amount of data transferred out ( $3.50 per million API calls received, plus the cost of data transfer out, in gigabytes).
API Logging, Caching, Throttling and Monitoring
Instead of invoking the backend API for every client call, you can configure caching which will improve performance. Cache settings allow you to control the way the cache key is built and the time-to-live (TTL) of the data stored for each method. The management API can be invoked to invalidate the cache. The pricing for this feature is based on the size of the cache.
To avoid spike and protect backend APIs from deliberate misuse you can configure throttling, and quota limits on a per API key basis. API Gateway automatically meters traffic to your APIs and lets you extract utilization data for each API key.
Figure 5: Set Quota & Throttling
Since API Gateway is a crucial element of an application after your API is deployed, Amazon API Gateway integrates with CloudWatch (monitoring service for all AWS services) and provides a dashboard to visually monitor calls to your services to see performance metrics and information on API calls, data latency, and error rates.
API Lifecycle Management
API has become an integral part of application design that needs to integrate with Continuous integration/Delivery pipelines. Amazon API Gateway supports multiple stages (ex. Development, Test/Quality Assurance and Production) and multiple versions of the same API simultaneously so that applications can continue to call previous API versions even after the latest versions are published. Each version of the API can be associated with a custom domain so that you can switch multiple versions while keeping the custom domain and endpoint the same. This makes it possible to easily rollback API versions.
Figure 6 Create stage step
You can optionally set your API methods to require authorization and verify API requests to AWS services. API Gateway is integrated with Identity Access Management (IAM) and provides multiple tools to authorize API access: you can use AWS credentials -- access and secret keys – to sign requests to your service and authorize access like other AWS services or use custom authorizers -- AWS Lambda functions -- to verify and authorize bearer tokens such as JWT tokens.
Figure 7: Custom authorizer
You can create API keys on Amazon API Gateway, set fine-grained access permissions on each API key, and distribute them to third-party developers to access your APIs. The use of API keys is completely optional and must be enabled on a per-method level.
Figure 8: Create API key or uses existing ones
Native Code Generation
Payload Modeling and Transformation
API Gateway payload modeling and transformation gives you a chance to modify the JSON schema during the request and response cycles: by defining a template, the request and response payloads can be transformed to reflect a custom schema. This is especially useful in aggregating output from multiple sources into one JSON payload.
Figure 9: Payload Modeling and Transformation
Integration with AWS Lambda
Amazon API Gateway integrates with AWS Lambda to allow you to create completely server-less APIs: you can upload code snippets to Lambda and expose it as a standard REST endpoint hosted by the API Gateway without spin up an EC2 instance that runs business logic exposed as an API. This integration enables a true NoOps platform and make deployment highly available, scalable and secure with no operations required. Deploying the same applications on a traditional PaaS involves quite a bit of configuration and management.
Integration with AWS Marketplace
AWS marketplace has over 3500 software listing and an active customer base of over 100k users. You can monetize your APIs on API Gateway by publishing them as products in AWS Marketplace. Read here to learn more about API Monetization.
In this article I attempted to highlight the capabilities of Amazon API Gateway in the context of microservices deployed on AWS. API Gateway, which acts as a single-entry point into a system, is responsible for request routing, composition, and protocol translation. With the right configuration of cache and throttling, you can increase the performance while securing the backend API.
- API Gateway Pattern
- Microservices Pattern
- Netflix API Gateway example
- Amazon API Gateway
- Amazon API Gateway Pricing
- Amazon API Gateway Importer
Would you like to take a quick tour about Microsoft Azure API Management and summarizes the basic differences from API Gateway? Go to my next blog post!
Do you have any question about Amazon API Gateway benefits in microservices project? Send us. It could become the topic of the next post!