As we reported previously, a number of leading television vendors believe that when moving television and multiscreen video processes and workflow functions to the cloud, ‘simple’ virtualization of existing software is a sub-optimal approach. They believe that the software should be re-architected for life in the cloud in order to maximise agility, elasticity and scalability, and to minimise risks associated with innovation.
So what exactly is a microservices software model and what are the claimed benefits in more detail?
A microservices-based architecture breaks software into smaller units that each have a single, discrete responsibility that can function independently of the software around them and which makes up the rest of the stack. “A container-driven microservices architecture, as found in the cloud, shifts the design of systems from massive applications to discrete functions that are more operationally nimble,” says Harmonic in an e-book that it published called ‘PURE cloud gain: the competitive advantage with cloud-native media processing’.
[Harmonic is one of a small number of vendors who are publicly championing microservices today. Its VOS platform supports a unified workflow built around microservices, covering ingest, playout, graphics, transcoding, encryption and delivery. The ‘VOS Cloud’ product allows media companies to operate the workflows themselves in a private or public cloud. ‘VOS 360’ mirrors the capabilities but on a SaaS model in the public cloud.]
These smaller components can scale independently of each other and the wider stack. They are modular, so can be replaced and swapped out easily. Imagine Communications, whose Zenium microservices platform already includes over 500 commercial level plugins (high-level) and more than 1,200 components (low-level components that are used to build the high-level plugins), provides a neat summary of microservices.
“A microservices approach to application development is essentially a replacement or deconstruction of monolithic application design… It results in an application or component that is constructed of discrete services, each of which performs a specific, often simple, business capability or task…The piece parts can be replaced or updated as needed, or even reused in a separate application, without replacing the entire unit.
“A microservice typically runs in its own process and is coupled with other processes through a lightweight mechanism. Microservices can be deployed independently, or as part of a group or suite of actions. A microservices design enables the construction of applications that are formed through the coupling, or chaining together, of multiple discrete services… Building blocks can be linked and bonded using only the barest of management overhead.”
Brick Eksten, Chief Product Officer, Playout, Networking & Distribution at Imagine Communications, says there are incredible efficiencies when you use cloud-native [microservices-based] software in the cloud. You can scale up the resources you need in small increments. “A microservices platform gives you the ability to use every last ounce of compute and network efficiency.”
He adds: “It is easier to break loads down and spread them across hosts. It is easier to synchronise your microservices between different datacentres.”
This all helps with geo-diversity, like running operations on different sides of a country, and with disaster recovery (which could harness different cloud regions).
Clive Malcher is SVP Commercial Development at Piksel, a microservices pioneer that pivoted to this software model around three years ago for its multiscreen backoffice and metadata technologies. The company created a foundation framework upon which microservices are built, called Piksel Palette.
Malcher expands on the value of granular scaling. “The more granular you make your services, the more closely you can match the resources you need with what you actually use. If you can scale individual services in the cloud, rather than scale a larger piece of software, you lower your costs. If you are showing a pay-per-view sports event, you can scale the microservices that deal with ID management and authentication to cope with the rush of incoming visitors just before the game. Previously you might have been required to scale more of the platform.”
Mark Christie, Chief Technology Officer at Piksel, adds: “If that was an OTT service with a monolithic structure you would have to scale the whole platform. Now features can be independently scaled.”
Independent resource scaling has other implications. “There is a performance and reliability aspect,” Malcher explains. “If you have clear separation of functions, the resources required for one part of the process cannot impact upon another. There is no chance of contention.”
Imagine Communications has also highlighted benefits when it comes to resilience. Using a monolithic approach is like putting all your eggs in one basket, and a single failure can spell catastrophe for your entire operation, the company claims. “A microservices approach, where each egg is isolated in its own basket, better protects the organisation from losing service, as well as simplifying and hastening the repair process.”
You could afford to increase the thresholds on a service level agreement (SLA) if you do not have to apply the higher standards to every part of a software stack, Malcher suggests. That means you can achieve a higher safety margin, in terms of performance, for specific functions.
Because a microservices architecture makes small pieces of software relatively independent of each other, and decouples functionality from a larger (or even monolithic) stack, software development becomes easier. You can make changes to a microservice and then release them when they are ready, without reference to what is happening around the rest of the stack.
This is how microservices make an agile cloud environment super-agile. Application development teams can push ahead at their own pace. Where previously everyone aligned themselves to big software releases a few times a year, solution vendors and their customers – the television content owners and service providers – can implement updates on a daily or weekly basis.
As Merrick Kingston, Principal Analyst, Technology, Media & Telecom at IHS Markit (the research and strategy company), points out, if you are releasing software at this frequency it implies that the changes are very incremental. A change could be the addition of an API to pull metadata from a new source, or a tweak to the recommendation system. “Maybe it is a small change to the commerce engine that adapts the way you can package content,” he explains.
A daily update might include support for a new DRM mechanism. It might change the look-and-feel of the user interface that operations staff see.
Software development is less risky in this world. As Piksel’s Christie explains: “The more changes you make to the software at once, the greater the risk that something will go wrong. If you are making small changes you need less coordination across the business, the cost of making that change is very small and there is less planning.”
If something goes wrong, you can easily pull back the software release – without impacting neighbouring applications and the wider service. You do not have to pull back a stack-wide software release. “There is lower risk with this approach. You can deploy changes without fear,” Christie emphasises.
Eksten agrees. “A primary benefit [of microservices] is lower risk. Things that break tend to break on a much smaller level.”
Fast, fearless software releases mean more innovation for solution vendors and the content creators, curators and aggregators using their technology. It is not unusual for Piksel to release 15 updates across its microservices-based multiscreen and metadata software in a single day.
Merrick Kingston (IHS) adds: “Microservices gives you more of a pick-and-mix approach and it means you can work on particular services and not others. Agile workflows and continuous development are part-and-parcel of any bona fide microservices solution. It means you can innovate more.”
Kingston cautions that a move to microservices does not guarantee that you become more competitive in relation to companies like Netflix. “You still need a solid video strategy, but if you have that in place it will make its execution more feasible and less risky in economic terms.”
A microservices architecture is expected to encourage choice. Ian Massingham, Worldwide Lead, AWS Technical Evangelism (at the dominant public cloud provider) says it becomes easier to swap components in and out, and therefore change vendors, assuming there is transparency and well-documented application and service interfaces. This also makes it easier to use multiple vendors for similar jobs. HEVC encoding could be assigned to one transcoder vendor and H.264 encodes to another, depending on who performs best in each codec.
Malcher (Piksel) expands on this point. “The operations team could request that 300 content assets are encoded using a specific vendor or insist that the assets are encoded at the lowest possible cost.”
Mark Christie thinks microservices will have a powerful impact on procurement patterns in the multiscreen environment, breaking up end-to-end monolithic service stacks over time. “You do not replace one monolith with another. You address the pain-point in your business by provisioning a couple of new components.” This could mean a new DRM or new metadata technologies.
Photo: iStock/olm26250
More reading
This story is an excerpt from the new Videonet report, ‘How Microservices Take Cloud-based TV Operations to Another Level’, which goes on to explain the barriers to adoption for a microservices model, including some fairly dramatic organisational changes. It also addresses the options for migrating to microservices (and the extent to which media companies will use ‘lift-and-shift’ virtualization as opposed to microservices, and where it makes sense to re-architect software for cloud use, and where it does not. You can download the free 8,000 word report here.
