7 ms·

Gravitee: Open-Source API Gateway

165 points by ausjke 8y ago

joombaga 8y ago
Trying it out now. For those who have already: how does Gravitee compare w/ Apigee, Kong, API Gateway etc.
- tarcio 8y ago
  Keen to know that too. We are heavily relying on Kong at my work.
- jxub 8y ago
  API Gateway is closed source for one. Kong is written in Lua, for better or worse.
  - fosk 8y ago
    Hello, Marco here (CTO of Kong). Correct, Kong is primarily written in Lua with some bits in C, for two particular reasons: low latency and very high performance. Lua per-se is a fast language (having a very small footprint), but running Lua on top of LuaJIT [1] 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 [2] 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. [1] http://luajit.org/ http://luajit.org/ [2] https://blog.cloudflare.com/cloudflare-traffic/ https://blog.cloudflare.com/cloudflare-traffic/
    - judge2020 8y ago
      Recent CF blog (by a guest author) about increasing LuaJIT performance https://blog.cloudflare.com/more-consistent-luajit-performance/ https://blog.cloudflare.com/more-consistent-luajit-performan...
      - loeg 8y ago
        tl;dr: Lua is a GC language and that's where the variance comes from.
        fsfod 8y ago
        As the co-author of that blog post a more accurate tl;dr would be the variance comes from shared hot counters that collide based on the address of objects.
        loeg 8y ago
        Ok, to resummarize: LuaJIT is a JIT'd interpreter for a GC'd language and those two factors are where the variance comes from. 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.
    - ThePhysicist 8y ago
- rdli 8y ago
  From what I gather in the GitHub repository, they implement their own L7 management, instead of using NGINX, Envoy, HAProxy, etc. IMO, this adds quite a bit of development cost with minimum benefit. 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.
  - jively 8y ago
    Tyk runs its own L7 engine, mainly around primitives provided by the Golang stdlib, IMO having full control over this part provides a lot more flexibility than sitting on top of someone else’s stack, bugs are faster to eke out and optimisation doesn’t rely on upstream code. (Caveat: I’m the CEO of Tyk)
    - alain_gilbert 8y ago
      Sorry for asking simple questions. Can someone tell us what exactly is L7 ? It seems like I cannot find any information when googling it.
      - alain_gilbert 8y ago
        For those interested, "L7 engine" seems to be the "application layer" https://en.wikipedia.org/wiki/Application_layer https://en.wikipedia.org/wiki/Application_layer in the OSI model https://en.wikipedia.org/wiki/OSI_model https://en.wikipedia.org/wiki/OSI_model So communication protocol such as gRPC and HTTP.
- niutech 8y ago
  Here is an answer from Gravitee dev: https://dev.to/brasseld/comment/25kb https://dev.to/brasseld/comment/25kb NB. There are more open source alternatives: API Umbrella and Tyk.
whoisjuan 8y ago
Why none of these API gateways offer monetization out of the box? I'm curious. Is that a not well-demanded feature? 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?
- LeonidBugaev 8y ago
  Billing is a hard issue since there is no common API to do that. All payment gateways are different. And what is most important, it lot of cases it requires some application logic, on how exactly you want to bill the user: for example partly static, partly dynamic. 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.
  - jbramble81 8y ago
    I think key issue here is that legacy api management solutions lock you into their billing flows and providers. An open SRC gateway like Tyk will give you freedom to use your own billing solution and define your own verticals at expense of slightly more complexity at integration/implementation.
- danieldsj 8y ago
  Apigee has some monetization features... https://docs.apigee.com/api-platform/monetization/basics-monetization https://docs.apigee.com/api-platform/monetization/basics-mon...
  - whoisjuan 8y ago
    They do, but it's $500 USD per month for the most basic plan. I'm looking for something that can start small and scale as needed.
- sunsetMurk 8y ago
techntoke 8y ago
Not speaking about the project itself, but since when did 100% Open Source become a thing?
- tomnipotent 8y ago
  Kong has Community Edition and an Enterprise Edition with non-free/proprietary features (same model as MySQL, Nginx, GitLab, & Redis). It's called the open-core model. Company is signaling that it intends to offer all features open source and without restriction. https://en.wikipedia.org/wiki/Open-core_model https://en.wikipedia.org/wiki/Open-core_model
  - ausjke 8y ago
    the evil is in the details so it really depends on the boundary where the core is defined at, in nginx/mysql's case, the core is large enough for 99% small players, and the big players are willing to pay and the income is enough to sustain the projects. I somehow feel Kong's core is a bit limited which is how I found out Gravitee.
- ausjke 8y ago
  3 popular OSS models: 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. I personally do not use option 3, and I think 1 is great for both sides.
  - scrollaway 8y ago
    What is the practical difference between 1 and 3? 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"?
    - 8y ago
