The challenge behind a fully managed service

Readers unfamiliar with our orchestration service and/or GPUs may be surprised that we did not yet offer this integration in general availability. This lies in the fact that our team is focused on providing a totally managed experience, including patching the OS (Operating System) and Kubelet of each Node each time it is required. To achieve this goal, we have built and maintained a single hardened image for the dozens of flavors, in each of the 10+ regions.
Based on the experience of selected beta users, we found that this approach doesn’t always work for use cases that require a very specific NVIDIA driver configuration. Working with our technical partners at NVIDIA, we found a solution to leverage GPUs is a simple way that allows fine tuning such as the CUDA configuration for example.

NVIDIA to the rescue

This Keep-It-Simple-Stupid (KISS) solution relies on the great work of NVIDIA building and maintaining an official NVIDIA GPU operator. The Apache 2.0 licensed software uses the operator framework within Kubernetes. It does this to automate the management of all NVIDIA software components needed to use GPUs, such as NVIDIA drivers, Kubernetes device plugin for GPUs, and others.

We ensured it was compliant with our fully maintained Operating System (OS), based on a recent Ubuntu LTS version. After testing it, we documented how to use it on our Managed Kubernetes Service. We appreciate that this solution leverages an open source software that you can use on any compatible NVIDIA hardware. This allows you to guarantee consistent behavior in hybrid or multicloud scenarios, aligned with our SMART motto.

Here is an illustration describing the shared responsibility model of the stack:

All our OVHcloud Public customers can now leverage the feature, adding a GPU node pool to any of their existing or new clusters. This can be done in the regions where both Kubernetes and T1 or T2 instances are available: GRA5, GRA7 and GRA9 (France), DE1 (Germany) (available in the upcoming weeks) and BHS5 (Canada) at the date this blog post is published.
Note that GPUs worker nodes are compatible with all features released, including vRack technology and cluster autoscaling for example.

Having Kubernetes clusters with GPU options means deploying typical AI/ML applications, such as Kubeflow, MLFlow, JupyterHub, NVIDIA NGC is easy and flexible. Do not hesitate to discuss this feature with other Kubernetes users on our Gitter Channel. You may also have a look to our fully managed AI Notebook or AI training services for even simpler out-of-the box experience and per-minute pricing!

Public Cloud : our fastest evolving set of services

Offering Baremetal services and Web Hosting for now more than 20 years, OVH launched its Public Cloud ecosystem 5 years ago. After a focus on infrastructure (computing instances, object storage and networking capabilities), we added nearly 30 different services, from managed Kubernetes to Big Data and Machine Learning. We plan to deliver a couple more in the upcoming year (databases, filesystem , baremetal …).

Each service regularly gets new capabilities, either from opensource technologies they are based on or through OVHcloud specific added value. This translates into dozens of features and improvements every year. For example recently, we launched automated backups for your virtual machines, nodepools & anti-affinity management for Kubernetes… We also will soon enable vRack (private networking) to Kubernetes and other services…

Finally, we upgrade the different softwares to always guarantee stability and security for your services. We also expand them to all our datacenters. For example, we offer the recent releases of major Linux distributions, enabled Kubernetes 1.19 a couple of weeks ago. We also recently made this service available in our Polish, Australian and Singaporean regions.

All this makes it challenging for our customers to be always up-to-date on how they can use all the value brought by this dozens of products together. The numerous questions following our public cloud session at OVHcloud annual event confirmed this challenged needed to be adressed.

Moving forward with total #Transparency

After checking the best practices in the IaaS, PaaS and SaaS industry, we agreed on sharing a macro view of our features backlog. We found the agile roadmap format a ideal compromise between clarity and usability. We iterated with multiple customer-facing colleagues (presales teams, technical account managers…) to adjust on the format. You can now consult it as a dedicated repository on the existing OVHcloud GitHub page : https://github.com/ovh/public-cloud-roadmap .

This artifact is a new proof of our “S.M.A.R.T.” cloud Transparency value. For years, our customers recognize us for sharing any planned tasks and incidents on the good old travaux.ovh.net (spoiler : this will go through a major revamp in 2021 for more clarity and usability). OVHcloud is also proud of our “1 page and no hiden fees” and totally predictable public cloud pricing scheme.

Publishing our changelog, but also allowing customers to view and participate publicly on our backlog prioritization was the logicial next step. This roadmap remains indicative (and we may surprise you with additionnal strategic features that we choose to keep confidential). We will also share more precise E.T.A. in specific item, as soon as we are confident enough to do so.

How to consult and contribute

Anyone can consult the board of his choice on https://github.com/ovh/public-cloud-roadmap/projects . You will find out the current features planned in the backlog and some details on how to use those improvments.

After loging in with a free GitHub account, one can subscribe to a given feature to get email notifications when it is modified or moves forward. Loged-in users can also comment or vote for listed features to influence our specifications and prioritization.

Finally, a user can suggest a new issue to the backlog . We will consider new issues within a week and, and they may enter one of the board’s Backlog if they align with our product strategy. We regularly commit to new items on the backlog. “Committed/Being developped” column means that the feature has been sized and is planned for the next 3 to 12 months. When these elements approach production, they are moved to “Coming soon“. At that stage, specifications are final, and the feature will hit GA usually in less than 2 months, some times we will details how you can get early access before general availability.

Help us by challenging the content and our priorities !

Do you feel a specific Item is unclear ? Underprioritized ? Feel free to upvote it or comment and raise questions! As in any Agile approach, your feedback will make this grow and bring back more value to all our users.