Let’s be honest – Google Colab is solving many challenges. It enables millions of people around the world to learn and use Python and play live with hundreds of libraries for free. It’s quite often for data-oriented use-cases – but not only. To be fair, I discovered the power of notebooks through Google Colab a long time ago.

Notebook? You said notebook?

A notebook is a document which contains code (e.g. Python code), text and images that can be read by us, humans, but also executed inside the notebook. With Jupyter app, it can be launched inside your web browser, allowing you to explore and experiment easily and share your work with many others.

Think of notebooks as cooking recipes that you can follow live, step-by-step and see the result directly. It’s truly wonderful.

Now imagine notebooks that can be linked to remote power and storage to perform your use cases at scale. That’s it 😀

Solutions like Google Colab are nice, but limited

There are plenty of managed notebook solutions on the market today. The market is split in two – complicated solutions inside cloud providers (AWS Sagemaker, Google AI Platform Notebooks, Azure ML Notebooks…) and pure players trying to bring notebooks to the masses. The main actor in this field is Google Colab.

Historically, Google Colab is based on Jupyterlab, and forked from this awesome open source project few years ago (source: their FAQ).

Since mid-2021, they now provide 3 plans in 9 countries, from free to paid (Pro and Pro +).

After browsing their website and FAQ, I drafted this comparative table:

If you are a student or an individual, Google Colab is ideal for you, as most pricing plans contain the basic features you need for exploring this magic world of data. That’s cool.

But once you are working on more intensive projects, you may reach Colab limitations:

• Compute resources are not guaranteed: for example, you don’t know exactly how long and how much you will have GPU power or RAM memory. This is very critical when timing is important (and reproducibility)
• You cannot chose which GPU model will be used: it might be a good one, or an old one like K80
• No background execution except in Pro+: you cannot close your internet browser, or it will automatically stop your work
• Maximum 24 hours time of execution: if you’re running intensive trainings, it’s a serious limitation
• Not official JupyterLab version: the live code editor is based on Jupyterlab, but not the exact open source one. You have some features missing
• Unavailable in multiple countries: quoting their FAQ, “For now, both Colab Pro and Pro+ are only available in the following countries: United States, Canada, Japan, Brazil, Germany, France, India, United Kingdom, and Thailand”
• Requires acceptance of Google ToS: when you use Google Colab, you need to fully accept the Google terms of services and privacy policy. Read them carefully 😃

Seeing their pricing, it’s fully understandable to put some limits.

But what can you do if you want more?

Good news everyone! You have some (simple) alternatives

We are a European company, and if I’m correct, the only one to provide managed notebooks in the cloud with GPU power at scale. We released OVHcloud AI Notebooks a few months ago and it’s really exciting to solve people’s challenges. Based on the current usage, it’s clearly a success (thumbs up to the team behind this new product!).

AI Notebooks = European legislation, guaranteed resources, back-end execution, native Jupyterlab or VSCode editor, no maximum running time, available everywhere… and yet it’s also simple to use.

Go back to the comparative table. You’ll see that we solve many blockers 😃.

To explain further, I’ve made a short video where I start in Google Colab and migrate my work in OVHcloud AI Notebooks. I took my time, explained everything and it lasts 8 minutes. If i wanted to automate it, it should take +-10 seconds.

Want to give it a try? Fearing it’s too expensive?

Our pricing is quite simple: you don’t pay per month, you pay what you consume.

1 CPU is 0,03€ per hour, 1 NVIDIA V100S GPU is 1,75€ per hour.

If you use a notebook with 2 CPUs during 24 hours, it will cost 1,44 euro (0,03 x 2 x 24h).

It’s more expensive compared to Google Colab plans, however it’s not exactly the same product. OVHcloud AI Notebooks offers managed notebooks in the cloud, but with less limitations (our real competitors are AWS Sagemaker or Google AI Platforms).

And we support startups and research! If you are interested, reach our startup program where the whole OVHcloud Public Cloud ecosystem is included (AI tools, K8s, storage, …) up to 100’000 euros.

We also do some philanthropy for schools, open source projects… contact us!

Thanks for reading 😃

Between two major online events, JupyterCon and PyData – both sponsored by OVHcloud – I wanted to share my team’s feedback on our collaboration with Project Jupyter. The partnership, which begun a few years back, is still growing and we are continuing to learn a lot in relation to the open-source experience. 

I’d like to introduce Maël Le Gal, one of our Data & AI DevOps for almost three years. In 2019, Maël was heavily invested in making OVHcloud one of the hosters of Binder Hubs.  

“Joining the multi-cloud Binder Federation and becoming an infrastructure provider of MyBinder.org was a thrilling project! I experienced open collaboration on a new scale. Typically, all the discussions regarding architecture evolution are held publicly within the Binder community on GitHub and additional day-to-day communications – such as operational tasks – are held collectively on Gitter. It’s a very different approach to building a trusting relationships than what we are accustomed to in the IT industry, and I really appreciate it!” , explained Maël.

