I wish they had said more about the technical architecture because I am not understanding what it is about their architecture that requires that much power for a dev instance. For production, sure, absolutely, gotta have resources to scale. But for dev? Is there truly no scaled-down config that can run on a local system? Nor a way to load only a slice of the product, not the full architecture?
Even back 8-10 years ago when having gobs of microservices each in their own container was the rage, every place I worked had various ways to run specific services locally, while leaving the rest in the cloud. Or is that exactly what they have now done?
Either way, the lack of technical info makes it difficult to tell how interesting this really is.
"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
I wish they had said more about the technical architecture because I am not understanding what it is about their architecture that requires that much power for a dev instance. For production, sure, absolutely, gotta have resources to scale. But for dev? Is there truly no scaled-down config that can run on a local system? Nor a way to load only a slice of the product, not the full architecture?
Even back 8-10 years ago when having gobs of microservices each in their own container was the rage, every place I worked had various ways to run specific services locally, while leaving the rest in the cloud. Or is that exactly what they have now done?
Either way, the lack of technical info makes it difficult to tell how interesting this really is.
(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.