Related content:

Cloud computing refines many previously existing technologies to improve flexibility and robustness. The services run in virtualized containers managed by a built-in supervisor. They are extremely scalable on a demand driven basis. The supervisor creates additional resources when necessary.

Instead of hardware, everything is presented as software dashboards in a web-page. These might be wrapped in a specialized application containing a web-view.

Cloud computing infrastructures are easier to understand if they are examined from several perspectives. Think about these questions:

• Do you want hosted or self-managed installations?
• Should they be deployed in your own data center (either on-premise or in an off-site location) or in the public cloud?
• What level of service, platform or infrastructure will be supported in the ‘cloud’ and what runs locally at the point of use?

Let’s look at the alternatives for Private vs. Public-cloud scenarios first. Then determine an appropriate threshold to separate in-house workflow processes from the public cloud services.

We mention Kubernetes often, but there are other alternative cloud computing orchestration packages. Kubernetes is already very widely adopted.

Evolution & Provenance

Cloud computing aggregates file sharing, large-scale storage, service listeners, web-servers, scheduled execution and security layers into a managed and coherent whole. Previously, they would have been managed individually by a sys-admin team. Admin tools such as Plesk that automate the deployment of web-sites have been around for a long time. Cloud dashboards for broadcasters are just an extension of the same concept.

Adding a layer of management and control simplifies the maintenance of multiple software products. Configuration parameters should be specified just once and propagated globally. Documentation helps, but it cannot completely eliminate human error.

Developers like to conjure up obscure new ‘buzzwords’ and terminologies. Unpack them to see how they are based on existing techniques used in a new way. This is nothing to be afraid of.

Advantages Of Cloud Compute Based Workflows

Cloud compute solutions need not disrupt your existing workflows. The underpinnings are different but editing footage, composing VFX overlays, compositing and conforming content into finished programs is still a familiar working pattern. The major advantages of a cloud compute based workflow are:

Virtualization - Facilitates rapid deployment and resilience by redundancy. Load balancing and resource allocation are more robust.

Containers - Containerized CPU images managed with Kubernetes (or similar tools) takes the idea further and facilitates a software driven configuration.

Scalability - Kubernetes replicates additional copies of managed containers carrying processing services on demand.

Access - Subject to security protections, the workflow is accessible from remote locations via IP connections. Outside broadcast feeds can integrate with the core processes back at HQ behaving as if they were local and onsite.

Easier post production process management - Process loading can flex according to the priority and needs of the workflow. Content and VFX editing by humans may be a priority during the day. Rendering the final output happens overnight on the desktop machines freed up by the off-duty staff.

More effective collaboration within and between multiple teams - Because the storage is managed centrally, access control determines who can see and manipulate the assets. Users are granted rights to access content from the central store. Collaborative working is facilitated but also easily managed.

Better consumer cross platform support - Sport is the most extreme and demanding broadcasting category. It needs:

• Multiple simultaneous viewing angles.
• A lot of statistical data based on past performance.
• Instantaneous replays.
• Graphical overlays to illustrate strategy and tactical game play.

The outgoing broadcast needs to orchestrate all of them to build a user experience for multiple viewing devices. VR headsets add to the complexity but also provide a very rich user experience.

Customizing the user experience - Delivering content simultaneously to multiple regional territories requires carefully managed advert insertion. Stream splicing inserts suitable adverts based on user profiles or regional factors. This might happen in edge servers. Metadata manages the advertising assets and deploys them across the available real-estate.

Monitoring and analytics of throughput and consumption - Logging asset movements and processes will record the events. Distil that metadata for wall mounted displays of the asset dispositions. Productivity metrics are available by analyzing the logs. Resource bottlenecks and configuration problems are alerted well before they become critical.

Compliance recording - Clone the outgoing streams and record them at a lower resolution on auxiliary storage.

Fine grained control over distribution and syndication - Content assets are packaged with their supporting resources and tagged for onward transmission to your syndication partners. The delivery specifications steer and automate the whole process. A package is delivered onwards only when all the component parts are checked-in.

Easier monetization on a regional or global basis - Metadata describing where assets can be distributed offers only the appropriate products to your customers. Once they purchase, invoicing and tracking incoming payments is easily automated.

Rapid rollout of new channels and portals - Channels are a legacy concept based on appointment viewing patterns. Use metadata to construct content manifests to launch new portals with minimal effort. An asset genre tag just requires a box to be ticked in your dashboard for that genre to be offered in the client user interface.

Disaster recovery, failover and redundancy - Kubernetes manages virtualized containers that are restarted automatically if they crash. If an entire server goes down, the containers are floated across to backup hardware with no apparent interruptions. Shared storage is centralized on RAID disk arrays. A failed disk is hot swapped as soon as it is detected. Complete disaster recovery is possible by replicating the storage and cloud configuration in an alternative offsite location to be brought up on demand during a complete data center collapse.

Cloud Compute Implementation Models

