Live data from Hacker News

Stripe's Monorepo Developer Environment

blog.nelhage.com

171–180 of 249 posts

Re: Stripe's Monorepo Developer Environment

#171
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.

+1. I'd go as far to say that multi-repo probably needs as much, if not more effort to properly keep functioning, but all that effort is better "hidden" so people assume monorepos are more work.

With a monorepo, it's common to have a team focused on tooling and maintaining the monorepo. The structure of the codebase lends itself to that

With a multirepo codebase, it's usually up tu different teams to do the work associated with "multirepo issues"— orchestrate releases, handle dependencies, dev environment setup, etc. So all that effort just kinda gets "tucked away" as overhead that each team assumes, and isn't quite as visible

Re: Stripe's Monorepo Developer Environment

#172

Earlier quoted context omitted.

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

I’d like to learn more about switching compose to nix. We will hit a wall with compose at some point.

Re: Stripe's Monorepo Developer Environment

#173
post #93

It's always so enlightening to have articles like this one shed light on how companies at scale operate. It goes without saying that many of the problems Stripe faced with their monorepo isn't application to smaller businesses, but there are still bits and pieces that are applicable to many of us. I've been working on an ephemeral/preview environment operator for Kubernetes( https://github.com/pier-oliviert/sequencer…

My main gripe with the dev box approach is that a cloud instance with similar compute resources as a developers MacBook is hella expensive. Even ignoring compute, a 1TB ebs volume with equivalent performance to a MacBook will probably cost more than the MacBook every month.

The article didn't actually say what "Stripe's cloud environment" was, besides "outside of the production environment". I assumed the company had their own hardware but your assumption is more probable.

Re: Stripe's Monorepo Developer Environment

#174
post #141

Earlier quoted context omitted.

I've been on this path and as soon as you work on a couple of concurrent branches you end up having 20 containers in your machine and setting these up to run successfully ends up being its own special PITA.

What exactly are the problems created by having a larger number of containers? Since you’re mentioning branches, these presumably don’t have to all run concurrently, i.e, you’re not talking about resource limitations.

Large features can require changing protocols or altering schemas in multiple services. Different workflows can require different services, etc. Keep track of different service versions in a couple branchs (not unusual IMO) and it just becomes messy.

Re: Stripe's Monorepo Developer Environment

#175
post #141

Earlier quoted context omitted.

What exactly are the problems created by having a larger number of containers? Since you’re mentioning branches, these presumably don’t have to all run concurrently, i.e, you’re not talking about resource limitations.

Large features can require changing protocols or altering schemas in multiple services. Different workflows can require different services, etc. Keep track of different service versions in a couple branchs (not unusual IMO) and it just becomes messy.

What does this have to do with running locally vs. on a dev server? You have to properly manage versions in any case.

Re: Stripe's Monorepo Developer Environment

#176
post #81
post #59

Maybe a silly question, but why all this engineering effort when you could host the dev environment locally? By running a Linux VM on your local machine you get a consistent environment that you can ssh to, remove the latency issues but you remove all the complexity of syncing that they’ve created. That’s a setup that’s worked well for me for 15 years but maybe I’m missing some other benefit?

I work on this at Stripe. There's a lot of reasons: * Local dev has laptop-based state that is hard to keep in sync for everyone. Broken laptops are _really hard_ to debug as opposed to cloud servers I can deploy dev management software to. I can safely say the oldest version of software that's in my cloud; the laptops skew across literally years of versions of dev tools despite a talented corpeng team managing them.…

The way these problems are stated mighy make it seem like they're unsolvable without a lot of effort. I just want to point out that I've worked at places that do use a local, supported environment, and it works well.

Not saying it's the wrong choice for you, but it's a choice, not a natural conclusion.

Re: Stripe's Monorepo Developer Environment

#177

Earlier quoted context omitted.

Most local laptops are much stronger than is needed to run the entire stack of your average startup with no resource issues. And the dev environment stops running when you close the laptop, but you also don't need it since you're not developing. Not saying it can work for absolutely all cases but it's definitely good enough for a lot of cases.

... this is an article about Stripe, not your average startup

And yet the discussion can go beyond that.

Re: Stripe's Monorepo Developer Environment

#178
post #115
post #95

Earlier quoted context omitted.

In my opinion the single most important feature of any development environment is a reliable “reset” button. The amount of time companies lose to broken development environments is incredible. A developer can easily lose half a day (or more) of productive time. With cloud environments it’s much easier to offer a “just give me a brand new environment that works” button somewhere. That’s incredibly valuable.

For sure, but , a VM has that feature too. They have to run some services directly on the laptop to handle the code syncing. So if you accept a certain amount of “need to do some dev machine setup” as a cost, installing Parallels and running a script to download an iso is a pretty small surface area that allows for a full reset. I don’t doubt that Stripe have a setup that works well for them them but I also bet they…

To be fair, it seems like the cloud development environment choice was driven by the scale of Stripe's organization.

Re: Stripe's Monorepo Developer Environment

#179

Earlier quoted context omitted.

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

I'm curious about the # of svc's / stack / company / team size -- if you have your own blog -- would love to read it when you publish

could be a cool lightning talk (or part of something longer)

maybe it's a good piece for https://nixinthewild.com/ ?

I'm @capileigh on twitter and hachyderm.io if you wanna reach out separately -- here is good tho too

Re: Stripe's Monorepo Developer Environment

#180

I think for smaller companies, you can get a long way towards a lot of this with judicious use of docker-compose, and convenience scripts in a Makefile. As long as you don't do anything stupid like try and spin up 100 services when you're a team of 8, most laptops these days are sufficiently capable of handling a database, Redis, your codebase, and something like LocalStack.

I would say you can even go a looong way without any Docker at all. And for the large majority of the companies/projects, if your project is so complex and heavy of resources that it doesn't fit on a modern laptop, the problem is not in the laptop, it's in the whole project and the culture and cargo-cult around "modern" software development.

- "A single-binary app behind a load-balancer might scale to far beyond our needs, but the promotion/resume trade-off can't be justified."
Post reply on HN