CHAPTER 8

image

Cloud, On-Premise, or Hybrid? DAM Delivery Models

Option 1: On-Premise

Option 2: Private Cloud

Option 3: Public Cloud

Option 4: Software as a Service

Option 5: Hybrid

Storage and Archiving

When you buy DAM software, several possible deployment model options are available. Although DAM systems have been on-premise traditionally, cloud-based options have proliferated. When we say “cloud-based,” we mean to what extent a particular solution can be deployed in a cloud, by you, the DAM vendor, or a third party. While this solution is often portrayed as “just put it in the cloud,” it’s not quite that simple in practice.

As enterprises seek to decrease infrastructure spending and free up IT resources, the cloud has risen to the forefront on many agendas. Cloud deployments offer several advantages, such as ease of virtualization, elasticity, resource pooling, and scalability.

Cloud definitions vary, and there are many types of cloud services. You need to distinguish among private cloud, public cloud, SaaS, and hybrid models. The important point here is that all cloud models obviate the need to run DAM technology on-premise.

When vendors say they “do cloud,” this expression could mean a variety of things, which are outlined next. Then, for each vendor, we show whether it offers the following options.

Option 1: On-Premise

In the first scenario, you manage the software, usually in your own corporate environment, hence, “on-premise.” In what’s called a “managed hosting” environment, the hardware can be self-managed or managed by a third party. You own the environment, and there are no cloud characteristics or advantages such as virtualization—unless you set that up yourself.

In a third-party, managed hosting scenario, the vendor (or one of its partners) offers managed hosting on a traditional version of the software in a data center somewhere. You still have control over customizing, extending, and upgrading the software; the vendor is just replacing your hardware and network connections with its own.

One key consideration here—and a potential disadvantage of on-premise software—is whether the software is virtualizable, and if so, whether it has been certified with different VM platforms. Some on-premise data centers deal with application elasticity by employing virtualization services, an inherent feature of cloud deployment models.

Option 2: Private Cloud

Private cloud is similar to on-premise, in that you still manage the DAM software itself, and it lives behind some sort of enterprise firewall. Now, though, it runs atop a cloud platform that can bring typical cloud benefits such as virtualization, elasticity, resource pooling, and so on.

Therefore, you should examine some of the same architectural considerations of public clouds, particularly around whether the DAM software is certified to run in your particular flavor of private cloud stack.

Private cloud-based implementations require the same—or an even higher—level of skills and resources as are required for an on-premise installation.

Option 3: Public Cloud

In the third scenario, you put your DAM in a public cloud service, such as Rackspace, Amazon, or Microsoft Azure. You’ll find many variants here. You could host your DAM on-premise but take advantage of cloud elasticity for your asset delivery and transformation/transcoding infrastructure to support global delivery or spikes in traffic and file processing. Alternatively, you could host your DAM application in the cloud and keep your assets on-premise.

Note that the DAM vendor (or its partners) may or may not manage your relationship with the cloud provider.

In addition, the DAM vendor may or may not convert its one-time license fee into a monthly subscription model. As always, you will need to pay more money to the cloud vendor to achieve greater levels of redundancy, reliability, and global dispersion. Also, don’t forget the cost and hassle of virtual private network connections to your cloud instances.

As with the previous two options, you are still running “traditional software” as a dedicated instance, and you are responsible for whatever changes you make to the application, unless the vendor includes that as a managed service. Note that not all on-premise solutions work in the cloud today, and many that do have been certified with only one cloud vendor.

Option 4: Software as a Service

In the fourth approach, vendors have built a multitenant, SaaS solution from the ground up. Note that these solutions didn’t historically run in a public cloud but were hosted in the vendor’s own (redundant) infrastructures. Vendors are now offering alternative public cloud options such as Amazon, Google, and Microsoft Azure. However, even if they run their own hosting environment, they have the benefit of elasticity and monthly billing for hosting and the DAM application itself, with no initial license fees (however, you typically need to pay a setup fee).

