Printer Friendly

Next-generation enterprise video platforms: are video platforms geared toward the enterprise more than just repackaged entertainment platforms?

It's long been accepted as gospel that enterprise video solutions lag behind platforms geared for entertainment. But while enterprise streaming media delivery used to consist of Windows Media, Real, or even older legacy streaming technologies, the past year has seen a number of changes in the enterprise video delivery ecosystem. Real Networks has ceased sale of its Helix servers, Microsoft is fully on the HTTP-based delivery bandwagon (with both DASH and Smooth Streaming), and a surge in mobile video usage in the enterprise shows no sign of abating.

The last issue--mobile usage for enterprise video consumption--is probably the biggest challenge facing the enterprise today. Mobile or remote workers, armed not with just a laptop but also a tablet and a smartphone (sometimes two or more of each), have forced companies to look at greenfield solutions to move beyond internally created legacy delivery solutions. Some of these may even include cloud-based or hybrid solutions.

This article explores the challenges and opportunities an enterprise might face in choosing an enterprise video platform (EVP). The article doesn't provide a checklist of key features, as we're still in the midst of preparing an enterprise video platform buyer's guide as part of the upcoming 2015 Streaming Media Sourcebook, but it does provide insight into some of the building blocks that are necessary for video platforms to co-exist within the multi-use networks found in most enterprises and large organizations.

To address these building blocks, we will try to shine the light on a series of acronyms, from SQL and NoSQL to AD, ON, and SDN.

AD, ON, and SDN

Three nonstreaming technologies are important for the proper dissemination of next-generation enterprise video within the corporate network.

One of these, Active Directory, has been around for quite some time, and we've highlighted one scenario of Active Directory's use in another article in this month's issue, "Streaming Goes to War."

The other two are networking technologies that fall under the terminology of open networking (ON) or software-defined networking (SDN) as descriptors of the intent to move toward standards-based networking that can be modified solely via the use of software.

To best achieve SDN, though, the switch and router manufacturers, sometimes called the "big iron" companies, need to offer deeper access to their switching fabric via software development kits (SDK) and application programming kits (API). In some instances, the "big iron" companies have responded, even open-sourcing the managed switch and router operating systems.

The Open Networking User Group (ONUG), is leading the way not just toward SDN but also common platforms as well. ONUG calls this the Common Networking Ecosystem.

The ONUG Board requires six levels of commonality to provide a proper ecosystem: provisioning, orchestration tools, control mechanisms, baseline policies, current-state management databases, and integrated monitoring.

The six commonalities were outlined at a recent ONUG Board meeting in New York (opennetworkingusergroup.com). And, lest our readers wonder why the streaming industry should care about the ONUG Board, let's just say it's made up of fairly heavy hitters in the enterprise IT space: Bank of America, Citigroup, Fidelity Investments, Cigna, Credit Suisse, FedEx, Gap Inc., JPMorgan Chase, Pfizer, Symantec, and UBS.

While many are familiar with the first commonality--the use of automated discovery, provisioning, and asset registration used to attach a device or a subnetwork to the primary network--ONUG sees the benefit as going beyond just a software-defined connection of local area networks.

In fact, the goal is to provide software-defined wide area networks (SD-WAN) in conjunction with virtual network overlays as a way to eliminate the hard-wired dependencies of more traditional virtual private networks (VPN).

At numerous Streaming Media shows, enterprise speakers and panelists have discussed issues facing their mobile or remote-worker streaming video needs and emphasized the issues created by multiple workers attempting to view content housed behind the firewall over a VPN.

The reasons for these limitations are twofold. First, companies bought these VPN services--and the hardwired lines that are often used for VPNs--back when the idea was to "dial in" for basic email access or simple remote desktop connections. They really weren't intended for video delivery, nor were VPN services priced with high-bandwidth delivery in mind.

Second, these psuedo-private networks, while virtual in nature, are still beholden to legacy technologies--and even legacy hardware, at the service provider's level--that limit the overall growth of VPN capacity.

All of which is to say that with open networking, SDN, and even SD-WAN, the intent is to be able to reconfigure any pipe into a more modern version of a VPN, one capable of meeting dynamic bandwidth and use-case requirements.

