The Cloud is not Enough

Operators should ensure that ‘cloud native’ doesn’t mean cloud dependant when selecting management tools.

By Blue Lucy -

Cloud native, software defined, the metaverse; the media technology sector is awash with buzz phrases.  And, as with all popular terms which are used too liberally (and more often than not incorrectly,) the more you hear them, the less they mean.  As Ms. Thunberg might say ‘blah blah blah’.

Greta Thunberg discusses terminology in the media technology sector

While the actual definitions of these words and phrases may often be misinterpreted, they have very clearly defined industry connotations, categorising them as either good or bad: proprietary – bad, (boo, shake head) open standard – good, (nod positively).  But in the real-world – even this polarised world – sorting the good from the bad is just not that simple.

One phrase which I believe to be particularly misleading (not necessarily in terms of what it means, but whether it is an entirely good thing) is ‘cloud native’.  The statement “the platform is cloud native” is universally met with nodding approval by a conference panel, but is that orthodoxy, correct?

Microsoft define cloud native as: Cloud-native architecture and technologies are an approach to designing, constructing, and operating workloads that are built in the cloud and take full advantage of the cloud computing model.

By stating that a platform is cloud native doesn’t in itself satisfy some fundamental nuances of the cloud.  Does it run in any cloud for example? Is there a dependency on a function or service provided by a given cloud service provider? Such a platform may genuinely be described as cloud native (good) but also vendor dependant (bad).

Many, if not most, aspects of production and consumer content supply are moving inexorably to the cloud, (for many good reasons) and so vendors are increasingly keen to cast themselves as ‘all cloud’ (the future) and not old on-prem’ (the past). Equally, industry commentators talk about cloud and ground in the context of a one-way migration, upward.  But there are many systems and functions that are still on-prem – and which will remain that way in perpetuity, or at least for a good number of years.   Cloud native can become a problem, or at least limiting factor, in cases where it actually means cloud-dependant or where an overall system has on the ground, ‘on-prem’ systems or resources which need to be managed and controlled.

These ground capabilities are not always a transitory function or a ‘necessary evil’ – often they are an intrinsic part of the solution architecture based on the business need.  Equally, many media businesses have invested significantly in on-prem’ infrastructure in recent years and this investment may still be being amortised or, more likely, the systems are still serving a useful and reliable function.  In these cases, the clear business requirement is to integrate these systems through API-based connectors, not migrate away from them and thereby create the functional data gaps the industry has spent the last 25-years closing. Implementing a cloud native (good) approach in this instance risks creating technology silos which reduces workplace productivity (bad).

In the same way as the most modern studios contain a mixture of IP and SDI – based on which technology is appropriate to meet the business requirement – so the modern production and content supply chain will contain a mixture of cloud and ground systems and services.  Media operations management systems should not be cloud OR ground as even 15-years since S3 and EC2 first emerged, the cloud alone is simply not enough. Most of our BLAM deployments are (cloud-ground) hybrid systems – whether by initial design or through evolution – and in some cases the on-prem function is significant.

The shift may rightly be to the cloud, but hybrid solutions are essential for integrated operations in most current operations.  There’s no denying that cloud native has a lovely ring to it, but the reality of now is undeniably hybrid.

The CORE BLAM architecture compromises one or more of two entirely stateless services: the application programming interface (API) and the workflow runner (WFR). Each are (Docker) containerised and infrastructure agnostic. They run as efficiently in an on-prem VM as they do in the cloud.  This enables hybrid systems to be built which seamlessly connect traditional broadcast systems to modern cloud-based services and business systems.

By Blue Lucy -
Share this