Let’s be honest, the first wave of the move of broadcast playout to the cloud was not hugely successful.
Early solutions used virtual machines reserved in the cloud and ran existing playout software – so they were not cloud native. As a result, they ended up being unreliable. Cloud costs became excessive, negating the advantages that the cloud had been sold on: resource efficiency, reducing costs, flexibility and scalability.
This resulted in a return to parallel running on premises, and ultimately a fall back to a hybrid model. This created more complexity, increasing costs further and clearly not delivering the costs savings envisioned.
Just like in all product adoption models, you could say this created a ‘bad taste’ in the mouth of the early adopters. A ‘trough of disillusionment’ created a kick back against the cloud, with many broadcasters believing the cloud was not ready and too costly to adopt.
Industry analysts, Devoncroft Partners, commented at a recent conference that the trough is proportionally larger than expected in the case of the cloud adoption rate for broadcasters. The cloud only began the journey up the slope of enlightenment recently, with the high-profile adoption of a few large broadcasters. For example, British broadcaster Sky are now playing out close to 200 channels from their cloud platform.
So what has changed?
Being the pioneers, and the technology behind the Sky platform, BCNEXXT is now leading the second wave. Adoption is growing strongly because finally cloud playout is being ‘done properly.’ This is not a ‘lift and shift’ of existing software onto a VM hosted in the cloud, but cloud-native software and new architectures that deliver 99.9999% reliability, whilst utilizing the advantages of the cloud, such as scalability and business model flexibility , dramatically reducing costs and increasing agility and reliability.
You need look no further than the Amazon website for a good definition:
“Cloud native is the software approach of building, deploying, and managing modern highly scalable, flexible, and resilient applications in cloud computing environments”.
These applications consist of multiple small, interdependent services called microservices which work independently. Using minimal computing resources, microservices are dynamically scaled or multiplied to make applications more or less powerful. They can be updated with fast and frequent changes to meet customer demands without impacting service delivery.
Cloud-native development brings along agile practices like DevOps and continuous delivery (CD). Plus, automated tools enable scalable applications to be built rapidly, which only use resources when needed, making sure resources do not sit idle.
Businesses no longer need to invest in the procurement and maintenance of costly physical infrastructure. This results in long-term savings in operational expenditure. The cost savings of building cloud-native solutions might also benefit your clients.
Companies can build resilient and highly available applications where feature updates do not cause downtime. Resources can easily be scaled up during peak requirements.
The real-world advantages of a cloud-based playout system are numerous and very real, confirmed time and time again by our customers.
Business decisions should be made based on the understanding of available information and the obvious parameters for decisions involving IT resources (broadcasting these days is really IT) is the total cost of ownership, or TCO. The cloud typically drives down costs in two areas:
TCO is usually calculated by aggregating the total costs associated with a function, over a period of time, let’s say a year. In talking with our current and future customers, herein lies the first problem.
Many broadcast departments do not know all their true costs; maybe the building, power (including air conditioning) and their maintenance are in a different budget. Often IT infrastructure and support is budgeted separately. So it’s common for a broadcaster not to know their true total costs for the playout function.
Cloud resources include all these costs. Due to the economies of scale, these hidden expenses are usually much lower than can be provided for on premise.
By making the software driven by exception, easy to use and with fully automated QC, channel to operator ratios can be kept high, in the 40’s and 50’s. Operations can often be run lights out overnight.
In addition, truly cloud-native software is containerized, uses microservices and scales according to use, only using the minimum resources to provide the functionality required. Therefore, it usually uses fewer resources than a hardware build out, best explained by this simple example:
A simple example of resource usage: VM versus cloud native
If a playout system runs on a virtual machine, the compute resource remains at 100% for 24hrs/day, but for file-based content only 15% of the resources are required.
For 3 hrs. of live sports or news in a day, the playout system only needs 100% compute resources for that 3 hrs. of live, the rest is file-based playback, so the math is simple:
The cloud is dynamically scalable. This means compute resources can be added and spun down in minutes, making it ideally suited to the changing complexity of the content in a typical broadcast.
Minimum compute power can be used for file-based content playout. When the channel goes live, resources can be added to provide the compute power required to render complex graphics and DVE moves in real time.
This is very different to a playout server, where the compute power has to meet the requirements for the most complex content and is then underutilized when less complex content is played out.
In turn, this drives pay-as-you-go commercial models that are appealing to a broadcast industry currently trying to save money and become more flexible.
The dynamic scaling ability of the cloud also drives a new level of flexibility.
Pop-up channels for sporting and other premium events can be spun up and shut down in minutes and paid for on a pay-as-you-go basis, providing unheard of agility to start and end new services. All without costly investment in new equipment and support staff.
Cloud resources are fully instrumented and health monitored. This enables the cloud provider to stay ahead of many issues and fix them before they occur, making the environment highly available.
In addition, the global nature of the cloud enables multiple opportunities to architect redundant systems, either across local zones or geographic regions or even on premises in hybrid systems, seamlessly switching between them if an error is detected in one of the streams.
Besides redundancy, multiple other considerations can be used to design robust cloud-based systems:
A correctly architected cloud deployment can be highly reliable, with 6x9’s (plus) availability routinely experienced by users.
Cloud providers support their service 24/7 and as noted above often find and fix errors before they occur, without the requirement for local support personnel.
Detected errors are fixed quickly and efficiently, or due to the scale of the cloud, switched to alternative resources in different zones or regions, usually seamlessl. This brings a level of support and flexibility a single Broadcaster cannot afford in an on-premises environment.
Broadcast playout in the cloud has evolved over the past few years, from early adopters doing a ‘lift and shift’ of existing playout software onto virtual machines booked in the cloud. Newer solutions take full advantage of the efficiency, scalability, flexibility and availability that the cloud environment provides, driving down costs and increasing agility and robustness.
If considering a cloud playout solution, ask the right questions to choose a system that transforms your content distribution in the right way. You should expect increased efficiency, agility and reliability and reduced costs, not the other way around!
Let’s be honest, the first wave of the move of broadcast playout to the cloud was not hugely successful.
Early solutions used virtual machines reserved in the cloud and ran existing playout software – so they were not cloud native. As a result, they ended up being unreliable. Cloud costs became excessive, negating the advantages that the cloud had been sold on: resource efficiency, reducing costs, flexibility and scalability.
This resulted in a return to parallel running on premises, and ultimately a fall back to a hybrid model. This created more complexity, increasing costs further and clearly not delivering the costs savings envisioned.
Just like in all product adoption models, you could say this created a ‘bad taste’ in the mouth of the early adopters. A ‘trough of disillusionment’ created a kick back against the cloud, with many broadcasters believing the cloud was not ready and too costly to adopt.
Industry analysts, Devoncroft Partners, commented at a recent conference that the trough is proportionally larger than expected in the case of the cloud adoption rate for broadcasters. The cloud only began the journey up the slope of enlightenment recently, with the high-profile adoption of a few large broadcasters. For example, British broadcaster Sky are now playing out close to 200 channels from their cloud platform.
So what has changed?
Being the pioneers, and the technology behind the Sky platform, BCNEXXT is now leading the second wave. Adoption is growing strongly because finally cloud playout is being ‘done properly.’ This is not a ‘lift and shift’ of existing software onto a VM hosted in the cloud, but cloud-native software and new architectures that deliver 99.9999% reliability, whilst utilizing the advantages of the cloud, such as scalability and business model flexibility , dramatically reducing costs and increasing agility and reliability.
You need look no further than the Amazon website for a good definition:
“Cloud native is the software approach of building, deploying, and managing modern highly scalable, flexible, and resilient applications in cloud computing environments”.
These applications consist of multiple small, interdependent services called microservices which work independently. Using minimal computing resources, microservices are dynamically scaled or multiplied to make applications more or less powerful. They can be updated with fast and frequent changes to meet customer demands without impacting service delivery.
Cloud-native development brings along agile practices like DevOps and continuous delivery (CD). Plus, automated tools enable scalable applications to be built rapidly, which only use resources when needed, making sure resources do not sit idle.
Businesses no longer need to invest in the procurement and maintenance of costly physical infrastructure. This results in long-term savings in operational expenditure. The cost savings of building cloud-native solutions might also benefit your clients.
Companies can build resilient and highly available applications where feature updates do not cause downtime. Resources can easily be scaled up during peak requirements.
The real-world advantages of a cloud-based playout system are numerous and very real, confirmed time and time again by our customers.
Business decisions should be made based on the understanding of available information and the obvious parameters for decisions involving IT resources (broadcasting these days is really IT) is the total cost of ownership, or TCO. The cloud typically drives down costs in two areas:
TCO is usually calculated by aggregating the total costs associated with a function, over a period of time, let’s say a year. In talking with our current and future customers, herein lies the first problem.
Many broadcast departments do not know all their true costs; maybe the building, power (including air conditioning) and their maintenance are in a different budget. Often IT infrastructure and support is budgeted separately. So it’s common for a broadcaster not to know their true total costs for the playout function.
Cloud resources include all these costs. Due to the economies of scale, these hidden expenses are usually much lower than can be provided for on premise.
By making the software driven by exception, easy to use and with fully automated QC, channel to operator ratios can be kept high, in the 40’s and 50’s. Operations can often be run lights out overnight.
In addition, truly cloud-native software is containerized, uses microservices and scales according to use, only using the minimum resources to provide the functionality required. Therefore, it usually uses fewer resources than a hardware build out, best explained by this simple example:
A simple example of resource usage: VM versus cloud native
If a playout system runs on a virtual machine, the compute resource remains at 100% for 24hrs/day, but for file-based content only 15% of the resources are required.
For 3 hrs. of live sports or news in a day, the playout system only needs 100% compute resources for that 3 hrs. of live, the rest is file-based playback, so the math is simple:
The cloud is dynamically scalable. This means compute resources can be added and spun down in minutes, making it ideally suited to the changing complexity of the content in a typical broadcast.
Minimum compute power can be used for file-based content playout. When the channel goes live, resources can be added to provide the compute power required to render complex graphics and DVE moves in real time.
This is very different to a playout server, where the compute power has to meet the requirements for the most complex content and is then underutilized when less complex content is played out.
In turn, this drives pay-as-you-go commercial models that are appealing to a broadcast industry currently trying to save money and become more flexible.
The dynamic scaling ability of the cloud also drives a new level of flexibility.
Pop-up channels for sporting and other premium events can be spun up and shut down in minutes and paid for on a pay-as-you-go basis, providing unheard of agility to start and end new services. All without costly investment in new equipment and support staff.
Cloud resources are fully instrumented and health monitored. This enables the cloud provider to stay ahead of many issues and fix them before they occur, making the environment highly available.
In addition, the global nature of the cloud enables multiple opportunities to architect redundant systems, either across local zones or geographic regions or even on premises in hybrid systems, seamlessly switching between them if an error is detected in one of the streams.
Besides redundancy, multiple other considerations can be used to design robust cloud-based systems:
A correctly architected cloud deployment can be highly reliable, with 6x9’s (plus) availability routinely experienced by users.
Cloud providers support their service 24/7 and as noted above often find and fix errors before they occur, without the requirement for local support personnel.
Detected errors are fixed quickly and efficiently, or due to the scale of the cloud, switched to alternative resources in different zones or regions, usually seamlessl. This brings a level of support and flexibility a single Broadcaster cannot afford in an on-premises environment.
Broadcast playout in the cloud has evolved over the past few years, from early adopters doing a ‘lift and shift’ of existing playout software onto virtual machines booked in the cloud. Newer solutions take full advantage of the efficiency, scalability, flexibility and availability that the cloud environment provides, driving down costs and increasing agility and robustness.
If considering a cloud playout solution, ask the right questions to choose a system that transforms your content distribution in the right way. You should expect increased efficiency, agility and reliability and reduced costs, not the other way around!
.png)
