[IBC 2013 Talk] The Future of OTT Platforms
This year at IBC, I was invited by Vimond to take part into their Industry Visionaries talk series and discuss “The Future of OTT Platforms: Is it Diversification or Standardization ?” with Eric Schumacher-Rasmussen, Editor of Streaming Media Magazine. As the 45 minutes talk was quite consistent, I thought I could take the occasion to go over the topic here also, as a follow-up of some general guidelines I previously exposed in “How to build a Netflix-like multiscreen OTT service (part 1)“.
The entry point for this discussion was a controversial question from Vimond’s Henriette Sæther, who asked Eric and me if the reign of end-to-end OTT platforms was over. It did ring a bell to me as this end-to-end perspective had been a major issue in the premium OTT projects I worked in, over the past two and a half years in Europe and LATAM. In all projects, the content provider was searching for an end-to-end service/solution provider supplying everything from content preparation to frontend applications development with long term evolutive support – and in all cases it didn’t go this way in the real life for a variety of reasons which all lead me to the same conclusions :
– No unique service/solution provider can offer you the best solution in the various areas of the OTT platform, as the features scope is quite wide and requires substantial development resources in the long run
– It’s difficult to reuse existing developments and investments in successive generations of a service’s platforms
– No service/solution provider is currently proposing a canonical Services Oriented Architecture (SOA) platform on which you would have necessary control to make it evolve in its core as well as in the peripheral services
For sure, none of these objections would prevent premium OTT services to be built and to run successfully for a certain period of time. But at the same time, things could be better for services’ long term agility and balanced evolution. Let’s try to dig and possibly find how…
Where are we now with OTT platforms ?
Eric Schumacher-Rasmussen and Nicolas Weil
Today many content providers must change of OTT platform after the first implementation of their service (or even before first deployment) because it’s a dead end : either the platform is deceptive in terms of overall features coverage or missing sub-features, or it doesn’t evolve quickly enough compared to the competitive pressure of premium OTT markets. And we can’t really blame the content providers for this, as it’s always a very difficult decision to take when you have to choose your OTT platform service/solution provider: you are pressured by the competition and you need a fast time-to-market, and in the same time you would like to ensure long-term platform evolution capacity and technical control on it. Usually you end up with the solution offering the quickest time-to-market – or pretending so. You also end up with feature zones unfinished or finally covered with the help a third party solution – thus clearly challenging the idea of decent one-stop-shop OTT platform provider.
Once you have chosen a platform and implemented your service on it, you can encounter a variety of problems. Some of them are inherent to the platform itself:
– Limited extensibility and openness
– Limited reusability and interoperability with existing or planned investments
– Limited scalability across hundreds of thousands of users and multiple countries, languages, tenants, catalogs and payment gateways integrations
The others are somehow inherent to the vendor or to third party services:
– Limited to null influence on the vendor’s roadmap
– Difficulties to make external teams work to extend the platform at the necessary pace when the vendor is out of dev resources
– Various nature of the services to integrate and lack of standardization of their interfaces
But at the end of the day it all ends up in a situation where you must change of provider in a big bang mode, a costly and risky wipe-out if you are running a service at large scale…
How to overcome these challenges ?
I’m not pretending here I have the magic potion for all projects and situations, but rather some architecture tracks to study and some good practices spotted on the field. [Must read : “The Service-Oriented Media Enterprise” by John Footen and Joey Faust]
– Break the idea of a monolithic core of the OTT platform and adopt a SOA approach: each of the main modules (ingest, catalog, subscribers management, payments management, reporting, devices management, frontend apps…) might be provided by different vendors, including the workflow engines (media-centric and business process centric). All of these services might be driven by their API (no watch folders that generate untraceable jobs) and scaled in the SOA way through the use of Services Registry. The business services might be orchestrated through Business Process Management (BPM) which allows quick workflows refactoring, and the messages shall be dispatched and potentially translated through an Enterprise Service Bus (ESB). Same goes for the media services with a Media Bus specifically handling Resource Management (FIMS concept). Avoid direct component-to-component custom communication as much as possible. Establish clear SLAs for all subparts of your workflows, provision and scale accordingly. Here is an architecture draft for this approach :
– Adopt standard services interfaces whenever available in the vendor component and create abstraction layers between the vendor component’s API and the rest of your architecture when the API interface contract is proprietary. When creating services interfaces, always take a look first at the domain leader’s one…
FIMS Framework Reference Model
– Build media workflows based on current or upcoming standards: as regards the input, the Interoperable Master Format (IMF) will be a powerful vector of standardization when all studios will be using it as a mezzanine format sent to all OTT ingest chains – it’s still in the works but within one year it will probably be widespread as it relieves the studios from the burden of handling several output formats (it’s not a currently supported input format in most transcoding engines). As regards the processing, the Framework for Interoperable Media Services (FIMS) promoted by EBU and AMWA seems to be the best bet, as it is extending its scope of services interfaces normalization from Capture, Transfer and Transform to Content Repository and Quality Analysis – and gathers more and more industry traction along its way. As regards the output, go for a MPEG-DASH fragmented MP4 profile as the reference format for all your compatible devices and repackage/DRMize on the fly on your origin server platform (protected from CDN hammering by a forefront caching layer) from DASH or MP4 source files to legacy ABR technologies for all other devices. For MPEG-DASH streams, maximize device reach by applying on the fly Common Encryption (CENC) and multi-DRM wrapping.
– Be scalable: Netflix showed the path with all their contributions to the Amazon Cloud best practices and management toolkits. Now it’s your turn to deploy in a public or private cloud (OpenStack ?), while ensuring service continuity and dynamic capacity management. Your content preparation equipments running on-premises shall be able to burst transcoding peaks onto cloud instances, or even to fallback entirely in the cloud for uninterrupted production flow.
– Use open source: whenever possible, it’s generally good to use open-source solutions. FFmpeg is a good example of video OSS widespread in the industry, and we also can meet more and more platforms which go open-source, like Kaltura OVP for a long time, and more recently Wyplay Frog which primarily addresses Pay-TV but can be used to build full-OTT services. As regards video workflow use cases, my pick would be to wait for Netflix’s Odin engine, and for business SOA workflow I would check first the WSO2 suite (which could certainly be a good fit for a Media Bus also, with some FIMS specific evolutions). In all cases, it’s always less risky in terms of support to integrate enterprise-backed OSS solutions rather than the ones based solely on an independent developers community which can vanish quite quickly.
– Extend with SCRUM: this is a trend among some service/solution providers. They offer you to host/offshore a dedicated SCRUM team (with you as the Product Owner) in charge of developing all the product missing features for your needs, in advance of their potential productization. Good for time-to-market and efficiency, but potentially expensive. Be smart and try to re-internalize the maximum of developments (that’s where working on an OSS components basis is definitely a better fit).
That’s all for the advices, you’ll be really building a Netflix of your own, and even more, if you could follow all of them…
Pros and cons of modular OTT platforms
So what are you precisely gaining in going the modular way, and what are the risks waiting for you ?
On the one-hand, the shiny one, you are able to use a best-of-breed integration approach which avoids vendors lock-in and increases competition between vendors at first integration and further evolution stages. The fine-grained architecture can push the customization level of the platform quite high and closely match your service’s requirements, and in the same time allow you to replace components individually with a minimum of efforts as every integrated component is properly abstracted and decoupled from others. At the end of the day, your architecture provides you the maximum agility when it comes to setup quickly new complex workflows – business or media centric ones – and it also maximizes the reuse your existing investments through service evolutions.
On the other hand, the dark one, taking the modular approach may complexify your initial choice of OTT platform as you will have to include the SOA orientation in the bid. On the architecture level, you might end up with something very complex to manage, requiring a very skilled devops team, and the abstraction layers might introduce unwanted latency here and there. Combining components from various vendors will automatically generate extra project management burden and interoperability risks – and using too many open source tools might also push you in difficult support situations where you will have to fix bugs by yourself. Last but not least, the chances to see the prime integration responsibility transferred from the service/solution provider to you is high and it’s a heavy one to undertake, all the more than you might end up with a very long time-to-market if your integration plan is not fully comprehensive.
And So: Diversification or Standardization ?
With the approach I just exposed, you can benefit from both: you will get diversification as you will be able to easily integrate components which are not available in most OTT platforms out of the box, and you will also progress towards the standardization by using existing service interface contracts like FIMS and defining new ones when needed. This last activity shall be covered by international standardization bodies instead of yourself, as this is precisely the goal of organizations like EBU, ETSI, AMWA or SMPTE to come to agreements on media industry companies’ needs (taking the FIMS initiative as a model, which would be great to see integrated in EBU’s own OSCIED project), but it’s not very likely that an international standardization effort could encompass such different areas as payment gateways, recommendation engines or subscribers management systems.
So my view on this is that, in order to foster legal OTT services development in Europe and prevent these OTT services to wipe out their platform every 3 to 5 years, the European Commission should finance a pilot project (like HBB-NEXT) aiming at defining the missing standardized service interfaces and at building a jumpstart framework based on available mature OSS solutions in the various areas of the ideal modular OTT platform architecture. I’m sure we could gather a nice group of broadcasters, telcos, universities, partner companies and consulting firms to work on this, as the open source is now a powerful vector of innovation in the industry…
