ceposta07

lol i’m not quite following how manually injecting envoy, “configuring envoy yourself/by hand” in a pod and “copying istio code for iptables re-direction” and then trying to maintain this yourself is easier than just using istio?

install istio, turn off mtls if you dont want that (https://istio.io/latest/docs/reference/config/security/peer_...) and you have what you’re looking for. doesn’t get simpler than that.

I think it does come down to risk and risk mitigation. As someone who works for an “Istio vendor” we see some of the largest deployments of Istio in the world for mission critical/tier-0 workloads… and all the steps it took to get there including evaluation/POC of other vendors/mesh technologies.

Part of these decisions are based on things like “What is the rest of the industry doing?” “How vibrant/diverse is the community?” “How mature is the project _for enterprise adoption_?” “What vendors are available for enterprise support?” “Is it already available in my platform of choice?” etc.etc.

The sting of “picking the wrong container orchestrator” is still fresh in a lot of organizations.

We see Istio make it through these questions with good answers for a lot of organizations where other/alternative service mesh vendors strike out pretty quickly.

This is even before we get to the “feature comparisons” for usecases these large organizations focus on/have.

Yes definitely. Similar to what we already do for KNative

https://docs.solo.io/gloo/latest/guides/integrations/knative...

RE AWS API Gateway... Gloo is more full featured and self hosted. Even wrt performance, in fact, we've seen anecdotal evidence of Gloo performing better than AWS API Gateway for things like calling Lambdas.

Disclaimer: I am an employee of Solo.io

I'd say a lot of our users are from big enterprises, especially financial services where security is paramount. Gloo has a decoupled control plane so it can be scaled and secured independently from the proxy/data plane. For example, Gloo requires zero privilege capabilities/service accounts, has a read-only file system, and the data plane has no access to the Kubernetes API when run in Kubernetes (not a requirement -- gloo can be run outside k8s as well). Additional security related functionality like WAF, OPA authz, and data loss prevention filters are crucial for our users.

see more here: https://docs.solo.io/gloo/latest/introduction/others/

HTH

Kong is mostly built on OpenResty/Lua

I'd say the main reason to use Gloo is it's much simpler, it's based on Envoy which is where most of the innovation around L7 proxies is happening these days (ie, see WebAssembly), and was built from the ground up with a cloud-native and kube-native architecture.

More can be found here:

https://docs.solo.io/gloo/latest/introduction/others/

And I can go into much more detail on slack. I'm `ceposta` on the solo/istio/cncf/envoy/kubernetes slack

Contour is not an API Gateway.

Disclaimer: I work for Solo.io

An API Gateway can do sophisticated edge security challenges (OIDC, Authz based on OPA, web app firewalling/WAF, etc) as well as things like message transformation, swagger/grpc detection, exposing APIs for self-service signup through a portal, etc. Gloo does all these things.

I've written in depth about this as well, specifically in terms of things like contour, Istio ingress gateway, consul's service mesh gateway, etc, etc

https://blog.christianposta.com/microservices/do-i-need-an-a...

Gloo resources: https://docs.solo.io/gloo/latest/guides/dev_portal/ https://docs.solo.io/gloo/latest/guides/security/waf/ https://docs.solo.io/gloo/latest/guides/security/auth/oauth/... https://docs.solo.io/gloo/latest/guides/security/opa/ https://docs.solo.io/gloo/latest/installation/advanced_confi... https://docs.solo.io/gloo/latest/guides/traffic_management/r...

Um. Yes.