2i2c joins the mybinder.org federation with a cheaper and faster way to deploy Binderhub

tl;dr: The 2i2c team is joining the mybinder.org federation with a single-node BinderHub instance at 2i2c.mybinder.org. It should be much cheaper to run than auto-scaling Kubernetes clusters, and might be a good way to support mybinder.org more sustainably. For questions or comments, join this Jupyter Zulip thread.

mybinder.org is a massive public service for creating and sharing reproducible computational environments. It is managed by the JupyterHub team and members of the mybinder.org federation. One challenge in running mybinder.org is identifying cloud credits or financial resources to support the cloud infrastructure that runs the service. Two years ago, Google stopped supporting mybinder.org federation with cloud credits, and last month the federation lost more capacity, leaving only GESIS and OVH as remaining federation members¹. This makes mybinder.org less reliable, slower, and generally less useful to the world.

The landscape of cloud infrastructure technology and services has changed considerably, and we think that there’s a way to deploy BinderHub instances with lower costs and less complexity. We’ve accomplished this by deploying a single-node Kubernetes cluster on a VM provider that is much cheaper, now running at 2i2c.mybinder.org. This both relieves Binder’s short-term capacity shortage and may provide an easier pathway for others to support the project in the future.

Below, we’ll describe what has changed to enable this, what we’re deploying, and what the impact should be.

Cloud infrastructure has become cheaper and more commodified #

A key theory of mybinder.org (and 2i2c) is that commercial cloud infrastructure will be commidified over time – what begins as cutting-edge functionality will become commonplace and offered across all cloud providers. As a result, costs will go down over time. Abstractions like Kubernetes will allow you to easily migrate workflows and infrastructure between cloud providers. As a result, you’ll be able to easily follow those costs where there are better options. That’s essentially what is happening here.

There are two key changes that make it much easier to deploy a BinderHub instance at a fraction of the cost:

First, Kubernetes has matured and become easier to deploy. When mybinder.org started, it was using the cutting-edge of Kubernetes functionality. This meant that we needed to use cloud providers that provided a managed Kubernetes service to deal with this complexity. A managed Kubernetes offering tends to be expensive, offered by only a few cloud providers, and thus raises costs across-the-board for the provider that offers it.

However, this was almost a decade ago, and Kubernetes has become both more functional and more stable. There are now many more ways of running Kubernetes, especially for simpler workflows that don’t require autoscaling. In the last several months, we’ve been experimenting with single-node Kubernetes workflows via K3s². K3s is a lightweight Kubernetes distribution that is much easier to deploy and manage. It’s designed for things like edge computing and low-resource environments, and it can be deployed with a single script!

By running a Kubernetes cluster on a single node, we don’t need a “managed Kubernetes service”, which means we can choose from a much larger pool of infrastructure / cloud providers. If all we need is a running VM, this is something the tech industry has been doing for decades.

Second, Managed Object Storage services have more open source options, and are more commodified and cheaper. In addition to Kubernetes, the other thing that BinderHub needs is a way to store and retrieve images for the environments that it builds. This also used to be a fairly complex problem, and thus required managed solutions from cloud providers that charged a premium for their service. However, a number of open source object storage solutions have emerged and made it much easier for providers to support this workflow.³. Because these are open source, infrastructure providers can provide managed object storage at a fraction of the cost.

Because of these two things, we’ve learned that we can run a BinderHub instance on a single VM from a much larger pool of infrastructure providers. This means we should be able to run BinderHub instances at a fraction of the cost.⁴

Deploying BinderHub on a single-node VM is cheaper and simpler #

Last week, we deployed 2i2c.mybinder.org, a single-node Kubernetes instance on Hetzner cloud using K3s. This will run on a single node VM, with a Kubernetes instance that is entirely managed by us, and with managed object storage from Hetzner. Compared to other cloud providers, it is around 5x cheaper per month.

