Kong has built on OpenResty (which is built on NGINX), Ambassador has been built on Envoy Proxy -- I think these projects will be able to sustain their velocity more so than projects that need to maintain their own L7 engine. Just watching the speed at which Envoy Proxy is adding stuff is kind of staggering; hard to imagine how another company could do the same on their own homegrown engine.
(Caveat: I’m the CEO of Tyk)
Can someone tell us what exactly is L7 ?
It seems like I cannot find any information when googling it.
So communication protocol such as gRPC and HTTP.
NB. There are more open source alternatives: API Umbrella and Tyk.
Lua per-se is a fast language (having a very small footprint), but running Lua on top of LuaJIT  is just so much faster. LuaJIT is an alternative implementation of the Lua VM created by Mike Pall and now supported by a few other folks and organizations like Cloudflare. Cloudflare in particular has a very large runtime implementation of the Lua + LuaJIT stack, and usually people are surprised to learn that at least 10% of the worldwide Internet traffic  goes through this stack.
With that said Lua + LuaJIT is being used in other applications as well, like mobile and embedded devices, where low footprint and high performance are required.
Having a low footprint is not just a nice-to-have, but a requirement for running a proxy in a Service Mesh deployment as a decentralized sidecar container (to not exhaust all the resources of the underlying VMs as we scale the number of pods and services) in addition to the traditional centralized API Gateway deployment.
You found some very low hanging fruit in the JIT engine in particular (64 global trace buckets), fixed it and at least threw it over the fence upstream (and kudos for that). But you buried it in a bunch of irrelevant figures, and at the end of the article you rediscovered GC pauses. GC pauses are a classic, well-known problem with GC languages.
My critiques are this:
1. There is a huge body of prior work and analysis of JIT'd and GC languages due to the outsized impact of Java, probably the most popular language on the planet at one point (if it isn't still). (And Golang — Java 2.0.) Java's history (and perhaps Golang's more recent history) should have been top-of-mind at the outset of this project. I think you could continue to apply lessons learned from abundance of experience around Hotspot and JRE tuning to the LuaJIT interpreter.
2. The lengthy benchmark spreadsheets seem like a distraction rather than a useful tool. They're certainly not adding much to the article and could be summarized in 2-3 sentences each. If you really felt like it, they could be linked to an external appendix.
I have researched a lot of them and none have a straight way to do metered billing and if they somehow do, they are prohibitively expensive.
Does somebody know of an API gateway solution that offers this?
What API gateway can do, is to provide you with a way to set a quota for a given user, track analytics, and have it all accessed in a programmatic way, so with a few API queries, you can know how much to bill the user. At least that's how most of the Gateways, like Tyk, do.
$500 for Apigee makes it untouchable for small startups.
Another one worth looking into might be at IBM bluemix.
We provide a full featured api management platform (gateway, dev portal, analytics, ...).
We use Eclipse Vert.x and every plugin is written in java.
The comparison between Gravitee and other competitors depends on your use case (saas/onprem/hybrid, features ootb, api gateway or api management, ...).
If you have specific concerns, please ask.
My question - what do people use these for?
Disclaimer: I am CTO of Kong .
1. 100% open source, funded by some entities, you can purchase subscription for its professional support and service.
2. 100% open source by volunteers and the community, document might be lacking but you got what you pay for.
3. open-core, only the core portion is open and you pay a premium for plugins or its enterprise-version/pro-version.
Like, support aside, what's the difference between "pay a premium to access professional services from the dev team" and "pay a premium to access a service already professionally-built by the dev team"?
1. All layers are open source, but if you want support, you pay.
3. Core layers are open source, the top layers are proprietary.
What I've seen in practice is that the useful features in question are only useful to very large companies, which is why they're gated.
Logic being, "if you're in need of this, you most definitely can afford the premium product, and we'd like you to be sponsoring our work since it's necessary for you to make money".
Is it better to let the open source project die on the Hill of Principles, and have nobody actually benefit from the potential wasted work?