Single-Cloud vs. Multi-Cloud for Streaming Workflow Migration
Choosing between single-cloud and multi-cloud strategies is critical when migrating streaming workflows because each offers distinct trade-offs in control, scalability, and vendor dependence. LiveX’s Corey Behnke, Cerberus Tech’s Chris Clarke, and TV2 Denmark’s Loke Dupont make the case for choosing (and limiting yourself to) a single cloud provider when crossing to the cloud side while emphasizing the importance of leveraging specific strengths and services offered by each provider in this clip from May’s Streaming Media Connect.
Stitching It Together
LiveX Co-Founder and Lead Producer Corey Behnke opens the conversation by declaring that as a product manager he gets more requests for multi-cloud and that there are some cloud providers that are more “broadcast-forward” than others. That said, he asks Cerberus Tech Co-Founder and CRO Chris Clarke to explain the benefits of choosing a single provider to start.
Clarke shares that “we are big multi-cloud proponents at Cerberus Tech, but I completely echo what you’re saying: You need to start somewhere. There’s no point in coming out all guns blazing.” He alludes to the one cloud provider that “every single one of us started off” with—“It was the one that offered free credits, free tiers.” He could use it to start building workflows “and just trying to see what sticks,” he says. “[T]hat same cloud provider has then gone on to deploy a very specific set of media-related products that don’t exist in any other cloud platform.”
Based on a conversation Clarke had with that cloud provider, “[O]ne of their biggest issues is people thinking that they are a managed service provider. They’re not. They’re a toolkit provider.” He likens this provider to the Home Depot: “You can go in there and you can choose whatever you want off the shelf, but how you stitch it all together, that’s on you or that’s on a third-party systems integrator or someone who’s going to build a dashboard for you. They provide all of the bits and they work very well. They’re very dependable. They do exactly what they say that they’re going to do, but they’re not … an end-to-end system.” This means “you’ve got to really think about how you are going to stitch it together because the way that you stitch it together is different [from] the person who came before you,” he advises. “But there are easy ways of seeing whether your workflows will work in one cloud over another—just to get started.” There will come a time when you need to think about your approach “outside of any one cloud provider’s offerings, so that in the event that you need to, you can deploy it into another,” Clarke notes.
Two Ways to Come at Multi-Cloud
TV2 Denmark Staff Software Engineer Loke Dupont speaks next, building on Clarke’s comments to agree on starting with one cloud provider and selectively using services from others based on specific needs. He calls out Amazon Web Services (AWS) for doing a lot of work to help enable the stitching together of workflows on different platforms, especially in its acquisition of Elemental Technologies, and it continues to be an area of focus, while Microsoft used to be better about it but let its support fizzle out. Dupont acknowledges that he might be biased because he uses AWS.
“I think for most people, you don’t need to be multi-cloud in the way that some people use that term,” Dupont asserts. “I think there’s two ways of viewing multi-cloud, right? One is that we run the exact same workload on multiple cloud vendors’ platforms.” That doesn’t truly leverage the benefits of the cloud providers, however, because your software and process have to be generic enough to run on everything. Two is what Dupont recommends you do, which is to adapt to each cloud provider’s strengths. This means, for example, using one service from Azure, another from Google, and another from AWS across a solution.
Dupont elaborates, “Of course, you’ve got to be careful about not gaining a lot of dependencies doing that, but sure, if Microsoft has[, for example,] a better service for transcription of video, then use that service there. And it doesn’t mean you have to run your live channel in that same cloud. You can just use that component. That part of multi-cloud, I think, is what a lot of people end up doing very quickly.”
He doesn’t see the benefit to running “the exact same workload with the exact same machines and the exact same cluster across multiple cloud providers.” Dupont continues, “I don’t think there really is a benefit because you’re not going to get a lot more resilience in that if you use a single cloud provider and use multiple regions, and that’s a hell of a lot easier to engineer.”
He’s also not experiencing the vendors “squeezing you for more money,” so it’s not necessary to “hedge bets against one of them,” he adds. Running that same workload across providers is also going to increase operational issues—it’s not worth it to have to double the operations staff, Dupont notes. “Don’t do it unless there’s a very clear reason or unless you’re of course a vendor that needs to operate stuff, depending on which customer cloud preference they are. That’s a different scenario,” he says. “But for most people who are not selling this to others and just running for themselves, stick to one cloud and use mix-and-match services from [other ones] depending on what you need, basically.”
Regional Downtimes and Egress Costs
Dupont’s mention of regions sparks a thought for Behnke: “There’s something I always tell my customers, is that it’s very rare for a cloud provider to go down as an entire service. … It’s typically a regional downtime that occurs. And so a lot of our approach with encoding live events or really important events will be to go to multi-region. I stream to Virginia and Oregon or California and London. And so I do find that that approach is definitely beneficial.”
Another of Dupont’s points made Behnke think of fees from the providers: “[W]hen you were talking about using a service and then using another service—just because I can’t help myself—in my mind was egress cost,” he says. “Microsoft Azure would love nothing more than to use transcription and then send it out, going into another cloud provider, then sending it out. It’s like the egress slope just goes huge [with] ingress and egress.”
Join conference chair Andy Beach and other streaming media experts in person Oct. 6–8 in Santa Monica, CA, for more thought leadership, actionable insights, and lively debate at Streaming Media 2025. Registration is open!
Related Articles
COVID accelerated the push to IP-based streaming workflows for many companies, proving that live streaming at scale via the cloud was possible, although not always in tip-top form. Live streaming has been something we've been covering since this publication started, but here we are looking at content that has traditionally been delivered via production trucks, satellites, and a lot of on-prem resources.
03 Feb 2025
This article offers a primer on how a traditional broadcaster could start to move services to a cloud provider.
07 Jun 2023
By investing in better ways to handle and manage content delivery by IP, organisations can offer greater compatibility instead of locking customers into a proprietary and potentially limiting approach. In the interim, those with IP expertise have a responsibility to ensure interoperability is at the core of decisions that broadcasters are making.
10 Oct 2022