Application Mobility. Virtualize This.
by Don MacVitte, f5 | DevCentral
#ApplicationMobility holds a place in IT’s future. Check out this app virtualization and movement tool.
We in IT have spent a ton of time, ink, and electrons discussing server virtualization, and with good reason. Server virtualization did wonders for IT as an industry, offering hardware independence for older applications – many an OS/2 app that was necessary but not “cool” ended up on VMware to relieve worries that the hardware it was running on might break, and a lot of poorly utilized servers were consolidated. Meanwhile, we greatly ignored all the other bits of virtualization while they were growing up. Application Virtualization has been around forever, and yet we don’t spill barrels of ink about it. Many organizations use app virtualization, yet it gets third rank, talked about when talking about overall virtualization strategy.
That might just be about to end.
I recently had the opportunity to chat with Greg O’Connor of AppZero about their solution to application virtualization. It’s not the application virtualization of a decade ago, that’s for certain.
AppZero wraps up an application in a device-independent package. As long as you’re moving from like OS to like OS, you can move the application across the globe.
This may sound like not a big deal in the age of virtualizing everything (did you see F5’s press release about virtualizing the network for VMware?), in practice what AppZero is doing certainly is the type of thing that IT admins need, even if they don’t yet know they need it.
Consider moving an application from cloud A to cloud B. Do you copy the entire VM across the Internet? Do you reinstall everything and just copy the application bits across the Internet? Both are inefficient. Copying an entire VM – even with compression – can be expensive in terms of dollars because it is bits across your cloud, while both take an inordinate amount of time. In the case of installing everything and then just copying the app files, there’s the risk of human error also.
But what if you could install the operating system on the target, and then simply say “move my app”? That’s what AppZero is building toward. And from what I’ve seen, they’re doing a good job of it. Moving only the application means that you’re moving less across the network, but they also compress, so you’re moving really very little. Depending on the app, the savings can be huge.
While I no longer have the full-fledged test lab that we used to use to test out vendors’ claims, I did pop out to their “enterprise app store” and install OpenOffice directly. I also sat through a demo where an entire web application was shifted from Amazon to IBM clouds. The entire web app. While we were on the phone.
For my part, I prefer to talk about the parts that I’ve touched more than the parts I’ve seen. I’ve been through enough dog-n-pony shows to know there are a million ways for marketing folks to show something that’s not there yet… Or not there at all. So what I can touch is a much better gauge of product readiness.
The OpenOffice install was the fastest I have ever done. I’ve installed OpenOffice a few bazillion times, and this was the fastest. The amazing part about that statement is that all of my previous installs were from local disk (CD or hard disk, depending), this one was over a hotel network. I was attending meetings at corporate HQ, so sitting in my hotel room at night, I ran the installer over hotel wireless. Not the fastest environment in the world. Yet it was the fastest install I’ve done.
So what use do we have for someone like AppZero? It is time to start asking those questions. The “limitations” that Greg admitted to are not, IMO, all that limiting. First is the “like to like” requirement. I was (and you will be) unsurprised to discover that you can’t move an app running on Windows to a Linux server. While I’d love to see the day when we have that level of portability, first you crawl, then you walk. Second, in the web app world, the “app” you are moving is the web server, and it takes the directory structure with it, so you might end up with several web apps moved when you only intended to move one. Knowing that one means you can plan around it.
The mobility falls into two categories also. They wrap the application in a container for movement, and that container will run on your machine as-is. But it’s not running native, which causes some support staff to get touchy. So they provided a “dissolve” function that unwraps it and moves it to a 100% native install – registry modifications, copy to default directories, etc.
The one issue I did have a bit of concern about was that you have to choose which services move with the app. When moving you are presented with a list of services and you have to pick which ones go along. Hopefully they’re working on making that more mobile. Again, that does not figure into their “Enterprise App Store”, where they have pre-packaged applications, only to moving a live app.
Cloud mobility requires that you are able to bring up processing power on a new cloud to avoid lock-in. AppZero is young yet, but they show promise of filling in that gap by allowing you to package applications and move them along. Integration for large applications might well be problematic – if you move the web app, but not the database, or if you move the entire application and need to merge databases for example. But cloud mobility had to get started, and this is a start.
AppZero is relatively new, as is the “application mobility” space that they’re placed in by analysts. Lori and I were discussing how cool technology like this would be to enable “I have application X, it can run in Amazon, IBM, Rackspace, or the datacenter… What are the costs, strengths, and weaknesses of each?”
It’s going to be an interesting ride. We certainly need this market segment to grow and mature, will be fun seeing where it ends up. I’ll certainly be paying more attention.
Of course, F5 gives me a lot of leeway about what I choose to cover in my blog, but in the end, pays me to consider things in light of our organization, so I can say unequivocally that it doesn’t hurt at all that you’ll need global DNS and global server load balancing (GSLB) to take advantage of moving applications around the globe. Particularly the GSLB part, where a wide IP can represent whatever you need it to, dynamically, without waiting for DNS propagation.
But only for the server side. The desktop application side is very cool, and I’ll be watching both.
Meanwhile, Greg tells me they are taking the Enterprise App Store into beta next month. If you have questions, you can contact him at go connor /at/ app zero /dot/ com. After you remove the spaces and s// the //.