Shortly before the start of the SMPTE 2017 Technical Conference & Exhibition, TV Technology spoke with Darren Gallipeau, Zenium Program Director at Imagine Communications about his Thursday session “Microservices: Building Blocks to New Workflows and Virtualization?”
TV TECHNOLOGY: Microservices has become a buzzword in the industry when it comes to virtualizing media workflows. What are microservices and why are they important?
DARREN GALLIPEAU: Microservices, or a microservice-based architecture, is an approach to software development and deployment that isolates functionality into discrete and independent services. Where a traditional software approach may attempt to provide a given set of functionality inside of a large, bundled, monolithic application (or several large monolithic applications), a microservices approach isolates each of those monolithic application’s features into isolated services. To achieve an end-to-end workflow, these microservices are then chained together, each performing a discrete, isolated function.
The goal is lighter-weight, easier- to-deploy and easier-to-maintain services - not applications. This applies both to how software developers would approach a solution design, as well as how it impacts a larger enterprise deployment methodology. At both ends of the spectrum, there is a conscious and active intent to separate functionalities into their smallest reasonable elements —so when developers implement a solution, they will do so in such a way that the functionalities can be compartmentalized; and when an operations team architects and deploys a larger solution, they will leverage the exact same principals in their deployment.
Microservices offer a number of benefits over traditional software approaches, the most notable of which include greater flexibility, isolation, efficiency and collaboration. The granularity offered by microservices is the primary reason behind these benefits: a larger monolithic application is constrained by its initial application design, and can be very difficult to extend or modify its functionality without software development changes; whereas a microservices approach permits both more flexible end-to-end workflows, as well as easier modification or addition of new functionality.
The isolated nature of these microservices also serves to limit the risk or difficulty in making these modifications—unlike a larger, complicated, monolithic application, where any change has potential negative impact on the entire application. This granularity also means only the functionality required to fulfill the end-to-end workflow need be deployed (and purchased), compared with the inefficient (and costlier) use of larger applications where only a portion or subset of the application’s larger feature set is utilized.
Finally, microservices permit easier integration of new technologies or functionality into the larger workflow, perhaps from multiple vendors, as they do not have large portions of their workflow obscured by large, opaque “black boxes” typically associated with monolithic applications.
TVT: Is it possible to mix and match microservices from different vendors to create the workflow and performance characteristics desired—sort of like mixing and matching black boxes in a best-of-breed system architecture?
GALLIPEAU: Yes; this is a very important feature of a microservices approach. Microservices are typically designed to leverage standards-based interfaces and protocols. For control and monitoring, RESTful APIs and web services are typically used, and standardized IP-based protocols, such as SMPTE ST 2110, ensure multiple microservices can be used for the content itself, including those from disparate vendors.
The granularity of microservices, and departure from large monolithic applications, permits a more malleable and configurable workflow, as they give an opportunity for various vendors to be used for those isolated functionalities—rather than having a significant portion tied into a larger, rigid application.
TVT: Have microservices lived up to their billing as an enabler of customized media workflows? If so, what is a good example? If not, why not?
GALLIPEAU: I think the majority of the media and broadcast industry is still investigating and educating themselves about microservices. However, microservices have been leveraged very successfully in various other industries, including big data, social media and IT. It’s not a coincidence that we are seeing increasing disruption in our industry from nontraditional companies like Netflix, Facebook, Amazon and Google—these companies have been leveraging microservices for years, which have enabled them to spin up competitive offerings much quicker than we would typically see in our industry.
That said, there are companies who have invested substantially in microservices, to great benefit. A major content provider recently transitioned its entire broadcasting infrastructure to the cloud by leveraging Zenium platform, which is the pure microservices platform powering many of Imagine Communications next-generation product offerings.
TVT: You have written that “microservices bring a whole new level of potential collaboration to the broadcast industry.” Can you elaborate?
GALLIPEAU: In software development, there have been various attempts to facilitate better collaboration among organizations that are often competitive. Some popular examples used in our industry include service-oriented architectures (SOA), where separate monolithic applications communicate over a common service bus, and “plug-in” architectures, where small, isolated functionality can be created for use inside of a monolithic application, usually via a software-development kit specifically designed for the application.
These approaches do offer a decent level of interoperability, and by extension potential for collaboration, but are still limited by the large, monolithic applications used. Microservices can allow for the smallest piece of functionality to be updated or replaced, usually without disrupting or affecting other microservices in the workflow, and mean that at any part of the processing chain a new or updated microservice can be used.
