By Brian Boyko
Editor, Network Performance Daily
We were supposed to have the video of Dr. Steve Fulton we put up on Thursday night up by Wednesday afternoon. That didn't happen.
By coincidence, we also saw this opinion piece by John Dvorak, and linked to it the day before we needed the video to go up. The article, entitled "Don't trust the servers," talks about problems with Windows Genuine Advantage and how it illustrates the problems with SaaS solutions - that you're eternally dependent on a third party to continue to provide service.
In our case, we rely on Google Video to provide the bandwidth and hosting for the videos in our Whiteboard series. Now, you can say what you want about "getting what you pay for" and the like, but when we couldn't upload our video to Google, I realized how dependent I had gotten on their SaaS video hosting solution.
I couldn't log-in to upload the videos. At first I thought the problem was at my end - perhaps Symantec Anti-Virus had caused some sort of conflict or had firewalled off the ports that Google's video uploader needed. That wasn't it. Maybe it was something with our in-house network. That wasn't it either, as I found out when I took a copy of the video home and tried to upload it from both my Windows XP and my Linux partition. Nada. Zip. Zilch.
Despite the fact that Google's help files had a ready - and wrong - answer to every problem I came across, the problem was entirely Google's. And there was nothing I could do about it until they finally fixed whatever the problem was the next day.
See, while there are a number of video hosting solutions out there, Google Video and Veoh were the only ones that allowed me to upload clips more than 10 minutes long - and Veoh's playback was poor. Even if I could re-code the entire video at a lower resolution to lower the filesize, that didn't matter. Ten minutes was the hard limit on YouTube (also owned by Google) and other sites. My 25 minute video needed Google Video.
Eventually I was able to get the video uploaded, and though it took a while to process, it went up last night.
This isn't the first problem we've had with SaaS. Expensable.com often goes down for a few hours and we can't log expense reports. I use Gmail for my personal e-mail and while it's generally reliable, it does have some problems.
All in all, if you're looking at it from a productivity or a network performance view, moving your apps from the local network to a third party service - well, yes, it will absolutely save bandwidth and may make the network run faster for your other apps. But having a faster network doesn't mean anything if the end-user is waiting for a third-party service as long or longer as they used to wait for their slow-loading WAN apps. Or, in other words, you're not solving the problem of slow performance from the perspective of the end-user. You're just shifting blame.
This is not to rag on SaaS. I haven't lost an e-mail since I started using Gmail in 2004. My Flickr account saved pictures of my deceased friend John when my hard drive stopped working one day. And if it wasn't for YouTube, I'd never be able to show my parents in Virginia anything about my life in Texas.
But these experiences are a bit of a wake-up call that SaaS isn't going to solve every problem. Ultimately, the end goal of enterprise network performance is not to keep the network running as fast as possible, or to free up as much bandwidth. It's about finding the solutions which make the end-users more productive and enabling the company to do more as a result.
