Kong Raises $43M in Series C Funding

We've been using openresty in production at vwo.com at our edge nodes for quite a few years. It's really fantastic, allowing you to write custom logic and embed it within nginx itself, making things super fast.

The only real disadvantage is the lack of a good library ecosystem within lua and openresty. Over the years, as we moved some more logic to edge because $reasons, we ended up rolling our own libs quite a few times. Documentation can be made much easier as well.

That, and the occasional limitations of Lua as a language.

Overall though, quite an awesome project.

Since Kong 1.0 it can run in both centralized or decentralized mode as a sidecar for Service Mesh. And since v1.1 the database can even be optional. We are executing very fast with the feedback of the community and our customers.

I once had to implement a giant ip address blacklist for an api in the fastest and cheapest way possible. Openresty and redis saved me that day. That has been my favorite project that I've ever worked on. Two amazing pieces of software. Kong is great, too. We were just unable to use it because its blacklist feature wasn't easy to implement.

This was also my immediate thought. Naming is hard. Globally unique names that actually convey something about what you do, are recognizable, and sound pleasant to speakers of most languages seems even harder.

I was thinking of Kongregate, which most of its users abbreviate as "Kong". Was like wow, they are really expanding!

No doubt!

Most of the Kong adoption is free and comes from the open-source version, which you can download for free [1] and perhaps even contribute to [2]. We support an extensibility framework [3] that the community has been using to extend Kong (more than 500+ plugins on GitHub), including about 30 plugins that are shipped for free in the open-source distribution [4].

Kong is modular by design so that we could walk away from bundled complexity, and that's really why we created the concept of Plugins. Plugins can be installed, distributed, and used independently and they can be removed anytime (not just disabled, but entirely removed from the actual runtime).

[1] - https://konghq.com/install/

[2] - https://github.com/Kong/kong

[3] - https://docs.konghq.com/latest/plugin-development/

[4] - https://docs.konghq.com/hub/

Disclosure: I work at Kong.

The simplest way to think of Kong is as a piece of software that controls traffic going in and out of an API. At its simplest form, it helps make sure that traffic gets to the right API, is secure, etc.

Where Kong really differentiates itself is its ability to support decentralized software architecture patterns like microservices, service mesh, etc as well as traditional monoliths, regardless of the underlying platform or hardware. Microservices make deploying software a lot faster, and we're the connective tissue that lets those microservices work together smoothly and with older legacy systems.

Kong is indesed open source. We also have an enterprise version that adds a lot of features that make managing kong in an enterprise much easier.

I work in API management and API gateways and related tech (IOT, security, api designt, digital transformation etc)

Kong makes a pretty neat impression in buisness, because it is "enterprise" supported and get recognized now as "others use it, so I can't be bad!"

And kong is miles and miles ahead of IBM, axway, CA and CO.

There is better and newer tech on the way to allow cloud mesh api (hyper) integration. But they are not on the "enterpricey" list (pun intented)

Had a brief look at it when considering an API gateway frontend for several microservices; as such it solves things like rate limiting, centralised authentication etc. Based on tried and tested tech like nginx, so has maturity as a benefit. If I remember the pro version offers some conveniences, secures the control pane better than the O/S version, and I imagine is supported commercially for those who need it.

Used Kong but don’t know too much about the internals other than I’ve heard it’s a wrapper on Nginx intended to be used as a proxy. Looking at some features around caching I was thinking about implementing they seem to have implemented a typical upsell tier around “plugins” or “features” not core to the product to charge for.

Kong is indeed a lot more than just a load balancer or proxy. We provide an ecosystem of functionality on top of high performance proxy core to allow you to better manage how your APIs, services, and applications interact with each other and with the world.

You could use us as an alternative to Istio, or you could integrate us with Istio. We provide additional control capabilities on top of what Istio does, and also service decentralized and centralized deployments. Basically, you could use Istio for a mesh (or use kong for the same mesh) and then use Kong to connect all your legacy apps and services into the same control platform. That way, you get global visibility and control at multiple layers - so you can get as granular as you want or as macro as you want.

Hopefully this isn't made into a problem that doesn't really exist ala elastic, redis, etc. To me this is a real opensource success story -- openresty / the lua bits of nginx that came out of taobao really upped the level of what you could do with nginx. Kong is a huge, nontrivial addition that builds on top of that work, the result of carving out a product focus area and really iterating on what businesses / enterprises need. This is really the best of open source, IMO.

Kong Cloud is a SaaS version of Kong Enterprise.

Do you mean under performing as in proxying performance? We do know there are some code paths that need to be optimized. For 1.2 we will be working on those issues, and for many of them, we already have solutions (in many cases more than one approach). A warmed up Kong usually runs with sub-millisecond latency, the plugins can usually add more to it, but sure there are rough edges, especially in p99. We'll just need to pick up the best ideas that have already been proposed, either by us or our community. For some issues we have a public pull requests in place for discussion. And some of them we have developed in close collaboration with the community or customers. We sure want to be lean and fast. Especially now that Kong is used as a sidecar proxy in service mesh.

After a large major release there could be problems in specific use-cases, I would try again with a 1.0.x release or 1.1.x - Kong prouds itself to be very fast, so I would like to get in touch with you to dig down into any problem you have experienced. You can find me on Twitter at @subnetmarco

neither Kong nor its infrastructure (i.e. nginx) have any future on the long term against envoy. Simply time is against them even if it is going to be very slow downfall. I guess that's the real reason nginx sold itself right in the peak of the economic cycle and before envoy gets the sufficient popularity

No the investors get the real numbers that we don't get. Number of customers, customer acquisition costs, revenue, trailing growth, churn, etc. etc.

Reading anything other than the title in these types of posts are not worth anyone's time.