Showing posts with label Kong. Show all posts
Showing posts with label Kong. Show all posts

Friday, April 6, 2018

Kong CE 0.13.0 - Services and Routes

Kong CE 0.13.0 has a new feature - Services and Routes.

The introduction of Services and Routes as new core entities. Those entities replace the “API” entity and simplify the setup of non-naive use-cases. They provide better separation of concerns and allow for plugins to be applied to specific endpoints.



With the introduction of Services and Routes, duplicates plugin definition can be avoided.

This is much cleaner and leaner in operation, especially if we are talking about tons of APIs in the micro-services world. Detailed read here.



.





Friday, January 26, 2018

Kong API Gateway CE 0.12.0 - Circuit Breaker feature

The latest Community Edition version is Kong CE 0.12.0, just released today.


Coincidentally, there is a new feature in Kong that is similar to the one released by CA API Gateway 9.3 - Circuit Breaker.


Support for health checks! Kong can now short-circuit some of your upstream Targets (replicas) from its load balancer when it encounters too many TCP or HTTP errors. 
You can configure the number of failures, or the HTTP status codes that should be considered invalid, and Kong will monitor the failures and successes of proxied requests to each upstream Target. We call this feature passive health checks. 
Additionally, you can configure active health checks, which will make Kong perform periodic HTTP test requests to actively monitor the health of your upstream services, and pre-emptively short-circuit them. 
Upstream Targets can be manually taken up or down via two new Admin API endpoints: /healthy and /unhealthy.



More technical with implementation details at GitHub - Add active and passive health checks.


Pretty cool!


.

Thursday, August 3, 2017

Kong API Developer Portal

Kong is a scalable, open source API Gateway. Kong runs in front of any RESTful API and is extended through Plugins, which provide extra functionality and services beyond the core platform.


We explored Kong few months back and liked it for its flexibility and scalability. A customer came along and was willing to give open source a try. Deal on.

During development, we discovered that Kong is overly flexible. :)  

I still remember the days when we were Compuware partner deploying and giving consultation to Dynatrace customers. There were far too many features and it allowed great flexibility. Beginners or customers who were not too technical complained. They got lost. 

With that experience still fresh in my mind, I suggested that we build a API Developer Portal on our own. And this portal should cater for this customer's daily operations. Nothing else. Whatever is not required, we should hide it.


The team has done a great job!






For this particular customer, the business use case is simple.

1. They have their internal application teams ("Clients") that want to consume APIs.
2. Each client will be issued a Client ID and Client Secret to exchange for a OAuth2 token prior to calling APIs.
3. Each client can only be granted access to specific set of APIs ("Service")


So, the UI is simplified to suit this need.

a. Create API



b. Assign API to Service



 c. Create Client and assign Service to Client




Very simple to use to get the job done.


.