A case study for a multitenant solution for delivery of user-generated content to designated consumers

Content delivery networks do not solve the massive technical challenges of delivering media uploaded by users to specific groups of consumers. Media can include photos, videos, and podcasts, and are created by individuals, organizations, and small-to-medium businesses. The majority of these are of low interest to the general public, which runs counter to the principle of content delivery networks where content is for public consumption. The leading content delivery networks tailor their network architecture and operational structure toward popular content.

A multitenant solution that provides content delivery services can fulfill the requirements by virtue of isolation and scalability. When the implementation is designed for the cloud, it can become both elastic and, on a pay,-as-you-go model.   Such a service would redistribute content among edge servers and render them in a context-aware fashion.

YouTube and Facebook represent the content web platforms available for common use today. They have native support for social networking functionality but they do not provide private delivery services because all the content is aggregated together for delivery. Some web services support content delivery such as CloudFront and object storage as a cloud service but they do not support access management and segmentation requirements. Therefore, it is hard to find a solution that can address all of these requirements.

The essentials for a multitenant service that fulfills these requirements include the following:

1.       Media cloud – The media cloud is hybrid in nature. It can include on-premise appliances or public cloud services that support unconfigured content distribution with an underlying network infrastructure.  It exhibits resource virtualization in terms of computing, storage, and networking resources. For example, networks can be virtualized with point-to-site VPN connectivity or open-flow technologies.

2.       Content provider – When the content is published, a content-delivery request is submitted to a choice media service provider. Each request has the following parts:

a.       A list of locations for the content which could be private servers or storage space such as Amazon S3.

b.       A group of targeted consumers which could be a group of friends on a specific social networking platform or all the users in some geological location or within some subnet.

c.       A list of desired Quality-of-service metrics e.g. Bandwidth, delay, time jitter, security, and others.

d.        A time window during which their contents can be consumed.

3.       Workflow – Carving out a content delivery service from the underlying media cloud supports a virtual overlay that provides the required QoS with minimum cost. Storage, bandwidth, and compute required for delivery are reserved. Managerial routines can be delegated to compute that can be scaled up or down.

4.       Identity and access management to secure a targeted audience. This could be as simple as public-private key pairs to gain access.

When the virtual content delivery service is configured, contents are acquired from the storage locations and pushed into the set of edge servers from which a targeted audience can consume.

Reference: https://1drv.ms/w/s!Ashlm-Nw-wnWhLMfc6pdJbQZ6XiPWA?e=fBoKcN