Personal Account of Stress Testing API Gateways Built on Envoy Proxy | Hacker News Reader

Personal Account of Stress Testing API Gateways Built on Envoy Proxy

dev.to

14 pointstexascloud5 comments

Nice, clear read. It seems like Gloo was the clear winner once you dug in. The tests were a bit limited, but since you've toyed with both, do you see a case where you'd still run with Ambassador? We've only spun up something really small, but were leaning toward Ambassador for the same reason you had (seemed really clear). Did Ambassador have any positives over Gloo other than how easy the docs were to step into?

My co-worker had been daunted by the Gloo docs, but I don't think he reached out like you did. He said he didn't get far enough to use their UI, which doesn't seem like it matters, but I kind of like the edge stuff for Ambassador. Did you get you try either?

Gah! Just when we thought we were done pre-evaluating.

Thanks!

I think Ambassador has better self-service CRs that function together well without needing to define explicit dependencies. An example is TLSContexts and Mappings. As long as you have a host value in your mapping which matches exactly the host value of a TLSContext, that cert is used. With Gloo, it's structured differently altogether, but they have no separate resource for tls/ssl. It's defined in the VirtualService itself, so strongly coupled to the routes. Route delegation (in newer gloo) helps with this a lot!

I believe the gloo GitHub has an open issue for making ssl config its own CR, which should help.

One other thing is Ambassador (starting in 1.0) allows Mappings to be created that refer to Kubernetes Services by name, using the Namespace the Mapping is created in to find that Service.

This is incredibly helpful when you have the same services but in different Namespaces (like with multi-tenant clusters), because the same set of Mapping YAML can be applied in each Namespace without having to first generate them from templates. It depends on how you deploy.

If you're not planning to have a huge cluster with lots of dynamically added routes, and don't already have complex deploy logic, I say it's fine to keep using Ambassador. Although due to the complexity of switching ingress controllers, standardizing on one is worth it IMO.

About the Edge stack, I did try to use it, but I was unable to successfully get it to deploy in a fresh cluster. This was literally the week of them launching it, so stuff was chaotic. I also had modifications to the codebase that were required for me to use it effectively, and Edge stack is a special container that has things baked into it, so I couldn't simply change the Deployment YAML to use my container image based on the OSS version :(

BTW, I highly recommend reaching out to the solo.io folks cuz they can help unravel the docs very quickly and get you pointed to where you need to go! Digging in is worth it too!

My tip: look at the .proto files on the docs site. They map (I think) 1:1 with the CRs, and explains what each field is for

This wasn't a strict controlled test with perfect setup. It was a personal account of a busy developer who works at a start-up trying to kick the tires on two technologies in a realistic way in order to decide which to move forward with as we faced scaling challenges.

I hope HN appreciates the scrappiness more than they dog on the sloppiness :)

scrappy or not, it's still very informative. thanks for sharing

Reply on news.ycombinator.com