[nithayakumar]

Nimbus is more like local development, we're building for teams that use a wide set of IDEs. Think of us as a "machine first" cloud environment instead of "repo first". So its like having a laptop in the cloud for every project.

Our differences means we've prioritized local editor integrations, use a full EC2 machine dedicated to each user, aim to be more flexible (e.g. you can schedule when your machines are active), and provide more power (right now up to 8vcpu 32gb ram, but customizable by us).

Codespaces, Gitpod and the like are repo first and provide containers instead of VMs. Codespaces doesnt support non-VS Code Users. Gitpod tops off at 8gb or 12gb of ram. We also decided not to go the browser based IDE path that Stackblitz took because the engineers we talked to really didnt want a new IDE.

Hope that helps!

Edit: Want to clarify that I'm Nish from Nimbus

[rsstack]

> Nimbus is more like local development, we're building for teams that use a wide set of IDEs.

How does that work from the IDE's perspective? VS Code of course loves being a thin-client, and I used Emacs with AWS Cloud9 with SSH tunneling (and since I'm so close to an AWS region, even X forwarding). What about others?

> Think of us as a "machine first" cloud environment instead of "repo first". So its like having a laptop in the cloud for every project.

I'm not sure what this means in practice. A development environment, regardless of what -first it is, should come with all dependencies required to run the project (app + database + other microservices + local fakes etc.). What does being "machine-first" mean for the end-user experience?

> provide more power (right now up to 8vcpu 32gb ram, but customizable by us).

> Gitpod tops off at 8gb or 12gb of ram

(AFAIK Gitpod's default limit is 8GB but on-prem allows for configuration of this value. Running "free -g" prints 64GB which is wild to me, maybe it's showing me the host server instead of the container?)

Does that mean your target audience is doing data-heaving / processing-heavy development that requires much more powerful machines?

> provide containers instead of VMs

Honest question: As an end-user, how does this affect me? I can stuff _a lot_ into a Docker image. Our largest development environment image right now is at 9GB and can run our whole system end-to-end.

[liushh]

> How does that work from the IDE's perspective?

We have been adding different IDE integrations into our solution so that a user would not even feel they are coding on a remote environment. We support a very smooth VSCode experience now and JetBrains IDE is on the way.

> What does being "machine-first" mean for the end-user experience?

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.

> Does that mean your target audience is doing data-heaving / processing-heavy development that requires much more powerful machines?

Data-heaving / processing-heavy development is definitely a good use case but our target audience is not limited to that. A few examples here:

  1. even though you are running a webapp with micro-services on the backend, the requirement for computing power can increase as the number of services grow. I see some teams are running 20 - 50 micro-services and it is just too much for a laptop.

  2. In some regions, it is not so common that engineers get the high-end macbook pro for their daily work. Some has to work with 8GB ram machines for various reasons.

> As an end-user, how does this affect me?

Theoretically, containers can do everything VMs do but in reality they introduce different complexity. Here are some examples:

  1. If you have two k8s clusters, you can easily run it on a Ubuntu VM and when you run into issues, it is easy for you to find answers support. But running two K8s clusters inside a docker container is much more challenging~ but yes doable.

  2. There are some random issues I run into with containers, like port forwarding (management in general). Again I figured it out but more complex

  3. Easier to integrate with users current configurations. Most users today still code on their laptop directly instead of creating a container and code inside that container. So most settings can be migrated to a VM-based environment directly.

  4. As much as I love containers... still many engineers don't use containers for various reason.

[shafyy]

> 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 letting every developer customize their cloud machine like they customize their local machine would lead to many of the "but it works on my machine" problems?

[liushh]

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 consistent environment with Nimbus easily.

[shafyy]

Got it!