[wjossey]

As someone who has built out a similar internal tool, one of the things I'm excited to see someone do is the route propagation technique. It's something I've evaluated adding to our internal solution as we rolled out a service mesh, but ultimately we manage routing in a different way under the hood.

Either way, this notion of slices of environments being deployed for testing, with "baseline" or fallback environments being used otherwise, is the future of software development. It's a real boon for developers when rolled out effectively, and I've seen it scale massively at GoodRx.

Congrats to the team. Wish you all tons of success!

[anirudhrx]

Thank you! We're really excited about covering the entire dev lifecycle using this approach. Re: routing, do you make use of a library that is directly included in each service? We've seen an approach in the wild where such logic is embedded into gRPC interceptors and HTTP middleware. Curious to hear how you thought about the choice between that and using the mesh.

[wjossey]

Right now, we just require intermediate services to be spun up if you need to connect with a custom downstream service.

So, as an example, if I have three services where A talks to B, B talks to C, and I have a custom version of A & C that require testing E2E, we have to spin up B in the middle.

It definitely is a point of confusion for engineers who have to understand what intermediate services are in play when working on a frontend and some distant backend microservice. Fortunately, that intermediate layer tends to just always be the same two services, so folks learn pretty quickly. At scale, especially hyper-scale in a microservices architecture, this becomes untenable, and either automatic dependency discovery OR routing (like you designed) is the path forward.

Needless to say, it's a "niche" issue I think folks don't run into for a while in their setups; however, once you run into it, it's a PIA for those involved.