TylerJewell 8y ago
Wso2 has a fully ASLv2 licensed API management solution which also includes a high performance gateway. It has monetization items included. Deployed to 1000s of accounts and running some environments with billions of transactions a day. Excited to take a look at this new entrant.
chuhnk 8y ago
Throwing my hat in the ring. Micro provides an API gateway that routes dynamically via service discovery. It's written in Go and includes a surrounding toolkit of useful features. It's also entirely pluggable. https://github.com/micro/micro https://github.com/micro/micro
jabl 8y ago
Is this something like an implementation of Googles beyondcorp model? https://beyondcorp.com/ https://beyondcorp.com/
- dyu 8y ago
  I'd say it's lower in the stack, and probably for a different audience. If you really wanted to, you can probably implement BeyondCorp using (but not only using) this or one of its competitors mentioned in this thread; but it's only part of the equation and leaves out the authorization logic of BeyondCorp.
sheeshkebab 8y ago
Running these api gateways on your own is very complex, especially when they need to be open publicly. Typically you’d want to layer a WAF and a CDN on top of them, which already come with their own api gateway like features (eg AWS cloudfront). My question - what do people use these for?
- fosk 8y ago
  API Gateways back in the days were primarily being adopted at the edge for external traffic, but they are increasingly being used internally to connect teams/products together, or in a Service Mesh deployment pattern for microservices. Solutions provided by cloud vendors are generally not well suited for all the N-S and E-W use-cases that typically an organization requires, they are usually slow (which in turn prevents more decoupled and traffic intensive architectures from working well), provide little extensibility options and while are every cheap to get up and running with, they also get expensive very quickly as traffic increases exponentially. Disclaimer: I am CTO of Kong [1]. [1] https://konghq.com https://konghq.com
  - Bombthecat 8y ago
    Yeah, my current project is using an internal / external api gateway style. You run into so many issues... You kinda want to run away (beside performance) it is super hard to actually manage / govern etc..
wongarsu 8y ago
This seems geared towards REST APIs. I would love something similar with good GraphQL support
- Bombthecat 8y ago
  Second this! It is still rarely used. But it's usage is growing.
kalman5 8y ago
Http API? When a GRPC one?
revskill 8y ago
I don't get the idea of API Gateway. Is it to secure, or reuse code logic, or load balance ??? Because as i see, gateway is the central point of downtime of the whole system.
NicolasGeraud 8y ago
Hi, I'm Nicolas (CEO of GraviteeSource, the company behind Gravitee.io). 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.

165 points by ausjke 8y ago

joombaga 8y ago

Trying it out now. For those who have already: how does Gravitee compare w/ Apigee, Kong, API Gateway etc.

tarcio 8y ago
Keen to know that too. We are heavily relying on Kong at my work.
jxub 8y ago
API Gateway is closed source for one. Kong is written in Lua, for better or worse.
- fosk 8y ago
  Hello, Marco here (CTO of Kong). Correct, Kong is primarily written in Lua with some bits in C, for two particular reasons: low latency and very high performance. Lua per-se is a fast language (having a very small footprint), but running Lua on top of LuaJIT [1] 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 [2] 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. [1] http://luajit.org/ http://luajit.org/ [2] https://blog.cloudflare.com/cloudflare-traffic/ https://blog.cloudflare.com/cloudflare-traffic/
  - judge2020 8y ago
    Recent CF blog (by a guest author) about increasing LuaJIT performance https://blog.cloudflare.com/more-consistent-luajit-performance/ https://blog.cloudflare.com/more-consistent-luajit-performan...
    - loeg 8y ago
      tl;dr: Lua is a GC language and that's where the variance comes from.
      - fsfod 8y ago
        As the co-author of that blog post a more accurate tl;dr would be the variance comes from shared hot counters that collide based on the address of objects.
        loeg 8y ago
        Ok, to resummarize: LuaJIT is a JIT'd interpreter for a GC'd language and those two factors are where the variance comes from. 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.
  - ThePhysicist 8y ago
rdli 8y ago
From what I gather in the GitHub repository, they implement their own L7 management, instead of using NGINX, Envoy, HAProxy, etc. IMO, this adds quite a bit of development cost with minimum benefit. 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.
- jively 8y ago
  Tyk runs its own L7 engine, mainly around primitives provided by the Golang stdlib, IMO having full control over this part provides a lot more flexibility than sitting on top of someone else’s stack, bugs are faster to eke out and optimisation doesn’t rely on upstream code. (Caveat: I’m the CEO of Tyk)
  - alain_gilbert 8y ago
    Sorry for asking simple questions. Can someone tell us what exactly is L7 ? It seems like I cannot find any information when googling it.
    - alain_gilbert 8y ago
      For those interested, "L7 engine" seems to be the "application layer" https://en.wikipedia.org/wiki/Application_layer https://en.wikipedia.org/wiki/Application_layer in the OSI model https://en.wikipedia.org/wiki/OSI_model https://en.wikipedia.org/wiki/OSI_model So communication protocol such as gRPC and HTTP.
