3 ms·

Not to pull attention away from the OP but do these web-based dev environments have any traction in larger organizations? To me this seemed like a novel way to

Not to pull attention away from the OP but do these web-based dev environments have any traction in larger organizations? To me this seemed like a novel way to enforce strictness in SDLC for junior devs writing javascript-like code but never came close to having the real IDE on your machine. The only area where I can see this making sense is in the realm of AI/ML where you need beefy GPU's and resources to train models and it's easier to keep them close to the runners. What's the value prop for something like this (or code spaces, or <insert name of some cloud dev ide service>)? If you need reproducible builds? Why not just use docker?

jatins 4y ago
> do these web-based dev environments have any traction in larger organizations They have traction _especially_ in larger organisations imo. afaik at least Google and Amazon rely on remote development where your laptop is just a terminal to some remote machine. Not sure about other BigTech but maybe others can comment.
- liushh 4y ago
  I can say for Meta/Facebook, Shopify, LinkedIn, Microsoft, Doximity...
- nithayakumar 4y ago
  Facebook definitely does it. Thats where we first learned about this way of working. Some bigger tech companies have actually written about it (see links below) but a list of ones that we've seen with this kind of infra include LinkedIn, Shopify, Dropbox, Stripe, Slack, DataDog, and Palantir - to name a few. Eng blog links: LinkedIn: https://engineering.linkedin.com/blog/2021/building-in-the-cloud-with-remote-development https://engineering.linkedin.com/blog/2021/building-in-the-c... Shopify: https://shopify.engineering/modelling-developer-infrastructure-teams https://shopify.engineering/modelling-developer-infrastructu... Slack: https://slack.engineering/development-environments-at-slack/ https://slack.engineering/development-environments-at-slack/ Doximity: https://technology.doximity.com/articles/github-codespaces-is-great-but-mutagen-is-better https://technology.doximity.com/articles/github-codespaces-i...
liushh 4y ago
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 4y ago
  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.

jatins 4y ago

> do these web-based dev environments have any traction in larger organizations They have traction _especially_ in larger organisations imo. afaik at least Google and Amazon rely on remote development where your laptop is just a terminal to some remote machine. Not sure about other BigTech but maybe others can comment.

liushh 4y ago
I can say for Meta/Facebook, Shopify, LinkedIn, Microsoft, Doximity...
nithayakumar 4y ago
Facebook definitely does it. Thats where we first learned about this way of working. Some bigger tech companies have actually written about it (see links below) but a list of ones that we've seen with this kind of infra include LinkedIn, Shopify, Dropbox, Stripe, Slack, DataDog, and Palantir - to name a few. Eng blog links: LinkedIn: https://engineering.linkedin.com/blog/2021/building-in-the-cloud-with-remote-development https://engineering.linkedin.com/blog/2021/building-in-the-c... Shopify: https://shopify.engineering/modelling-developer-infrastructure-teams https://shopify.engineering/modelling-developer-infrastructu... Slack: https://slack.engineering/development-environments-at-slack/ https://slack.engineering/development-environments-at-slack/ Doximity: https://technology.doximity.com/articles/github-codespaces-is-great-but-mutagen-is-better https://technology.doximity.com/articles/github-codespaces-i...

liushh 4y ago

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 4y ago
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.