4 ms·

We kind of already have. We built a CLI that allows them to create/update/delete/list all their dev envs, so they have all the tooling needed. Also, we are stil

by hacb 4y ago

We kind of already have. We built a CLI that allows them to create/update/delete/list all their dev envs, so they have all the tooling needed. Also, we are still a small/medium sized company, so we often had the chance to talk with them to expose this issue, but in the end it never really worked.

wizhi 4y ago
> we are still a small/medium sized company Sorry this is somewhat off-topic, but _why_ do you have virtual development machines?
- hacb 4y ago
  We currently have ~40 microservices running (for the same number of devs), and having the full stack on a laptop is not possible. Especially with 80% of the devs having MacBook and Docker in a VM. Also, this allow us (the infra folks) to chose how devs will work (partially), so it's easier for us to debug when they have issues because we do not have to deal with custom Makefiles etc.
  - piva00 4y ago
    Is it really needed to have 40 microservices for 40 devs? What I mean is that you generally scale out to so many services when you need each to have variable scalability, so each part of the system can scale up/down as necessary. If you don't need this, all these services could be written as larger modules, with proper separation of concerns but easy to be deployed as a single piece. Collect some stuff that are similar in domain and create a well designed monolith. Easier for operations, easier for devs to maintain. Dependencies upgrades aren't a nightmare, or you need very good tooling to not create toil (which generally a small operation won't have). Just throwing this in the wind because it sounds pretty heavy for a 40-body shop to be carrying as many services, at least I don't see the benefits unless for the aforementioned scalability advantage.
- aprdm 4y ago
  One example can be to target many different OSes/CPU architecture / GPUs architecture.
trumbitta2 4y ago
A weekly digest over email, or a dashboard on a real screen if you all work out or the same office, indicating costs and what's contributing to them. That will do wonders.
- hacb 4y ago
  That will also add a lot of overhead/maintenance cost that we can't currently handle.

by hacb 4y ago

wizhi 4y ago

> we are still a small/medium sized company Sorry this is somewhat off-topic, but _why_ do you have virtual development machines?

hacb 4y ago
We currently have ~40 microservices running (for the same number of devs), and having the full stack on a laptop is not possible. Especially with 80% of the devs having MacBook and Docker in a VM. Also, this allow us (the infra folks) to chose how devs will work (partially), so it's easier for us to debug when they have issues because we do not have to deal with custom Makefiles etc.
- piva00 4y ago
  Is it really needed to have 40 microservices for 40 devs? What I mean is that you generally scale out to so many services when you need each to have variable scalability, so each part of the system can scale up/down as necessary. If you don't need this, all these services could be written as larger modules, with proper separation of concerns but easy to be deployed as a single piece. Collect some stuff that are similar in domain and create a well designed monolith. Easier for operations, easier for devs to maintain. Dependencies upgrades aren't a nightmare, or you need very good tooling to not create toil (which generally a small operation won't have). Just throwing this in the wind because it sounds pretty heavy for a 40-body shop to be carrying as many services, at least I don't see the benefits unless for the aforementioned scalability advantage.
aprdm 4y ago
One example can be to target many different OSes/CPU architecture / GPUs architecture.

trumbitta2 4y ago

A weekly digest over email, or a dashboard on a real screen if you all work out or the same office, indicating costs and what's contributing to them. That will do wonders.

hacb 4y ago
That will also add a lot of overhead/maintenance cost that we can't currently handle.