neilxchen
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.
Thanks for the support!
> One question, how does Nimbus manage secrets/creds? Integration with KMS?
It actually depends on what type of secrets/credentials that you are referring here
- For third-party tool login credentials (e.g. the GitHub authorization that we currently support), we are handling that with OAuth. That means we don't directly store secrets/creds on our end and developers can revoke the authorization any time on that tool and/or Nimbus;
- For any secrets/credentials that may be used in environment variables and dotfiles. They are currently lives within the "workspace" scope. That means, if developers delete the workspace, the credentials will be gone, and we don't persist them at the moment.
We are actively working on persisting env variables and dotfiles as part of settings of org/template/user, and the feature will become available soon.
We are also actively working on self-hosting Nimbus on customer's cloud - so if security is the top concern in your mind, with self-host solution, any secrets/credentials will never leave your cloud (together with codebases, user data, etc.)
Happy to provide more insights if you have more questions!
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.
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.
Thanks for the support! I'm also switching between mac (laptop) and windows (desktop) multiple times throughout the day (depends on where I'm sitting at that moment). Using Nimbus to build Nimbus definitely helped me a lot in this scenario!
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? :-)
Yeah, we are actually huge fans of writing code on the cloud!
To me personally, It feels awesome to offload the package/repo download to the data centers, which can be way more faster than my own network. Not even mention that my laptop no longer heats up crazily - I can just put it on my lap and write code.