A Broadcasters Guide to Microservices

Roger Persson

Author: Roger Persson

Published 31st March 2021

A Broadcasters Guide to Microservices

The word “microservices” has been creeping into the conversation about software-centric systems recently. Is it really a different approach, what does it mean, and what are the advantages?

Anyone who has ever designed a software device will understand the basic principles of modular design. It is easier to keep track of what the whole system is doing if each part of the processing is in a separate package of software. If you need to change the performance of that part of the process, then you should not need to change anything else.

Is microservices just a new name for modular software design? Yes, in the sense that they both build bigger functionality from individual elements, small independent pieces of software. In a good microservice design they can be very small: you hear people talk about a microservice as the smallest viable package.

One of the key differences, though, is that a modular software design results in an overall piece of software that is inter-related, and which runs on its own piece of dedicated hardware. Microservices are completely self-contained, with their own allocation of processing and storage resources sitting in a container. That means that the overall architecture is not confined to a single computer but can run across a network of hardware.

That is the essence of virtualisation. It makes the most efficient use of the resources available, and it allows for very high performance in a multi-processor environment (like the cloud).

But it does mean that microservices have to be orchestrated to do the right things at the right time, to get the work out that you need. So, at the lowest level, you need to schedule microservices.

There are readily available solutions for this, like Docker Swarm and Kubernetes. These tell the overall system that “I want these services to run on hardware with these properties”. This orchestration layer is important because it also allows the system to reschedule performance around hardware failures, keeping the applications running without disruption.

Then you need orchestration on the functional level, to determine what data the microservices need to exchange to get the output you are looking for, and how they talk to each other to achieve that. You might have a data microservice and a search microservice, and obviously they have to talk to each other.

That can be done using the familiar HTTP from the web, or a publish/subscribe system. In broadcast, we have long had the MOS protocol, which can do the job. At nxtedition we have developed our own powerful realtime system where all the microservices communicate.

Finally, there is a high-level orchestration, which sets out how microservices come together to create workflows. This is not standardised, but is part of the product. If you buy, say, a nxtedition system, then you get this orchestration layer in the package. Our solution is data-oriented rather than task-oriented, because that is the way that story-telling works.

That is the underlying basis of a microservices architecture. But what is the benefit? We have already mentioned one of the biggest gains: the ability to run in a shared environment. The whole system – software and hardware – is dynamically configured to do multiple things in response to user requests. Varying demands for processor power or communication bandwidth are automatically and instantly effected, assuming sufficient overall capacity is available.

That, in turn, is a key benefit of virtualisation, whether you run it in your own data centre or in the cloud. If you have a short-term requirement for a lot of extra processing power – realtime transcoding, say – then the microservices orchestration layer can dynamically allocate the necessary resources. When the short-term demand goes away, those processor cycles can go back to offline rendering for an edit suite, or running the payroll, or whatever else is housed in the data centre (or cloud).

A second important benefit is that, because each microservice is a complete, self-contained piece of software with a standardised means of communication with its fellow microservices, replacing or upgrading it can be simply achieved without affecting anything else.

Indeed, we do maintenance upgrades online for nxtedition installations. We add the upgraded version of the microservice, then replace the existing versions, with zero downtime and zero impact on the service level.

The cloud has been mentioned several times, so does this mean that the microservice architecture is only suitable for the cloud? It is an essential element of getting the best performance out of cloud services, certainly, but it is equally applicable to an on-premises data centre.

How do you decide whether to host your system locally or entrust it to the cloud? There are advantages to both approaches.

If you choose to use hardware on your premises, then you are not affected by the availability or performance of the internet. If you have workflows that depend upon high speed, high bandwidth internet transfers of very large video files, that can be a significant point of risk.

On the other hand, if you choose an on-premises solution then you have to build and maintain your own hardware. You may not have the skills to build a high-performance data centre, or you may not want the continuing overhead of maintenance. You may also not have a single base, or an increasing need for remote working.

A hybrid environment is a good solution. The public cloud can provide effectively infinite storage, the ability to scale instantly when you need peak performance, and the specialist power to run AI tools. With intelligent system management, you can move content between your building(s) and the cloud, for example keeping high resolution versions of your content remotely while having playout versions locally when you need them.

I hope this quick guide has demystified the microservice. In truth, it maybe today’s top talking point but, not far into the future, all systems will depend upon virtualised architectures and microservices.

Watch the full video here

Related Articles

Related News

© KitPlus (tv-bay limited). All trademarks recognised. Reproduction of this content is strictly prohibited without written consent.