In a cloud-first architecture, API gateways play a crucial role in enabling communication between different cloud services and applications. They act as a central point of control and provide a unified interface to the clients, making it easier to manage and monitor the overall system. API gateways also provide a layer of abstraction between the client and the cloud services hence allowing developing different applications while still using the same services.
In essence, an API gateway is a server that acts as an intermediary between the client and the cloud services performing many tasks such as authentication, rate limiting, caching, and protocol translation. Therefore, the API gateway can improve the performance, scalability, and security of the overall system architecture. It is commonly used in microservices and serverless architectures.
In the conventional API Gateway market, various vendors offer API Gateway solutions for managing, securing, and exposing APIs to external or internal applications. The main players are Amazon API Gateway, Kong, Rapid, Google Cloud (Apigee) and Azure API Management, among others. They offer different solutions based on their functionality and features such as Proxy, Transformation Gateways, Security, Orchestration and Monetization. Developers can choose the right one according to their specific requirements and use cases.
Examining this offering, we can identify three distinct types of API gateways: façade, exposure, and listening endpoint.
The first one, the API Gateway, acts as a facade for service implementations that operate in separate environments. The API Gateway serves as a single-entry point for all incoming API requests, abstracting the complexity of underlying microservices or distributed systems. These gateways are engineered to manage specific protocols such as HTTP and WebSocket, and they primarily focus on addressing security concerns, particularly TLS security. By using an API Gateway as a facade, organizations can simplify the management of their APIs and services, improve security, and enhance the developer experience for API consumers.
The second one, often call API Exposure Gateway, is an API Gateway which alters or enhances the implemented API that runs on a different environment. It focuses on making APIs accessible to external consumers, partners, or third-party developers. The main goal of an API Exposure Gateway is to facilitate secure, controlled, and efficient access to APIs while ensuring a positive developer experience. It can implement business logic, including caching, throttling, and even metering for billing purposes. API Exposure Gateways are crucial for businesses looking to expose their APIs to a broader audience, foster innovation, and create new revenue streams through API monetization. By providing a secure and controlled environment for API consumption, these gateways enable organizations to maximize the value of their APIs while minimizing risks.
The last one, the listening endpoint API terminates the network connection, is commonly utilized in serverless environments to instantiate the process required for executing the operation requested by the API call. This endpoint acts as an entry point for clients to access the functionality provided by the API, and it’s responsible for processing incoming requests, executing the appropriate actions, and returning the expected responses. In most cases, the API and the service function within the same environment.
Though the gateways vary in their execution, their primary goal remains consistent to act as a central entry point and intermediary for managing, securing, and exposing APIs of cloud services to external consumers or internal applications. It enables cloud services to be utilized by other cloud services or client applications without needing to comprehend the service’s inner workings. This gateway can operate in the cloud or near the client applications as an edge cloud broker.
Suppose for a moment, this cloud-centric approach didn’t exist, and it was feasible to run microservices (or functions as a service) at the edge within the device or system hosting client applications. In that case, a reverse API gateway becomes necessary to expose these microservices. However, instead of exposing cloud services to client applications, it focuses on exposing edge microservices services to either client applications or other edge microservices running on different nodes or cloud services. Consequently, each node within a system serves as an individual server running microservices with exposed APIs at the software level, establishing a ad hoc edge service mesh among all nodes capable of discovering one another.
In this edge first scenario, the reverse gateway would function as a local API Gateway, managing the microservices within the device itself. It would have a vital role in managing and securing the communication between microservices and client applications. By functioning as a local API Gateway, it would manage, secure, and optimize API traffic within the device or system, providing a unified entry point for accessing microservices and improving overall performance and security. Moreover, the local API Gateway would also enable better resource utilization and faster response times as the microservices would be running in the same environment as the client applications.
This reverse API gateway is a natural next step in the evolution of the API Architecture, well described in the Netflix technology blog.
Left to right: 1) Accessing the monolith via a single API, 2) Accessing microservices via separate APIs, 3) Using a single API gateway, 4) Accessing groups of microservices via multiple API gateways. Source: Netflix Technology Blog
Edge microservice can either access each other edge microservice on different nodes directly without going thru the cloud via reverse API gateway or access cloud microservice via a single API gateway.
The concept of device-as-a-service will then be established, allowing client applications to utilize features from a single device or a collection of devices through a series of APIs without needing to comprehend the inner workings of the implementation. This will spark a surge in innovation as it enables the development of applications using systems without requiring expertise in those specific systems. As an example, considering the automobile industry’s ongoing shift towards SDV, it is crucial to begin revealing car functionalities to developers outside of the automotive realm to harness the creative potential within the mobile app industry. A reverse API gateway is essential for accomplishing this objective.
mimik’s edgeEngine provides this reverse API gateway, enabling each node to serve as a data source at the application level. mimik’s edgeEngine allows client applications to utilize features from a single device or a collection of devices through a series of APIs without needing to comprehend the inner workings of the implementation. This edegEngine comprises an API gateway, an OS-agnostic runtime environment, a discovery service for nodes and edge microservices, and an edge analytic platform that enables each node to serve as a data source at the application level. This enables the development of applications using systems without requiring expertise in those specific systems, sparking a surge in innovation.
