There is definitely a role for cloud in our broadcast operations, but not all roles are ideal in a cloud ecosystem. Brick Eksten shares some ideal and not-so-ideal cloud scenarios.
The media industry has been talking about the cloud for a few years. Now is a good time to take a look at what can be done in the cloud, where the practical advantages lie, and what new possibilities have opened up.
First, should you move your media to the cloud? As always, it depends on the size and nature of your business. But in general, your content is the number one asset of your business Ā and you know you have to protect that asset. You must ask yourself two questions: am I able to guarantee the safety and integrity of my content on my own; and is it more efficient to put those assets into a storage pool in the cloud?
On the one hand, there is nothing magical about the cloud: service providers use exactly the same commodity hardware that you can buy. If you are confident in managing performance and sorting your own geo-diversity, then you may as well buy your own system. You can probably buy the hardware for the same sort of price as the cloud vendors, so you would save their added margin if nothing else.
But once you start to factor in things like the duplication of IT and network resources, overall management and lifecycle care, then cloud gets a lot closer in cost to owning it yourself. And cloud will always be the most secure option Ā even if your building burns down, your assets will still be pretty safe in the cloud.
Geo-diversity is an important point to bear in mind, and not just for resilience. If you are delivering content beyond your own immediate area, then it can actually be cheaper to put it in the cloud. If you are a national broadcaster moving content between your own facilities, it is probably more cost-efficient to do it yourself.
Total cost of ownership
Keep in mind total costs: facilities, power, cooling, leased lines to storage, the space your kit occupies. Most people, when they think about cloud, only compare storage costs; they donĀt really compare the IT overheads. The backbone of cloud value is really high-scale IT automation and top-tier security Ā what is that worth to you?
Recently, an Imagine customer told us that they had analysed their network and found that 80% of their equipment only runs 20% of the time Ā four-fifths of the network only working one-fifth of the time. If you think that power and cooling is 30% of your operational overhead, that is a lot of money you could transfer to more creative tasks.
What should you put in the cloud? Anything up to and including scheduled playout. Anything to do with the distribution of scale. If you are playing out a channel, then cloud should be at the top of your list. If, however, you are involved in live production, then cloud probably isnĀt the right fit today. We have done proofs of concept of live production in the cloud, but it tends to be very application-specific.
It is often said that cloud is for peaky demand, but how many broadcast companies actually have peaks in their internal processes? They tend to do the same thing day in, day out. Except for specific, large-scale events, they are not really changing scope. The only peaks for a typical broadcaster might be when a new set of stations or a library is acquired.
For me, the issue is the inverse of peak: services that you only run occasionally, and you ask yourself whether itĀs really worth owning the equipment for that. Why am I giving rack space, power and cooling to something I only use three times a week? Better to put it in the cloud.
Microservices
We are all aware that the cloud depends on virtualisation, but we also need to be aware that cloud providers are primarily serving IT customers and do not really provide specific functionality for media organisations. You cannot forklift desktop playout to the cloud.
Across the IT industry, the virtualisation trend depends on microservices, and the media industry has to follow suit. This is about getting an optimised deployment plan based around a technology set that is lighter weight and more agile than traditional software. We see more and more broadcasters coming up to speed on microservices: what the design philosophy is and what it can do for them. We are seeing more articles in the press about this, but there is still a way to go on both the education and the adoption side.
We are now getting customers who have their heads wrapped around the notion not only of microservices, but also of the importance of ĀpureĀ microservices. Can I run this in a container without a virtual machine? Can it really meet my requirements for flexibility? Microservices may be the answer. Microservices mean services can run on any standard COTS platform: in a dedicated appliance, in the machine room, in a corporate data centre or in the cloud. Marketing people always then add that your system could run in a hybrid of multiple locations.
The modern take on hybrid systems is the notion of edge computing. What we are really saying is that there is a role for cloud and there is a role for other things that donĀt fit in the cloud, whether they are too small, too specific or the performance just doesnĀt fit right.
We have major broadcast customers who have part of the content chain in the studio in downtown Manhattan and part in a cloud data centre elsewhere. There is an appropriateness to each, so it is about locality: the things that can be put in the cloud probably belong in the cloud. This sort of hybrid solution is practical.
With an increase in education and awareness of real cloud technologies such as microservices, and an increase in the number of deployments, there is a next-step requirement from the industry to agree on how all these systems are going to inter-operate. WeĀve done that for the network with the Alliance for IP Media Solutions (AIMS) and with SMPTE ST 2110, but the opportunity is to bring those same efficiencies to the computer itself.
There are ongoing efforts in SMPTE with the media microservices standard, and there are other efforts in other professional bodies. The risk is that individual vendors develop their own platform, but at some point we have to get to a place when we can connect services. As computers get faster, the natural evolution for interconnectivity is to do it inside the computer, not in a network Ā do it in memory.
