Kong API Platform for Multi-Cloud and Hybrid Organizations
Kong API Platform for Multi-Cloud and Hybrid Organizations
Kong has evolved significantly from an open-source API gateway, handling just north-south traffic, to a full cycle API management platform.
Join the DZone community and get the full member experience.Join For Free
Last year I spoke with Marco Palladino of Kong about the company and their new product offering.
Kong was born in 2015, long before Kubernetes was released and just a couple of years after Docker. Microservices were emerging as a trend, and a shift away from legacy monoliths beginning.
But since its inception, Kong has evolved significantly from an open-source API gateway, handling just north-south traffic, to a full cycle API management platform with a service mesh for east-west traffic. It allows teams to manage how services interact and move within their architecture.
You may also like: A Summary of Kong as an API Management Solution
Why Do Enterprises Need Kong?
As enterprises pivot to microservices-driven architectures to power their core business applications and accelerate application development, the need for comprehensive API management capabilities grows. That's where Kong comes in.
Kong provides enterprises with a way of managing all their APIs, in a platform-agnostic way. This enables Kong to support and facilitate the development and transition of organizations' technological paths, integrating old and new systems as they emerge and are retired.
Kong works fantastically with Kubernetes, and it also works just as seamlessly with traditional legacy virtual machines or bare metal infrastructures. This means Kong can be used by a huge range of enterprises, each with varying levels of technological maturity.
As Marco explains, Kong wants to remain a pragmatic product that does not identify with just one particular technology so it can always support emerging trends and enable its customers to take advantage of the latest market transitions and new developments.
Kong Helps Create Trust in a Service
The problem with microservices is the sheer number that can emerge, including different versions of the same service, that are inevitably running within an environment. With such complexity, ensuring documentation is accurate and up to date poses a problem.
As different developers and teams consume each other's APIs, documentation is crucial. If something doesn't work, the API's documentation is the only thing the developer or team has. If documentation is not current, distrust among developers occurs and that's one of the main reasons microservices fail.
With Kong's dev portal, enterprises can start cataloging the APIs and microservices they are using, underlining that much-needed trust. All this can be done automatically and kept up to date using Kong Brain's documentation autogenerate functionality.
Hands-On With Kong Open Source
Despite the promise of the "5-minute quickstart", installing open-source Kong involves several steps.
Before anything else Kong needs a way to store configuration and entities to connect to. You can use a database (Cassandra or PostgreSQL) or configuration files. I initially thought I'd use PostgreSQL (incidentally their official Ubuntu installation instructions don't work, follow this Digital Ocean post instead), but for simplicity, I thought the file-based would likely be quicker. But it turns out that the quickstart only works when you use a database. I put away my documentation critic eye, finished setting up PostgreSQL and continued.
The first step of setting up Kong is adding the schema migrations it needs to the database, then you can start adding services and routes to the services for Kong to monitor. The service added in the quick start is a simple mock service, but hopefully enough to start investigating what's possible. In summary, for each service you
POST a request to
[/service](https://docs.konghq.com/1.4.x/admin-api/#add-service), and then add a route to the service
/admin-api/#add-route) using the service name specified in the last step.
The Kong project/product consists of plugins that you add and configure to provide the features you need for your service. There are plugins to add authentication, bot detection, blacklisting, rate limiting, and more. As with the steps above, you send a
POST request, specifying a route or service, and the plugin you want to enable.
Another fundamental resource for Kong is a "consumer," users that have certain levels of access to services, routes, or plugins. You can associate these with existing users from databases, or other authentication systems. Once again this takes the form of a
POST request to
/consumers/ with the user data sent as part of the request.
Hands-On With Kong Enterprise
Kong Enterprise shares many of the same concepts and adds others for more finessed permissions management. You need to sign up for a 15-day trial, so expect a lot of follow up sales emails.
Once that's done the steps to follow are similar, but you have your own hosted Kong instance. You also have the option of using the web interface to create the routes, services, and plugins, and it adds workspaces and permissions for organizing team projects.
I was most interested in the developer's portal service that Kong offers in its enterprise edition. You enable it from the dashboard, and instantly have API documentation available for any API routes added. From there you can add authentication, email templates, branding and much more.
Weigh Up the Benefits
As with all open-source versus SaaS decisions, weighing up if the cost of an external service or maintaining custom or open-source tooling yourself is always complex and individual decision to make. Have you used any API gateway services such as Kong before? What were your experiences?
Opinions expressed by DZone contributors are their own.