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. This video explains what microservices are and why they can work well for media & entertainment.
In this video from nxtedition, Roger Persson introduces colleagues Robert Nagy and Jesper Ek to answer questions on microservices. 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.
Jesper explains that microservices are a type of modular software design, but with the lines between the modules better defined. 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, Roger asks whether an orchestration layer is necessary. Robert agrees this is for the best, but points out that their approach to an orchestration 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. This can work in real-time ensuring that the correct microservices are created for the workflow options being requested.
The ease of managing a live microservice-based system is explored next. 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.
As ever, there’s no one solution that fits everyone. The use of microservices is a good option and should be considered by vendors creating software. For customers, typically other aspects of the solution will be more important than the microservice approach, but deal-breaking features may be made possible or improved by the vendor’s choice to use microservices.
Lead developer & Co-founder
Sales Marketing Manager,