[neilxchen]

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 personal/team configs).

- That being said, I can imagine exporting a Dockerfile can be feasible on Nimbus for the future (sufficient to replicate a new dev environment), but with certain Nimbus specific features missing there.

> it is git integrated i assume...

And yes, you are right! It's has git integration, and we are working on more tooling integrations right now to build better developer experiences (talking about all the source code management tool the team is using, credentials/env variable tools, etc)

> how easy is it to go from writing code to production deployment?

I'm totally with you. As an engineer myself, to me, only having code deployed on the production marks the completion of something, instead of just merging the code to the main branch. So it's important to have an efficient/stable way to move a piece of code to PR, to staging, and eventually to production.

As for Nimbus team, we don't solve this question as our main value prop, but we do facilitate that for sure, by

- making Nimbus a seamless part of engineers dev workflow (among all your task tracking, SCM, CI/CD tools)

- providing flexibly on setting up the dev environment (e.g. you can set it up in a way that is more consistent with the production setup, but still contain development-specific tools)

> Can i single click create a running docker environment with my running code EXACTLY like the code dev environment.

Not an expert of Sagemaker myself - do you mean auto-generating a Dockerfile based on your codebase? :-)

[sandGorgon]

>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 with my production environment.

Everyone here has been burnt by different version of operating system libraries, so stuff doesnt work properly. Python is notoriously funky about this because most of its libraries are written in C actually.

[neilxchen]

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.