Initially, we were working on simplifying dev environments for coding school students. But when we found ourselves using what we were making and finding it useful for our own work, we pivoted to dev teams like us.
Big tech companies like Facebook, LinkedIn, Shopify, Slack, Dropbox, etc. all have in-house cloud environment solutions. This lets engineers spend more time on software design and writing production code and less time waiting, testing or troubleshooting. With Nimbus, we’re bringing the same convenience to everybody else.
The three biggest pains Nimbus alleviates are compatibility issues, scaling challenges and not having a powerful enough dev machine.
Compatibility issues touch hardware, software, and users. The leading cause is poorly supported tooling on M1 and M2 architecture or a varied fleet of Mac, Linux and Windows devices of various specs. This is made more complex by tool/package updates that break support for that fleet and the impossible task of writing and maintaining perfect documentation.
Scaling challenges build on the compatibility issues. Engineers can spend days to get access and setup environments for every project they touch. Containers help but it’s only part of the solution and tools like Docker can be so resource intensive that slow devices to a crawl. And then, once everything is set up, important data and code sits on the laptop - which is a hugely vulnerable endpoint (probably second to smartphones).
Nimbus lets engineers always pull the right environment, eliminates local env management and debugging, and makes environments portable - engineers can work from any machine because the code runs and stays in the cloud.
We want Nimbus to be easy to use and flexible enough for any developer, so we provide persistent and ephemeral VMs (EC2) that work just like local development. You create a ‘template’ that tells us what kind of machine and OS you want. Then you load up a ‘workspace’, which is a cloud machine near you for the lowest latency possible. You can jump into that server via our local VS code plugin (Jetbrains coming soon) or the remote dev capability of your IDE and get to work. At any point, you can ‘snapshot’ the image and use that as a ‘template’ for future workspaces.
Here are some examples of ways we’re being used today: a European logistics software company replaced their internal cloud infra with Nimbus to improve reliability and reduce engineering and cloud costs; a fast-growing international fintech company is using Nimbus to bring reliability and consistency to dev environments that broke often; a software development agency is using Nimbus to cut onboarding for their engineers from days to hours; some developers are personally using Nimbus to work at home from their gaming PC and extend their laptop battery life when away from home.
Other products in this space focus on simpler use cases (e.g. Replit) or have design choices and limitations that we weren’t happy about. Codespaces is the best-known offering but it’s expensive, not platform-agnostic, and has limits from its repo-based workspace design. Some people ask if we compete with Docker but most of our users use Docker in Nimbus - and Docker’s poor performance on Mac is one of the main reasons people try Nimbus.
We have a free trial if you want to check it out: https://app.usenimbus.com/. We’re currently working on self-hosting capabilities, enabling prebuilds, and easier templated environment creation – but we’d love to hear what you want. And we look forward to your thoughts and feedback on Nimbus and coding on the cloud in general!
What's the differentiation of Nimbus? Why should I get my team to try out Nimbus?
(Not a trick question, I'm just trying to understand how I should remember Nimbus for the next time the question of picking a cloud dev env solution comes up.)
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
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.
If 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.)
>I'd love to look again once virtual MFA or hardware MFA is supported.
MFA is not far. We have already started to work on MFA across our solution. I will ping you as soon as we have it ready for you.
Actually your use case is also something we are really interested in. Engineers who work on contracts or work at IT consultant companies switch between different environments way more frequently than other use cases. I wonder how you mitigate that problem today?
> The cloud env worked well, although I noticed the latency.
About latency, can I ask what your geolocation is? (country?) and which region did you select from Nimbus?
> I'd want fast VM start times
We have provided a `active hours` feature (not available for trial user). You can have your server start/stop at a given time of the day. During that time range your server will always be active. only takes about 10-15 seconds to connect.
my fundamental question is : how easy is it to go from writing code to production deployment ? This has been the big issue with cloud dev. Take an example of Python flask with Pandas. There are problems depending on whether u used an alpine dev environment or debian. Now if i just take the code and try to deploy it on redhat...it goes all screwy. lots of the c library extensions start screwing up.
Can i single click create a running docker environment with my running code EXACTLY like the code dev environment.
Funnily enough, the only good one here is AWS Sagemaker - https://docs.aws.amazon.com/sagemaker/latest/dg/docker-conta...
They do this for machine learning code. You can take your data and algorithms out of the ide and get a running docker container with all the build scripts and everything.
second - ur pricing is off. part of the charm of a cloud dev environment is never turn it off. like shutting the lid of my macbook m1 and opening tomorrow morning. even the cursor is in the same place. There is zero incentive for me to shutdown a system and reopen tomorrow morning. In that scenario, ur pricing for an 8 core 32 gb instance is 421 USD per month. Comparitively a Google Cloud 8core 32 gb instance with 100 GB SSD is 212 USD.
Sagemaker Python notebooks ml.t3.2xlarge are 0.399 USD per hour - about 288 USD per month. you will need to adjust pricing.
replit pricing of 7$ hacker plan is cheaper than equivalent Sagemaker pricing (about 36$ per month)
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? :-)
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.
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, the way we’ve set up our environments is that the machine doesnt “turn off” - we just stop it. So its like closing your macbook lid and reopening it. You don’t lose your progress and youre not charged for the time in between.
And Replit’s Hacker plan is cheap but they aren’t very powerful (just 2vCPU and 2GB ram)
with all due respect, ur equivalent plans are far more expensive. because the equivalent on Nimbus is 30 hours per week. But on replit - u can actually host a website. The repl is "always on".
I think we probably have to agree to disagree on wasting energy here. The magic of cloud environments is always on environments where my scratch api is also running for my other developer to ping. Replit is pretty good for this. So is Sagemaker. But I do respect that ur target market is a bit different.
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 years ago
This is my question too.
There are increasingly limited differentiation between various vendors. The biggest improvement areas needed now are simpler configuration, faster boot times for complex projects (pre-built code, cached artifacts, IDE plug-ins configured).
Cloud9 IDE Appvia Coder CodeSandbox CodeZero.io DevSpace Desktop Tilt Env0 Floxdev Gitpod Itopia Spaces LocalStack MetalBear Azure DevTest Labs Visual Studio Codespaces Nimbus Okteto SourcePro Porter Codeready Workspaces Repl.it Stackblitz Strong.network Subpoint Solutions Tangram.dev
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 your point there's going to be someone doing things like you when theres more and more competitors.
Also - brilliant job with Codenvy! You're one of the pioneers in the field. When we started Nimbus we did our research (even talking to the folks at Koding, NitrousIDE, etc)
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?
A few more things we learned based on the current market is that the team is way more distributed geographically now. So the latency and collaboration across different geolocation are also two areas we really focus on.
The tracking methodology buckets companies by the primary product they advertise. Withcoherence is in a different category that has a broader platform definition.
There are companies like gitlab and Codegiant that also have remote dev envs as features of the broader product line.
Mainframes are back baby!
> engineers can work from any [network connected] machine because the code runs and stays in the cloud.
Now that we have pervasive and quick internet in most of the places people want to work, we can start offloading the work back to centralized machines.
It's honestly a more efficient use of resources to have shared central systems, we just had to move away from them for a few decades because the networks couldn't keep up with where people wanted to work.
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.
This is on the money. The challenge though is still giving engineers flexibility/freedom. Our approach is to have templates that engineers can use but they can fork it and play around with it, make a snapshot of that fork and share it, etc. Its a fine balance though and every team has to figure out what works best for them
Love the site, digging into the concept...
One question, how does Nimbus manage secrets/creds? Integration with KMS?
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!
Thanks for explaining! this makes a ton of sense -- the workspace scoped creds I guess would be the only place where they'd be stored (temporarily).
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!
I have been using Nimbus on my flights and it works well. Of course depends on your geolocation, the latency can be higher than normal but the internet speed should not be a blocker because all the intense internet traffic happens on the data center.
However, without internet it would be challenging to leverage Nimbus solution at this moment since the environments live on the cloud 100% now. But in the future, we will look into a hybrid solution. In short, we can offer the option to rsync (or similar tools) the cloud environments into your local or the other way around to facilitate this corner case.
We have some loose plans but not really high up to be honest.
From a traveling perspective, it works well... as long as you have internet..you get fast download speeds (based on AWS data center transfer speeds), can work on an env more powerful than ultrabooks, and your battery life is longer.
But you can't work from a jungle or a plane without wifi :)
2. What do you mean by "Local File Sync" here - https://endurable-podium-3d4.notion.site/Nimbus-vs-the-compe...
2. Basically, you'll be able to keep the files synced between your local environment and your Nimbus workstations
https://azure.microsoft.com/en-us/blog/announcing-microsoft-...
Nimbus is more like GitPod/Codespaces and not intrinsically linked to Kubernetes like DevSpace is. DevSpace is optimized for cloud native development and you could run it on top of Nimbus to connect your dev environment to a k8s cluster.
Hope that helps!
I was just typing up a response but can't be more succinct than this :)
Love to see how you like Nimbus and how you feel the difference between different alternatives.
The cost of a laptop is a factor but its a drop in the bucket relative to the cost of an engineer. A $4k machine over 2 years on an engineer that has a fully loaded cost of over $200k/yr is only 1% of the total cost - not huge.
The real win is in helping engineers do more while saving time. This has huge impacts on the dev experience, productivity and general happiness in a role where many experience burnout.
But to answer more plainly, in some cases it will replace laptops (e.g. some companies ship laptops to their contractors to keep their code and data secure. They wont have to anymore). In other cases, teams save money on laptops (through lower spec'd machines with a longer lifespan).
- Why EC2 instead of EKS or container oriented AWS service for running workspaces?
Feel free to check out our doc about how to set it up here: https://www.notion.so/Connect-to-Nimbus-workspace-8c7c5b41d9...
The only area where I can see this making sense is in the realm of AI/ML where you need beefy GPU's and resources to train models and it's easier to keep them close to the runners.
What's the value prop for something like this (or code spaces, or <insert name of some cloud dev ide service>)?
If you need reproducible builds? Why not just use docker?
Actually the larger the organizations the more necessary a cloud-based dev environment solution. That is why all the tech giants have a solution internally like Nimbus and all organizations with more than 500 engineers that I have talked to have something like Nimbus.
> To me this seemed like a novel way to enforce strictness in SDLC for junior devs writing javascript-like code...
The key is not to enforce a strict SDLC. The key word is `Consistent`. I can see some exceptions where teams want to have inconsistent environments but I believe vast majority of the teams want to have consistent environment within their eng org. It means easier onboarding, fast recovery, and better collaboration.
> ... but never came close to having the real IDE on your machine.
If you are doing iOS development or something similar I would agree that IDE on your machine is a necessary. After all, you still need XCode. (even that, I see technologies are catching up...) But other than those native apps, I don't see real difference between a local vs cloud dev environment.
Can you share some examples? What can you do on local but very difficult/impossible to do on cloud dev env?
> If you need reproducible builds? Why not just use docker?
Here are some of my thoughts:
1. in a small scale (3 micro-services + 1 DB + 1 webapp), I think docker does an amazing job to ensure reproducible builds. But as the complexity grow, docker starts to shift from part of the solution to part of the problem. Just to throw out some questions: how to manage compatibility if a team uses Windows, Mac, Linux at the same time, even with different versions? How to ensure 237 of my engineers do not have a broken environment when I want to bump the docker version?
2. There are things should not be part of docker images and those things are more troublesome than the build itself sometimes. For example: credentials, env vars, and so on. I don't remember how many times I need to ask a bunch of people just to get the credentials right.
3. Even an amazing tool like Docker does not have 100% of the market. So we may be a good alternative for the teams who choose not to use Docker.
They have traction _especially_ in larger organisations imo.
afaik at least Google and Amazon rely on remote development where your laptop is just a terminal to some remote machine. Not sure about other BigTech but maybe others can comment.
Eng blog links:
LinkedIn: https://engineering.linkedin.com/blog/2021/building-in-the-c...
Shopify: https://shopify.engineering/modelling-developer-infrastructu...
Slack: https://slack.engineering/development-environments-at-slack/
Doximity: https://technology.doximity.com/articles/github-codespaces-i...
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.