Cloud compute services can be implemented on public infrastructure shared by many different organizations or on a private on-premise infrastructure running in your own data center which is not shared with anyone else. There are a variety of architectural approaches available:

• Monolithic servers.
• Public-cloud.
• Private-cloud.
• Hybrid-cloud.
• Community-cloud.
• Multi-cloud.

Monolithic Servers

Existing monolithic on-premise servers are still a viable solution for some tasks. Not everything needs to be cloud-based. Provide these systems with API libraries to interact with the cloud infrastructure.

Implement an experimental cloud service running in the application layer on a monolithic server. Start with Private-cloud open-source products such as OpenStack or Apache CloudStack to practice running containers in a virtualized environment with Kubernetes.

Public-Cloud

With a Public-cloud, everybody is hosted on a huge shared infrastructure. The hosting providers build very large data-centers with massive computing capacity. This leads to very good performance. These are very large installations with millions of users running on the same system. It is always classed as Off-Premises hosting and is currently not a commonly preferred solution for broadcasters.

I built a system with a MariahDB database engine and deployed it on a Microsoft Azure Public-could service. The performance increase was astonishing! More than 100 times faster compared to my development platform in the lab. Using Public-cloud infrastructures might be the right solution for some tasks.

Time-consuming systems administration and security maintenance is banished. There are concerns that your content is now not closely under your direct control. If the entire cloud service develops a serious fault, it can affect thousands of customers and take them all offline at once.

Private-Cloud

A Private-cloud uses the same IT technologies as a Public-cloud. Dedicated hosting privately available to a single enterprise is commonly preferred by broadcasters. This can be hosted On-premise or Off-premise. On-premise hosting runs on hardware in your own data center, co-located with other production infrastructure while Off-premise runs on hardware that you may or may not own in a data center located away from the rest of the production infrastructure. No-one else shares that Off-premise system but it is remote and can be provided as a managed or unmanaged system. There are many options.

An ingest or distribution process for your content could be deployed on Public-cloud services or within a managed Private-cloud on dedicated hardware.

Hybrid-Cloud

Ingest and deployment might exist in a Public-cloud, but other tasks are better suited to a Private-cloud design. Operating a Hybrid-cloud combines both. The distinction between Public vs. Private-cloud services is a variable threshold. This might be an optimal solution for broadcasters in some scenarios.

Outside broadcasting feeding back to the central content store might use less expensive Public-cloud services or hosted Private-clouds instead of satellite uplinks.

Off-premise systems can support low latency paths to edge servers for streamed content close to the viewing public. Production workflows are still implemented as Private-clouds. Moving content to an Off-premises cloud streaming service is functionally very similar to deploying broadcast content to a head-end content store for linear transmission.

Storing a large library of archived content in a Public-cloud or off-premises Private-cloud can be cost prohibitive. Only the most popular material needs to be stored for instant access. The rest is deployed on demand from large capacity hierarchical content stores when requested by the viewers. Infrequently requested content is migrated further offline to lower cost storage.

Community-Cloud

Collaborating with other organizations to share cloud resources can be very cost effective. Different divisions within a global enterprise or organizations that have common goals and share content could benefit here.

Potentially use this for a syndicated content scenario. Some production companies don’t broadcast their own content and their broadcasting customers don’t make the programs they deliver. Sharing the infrastructure between them can streamline the entire relationship.

Multi-Cloud

Several clouds can be integrated together into a larger complex. This is a super-set of all the different cloud types and described as a Multi-cloud configuration. An extra layer of management and control is added to supervise and orchestrate how these clouds interact:

• A collection of Public-clouds.
• A collection of Private-clouds.
• A hybrid mixture of Public and Private-clouds.
• Shared Community-clouds of different types.
• Any of these can be On or Off-premises.

Different cloud scenarios can co-exist within your organization. It is not necessary to use one solution for the entire enterprise. Partitioning into different pools allows each one to be tuned for optimal performance. Orchestrate this with supervisory software managing the interactions between clouds.

Service Providers

Only large organizations can afford to build and maintain Public-cloud infrastructure.

Collectively these providers are called Hyperscalers. They maintain massive data centers with sufficient processing power and storage to potentially support billions of users. These are the major public cloud infrastructure providers.

They all provide On or Off-Premise Private-cloud solutions for dedicated use. A hosted Private-cloud solution is deployed on higher performance hardware than you might build yourself.

OpenStack and Apache CloudStack are open-source solutions. Their Off-premise services are delivered by third parties.

All of the cloud implementations support Kubernetes container management. Other container managers might also be supported.

A Taxonomy Of Cloud Compute Based Service Types

Your infrastructure plan determines the distribution of Public vs. Private-cloud hosting. Now, set a threshold for how much of your workflow lives locally vs. in the cloud and determine right the mix of cloud-based services.

