Microservices

Video: Standardising Microservices on the Basis of MCMA

Posted on by Russell Trafford-Jones

Microservices are a way of splitting up large programs and systems into many, many, smaller parts. Building up complex workflows from these single-function modules makes has many benefits including simplifying programming and testing, upgrading your system seamlessly with no downtime, scalability and the ability to run on the cloud. Microservices were featured last week on The Broadcast Knowledge. Microservices do present challenges, such as orchestrating hundreds of processes into a coherent media workflow.

The EBU is working with SMPTE and the Open Services Alliance for Media on a cloud-agnostic open source project called MCMA, Media Cloud Microservice Architecture. The MCMA project isn’t a specification, rather it a set of software providing tools to enable a move to microservices. We hear from Alexandre Rouxel from the EBU and Loïc Barbou from Bloomberg that this project started out of a need from some broadcasters to create a scalable infrastructure that could sit on a variety of cloud infrastructure.

Direct link

What is a service? Created a standard idea of a service that contains standard operations. Part of the project is a set of libraries that work with NodeJS and .net which deal with the code needed time and time again such as logging, handling data repositories, security etc. Joost Rovers explains how the Job Processor and Service Registry work together to orchestrate the media workflows and ensure there’s a list of every microservice available, and how to communicate with it. MCMA places shims in front of cloud services on GCP, AWS, Azure etc in order that each service looks the same. Joost outlines the libraries and modules available for MCMA and how they could be used.

Watch now!
Speakers

Loic Barbou Loïc Barbou
Consultant,
Bloomberg
Alexandre Rouxel Alexandre Rouxel
Data Scientist & Project Coordinator,
EBU
Joost Rovers Joost Rovers
Managing Director,
Rovers IT

Video: A Broadcasters Guide To Microservices

Posted on by Russell Trafford-Jones

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.

Watch now!
Speakers

Robert Nagy Robert Nagy
Lead developer & Co-founder
nxtedition
Jesper Ek Jesper Ek
Senior Developer,
nxtedition
Roger Persson Roger Persson
Sales Marketing Manager,
nxtedition

Video: Media’s Brave New World of Interop Microservices

Posted on by Russell Trafford-Jones

‘Microservices’ can have several meanings, but centres on the ability to create a workflow from individual building blocks using very simple, individual services/programs running on a number of computers. Microservices are generally understood to improve interoperability, which is one of the many benefits of a microservices environment that this panel explores.

Splitting your work into microservices promises to allow your products to be deployed in a more automated way and may help them work with a decentralised structure (where such structure makes sense). Because microservices are intended to be very simple, self-contained programs, you can be very specific about what you run and therefore only pay for the compute you need, in a cloud context.

Watch now Free registration required

Indeed, the cloud is pushing software architects in the right direction. Whilst cloud isn’t intrinsically microservices-based, it’s highly modular which promotes similar coding practices in developers as they would need working directly with native microservices. For instances, many programs have an Amazon S3 interface. Working to this type of standard API is exactly what is needed for microservice architectures.

One of the benefits to splitting everything into the simplest building blocks is time to market. This can be considered in two ways, how long take it takes to update/change an existing workflow and how quickly you can iterate. Both linked, being flexible in the workflow means you can quickly iterate when necessary; you don’t need a two-year project in order to update your way of working and the cost of failure is low.

What’s the alternative to microservices? Often referred to as a monolithic, it’s actually more about a having about mono-workflow. When your workflow is wrapped up into one product or binary, you can’t easily integrate new elements into this workflow. Microservices allow data to flow in the ‘open’ and allow the workflow be rerouted. Data at all different parts of the chain is available to any program that needs it.

The aim of the OSA looking at fundamental issues that can’t just fix unilaterally by one customer leading the roadmap with a vendor, rather it is seeking a wider agreement on how to interoperate between all these services.

Watch now!Free registration required
Speakers

Loic Barbou Loic Barbou
Bloomberg Television
Wes Rosenberg Wes Rosenberg
CTO,
Levels Beyond
Ankur Jain Ankur Jain
Prime Focus Technologies
Shawn Maynard Shawn Maynard
SVP & General Manager,
Florical Systems
Chris Lennon Moderator: Chris Lennon
Executive Director
Open Services Alliance

Video: Investigating Media Over IP Multicast Hurdles in Containerized Platforms

Posted on by Adam K

As video infrastructures have converged with enterprise IT, they started incorporating technologies and methods typical for data centres. First came virtualisation allowing for COTS (Common Off The Shelf) components to be used. Then came the move towards cloud computing, taking advantage of scale economies.

However, these innovations did little to address the dependence on monolithic projects that impeded change and innovation. Early strategies for Video over IP were based on virtualised hardware and IP gateway cards. As the digital revolution took place with emergence of OTT players, the microservices based on containers have been developed. The aim was to shorten the cycle of software updates and enhancements.

Containers allow to insulate application software from underlying operating systems to remove the dependence on hardware and can be enhanced without changing the underlying operational fabrics. This provides the foundation for more loosely coupled and distributed microservices, where applications are broken into smaller, independent pieces that can be deployed and managed dynamically.

Modern containerized server software methods such as Docker are very popular in OTT and cloud solution, but not in SMPTE ST 2110 systems. In the video above, Greg Shay explains why.

Docker can package an application and its dependencies in a virtual container that can run on any Linux server. It uses the resource isolation features of the Linux kernel and a union-capable file system to allow containers to run within a single Linux instance, avoiding the overhead of starting and maintaining virtual machines. Docker can get more applications running on the same hardware than comparing with VMs, makes it easy for developers to quickly create ready-to-run containered applications and makes managing and deploying applications much easier.

However, currently there is a huge issue with using Docker for ST 2110 systems, because Docker containers do not work with Multicast traffic. The root of the multicast problem is the specific design of the way that the Linux kernel handles multicast routing. It is possible to wrap a VM around each Docker container just to achieve the independence of multicast network routing by emulating the full network interface, but this defeats capturing and delivering the behaviour of the containerized product in a self-contained software deliverable.

There is a quick and dirty partial shortcut which enable container to connect to all the networking resources of the Docker host machine, but it does not isolate containers into their own IP addresses and does not isolate containers to be able to use their own ports. You don’t really get a nice structure of ‘multiple products in multiple containers’, which defeats the purpose of containerized software.

You can see the slides here.

Watch now!

Speaker

Greg Shay Greg Shay
CTO
The Telos Alliance