[galenmarchetti]

founder/developer on Kardinal here - that's a good question

in reality what you're doing with namespace-based deploys or telepresence is equally "lightweight" to what you're doing with Kardinal. it's just that (at least in our phrasing), those don't quite constitute a separate "environment" as state is shared between any developers working at the same time

Kardinal matches those approaches in terms of light-weightedness, but offers state isolation guarantees too (like isolation for your dbs, queues, caches, managed services, etc). so in comparison to "ephemeral environment" approaches that give state isolation, we do believe we're doing this in the most lightweight way possible by implementing that isolation at the layer of the network request rather than by duplicating deployed resources

and thanks for the +1 on the name haha, we called it Kardinal because the goal is to deploy only "unique elements of your ephemeral environments" across the organization, i.e. number of services deployed equals the "cardinality" of service versions

[from-nibly]

I don't think thats what they meant by namespaced deploys. I think they meant an entire copy of the environemnt contained in separate namespaces.

How do you handle requests going from service A to B and then to database C vs A2 -> B -> C2?. How does service B know to route to a different database based on the version of A thats different?

[galenmarchetti]

service B doesn't actually know that - it happens at the level of the service mesh (you have to have a service mesh installed, right now just supporting istio but we plan on making that configurable)

we use trace headers to keep track of where the request originally came from to route it to the right database. it's transparent to service B as long as service B is properly propagating the request context from incoming request to outgoing requests

[from-nibly]

Is that at the TCP level or the http level?