emissary VS Ory Oathkeeper

We will install Ambassador Gateway which is an open-source Kubernetes-native API gateway for microservices. We will use it as a reverse proxy to manage external access to services within our Kubernetes cluster.

Command and Query services APIs can be managed via lightweight, independently deployable, and scalable API gateways that can run anywhere that allow developers to manage API endpoints. They can handle extremely large volumes, as they run on highly scalable platforms, for example, Apache APISIX, Kong, Tyk, and Ambassador to name a few.

Ambassador

Did you know that it takes 23 minutes to get into a flow state? For some people it takes even longer. That means that for every question, disruption, email, and interruption that you or your coworkers are subjected to, it could be half an hour of productivity down the drain. We talked to Katie Wilde, VP of Engineering at Ambassador Labs, about how she manages workflow

Let's dive deep and start understanding more bit about Emissary Ingress.

Emissary is pretty much the gold standard for people with complicated setups: https://github.com/emissary-ingress/emissary

Katie Wilde, VP of Engineering at Ambassador Labs, knows your pain and she’s on a crusade to help devs everywhere reclaim their focus.

Ambassador API Gateway is an Envoy-based ingress controller.

I am starting to doubt their marketing materials about broad adoption, because we cannot get it to work even with basic setup. Apart from terrible DX (e.g. you can provide whatever arbitrary configs, there is no validation), we keep hitting bug after bug after bug. They are not small bugs either, e.g. broken redirects. Any time I try asking questions in their Slack, their sales rep will message asking to "connect via zoom meeting to cover the pricing".

Peter: Yeah. So that was my first time having a DevRel title. I was a developer Advocate for Ambassador Labs, another startup. And so I think they were Series B at the time. They were centered around the developer experience. So I had a lot of fun diving into the DevRel industry with them. And so my manager that I was working for has a long history of DevRel. And so I got to learn a lot of tips and tricks from him.

Hydra feels mature. I think it's their longest-developed product so far. Besides breaking changes during big upgrades(v0 -> v1beta -> v1), everything has been painless:

- It runs anywhere with or without containers

- API makes sense, good SDKs are available in all my used languages

- RAM usage is surprisingly low compared to usage and has been great for resource-constrained environments

- Stateless means horizontal scaling is as easy as `replicas++`

- Sub-millisecond response times for some calls, much faster than our previous setup

With Hydra, I know it's the client's fault when OAuth calls fail and not just a buggy server implementation. This is reinforced in dev mode with great errors like:

- The authorization code has already been used

- The request is missing the response_type parameter

- Parameter "nonce" must be set when using the implicit flow

- Redirect URL "https://example.com/callback" does not match

On the flipside, Oathkeeper is not a mature product and has not yet reached v1. There are breaking changes planned [1]. It lacks support for at least one popular usecase (mine) out of the box [2]. Rules can be hard to create and debug. I wouldn't recommend Oathkeeper in its current state unless you're ready to dive in and fix things yourself. Once configured it sticks with the Ory trend: fast, lean, and stable.

Depending on your usecase, Oathkeeper could be swapped out with any IAP like Pomerium or just with your reverse proxy's auth request support + some small custom shim.

I haven't tried Keto (access control) or Kratos (user management) yet. Kratos is on my todo list.

[1] https://github.com/ory/oathkeeper/issues/441