an arqiva satellite & media whitepaper exploring the ... · cloud function, exploited by...

November 2017

An Arqiva Satellite & Media whitepaper exploring the benefits of virtualisation in the delivery of common media services.

Virtualisation

in the broadcast industry

By Kris Barker

Head of Product Development, Satellite & Media

BackgroundFinance, engineering and retail industries have all made significant moves to adopt cloud-based delivery of development and production environments. Media and broadcast businesses are now seeking the anticipated benefits of virtualisation that have driven other markets to adopt the transformation.

In January of 2016 Arqiva Satellite & Media conducted market research on virtualisation in the broadcast industry. It sought to understand what broadcasters plans for adoption were and the perceived benefits and barriers. The biggest benefits were felt to be:

n Commercial flexibility, which meant shorter contract durations supporting market testing and event based services

n Potential cost reductions

n Reduced speed to market

n Most felt that adoption would initially be through low risk services or disaster recovery, in some instances adoption would be driven by technology refresh

n Most felt that the barriers to entry for virtualised services were low and expected to see increased competition in service offerings for media management, playout and distribution.

This paper begins with an introduction to virtualisation and orchestration. Following that, we explore the benefits of orchestration in the delivery of common media services. We then examine the relative merits of public versus private cloud environments, and their suitability in delivering the commercial flexibility and cost reduction drivers noted in the market research. Finally, we review the maturity of the vendors approach to application development and accompanying commercial models.

01 Virtualisation 2017

Virtualisation introductionWhen people talk about virtualisation, they’re usually referring to server virtualisation, which means partitioning one physical server into several virtual servers, or machines. Each virtual machine can interact independently with other devices, applications, data and users as though it were a separate physical resource.

Different virtual machines can run different operating systems and multiple applications while sharing the resources of a single physical computer. As each virtual machine is logically isolated from others, if one crashes it doesn’t affect the others.

Virtualisation is also often considered to cover service automation. To avoid confusion virtualisation in this paper will purely refer to the infrastructure component. The automation of service instantiation, management and monitoring will be termed orchestration.

Infrastructure optionsVirtualised infrastructure is typically referred to as a ‘cloud’. There are a range of characteristics which apply to cloud computing, whether privately or publically hosted. This is the widely accepted National Institute of Standards and Technology definition of those characteristics:

n On-demand / self-service – The ability to provision computing capabilities, such as server time and network storage, automatically without requiring human interaction with each service’s provider

n Broad Network Access – Capabilities are available over a network and accessed through standard mechanisms that promote use by heterogeneous thin or thick client platforms

n Multitenancy / Resource Pooling – Computing resources are pooled to serve multiple customers using a multi-tenant model, with different physical and virtual resources dynamically assigned and re-assigned according to customer demand

n Rapid Elasticity – Capabilities can be rapidly and elastically provisioned, in some cases automatically, to quickly scale out and rapidly released to quickly scale in. To the consumer, the capabilities available for provisioning often appear to be unlimited and can be purchased in any quantity at any time

