We`ve recently begun a series focusing on video within streaming. And we will get back to that in an upcoming article but first we`re going to take a detour looking at how Vimond VIA is architected to avoid vendor lock-in. Enabling the content owner to take full control of the best technologies in the streaming market. Assembling best of breed solutions interconnected through APIs and standards based formats. With the ability to expand and swap out components, and vendor technologies as needed. Traversing clouds and geographies. Without long and arduous development processes.
There`s many ways we can talk about how Vimond VIA breaks the monolith of vendor lock-in but in this article let's talk to one key point: where your content lives. And why we don`t care.
To get there let's first look at one of the guiding concepts in the development of the modern internet. Which is the notion of creating distributed systems working as discrete services across platforms and locations. While we won't dive deep into this, as it's a broad topic with a mandelbrot set of fractal permutations, the trend of internet applications is to be more decentralized. And distributed. Taking advantage of the asynchronous applications and user experiences that characterized the emergence of software as a service from circa 2004 and on.
Broadcast and the broader streaming industry, late to the game in embracing software as a service, is now driving head on to this shift with the pedal to the floor. Moving away from both monolithic software stacks and on premise hardware beyond such critical components as contribution encoders. And perhaps, if they're holding on tightly, their content itself.
Our core notion is that the central and unifying component in any streaming service is the CMS. In our case the world class Vimond VIA. Vimond VIA is where the assets are managed, regardless of physical location. Where the metadata is cataloged. Where playlists are created. Where content is curated. Where asset relationships are defined. The central point all other components spoke out from. But that doesn't mean all the ancillary services, data, or content, need to reside with the CMS. Neither physically nor logically.
With that notion it's clear that any modern and serious content owner needs to leverage software and vendor technologies that are easily replaceable. Extensible. Interoperable. Limited only in duration of use by the length of contract, and not some arduously long migration project. Wherein onboarding and off-boarding new components, or new vendors into an API based ecosystem becomes simple. A task of weeks, and not months.
Just as recently as the day of writing this we heard from a major network and streamer, “we`re currently using redacted and it really just isn't designed for modern streaming workflows. Most certainly not for live. And we`re moving away from them to an open API driven architecture.”
Broadly these are:
With Vimond VIA we've broken apart the monolith, living fully in the exiting dystopia of the roaring 20s. With a modern no lock-in architecture that achieves:
With Vimond VIA it doesn't matter where your content lives. Through API or feed ingest Vimond VIA provides simple and standards based mechanisms to ingest content. The feed ingest module lets you set up jobs to pull or push Atom feeds with all metadata and mediafiles into the Vimond VIA. Further the feed ingest allows you to import both external video streams and video files for download and distribution. Simply toggling the media:content tag’s type attribute indicates whether the media item is video or audio to download or an external stream.
Meaning if the content owner does not have a video pipeline in place and requires the video files to be ingested setting that attribute means Vimond VIA will ingest the video asset, processing it as we discussed last article in “Orchestrate Streaming Perfection Using Vimond” through a AWS Media Services based video pipeline. Comcast is a great example of this workflow. Providing us with links to high quality mezzanine files we ingest, process, and ultimately distribute to an origin with CDN to scale.
Or as we previously discussed with customers like Streamotion with their Kayo, Binge, and Flash services they came to us with their own video pipeline already in place. Whereby we ingest the content only as metadata pointers to their location. Residing fully external to Vimond VIA, while still benefiting from it`s slick user interface, scale, and powerfully easy organization of content.
Increasingly we`re hearing a good deal about single copy asset workflows. Emerging within the lucrative content licensing realm. Whereby a content owner with their own video infrastructure or even streaming service is licensing out content to a competitor or a streamer in another geographical region. And rather than distribute that content, transcode it, it can be ingested into Vimond as a pointer to the source, and played back externally from Vimond`s own cloud footprint. Reducing copying, transport, storage, and ultimately starting to approach a greener and more sustainable content distribution strategy. But this is new, and emerging.
In summation, we don't care where your content is stored because we have deployed a modern distributed architecture for Vimond VIA, future proofing in place.
So we`re ready. Already. Are you? Or are you locked-in?
PS. We've barely skimmed the surface here in how Vimond prevents vendor lock-in. We didn't talk about CRM. Billing Systems. Analytics. Front end consumer applications. Video Players. Recommendations. Payment. None of that. But we should, so keep reading and we'll get there. Or give us a call, an email, or reach out here ↓