By Peter Hajittofi, CEO, coralbay.tv
Over the last decade or so, many linear TV channels have been migrated to the cloud. But has this move been successful? Have expectations been fulfilled? What lessons have been learned?
Unfortunately the answers to the first two questions are not a simple yes or no. It really depends on what we mean by “cloud”, what we mean by “successful” and what the expectations were in the first place.
Public vs Private Clouds: Choosing the Right Infrastructure for Broadcasting
For some, the cloud means public clouds such as AWS, Microsoft Azure or Google Cloud, whilst for others it means private clouds or private data centers. Many broadcasters moved channels to the cloud to save costs and to reduce the risk of new channel launches by avoiding large capital spending at the beginning of the project. There were also perceived operational advantages, such as being able to control channels from a web browser, being able to launch channels quickly and easily as well as being able to easily shut down channels which are no longer needed. There is also the additional redundancy and resilience that the cloud offers.
But to properly assess whether a move to the cloud has been successful, you have to look at what the objectives were. If it was only to save costs, then unfortunately not all broadcasters have achieved that goal. In some cases, the failure to meet goals was affected by what playout system was chosen, where it was hosted and what channel types were migrated to the cloud.
To get the maximum advantage of hosting in the cloud, the playout solutionhas to be cloud native. An older product designed as a real time system for on premises dedicated hardware might run in the cloud, but it won’t utilize its full power. Also, it will be inefficient in resource usage and expensive to operate.
A modern cloud-native product is designed using microservices, containers, and orchestration. Rather than one large monolithic application, there are a large number of smaller services that run in containers and are deployed and orchestrated by an orchestration layer, such as Kubernetes. The advantage is that you get the resilience and elasticity that the orchestration provides. For example, Kubernetes will automatically detect and restart failed containers allowing services to recover from failures very quickly. In other words, self-healing. Cloud platforms can also detect failures at the hardware and OS level, automatically replacing failed hosts while Kubernetes reschedules the services onto healthy hosts, minimizing service disruption. Advanced monitoring tools are used to notify engineers when these failures occur so they can investigate and take appropriate action.
The Benefits of Microservices and Incremental Upgrades in Cloud Playout
There are other benefits too – software upgrades are much easier and less risky. Using microservices has changed the way software releases are managed. Rather thanone or two large software releases per year, it is possible to release software incrementally, which greatly reduces the risk of doing upgrades and customers receive the software sooner. It is now possible to upgrade only the services that are affected by any software changes made and most upgrades can be done whilst the software is running. It’s also possible to roll back easily if any issues are encountered with the new version.
Running playout in public clouds does offer potential cost savings. You don’t need to invest in expensive on-premises hardware or budget for its maintenance. You also don’t need the equipment rooms, the air-conditioning, lighting and the personnel to manage all the infrastructure. Instead, the software is spun up in the cloud and configured to meet the needs of the channel. This includes setting up the bit rates, frame rates, formats, graphics, subtitling, I/O and so on.
It is very easy to launch new channels. Some systems can actually deploy new channels in minutes. Compare that to several weeks, if not months of planning, rack layouts, wiring, commissioning and so on as it used to be done with older on-premises systems.
It’s also just as easy to decommission channels when they are no longer required. This means you only have to pay for infrastructure that you use and not what you don’t use. This greatly reduces the risk of new channel launches.
The Flexibility of Pay-As-You-Go Licensing for Broadcasters
Some vendors offer both Pay-As-You-Go (PAYG) pricing and perpetual licensing to provide the optimum cost saving. Customers can choose the best licensing model for each channel; PAYG for channels which may have a short life or perpetual licensing for those channels that are expected to be more permanent. PAYG licensing is ideal for Pop up channels and for Disaster recovery (or business continuity).
However, established broadcasters may have long building leases and are already committed to space and on-premises equipment for several years. So when a cost comparison is done, it doesn’t always stack up if you don’t factor in all the space savings and associated costs. That is one of the reasons why coralbay.tv has designed its products to operate both on premises and in the cloud. In fact hybrid solutions are also possible, where some channels can be hosted in the cloud and others on premises, all with the same user interface and workflows. Edge solutionsare also possible and can offer savings in distribution costs.
Ensuring Resilience in Cloud Playout: From Redundancy to Multi-Region Deployment
Although the cloud offers many benefits you still need a well-architected product to provide the feature range and the high reliability expected by today’s broadcasters. A good product will be architected to provide additional resilience over and above what the orchestration provides. All mission critical components, such as the database, message bus, core automation services and video pipelines need to be replicated for redundancy. The outputs from the video pipelines can be fed to a downstream product, which monitors the output of the main and backup pipeline and can switch automatically if one was to fail. For added resilience it is also possible to deploy the system across multiple availability zones, so if one cloud zone was to fail, playout would continue from the other zone. And for those that want even greater resilience, it is also possible to go one step further and deploy systems across multiple regions.
How to Handle Live Event Broadcasting in the Cloud: Challenges and Solutions
One other important factor when selecting a cloud playout system is live event handling. In traditional SDI on-premises playout systems, handling live inputs is quite straightforward. An automation system only needs to control a router or master control switcher and switch to a live source when a live event is scheduled. These events typically have undefined durations as it is impossible to predict exactly when a live event will end. Commercials or other events can be played during the live event and when the live event ends the operator presses the “next” button and the playlist moves on to play the next video event in the schedule.
There are no delays to be concerned about and the operator can view the output in real time and make decisions on when to move on in the schedule easily. In the cloud things are different. The inputs and outputs are normally compressed transport streams and there are encoding delays. Switching isn’t that easy either – you can’t just switch instantly to a new IP address and make a frame accurate transition between transport streams. So how then can live events be handled reliably in the cloud?
Efficient method of switching between multiple sources in a playout system
Any serious playout system needs to be able to switch between multiple sources as there is often a need to switch from one live feed to another. To handle multiple inputs in the cloud, it is possible to decode multiple sources at the same time and the video sources for these to be fed to the input of the video pipeline’s internal software router. If a switch from one live source to another is required the video source(s) is already decoded and a frame accurate switch can then be made.
To make life easier for the operator, the live input feeds (as well as the channel output) can be monitored. Rather than make the decision on when to switch out of live events by monitoring the delayed output, it is possible to view the input and make the decision based on that. The output encoding delay is then not a significant factor.
Reducing Latency
To reduce delays and make things even easier, low latency monitoring can be used, such as webRTC. And for those wanting high quality video with minimal delays, formats such as JPEX-XS, NDI or 2110 can be used, although 2110 could be prohibitively expensive in the cloud. AWS’s CDI is a more realistic alternative when working in the cloud.
But there is more to managing live events. It is also a requirement to be able to manually control events during a live event. This could be to trigger commercial breaks or it may be to control a logo or other graphic manually. coralPlay enables users to set up and control these functions using manual control panels in the UI. So during a live event, such as a cricket match, it is easy to bring up a graphic manually or to play a commercial.
Conclusion
For many broadcasters, the move to the cloud has been successful. The cloud has offered cost savings and has reduced the risk of new channel launches by moving to an Opex rather than Capex cost model. It has also offered greater elasticity, allowing for systems to scale up and down to match demand. Broadcasters have also benefited from the additional resilience and self healing that cloud offers. However, not all who have moved to the cloud have benefited from the advantages the cloud offers. One lesson to be learned is that to run efficiently in the cloud, the playout system has to be cloud native and it has to have the features you need, especially around live event handling. It is also important to carefully considerwhat you need from your cloud hosting, as costs and features differ between cloud service providers.
Coralbay.tv will be exhibiting at IBC on stand no 7.A09e.
