In under 10 years, the concepts of public cloud computing and virtualization of computing resources have disrupted all of the perceived wisdoms of IT system design. Engineers who design systems for media processing and production now have to consider where the computing resources for their system are located and how they want to pay for it. In other words, they have to consider much more than just signal paths and workflows.
Solution architects now have choices of running their systems on various infrastructures, including dedicated “on-premise” servers, virtual machines in private data centers, or on public cloud computing platforms. Then there is a choice of business models to consider… do you buy systems on CAPEX and depreciate them as business assets? Do you subscribe to software or do you pay for it according to usage? There are so many options to choose from and the cost/benefit comparisons can be very complicated, so it is understandable that many customers appear to be in a state of indecision.
Perhaps it is time to suggest that we are looking at the system design problem in the wrong way. We should be looking at function first, i.e. what must the system do, then look at the required business model, then decide on the appropriate infrastructure, rather than letting the infrastructure form dictate the design process. To learn a lesson from another industry, classic architecture or design students are taught to get the balance right between form and function in a building or product design. They are taught that form without function is of little value, while function with form can be equally ineffective. Perhaps these factors should also be considered in media systems design?
A classic broadcast system would be designed according to signal flow (typically “left to right”), with discrete boxes that each perform a single task. As we have moved into IP-based and file-based processing, we have had to adapt to thinking about a hardware/software stack, with applications at the top and infrastructure—computing, networking and storage—at the bottom.
Unfortunately, the infrastructure question has come to dominate too many discussions, when it should be software/system functionality that is decided first and infrastructure should be provided that suits the desired operational or business model. In other words, software function should come first and infrastructure form should be defined to suit the business needs.
WHERE TO HOST YOUR MEDIA PROCESSING PLATFORM
Having said that, the infrastructure decision is important, so when choosing where to host “heavy lifting” media processing, there are a few simple guidelines to consider.
For the highest-performance media processing, the servers should be located topologically close to the file storage. In many cases, on-premise processing will provide the fastest performance, but if the files are already on a cloud storage facility, maybe that’s where media processing should be formed.
Running most software on virtual machines is easy unless your vendor still relies on dongles for licensing. The challenging part is creating an elastically scalable license model that works on a customer’s private data center.
Media processing tasks such as transcoding can use the full computing resources of a server, so one of the benefits of virtualization—that of sharing computing resources—is not usually seen. All of the other benefits of virtualization apply. For the same reasons, containerization of software offers little benefit over virtualization for media-processing systems.
If you plan to virtualize your software solutions, look for solutions that offer a single point of management.
SaaS IS A SERVICE, NOT JUST A PRODUCT
SaaS models for your media processing, used extensively, may cost more than provisioning your own servers and software but may be more aligned with your company’s financial and business models. SaaS on public cloud is typically chosen for reasons of cash flow, convenience, flexibility and easy scalability more than for cost savings.
Modern enterprise class software should be capable of running on any of the major infrastructure models: on-premise dedicated server, virtual machines or on public cloud, and with a range of business models from CAPEX purchase to usage-based SaaS models. Workflow orchestration should allow customers to use any one or a combination of these infrastructure types and payment models according to their business needs.
In summary, system designers should select the software and solutions that offer the functions their business needs, and vendors should be expected to make this available in any infrastructure form, and with range of business models.
If your software vendor cannot answer all of these requirements, then perhaps your real question should be—“Is this a vendor that can help my business?”
George Boath is the director of channel marketing for Telestream.