Ebury API Gateway: architecture

The underlying goal is to streamline the API request flow, using a gateway to replace some existing services.

Problem Description

Kong, as every other gateway product, has lots of options to be deployed, managed, monitored, and configured.

This does not make the final deployment easier. Even it can make it more complex, because we have more possibilities to have something we don’t need or we don’t want.

Background

We documented motivation and the product selection in the two previous blueprints.

This blueprint sketches the desired final role the gateway will play on the API architecture.

Solution

We will deploy Kong outside kubernetes, allowing for high-level separation of traffic between different configurations, as Kong "Services". This deployment in ECS will help us to understand Kong deployment and configuration. In the future, Platform area will only support one operating environment, kubernetes, and this two services will be migrated to it.

Kong data plane will receive traffic from a Load Balancer. Kong data plane will direct traffic to the k8s ingress Load Balancer, and to external services when needed.

Every environment will have a different Kong deployment and so a different database, initially. But for environments that share a k8s cluster, we will try to share also the kong instance, using Kong Workspaces. Local development of the gateway can be done just pointing the local instance to the right developer workspace in the cloud. Kong control plane will manage database schema and migrations. We will use RDS following vendor recommendations.

Alternatives

Kong as Ingress Controller

Kong licensing model enforces limits on the "Services" that can be configured. Services are designed to allow for seamless routing while allowing different configurations for each public endpoint.

While we appreciate the routing capabilities of Kong, we don't think that using it can make a good fit for our architecture: it would limit the number of services we could expose through it.

Deploying Kong as Ingress Controller would make it the default routing mechanism, and the licensing could then become a limitating factor in our design. We don't want that.

Caveats

How the internal endpoints (like BOS, or other admin interfaces) and Kong control plane itself are going to be exposed is not in the scope of this document. Note that, since we booked a license that depends on the number of services, making internal admin interfaces to use Kong would need an explicit consideration. Said that, the global understanding is that BOS and other admin interfaces are not going to use Kong as an API Gateway.

Operation

Kong staff will guide us to integrate and operate this proposal. That mean that details about operation, continuous integration and configuration/secrets management will not be covered in this document. We will have a low level document that will harness everything we learn in the process.

Performance Impact

Kong is nginx-based and it has a great performance for proxying traffic. The option we selected can have more "hops" but that barely affects the performance itself neither the perceived one: if everything else is in a good shape, the latency added is to be neglected.

Developer Impact

At the end, everything related to the authentication and other non-functional requirements of the API will live in the gateway. That can impact the way we think on the new features right now. For this architecture to be successful, we need to leverage the most out of the gateway, and keep the API layer slim and business focused.

Data Consumer Impact

None

Deployment

It is covered through the whole document.

Dependencies

This blueprint depends on the selection of Kong as a product for the gateway.

References

None