Kong’s First Birthday
The first public release of Kong was launched on April 27th, 2015. We are happy to announce that yesterday Kong turned 1 year old, and we are going to take this chance to recap what happened during the long and intense past 12 months.
Kong is the most popular open source API & Microservice management gateway currently on GitHub, having just crossed 5,000 stars.
Although Kong is still pre-1.0 its production usage has been growing intensively in the past 12 months, reaching about 40,000 running active instances per month.
(The chart above is not cumulative)
Kong is rapidly reaching 1M downloads across all its distributions. We currently support the most popular distributions, and more will be added to support production adoption of Kong (including support for Mesos).
In the past 12 months we have published 23 releases of Kong, achieving the following goals:
40,000 Production Instances per Month
5,000 GitHub Stars
This is a subset of the data available, for users who haven’t disabled anonymous reports, which are used to track usage, bug reports, and help improve Kong with hundreds of bug-fixes. We thank every user who is participating in the program. As reports are asynchronous, your contribution is helping Kong become a more stable and mature product.
Support for Cassandra and PostgreSQL
Initially Kong only supported Cassandra, which was a great choice to address its usage in every environment. Thanks to Cassandra’s eventual consistency model and its replication features, Kong can be installed in single datacenter, multi-datacenter and hybrid setups.
Support for PostgreSQL was one of the most requested features since the early days of Kong, and we are happy to announce that version 0.8.0 now supports PostgreSQL. That also includes support for the multitude of Postgres SaaS offerings, like Amazon RDS.
Kong Plugins are the secret sauce of the project that deliver the actual functionality to APIs and Microservices. Today Kong counts 26 public plugins that take care of authentication, security, traffic control, transformations, monitoring, analytics and logging.
Kong has been built since day one to be easily extended with more and more plugins, and we are aware of the existence of tens of plugins privately created by the community to address their specific requirements. In order to facilitate the creation of new features we have published a Plugin Development Guide that you can use to create new functionality on top of Kong.
In its first year, the community has opened about 700 GitHub issues, of which ~460 have been closed thanks to ~500 Pull Requests. Our Community channels, including Gitter, Google Groups, are Meetups around the world (San Francisco, Boston and London to date) are growing day after day and we are happy to interact with a larger user base on a daily basis.
Users of all kind are using Kong to secure and manage both private and public APIs/Microservices. Besides the Open Source installations, we are also happy to provide Enterprise support for more critical production environments, and we are glad to count these companies and organizations among the ones that are relying on Kong for their infrastructures.
Learn more about our Community Channels.
KGG Stack: Kong, Galileo, Gelato
Building an API or Microservice is only 50% of the workload required when publishing a service publicly or privately. We, as developers, often ignore the remaining 50% of the workload required which is securing and managing our APIs, including monitoring and proper documentation.
As you already know Kong is a product created to address the Gateway and Management tasks, but I would also like to introduce Galileo (API Monitoring) and Gelato (Developer Portal). These two Mashape products that take care of your monitoring and on-boarding issues; best of all they’re highly integrated with Kong.
We like to call the combination of these products with the acronym of KGG Stack. The KGG Stack is the combination of Kong (API Management) + Galileo (API Monitoring) + Gelato (Developer Portal), and when used together they cover the remaining 50% workload when releasing an API.