This Is How We Kong
By: Shai Moria, Software Engineer @zooz
When we first started building PaymentsOS, ZOOZ’s open payments platform, we needed a quick and reliable solution for our API gateway. Eventually, we decided to go with a 3rd party service that looked very suitable for us at the time.
As PaymentsOS evolved, things became more complicated. The time it took for new features to become ‘production-ready’ was getting longer and longer and maintaining existing code had become a very difficult task.,In addition, we used Javascript for additional flexibility, even though the way we used it ran counter to the best practices defined by the 3rd party service. On top of that, we experienced downtime on several occasions, which we could not control since we were using a 3rd party solution. This led us to search for an alternative.
We decided the alternative should satisfy the following conditions:
- ‘In house solution’ — all the code base should be stored on our infrastructure and servers so that we have maximum control over everything that happens.
- It must be a very fast gateway in order to quickly process our requests.
- Test infrastructure should be easy to develop and maintain.
- Can horizontally scale easily.
- Code maintenance should be as simple as possible.
- Ability to expand the gateway functionality easily.
After evaluating our options, we selected the Kong open source project.
Kong is an Open Source Microservice API Gateway developed by Kong Inc. Kong, which is built on top of nginx. It allows developers to reduce complexity and deployment times when implementing an API solution. Nginx is a web server which can also be used as a reverse proxy or a load balancer.
After we studied a bit about how Kong works and how to custom dockerize it in a container, we performed load tests inside our pre-production environment. The load tests passed with great success and without much effort from Kong. As I mentioned earlier, Kong is built on top of nginx which has the ability to handle more than 10,000 simultaneous connections with a low memory footprint (~2.5 MB per 10k).
The second thing we did, was to start building all the necessary functionality that is used by all our micro gateways. Kong is a lua application designed to load and execute lua modules and therefore you can build ‘custom plugins’ that execute for every request and/or response passing through Kong in a predetermined order. Some examples of the custom plugins we built include: Authentication plugin, Logging plugin, Error Handling plugin, API Versioning Mapper plugin and more.
In PaymentsOS, we use Akamai CDN as the entry point. This means that every request in our system first passes through Akamai before entering PaymentsOS. When we look at the big picture of our architecture using the 3rd party gateway, it looks something like this:
As shown in the figure above, each request passes through Akamai and the gateway before entering the production environment. We took advantage of this architecture to gradually shift all the traffic from the 3rd party gateway into Kong (which now lives inside the production environment as a service) as shown in the figure below:
In this manner, we could slowly shift all proxies one by one until all traffic goes straight to Kong, after which we could close the 3rd party gateway.
In the next blog on this topic, we will take a deep dive into how we build all the custom plugins and dockerize the Kong inside a container.
Visit us at www.zooz.com
