Skip to main content

Navigating the World of Cloud Apps

Al Kovalick

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.

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 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.

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.

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.