Bob Dylan said:
“The times they
are a-changin’.” It
seems these words are
never out of date. Most
certainly this applies to
the changing landscape
of the media facility infrastructure.
Previous
columns discussed
cloud types and the advantages toward
migration. This column will focus on the
reshaping of facility applications or “apps.”
We’ve all manually installed software
applications on a PC or Mac. Media facilities
may have hundreds of desktop computers,
each with a few or many installed
apps. The cloud, however, is providing
new ways to deliver applications. These
paths offer marvelous benefits that, once
appreciated, make installed apps look old fashioned.
APPLICATION DELIVERY
Fig. 1 outlines the landscape for “application
delivery.” The term indicates the
methods to enable application access by
an end user. There are four basic domains
and they will be considered from right to
left. Three methods have some connectivity
to the cloud.
On the far right are embedded applications
on custom hardware, such as the
control logic and user interface for an
A/V mixer/switcher or the I/O crosspoint
control of a signal router. It’s unlikely this
class of app will migrate to the cloud for
some time.
A second domain (boxed in Fig. 1) represents
the traditional standalone desktop
with captive installed apps. These apps
have access to remote storage
 |
| Fig. 1: Methods of application delivery |
or file directories
from a local file server (NAS) or
a public cloud (such as Google Drive or
Box.com). Installed apps are not dead by
any means, but they are challenged by the
other models.
The third model has two associated
types: SaaS-based and Virtual Desktop.
Let’s consider SaaS first. It stands for “Software-
as-a-Service” and, from the end-user’s
perspective, is a Web app that (usually)
runs in a browser. It appears to run as an
installed application, but it’s not.
Incidentally, SaaS is a delivery model, not
a technology in the strictest sense. More
formally, SaaS is implemented as a Rich
Internet Application (RIA). For our discussion,
the SaaS term will be used informally.
“App pages” written using HTML5 and
associated frameworks deliver rich and
robust capability. In 2012, most SaaS apps
are being written using HTML5 and AJAX.
AJAX is not a programming language, but
a method to update the browser screen
without the typical page refresh interfering
with the user experience. Google’s
Gmail is written this way as are many
common browser apps. Legacy applications
need to be rewritten for display on
a browser.
The Virtual Desktop Infrastructure
(VDI) is a scalable and managed way to execute
programs running on remote servers.
Each target application executes on
a remote server and streams the “screen
image” to the client over a network.
The server(s) can supply a few or thousands
of end-users. Users consume apps
using low-end PCs/Macs or thin clients.
The heavy lifting is done on the servers.
VDI is ready for prime time and companies
such as Microsoft, Citrix, IBM, Desktone
and VMware offer products in this
space. Applications do not use HTML and
do not need to be rewritten to use this
model.
EXECUTING APPS
Naturally, there is a world of difference
between how Web apps and VDI apps execute.
In effect, both execute in a server
and deliver the application user interface
over a network.
Both types (SaaS and VDI) execute apps
in a data center (or private cloud) or a public
cloud such as Amazon Web Services.
In principal, an installed app, HTML app
or VDI app should perform equally well
across a number of metrics. Sure, performance
QoS will depend on network connectivity,
latency and available bandwidth.
In a future column, application QoS
will be discussed. For now, and there is
ample proof to conclude this, all three
models can perform as equals from the
standpoint of the end-user experience.
Finally, the fourth model is shown on
the far left of the figure. These apps are
typically written as native or in HTML5.
Native apps are easy to install and offer
optimized performance per mobile platform.
The war between these two methods
will continue for years. Of course,
native apps can have connections to the
cloud, too, but their logic runs on the mobile
device. One advantage of an HTML5
app is the ability to run on Android, iOS
and Windows Mobile devices without
change. Well, that’s the goal at least.
Walking the floors at the 2012 NAB
Show, I asked many vendors about their
cloud strategy for desktop apps. In approximately
80 percent of the cases new
apps were written in HTML5/AJAX and
cloud-ready. Initially, they may run on a local
server or even on a desktop, but they
could be moved to the cloud.
HTML5 browser apps also run equally
well on a PC, Mac or Linux device, thus
reducing the need for the vendor to develop
two or three different installable
versions. That said, HTML5 browser support
is still growing and not all browsers
support all aspects of HTML5. Legacy applications
are not easily ported to HTML5
and will likely run their course until decommissioned.
MOVING FORWARD
Application vendors should understand
these choices and most either support
the HTML style or the natively installed
style. Implementing a VDI solution
may cause angst to app vendors since: 1)
the app software executes on a server,
not under their specifications; 2) network
QoS issues; and 3) general support
aspects. For this reason VDI is not a common
choice for many media apps despite
its benefits of centralized execution and
management.
Media facility apps are starting to migrate
toward SaaS-style apps. Vendors may
decide to execute the app on local (data
center) servers or offer a public cloud
subscription model or both. Running SaaS
apps locally guarantees a level of QoS
that may not be available from the public
cloud.
Software developers know they must
develop cloud-friendly Web apps. Whether
they port to a cloud initially is a business
decision. However, in the long term
most new apps will be designed to work
on local servers or based in the cloud.
Al Kovalick is the founder of Media
Systems consulting in Silicon Valley. He
can be reached via TV Technology.