• Monolithic - Non-cloud services all running locally.
• IaaS - Infrastructure as a Service.
• PaaS - Platform as a Service.
• SaaS - Software as a Service.
• XaaS - An emerging term describing ‘Anything or Everything as a Service’. This aggregates all three of the above into a single category.

Monolithic Implementations

If you run your systems entirely on your own premises, you have 100% control over what is happening but you also have 100% responsibility for keeping it working.

This layered model shows how the services are built onto each other in a monolithic server:

A first migration step would be to relocate your hardware to a data center provided by a third party (indicated by the shaded boxes). They could manage the systems for you.

Network traffic increases to deliver content from your premises to a data center. Managed data centers have huge connectivity onwards to the outside world. That may outweigh the disadvantages if your content is being distributed widely to other organizations.

IaaS - Infrastructure as a Service

Implementing cloud compute support as an infrastructure service operates at the virtualization layer. In a Public-cloud, these are all managed by the provider.

A Private-cloud would implement something structurally similar on a dedicated system.

The shaded cells in the diagram indicate cloud compute services. The unshaded items are your responsibility to manage and configure.

Your dashboard allows some control over the configuration but the individual hosts need to be managed. Install your own chosen operating systems on each virtual host and configure the applications yourself.

PaaS - Platform as a Service

Implementing cloud compute support at the platform level vends a single CPU as a service. The operating system and all the other configurations have already been done for you. Install your chosen applications on top. Begin your own cloud infrastructure build-out with this, using a server to run several virtualized containers.

In a Private-cloud scenario, you might establish a team to manage the cloud services. They deliver them to the team responsible for the applications layer. 

Operationally, this is similar to buying in a Public-cloud service but you maintain complete ownership and control.

SaaS - Software as a Service

Implementing cloud support at the software level removes all of the systems administration tasks. Your application runs on a virtualized operating system with a web-based user interface for control and access. The entire layered stack is provided by the cloud service.

This is a good foundation for building flexible Microservice support that is easy to deploy and scale as needed.

Service-meshes

Managing a large collection of cloud services can become unwieldy as things scale up. Introduce another layer of control to orchestrate the individual services.

This is called a Service-mesh, but it is not the same as a Multi-cloud orchestration layer. Multi-cloud management operates on entire clouds while a Service-mesh works at the individual services level. Service-meshes provide these features:

• Reliability.
• Observability.
• Enhanced security.
• Decoupled communication.
• Data/control abstraction.

The Service-mesh is split into a data-plane and a control-plane. This is a similar concept to the abstraction of essence content and metadata. The data-plane is where the Kubernetes containers exist. The control-plane API interacts with your user interface dashboard.

Regulatory Guidance For SaaS

There are currently no ratified standards for how IaaS, PaaS and SaaS cloud services are constructed. Everything is based on de-facto or open-source implementations. There are some regulatory requirements that your service provider should be compliant with if you use Public-cloud services. If you run Private-clouds, then you have the responsibility of adhering to them.

Compliance is challenging when the SaaS environment is changing rapidly. Data might be spread across many services or be controlled by different parts of the hosting organization.

IaaS has better structural regulation than SaaS via the CIS Controls (Center For Internet Security Controls).

These are some useful resources to start with. There are others that are specific to particular business sectors such as healthcare and finance. We don’t yet have any broadcast specific recommendations but that may change:

Related Guidelines, Standards & Technical Reports

Download and consult these documents for further supporting broadcast focused technical details:

Check out the collection of Video Services Forum (VSF) documents here.

Download the open-source kits for OpenStack, Apache CloudStack and Kubernetes and read the documentation contained therein.

Conclusion

Broadcasters are naturally concerned about security and robust failover protection because being taken off air by unreliable systems, nefarious individuals or having one’s content subverted simply cannot be tolerated. Consequently, broadcast and production companies will most likely prefer to deploy On-premise Private-cloud infrastructures using the same technology as the Public-cloud providers.

There are several layered approaches to the deployment of cloud-based systems. At one extreme, everything is managed by the broadcaster in their own data-center. At the other extreme, everything is delegated to a cloud service provider. The intermediate configurations use the same technology as the Public-cloud providers, but at a cost of some systems administration overhead. Private-clouds are dedicated to one single organization and optimally configured just for their use.

There are no rules that dictate that your entire infrastructure needs to be deployed using cloud technologies. You also don’t need to stick entirely to Public or Private-cloud solutions. There may be parts of your enterprise that would operate more efficiently if they were hosted differently to other parts.

A streaming service might operate very efficiently outside of your organization on a cloud-based streaming platform. Content creation and production workflow could be hosted On-premises with monolithic servers or in a Private-cloud with virtualized processes.

Virtualization facilitates the implementation of Microservices. A virtualization container can be configured as a very small CPU with limited resources if the Microservice is short-lived and does not require much computing capacity. A sensor reading monitor is a very minimal process for example.

Your deployment strategy can scale in a gradual fashion from a monolithic approach to a virtualized Microservice based architecture as your enterprise grows.