In hindsight, it was a unique, co-innovation opportunity for OVHcloud to become the first partner of the Binder Federation, and it became even more interesting when the two other partners – Gesis and Turing – joined as well. Thanks to our collaborative methods, we can easily and collectively submit a new feature; once most of the community agrees on the feature, we deploy it on each of the three clouds. 

Maël Le Gal, Data & AI DeVops with OVHcloud, explains the daily collaboration of the Binder Federation.

This is what I wrote about my experience with MyBinder last year: “Working with open source requires a very human-centric mindset to build consensus and deliver progress when everyone has different objectives, priorities, timelines and points of view.” 

2020: scaling projects and accelerating 

Building on this experience, Maël contributed to another hosting initiative for Project Jupyter earlier this year that quickly scaled: NBViewer – the web application behind The Jupyter Notebook Viewer, hosted by OVHcloud.  

“Jupyter was quite happy about our first collaboration and, in March, asked us to replace a previous hosting provider that had disengaged from the open-source community. Because we already had the deployment experience, and methods from Binder, it was a very smooth deployment. We were happy to see that the traffic running on the OVHcloud infrastructure grew from 25% to 100%”, explained Maël. 

Now I’d like to introduce another member of my team: Guillaume Salou, our AI Technical Lead, who’s been working closely with Project Jupyter from the beginning and driving the OVHcloud sponsorhip of the JupyterCon 2020 digital event as an infrastructure donor.  

“We kicked off this project in June with Project Jupyter and NumFOCUS Foundation as well as IBL Education, responsible for the Open EDX deployment at the conference. OVHcloud has offered the underlying infrastructure to host the global event (for the first time fully online) and its educational platform and now we had to deploy it!

The type of infrastructure we’re talking about is, of course, GPUs, coupled with Kubernetes to support all the talks, demos and online experiments that were planned.  

I want to highlight three aspects of this infrastructure that meet Project Jupyter’s requirements: 

• Ability to scale up and down as necessary; 

• Ability to load balance on other cloud providers and the reversibility of our services; 
• Simplified rights management and user account creation based on Openstack.“

This collaboration has steered our efforts towards simplifying features and providing ready-to-use services for the event’s organizers and users; it’s a new milestone in OVHcloud’s AI approach to eliminate all infrastructure set-up and management complexity to facilitate and spread usages.

Guillaume Salou, AI Technical Lead with OVHcloud explains how the collaboration on JupyterCon 2020 has supported internal efforts to simplify the user experience.

To conclude: this partnership with Project Jupyter is here to stay. Thanks a lot to our partner as well as internal teams for making this open and fruitful collaboration a reality!

As you probably know, Jupyter has been a huge enabler of the programming community, with over 140 Kernels supported such as Python, R, Julia, Spark, Sas, Haskell, Ruby, C++, Go, etc…

The Jupyter Project embodies open and collaborative dev communities, both key values in the makeup of our own ecosystem.

In recent years, Jupyter and OVHcloud have worked hand in hand on projects such as Mybinder.org and NbViewer. I would like to thank the Jupyter board and NumFocus for their openness and trust, which has enabled such a successful partnership.

In 2020, we moved further, offering a full year of support for the JupiterCon and helping to contribute to the event’s success.

With the transition to a fully digital experience, COVID-19 travel restrictions are an opportunity not only to reduce travel costs and ease accessibility, but to limit the carbon footprint tied to knowledge sharing within the ecosystem.

With approximately 100,000 weekly users of the mybinder.org public deployment and 3,000 unique git repositories hosting Binder badges, the need for more resources and computing time was felt.

Today, we are thrilled to announce that OVH is now part of the world-wide federation of BinderHubs powering mybinder.org. All traffic to mybinder.org is now split between two BinderHubs – one run by the Binder team, and another run on OVH infrastructure.

So for those who don’t already know mybinder.org, here’s a summary.

What is Jupyter?

Jupyter is an awesome open-source project that allows users to create, visualise and edit interactive notebooks. It supports a lot of popular programming languages such as Python, R and Scala as well as some presentation standards such as markdown, code snippet, charts visualisation…

Example of a local Jupyter Notebook reading a notebook inside the OVH GitHub repository prescience client.

The main use case is the ability to share your work with tons of people,  who can try, use and edit the work directly from their web browser.

Many researchers and professors are now able to work remotely on the same projects, without any infrastructure or environment issues. It’s a major improvement for communities.

Here is for example a notebook (Github project) allowing you to use Machine Learning,  from dataset ingestion to classification:

Example of a Machine Learning Jupyter Notebook

What is JupyterHub?

