Getting To Know Microservices – API Gateway Evaluation

While exploring the world of microservices more I had this thought stuck in my mind, that I should also spend time looking into technology that would help me orchestrating requests going into and out of those services. I refer to this technology as an API gateway and I see it being quite prominent amongst the companies I work with as part of my official occupation.

Furthermore I have to admit that right when I started looking into API gateways I came across Kong which sounded very interesting and I was tempted to try it out. However to make this look more like an unbiased evaluation amongst more than just one tool I also want to mention other solutions, which I researched.

Two solutions I would like to mention in one sentence are WSO2 as well as Apigee, which are both used by some of the companies I have worked with. Funny enough I came across them while working with banks and I can see these to be used mainly in a commercial scenario. Both vendors offer a SaaS based solution and there is no real freemium model available. Although WSO2 talks about open source I was surprised to not really see containers being offered as a deployment model from the company itself (although they, different to Apigee, would also allow for an on-premise installation).

AWS of course also has to be named. There is a service called “API Gateway” available and while playing with a demo endpoint it looked like all my requirements would be satisfied. However after expiring my free tier year I would not be able to use the service for free any longer.

While investigating the topics of devops and microservices I also came across a company called Hashicorp, who provides a number of interesting tools in this space. There does not seem to be one really fitting the label of an API gateway however. Then again something which caught my eye and which I might integrate into my stack at some point could be Hashicorp’s Consul. Consul deals with service discovery, which may get important, the bigger the zoo of my microservices gets.

Finally I also want to mention Tyk, which made a very good and complete impression to me. They also seem to offer builtin monitoring including dashboards available as a seperate container. Only thing to mention here might be that the freemium model ends when one decides to have more than one self hosted gateway.

None of the “limitations” I spotted with the above solutions seem to exist in Kong so I was happy to give it a thourough test run.

What I evaluated in Kong:

Proxying UI traffic to AWS’es Cloudfront (where I am expecting to host the UI going forward) and activating maintenance mode (hopefully not required anymore with blue/green deployment approach). A custom Cloudfront to S3 origin configuration had to be chosen on the S3 side in order to make using subfolders in S3 work (also see this).

curl -X POST --url http://localdocker:8001/apis/ --data 'name=harvee_ui_blue' --data 'uris=/' --data 'upstream_url=http://xyz.cloudfront.net/v1.8.7/' --data 'strip_uri=false' --data 'hosts=localdocker'

curl -X PATCH http://localdocker:8001/apis/829c9c16-3ba7-403e-9a9b-436d9e04a5c0 --data "upstream_url=http://xyz.cloudfront.net/maintenance/maintenance.html"

Proxying webservice traffic including context rewriting through usage of strip_uri parameter to cater for historically grown webservice instances which listen on different URL contexts.

curl -X POST --url http://localdocker:8001/apis/ --data 'name=harvee_ws_v1_blue' --data 'uris=/ws/api/v1.0' --data 'upstream_url=http://192.168.99.1:5000/harveews/api/v1.0' --data 'strip_uri=true' --data 'hosts=localdocker'

Proxying traffic based on target hosts name used for both UI and webservices to support green and blue deployments (where there would be a hostname to access the green environment and the same for the blue environment). See previous examples where the hosts parameter is set to localdocker. Considering this as the blue environment will mean that the green environment will use a different hosts setting (obviously localdocker refers to my test environment on my laptop).

I have not really evaluated the authentication part which I want to introduce in front of my services but I know that Kong has the concept of consumers which can have access keys assigned that then need to be used by the client. After I can be confident that Kong will allow me to reach my goals regarding the usage of an API gateway I guess it is now time to build it in a way that works for my Harvee stack.