Hacker News new | ask | show | jobs
by hamandcheese 675 days ago
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.
3 comments

Wouldn't this be a reasonable alternative? Asking because I don't have experience with this.

1. New shared builds update container images for applications that comprise the environment

2. Rather than a "devbox", devs use something like Docker Compose to utilize the images locally. Presumably this would be configured identically to the proposed devbox, except with something like a volume pointing to local code.

I'm interested in learning more about this. It seems like a way to get things done locally without involving too many cloud services. Is this how most people do it?

We do this, but with k3s instead of docker compose (it’s a wonderful single-box substitute for full k8s), and a developer starts by building the relevant container images locally. If everything works, it takes about 3 minutes to get to a working environment with about a dozen services.

We steer clear of proprietary cloud services. In place of S3, we use minio.

The one sore spot I haven’t been able to solve yet is interactive debugging. k8s pushes you toward a model where all services need a pile of environment variables to run, so setting these up is pretty painful. In practice, though, all rapid iteration happens inside unit tests, so not having interactive debugging isn’t much of a productivity drag.

At least on a MacBook, docker is still a compromise in many ways since it has to run on a Linux VM (I live in the SF tech bubble where I've only ever been issued a MacBook).

Even on my personal Linux desktop, I don't love developing in containers. It is very tedious to context switch between my local environment and the in-container environment, and I don't even consider myself the type with a super personalized setup.

So I don't consider local docker that much of an improvement over a remote devbox.

> It is very tedious to context switch between my local environment and the in-container environment

I think, with my proposed setup, you'd still do development on your local machine. The containers would only be there for the dependencies, and as a shell to execute your code. The container hosting the application under development would use a volume to point to the files on your local machine, but the container itself (with all its permissions and configuration) would match or nearly match what you plan for the production environment.

I manage a dev environment for a small, inexperienced (but eager) team and I have a similar setup. I’ll do a write up at some point if I have time. It can work, and does for me, but there are some funny consequences can end up mediate the relationship between a developer’s computer and his code, which is a terrible place to be.
It’s $250/month for a c6g 2xl 1tb ebs on demand pricing go reserved instances. Given they use AWS and are a major customer, you can expect excellent pricing above the above public pricing quote.

Considering the cost of a developers time, and you can do shenanigans to drive that even lower, this all feels totally reasonable.

Price out a 1TB ebs volume with similar performance to a local SSD.

For gp3, you only get 3000 IOPS and 125MBps throughout, without paying extra. That is orders of magnitude less than a local consumer-grade SSD.

Spec it up to 100k IOPS and 5000MBps and you're looking at nearly $800 a month. And that's still way less performance than you get with a local SSD.

Spec it up to 500k IOPS (approaching nvme SSD performance) and you're looking at $2500/month. Now you are on par with a consumer grade SSD.

If you truly need that kind of perf (and at Amazon, we had plenty of dev desktops running on ebs without that kind of performance) then you should really opt for an instance type with local storage.
Yeah, that's a good callout.

Ive been deep in to implementing macOS CI workers on AWS where that isn't an option (or rather, it is an option, but it is unsupported and Amazon only buys Macs with the smallest possible SSD for the given configuration). So your options are to pay an arm and a leg for fast EBS, or pay an arm and a leg for a pro or max instance with larger internal SSD.

But on Linux there are better options.

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.