5 ms·

Building DigitalOcean's API Gateway

165 points by chynkm 6y ago

deleted 6y ago
[deleted]
nhoughto 6y ago
The decision to roll their own in golang entirely and then reimplement rails auth in golang, vs reimplement auth in lua and lean on nginx for everything else could be examined more, feels a bit like they wanted to do it in golang so nginx+lua was a non starter. Imagine how many crazy long tail problems nginx has already solved There is always the benefit of building it up yourself and understanding it more deeply tho..
- ownagefool 6y ago
  > There is always the benefit of building it up yourself and understanding it more deeply tho.. That doesn't really fly though because unless you're the same coder on the same project forever, then eventually the team will have inherited someone elses code anyways. On average, might as well be OSS that's popular, well documented and has a community around it. Think about it, what would you rather inherit? Of course, there are counter arguments. We want everything in golang because our Engineers know golang and most the CNCF toolset we use is in golang; Our usecase is simpler or specific and thus the general OSS solution would require to be tailored and that's more work than rolling our own; The OSS solution just isn't that good, and we think we can do better and have a competitive advantage by doing it internally; loads really. Understanding it better though? On average seems like short term thinking.
  - nhoughto 6y ago
    yeah fly by night eng orgs sure, if you're DO your eng maturity (esp at this point) should be such that choices are being made knowingly, eyes open about future maintenance burden might be. If an api gateway is a foundational component at DO and having more control of it in golang is more important than getting long tail learnings for free building on top of nginx thats cool. If its a big important thing than building it up from lower level is useful bc then I know how to form it into the thing that I need when all the new requirements come in, harder to do that with nginx.. but i might get hurt less along the way with nginx. i guess the tl;dr is, mature eng org shouldn't have too many dark corners for mushrooms that are important to grow, and nginx+lua choice or straight golang choice should be made informed either way.. as always.. tradeoffs! =)
    - ownagefool 6y ago
      I'm not sure I'm confident that the popular (and being fair, strong) engineering orgs don't make the decision first and work backwards justifying it like most of us do. I have no specific exposure; but the rumour is with several big tech, it's write everything from scratch ( because we're special ), only reward impact ( rewriting from scratch ), and then shut it down because you can't maintain the thing ( too expensive because we keep rewriting it from scratch ). Is it like that in reality? I dunno, but we all have our problems.
      - mchristen 6y ago
        It's not just big tech. I've seen multiple startups struggle and fail because ultimately they are building things to build things, not to solve the problem they set out to solve.
- sgt 6y ago
  We also recently started to roll our own API gateway in Java using Undertow.
- mlinhares 6y ago
  If Nginx+Lua had better development and testing support (back in 2016, I haven't really looked at it in a while) we might have gone that way. It was kinda "here's a script, load it on nginx and hope it works" so it required a considerable amount of work to make it reliable and testable. Golang actually has a lot of stuff already done for you in terms of proxying so that part of the gateway isn't really that large. There was no simple way to reload configs on the fly (other than updating the file locally with something like chef or ansible and reloading nginx on all machines) and that made it harder to provide self service routes from the get go (it's much easier nowadays with Nginx Service Mesh). Nowadays with the options available I don't think we'd build it from scratch anymore (we could even use Zuul 2 I think). I'd say our mistake was that we didn't open source it in the beginning to benefit from more external usage and contributions, the way it is tied to internal services nowadays makes this hard to pull off right now.
- spyspy 6y ago
  I’ve built an api gateway in go at my last company and my current one, so I’m actually a fan of the pattern. Usually the decision revolves around complex auth and permissioning rules that already exist in go, and would be a pain to rewrite. It also allows for custom multiplexing of requests to hit multiple downstream APIs. It also makes monitoring simpler, since you can have a view of your entire platform by just monitoring a single service. A reverse proxy in go is dead simple to write and maintain, especially if it matches the rest of your stack.
jph 6y ago
The article touches on NGINX and Lua for API gateways, and that's an approach I like very much. The NGINX website has a bunch of well-written training posts about microservices and gateways. https://www.nginx.com/resources/library/designing-deploying-microservices/ https://www.nginx.com/resources/library/designing-deploying-...
- sriku 6y ago
  Kong is an API gateway that builds on top of nginx - https://konghq.com/kong/ https://konghq.com/kong/
  - adolph 6y ago
    Kong is built on OpenResty which is NGINX with a Lua JIT. https://github.com/Kong/kong/issues/484 https://github.com/Kong/kong/issues/484 https://openresty.org/en/ https://openresty.org/en/
    - benatkin 6y ago
      KrakenD is an open source API gateway written in Go. I think they started off the same way I would, by extending nginx or a fork, or by using Go. I am not sure what I would choose. https://www.krakend.io/ https://www.krakend.io/
  - jively 6y ago
    Going to jump on the shilling thread here and recommend Tyk. Tyk is an open source API Gateway written in Go, it's also the most extensible OSS API gateway as it doesn't force you to learn Lua (Go, Python and Lua plugins are supported in-process) to extend it. In fact DO could have written their auth logic in rails with Tyk's gRPC plugin support. It also has the same performance curve as OpenResty these days as it's been around for over 5 years and used in critical high-performance infrastructure projects. https://tyk.io https://tyk.io /Shill
    - spacewander 6y ago
mojuba 6y ago
Not very knowledgable on the topic, but aren't API gateways like Amazon's and this one essentially vendor lock-in tools? Can you migrate your system across this type of gateways easily when you want to switch your vendor?
- djm_ 6y ago
  The post is about how they built their own internal API Gateway; it's not a product Digital Ocean offer (yet?).
- adolph 6y ago
  Generically any use of a vendor represents some amount of vendor lock-in since the reason why the vendor was selected often reflects some unique capability or added value of the vendor.
xorcist 6y ago
Great! You've made yourself a haproxy. The next step would be to make it dynamically configurable at runtime. Then there needs to be monitoring. And some tools for troubleshooting. There's something to be said for battle hardened tools.
- sgt 6y ago
  How flexible is haproxy though? We recently started writing our own API gateway because we needed tight integration to existing services, even support some specific legacy authentication schemes.
  - mlinhares 6y ago
    It's better nowadays, specially if you go for the paid version, I think they saw the writing on the wall that they wouldn't really have a future proof business if they kept on the "config file for everything" mantra, there's even a prometheus module you can bundle so you don't have to use the horrible metrics they had. I think it's pretty good people are building these proxies as it's forcing the entrenched vendors to move.
  - xorcist 6y ago
    Integrations are never maintenance free, however I found them much easier to write than to get a greenfield proxy up to snuff. It can call out to lua functions nowadays, but I haven't had to use that yet.
- digianarchist 6y ago
  >The next step would be to make it dynamically configurable at runtime. Like Caddy? https://caddyserver.com/ https://caddyserver.com/
  - mholt 6y ago
    Yeah, Dgraph is doing exactly this, building their own gateway as Caddy modules: https://twitter.com/caddyserver/status/1349434660107939841 https://twitter.com/caddyserver/status/1349434660107939841 > I'm impressed with how easy this was. I think I'm starting to understand why Caddy is not just a proxy, but a system for hosting apps.
PhilipA 6y ago
Very interesting article. I do believe with better documentation they probably could have been less hands on with onboarding the “customers”. I am currently creating a cloud based API gateway for primary SMBs. The current gateways are quite complex to implement, and for the simpler use cases I believe it can be done better.
rossmohax 6y ago
It would be interesting to know whether they make all service to service calls to go via API Gateway or it is for external call only and why.
adolph 6y ago
We even had to expose some of the Ruby code, mostly authorization policies, as a GRPC service so people wouldn’t have to rewrite all the policies they already had in place themselves. This is an area of interest and learning for me. A pattern of use for gateways sometimes is to provide id/auth and access the backing services with a high priv service account. This can’t be 100% of the time because some applications perform their own authorization at the data level, as in User X can see data A but not B, or in service Q user type X can crud attributes a thru d but only user type Y can enter attribute e. What other patterns do people see?

165 points by chynkm 6y ago

deleted 6y ago

[deleted]

The decision to roll their own in golang entirely and then reimplement rails auth in golang, vs reimplement auth in lua and lean on nginx for everything else could be examined more, feels a bit like they wanted to do it in golang so nginx+lua was a non starter. Imagine how many crazy long tail problems nginx has already solved There is always the benefit of building it up yourself and understanding it more deeply tho..

ownagefool 6y ago
> There is always the benefit of building it up yourself and understanding it more deeply tho.. That doesn't really fly though because unless you're the same coder on the same project forever, then eventually the team will have inherited someone elses code anyways. On average, might as well be OSS that's popular, well documented and has a community around it. Think about it, what would you rather inherit? Of course, there are counter arguments. We want everything in golang because our Engineers know golang and most the CNCF toolset we use is in golang; Our usecase is simpler or specific and thus the general OSS solution would require to be tailored and that's more work than rolling our own; The OSS solution just isn't that good, and we think we can do better and have a competitive advantage by doing it internally; loads really. Understanding it better though? On average seems like short term thinking.
- nhoughto 6y ago
  yeah fly by night eng orgs sure, if you're DO your eng maturity (esp at this point) should be such that choices are being made knowingly, eyes open about future maintenance burden might be. If an api gateway is a foundational component at DO and having more control of it in golang is more important than getting long tail learnings for free building on top of nginx thats cool. If its a big important thing than building it up from lower level is useful bc then I know how to form it into the thing that I need when all the new requirements come in, harder to do that with nginx.. but i might get hurt less along the way with nginx. i guess the tl;dr is, mature eng org shouldn't have too many dark corners for mushrooms that are important to grow, and nginx+lua choice or straight golang choice should be made informed either way.. as always.. tradeoffs! =)
  - ownagefool 6y ago
    I'm not sure I'm confident that the popular (and being fair, strong) engineering orgs don't make the decision first and work backwards justifying it like most of us do. I have no specific exposure; but the rumour is with several big tech, it's write everything from scratch ( because we're special ), only reward impact ( rewriting from scratch ), and then shut it down because you can't maintain the thing ( too expensive because we keep rewriting it from scratch ). Is it like that in reality? I dunno, but we all have our problems.
    - mchristen 6y ago
      It's not just big tech. I've seen multiple startups struggle and fail because ultimately they are building things to build things, not to solve the problem they set out to solve.
sgt 6y ago
We also recently started to roll our own API gateway in Java using Undertow.
mlinhares 6y ago
If Nginx+Lua had better development and testing support (back in 2016, I haven't really looked at it in a while) we might have gone that way. It was kinda "here's a script, load it on nginx and hope it works" so it required a considerable amount of work to make it reliable and testable. Golang actually has a lot of stuff already done for you in terms of proxying so that part of the gateway isn't really that large. There was no simple way to reload configs on the fly (other than updating the file locally with something like chef or ansible and reloading nginx on all machines) and that made it harder to provide self service routes from the get go (it's much easier nowadays with Nginx Service Mesh). Nowadays with the options available I don't think we'd build it from scratch anymore (we could even use Zuul 2 I think). I'd say our mistake was that we didn't open source it in the beginning to benefit from more external usage and contributions, the way it is tied to internal services nowadays makes this hard to pull off right now.
spyspy 6y ago
I’ve built an api gateway in go at my last company and my current one, so I’m actually a fan of the pattern. Usually the decision revolves around complex auth and permissioning rules that already exist in go, and would be a pain to rewrite. It also allows for custom multiplexing of requests to hit multiple downstream APIs. It also makes monitoring simpler, since you can have a view of your entire platform by just monitoring a single service. A reverse proxy in go is dead simple to write and maintain, especially if it matches the rest of your stack.

jph 6y ago

The article touches on NGINX and Lua for API gateways, and that's an approach I like very much. The NGINX website has a bunch of well-written training posts about microservices and gateways. https://www.nginx.com/resources/library/designing-deploying-microservices/ https://www.nginx.com/resources/library/designing-deploying-...

sriku 6y ago
Kong is an API gateway that builds on top of nginx - https://konghq.com/kong/ https://konghq.com/kong/
- adolph 6y ago
  Kong is built on OpenResty which is NGINX with a Lua JIT. https://github.com/Kong/kong/issues/484 https://github.com/Kong/kong/issues/484 https://openresty.org/en/ https://openresty.org/en/
  - benatkin 6y ago
    KrakenD is an open source API gateway written in Go. I think they started off the same way I would, by extending nginx or a fork, or by using Go. I am not sure what I would choose. https://www.krakend.io/ https://www.krakend.io/
- jively 6y ago
  Going to jump on the shilling thread here and recommend Tyk. Tyk is an open source API Gateway written in Go, it's also the most extensible OSS API gateway as it doesn't force you to learn Lua (Go, Python and Lua plugins are supported in-process) to extend it. In fact DO could have written their auth logic in rails with Tyk's gRPC plugin support. It also has the same performance curve as OpenResty these days as it's been around for over 5 years and used in critical high-performance infrastructure projects. https://tyk.io https://tyk.io /Shill
  - spacewander 6y ago

mojuba 6y ago

Not very knowledgable on the topic, but aren't API gateways like Amazon's and this one essentially vendor lock-in tools? Can you migrate your system across this type of gateways easily when you want to switch your vendor?

djm_ 6y ago
The post is about how they built their own internal API Gateway; it's not a product Digital Ocean offer (yet?).
adolph 6y ago
Generically any use of a vendor represents some amount of vendor lock-in since the reason why the vendor was selected often reflects some unique capability or added value of the vendor.

xorcist 6y ago

Great! You've made yourself a haproxy. The next step would be to make it dynamically configurable at runtime. Then there needs to be monitoring. And some tools for troubleshooting. There's something to be said for battle hardened tools.

sgt 6y ago
How flexible is haproxy though? We recently started writing our own API gateway because we needed tight integration to existing services, even support some specific legacy authentication schemes.
- mlinhares 6y ago
  It's better nowadays, specially if you go for the paid version, I think they saw the writing on the wall that they wouldn't really have a future proof business if they kept on the "config file for everything" mantra, there's even a prometheus module you can bundle so you don't have to use the horrible metrics they had. I think it's pretty good people are building these proxies as it's forcing the entrenched vendors to move.
- xorcist 6y ago
  Integrations are never maintenance free, however I found them much easier to write than to get a greenfield proxy up to snuff. It can call out to lua functions nowadays, but I haven't had to use that yet.
digianarchist 6y ago
>The next step would be to make it dynamically configurable at runtime. Like Caddy? https://caddyserver.com/ https://caddyserver.com/
- mholt 6y ago
  Yeah, Dgraph is doing exactly this, building their own gateway as Caddy modules: https://twitter.com/caddyserver/status/1349434660107939841 https://twitter.com/caddyserver/status/1349434660107939841 > I'm impressed with how easy this was. I think I'm starting to understand why Caddy is not just a proxy, but a system for hosting apps.

PhilipA 6y ago

Very interesting article. I do believe with better documentation they probably could have been less hands on with onboarding the “customers”. I am currently creating a cloud based API gateway for primary SMBs. The current gateways are quite complex to implement, and for the simpler use cases I believe it can be done better.

rossmohax 6y ago

It would be interesting to know whether they make all service to service calls to go via API Gateway or it is for external call only and why.

adolph 6y ago

We even had to expose some of the Ruby code, mostly authorization policies, as a GRPC service so people wouldn’t have to rewrite all the policies they already had in place themselves. This is an area of interest and learning for me. A pattern of use for gateways sometimes is to provide id/auth and access the backing services with a high priv service account. This can’t be 100% of the time because some applications perform their own authorization at the data level, as in User X can see data A but not B, or in service Q user type X can crud attributes a thru d but only user type Y can enter attribute e. What other patterns do people see?