To do so, automated orchestration tools for network configuration and change management are needed and have been highlighted as part of the overall ecosystem by the ONUG Board.

Common Control

In addition, given the likelihood that physical routers will coexist with both physical and virtual switches for the foreseeable future, common control mechanisms are needed to control networking gear from a variety of competitive switch and switching fabric manufacturers. To get there, though, one must also assure that a common baseline policy for all vendor gear is not only in place but also enforceable through a controller environment common to all gear attached to the local and wide-area networks.

A final portion of common control, called out by both the ONUG and vendors, is the need for a standardized "state management" database. This is less about the control of the network than it is about the network's current state. For streaming media delivery, this would be both the state of the route--from the origin server to a Wi-Fi-based mobile device moving between access points on the corporate network, for example--but also whether networking protocols have been defined and are in an active state. Those protocols could be HTTP (assumed to be on), as well as RTP/ RTSP, RTMP, and even legacy protocols that use specialized ports and transport.

Interestingly, ONUG says these network states should be "automatically captured for all physical and virtual network devices" and most software-defined video solutions (such as the type that Elemental Technologies is pitching as part of its SDV initiative) would fall primarily into the virtual device category.

I asked Sam Blackman, co-founder of Elemental Technologies, to help our readers understand the difference between SDN and SDV, as the terminology can be confusing.

"Software-defined data centers will entirely consist of virtualized infrastructure--compute, storage, networking--and SDV applications will ride seamlessly on top of these virtual machine resources," Blackman says. "Media companies managing these SDDCs will be able to spin up and down SDV resources (on-demand transcoding, linear or live encoding/ transcoding, packaging, and content origination) as business needs dictate."

SQL or No SQL?

Most legacy enterprise video systems are built around a relational database system or RDBS. Regardless of whether the backend is based on a proprietary (Oracle, IBM, Microsoft) or an open-source (MySQL, Maria, Postgres, SQLite) database engine, the language used to run queries and request content from an RDBS is based on a form of structured query language (SQL).

SQL variants are different as the RDBS solutions that run them, but they share a common foundation: Structured content is stored in tables and columns; the queries use those tables and columns to search for content stored in a given row or field, otherwise known as a database record.

At least one column in any given table is designated as the primary key. This column needs to contain unique information for every single field in that column and establishes the relationship between various tables and database records. Without a unique primary key, there's a risk that content in a given record will be mistakenly served up when an SQL query or report is run.

For streaming content, a record could vary from something as simple as a DASH segment or as complex as an entire alternate audio stream.

Content that doesn't fit in to a given table or column, such as additional metadata about an existing record that doesn't yet have a column in the table, potentially could be abandoned. In other words, data types added later--or used infrequently--aren't a good fit for the field-based relational database model

In the past 5 years, though, another kind of database has appeared, driven partially by big data concept and "dirty data" that doesn't fit well into the relational model. These databases go by the terminology of NoSQL, although the name's a bit of a misnomer since content can still be queried.

Two primary types of databases using the NoSQL model are document-based and map-reduce indexes. We won't spend an inordinate amount of time on these, but let's take a look at each of them briefly, and their applicability to various types of video platforms.

Document-Based NoSQL Databases

These databases use a JavaScript Object Notation (JSON) as a way to mark up a large document for later partial retrieval. Document-based databases rely on the premise that all the information about a given user should reside in a single document, rather than be spread across multiple tables as it would be in an RDBS. The idea might be to store all the videos a single user has consumed in one document, along with all pertinent contact information, so that the IT and training departments can easily find that information.

Document-centered databases work well when a few users have consumed large amounts of content, but the majority of users have not. An example of this would be Users A and C each viewing 100 videos per week, while Users B and D only consume 10 videos per week. In a traditional RDBS, there could potentially be a table for every single video, plus a table that contains users, while a document-based NoSQL database would only have one document per user.

Map-Reduce Indexes

The second type of NoSQL database creates a map of potentially pertinent information, then reduces that information in a series of pre-indexing steps. The reason for this mapping and reduction, followed by indexing of those key store values, is to speed up database queries.