niutech 8y ago
Here is an answer from Gravitee dev: https://dev.to/brasseld/comment/25kb https://dev.to/brasseld/comment/25kb NB. There are more open source alternatives: API Umbrella and Tyk.

whoisjuan 8y ago

Why none of these API gateways offer monetization out of the box? I'm curious. Is that a not well-demanded feature? 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?

LeonidBugaev 8y ago
Billing is a hard issue since there is no common API to do that. All payment gateways are different. And what is most important, it lot of cases it requires some application logic, on how exactly you want to bill the user: for example partly static, partly dynamic. 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.
- jbramble81 8y ago
  I think key issue here is that legacy api management solutions lock you into their billing flows and providers. An open SRC gateway like Tyk will give you freedom to use your own billing solution and define your own verticals at expense of slightly more complexity at integration/implementation.
danieldsj 8y ago
Apigee has some monetization features... https://docs.apigee.com/api-platform/monetization/basics-monetization https://docs.apigee.com/api-platform/monetization/basics-mon...
- whoisjuan 8y ago
  They do, but it's $500 USD per month for the most basic plan. I'm looking for something that can start small and scale as needed.
sunsetMurk 8y ago

techntoke 8y ago

Not speaking about the project itself, but since when did 100% Open Source become a thing?

tomnipotent 8y ago
Kong has Community Edition and an Enterprise Edition with non-free/proprietary features (same model as MySQL, Nginx, GitLab, & Redis). It's called the open-core model. Company is signaling that it intends to offer all features open source and without restriction. https://en.wikipedia.org/wiki/Open-core_model https://en.wikipedia.org/wiki/Open-core_model
- ausjke 8y ago
  the evil is in the details so it really depends on the boundary where the core is defined at, in nginx/mysql's case, the core is large enough for 99% small players, and the big players are willing to pay and the income is enough to sustain the projects. I somehow feel Kong's core is a bit limited which is how I found out Gravitee.
ausjke 8y ago
3 popular OSS models: 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. I personally do not use option 3, and I think 1 is great for both sides.
- scrollaway 8y ago
  What is the practical difference between 1 and 3? 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"?
  - 8y ago

TylerJewell 8y ago

Wso2 has a fully ASLv2 licensed API management solution which also includes a high performance gateway. It has monetization items included. Deployed to 1000s of accounts and running some environments with billions of transactions a day. Excited to take a look at this new entrant.

chuhnk 8y ago

Throwing my hat in the ring. Micro provides an API gateway that routes dynamically via service discovery. It's written in Go and includes a surrounding toolkit of useful features. It's also entirely pluggable. https://github.com/micro/micro https://github.com/micro/micro

jabl 8y ago

Is this something like an implementation of Googles beyondcorp model? https://beyondcorp.com/ https://beyondcorp.com/

dyu 8y ago
I'd say it's lower in the stack, and probably for a different audience. If you really wanted to, you can probably implement BeyondCorp using (but not only using) this or one of its competitors mentioned in this thread; but it's only part of the equation and leaves out the authorization logic of BeyondCorp.

sheeshkebab 8y ago

Running these api gateways on your own is very complex, especially when they need to be open publicly. Typically you’d want to layer a WAF and a CDN on top of them, which already come with their own api gateway like features (eg AWS cloudfront). My question - what do people use these for?

fosk 8y ago
API Gateways back in the days were primarily being adopted at the edge for external traffic, but they are increasingly being used internally to connect teams/products together, or in a Service Mesh deployment pattern for microservices. Solutions provided by cloud vendors are generally not well suited for all the N-S and E-W use-cases that typically an organization requires, they are usually slow (which in turn prevents more decoupled and traffic intensive architectures from working well), provide little extensibility options and while are every cheap to get up and running with, they also get expensive very quickly as traffic increases exponentially. Disclaimer: I am CTO of Kong [1]. [1] https://konghq.com https://konghq.com
- Bombthecat 8y ago
  Yeah, my current project is using an internal / external api gateway style. You run into so many issues... You kinda want to run away (beside performance) it is super hard to actually manage / govern etc..

wongarsu 8y ago

This seems geared towards REST APIs. I would love something similar with good GraphQL support

Bombthecat 8y ago
Second this! It is still rarely used. But it's usage is growing.

kalman5 8y ago

Http API? When a GRPC one?

revskill 8y ago

I don't get the idea of API Gateway. Is it to secure, or reuse code logic, or load balance ??? Because as i see, gateway is the central point of downtime of the whole system.

NicolasGeraud 8y ago

Hi, I'm Nicolas (CEO of GraviteeSource, the company behind Gravitee.io). 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.