Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gravitee: Open-Source API Gateway

gravitee.io

Post reply on HN
Print view View original

31–40 of 47 posts

Re: Gravitee: Open-Source API Gateway

#31

Post by testrun »

scrollaway wrote: post #29
ausjke wrote: post #22

Earlier quoted context omitted.

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 gre…

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"?

Onion layers.

1. All layers are open source, but if you want support, you pay.

3. Core layers are open source, the top layers are proprietary.

Re: Gravitee: Open-Source API Gateway

#32

Post by KajMagnus »

scrollaway wrote: post #29
ausjke wrote: post #22

Earlier quoted context omitted.

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 gre…

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"?

For a company that can create its own professionals related to the product, only alt 1 (but not 3) will be free. For example, not all people feel the need to buy RHEL support; they use CentOS instead.

Re: Gravitee: Open-Source API Gateway

#33

Post by scrollaway »

testrun wrote: post #31
scrollaway wrote: post #29

Earlier quoted context omitted.

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"?

Onion layers. 1. All layers are open source, but if you want support, you pay. 3. Core layers are open source, the top layers are proprietary.

It's not uncommon to request custom software modifications in case #1. Which brings you to case #3 in all but name.

Re: Gravitee: Open-Source API Gateway

#35

Post by jively »

rdli wrote: post #27
joombaga wrote: post #2

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

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 eng…

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)

Re: Gravitee: Open-Source API Gateway

#36

Post by alain_gilbert »

jively wrote: post #35
rdli wrote: post #27

Earlier quoted context omitted.

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 eng…

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)

Sorry for asking simple questions.

Can someone tell us what exactly is L7 ?

It seems like I cannot find any information when googling it.

Re: Gravitee: Open-Source API Gateway

#37

Post by egeozcan »

scrollaway wrote: post #33
testrun wrote: post #31

Earlier quoted context omitted.

Onion layers. 1. All layers are open source, but if you want support, you pay. 3. Core layers are open source, the top layers are proprietary.

It's not uncommon to request custom software modifications in case #1. Which brings you to case #3 in all but name.

#3 means the company will purposefully put very useful features out of scope of the core, while in #1, people expect everything that's not very custom to a specific use-case to be open-sourced eventually - which is usually the reality.

Re: Gravitee: Open-Source API Gateway

#38

Post by alain_gilbert »

alain_gilbert wrote: post #36
jively wrote: post #35

Earlier quoted context omitted.

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)

Sorry for asking simple questions. Can someone tell us what exactly is L7 ? It seems like I cannot find any information when googling it.

For those interested, "L7 engine" seems to be the "application layer" https://en.wikipedia.org/wiki/Application_layer in the OSI model https://en.wikipedia.org/wiki/OSI_model

So communication protocol such as gRPC and HTTP.

Re: Gravitee: Open-Source API Gateway

#39

Post by scrollaway »

egeozcan wrote: post #37
scrollaway wrote: post #33

Earlier quoted context omitted.

It's not uncommon to request custom software modifications in case #1. Which brings you to case #3 in all but name.

#3 means the company will purposefully put very useful features out of scope of the core, while in #1, people expect everything that's not very custom to a specific use-case to be open-sourced eventually - which is usually the reality.

I get where you're coming from, but is that the reality?

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?

Re: Gravitee: Open-Source API Gateway

#40

Post by dyu »

jabl wrote: post #15

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

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.
Post reply on HN