Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stripe's Monorepo Developer Environment

blog.nelhage.com

Post reply on HN
Print view View original

91–100 of 249 posts

Re: Stripe's Monorepo Developer Environment

#91

Post by bastawhiz »

aidos wrote: post #64
bastawhiz wrote: post #42

Earlier quoted context omitted.

I was at Stripe until 2022 and inconsistency with the language server was never an issue

Due to the work that this team put in though, right? The choice to run dev environment far away from the files puts you in the position of needing to engineer your way past the inconsistency.

Yes, almost certainly.

On the other hand, there was so much code that running everything on your own laptop was essentially out of the question. Doing a git pull after a long vacation locked up your dev box for a hot minute while it checked all the types—doing the same thing on your MacBook would be painful at best.

Re: Stripe's Monorepo Developer Environment

#93

Post by p-o »

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) and as I could agree to a lot of things OP said.

I think dev boxes is really the way to go, specially with all the components that makes an application nowadays. But the latency/synchronization issue is a hard topic and it's full of tradeoff.

A developer's laptop always ends up being a bespoke environment (yes, Nix/Docker can help with that), and so, there's always a confidence boost when you get your changes up on a standalone environment. It gives you the proof that "hey things are working like I expected them to".

Re: Stripe's Monorepo Developer Environment

#94

Post by crabbone »

aidos wrote: 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?

Working in a configuration where your development environment isn't on your computer is always a huge downgrade. Work with VM? -- sooner or later you'll have problems with forwarding your keyboard input to the VM. Work with containers? -- no good way to save state, no good way to guarantee all containers are in sync etc. God forbid any sort of Web browser-based solution. The number of times I accidentally closed the tab or did something else unintentionally because of key mapping that's impossible to modify...

However, in some situations you must endure the pain of doing this. For example, regulatory reasons. Some organizations will not allow you to access their data anywhere but on some cloud VM they give you very botched and very limited control over. While, technically, these are usually easy to side-step, you are legally required to not move the data outside of the boundaries defined for you by the IT. And so you are stuck in this miserable situation, trying to engineer some semblance of a decent utility set in a hostile environment.

Another example is when the infrastructure of your project is too vast to be meaningfully reduced to your laptop, and a lot of your work is exploratory in nature. I.e. instead of typical write-compile-upload-test you are mostly modifying stuff on the system you are working on to see how it responds. This is kind of how my day-to-day goes: someone reported they fail to install or use one of the utilities we provide in a particular AWS region with some specific network settings etc. They'd give me a tunnel to the affected cluster, and I'd have some hours to spend there investigating the problem and looking for possible immediate and long-term solutions. So, you are essentially working in a tech-support role, but you also have to write code, debug it, sometimes compile it etc.

Re: Stripe's Monorepo Developer Environment

#95

Post by simonw »

aidos wrote: 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?

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.

Re: Stripe's Monorepo Developer Environment

#97

Post by chpatrick »

eadmund wrote: post #67
stavros wrote: post #9

Earlier quoted context omitted.

Nix is the right tool for this, developing a tool to make Nix's UX easier is a great idea. Thanks for this!

> Nix is the right tool for this Or Guix, which has the advantage of a more pleasant language.

YMMV, I really don't like lisp braces personally.

Re: Stripe's Monorepo Developer Environment

#98

Post by crabbone »

n0us wrote: post #69
aidos wrote: 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?

You're limited by the resources available to you on your local laptop and when you close that laptop the dev environment stops running. Remote dev environments are more costly and complicated to maintain but they can be shared, can scale vertically (or horizontally) on demand, can persist when you exit them, and managing access to various internal services from dev environments can in some cases be simpler. It also c…

Not even once did I want to share my dev. environment, nor did anyone want to share mine. We are talking about 25-odd years of being a developer.

Never in my life did I want to scale my dev. environment vertically or horizontally or in any other direction. Unless you work on a calculator, I don't know why would you need that.

I have no problems with my environment stopping when I close my laptop. Why is this a problem for anyone?

For overwhelming majority of programming projects out there they fit on a programmer's laptop just fine. The rare exceptions are the projects which require very specialized equipment not available to the developers. In any case, a simulator would be usually a preferable way to dealing with this, and the actual equipment would be only accessed for testing, not for development. Definitely not as a routine development process.

Never in my life did I want development process to be centralized. All developers have different habits, tastes and preferences. Last thing I want is to have centralized management of all environments which would create unwanted uniformity. I've been only once in a company that tried to institute a centrally-managed development environment in the way you describe, and I just couldn't cope with it. I quit after few month of misery. The most upsetting aspect about these efforts is stupidity. These efforts solve no problems, but add a lot of pain that is felt continuously, all the time you have to do anything work-related.

Re: Stripe's Monorepo Developer Environment

#99

Post by sulam »

aidos wrote: post #68
JasonSage wrote: post #63

Earlier quoted context omitted.

This does not scale to a large number of services with a certain amount of RAM/processing per service.

You could still run the proxy they have that lazy boots services - that’s a nice optimisation. I don’t think that many places are in a position where the machines would struggle. They didn’t mention that in the article as a concern - just that they struggled to keep environments consistent (brew install implies some are running on osx etc).

I think it’s safe to assume that for something with the scale and complexity of Stripe, it would be a tall order to run all the necessary services on your laptop, even stubs of them. They may not even do that on the dev boxes, I’d be a little surprised if they didn’t actually use prod services in some cases, or a canary at any rate, to avoid the hassles of having to maintain on-call for what is essentially a test environment.

Re: Stripe's Monorepo Developer Environment

#100

Post by recroad »

JasonSage wrote: post #63
yeswecatan wrote: post #60

Earlier quoted context omitted.

I came to ask the same thing. We use docker-compose to describe all our services which works fine.

This does not scale to a large number of services with a certain amount of RAM/processing per service.

If you have 100 services in your org, I don't have to have 100 running at the same time in your local dev machine. I only run the 5 I need for the feature I'm working on.
Post reply on HN