This page contains a Flash digital edition of a book.
50 TVBEurope Cloud for Broadcast


www.tvbeurope.com March 2014


The reality is that a true cloud-based computing architecture should be far more reliable than the traditional broadcast playout system running on-site and backed up by a SQL database


Hard edges in the cloud


In our February issue, Ian Fletcher, Miranda’s CTO of automation and playout, outlined the basics of cloud computing for broadcasters. This month, he goes deeper into the possibilities for broadcast automation that cloud tools offer


IN THE first of this two-part article, I talked about the need to be wary of solutions that come dressed in some of the clothing associated with ‘the cloud’, but which have limited potential because they do not implement a true cloud-computing architecture. The key point to emphasise here


is that if our industry is to benefit from the full, extraordinary potential of cloud computing, it requires vendors to fundamentally re-think and redesign solutions for this new architecture. The industry’s demands for increased agility, more channels, more localisation and more scale can’t be met by simply implementing more of the same technology we already have.


In the beginnings of broadcast


automation, the aim was to produce a system that would unify the control of a large number of physical devices, and deliver realtime commands to execute operations such as switching, starting the video server, and bringing on the graphic. Then, as IT technology


matured, the industry moved towards newer technologies and the channel-in-the box paradigm. The automation system and the device performing the playout became squeezed into one and the same system. At the same time, the needs of the broadcast industry have also grown more complex. Automation has gone from being concerned mainly with list-management and execution to a much more sophisticated set of capabilities. Combining the ‘management’ functionality and the playout functionality in the same unit delivers many advantages, but there are also further gains to be made by separating them in any future architecture designed to deliver a highly scalable and agile solution. On one hand, there is the act of


playing out video clips, bringing on graphics, switching to live sources – all operations that need to be performed with accuracy measured in milliseconds. On the other, there are complex


information management tasks that do not require such deterministic responses. The way you go about designing a frame- accurate playout system is very different from the way you design a business management system. And to take broadcast automation forward into a new generation of capability it makes sense to divide the functionality into two layers – the realtime playout/automation layer, and the management layer. Why? Let’s return to the


natural and justifiable caution broadcasters feel about losing control of the physical machinery and assets of broadcasting. Playout from the cloud does not sound an enticing prospect to most broadcasters. Where is the security over content? How can the cloud deliver with frame- accurate timing?


delegated to individual computer nodes and the management layer can provide global control for any number of them. While the management layer


of the automation system does not require the realtime frame- accurate responses that the playout layer must deliver, it must provide failsafe reliability and very high performance. This is where the unique capabilities provided by true cloud computing are critical, and the automation system of the future must be designed to exploit them to the full. The system needs to make full use of a multi- tenancy cloud environment that can dynamically scale with the load, to service many customers cost-effectively with the same set of computing resources, instead of dedicating computer resources to individual channels or customers.


Fletcher: “The design aim is to get to a point where the system is infinitely scalable and where there is no specific bottleneck when handling very large amounts of traffic”


traditional broadcast playout system running on-site and backed up by a SQL database. At 2am on Sunday when there are no maintenance staff at the broadcast centre and the SQL server falls over, how long will it take to get that traditional system back on air? To make a future automation system bomb-proof, guaranteed messaging and connectivity is essential. Non-deterministic behaviour of the network has to be assumed in the architecture. The public internet is very reliable, but it’s not deterministic, and that’s why you can’t rely on sending


“The industry’s demands for increased agility, more channels, more localisation and more scale can’t be met by simply implementing more of the same technology we already have”


The answer is that you don’t need playout from the cloud. With the two layers of


management and playout separated, we can take full advantage of cloud computing’s potential, while still retaining the vital frame-accurate control over playout that broadcasting is built on. The management layer can be moved to the cloud, where realtime dependency is not critical. The realtime playout component can be designed separately and localised to where the media storage is: in this way it can operate with the high performance and availability demands that broadcasters require. The management system can be made capable of handling large numbers of channels because the computing platform it runs on doesn’t also have to cope with playing them out. Playout can be


The system has to be able to deal with failure — to be ‘stateless’. The architecture has to be proof against the disappearance of any of its computing nodes at any time with no interruption to the service. This kind of resilience already


exists in many cloud-based services and one of the ways of testing true cloud-based systems is by deliberately provoking failure of nodes within them. The in-house system used by Netflix (known as The Chaos Monkey, and now available to other developers) goes through the cloud system randomly switching nodes off to test that the software has been properly designed to deal with that. So while it’s natural for


broadcasters to wonder whether cloud systems can be reliable, the reality is that a true cloud-based computing architecture should be far more reliable than the


effective, it also has to be fast. The typical online shopping experience just won’t do for realtime operations in a broadcast centre. There has to be instant response from the automation environment, and this can be built-in by using web apps within the browser. Web apps exploit the power of modern web browsers to execute quite complex application code within the browser window. With HTML5 and Javascript, rich applications can be built that perform the logic and user interaction directly in realtime within the web browser, while data is transferred separately between the application and the cloud-based system. To deliver the speed of


Ian Fletcher, Miranda


frame-accurate messages around any kind of distributed computing environment. So for the playout functionality you need to use external time references and time- stamping messages to ensure that the right message is processed at the right time by individual nodes within the network. It’s also essential to have guaranteed messaging. A correctly architected cloud-based computing architecture should be able to survive network cables being unplugged while schedules are being edited, and on reconnection the right device must automatically receive the messages that it missed. Any as-run information should also be delivered after any interruption of connectivity, so that there is a clear record of what was played out and when. For the cloud-based


management functionality to be


response the management layer needs, the cloud-based solution must also have a highly efficient back end. If you are designing a system from scratch it’s advantageous to avoid SQL and take a Big Data approach to the architecture, because SQL itself would become a bottleneck and a single point of failure. The design aim is to get to a point where the system is infinitely scalable and where there is no specific bottleneck when handling very large amounts of traffic. Broadcasters’ demands for


increased reliability and agility, more channel numbers, easier localisation, and elasticity of scale can’t be satisfied with more of the same – by cramming more functionality into increasingly complex boxes. Our expectations of automation have changed over the years, and it’s not enough to keep the same concepts and moving parts, even when collapsed together on IT hardware. Vendors that have just applied their existing automation systems to IT based playout hardware are missing the point. It’s time for a rethink.


Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15  |  Page 16  |  Page 17  |  Page 18  |  Page 19  |  Page 20  |  Page 21  |  Page 22  |  Page 23  |  Page 24  |  Page 25  |  Page 26  |  Page 27  |  Page 28  |  Page 29  |  Page 30  |  Page 31  |  Page 32  |  Page 33  |  Page 34  |  Page 35  |  Page 36  |  Page 37  |  Page 38  |  Page 39  |  Page 40  |  Page 41  |  Page 42  |  Page 43  |  Page 44  |  Page 45  |  Page 46  |  Page 47  |  Page 48  |  Page 49  |  Page 50  |  Page 51  |  Page 52