Hi, Dan and Genevieve from burstable.ai here. We created a tool called burst to make on-demand cloud compute easy. This lets developers access powerful machines for CPU- and GPU-intensive tasks, with minimal devops overhead.
Using our burst CLI, you can provision a cloud VM (or restart an existing one), sync your code and data, run the task, re-sync the data back, and have the VM stop automatically once the task is done.
We've also added support for running JupyterLab in the cloud, with automatic timeout so you don't accidentally leave expensive machines running overnight (or worse).
burst is an open-source project with a permissive licensing model. We do intend to build a PaaS business leveraging burst (the so-called "open core" business model). However, we are committed to the development of burst itself as a viable FOSS project. Our vision is to make simple cloud devops as transparent as possible for data scientists, ML / AI researchers and the like. With the support of users and contributors, this vision can extend to other domains such as 3D production, video analytics and more.
One of our beta testers, an Astrophysicist/Data Scientist, put it succinctly: when it comes to devops "I treasure my ignorance". Developers who are not pursuing an IT/devops career should have an easy way to provision compute resources---one that is predictable, and consistent across platforms. burst is our first step toward that vision. We’re excited to share it with you.
I use burst with google cloud, and it works great! I especially like the new Jupyter support -- I can actually run emacs in a shell window in the docker container via a Jupyter notebook in the browser, and it works just fine!
Maybe it's a bad habit and breaks the rules of encapsulation, but it sure makes it easy to go in there in the first person, to see what's installed, to look at the input and output and log files, to diagnose what's going wrong, and to hack and debug it with emacs the "old school way", which is a lot easier for me than the typical "hands off" approach to docker development.
It's expensive to rent the big GPUs, so it's useful to go in there and interactively hack the code in real time while it's still running, instead of waiting for yet another docker container rebuild for a tiny little tweak. Then burst syncs my changes back. It also saves money to shut off the server when it's not being used.
> run emacs in a shell window in the docker container via a Jupyter notebook in the browser
I don't know if I'm more disgusted by this unholy accumulation of complexity, or amazed that it actually works well. In any case, we live in awesome times.
This is really awesome. When I was younger, I accidentally kept a gpu AWS instance on for a week or two and racked up $1K+ bill (which Amazon thankfully forgave). Been kinda traumatized and haven’t used any cloud related service since then for personal projects. This might make me try it out again!
Same! Did it with Amazon and they forgive a $200 debt (gotta say something for amazing customer service), did it with Google and they would not forgive a much smaller $40 debt (also gotta say something for terrible customer service I suppose). Will probably turn to AWS and certainly not Google again if I ever need the cloud.
It's good customer service on one hand, terrible customer service on the other hand, in that there should be ways to prevent this from happening in the first place. Waiving charges for those who beg forgiveness reduces the number of public complaints about the lack of planning capacity for cloud service costs. The better solution would be to implement budgeting & cost limiting tools.
> I checked into a hotel yesterday, and will check out this morning. I don’t consider it bad customer service that they want to get paid for that room.
What if you forgot to check out, and the hotel kept charging you for the room until you got a bill at the end of the month? (ie you got a bill for 20 nights).
I know that’s not how hotels work, but it’s how these cloud services work.
I don't disagree that there should be some kind of scheduling or, at least, some kind of cost limitation.
But the hotel is the same thing, right? If you don't check out, and they keep the room empty because they think you're using it, you're still monopolizing the resource.
How can they make the difference between someone who will be back but just happened to spend a few nights away (say using the hotel as a base for trips) and someone who won't be back but forgot to check out?
But I guess, in the case of hotels, you can usually tell them "I'll be here for X days" upfront. Then again, if you change your mind, they won't always reimburse you the cost you've paid.
> But the hotel is the same thing, right? If you don't check out, and they keep the room empty because they think you're using it, you're still monopolizing the resource.
Sure but how easy is it to accidentally book an open-ended hotel room stay?
I'd imagine "not very" because there'd certainly be a huge deposit required and/or proof of finances, etc.
these cloud services intentionally try to get you to make such spending mistakes by not providing an option to set a budget or time limit, or auto shutdown on idle.
i assume AWS learned to target businesses with this shady strategy, which do waste huge amounts of money this way, instead of burning bridges with hobbyist developers over pennies that later will avoid using AWS at the workplace if given the choice.
On Azure if you create a VM, by default it'll be set to auto shutdown at 7pm that night, I think you can turn it off but by default it's on to avoid billshock.
I don't recall this being the case from the time I tried Azure, and can't find anything about it in the documentation. It would leave many people wondering why their instance was turned off.
Perhaps it is a feature of Azure Lab Services, and you were using that?
Just looked it up, apparently it's only happens with ARM (Azure Resource Manager) templates, I usually pick the Ubuntu or Windows server ones which is why it applies the autoshutdown rule.
As the sibling said, I don't remember seeing that. I don't usually use Azure, so when I last started a VM there a few months ago I didn't do any special config, and the VM kept on running forever, as expected.
And there are no policies set up by someone else that I don't know about, we don't usually use Azure for VMs.
Please consider adding an FAQ about how it compares to "native" AWS offerings, because it resembles a few of them.
E.g. Lambda ("run your code" without "start a cloud server" and "turn it off"), ECS (runs containers, can run a standalone task too), Fargate, Batch... The "running JupyterLab in the cloud, with automatic timeout" use case is supported by AWS Sagemaker.
Lambda has currently a limit of 15 minutes as far as I can remember.
I was considering it for a very cost efficient way to scale our multiplayer backend in VRWorkout (dynamically spin up room servers as needed) since it all fits in a single python module. But with the 15 minute limit it's not an option.
I would not even need data syncing since it talks to the main server and does not have state. But it would need to be reachable on a public IP
Lambda indeed is not the right tool for this. It sounds like you need some infra that can auto scale - there are many ways to do it on AWS (EC2 auto scaling, ECS, EKS), any other cloud provider, with Kubernetes...
yes, probably, but then we are back where I need to put a lot more effort into it than I wanted to at this stage.
I really only need to cover burst usage since an average VRWorkout session is only ~10-20 minutes anyway and with players being distributed around the world there is usually no need to boost the available resources.
That's a problem I would like to have down the road when we have millions of people doing VR fitness though :)
How does this compare to https://spotty.cloud ? That's a very convenient open-source tool for provisioning (spot and reserved) instances, and syncing your data to and from it.
I find the documentation to be missing a short overview of the architecture or the conceptual model. It only has step-by-step instructions, and it's not entirely clear what really happens underneath each command. I can guess it is building docker images and sending them to the VM but i'm not really sure if and when that happens.
Seems pretty similar to a couple of things, not least terra (although that is nominally more biology focused). Where terra allows setting up pipelines for data as well
All of the major clouds have stop/start for this same purpose. It is left as an exercise for the user to trigger and run a command based on work completion.
Beyond that they have dedicated service offerings for this kind of compute. Severless, managed service to execute specific framework, etc. Like I don't see how this is anything less than a feature-light sagemaker notebook.
Name is pretty good. But I suggest "cloudburst" -- both for the rain association, the obvious overlap with your business, and (I think) in some Asian languages it's associated or with or a euphemism for orgasm.
Haha, well that might be too obvious a reference? Stepping on people's taboos or prudishness? Some euphemism can be helpful :)
You know, it's like association with something that is positive, a peak experience, as well as connoting maybe something a little fun and naughty, but nevertheless something we all share. Like poop, but with a good valence.
Thanks for pointing this out. Is it considered standard practice for websites to ignore unrecognized query parameters? Disclaimer: I'm not a front-end engineer; we put the site up in a bit of a hurry, using the framework I usually use for REST API's, where typically you want to error out if given unknown query strings.
At my previous startup I often had to spin up high powered Windows machines for the MechEs to run their solidworks simulations. It was always a hassle and they never remembered to turn them off when they were done. IIRC they cost about $30/hour and that adds up if you forget and leave it running over the weekend.
I would have definitely used a service like yours if it supported solidworks simulations. Especially if it auto timed out.
Great question. Initially we have focused on the Python ecosystem but we certainly don't want to stop there. Jupyterlab (which we have integrated support for) claims to support 100+ languages. While our infrastructure code is written in Python, we present a CLI which is language-agnostic. We depend on Docker to virtualize the environment, but again that is not tied to Python.
If somebody wants to do some coding and testing of non-Python languages, we would certainly support the effort as best we can.
This is pretty neat. I saw that Docker is required on the local side; what's that for? (My understanding is that it sets up Docker on the remote server and build the container using the project's Dockerfile.)
This is awesome, I have been searching for a tool like this as recently as a couple of months and have been baffled to always come up empty.
Thankyou and good luck!
It appears I misunderstood the service. This isn't actually a cloud service, these are tools to facilitate the use of your own cloud services it appears..
Using our burst CLI, you can provision a cloud VM (or restart an existing one), sync your code and data, run the task, re-sync the data back, and have the VM stop automatically once the task is done.
We've also added support for running JupyterLab in the cloud, with automatic timeout so you don't accidentally leave expensive machines running overnight (or worse).
burst is an open-source project with a permissive licensing model. We do intend to build a PaaS business leveraging burst (the so-called "open core" business model). However, we are committed to the development of burst itself as a viable FOSS project. Our vision is to make simple cloud devops as transparent as possible for data scientists, ML / AI researchers and the like. With the support of users and contributors, this vision can extend to other domains such as 3D production, video analytics and more.
One of our beta testers, an Astrophysicist/Data Scientist, put it succinctly: when it comes to devops "I treasure my ignorance". Developers who are not pursuing an IT/devops career should have an easy way to provision compute resources---one that is predictable, and consistent across platforms. burst is our first step toward that vision. We’re excited to share it with you.