Interesting article. It was initially confusing to me because I wasn't able to find what's unique about this approach, and how it's different from the typical Ambassador pattern that I'm more familiar with. That is, what does the word "Routing" even mean in this context?

I think the answer is that he's doing essentially layer-7 routing, using the HTTP path (and verb?) to decide what backends to route to, rather than doing it on a per-port basis (which is necessary to support non-HTTP services.)

Implementations I've run into before seem to fall into a few categories:

- A service declares that it needs to talk to, say, 3 other services. Each of these upstream services is assigned a unique client-side port, and an ambassador proxy is launched alongside each instance, which exposes those 3 ports, routing each to the corresponding 3 backend services. To keep the ports out of the source code, typically environment variables are automatically assigned, so you just talk to ie. "my-ambassador:${UPSTREAM_PORT_NAME}"

- A service is responsible for using a service discovery layer like zookeeper or etcd to find backends on its own. This is important for things that use raft/paxos/gossip, where blind routing isn't enough, you actually need to keep track of peer instances (although in that case, the service discovery layer is only used for initial discovery).

- Service discovery is done with just plain DNS on well-known ports (or even SRV records if you're lucky enough to have client software that can tolerate them), and you just hope the right thing happens. This can be accomplished with things like SkyDNS on top of etcd... a surprising amount of flexibility can be accomplished by putting logical things right in a hostname.

This approach seems to be like a more opinionated version of the first approach, but instead of ports, it uses HTTP routes, which is definitely more flexible, but only works with HTTP. The routes can contain enough information to route more intelligently than just enumerating your dependency services ahead of time and getting static port assignments.

It's almost like an API gateway distributed as an ambassador to each service. At least, it looks a lot like an API gateway, in that it presents the whole mesh of services underneath in a single URI namespace, using HTTP to route requests accordingly and handling things like TLS and potentially authentication. It's definitely an interesting approach, and something I'm curious to try.