The RESTful API software style provides an easy manner for client applications to gain access to the resources (data) they need to meet business needs. In fact, it did not take long for Javascript-based frameworks like React, Angular and Vue to rely on RESTful APIs and lead the need for enhancement of legacy web-based applications.
This pattern of RESTful service APIs and frontend Javascript frameworks sparked a desire for many organizations to fund projects migrating away from monolithic or outdated applications. In doing so an outdated application design was ultimately replaced with a very large RESTful API and an equally large Javascript framework. This created challenges with coordinating future features and enhancements.
Today many service-based applications today follow a design similar to what is illustrated below:
In this example, each service has implemented six common components at the service layer. This leads to duplication which must be managed manually – especially when the underlying source code (as shown above) utilizes different languages and frameworks.
As a feature developer, one will strive for ways that can be more productive. Ideally one can maximize the amount of time allocated to meeting acceptance criteria and making business rules lead to successful product enhancements.
So what if the illustration above was refactored and consolidated as shown below?
In the example above, all of the duplicate components are consolidated into a distributed microservice abstraction layer, which is commonly referred to as an API gateway. In fact, I discovered this very design with Kong’s Cloud-Native API Gateway product – also known as “Kong Gateway”.
Kong Gateway:
The Kong Gateway product allows the complexity of any service-tier APIs to be reduced to a collection of endpoints (or URLs) focused on meeting a collection of business needs and functionality. Often duplicated components (like authentication, logging, and security) are handled by the gateway and can be removed from the service-tier design.
In addition to the common components shown in the original illustration, Kong Gateway offers additional functionality:
- Dynamic Load Balancing
- Health Checks
- Service Discovery
- Serverless
- Clustering
- Scalability
- Performance
The best part of Kong Gateway is that it is a cloud-native (platform agnostic) open-source software (OSS) solution, which can be utilized pretty much anywhere. There are also no licensing costs while utilizing the OSS product
Kong Ingress Controller:
For those organizations using Kubernetes for their container orchestration, Kong created the Kong Ingress Controller which implements authentication, transformations, and other functionalities (via plugins) across Kubernetes clusters.
Kong Ingress Controller updates a standard Kubernetes implementation as shown below
With the Kong Ingress Controller in place, the features noted in the Kong Gateway product are accessible via the plugin architecture. Six plugins are depicted in the example above.
Using the open-source version of Kong Gateway, the following plugins could be easily added following the same pattern noted above:
- Basic and JWT Authentication
- CORS and IP Restrictions
- ACL and Request Size Limitations
- Invoke Serverless Functions
- Data Transformations
- Multiple Logging Options
Conclusion:
Kong provides products and services to not only avoid service-tier duplication but in many cases abstract common components away from the mind of the feature developer. The result of this approach allows a code-base that is lean and focused on meeting acceptance criteria.
Kong follows this same themselves, allowing aspects from Kong Gateway to be implemented as a plugin in the Kong Ingress Controller product. As a result, components are configured once and leveraged everywhere.
Kong employs a platform-agnostic approach, allowing legacy applications to utilize the same services for short or long-term periods of time. As a result, supporting the pain points noted in the introduction of this publication becomes less of an issue