Launch HN: Nimbus (YC W22) – Cloud dev environments for teams
81–90 of 96 posts
Re: Launch HN: Nimbus (YC W22) – Cloud dev environments for teams
#82Congrats Liusha and team!!
Re: Launch HN: Nimbus (YC W22) – Cloud dev environments for teams
#83Earlier quoted context omitted.
1. The usage based fee goes up or down based on the hours used. So if you use 60 hours / week, expect it to be double the estimates. In a few months, we'll be launching our "self-hosted" option that lets you avoid usage fees from us by running it on your own AWS. 2. Basically, you'll be able to keep the files synced between your local environment and your Nimbus workstations
Regarding (2), what does it use under the hood? Rsync? Will the files be automatically synced to local on save?
Just for a quick clarification - it actually refers to manual file sync on your need at the moment. Syncing files automatically is something the team is discussing right now but may not become available in the product in the near future.
Under the hood, essentially, you can access Nimbus workspace via ssh (with private key/public key pair). With that foundation, if you ever want to download files or upload files, you can do so with scp, rsync, or anything that can transfer files over ssh tunnel.
That also means, technically, you don't have to use VSCode/JetBrain to write code on Nimbus workspace (though we have/are going to have official extension/plugin support, which is recommended). You can directly ssh into the workspace and write code in emacs/vim, or use any editor/IDE with SFTP support.
Re: Launch HN: Nimbus (YC W22) – Cloud dev environments for teams
#84Earlier 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…
every virtualisation product for 20 years has supported saving the machine state to a file and then restoring it at some point later (maybe years) I do this a lot on my home machine, with an nvme ssd it's under a second to save or restore the entire machine state it's a shame the big cloud providers (Azure, GCP, AWS) virtualisation offerings are so... crappy compared to VMware workstation/ESXi/Xen/KVM/... from 20 yea…
Re: Launch HN: Nimbus (YC W22) – Cloud dev environments for teams
#85Are Cloud environments/IDEs going to replace the desktop/laptop we give to dev teams. What's the comparison wrt cost and ease between two?
Re: Launch HN: Nimbus (YC W22) – Cloud dev environments for teams
#86If that's addressed, I'm interested, although my use case is different. I do contract work, mostly short-term time-sensitive projects where I need to rapidly get productive on client systems. So far I've managed this by working from a beefy machine and putting each client's environment in their own local VM. The separation of clients is important since I work with multiple clients at a time, and mixing would be a huge issue.
This works fairly well. At the start of the contract I spin up a new VM. I've got standard dotfiles and install scripts I copy/paste from a Gist, then I manually install anything client specific. I needed to spin up a cloud env recently for a client who had a very memory hungry web app. The cloud env worked well, although I noticed the latency.
It looks like Nimbus will let me spin down my "beefy cloud VM" when I'm not using it, to save costs. I don't do that currently, mostly because I don't see a _trivial_ one-click way to do it. This looks like roughly 2x EC2 pricing (8cpu/32G $0.26 vs $0.58), so reducing running hours is key. I'd want fast VM start times, I don't want to wait too long. I'd probably be interested in even larger instance types, as throwing more hardware on a project is worth it to me if it helps me work faster and justify higher rates.
(edit, looks like there's a 14 day trial. I won't try this before there's an MFA solution, but it would be nice if the trial would start when I spin up the first VM.)
Re: Launch HN: Nimbus (YC W22) – Cloud dev environments for teams
#87Earlier quoted context omitted.
> It means you have the full control and flexibility to define how your environment looks like instead of being forced to have one repo per environment. This flexibility enables the exact same experience as the one you have in your laptop from development and env management perspective. One thing I love about Gitpod is that everyone gets the same exact environment when they start Gitpod from a repo/PR. It seems like…
haha I want to be clear. I meant you can define your environment however you like in terms of flexibility. You can have 27 different repos with 2 k8s clusters with other integrations you like in an environment. Nimbus can achieve exactly the same. You can define an environment template and all workspaces your team create from that template will have exactly the same environment. In short, a team can enforce consisten…
Re: Launch HN: Nimbus (YC W22) – Cloud dev environments for teams
#88- Why EC2 instead of EKS or container oriented AWS service for running workspaces?
Re: Launch HN: Nimbus (YC W22) – Cloud dev environments for teams
#89Re: Launch HN: Nimbus (YC W22) – Cloud dev environments for teams
#90The remote dev environment space is heating up. Quite a few variants and competitors now emerging in this generation of vendors. I started and sold Codenvy to Red Hat which implements Eclipse Che and Eclipse Theia as CodeReady Workspaces. There are increasingly limited differentiation between various vendors. The biggest improvement areas needed now are simpler configuration, faster boot times for complex projects (p…
Nish from Nimbus here. Personally, I dont think this is going to be a space where one company "wins the market". Whats best for developers is having flexibility and choosing the right tool for what their building and their team. So I'm hoping that these products become/stay more open and let people pick them up and drop them as needed. On the differentiation front.. there's some common differentiation points, but to…
One of the things that's annoyed me about codespaces and gitpods is that they really require/assume the whole team will use that one product. Codespaces does that through their billing and permissions, and gitpods does it via their PR based features etc. Is this something Nimbus is going to try and avoid? What's best for the majority isn't always best for the individual, and that's why we have so many different IDE's. Perhaps my personal workflow is served better by Nimbus and my colleagues is better suited for codespaces.
With some tools, like bug trackers, it makes sense to pick one tool for everyone of course. What do you think about remote dev environments?