All I really want is to open VSCode and remote into a thing, no matter what it is, where my repo is available, and to build my bazel targets with remote execution and caching. But at 4x the price of EC2 instances I'm honestly not seeing what's being offered here or how it helps me.
Launch HN: Nimbus (YC W22) – Cloud dev environments for teams
61–70 of 96 posts
Re: Launch HN: Nimbus (YC W22) – Cloud dev environments for teams
#62Your documentation in Notion is annoying me because at the bottom of each page you have no footer, no navigation, nothing. So after each page I've read, I have to use the top left breadcrumb, remember which page I've just read and find the next page in the list to continue reading through your documentation.
Maybe they should use Nimbus for their documentation? Nimbus Note, that is: https://nimbusweb.me/ . I use Nimbus Note occasionally, it’s a bit confusing, both using the same name.
Re: Launch HN: Nimbus (YC W22) – Cloud dev environments for teams
#63Earlier quoted context omitted.
Nish here. Let me address the run time and pricing question - my cofounder wants to touch on the other question. Teams have told us that they want to avoid 24/7 machines. It gets really expensive (and wastes energy) when people keep creating instances and leave them on. Our approach is to let people keep them on 24/7 if they want, but we want them to stop the instances too (we have automation for this). That said, th…
>And Replit’s Hacker plan is cheap but they aren’t very powerful (just 2vCPU and 2GB ram) with all due respect, ur equivalent plans are far more expensive. because the equivalent on Nimbus is 30 hours per week. But on replit - u can actually host a website. The repl is "always on". I think we probably have to agree to disagree on wasting energy here. The magic of cloud environments is always on environments where my…
> The magic of cloud environments is always on environments where my scratch api is also running for my other developer to ping.
The magic of cloud environments is efficiency and economies of scale. Scale to 0 services are perhaps some of the most popular in the cloud era; especially for students or side projects which seem to be the inspiration for Nimbus.
I’m not defending any pricing but I think the model is useful.
Re: Launch HN: Nimbus (YC W22) – Cloud dev environments for teams
#64Earlier quoted context omitted.
Nish here. Let me address the run time and pricing question - my cofounder wants to touch on the other question. Teams have told us that they want to avoid 24/7 machines. It gets really expensive (and wastes energy) when people keep creating instances and leave them on. Our approach is to let people keep them on 24/7 if they want, but we want them to stop the instances too (we have automation for this). That said, th…
>And Replit’s Hacker plan is cheap but they aren’t very powerful (just 2vCPU and 2GB ram) with all due respect, ur equivalent plans are far more expensive. because the equivalent on Nimbus is 30 hours per week. But on replit - u can actually host a website. The repl is "always on". I think we probably have to agree to disagree on wasting energy here. The magic of cloud environments is always on environments where my…
Yeah - the targets are different. Thats probably why comparing the pricing seems odd too. Even our lowest tier has more dedicated memory (so its more expensive for us too). But don't get me wrong - I think Replit is really cool but just not what we're going for :)
Re: Launch HN: Nimbus (YC W22) – Cloud dev environments for teams
#65All I really want is to open VSCode and remote into a thing, no matter what it is, where my repo is available, and to build my bazel targets with remote execution and caching. But at 4x the price of EC2 instances I'm honestly not seeing what's being offered here or how it helps me.
We're working on self-hosted right now. When that comes out, you'll be able to do exactly what you want without any usage fees from us (you'll take on the AWS usage, storage, load balancer, and other fees though).
Re: Launch HN: Nimbus (YC W22) – Cloud dev environments for teams
#66Earlier quoted context omitted.
Neil from Nimbus here. You can view Nimbus workspace as a linux machine that you have, but on the cloud. We built an internal Dockerfile-like IDL to replicate the exact dev environment every time when a new workspace is being created. - We love Dockerfile, but we didn't directly build on top of it because there are more configurations we want to enable (such as on create/start/stop/delete lifecycle hooks, and persona…
>making Nimbus a seamless part of engineers dev workflow (among all your task tracking, SCM, CI/CD tools) tricky. unless u can allow my prod environment to be imported into nimbus (or the other way around - export). Otherwise my prod packages and your packages will always be out of sync. And that is too bothersome. The problem is not code merging and branching. But if its a "dev environment", it has to be in sync wit…
This is a really great and interesting point.
We'd love to make Nimbus such a flexible platform that engineering teams can configure the Nimbus dev environment as close as possible to production environment. A few opinionated thoughts here:
- it makes sense that dev environment setup follow prod environment setup as much as possible (so that it's reliable to know code in dev environment works on prod environment, for example). However, on the other direction, prod environment should focus on solving its own problems (scalability, stability, etc..), so it might not be a great practice to set up prod environment following the dev environment;
- automatically importing prod environment into Nimbus is definitely a higher level of thinking once engineers can at least manually specify which package should be included in the dev environment (I love this one);
> Otherwise my prod packages and your packages will always be out of sync
From the dev environment perspective, we intend to not enforce everyone to use "our packages" (in fact, our built-in packages should be common ones with least surprises). In the future, we want to have a way so that users can define their own packages on Nimbus.
> Everyone here has been burnt by different version of operating system libraries, so stuff doesnt work properly
Not sure if everyone in your team has consistent dev environment, but just different from the prod environment; or everyone in the team also has inconsistent dev environment, which is also inconsistent with prod environment.
If it's the latter one, that's also a problem we are trying to solve - eventually in a team setup, there should be just one-time set up of the dev environment, and everyone else can just spin up a workspace and write code, without worrying about the version difference etc.
Re: Launch HN: Nimbus (YC W22) – Cloud dev environments for teams
#67What does this support outside of Javascript?
If you are talking about programming languages - it supports Golang, PHP, Java, Ruby and more. Mostly any frontend/backend languages (other than mobile development languages)
You can actually treat the Nimbus workspace as your laptop on cloud. If there's anything you see not supported on Nimbus at the moment, you can create a workspace, install as many packages as you need. And once you want to share the set up with the team, you can snapshot it and create a public (org-wide) template out of it.
Re: Launch HN: Nimbus (YC W22) – Cloud dev environments for teams
#68Not 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 mode…
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…
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.
Re: Launch HN: Nimbus (YC W22) – Cloud dev environments for teams
#691. Your pricing assumes 30 hour / week. What happens if we use it beyond that?
2. What do you mean by "Local File Sync" here - https://endurable-podium-3d4.notion.site/Nimbus-vs-the-compe...
Re: Launch HN: Nimbus (YC W22) – Cloud dev environments for teams
#70Congrats on the launch -- great minds think alike I guess... I've got a little think I'm still churning on @ https://nimbusws.com
Love the site, digging into the concept...
One question, how does Nimbus manage secrets/creds? Integration with KMS?