Many of these vendors also serve as your “integrator,” and perhaps even agency, since they know their platform best and typically don’t have many partnerships outside development firms. They also take care of upgrades, which tend to come in frequent, albeit small bursts. Some customers are surprised to discover that they typically don’t have a choice of whether—or when—to upgrade.

Option 5: Hybrid

Hybrid installations are, as the name implies, a mixture of cloud and on-premise models, which can include any combination of one or more of the preceding approaches. You may want to have your software hosted and maintained by a third party; however, you may decide not to do this with your assets and data for security reasons. In a hybrid model, you can maintain physical control over your assets and data while using a cloud-based platform, in some cases approaching the maintenance and support features that pure SaaS brings to the table.

One popular use of the hybrid model is called cloud “bursting.” In this case, you use the cloud only for elasticity when you have spikes in activity or data. In bandwidth-intensive environments and when heavy archival needs are present, hybrid models are appropriate in DAM.

Many vendors now offer you the ability to “point” to on-site servers to access assets or back up data stored in the DAM system to a physical location (or multiple locations) that you denote. This combination of features from on-premise and cloud-delivery models goes some way to appease detractors who worry about throwing all their data into the cloud. Hybrid has had a slow uptake in the DAM industry, but we’re expecting provisions to increase in the space.

Table 8.1 summarizes all these features.

Remember, be wary of hosting companies and other vendor partners that take on-premise software and convert it to multitenancy to sell as a shared service to more customers. This approach frequently does not end well, since software designed for a single customer often does not have the right security mechanisms in place to run for multiple customers off just one instance.

Now let’s turn to some more general cloud considerations. In every case shown in Table 8.1, you need to address special issues and ensure that you have some key elements in place:

• Sufficient and secure network connections to your remote instances.

• Trust in the vendor’s security model and procedures. The vendor knows this and usually has strong controls in place, but you still should check.

• An awareness of the potential for outages or disruptions caused by other customers.

• An understanding of who is going to perform backups and where.

• A clear outline of who is responsible for each layer in the stack, including the following:

Network

Hardware

Operating system

Application server

Data

DAM applications: management and delivery

Caching and/or CDN

• A clear plan for handling authentication and authorization, including integration with on-premise identity management and SSO systems.

• Knowledge for how you will integrate with other enterprise systems if necessary.

• A plan for migrating your content out of the cloud in a non-proprietary format for you to use elsewhere if you change your provider.

TABLE 8.1 CLOUD DEPLOYMENT OPTIONS

image

Here’s the bottom line: vendors, consultants, and analysts throw around the term cloud loosely. Be sure you understand exactly what you’re getting when you sign the contract. The decision lines here are usually drawn by IT, based on their comfort levels.

Storage and Archiving

Storage management refers to the storage, retrieval, management, and eventual archiving of files and metadata. Every DAM must somehow manage where assets live, how metadata is stored, and the breadth of storage types that can be used with the system over the lifetime of the asset. Depending on the scope and scale of your deployment, storage management could be an important consideration. If you choose a SaaS or cloud system, you will not be as concerned with storage management. If you plan to install the software on premise, your IT group and the administrator will need to consider storage management.

Storage management includes

• The underlying mechanisms for storing, retrieving, and managing assets—files and metadata. Examples include database, files system, and raw disk partitions.

• The integration and management of external stores and storage types, such as spinning disk, near line, off-line, archival, tape libraries, storage area networks (SANs), network attached storage (NAS), and RAID arrays.

• The transition from one type of storage to another or one state to another. Examples include transitioning from live to archived or archived to live.

DAM Storage

Storage costs seem to be dropping each year, but given the vast quantities of audio and video media companies are dealing with, storage is a big-ticket item for broadcasters, and they strive to achieve an optimal balance between storage cost and performance. Following are the different types of storage media companies may use:

Broadcast storage: A video server stores high-quality media files intended for immediate playout. These servers are meant for high performance and are specifically built for broadcast purposes; not surprisingly, broadcast storage is the most expensive among the different storage alternatives.