JupyterHub is an even more awesome open-source project bringing the multi-user feature for Jupyter notebooks. With several pluggable authentication mechanisms (ex: PAM, OAuth), it allows Jupyter notebooks to be spawned on the fly from a centralised infrastructure. Users can then easily share their notebooks and access rights with each other. That makes JupyterHub perfect for companies, classrooms and research labs.

What is BinderHub?

Finally, BinderHub is the cherry on the cake: it allows users to turn any Git repository (such as GitHub) into a collection of interactive Jupyter notebooks with only one click.

Landing page of the binder project

The Binder instance deployed by OVH can be accessed here.

• Just choose a publicly accessible git repository (better if it already contains some Jupyter notebooks).
• Copy the URL of a chosen repository into the correct binder field.
• Click the launch button.
• If it is the first time that binder sees the repository you provide, you will see compilation logs appear. Your repository is being analysed and prepared for the start of a related Jupyter notebook.
• Once the compilation is complete you will be automatically redirected to your dedicated instance.
• You can then start interacting and hacking inside the notebook.
• On the initial binder page you will see a link to share your repository with others.

How does it work?

Tools used by BinderHub

BinderHub connects several services together to provide on-the-fly creation and registry of Docker images. It uses the following tools:

• A cloud provider such as OVH.
• Kubernetes to manage resources on the cloud
• Helm to configure and control Kubernetes.
• Docker to use containers that standardise computing environments.
• A BinderHub UI that users can access to specify Git repos they want built.
• BinderHub to generate Docker images using the URL of a Git repository.
• A Docker registry that hosts container images.
• JupyterHub to deploy temporary containers for users.

What happens when a user clicks a Binder link?

After a user clicks a Binder link, the following chain of events happens:

1. BinderHub resolves the link to the repository.
2. BinderHub determines whether a Docker image already exists for the repository at the latest reference (git commit hash, branch, or tag).
3. If the image doesn’t exist, BinderHub creates a build pod that uses repo2docker to:
   • Fetch the repository associated with the link.
   • Build a Docker container image containing the environment specified in configuration files in the repository.
   • Push that image to a Docker registry, and send the registry information to the BinderHub for future reference.
4. BinderHub sends the Docker image registry to JupyterHub.
5. JupyterHub creates a Kubernetes pod for the user that serves the built Docker image for the repository.
6. JupyterHub monitors the user’s pod for activity, and destroys it after a short period of inactivity.

A diagram of the BinderHub architecture

How we deployed it?

Powered by OVH Kubernetes

One great thing about the Binder project is that it is completely cloud agnostic, you just need a Kubernetes cluster to deploy on.

Kubernetes is one of the best choices to make when it comes to scalability on a micro-services architecture stack. The managed Kubernetes solution is powered by OVH’s Public Cloud instances. With OVH Load Balancers and integrated additional disks, you can host all types of workloads, with total reversibility.

To this end, we used 2 services in the OVH Public Cloud:

• A Kubernetes Cluster today consuming 6 nodes of C2-15 VM instances (it will grow in the future)
• A Docker Registry

We also ordered a specific domain name so that our binder stack could be publicly accessible from anywhere.

Installation of HELM on our new cluster

Once the automatic installation of our Kubernetes cluster was complete we downloaded the administration YAML file allowing us to manage our cluster and to launch kubectl commands on it.

kubectl is the official and most popular tool used to administrate Kubernetes cluster. More information about how to install it can be found here.

The automatic deployment of the full Binder stack is already prepared in the form of Helm package. Helm is a package manager for kubernetes and it needs a client part (helm) and a server part (tiller) to work.

All information about installing helm and tille can be found here.

Configuration of our Helm deployment

With tiller installed on our cluster, everything was ready to automate the deployment of binder in our OVH infrastructure.

The configuration of the helm deployment is pretty straightforward and all the steps have been described by the Binder team here.

Integration into the binderhub CD/CI process

The binder team already had a travis workflow existing for the automation of their test and deployment processes. Everything is transparent and they expose all their configurations (except secrets) on their GitHub project. We just had to integrate with their current workflow and push our specific configuration on their repository.

We then waited for their next launch of their Travis workflow and it worked.

From this moment onward, the ovh stack for binder was running and accessible by anyone from everywhere at this adress: https://ovh.mybinder.org/.

What comes next?

OVH will continue engaging with the data open-source community, and keep building a strong relationship with the Jupyter foundation and more generally the python community.

This first collaborative experience with such a data-driven open-source organisation helped us to establish the best team organisation and management to ensure that both OVH and the community achieve their goals in the best way possible

Working with open source is very different from the industry as it requires a different mindset: very human-centric, where everyone has different objectives, priorities, timeline and points of view that should all be considered.

Special Thanks

We are grateful to the Binder, Jupyter, and QuantStack team for their help, the OVH K8s team for the OVH Managed Kubernetes and OVH Managed Private Registry, and the OVH MLS team for the support. You rock, people!