[liushh]

Liusha from Nimbus here.

Actually the larger the organizations the more necessary a cloud-based dev environment solution. That is why all the tech giants have a solution internally like Nimbus and all organizations with more than 500 engineers that I have talked to have something like Nimbus.

> To me this seemed like a novel way to enforce strictness in SDLC for junior devs writing javascript-like code...

The key is not to enforce a strict SDLC. The key word is `Consistent`. I can see some exceptions where teams want to have inconsistent environments but I believe vast majority of the teams want to have consistent environment within their eng org. It means easier onboarding, fast recovery, and better collaboration.

> ... but never came close to having the real IDE on your machine.

If you are doing iOS development or something similar I would agree that IDE on your machine is a necessary. After all, you still need XCode. (even that, I see technologies are catching up...) But other than those native apps, I don't see real difference between a local vs cloud dev environment.

Can you share some examples? What can you do on local but very difficult/impossible to do on cloud dev env?

> If you need reproducible builds? Why not just use docker?

Here are some of my thoughts:

  1. in a small scale (3 micro-services + 1 DB + 1 webapp), I think docker does an amazing job to ensure reproducible builds. But as the complexity grow, docker starts to shift from part of the solution to part of the problem. Just to throw out some questions: how to manage compatibility if a team uses Windows, Mac, Linux at the same time, even with different versions? How to ensure 237 of my engineers do not have a broken environment when I want to bump the docker version? 

  2. There are things should not be part of docker images and those things are more troublesome than the build itself sometimes. For example: credentials, env vars, and so on. I don't remember how many times I need to ask a bunch of people just to get the credentials right. 

  3. Even an amazing tool like Docker does not have 100% of the market. So we may be a good alternative for the teams who choose not to use Docker.

Of course, there are various solutions to those different problems. I believe we are one of them. Moreover, I believe we can integrate with other solutions to solve the bigger problems.

[gabereiser]

Thanks for the detailed explanation. You're right, "consistent" SDLC is what I meant. For compatibility, docker itself is kind of a sort of standard. I say sort of because of OCI. The idea is that if you run your own registry, create your own base images (and include your security team's input) and enforce a policy where you can only pull from your registry than development is forced to use your standard images, your standard environment. We've even gone so far as to then incorporate terraform to standardize the deployments. Having an M1 Mac with 8 cores and 8 gpu feels like overkill if I'm just going to login to a website and code. How do you handle desktop codebases? Electron apps? OpenGL w32 apps? There's still room for an IDE on my mac. I guess my biggest concern with platforms like yours is the fact that big brother can always slip a timeclock in there.

[liushh]

I think you are right :) with a great dev infra and policy setup and proper enforcement, docker can be a great solution of environment consistency/standardization.

One use case I forgot to mention and I want to share. In some scenarios, engineers need to work on more than one project and they have completely different set up, which would be difficult for them to maintain multiple environments on their laptops. Back to our docker example, if project A requires docker desktop 4.1.0 and project B requires 4.7.0 it would difficult for the engineers to manage that. I know this is an extreme example but good enough to make the point. This scenarios happen a lot in consultant business where one engineer need to work for multiple clients at the same time.

In terms of desktop codebases, do you mean native desktop application development? I think that is a tricky one as well for similar reasons as mobile development because you need to run the apps on a specific OS for testing. But if one finds a workaround for testing, then writing code on Nimbus environments should be as good as on your local environments.

About the concern the big brother can always slip a timeclock in there: haha~ as an engineer I feel you. That is never the goal of Nimbus and I would not want my boss to stalk my every single keystroke.