Not only do more bugs reproduce in staging than locally (for obvious reasons), but mirrord also saves you the trouble of figuring out how to run your stuff locally in the first place. Previously, before you could add a single line of code to your microservice, you had to be able to run it and all of its dependencies on your local machine. This is such a huge challenge in some cases that people actually prefer to git push and deploy to the cloud for every little change. With mirrord you can just clone the repo and debug.

Ideally! And it can be run on a Linux machine if the user prefers. But if you code on a Mac, mirrord still lets you go through a good number of test iterations (by letting your process run with network input/output, file content and environment variables from the cloud) before having to deploy your code to a Linux machine for that (hopefully) final round of testing.

It's initially the parent who'll pick the book though (or the critic? the people who decide what to put in the front window of the bookstore? probably not the four year old though), so the uncanniness could come into play.

This is detailed in the post, but the security feature i.e. preventing injected libraries access to entitlements isn't actually bypassed here. Rather the binary is run without these entitlements (which aren't required anyway for mirrord's use case).

Maybe, we haven't looked into that option for the following reasons:

a. It would require that we maintain a potentially pretty big list of self-compiled binaries

b. It would be an alteration of what the user's running, which we try to keep to a minimum, as mirrord's commonly used as a testing tool

The part of mirrord that's affected by SIP is the client. This is meant to be run by users on their development machines (we could ask them to disable SIP, but would rather not for obvious reasons).

It does work with any k8s cluster, no operator needed. It indeed relies on kubectl's config to talk to the k8s API. All that's needed is permissions to run privileged pods (or if you've configured mirrord to use ephemeral containers, not even that).

We're currently working on a more enterprise-oriented version where you would have a persistent operator in the cluster, and it would let you properly manage RBAC, rather than relying on each user's kubectl.

Thanks for pointing all of this out! We'll try to make this info more easily accessible.

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/

How can you process production requests without the matching data? Processing a user with UUID X taking action Y depends on those things existing in the DB.

I can't tell if this is brilliant or insane. Brilliant in that I see the potential of catching bugs. Insane in that you'd need to be really really really sure that the environment the requests are diverted to can't change production data. Including sending out e-mails or other communciations.

So right now we focus on helping devs develop using their staging environments, but we do plan to get to production later on. As Eyal described here (https://news.ycombinator.com/item?id=31634831) next features would be enabling network access, env var access and file system to the remote cluster as the impersonated pod. After enabling "primitive" access we would also provide "protection" features as of what you can really send/use/change.

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.

Our agent sniffs traffic in the same network namespace as the pod whose incoming traffic we mirror, so in most cases that would be after the HTTPS traffic is decrypted (by e.g. a load balancer, or a service mesh)