Promising to simplify programming, improve resilience and redundancy, Microservices have been moving into the media and broadcast space for several years now adopted by names such as EVS and Imagine Communications as well as being the focus of a joint project between SMPTE, EBU and Open Services Alliance.
Microservices are individual, independent programs that talk together to create a whole system. They stand in contrast to monolithic programs which have many functions in one piece of software. Splitting each function of a program into its own microservice is similar, but better than modularising a monolithic program since you can run any number of microservices on any hardware leaving you able to create a dynamic and scalable program across many servers and even locations.
The benefit comes from the simplicity of microservices. Modules can still be complex but microservices are small and simple having only one function. This makes testing microservices as part of the development workflow simpler and when it comes to extending software, the work is easier. Using microservices does require a well-organised development department, but with that organisation comes many benefits for the company. One thing to watch out for, though, is that although microservices themselves are simple, the more you have, the more complex your system is. Complex systems require careful planning no matter how they are implemented. The idea, though, is that that’s made all the easier due to the modular approach of microservices.
With so many small services being spawned, finishing and being respawned, an orchestration layer is usually needed. This can take many forms from ‘schedulers’ such as Docker Swarm or Kubernetes which take your instruction on which microservices are needed on which hardware with which properties up to more complex options which abstract the workflow from the management of the microservices itself such as in MCMA. This can work in real-time ensuring that the correct microservices are created for the workflow options being requested.
Each part is so small, and will typically be running several times, that services can be updated while they are live with no impact to the service running. You can bring up a new version of the microservice and once that is running kill off the old ones either naturally as part of the workflow (in general services will never run more than 15 minutes before being closed) or explicitly. Failover, similarly, can work simply by seeing a hardware failure and spawning new services on another server.
Because of this indifference to the underlying hardware, Microservices can be spun up anywhere whether on-premise or in-cloud. Cloud-only services are certainly an option, but many companies do find that low-latency, high-bandwidth operations are still best done on-premise close to the source of the video. The cloud can be used to offload peaks or for storage.
Microservices, like any technology, are not perfect for every situation and lend themselves best to large-scale solutions. Nonetheless, they are perfectly suited to many broadcast and streaming applications. Take a look these videos to learn more.