Feed
Microservices are the building blocks on which all
modern and successful digital businesses are constructed.
It doesn’t sound much. A microservice is the minimum
embodiment of technology which provides a performant and valuable service. Yet
this software design architecture is instrumental to the spectacular success of
Spotify, Netflix, Expedia, Uber, Airbnb and essentially every other digital
business that gained commercial prominence in the past decade.
It’s an approach to application development and management
that is also seen as crucial to the transition of old school media – pay TV
operators and commercial broadcasters – to the brave new world of the Cloud.
The key word is ‘approach’ and not all broadcast or vendor
engineering teams are getting it right.
“Microservices serve a fundamental role in most aspects
of the software landscape for media and entertainment,” says Brick Eksten, CTO,
Playout & Networking Solutions at Imagine Communications. “Whether it is a
core network function, a piece of a website, or a utility that runs in the
background, there is an opportunity to improve that role or function through
the use of microservices.”
So, what is a microservice?
It’s used to describe the practice of breaking up an
application into a series of smaller, more specialised parts, each of which
communicate with one another across common interfaces such as APIs and REST
interfaces like HTTP.
“These smaller components can scale independently of each
other and the wider stack,” says Kristan Bullett, co-MD at cloud product and
services provider Piksel. “They are modular so can be tested, replaced,
upgraded and swapped out easily. It is also much easier to break down workloads
using microservices and spread them across the cloud, efficiently
matching resources more closely to business needs.”
A familiar example is the landing screen you face when
accessing a new service on a website which asks you to sign in with Facebook or
Google or email. Netflix build much of their operation from microservices,
dozens of which interoperate to provide the slick experience users of their
platform receive.
“The reason microservices are so great is because
typical software approaches rely on bulk installations, which must be upgraded
all at once (much like OS updates to phones or laptops),” says Alex Snell,
associate solution architect at system designers and consultants BCi Digital. “Microservices can
be changed as the provider sees fit, so a user sees different things between
visits to a platform, or even during a single session.”
In the broadcast facility, the same approach of bulk
software implementations exists. To add new functionality to a system, often a
month’s long provider acquisition and consultation period is followed by
further months of installation, testing, and finally launch.
“As speed to deployment increases, broadcasters want
upgrades to be faster,” says Snell. “If a system were built from microservices,
implementation of upgrades and changes can be realised in days, or even hours.”
Microservices contrast with the older broadcast model
which is typically characterised as monolithic. Essentially inflexible, cost
inefficient and no longer fit to compete with digital first rivals, any
organisation stuck with this model won’t travel far. A monolithic architecture
is where the functions needed to run operations are tightly interwoven so that
a change to one part of the software will have immediate consequences for the
rest.
“Microservices are really about making small changes in
a controlled and non-invasive fashion,” explains Bullett. “By taking a microservicesapproach
you have a much smaller slice of functionality which you can test and introduce
with great confidence into the wider service. Where cloud utilises compute,
storage and networking resources more efficiently, microservices-in-the-cloud
makes even better use of them, pulling down operating costs.”
While a number of workflow functions including transcoding,
graphics insertion and scheduling are harnessing microservices, it is the
macro benefits of the approach that are more important.
These include the ability to scale cloud resources, avoiding
the need to scale an entire platform that the applications are part of; the
ability to pick best of breed applications and scale easily with them; the
isolation of software development so developers can work on part of a service
without interfering with the rest of the stack; and the agility to update,
release and – if necessary – pull back a software release without impacting the
applications around it.
“Broadly, it’s about lowering the cost and the risk of
change while increasing flexibility,” says Bullett.
Cloud-native
Microservices could just as easily be called
‘cloud-native software’ since they are specifically re-architected for life in
the cloud. However, much of current cloud usage in the TV industry
is what is dubbed ‘lift-and-shift’. This is when developers which previously
married software with dedicated hardware simply port their existing software
into a datacentre, without any software redesign.
“There are crucial differences between how physical and
virtual hardware systems operate,” says Bullett. “Software designed to sit on
dedicated hardware systems will be constrained in what it can achieve in the
cloud. This ‘lifted and shifted’ software simply can’t scale as efficiently as
a ‘cloud-native’ solution. They lack the ability to tap into traditional cloud
characteristics such as elastic scaling, geo-dispersion and advanced process
automation.”
“The best ways to write software for the cloud doesn’t
necessarily change what the software is doing,” says Shawn Carnahan, CTO,
Telestream.
His company has spent the last 18 months taking the software
it ships today and migrating it to a microservice, often using the exact same
code.
Imagine’s Zenium platform, according to Eksten, allows its
customers, and partners to create microservices on demand. “Our
investment has been to develop a platform that allows us to develop at the
nano-services scale, one that maximises the philosophy of microservices,
while allowing us to maximise our return on R&D investment,” he says. “The
next step, where the community will become more involved, is to establish a set
of standards around how microservices interoperate at the network
level. It’s something we need as a community to move the collective
success of the industry forward.”
The EBU, a coalition of Europe’s broadcasters, is working on
this. The Media Cloud and Microservice Architecture (MCMA) builds on previous
work in the FIMS (Framework for Interoperable Media Services) project and aims
to develop a set of APIs to combine microservices in the cloud with
other in-house services and processes. MCMA will also share libraries
containing “glue code” between these high level APIs and low level cloud
platforms.
Supply chain methodology
According to Simon Eldridge, chief product officer, SDVI
Corporation a provider of software as a service solutions, the real
challenge is less about the technology per se but about an approach to
business.
“Traditionally, vendors have sold product with licences or
in boxes and broadcasters are used to buying boxes and licensing software then
amortising the expense over time,” he says. “When you move to an operations
model where you only pay for what you use it seems difficult for some
organisations to get their heads around this. Once they do, they immediately
see the benefit in only paying for the for services they require.”
He adds, “Essentially, in a real microservice environment
the end user gets to pick and choose the providers of each service from the best
of breed vendors, and plug them together in a way that lets them construct
their own solution, not simply turn things on and off from a single vendor -
that’s just software options on a monolithic application.”
Carnahan agrees, suggesting broadcasters need to shift
mindsets further toward trusting in software as a service. “The client doesn’t
know what machine the software is actually running on. There’s no sense of
permanence. The software only lives long enough to do the workload that it is
cast to do and then goes away. That is a very different concept from shipping
software that runs 24/7 but is chewing up power all day long while the customer
is paying off the lease it used use to buy the gear in the first place.”
It’s becoming more and more common for media companies to
consider what they do in the context of a supply chain – essentially receiving
raw material (the content), then processing, assembling and packaging it for
distribution to consumers, much like any manufacturing facility. But customers
need to get their head around the loss of control that comes with moving to
software as a service.
“They need to adapt to a supply chain methodology which asks
how much does it cost to produce and deliver a show, rather than how much will
it cost me to buy gear,” suggests Carnahan. “And instead of dealing in
thousands of pounds of capital investment the answer will be in fractions of a
penny per minute.”
Vendors, he says, can take care of solving that equation by
providing it as a service which delivers on the desired outcome - whether
quality, turnaround, reliability.
“Vendors are providing the infrastructure that sits
indirectly on top of a public cloud but its margins have to be sufficient to
sustain the business. In the end, the customer is probably paying more for
software as a service than if they had capitalised the hardware and software
themselves but the trade-off it that they don’t carry that capex and they have
far more options to change their business.”
The classic example is being able to spin up a channel in
days if not hours and if it doesn’t work, simply turn it off without ongoing
costs.
Don’t write off hardware
Can microservices solve all problems? Well, no,
as microservices are fundamentally a software solution to problems
that may be better solved in hardware. For example, Imagine’s
Selenio Network Processor is an FPGA-based, low-latency 1RU solution that can
handle simultaneous processing of up to 32 HD streams or 8 UHD streams. Can
you perform the same functionality in microservices?
“Absolutely, but the cost would be prohibitive,” says
Eksten. “The benefit of moving to a COTS architecture is based partially on
Moore’s Law: as compute power goes up, costs come down. We are at the point
where it is now financially and physically efficient to perform many, if not
most, broadcast functions in software as microservices — but not
every function.”
The move to microservices doesn’t have to happen
overnight, but it does have a “best-by” date associated with when giant player
like Amazon and Google will overwhelm any payTV or broadcast competition. You
are already seeing the effects of this chess match being played out by the
M&E giants and the IT market leaders. At some point it will
become a relevant discussion for the rest of the market. It’s not a question of
“if,” but a question of “when.”
How to switch to microservices in a few easy
moves…
The easiest way to get into microservices, at least
according to Imagine, is to purchase a microservices-based solution.
(Imagine has the major technologies covered, offering microservices-based
playout, multiviewer, encoding, transcoding and ingest solutions.)
Alternatively, you can explore microservices as
provided by a cloud vendor, since all major cloud providers layer their service
offerings on top of individual microservices. For instance, if
you wanted to try the captioning services from IBM or Microsoft, you can start
by sending files into the services, and in turn, those cloud providers can
provide back captions or captioned content.
The most common way to start building a microservices-based
infrastructure would be to select existing service/solution chains and start
swapping out individual components for ones based on microservices.
“That will provide you with a piece-wise method for stepping
into microservices,” says Eksten. “If, however, the customer
wants to move to a more pure microservices architecture, there are
many considerations to get from traditional rack/stack thinking to a process
and plan based on microservices.”
The first step is organisational. Eksten
explains: A pure-play microservices solution requires a team to
consider each service element (each microservice) as a logical unit of
functionality — what it is, what its requirements are, how it works, and
ultimately how it will be deployed and managed. This doesn’t necessarily mean
DevOps, but it does mean bringing together the right people. It
takes a diverse team with a broad skillset all leaning in to the same problem
to bring the right perspective and to ultimately be successful in moving
to microservices. Build a team that couples forward-thinking broadcast
engineers with microservices-savvy personnel, or find a technology partner
like Imagine who can provide the experience, expertise and engineering talent
to achieve a successful deployment.
The second step is to set goals, starting with small pieces
of the solution set. The first steps should be isolated, easy to measure, and
easy to replicate. I suggest starting with compressed workflows,
which allows everyone to get comfortable with failure/recovery modes and lowers
the overall infrastructure performance bar. One way to accomplish
this is start with a transcoder or encoder, both of which are flow-thru
solutions that do not require external timing and automation.
The third step is to begin building up the scope and
complexity of the deployment. Start looking at bringing in the third-party
services — like automation (if you are in playout) or monitoring solutions
—that you will use to manage the overall service. Having a plan for
orchestration, provisioning, monitoring, recovery and scale will allow you to
consider more complex solutions.
The last step is to tackle the more complex solution-sets
like playout. Moving from the simple to the complex is achievable
once you get into the habit of defining, designing, deploying, and measuring
each individual functional aspect of the overall solution so that you
understand where the dependencies are and what the recovery modes will be.
No comments:
Post a Comment