n Managed Service – Cloud systems automatically control and optimize resource use by leveraging a metering capability at some level of abstraction appropriate to the type of service (e.g. storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled and reported providing transparency for both the provider and consumer of the utilised service.

There are broadly two cloud deployment models:

n Private Cloud – the cloud infrastructure is operated solely for an organisation. It may be managed by the organisation or a third party and may exist on-premise or off-premise

n Public Cloud – The cloud infrastructure is made available to the general public or a large industry group and is owned by an organisation selling cloud services.


There are three recognised service models:

n Software as a Service (SaaS) – Applications, running on cloud infrastructure, are directly available to a consumer. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, storage or even individual application capabilities, with perhaps the possible exception of limited user-specific application configuration settings

n Platform as a Service (PaaS) – The capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or acquired applications supported by the provider. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems or storage, but has control over the deployed applications and possibly application hosting environment configurations

n Infrastructure as a Service (IaaS) – The capability provided to the consumer is to provision processing, storage, networks and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications.


Key functional components for orchestration include:


Orchestration

It is the combination of these elements of orchestration which generate most the benefits expected for virtualisation:

n Service instantiation: where infrastructure is required it is created using templates at the point it is needed, and removed when the service is no longer required; where the service is comprised of Software as a Service (SaaS) components the orchestration workflow calls the required function and provides requisite conditions for use (authentication, point of origination, destination etc.)

n Management provides the numerous functions including: an awareness of services and their status; security tools for authentication and protection against intrusion or malware; and, data collection for service optimisation, cost allocation and billing

n Tools to monitor infrastructure, environments and applications.

Element Function

Infrastructure Management

Application Management

Workflow Management

Logging / Reporting

Lifecycle Management

Tools that instantiate compute resource, specifying the right processor, memory, local storage and operating system requirements. These tools also cover nearline storage, networking and container management.

Installs, configures and manages applications on to the infrastructure.

In the context of managing cloud services this is entirely separate from workflows that control assets as they progress through broadcast chain. In this context, it is the management of the series of activities that creates infrastructures, maps applications, creates the network etc.

Provides the tools and environment for harvesting and analysing data. This is for both metering and cost management, in addition to service management.

Managing environments for testing, staging and production, in addition to the configuration and service capture.

ArqivaOrchestration Engine

Servicemonitoring

Continuousintegration

Serviceaware

Service instantiation,upgrades and removal

Useraccess

Securitycompliance

Operating systemand patchmanagement

Billing and costmanagement


Virtualisation has become a catch-all term for the use of software on common infrastructure. People often infer many properties of virtualised services, such as self-healing replication, or speed of service setup. However, these are orchestrated through a range of tools and not inherent in the infrastructure or the applications that provide service features. It is a combination of the applications, common infrastructure, orchestration and continuous integration practices that create a ‘virtualised cloud’ service.

There are some inherent values of orchestration, such as repeatability and speed, which are a factor of creating templates for functions, systems or services in code. Rapid elasticity is another cloud function, exploited by orchestration, which is of specific value in the delivery and management of broadcast products and services. It is the broad combination these functions that generate both ‘vertical product orchestration value’ and ‘end-to-end proposition orchestration value’.

Vertical product orchestration value

The value of orchestration at a vertical product level is proportional to the volume of services that are created. There is little need for the automation of service creation if the service is only going to be created once. Services that are created in the hundreds or thousands, or reacting to external events, benefit from the removal of manual processes. The customer benefits include repeatable quality in service delivery and speed of service provision. The benefits to public cloud broadcast services providers, like Arqiva, include dynamic scaling, or rapid elasticity.

End-to-end proposition orchestration value

The value here is the automated integration of multiple products or services that are naturally bought and sold in combination. In this context, there is little value in automating two services either side of a manually provisioned one. The benefits of repeatable quality and speed of provision are immediately lost.

The following matrix outlines the intersect between the value of product and proposition orchestration for a range of common media services.

Vert

ical

Pro

duct

Orc

hest

ratio

n Va

lue

End-to-end Proposition Orchestration Value

Cloud VoDProcessing

Variable Volumn

Cloud VoDProcessing

Fixed VolumnCloudMAMIngest

PermanentSimulcastStreaming

Live to VoDPlatform Processing

DymamicAd Insertion

OUSimulcastStreaming

Live to VoDB2B Publishing

Live to VoDOTT TragetDR Playout Cloud

Playout

The following tables outline the benefits for each of these services.


Cloud Playout

Vertical ProductOrchestration Value

Required for service recovery, quick launch and correlation of AWS and 3rd partylicense costs

DR Playout Cloud MAM Ingest

Required for immediate automated launchin DR scenario. Required to accurately track and bill for usage on PAYG basis

Generally going to be a fixed service over long term, with predictable volumes of content, so managing scaling is not an issue, nor is there going to be lots of services to launch

End-to-endPropositionOrchestration Value

Can theoretically stand alone and there won't be many

Will likely stand alone and be invoked onits own

Could be a completely standalone platform, little value in tight integration except perhaps to reduce storage andegress costs

Cloud VoDProcessing FixedVolumes


Generally going to be a fixed service over long term, with predictable volumes of content, so managing scaling is not an issue, nor is there going to be lots of services to launch

Required for spinning up and track resource usage by ad-hoc customers. Required to manage capacity on permanent resources and allocate accordingly

Generally going to be a fixed service over long term, so PAYG not as critical, nor is there going to be lots of services to launch


Could be a completely standalone platform, little value intight integration except perhaps to reduce storage and egress costs

Will need to integrate closely with streaming platform but this could be a platform level thing done at first build, rather than service deployment

Likely to be integrated with some other service but not definitely. Will certainly benefit cost wise if integrated with playout of L2V

Cloud VoDProcessing VariableVolumes

PermanentSimulcast Streaming


Occasional UseSimulcastStreaming


Required for quick and efficient launch of OU services at volume in bursty patterns, will be used to track resource usage and integrate with PAYG billing mechanisms

Can be delivered with basic workflow orchestration and use workflow data to monitor and report on usage. Not really dependant on scalable resources and likely to feed a fixed volume, permanent service

Will depend on cloud platform to host portal/player for publishing and editing content, will potentially generate ‘bursty’ content volumes so resources will need to scale and be tracked for usage


Highly likely to be integrated with some other service. Will certainly benefit cost wise if integrated with playout of L2V

Will need to integrate closely with streaming platform but this could be a platform level thing done at first build, rather than service deployment

Only works as part of an integrated set of service platforms. Needs streaming and OTT capability and potentially VoD processing to be seemlessly integrated and managed holistically

Live to VoD for Platform Processing

Live to VoDfor B2BPublishing

Live to VoD for OTT Target


Will depend on cloud platformto host broker and CMS for managing content lifecycle, will potentially generate ‘bursty’ content volumes so resourceswill need to scale and be tracked for usage

Likely to be used for permanent services so could be a set up and forget about it type arrangement. Complicated stuff is done outside of Arqiva's control but there will need to be the ability to orchestrate the propagation of business rules for replacements


Only works as part of an integrated set of service platforms. Needs streaming and OTT capability and potentially VoD processing to be seamlessly integrated and managed holistically

Basically, part of permanent streaming so value of orchestration is inherent

Dynamic Ad Insertion


Service benefits of virtualisation for broadcastersThe scenario below is hypothetical, but entirely realistic. It is based on a customer with the following requirements:

n 3 channels of simple thematic playout (2 single thread as low revenue)

n VoD processing with delivery to a DTH platform for 10 hours of programming a week, with a requirement for a 30-minute turnaround

n Pop-up OTT simulcast streaming channels for 8 live events per year

n Live to File – live event extraction and segmentation into 1 hour programmes for inclusion into the VoD process above.

Potential issues faced in a traditional delivery model

While it is unlikely that all these scenarios would happen together, each of them independently is possible in a physical build where capacity is primarily dictated by current demand.

n It is entirely plausible, for example, that the playout channels could require the purchase and installation of equipment. This could impact the aspirational on-air date if there were delays in delivery. Rack space, wiremen and local engineering are also factors in the project delivery timing

n VoD capacity, if managed on average utilisation, could also require extending to meet this new peak demand

n Simulcast channels, for occasional use events, could have clashes on encoder ports due to bookings clashes. These pop-up channels would require manual configuration for each live event

n Decommissioning, at the end of the contract, could take up to three man days of effort for all services.

Potential opportunities for a public cloud-based orchestrated delivery model

Some of these benefits equally apply to private cloud models, however managing capacity to peak forecast demand is economically sub-optimal.

n The provision of the playout channels is done on demand, as capacity is not constrained. Neither rack space nor manual wiring is required

n Elastic scaling of VoD processing also obviates detailed capacity planning and management

n Simulcast occasional use channels are configured quickly from automated templates. There are no possibilities for booking clashes on capacity

n Service decommission is largely automated saving considerable time.

The following tables outline some of the differences in process, delivery and operations managing the customer requirements above on traditional models versus cloud-based models.


Provision

Traditional method

Process schedule and content

Orchestrated method

No change

Configure playout services Infrastructure and application templated

Initate VoD workflows(transcode, QC, subtitle processes)

No change

Source live feeds No change

Route traffic to sites for ‘processing’ Same, but to a public cloud

Configure simulcast services Use customer created templates

Order physical equipment Not required

Upgrade VoD engine, playout server, graphics switching, encoder probe, VoD upgrade

Not needed, scale to requirements

New multi-channel encoder / transcoder PIE Not needed, scale to requirements

Arrange for install and commissioning Not required, service configuration only

Organise for the delivery to end-points No change

Test end-to-end No change

Operate & Cease

Traditional method Orchestrated method

Single threaded services – source spare capacity on cross-site

Use the same service snapshot to re-establish in another availability zone

Connect playout output to temporary cross-sites Re-route to destination

Cease services by physically decommissioning equipment, removing from racks, returning to stores etc.

Initiate cease commands

Public vs private cloud adoption

The pace of evolution of cloud environments is extremely quick. Not only does this cover the functional services on offer, such as automated scaling or data analytics, but also the commercial models on offer. Vendors of compute resources and associated management stacks for the creation of private clouds are adopting alternative pricing schema to directly address the dual threats of Pay-As-You-Go (PAYG) and scalability of the public cloud provider models.

Compute & Networking


At a high level, the advantages of owning and building private infrastructure are:

n where infrastructure is procured using traditional capex models, the costs can be depreciated over several years, and the assets then ‘sweated’ for their reasonably useful life

n the cost of access to stored data (media assets) is incredibly low

On the other hand, public cloud infrastructure allows for:

n a marked reduction in risk, and increased flexibility, where compute costs are directly related to utilisation

n infrastructure is continually upgraded ensuring you are using the most efficient functions possible

n vertically scaled services, such as Over-The-Top streaming, where demand can fluctuate on an hourly basis and the scale between ‘peaks and troughs’ can be dramatic

n location independence, where services can be provided close to the area they are required in.

When reviewing whether a public or private cloud environment would be the best technology solution for any particular use case, the cost of moving content in and out of these environments must be considered. Within the media industry one of the most commonly expressed concerns relates to the ‘egress’ (outbound traffic) costs from public cloud environments such as Amazon Web Services (‘AWS’). This is due to the fact that the vast majority of egress costs are driven by public cloud providers basing their pricing strategy on GBs of data / content egressed, rather than a flat fee for any utilisation within a defined connection. However, in traditional datacentres, or within a private cloud, the cost of moving data/content is driven solely through the costs of networking required to carry that data. Separately, ingress (the process of passing data into AWS or other public cloud environment), does not usually incur an additional fee from the likes of AWS.

When modelled, it becomes clear that egress costs could be a significant portion of the cost base for running a public cloud-based service, and this will likely be a key drawback for someuse cases. However, three other factors usually weigh in, and in the modelling Arqiva have undertaken, work to counterbalance this ‘new’ cost which is unlikely to have existed inprevious systems:

1. Significant and regular price erosion on many other elements of the cost base (such as compute power) helping to offset egress costs.

2. Utilising more efficient egress methods. For example, most content from AWS can be egressed through CloudFront (AWS’ Content Delivery Network (‘CDN’) at a much lower rate than other egress options.

3. Utilising Direct Connect (rather than egressing data / content onto the open internet), whereby Arqiva (or another company) is able to directly peer with AWS’ network and tunnel traffic through these links.

So although egress costs may be significant, options to keep this as low as possible, as well as other advantages of a public cloud, mean that each use case cost model must be reviewed as a whole, rather than focussing on a single cost item.


Market – Vendor review Deployment and removal

As described above, to leverage the cost benefits of the most efficient utilisation of infrastructure and applications, it is vital that services can be deployed and removed, in a rapid and repeatable way. It is no longer sufficient for a function just to be available as software. Each application requires the capability to manage service configuration ‘injection’, as well as allowing these to be captured programmatically through APIs. They should also provide the ability to install through relevant package managers. Where possible, container based services should be used as they provide the widest range of platform support.

Monitoring

Additionally, applications should also support monitoring capabilities (beyond interfaces into the existing service tools). Ideally, this would include logging data that could be captured by Elastic Logsearch, and interfaced with common dashboard tools.

In summary, it should be a mandatory requirement of all vendors to ensure that their applications can be managed through a full service lifecycle, in addition to providing the features and functionality required by the service chain.

Licensing

It is important that vendors offer licencing models that support short term usage (hour, day, week, month), or throughput (90% of peak, Gbps, GB etc) based pricing. Licencing should be captured on a per service basis, to align with billing and P&L management, and not rely on the presence of physical components or their MAC addresses. Additionally, licenses should be easily transferable in the event of the need to re-instantiate any particular element of the service chain.


ConclusionsCloud-based delivery is here to stay, the question is what needs to happen to increase the levels of adoption in broadcast.

The benefits appear to be clear, but they are also many and varied and while moving to virtualised services could be considered the obvious choice, to ensure it is done correctly requires a full understanding of the drivers of that choice.

For instance, a fundamental decision within the move to virtualised services is the adoption of public or private cloud services. This cannot be dictated on cost alone. Other factors such as physical location, whether all functions in a chain can be virtualised, and buyer behaviours, will also have a bearing.

As an example, there is a widely-held belief that statistical multiplexing can only be conducted with dedicated graphics processors, meaning either new technology or functionality within public cloud environments, or the control over infrastructure that private clouds provide. Furthermore, the statistical multiplexing function is primarily to ensure the most efficient use of downstream bandwidth, for example the bandwidth of a satellite transponder. Moving these functions away from the teleport offers potentially little benefit and could increase operational risk.

In late 2016, Arqiva undertook detailed commercial modelling comparing the costs of private and public cloud, with several interesting conclusions.

Chief amongst these was that the level of price erosion from cloud providers is such that, when combined with equipment refresh and paying for services as used, makes a compelling case for public cloud adoption. In the intervening period price erosion on compute resource has continued. An interesting article on this can be found here: https://www.cloudyn.com/blog/analyzing-aws-ec2-price-drops-over-the-past-5-years/

On the vendor side, our experience to date has been mixed. The more mature products have often proven to be the most immature when adopting a software only model. This has either been from retaining capex based charging structures, or lack of suitable programmatic interfaces making orchestration and life cycle management difficult or manual. Conversely, more recent services, or those ‘born’ in the cloud such as streaming, have more mature software models. The challenge is to ensure that features and functions are not compromised at the expense of availability, monitoring and management.

With all this in mind, it is worth remembering that virtualisation is still relatively new in the broadcast arena and to navigate the journey to adoption the industry must acknowledge the shift and consider the changes needed across the supply chain.

Arqiva is at the heart of this shift and working hard to deliver the reality of virtualisation and orchestration today.

For further information:Telephone: +44 (0)1962 823 434 Email: [email protected] Web: www.arqiva.com

an arqiva satellite & media whitepaper exploring the ... · cloud function, exploited by...

Documents