– July 29, 2022 –– After the recent announcements, Broadcast Pix’s entire product line is now software based, running on Consumer off-the-shelf hardware (CoTs), the next question is what about the cloud?

The short answer is, we can run the software in the cloud today, on a server instance in AWS for example, however, it is worth understanding both some technology principals as well as, perhaps more importantly, some of the business issues.

Let’s start with the technology.

Pretty much any software, such as ours can be used in the cloud by booking an amount of storage and compute power in AWS for example. AWS provides a console and sophisticated tools to manage the resources you need; manually turn them on, route signals, manually turn them off, etc.

A second type of software can be termed cloud ‘native’ meaning it was written specifically to run in the cloud. Typically, this means the functionality is containerized and can be automatically duplicated, to provide more power or functionality on demand. As requirements change, the software scales up and down automatically to meet the changing demand. Cloud ‘native’ software therefore automatically not only controls the duplication of itself, but also the cloud resources required to run it.

Cloud native software is great for applications where the requirements change fast and frequently and it ensures you always have just the right number of resources running for the task at hand, in theory, reducing costs.

But this is where we have to consider the business issues too.

AWS has an asymmetric pricing model; ingest or transfer to the cloud, storage and compute is relatively low cost, but egress is extremely expensive. The model is not designed for Media, but for compute and storage of data and databases not huge media files and there is no plan to change the pricing model as media only represents 8% of Amazon’s business.

In addition, the ‘on the fly’ compute and storage pricing is higher than longer term commitment pricing – it’s all based around utilization; if I spin up and down resources dynamically, as I need them, the price is higher than booking an instance for a week. AWS compute instances in turn are higher priced than buying and amortizing over longer term, on premises hardware.

So, what does this mean.

Generally, in productions we know what resources we need; we know how long the production will run, the number of cameras and what we want the output to look like, which in turn determines the graphics requirements, number of DVE’s, clips and still stores.

We can therefore determine the resources required for a production and book it in advance, or if we have significant productions in the pipeline, book a server in a co-lo facility, or even buy a server. These options are generally cheaper than buying on-the-fly compute and storage from AWS, before we even consider the very high egress charges to stream our content to its destination.

Because of this advanced knowledge and level resource loading required during a production, at this stage we are not intending to make our software cloud native as the inherent dynamic scaling is not required. If a customer does want to host in AWS, the Amazon consoles that allow you to manage resources are very complex and way beyond the ability of a volunteer run organization, so we are intending to provide some easy-to-use tools to turn on and off AWS resources for the duration of a production.

So our software can and will run in a public cloud, but is not and probably will not be cloud native. However, we remind our customers that this does not solve the issues of the expensive AWS egress costs, so be aware.

In summary, are we looking at the cloud? Absolutely, yes.

Do we believe that cloud is a viable solution? Technically, yes, economically, probably not.

If I understand the production I’m doing, I’m better off putting a known server in a colocation facility than going to on the fly pricing with Amazon, where I can’t control my costs.

It’s not a technology issue. It’s a commercial issue.