Ebury Transactional API Gateway: the product selection

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

We established what was the concern and motivation for a gateway in the first RFC, much more abstract and generic.

In that document, we had decided we needed to “deploy a service that acts as a gateway”.

Here, we describe the process followed to select which gateway.

Problem Description

The specific goal of the blueprint is to select a technology that fits our known current requirements and, at the same time, can help us against unknown future problems.

This requires collaboration and good processes, because different people of the company can focus on different kinds of known and forecasted problems.

Background

We gathered specific requirements that can be evaluated and measured. The complete list of requirements was collected in a spreadsheet.

Because the pricing can depend on the requests, and the SLAs are part of the requirements, we collected some metrics on the API endpoints volume.

We sent some requests to some vendors to clarify their support for our features. Among them, we received responses from Gloo and Kong.

Some options were decided to be evaluated on our own: AWS, Ambassador, and also Kong, and Gloo even if they answered the questionnaire.

After some evaluation, we improved our requirements to be aware of the ebury 2.0 architecture. We are embracing kubernetes. Selecting a gateway that is compatible with kubernetes was not enough, we wanted to evaluate the support and the integration with the workflows. E.g., is the gateway able to act as an Ingress Controller? Is the configuration to be deployed as Kubernetes manifests?

We collected our views on the feature coverage in a different spreadsheet.

The two options with more feature support and without any red flag, were then evaluated locally. We installed and configured the products to map routes to internal and external services, using a local kubernetes cluster. We did it for Kong and for Gloo.

Solution

We reviewed everything and filled the score document.

Then, Kong is the selected option.

Alternatives

Gloo

This option was also very good, the second one only after Kong. We had the technical evaluation, a POC, some meetings with the vendor, and an evaluation of the price. The, it was discarded based on the evaluation of the fit with the provider as a company.

AWS Gateway

We evolved our requirements to find a solution that can integrate inside kubernetes and act as an Ingress Controller. Also, some of the important features required actual coding on our side, which was the opposite of our goal selecting a gateway. Most of them were "supported" only if coded in an external lambda.

Ambassador

Discarded because, after starting the evaluation, we find some key requirements were not present in the product.

Traefik

The initial prospection revealed not a good match to our requirements, so we decided not to evaluate it deeper.

Mulesoft

They did not return the questionnaire.

Caveats

Kong and Kubernetes are two new technologies to the company. Even if mature and well-documented, we still need to improve our knowledge about them to make this project successful.

Operation

Operation and monitoring will be considered in the next RFC.

Performance Impact

Nothing to talk about, at this point.

Developer Impact

The whole API Gateway project will have some impact on the developer, but will be covered in the next two RFCs.

Data Consumer Impact

None

Deployment

The deployment options were considered as part of the evaluation.

The deployment details of the selected option will be detailed in the next RFC.

Dependencies

None

References

None