Live data from Hacker News

Stripe's Monorepo Developer Environment

blog.nelhage.com

151–160 of 249 posts

Re: Stripe's Monorepo Developer Environment

#151

Earlier quoted context omitted.

We have 100 Go services (with redpanda) and a few databases in docker-compose on dev laptops. It works well when and we buy the biggest memory MacBooks available. https://moov.io/blog/education/moovs-approach-to-setup-and-t...

Your success with this strategy correlates more strongly with ‘Go’ than ‘100 services’ so it’s more anecdotal than generally-acceptable that you can run 100 services locally without issues. Of course you can. Buying the biggest MacBook available as a baseline criteria for being able to run a stack locally with Docker Compose does not exactly inspire confidence. At my last company we switched our dev environment from…

Buying the biggest Mac’s also lets developers run an electron app or three (Slack, IDE, Spotify, browser, etc) while running the docker-compose stack.

Re: Stripe's Monorepo Developer Environment

#152
post #25

"This scale – the scale of devprod, and in turn the scale of the overall organization, such that it could afford 10 FTEs on tooling – was a major factor in our choices" Is basically the summary for most mono/multi repo discussions, and a bunch of other related ones.

Multirepo also comes with cost overhead. I think people talk about it somewhat less. I’ve worked at multirepo and monorepo places, both, before. My current company has a multirepo setup and it sure seems like it comes with plenty of tooling to fetch dependencies. That tooling has to be supported by FTEs.

Internally, they definitely do. I worked at Stripe's monorepo many years ago, and I am working at a larger company with massive amounts of repos. The difference in pain has little to do with mono v multi, but with the capabilities of your tooling team.

If there's anything I'd say to low-level execs, the kind that end up with a few hundred developers under them, it's that mis-sizing the tooling team, in one way or the other, comes with total productivity penalties that will appear invisible, but will make everything expensive. Understanding how much of a developer's day is toil is very important, but few really try to figure that out.

Re: Stripe's Monorepo Developer Environment

#153
post #147
post #127

Earlier quoted context omitted.

So the devs don’t have the ability to ssh to your cloud instances and change config? Other than the size issue, I’m still not seeing the difference. Take your point on it needing to start before you have control, but other than that a VM on a dev machine is functionally the same as one in a cloud environment. In terms of needing to reset, it’s just a matter of git branch, push, reset, merge. In your world that sync c…

> So the devs don’t have the ability to ssh to your cloud instances and change config? They do, but I can see those changes if I'm helping debug, and more importantly, we can set up the most important parts of the dev processes as services that we can update. We can't ssh into a VM on your laptop to do that. For example, if you start a service on a stripe machine, you're sending an RPC to a dev-runner program that al…

Ah! So that’s a spot where we’re talking past each other.

I’d anticipate you would be equally as able to ssh to VMs on dev laptops. That’s definitely a prerequisite for making this work in the same way as you’re currently doing.

The only difference between what you do and what I’m suggesting is the location of the VM. That itself creates some tradeoffs but I would expect absolutely everything inside the machine to be the same.

Re: Stripe's Monorepo Developer Environment

#154
post #124

Earlier quoted context omitted.

Right, dev boxes do not need to do double duty as a personal computer plus development target, which allows them to more closely resemble the machine your code will actually run on. They also can be replaced easily, which can be helpful if you ever suspect something is wrong with the box itself - if the new one acts the same way, it wasn't the dev box. I don't recall latency being a big problem in practice. In an org…

I feel like we're not getting the right lessons from this. It feels like we're focusing on HOW we can do something versus pausing for a brief moment to consider if we SHOULD in the first place. To me the root issue is the complexity of production environments has expanded to the point of impacting complexity in developer environments just to deploy or test - this is in conjunction with expanding complexity of develop…

I think we don't have good solutions for scaling down prod.

Our relatively simple prod architecture has 5 containers & a hosted database (so 6 containers when run locally), and any less would impact our product goals.

I still find running prod locally valuable, and is the most common way anyone does development here, but containers are fairly heavyweight when you want to run everything on one machine. It's also impossible if you have parts that need special accelerators to get good latency, etc.

If you're willing to build everything from scratch, you can have a framework that seamlessly lets you build conceptual services and then separate the physical deployment concerns, like Google has and sometimes even uses. But for the rest of us where we're clobbering together a bunch of different technologies, that's a luxury we can't really afford.

Re: Stripe's Monorepo Developer Environment

#156

Earlier quoted context omitted.

We have 100 Go services (with redpanda) and a few databases in docker-compose on dev laptops. It works well when and we buy the biggest memory MacBooks available. https://moov.io/blog/education/moovs-approach-to-setup-and-t...

Your success with this strategy correlates more strongly with ‘Go’ than ‘100 services’ so it’s more anecdotal than generally-acceptable that you can run 100 services locally without issues. Of course you can. Buying the biggest MacBook available as a baseline criteria for being able to run a stack locally with Docker Compose does not exactly inspire confidence. At my last company we switched our dev environment from…

That's a huge win -- has your team written about or spoke on this anywhere?

Re: Stripe's Monorepo Developer Environment

#158

Earlier quoted context omitted.

Your success with this strategy correlates more strongly with ‘Go’ than ‘100 services’ so it’s more anecdotal than generally-acceptable that you can run 100 services locally without issues. Of course you can. Buying the biggest MacBook available as a baseline criteria for being able to run a stack locally with Docker Compose does not exactly inspire confidence. At my last company we switched our dev environment from…

Buying the biggest Mac’s also lets developers run an electron app or three (Slack, IDE, Spotify, browser, etc) while running the docker-compose stack.

You're right. My coworkers remarked that they could run Slack and do screensharing while running the apps locally when we removed docker-compose.

Re: Stripe's Monorepo Developer Environment

#159

Earlier quoted context omitted.

Your success with this strategy correlates more strongly with ‘Go’ than ‘100 services’ so it’s more anecdotal than generally-acceptable that you can run 100 services locally without issues. Of course you can. Buying the biggest MacBook available as a baseline criteria for being able to run a stack locally with Docker Compose does not exactly inspire confidence. At my last company we switched our dev environment from…

That's a huge win -- has your team written about or spoke on this anywhere?

No but I'd be happy to (I maintained the docker-compose stack, our CLI, and did the transition to Nix).

Re: Stripe's Monorepo Developer Environment

#160

I wonder if there’s a devbox-as-a-service tool out there. I use a MacBook Air for most of my work and on occasion would be benefited by using a beefier machine in the cloud. I just don’t want to set up a machine, set up sync etc.

You could just rent a beefy server for like $40/month at hetzner or OVH and use VS Code with the remote development extension.
Post reply on HN