Microservices To The Rescue

The solution to many of these challenges is the use of Microservices. Microservices is a generic name given to a software development method that arranges a program as a collection of loosely coupled functions (or services).

Loosely coupled is the opposite of tightly coupled. In the monolithic code description earlier the effects of tightly coupled interfaces led to the ripple down effect on the rest of the program. However, with loosely coupled systems, each component (or function) has little knowledge of the definitions of other components. Consequently, components can be replaced with other versions of the component that provide the same function with greater ease and reliability.

Unlike monolithic code, microservices, through loose coupling can exist on multiple platforms with different code base and interface methods. For example, the video processing function may exist on virtualized instances with GPU resource. The user interface code might call this as part of a workflow when the user uploads a video file using a messaging system such as RESTFul (Representational State Transfer) API’s.

Message Queuing

RESTFul is a hardware and operating system agnostic method of exchanging messages between software components. Webservices notably use this system through HTTP methods. Messages such as GET, HEAD, and POST (to name but a few) are sent from a web browser to server to send and receive web pages and information. Microservices use a similar method allowing them to take full advantage of distributed system programming.

This leads onto the concept of message queuing. Each component requiring a video processor will send a message to the video processing component. A load balancer, or similar middleware message processor can determine the number of messages in a queue for the video processor, and if there is too much of a backlog then it can spin up new instances of the service on a new virtualized server.

When the backlog of message queues has been serviced, the instances will be switched offline and then deleted. Again, greatly improving efficiency for the broadcaster.

As well as providing a system that can be massively and relatively easily scaled, microservice designs lead to greater programming efficiency for software teams resulting in much improved reliability and cost savings.

User Expectations

As new user requirements are continually expanding the size of the code base, monolithic designs soon become incredibly big and difficult to follow. Due to the tight coupling and associated ripple effect of this architecture, developers must have a picture of the entire code architecture in their heads when they start programming.

For new members of the team this can be incredibly intimidating, and for existing members it means that they must constantly increase their understanding of the whole design, even the areas of code their colleagues are working on that doesn’t necessarily affect them. This leads to inefficient allocation of highly qualified developers, and a great deal of stress and risk every time the code is recompiled.

As microservices are loosely coupled, many of these issues are resolved. Developers can work in small teams as each feature is considered a component in its own right and can be developed independently of the rest of the team. For example, if the video processor needs to be improved to work with Rec.2020 wide color gamut, then the team responsible for this service can work on and deploy the service as required. It will maintain its backwards compatibility with Rec.709 color space so the services calling this function will not require changing or notifying, so there is no re-compilation and consequently no ripple down effect.

Furthermore, if the developers of the improved Rec.2020 video processor decide it needs an updated GPU then this can be achieved without notifying the rest of the team. They may well mention it in their weekly update meetings but for the rest of the team it will not matter as their messaging communication is unchanged. In effect, this is treated as a black box by the rest of the software team.

Broadcasters benefit greatly from this design philosophy as it promotes flexibility and allows much easier customization. If a broadcaster needs to log events sent to a MAM service in a particular format as part of their logging and compliance requirement, then the specific logging service can be adapted without reference to the rest of the code. This allows the vendor to better understand the problem to be solved and cost the work accordingly. They also know the risk of side-effects and consequently the risk to the rest of the design will be greatly reduced, resulting in a much improved and reliable service.

Reliability, Scalability And Flexibility For Broadcasters

Being able to measure the number of services and the frequency they are used allows system integrators to be able to calculate with high levels of accuracy, the size of the hardware resource required. Furthermore, this promotes virtualization to take advantage of using pay as you go hardware resource, further improving efficiency.

Advanced logging and monitoring can be easily provided at the microservices level. The metrics help dev-ops and system managers to understand which parts of the system are working hardest, or not at all. All this leads to much greater efficiency, improved coding and consequently greatly improved reliability.

Microservices create the reliability, scalability, and flexibility broadcasters have been demanding for many years. The loosely coupled architecture further allows vendors to quickly and reliably build new services specifically for the broadcasters and use-case. And combined with virtualization and service monitoring, highly adaptable systems can be easily designed to further enhance efficiency and reliability for broadcasters.