Startup Framehawk, which counts a former NASA physicist as a co-founder, uses desktop virtualization and its own communications protocol to safely extend corporate apps and data to tablets and smartphones.
Leave it to a rocket scientist to provide one of the most promising approaches to solving an IT challenge tantamount to landing a human on Mars. But that's just what a former NASA deep-space-communications expert and his real-time data delivery co-founder may have done with a startup that aims to resolve the dilemma of extending corporate applications to the edges of the anywhere, everywhere, and anytime workplace.
It does so in a conceptually simple way: Taking desktop virtualization beyond its bottlenecks--sending pixel-based images of data instead of the data itself via its own, new highly efficient communications protocol.
The co-founders are Stephen Vilke and Peter Badger. Their company is Framehawk. By declaring the four-year-old San Francisco startup a success after its barely gotten off the ground, I boldly go where no one has gone. But I'll risk being wrong, if only to launch a healthy debate about the growing number of mobile device management alternatives, including the recent dual-OS solutions like the one that being proffered by ARM as featured on InformationWeek's Valley View Webcast.
To understand where Framehawk is heading you have to understand the career trajectory of Vilke, the company's 41-year-old CTO, and Badger, its 44-year-old CEO. Vilke was a NASA physicist who worked on developing data reduction and graphic display software for spacecraft communications. (Think of Voyager as mobile device!) He connected to Badger during a stint at Barclays Global Investors, where they were worked on developing high-security, real-time data systems used for stock market trading.
They found themselves spending years of their respective careers trying to resolve the latencies encountered by client-server networks. Eventually, they came to see desktop virtualization as key to real-time performance. In 2008, they left Barclays together to start a self-described "better-Citrix" VDI company of their own--only to be waylaid by the Great Recession. That, in turn, sent them on their way to consulting companies on a variety of VDI solutions, at which point they came to two revelations.
The first: "VDI vendors are terrible," Badger told me. They represent a slow, bad user experience caused by unreliable mobile networks and the core TCP communication protocol, which is optimized, as you know, for accuracy not throughput. The second: Along with the smartphone, the tablet especially would forever change the complexion of corporation applications.
So Framehawk's space communications wizards--like Vilke, the company's core R&D team came from NASA--created their own UDP-based protocol that, the company claims, is fast and consistent even over low-bandwidth networks with highly variable latency, loss, and jitter. They call it Lightweight Framebuffer Protocol, or LFP, in the alphabet-soup argot of these things.
Framehawk works like this: Corporate data and apps feed into Framehawk's server platform--with, get this, the whole shebang remaining behind the corporate firewall. Its architecture sends neither application nor data beyond. Instead it transforms the output into an image that's sent to a tablet or smartphone.
InformationWeek Elite 100Our data shows these innovators using digital technology in two key areas: providing better products and cutting costs. Almost half of them expect to introduce a new IT-led product this year, and 46% are using technology to make business processes more efficient.
The UC Infrastructure TrapWorries about subpar networks tanking unified communications programs could be valid: Thirty-one percent of respondents have rolled capabilities out to less than 10% of users vs. 21% delivering UC to 76% or more. Is low uptake a result of strained infrastructures delivering poor performance?
InformationWeek Tech Digest August 03, 2015The networking industry agrees that software-defined networking is the way of the future. So where are all the deployments? We take a look at where SDN is being deployed and what's getting in the way of deployments.