eyalbukchin

(CTO of mirrord here.)

"Running specific services locally while leaving the rest in the cloud" is exactly it, but it's not as simple as you make it sound. At monday's scale you have large DB state and too many microservices to run any meaningful subset locally, and replicating the environment per-dev in the cloud is what the post describes them moving away from (long setup, high cloud cost).

That leaves running local services against a shared cloud environment, which at this scale needs:

- Features like traffic filtering, DB branching, queue splitting, so many devs can share the same environment without stepping on each other

- RBAC and policies

- Fast, low-friction UX

Which is what mirrord provides.

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/

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)

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 :)

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.