Architecture

Telestream Cloud provides a broad range of services that operate on live and file based media content. This section describes how the platform works for a typical file based service like Transform

In file based services a job can be submitted manually (through the web console), programmatically (through the API) or automatically when a new media file arrives in object storage.

The service assigns each job to a specific cloud provider region, generally the same region where the input media objects are stored (or where the output objects will be stored).

Access to the service web console requires an valid user account. Telestream Cloud provides a sophisticated Identity and Access Management (IAM) system that supports user and admin accounts and multi-factor authentication. See Getting Started - Identity and Access Management for details.

📘

Single sign-on (SSO)

Users can also be authenticated using a single sign-on provider such as Okta or Azure Active Directory. See SSO Enablement (SAML 2.0) for details.

All Telestream Cloud core infrastructure: front end (web applications) and backend (service APIs, IAM, storage, etc.) run in Kubernetes on the Google Cloud Platform (GCP).

Manager

Jobs submitted to a service (through the service API) are forwarded to the job manager is the appropriate regions. The job manager has two components:

• the scheduler queues jobs received from the service API and schedules them for execution when compute resources become available.
• the autoscaler creates new compute instances when the job queue fills and destroys instances when the queue is empty.

High traffic regions (like AWS US East) have dedicated local managers. Lower traffic regions may be managed remotely.

A remote manager can be in a high traffic region on the same cloud provider or potentially a different cloud provider. Remote management provides resiliency against cloud provider outages.

Regional managers are hosted on a local Kubernetes (K8s) cluster. Kubernetes ensures that there is always an active manager available in the region and that manager remains at a static (and public) IP address. Managers are currently located in 6 regions across GCP, AWS and Azure.

Coordinator

Within each region Telestream deploys multiple compute instances to execute jobs. Each instance is provisioned with a virtual machine image containing the Telestream Cloud coordinator. When the coordinator starts it creates a connection to the local (or remote) manager for that region.

Each coordinator in the region reports its currently available resources (CPU cores, GPU cores, memory, etc.) to the manager.

The manager evaluates the resource requirements for each job and the total resources currently available in the region (as reported by the instance coordinators). If a specific instance has sufficient resources the manager schedules a job for execution by that coordinator.

The manager and coordinators communicate over gRPC (Remote Procedure Calls). The coordinator initiates the connection to the manager's public IP address. Once the connection is established either the coordinator (client) or manager (server) can initiate a procedure call.

📘

Mutual TLS

Mutual TLS certificate authentication ensures that traffic between the coordinator and manager is secure and trusted in both directions.

Autoscaling

When the occupancy of the region (the percentage of resources that are in use) exceeds a specific threshold the manager will provision additional compute instances. Similarly when the occupancy drops below a certain threshold the manager will retire idle compute instances.

The goal of the autoscaler is to schedule jobs as quickly as possible without spending too much on idle infrastructure.

The autoscaler is highly flexible: it can provision different instances types (based on job requirements or regional availability) and provision instances from on-demand, reserved or preemptible (spot) instance pools.

Virtual Private Cloud

Coordinator instances are provisioned within a dedicated Virtual Private Cloud (VPC). The private cloud secures the instances that execute jobs and that have access to customer object storage. The private cloud also isolates those instances from the publicly accessible infrastructure managing the jobs.

Within a private cloud only secure outbound connections (e.g. to the regional manager) are allowed, no inbound connections are permitted or required.

Customer Private Cloud

By default, compute instances are created in a private cloud provided by Telestream. The service charges include both the software usage and the compute instance cost for each job.

Optionally compute instances can be created in a private cloud provided by the customer. In this case the service charges only include the software usage. The cost of the compute instances are charged directly to the customer's cloud provider account.

In either case Telestream Cloud manages and autoscales the coordinator instances within the private cloud.

Operating in a customer private cloud requires setup. See Customer Private Cloud for details.

Workers

For each job the coordinator creates a worker and provides it with the job details. For example in the Transform service each job includes a JSON composition. This document identifies the storage location of the input media and describes the output media produced by the composition.

When the worker starts it creates a separate gRPC connection with the manager to report the status and progress of the job. As the job executes the manager adds that information to the database making it available to the service API and the web console.

Containers

The software engine for each service is deployed as a container to the Telestream Cloud Docker registry. When a job executes the worker pulls an engine container image from the registry. In high traffic regions the registry is mirrored locally to minimize job startup times.

The worker runs the Docker container, monitors the progress of the job and reports that information to the regional manager. Typically the worker creates a gRPC connection with the container to track progress and monitor the health of the engine.

Versioning

As features are added to a service (and the inevitable bugs are fixed) new versions of the engine container are added to the registry. The job details identify the which version of the engine should be used to execute the job.

For example in the Transform service the composition identifies an engine version that has been successfully tested with the associated job template. The production version is stored in a job factory and will be used for all subsequent jobs until upgraded by the user.

Object Storage

During job execution the engine reads directly from (and writes directly to) the customer object storage buckets. This significantly improves job performance as it eliminates the need to copy media to and from the instance before and after processing.

📘

FUSE

The worker mounts the input and output object stores to the container using a caching system based on FUSE (Filesystem in Userspace). This reduces the amount of block storage required and helps secure the customer media (as there are no complete copies on the instance).

Telestream Cloud supports a variety of authentication methods to access the customer object storage. See Getting Started - Stores Management for details.