Ask HN: Do you share your dev clusters? | Hacker News Reader

Ask HN: Do you share your dev clusters?

10 pointsairocker12 comments

When developing software in your team, does everyone share a cluster, or does everyone have a separate cluster. Which do you prefer? Anyone have a setup where some parts are shared and some are separate?

By cluster, I mean the servers that are serving the website or mobile application.

I have been asking a few companies and it seems that some small companies (5-10 developers) have one important service that they develop independently like a monolith on one VM/container/desktop. The rest of the services(ingress, load balancer, autoscaler) are just scaffolding to put the SaaS(or some other product) together around that one monolith. And I am guessing there are other companies where the product is so big (Google Workspaces) that one cluster per developer is very cost prohibitive.

It would be great to know how different companies do it.

View on HN

Can you be more specific on what exactly do you mean by 'cluster'? A cluster of desks? Deployment and testing environments? A storage array? It might be helpful to know what kind of application are you building.

A cluster of vms or pods that is running on the servers serving the website or mobile application.

(Here "cluster" means "copy of the system being developed", whether or not that is one or more machines, virtual hosts, containers, whatever, ...)

It's a requirement I think that one developer be able to work without disrupting what other developers are doing. If sharing clusters is a reason why they can't do that, then sharing clusters gets in the way of doing work.

Some developers might be able to work without a cluster some of the time (sometimes unit tests are enough), other times a developer might need two or more clusters. In some cases a developer can work with a partial cluster (for most of my current job I was able to run a "cluster" that was missing a certain service because I never worked on things that needed that service... until I did)

Whatever technology you are using you ought to have some scripts that make creating a cluster a simple and reproducible procedure, particularly if you are using cloud technology, in which case a developer should be able to create a cluster when needed and destroy it afterwards.

This was my perception too. I have been asking a few companies and it seems that some small companies (5-10 developers) have one important service that they develop independently like a monolith on one VM/container/desktop. The rest of the services(ingress, load balancer, autoscaler) are just scaffolding to put the SaaS(or some other product) together around that one monolith.

And I am guessing there are other companies where the product is so big (Google Workspaces) that one cluster per developer is very cost prohibitive.

It would be great to know how different companies do it.

In the current place of work I’m at (a YC funded startup) we have 4 dev environments that are shared among several dozen engineers. Each of these is a kubernetes cluster that can be “checked out” using a slack bot. Devs can also run the cluster locally on Docker Desktop which most developers do for most use cases. It works pretty well. We have never run out of environments. There’s definitely still some room for improvement, however.

For instance we currently reuse environments but are instead working on a way to build a queue of fresh environments that rebuild themselves after you are done with it so that developers always get a clean cluster when they request one.

I will say that we almost never run into problems due to environments being shared between developers - the “clean room” approach is more for developer confidence and feeling good than anything else.

I think the suggestions of docker are overly specific.

The industry gold standard for any given software application that will be deployed to the cloud is:

- Define infrastructure as code (terraform, AWS CDK, etc.)

- Have automated mechanisms in place to deploy self contained pre-production and production environments of the above infrastructure

- Allow developers to create a “personal” deployment of the above, similar to a pre-production environment but with any changes the developer wishes to make as part of development. This should be as simple as running a few commands.

Some harnessing that allows for completely local development of portions (or all of, depending on the software application) of the above can also be desirable, to speed up development.

Do you ever see a case when there are so many services with so many dependencies that personal deployments are too costly or unweildy?

I think the vast majority of well architected software applications will have the property that no component alone is too large to be deployed as a “personal” deployment.

The ability to point deployed personal stacks at a pre-production environment (this is often the default) instead of another personal deployment is a means of breaking the chain of needing to deploy personal instances of every dependency needed to function.

This gives the developer choice. If they are only working within one part of the system, only a single personal deployment may be needed. If the change is more cross cutting, multiple personal deployments could be used (or maybe, the change should be made more incrementally).

At my company engineers run the services they're working on locally (on their laptops) in docker containers and they also run any other containers their service/app/client needs like the database, a copy of the auth service, and other dependencies, etc. Usually with docker compose.

How many services are we talking about here? Do you think this model will scale as the number of service grows?

I think a popular solution to this kind of problem is docker compose.

Or minikube.

But would it work for large products with possibly 1000 services? I have never worked on those but would like to know if there are products where one cluster per developer is too costly and unweildy.

Is there a case for products that are better served by monolithic codebases that are developed without going to docker-compose or minikube at all.

Reply on news.ycombinator.com