In some ways the map-reduce concept is similar to the streaming media concept of "pre-fetching" content, where the first 5-10 seconds of multiple video clips are downloaded to the client's player ahead of time. In the case of streaming media, the idea is to allow rapid viewing of the beginning of any video a user chooses. From a database standpoint, the idea is to limit the amount of content the database query needs to search through, which in turn makes responses faster.

A map-reduce index might include not only the most popular enterprise video content but to also HTTP Live Streaming (HLS) or DASH segments for the most popular bandwidth and resolution combinations.

The other big benefit of modern database structures is something called sharding. Sharding is the process of spanning multiple servers in a database cluster, or even multiple clusters, in a way that balances the load of hundreds or thousands of simultaneous database queries.

Sharding not only allows an EVP solution to move beyond the legacy limited single server/ database structure, but also to create opportunity for solutions that need to take advantage of shared resources in the cloud

Hybrid vs. Fully Cloud-Based Solutions

That leads us to the last point in our exploration of next-generation enterprise video platforms: Hybrid solutions might be the best approach, but we're still in a state of flux.

There's little doubt that some things--such as simple transcodes, or even single-channel encoding--can be done better on premises. This use of resources is often referred to as "on prem," following the concept of telecom installations late in the last century, where phone lines were pulled into an enterprise location, connected to an expensive "middleware" box known as a PBX, which then routed calls to whomever the PBX had been programmed to route a given number to.

Along the way, companies began to look at the idea of having some services in the cloud, although they weren't called cloud services at the time. Many companies went to a Centrex model, which essentially virtualized the primary services of a PBX, such as call-forwarding, allowing for hundreds of handsets to be added to an enterprise location without requiring the company to buy a PBX capable of handling all those handsets.

The next move was toward VoIP, where the PBX was further virtualized, essentially using the data switch and router to create a software-only telephony solution. Every handset was nothing more than a data terminal, and any handset from an enterprise location could suddenly be moved around and plugged into a different Ethernet port without requiring someone to come in and program the PBX to a particular phone line.

Why the history lesson on enterprise telephones? Because we're moving in the same direction with streaming in an enterprise environment.

The end points in this case, though, should be thought of as both receiving and sending devices. In some instances, such as the smartphone or tablet, the same device can create content and consume different content. In other instances, probably for the majority of employees, only content consumption matters.

What's curious about the move within the EVP ecosystem, though, is the tendency of EVP providers to suggest skipping the middle step and going to fully cloud-based solutions.

"We consider cloud-native architecture a next-generation solution," one EVP vendor says.

This cloud-only approach should be fully assessed, as it often doesn't account for content created and consumed in the same location, instead forcing all content to the cloud first.

A better model, and one that enterprise will probably swing toward in late 2015, is the hybrid approach. The routing of content will be virtualized, as perhaps will the storage, but the use of on-premise appliances to generate content will regain popularity.

On the consumption front, the swing toward soft clients and apps may also see some moderation, with a new breed of set-top boxes emerging to fill the gap. We'll look at both of those options in the 2015 Streaming Media Industry Sourcebook's "State of the Enterprise" article coming in March.

One thing is clear as we enter 2015: Enterprise video platforms and delivery solutions are moving rapidly to catch up, in terms of complexity and even capacity requirements, with the traditional entertainment-focused media delivery platform. Scale on an enterprise solution, especially for some multi-national corporations, could easily meet or exceed that of an entertainment platform, and we suspect enterprise will solve the issue of multiple-device/ multiple-screen delivery at least a year before general entertainment solutions emerge.

Tim Siglin (writer@braintrustdigital.com) writes and consults on digital media business models and go-to market strategies. He is chairman of Braintrust Digital, a digital media production company, and co-founder of consulting firm Transitions, Inc.

Comments? Email us at letters@streamingmedia.com, or check the masthead for other ways to contact us.
COPYRIGHT 2015 Information Today, Inc.
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2015 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Author:Siglin, Tim
Publication:Streaming Media
Date:Jan 1, 2015
Words:2464
Previous Article:The OTT playbook: success factors for video services.
Next Article:The mobile video monetization challenge: the technology barriers are (almost) gone, so when will mobile video delivery be profitable?
Topics:

Terms of use | Privacy policy | Copyright © 2019 Farlex, Inc. | Feedback | For webmasters