BREAKING THE MONOLITH-ONY?

A specific advantage a cloud based MAM offers is the de-coupling of services and functions that usually come bundled in monolithic systems. This allows broadcasters and content companies to handpick services that are most relevant to their workflows.

Migrating from legacy software and monolithic systems to the cloud has been a topic of debate for quite some time now, both in the broadcast industry and elsewhere. Many organizations, especially in the banking industry, have delayed the inevitable for years milking the lifecycle of software systems that was on its last legs. While an IT modernization project may incur a significant CAPEX, it is mitigated by lower OPEX in the long run if organizations choose to move away from monolithic systems. Nick Rockwell CTO of New York times recently acknowledged the cost benefits when the company announced its decision to move from its own servers to the public cloud. While companies are open to this, they are looking ahead to ensure that the end of every lifecycle doesn’t mean project costs running into millions or billions of dollars and years to build.

“MAM is dead, let’s talk supply chain”

In an excellent panel discussion led by Jon Folland at IBC 2015 titled “MAM is dead, let’s talk supply chain” he examined why MAM systems are undergoing an identity crisis of sorts and how downstream consumer technology is influencing how content has to be created, managed and deployed upstream by broadcasters. In the broadcasting world, the move to tapeless workflows began around the turn of the century. However, most broadcasters who opted for monolithic systems did so because the way content was distributed and consumed was linear. The digital explosion of platforms and devices means consumption of content has evolved from a single device to multiple devices and screens. As a consequence, the broadcast industry is forced to keep pace with the way consumers adopt and use technology. In an industry that’s in love with labels and definitions, MAM as a term has metamorphosed, from meaning something that controls and accesses digital assets, to a behemoth that is an umbrella term for a variety of functions, right from ingest to playout.

A monolithic MAM system typically comes bundled as a single offering and is usually installed on premise behind a firewall. While content and media assets are central to every broadcasters core operation, MAM systems continued to be a siloed system that was separate from the rest of the business. In most cases, it was shoehorned to work with other services through custom integrations. In order to accommodate the needs of different teams and functions, their UI’s tend to become cluttered and overwhelming for users.

“Looking at a specific advantage a cloud based MAM offers is the de-coupling of services and functions that usually come bundled in monolithic systems.”

As stated above, the digitization of content and a globally dispersed network of teams, vendors and fulfillment partners, the case for installing a cloud or hybrid MAM as opposed to an on-premise MAM is gaining currency. Thanks to how digital natives like Netflix, who are not shackled by legacy systems in the same way as traditional broadcasters, have embraced the web and taken a cloud-first approach to content management. One caveat for Broadcasters is not to mistake a monolithic MAM deployed in the cloud to be the same as a cloud MAM. Advantages of a cloud infrastructure include the ability to scale, support multiple platforms, handle complex business requirements and shorten time to market. Looking at a specific advantage a cloud based MAM offers is the de-coupling of services and functions that usually come bundled in monolithic systems. This allows broadcasters and content companies to hand-pick services that are most relevant to their workflows.

To truly benefit from moving to the cloud it is important to take advantage of the flexibility in architecture that it offers. While this sounds easy in theory, it is quite difficult for both broadcasters and traditional MAM companies to implement in practice. The way software is built has changed and broadcasters and service providers need to shape up or ship out. Usually, this means building everything from scratch which can be a scary prospect for many. Instead of taking the baptism by fire route, we only need to look around to see how the digital natives are building their products and taking advantage of the cloud.

One practice that is gaining currency is the use of microservices. A successful example of microservices is Spotify . They have built autonomous full stack teams that are structured in loosely coupled parts. In addition to the advantages of cloud deployment mentioned above, a microservices approach offers ease in the ability to test, deploy, and version independently decreases the chance of large failures. Microservices are not without faults either. They make it harder to monitor and increase latency. It is also not a magic wand to wave away all the problems associated with a monolithic system. A poorly structured microservices approach could make things worse.

“A poorly structured microservices approach could make things worse.”

So what are the options available to companies looking to migrate content management from monoliths into the cloud/hybrid deployment? One solution as discussed above is the microservices approach. Another possible solution lies in centralizing all content into a single repository and building services around it. An indicative architecture is outlined below to explain the idea.

The repository is used as a resource and accessed by different apps. Apps are services created or customized to meet the requirements of specific departments or workflows. For example, a trailer production app, an app for ordering content, an app for Ingest and QC and an app for playout or distribution. Apps work independently of each other and are connected to the content repository through a business rules layer or a message queue that allows it to make requests to the content repository. This allows apps to be replaced or retired as and when needed without affecting other parts of the system. Message queues are also preferable as even if an app goes down, it can retrieve message requests that were created when the app comes back up. Furthermore, to ensure that the core system is not loaded with too many queries domain specific communication protocols can be used.

Custom APIs can be developed so in the event that any part of the system needs replacement it can be done without having to rewrite the entire code that integrates with the replaced part. Having workflows distributed between multiple apps also means that each team or department can work independently, both with the same assets concurrently and work with improving and changing their parts of the overall workflows. A centralized content repository gives traditional broadcasters and content owners the control they are familiar with while separate services increase the efficiency of workflows and how different users interact with the system. This allows for custom views and UI’s for teams thereby improving the user experience while addressing the problem of clutter present in a monolithic system. This system would require complex infrastructure and care needs to be taken when packaging, deploying, scaling and operating application containers. But if done correctly can improve efficiency and productivity of teams while reducing costs.

“Preparation is key.”

Before transitioning away from monolithic systems building a robust architecture should be the priority for IT teams. Only once this is done is it wise to float an RFP. Preparation is key. But if attention and care are paid to both the big picture and the minor details a successful deployment can save broadcasters the pain of having to repeat this exercise every time technology shifts
the goalposts.

This guest post was written by Dinesh Damodaran, Sales & Business Development Manager at Codemill. Come see us in Vidispine’s booth 3.A23 at IBC and get a demo of Accurate Player, the frame accurate HTML5 media player, purpose-built for post-production QC/QA of video, audio, and subtitles.