
Personal Account of Stress Testing API Gateways Built on Envoy Proxy - texascloud
https://dev.to/texascloud/stress-testing-api-gateways-built-on-envoy-proxy-18dk
======
pinkparsnips
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.

~~~
texascloud
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 :(

~~~
texascloud
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

------
texascloud
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 :)

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

