A broadcaster’s guide to microservices

A broadcaster’s guide to microservices

Wednesday, March 3, 2021

3/3/21

rogerpersson


https://www.youtube.com/watch?v=SbJgBoJu0m0



We have recently published a short video on our YouTube channel, aiming to demystify the subject of microservices. Our head of technology (and co-founder) Robert Nagy and senior developer Jesper Ek answer the frequently asked questions, clearly and simply. 



This blog post summarises some key points. Watch the whole video – it is only 13 minutes – to get the full story. 



What makes a microservices architecture different to modular software design? 



They are similar, because both build bigger systems from individual elements, small independent pieces of software. 



Perhaps the key difference is that a modular software design results in a system which runs on its own hardware. A microservice architecture produces small pieces of functional software which can run across a network of hardware, making most efficient use of resources. 



Do you need an orchestration layer to call and co-ordinate microservices to create useful workflows? Is this standardised? 



Orchestration can mean different things, dependent upon the context. 



At the lowest level, it defines how the different microservices are scheduled, on different pieces of hardware. There are readily available solutions for this, like Docker Swarm and Kubernetes. These tell the system that “I want these services to run on hardware with these properties”. This is also important in case any piece of hardware goes down, to reschedule around it and keep the applications going. 



Other orchestration is on a functional level, to determine how the microservices speak to each other to provide the functionality you are looking for. You might have a data microservice and a search microservice, and they obviously need to talk to each other. You can use regular HTTP or a publish/subscribe system. Traditionally in broadcasting you have MOS. 



At nxtedition we have 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: it is a part of the product. In nxtedition our solution is data-oriented rather than task-oriented for workflows. 



Can you get a microservices environment off the shelf? 



It is part of the design of the product. When you buy a server from nxtedition the necessary microservices environment is included. It is already set up with the service orchestration level. It will automatically configure itself to deliver the best performance from the available hardware. 



Does the microservices architecture deliver efficiencies and power? 



A traditional software environment needs one piece of hardware for each functionality. In a microservices system, the hardware is dynamically configured to do multiple things, delivering services in a shared environment. 



An important point about it is that each microservice is a complete, self-contained piece of software, which makes it much easier to replace if you develop new versions. You can update a single component without affecting anything else. 



Indeed, our users do not notice when we do maintenance upgrades. We can add the upgraded version of the microservice, then replace the existing versions, with zero downtime and no impact on the service level. 



Is it only suitable for the cloud, or can you build a microservices architecture for yourself? 



You can run microservices in the public cloud, or you can buy your own servers on premise, effectively creating your own private cloud. 



There are advantages to both systems. If your systems are on your premises, then you are not affected by the availability or performance issues with the internet. If you have workflows that depend upon high speed, high bandwidth internet that is a significant point of risk. 



On the other hand, on premises you have to build and maintain your own hardware, which you may prefer not to do. 



A hybrid environment is a good solution. The public cloud can provide effectively infinite storage, and the specialist power to run AI tools when you need them. It can also scale instantly. If your workflows require processor-intensive rendering, you can make a commercial choice to spend more on processing power when you need it. 



With intelligent system management, you can move content between your building and the cloud, perhaps keeping high resolution versions of your content remotely while having playout versions locally when you need them. 



https://www.youtube.com/watch?v=SbJgBoJu0m0



We have recently published a short video on our YouTube channel, aiming to demystify the subject of microservices. Our head of technology (and co-founder) Robert Nagy and senior developer Jesper Ek answer the frequently asked questions, clearly and simply. 



This blog post summarises some key points. Watch the whole video – it is only 13 minutes – to get the full story. 



What makes a microservices architecture different to modular software design? 



They are similar, because both build bigger systems from individual elements, small independent pieces of software. 



Perhaps the key difference is that a modular software design results in a system which runs on its own hardware. A microservice architecture produces small pieces of functional software which can run across a network of hardware, making most efficient use of resources. 



Do you need an orchestration layer to call and co-ordinate microservices to create useful workflows? Is this standardised? 



Orchestration can mean different things, dependent upon the context. 



At the lowest level, it defines how the different microservices are scheduled, on different pieces of hardware. There are readily available solutions for this, like Docker Swarm and Kubernetes. These tell the system that “I want these services to run on hardware with these properties”. This is also important in case any piece of hardware goes down, to reschedule around it and keep the applications going. 



Other orchestration is on a functional level, to determine how the microservices speak to each other to provide the functionality you are looking for. You might have a data microservice and a search microservice, and they obviously need to talk to each other. You can use regular HTTP or a publish/subscribe system. Traditionally in broadcasting you have MOS. 



At nxtedition we have 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: it is a part of the product. In nxtedition our solution is data-oriented rather than task-oriented for workflows. 



Can you get a microservices environment off the shelf? 



It is part of the design of the product. When you buy a server from nxtedition the necessary microservices environment is included. It is already set up with the service orchestration level. It will automatically configure itself to deliver the best performance from the available hardware. 



Does the microservices architecture deliver efficiencies and power? 



A traditional software environment needs one piece of hardware for each functionality. In a microservices system, the hardware is dynamically configured to do multiple things, delivering services in a shared environment. 



An important point about it is that each microservice is a complete, self-contained piece of software, which makes it much easier to replace if you develop new versions. You can update a single component without affecting anything else. 



Indeed, our users do not notice when we do maintenance upgrades. We can add the upgraded version of the microservice, then replace the existing versions, with zero downtime and no impact on the service level. 



Is it only suitable for the cloud, or can you build a microservices architecture for yourself? 



You can run microservices in the public cloud, or you can buy your own servers on premise, effectively creating your own private cloud. 



There are advantages to both systems. If your systems are on your premises, then you are not affected by the availability or performance issues with the internet. If you have workflows that depend upon high speed, high bandwidth internet that is a significant point of risk. 



On the other hand, on premises you have to build and maintain your own hardware, which you may prefer not to do. 



A hybrid environment is a good solution. The public cloud can provide effectively infinite storage, and the specialist power to run AI tools when you need them. It can also scale instantly. If your workflows require processor-intensive rendering, you can make a commercial choice to spend more on processing power when you need it. 



With intelligent system management, you can move content between your building and the cloud, perhaps keeping high resolution versions of your content remotely while having playout versions locally when you need them.