[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.