Running a single-node Kubernetes instance will be a cheap and effective way to handle a lot of mybinder.org’s capacity needs. Because it’s a single node cluster, there is no auto-scaling (one reason it is so cheap), which reduces a lot of the complexity we’ll have to manage. These are acceptable tradeoffs for a service like mybinder.org, which runs entirely ephemeral sessions with very limited resources and no promises about uptime, persistence, etc.

You might be wondering: “I thought Kubernetes was supposed to save money.” Normally, running Kubernetes for scalable workflows does save costs because you can scale infrastructure to match your capacity needs. Without scaling, you’d need to provide a VM that can always handle your maximum capacity needs (and pay for the costs the entire time). With Kubernetes, you can request and remove nodes to grow your capacity as-needed (and save money doing so). It looks something like this:

However, there is a built-in cost you pay when you use a service that provides managed Kubernetes. Managed Kubernetes services are complex and expensive, and this is reflected across-the-board in the provider’s costs. What if we could achieve the same outcome with a much simpler cloud offering like a single VM?

We did a bit of research and discovered that the Kubernetes and object storage landscape has indeed evolved significantly since the early days of mybinder.org. For example, Hetzner is a cloud provider that has been around for a long time. It has single-node VMs that are about 4x cheaper than their counterparts in Google Cloud or AWS, and provides managed object storage that uses MinIO in a cost-effective way. Using K3s, we can run a lightweight, single-node Kubernetes runtime on this node, and deploy a BinderHub with the same infrastructure as any other BinderHub federation member.

By our estimate, we could fit around 400 simultaneous sessions on mybinder.org (because each session uses very few cloud resources). This is already the majority of mybinder.org’s capacity needs, and at a much lower cost than using a scalable Kubernetes cluster. The cost picture looks something like this:

2i2c.mybinder.org now serves 70% of the mybinder.org federation #

About a week ago, we launched 2i2c.mybinder.org running via the methodology we described above. We intended to run this as a longer experiment, but believe that it has already proven useful enough to consider “ready for production”. We recently increased 2i2c.mybinder.org’s load to 70% and will continue to monitor its performance over time. Here’s a plot of where each mybinder.org session has been run over the past ten days - you can see the moment where we turn on 2i2c.mybinder.org to the left:

For now, 2i2c is sponsoring a max of €350 a month (with some currency conversion noise) to run this service. We’ll provide in-kind labor to run this node, and treat it as an organizational investment in supporting open science, as well as learning new Kubernetes and cloud infrastructure workflows. We’re going to use funds recovered from communities in our community hub network, along with in-kind labor to build out this experiment.

In six months, we’ll evaluate how much effort it was to run this node for mybinder.org, whether it meaningfully helped with mybinder.org’s capacity, and whether it was sustainable for us from a time and labor perspective.

Others can join the mybinder.org federation using this approach as well #

We think that developing this single-node BinderHub workflow will make it much easier for others to join the mybinder.org federation, because it lowers the infrastructure and skills complexity needed to join. Here is a brief guide we’ve written for deploying a BinderHub with K3s. We are helping a few interested organizations deploy their own BinderHubs in this way in order to validate the idea, and are hopeful that this makes it much easier to grow mybinder.org’s capacity via new federation members.⁵

We’re excited to experiment with new ways to support mybinder.org. We think this is an excellent example of how open standards and technology lead to cloud workflows with lower costs and more flexibility. We also think it’s a good example of how it is valuable to have organizations aligned with open science (like 2i2c!) acting in this space. If you have any questions or comments, please join this Jupyter Zulip thread

Anybody want to fund this? #

If you’re interested in making open science infrastructure like Binder more scalable and sustainable, we’d love to find more resources to both sustain this node and cover more development time to run this experiment. Feel free to reach out here.

If you have access to VMs and object storage, and are interested in running a mybinder.org federation member using the methods described here, check out our brief guide for deploying a BinderHub with K3s.

If you’re generally interested in supporting mybinder.org with cloud resources, financial resources, or human resources, please see the Support Binder page for how you can help.