[HN Gopher] Launch HN: Nimbus (YC W22) - Cloud dev environments ...
___________________________________________________________________
Launch HN: Nimbus (YC W22) - Cloud dev environments for teams
Hey HN! We're Nish, Liusha and Neil, the founders of Nimbus
(https://www.usenimbus.com). We're building an easy way to code and
manage environments on cloud VMs that are configured for projects
you're working on. There's a video demo here:
https://www.youtube.com/watch?v=0g6Jk5zyQG4. 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!
Author : liushh
Score : 66 points
Date : 2022-08-17 13:58 UTC (9 hours ago)
| radiojasper wrote:
| Your documentation in Notion is annoying me because at the bottom
| of each page you have no footer, no navigation, nothing. So after
| each page I've read, I have to use the top left breadcrumb,
| remember which page I've just read and find the next page in the
| list to continue reading through your documentation.
| nithayakumar wrote:
| Noted and very fair comment - thats definitely an area that we
| want to upgrade.
| yabatopia wrote:
| Maybe they should use Nimbus for their documentation? Nimbus
| Note, that is: https://nimbusweb.me/ . I use Nimbus Note
| occasionally, it's a bit confusing, both using the same name.
| gabereiser wrote:
| Not to pull attention away from the OP but do these web-based dev
| environments have any traction in larger organizations? To me
| this seemed like a novel way to enforce strictness in SDLC for
| junior devs writing javascript-like code but never came close to
| having the real IDE on your machine.
|
| 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?
| jatins wrote:
| > do these web-based dev environments have any traction in
| larger organizations
|
| 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.
| nithayakumar wrote:
| Facebook definitely does it. Thats where we first learned
| about this way of working. Some bigger tech companies have
| actually written about it (see links below) but a list of
| ones that we've seen with this kind of infra include
| LinkedIn, Shopify, Dropbox, Stripe, Slack, DataDog, and
| Palantir - to name a few.
|
| 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...
| liushh wrote:
| I can say for Meta/Facebook, Shopify, LinkedIn, Microsoft,
| Doximity...
| liushh wrote:
| Liusha from Nimbus here.
|
| 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.
|
| Of course, there are various solutions to those different
| problems. I believe we are one of them. Moreover, I believe we
| can integrate with other solutions to solve the bigger
| problems.
| TylerJewell wrote:
| The remote dev environment space is heating up. Quite a few
| variants and competitors now emerging in this generation of
| vendors. I started and sold Codenvy to Red Hat which implements
| Eclipse Che and Eclipse Theia as CodeReady Workspaces.
|
| 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
| emptyparadise wrote:
| I wonder if there are any drop in self-hosted solutions for
| this? Would be great to just use a tool like this even for
| personal dev.
| liushh wrote:
| self-host is definitely on our roadmap. For the first step,
| at least we want to deploy the EC2s in your own cloud rather
| than Nimbus's cloud.
| liushh wrote:
| There are definitely more alternatives in the market now. But I
| do see the differentiation pretty clear (maybe because I am
| building it) Actually I think you are pointing out some great
| categories for differentiation, simpler config, faster boot
| time, and so on.
|
| 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.
| verdverm wrote:
| Those are the public ones. We manage our own with packer and
| Ansible, technical a suite of dev VM images, depending on the
| role or tasks (i.e. reg vs ML).
| nithayakumar wrote:
| Nish from Nimbus here.
|
| 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)
| zoomzoom wrote:
| Tyler, don't forget about Coherence! (withcoherence.com)
| TylerJewell wrote:
| Ha! I maintain a public database and people can navigate it
| by going to tylerjewell.substack.com. It links into a public
| google sheet.
|
| 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.
| zoomzoom wrote:
| Thanks! And appreciate the context here...
| dataminded wrote:
| I LOVED Codenvy! Kudos.
| sandGorgon wrote:
| how does it work ? it is git integrated i assume...and do u
| export a Dockerfile or something to replicate the exact runtime ?
|
| 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)
| nithayakumar wrote:
| Nish here. Let me address the run time and pricing question -
| my cofounder wants to touch on the other question.
|
| 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)
| sandGorgon wrote:
| >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.
| nwsm wrote:
| > The magic of cloud environments is always on environments
| where my scratch api is also running for my other developer
| to ping.
|
| The magic of cloud environments is efficiency and economies
| of scale. Scale to 0 services are perhaps some of the most
| popular in the cloud era; especially for students or side
| projects which seem to be the inspiration for Nimbus.
|
| I'm not defending any pricing but I think the model is
| useful.
| nithayakumar wrote:
| Yeah - the targets are different. Thats probably why
| comparing the pricing seems odd too. Even our lowest tier
| has more dedicated memory (so its more expensive for us
| too). But don't get me wrong - I think Replit is really
| cool but just not what we're going for :)
| blibble wrote:
| every virtualisation product for 20 years has supported
| saving the machine state to a file and then restoring it at
| some point later (maybe years)
|
| 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
| neilxchen wrote:
| 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 wrote:
| >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.
| chrisweekly wrote:
| > "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."
|
| This is my question too.
| neilxchen wrote:
| answered on the parent comment - plz let me know if it
| doesn't answer the question for you
| jcolella wrote:
| Awesome work on the launch!. I was wondering what the main
| difference between Nimbus and something like https://devspace.sh/
| is?
| zdloft wrote:
| Hey there! Ziyad from Loft here.
|
| 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!
| nithayakumar wrote:
| Nish from Nimbus here
|
| I was just typing up a response but can't be more succinct
| than this :)
| liushh wrote:
| +1 on "You could run DevSpace on top of Nimbus"
| thegandhi wrote:
| One of the biggest problems with dev environments is maintenance
| just like documentation. As a dev, when I am working on my local
| environment, if something breaks, I usually end up finding some
| hack to fix it and move on with my feature/assigned task. Most
| devs leave it to the "new guy" who is onboarding. I also think
| having templates as code might be a way to alleviate that issue
| to certain extent.
| nithayakumar wrote:
| Nish from Nimbus here.
|
| 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
| fuzzmuzzy wrote:
| Great stuff. Looking forward to JB Gateway compatibility! Really
| looking forward to cloud environments being more of a "thing".
| All the places I've worked at have struggled with various Dev
| environment issues
| liushh wrote:
| Nimbus is now compatible with JB Gateway actually even though
| we don't have an official JB plugin, which we are actively
| working on already!
|
| Feel free to check out our doc about how to set it up here:
| https://www.notion.so/Connect-to-Nimbus-workspace-8c7c5b41d9...
| nithayakumar wrote:
| Yes! I think the problem is that it looks simple to build. But
| once you get in the weeds - its not so easy to manage
| performance, flexibility and stability :)
| mvice wrote:
| This looks really cool! I use various different environments on a
| daily basis (windows, mac, linux) so being able to access my dev
| environment regardless of what machine I'm on is awesome.
| neilxchen wrote:
| Neil from Nimbus here.
|
| 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!
| rsstack wrote:
| We're Gitpod users and we absolutely love it. Clean environments
| for every feature, fast onboarding, easy multitasking, easy PR
| reviews, great. I also used AWS Cloud9 in the past and GitHub
| Codespaces. I'd also include Stackblitz in the category.
|
| 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.)
| nithayakumar wrote:
| 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 wrote:
| > 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 wrote:
| > 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 wrote:
| > _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 wrote:
| 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.
| gigatexal wrote:
| +1 to this. I came to ask the same questions.
| nithayakumar wrote:
| Answered in the parent comment! But high level - we aim to be
| more like local development and flexible.
| aklarfeld wrote:
| This is awesome - congrats on the launch!!!
| neilxchen wrote:
| thanks!!
| dianaviolet wrote:
| Sound like it could be really useful. Wondering if there will be
| a method to load the remote workspace locally if I need to do
| development without internet (travelling, etc)
| nithayakumar wrote:
| Nish from Nimbus here
|
| 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 :)
| liushh wrote:
| Great question! (Also a tough one)
|
| 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.
| tomasHokali wrote:
| Great product, it's true that there are not many options to
| optimize and make more efficient the day to day of an engineer
| working on small-medium size companies. This product has great
| future.
| neilxchen wrote:
| Thank you for the support!
| erikpukinskis wrote:
| As a Codespaces user, glad to see competition in this space!
| liushh wrote:
| As a Codespaces competitor, glad to see a Codespaces user
| giving us some attention.
|
| Love to see how you like Nimbus and how you feel the difference
| between different alternatives.
| emeraldd wrote:
| What does this support outside of Javascript?
| jeffbee wrote:
| All I really want is to open VSCode and remote into a thing, no
| matter what it is, where my repo is available, and to build my
| bazel targets with remote execution and caching. But at 4x the
| price of EC2 instances I'm honestly not seeing what's being
| offered here or how it helps me.
| nithayakumar wrote:
| We're working on self-hosted right now. When that comes out,
| you'll be able to do exactly what you want without any usage
| fees from us (you'll take on the AWS usage, storage, load
| balancer, and other fees though).
| jedberg wrote:
| I like this idea, but on a side note:
|
| 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.
| neilxchen wrote:
| Neil from the Nimbus here.
|
| 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.
| vyrotek wrote:
| Looks interesting. We're actively looking at Azure DevBox right
| now but we need Macs too. We'll check it out.
|
| https://azure.microsoft.com/en-us/blog/announcing-microsoft-...
| liushh wrote:
| Do you mean having a MacOS on a cloud machine?
| vyrotek wrote:
| Yes!
___________________________________________________________________
(page generated 2022-08-17 23:00 UTC)