Online storage: In this option, frequently used files or files that were just ingested are stored. These files are used in the content production process and multiple users access them. Examples of online storage solutions include NAS, SANs, and high-end disk array systems optimized for fast read-writes.

Near online storage: Also called near-line storage, this type holds occasionally used videos (such as IDE disk drives). Disk access speeds are slower than online storage. These videos are meant to be accessed by a limited number of users, but this option is less expensive than online storage.

Offline or archival storage: This option houses infrequently accessed media files and programs that were broadcast and are maintained as archives. Examples of solutions include robot-arm-operated tape libraries and CD (or DVD) jukeboxes. This is the cheapest form of storage, but it also has slower access and retrieval.

For broadcasters, storage management entails balancing cost, frequency of use, and accessibility. A storage policy determines which media files should reside on what type of storage, and how and under what circumstances they should be transferred to the various storage options. As you can imagine, a storage policy could range from simple with a few basic rules to very complex, involving multiple different sites and rules.

DAM systems can be used to handle simple storage policies and provide necessary file management functionality. However, when complex storage policy implementation is required, it is usually done with a combination of DAM and a hierarchical storage management (HSM) system. When DAM is integrated with an HSM solution, the HSM handles file movements and retrieval in the context of the broadcast workflow.

On the surface, storage management appears largely concerned with what physical storage a DAM system can support and the physical storage location and type of storage for each asset’s file. It also deals with the system’s capabilities to manage, monitor, and handle problems when accessing and moving assets among various storage types, and with the logical view of an asset, which means hiding its underlying physical location to the end user while making it easy for an administrator to manage. For example, if you are using SAN or NAS storage, you need to determine if the asset management system can handle it and how transparently.

Database Storage

Most systems use a database to store metadata and a managed file system to store the asset’s files. Systems typically support Oracle, Microsoft SQL Server, an open source database such as MySQL, or in rare instances IBM DB2. Be sure to check that the vendor supports your flavor of database.

The asset management system supports a file store, which is typically (but not always) a managed file system. It takes over either a raw disk partition or some section of the file system in which to manage assets. It should provide a range of capabilities for monitoring the capacity, use, and utilization of the file store. Additionally, it should be able to allocate new file stores, determine when to migrate, and balance between clustered storage.

Distributed File Stores

Some systems support distributed file stores. For example, some assets live in New York, whereas others live in Los Angeles and the archive is in Des Moines. The system manages references to remotely stored assets. If the system doesn’t directly manage the asset, such as a very large video that lives in a remote SAN, it does its best to maintain access and resolve access problems. Key issues in distributed storage have to do with asset accessibility and movement. The goal is to minimize the movement of the actual file, using proxies whenever possible. You should move the file only when absolutely necessary, such as with video workflows. Many of the storage vendors that provide technology to the broadcast and film industry have specialized storage systems that integrate well with asset management systems.

Archives

Enterprise DAM systems generally need deeper support for storage management. They typically integrate with and support a variety of storage types and are more fluid in moving media among them. An administrative console controls movement and changes of state. These systems also may provide some degree of automation and scheduling. Systems vary in their support for archiving, integrating with, or handling a variety of storage types. Some organizations have very specific needs for “deep archiving,” which certain vendors support; be sure to ask about this capability if it is important to you.

Cold Storage

In what could be considered a manifestation of the ideas behind hybrid implementations, we see the DAM community beginning to adopt cold storage as an archive option, allowing for cheap mass storage of assets and data that are no longer in active use. AWS Glacier is the most commonly used medium for cold storage, which is being used to store terabytes of inactive data for a number of DAM vendors. Buyer beware: This is only a cheap option if data remains “cold,” and should not be considered for archives that are frequently accessed to reactivate old content. If you want a cheap and simple way to push a large amount of data somewhere for “safe keeping,” cold storage might be part of your strategy.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset