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..
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.
> 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.
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! =)
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.
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.
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.
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.
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.
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.
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.
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.
From customers that have performance tested us against Kong and NGinX during competitive tender (where we also won the business). Unfortunately those aren't public.
There's a decent blog post my head of research did a while 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.
Claim: I am the core developer of APISIX, and I am also the core developer of OpenResty (known as Nginx + Lua). I have written Go for several years and I have contributed to github.com/golang/go.
We have done some benchmarks around APISIX, Kong, Tyk. APISIX is the fastest (APISIX > Kong > Tyk).
All of them have rich features and fantasy GUI.
If people really care about the performance, it would be good to consider APISIX. Remember to benchmark every candidates in your own environment, even if you do not benchmark them correctly (every vendor complains others can't do benchmark correctly, some even don't allow others to do benchmark[1][2]), it is the way you use them in the production.
Advertisement time is over. Let's talk something irrelevant to my employer.
If you care about performance, forget about writing a plugin with a guest language. A guest language is a language doesn't supported by the gateway natively, like Go in Kong and Lua in Tyk. The performance waste in ctx serialization and IPC are huge. I have seen these complains for more than one.
> Imagine how many crazy long tail problems nginx has already solved
There is a problem I believe that API Gateways based on Go can't solve it unless Go have made its GC as good as Java's. Some people have consulted with me about replacing their Go implementation to a Nginx or Envoy one because this problem.
Go's GC is excellent btw, a massive benefit is also that you don't need the whole Java VM to run your app.
For pure performance, go write something in C or Rust. In fact for folks that are obsessed with performance rolling your own is the only option. Which is probably why the DO team went down this path.
For most use cases the benefit of working in your dev teams context / language of choice outweighs performance considerations.
And at Tyk the go plugins are native, you can slow down the GC activity to really boost performance if you have RAM to spare. Speed isn't an issue.
Ultimately it comes down to what you are trying to accomplish. What's best for your dev team? How can you innovate faster? How can you get this done cost effectively.
Performance comparisons are a dick measuring contest that are rarely relevant to the problem you are trying to solve.
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.
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.
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?
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.
There is always the benefit of building it up yourself and understanding it more deeply tho..