Mirrord – mirror production traffic to your development environment

Up to you: you’re going to be able to configure what works locally vs what works with the cloud environment. So for example, you could configure all read functionality (incoming traffic, DB reads) to work with the cloud, and all write functionality to work locally. Further down the line, we’re planning to support Copy On Write for databases - so you’d read from the cloud, write locally, then read the records you wrote locally (and records you haven’t written, from the cloud). Disclaimer: we’re still pretty early in the roadmap, so currently only support mirroring incoming traffic. But we’re moving fast :)

I would generally use this for e2e testing since it's too expensive to run a 100% mirror of a large production environment. Well, depends on your scale and whether your production costs are a significant factor in your total expenses - I guess if your production costs are tiny compared to revenue/dev time spent debugging, you could justify a full mirror. For something like an eshop where revenue >> production costs you could probably justify cloning out production multiple times.

Sampling is another useful tool but I don't see any sampling in the API for this. If you do sample though you could end up with inconsistent or divergent state if you just sampled a flat % of traffic, so in some contexts it makes sense for sampling to be determined per-user/tenant/etc. rather than per-request.

This is pod based so you could easily slice by pod. If you have a pod with a lot less traffic, more impactful traffic, or that is harder to debug (example: pod that periodically aggregates and exports metrics but you believe it's dropping data sometimes) you could just enroll that and have some kind of dev shard of a portion of the stack.

I could also see this being very useful if you believe it to be too big a liability to record actual user requests (or implement something special to scrub out sensitive stuff) or let devs peek too close. You have a way of investigating some classes of issues without necessarily looking at sensitive data or requiring extensive back and forth in a support case.

Don't forget that you need to disable CSRF checks, because the randomly generated tokens from prod vs dev would be different.

The full use case we want to have is developer using staging as their development environment, sharing it with others. The developers would launch their locally developed services using mirrord, getting traffic from the staging environment and also having access to the same resources as the pod in the staging environment (env vars, file system, outgoing traffic) while being able to control each service with settings (use remote/local for each)

So there are a bunch of use cases, but the main one we think is during day to day development. mirrord can give you access to “cloud conditions” while you code, without having to go through CI and actually deploying, which a. makes your feedback loops a lot tighter and b. reduces the likelihood you’ll deploy something broken to the cloud (i.e. staging/production) environment and break it for other developers in the organization. We wrote about it a bit more here if you’re interested: https://metalbear.co/blog/reintroducing-mirrord/

First of all, mirrord runs on the process level. Telepresence either runs on your local machine, changing its network behavior or in a container making development less smooth than running a local process. Second, mirrord's default is to duplicate traffic and not intercept it, so useful when you don't want to disrupt the cloud environment, want to work concurrently with other developers on the same service, etc.

AFAIK Istio mirroring is an infrastructure tooling for devops to mirror traffic between pods in k8s whilst mirrord mirrors traffic to your local ran service without deploying it or building it as a container. The first helps devops achieve traffic mirroring while mirrord helps backend engineers work on their apps faster and better

It's literally in the first sentence of the README:

> mirrord lets you easily mirror traffic from your Kubernetes cluster to your development environment.

That said, cool application, although I can see a lot of compliance and/or data protection problems when production data is leaving the (hopefully protected) production environment.

Hey, one of the creators or mirrord here. The technology behind mirrord is actually agnostic - what it does is wrap a local process and "proxy" it's API calls to a remote environment and remote traffic is also mirrored from there. We tailored the solution for K8S to provide seamless experience, but if there's a need for another orchestration solution, we can consider adding support :)

Yes! This is actually in development at the moment so should be out really soon. Along that same line, we're also planning to support routing of outgoing traffic back to the cloud environment. We're obviously thinking of both those features as more suitable for use with a staging environment rather than production.

Right now the focus of mirrord is for back end engineers, so the use case is backend engineers wanting to work on real traffic and real environment being able to do so without help of or change of infrastructure

The new Kubernetes gateway specification also supports mirroring out of the box.

Somewhat similar. mirrord works live only (currently) but doesn't just replay the traffic, it wraps your process and duplicates connection to your local service as if it's running in the remote environment. We'll soon add filesystem access, environment variables and outgoing traffic enabling developers to work seamless on a remote environment.

It should work as this is for k8s and OpenShift is based on k8s.

Yeah, this feels like a data breach waiting to happen. Every security questionnaire I’ve ever filled out wants to know prod, staging, and dev are entirely separate.

Does mirrord not allow to connect via an encrypted protocol such as HTTPS?