MovieLabs is a film and television research nonprofit that helped amplify the entertainment industry’s interest in cloud adoption three years ago with a single whitepaper. It contained a ten-year technology roadmap for the progressive integration of cloud-based technology in content production. At the time, its premise seemed cutting-edge, and many studios began to look at the cloud more closely, penciling it into their development timelines. Then, the pandemic struck and live action production temporarily shuttered. The unprecedented extended pause prompted a reevaluation of traditional workflow approaches and a move toward those that better support remote collaboration. The cloud has been a key component of remote workflows, and its role in rendering continues to grow alongside demand for content.
Cloud rendering at a glance
As an invaluable production resource that allows studios to work with greater flexibility and scale, cloud-based rendering has received a lot of attention for its ability to provide on-demand compute resources. The functionality also can be leveraged relatively easily alongside existing infrastructure and without a pipeline overhaul. Having powerful compute resources available on a pay-per-use basis allows artists and studios to run renders that would otherwise require expensive upfront hardware purchases. Using the cloud to render also allows running jobs in parallel, meaning that the entire job can be rendered in the time it takes to render the scene’s longest frame. This accelerated return time allows artists to make more iterations and continue refining the work closer to delivery deadlines.
Scalability inhibitors
However, with all the enthusiasm for the benefits of cloud-based rendering, logistical hurdles are often glossed over. The cloud can be viewed as an all-encompassing resource that’s freely accessed once pipelines have been securely established with the chosen provider. In reality, cloud providers set up groups of data centers, also called regions, and users typically work within one region at a time. The selected region will generally be the one closest to the user to minimize data transfer times and latency. This means that there will be disproportionate demand from areas with historically large studio bases, such as Los Angeles, New York, London, Vancouver, Sydney, etc. When demand exceeds capacity in a geographic region, studios can tap into another region, but switching over can be a manual, time-consuming process that entails trial-and-error – not an ideal approach during a render crunch with a looming deadline.
Backend load balancing
Switching between cloud regions to secure the necessary compute resources is referred to as backend load balancing, and this feature is automated in Conductor cloud platform, which can be used with either Amazon Web Services (AWS) or Google Cloud Platform (GCP). Conductor users select their desired virtual machine type from a list of more than a hundred different configurations, with various GPU and CPU offerings. Then Conductor’s proprietary placement technology proactively evaluates data center capacity for the user’s selected cloud provider across regions, so that when an artist submits a render, they don’t have to worry about a job failing due to resource availability. Since cloud-based rendering isn’t dependent on latency, jobs can easily and securely be sent halfway around the world, and returned to artists as quickly as they’d like. Conductor pricing includes data egress, so the cost to render a job remains the same if it’s run through a region close-by or across the globe.
Faster returns with smaller budgets
Along with gathering and analyzing real-time metrics from data centers, Conductor’s placement technology also assesses the likelihood of resource pre-emptibility. Preemptible instances (on GCP), also known as Spot Instances on AWS, are significantly cheaper than standard cloud-based compute resources, but their availability isn’t guaranteed. This means that the resources can be taken away by the cloud provider for a higher paying customer, which would cause a render job to be disrupted. By helping to minimize this, Conductor allows users to leverage cost-effective preemptible instances at relatively low risk. All these functions are done automatically in the background, with Conductor helping to inform intelligent decisions for optimizing render performance based on parameters set by users.
If you would like to have a chat with one of the team about this article, and to get the most out of your rendering - click here!
Comments