The move to cloud-based computing models and cloud-based services continues forward at a breakneck pace. Seemingly everything is migrating to the cloud and along with that transfer there seems to be an assumption that the local capabilities of attached client devices, particularly the CPU, don’t really matter. The reality of the situation, however, is actually much different.
The quality of virtually any cloud-based service is directly impacted by the horsepower of the device you’re using to access it. Don’t believe me? Think about it this way. If the local CPU (and graphics) didn’t matter, you should be able to have the same experience when you visit a web site or other cloud-based service from several different devices across the same network connection. As we all know, that just isn’t the case. In fact, the experience can vary widely between different devices and one of the core reasons—pardon the pun—has to do with the computing power of the connected device.
Other factors can certainly make an impact too. Everything from whether the service is accessed via a dedicated app or through a browser, the choice of browser, the efficiency of the underlying operating system, the speed of the memory and storage subsystems, and more. The bottom line is, though it may not appear that way at first, cloud-based computing solutions are dependent on the speed of the attached client. In other words, cloud computing isn’t all about the cloud.
Part of the reason for this has to do with how web-based applications and services are created and delivered. Generally speaking, there is a split of the computing load between the server hosting the application or service and the local device accessing it. The amount of the split can vary tremendously, from, say, 90% on the client and 10% on the server, to the exact opposite (or more likely, somewhere in between). But even in cases where significantly more of the workload occurs on the server, the performance of the client matters, because the local device needs to render the results of any server-processed workload to the local screen (at the very least). Plus, in true “thin client”-type environments, where 100% of the work is done on the server and a series of pixels are sent down a network connection—sometimes called “screen scraping”—the local device also has to deal with the protocols used to take those packets and convert them into pixels on the screen.[pullquote]Even if you’re connecting globally, you’re still computing locally, and that’s going to continue to drive the evolution of devices for many years to come.”[/pullquote]
The issues can also go beyond performance. Even today, there are still some web-based application services that don’t run on certain operating systems or certain chip architectures. Believe it or not, the good ol’ x86-based PC is still the most compatible cloud computing solution.
There’s no question we’re seeing an evolution of computing models and more and more of the applications we use every day are moving to the web. When it comes to computing in the cloud however, even if you’re connecting globally, you’re still computing locally, and that’s going to continue to drive the evolution of devices for many years to come.
13 thoughts on “Computing in the Cloud”
Bill Joy famously said, “The network is the computer”.
I once winced at that statement, but in many ways, it’s correct. Like any computer, you need to know the bottlenecks. I’m glad you’re pointing out the importance of the client. Performance DOES matter. For many tasks and usage patterns existing tablets and smartphones suffice, for many others they don’t. This is despite all the spin of “experience” being primary. In that context, I can think of no worse experience than using an inadequate tool for a certain job. Many enthusiasts have come to know this first hand as they try to push the envelope.
Due to various dialogues here, I’ve been thinking lately on what it means to be a “personal computer”. You got me thinking into where the cloud fits in. When viewed as a “peripheral” it fits quite nicely. If “the cloud is the computer”, it’s the antithesis of what a PC is, and very much what a mainframe is. It’s not just about controlling the code and the data, it is also just as much about having physical possession, ownership, and control over that that code and data. Possession is 9/10ths of the law.
Thanks for a good read.
Thanks. Yeah, it really is about finding the right tool for the task at hand or even just the portion of the task that needs to be done at a given time. The wealth of options we have when it comes to tools these days can often lead people to want to try and simplify into focusing on one tool versus another and I think we need to take a more comprehensive view that lets people use whatever set of tools either they have access to or want to use. The tricky part, of course, is getting all those tools to work together well…still not quite there yet.
Right on, Bob. I would add that local storage of user content is much more important than people think, which, in this era of everything living in the cloud, may sound counter-intuitive. But our assumption that we can connect to the cloud at any time and always with sufficient bandwidth is not true. Think back to the last time you accessed the cloud while on a plane, in a hotel, or from the floor of a crowded conference. Our client devices should be able to buffer us against these connectivity problems. Caching, syncing and generally larger local storage should be part of the design of our clients so we can get the most out of the cloud.
Spot on. What would we think of our hard drives if they were as reliable as the cloud? The cloud excels at syncing.
The SSD in my Air13 has been a champ for 4 years, so I think maybe we’re about to enter a new “golden era” of reliable storage. Fingers crossed!
No only the durability of local storage, but the sporadic access of the cloud as well. Even with perfectly good hardware.
Thanks, yeah, you know, I was going to also talk about the importance of local storage as well and then ended up not. I’m glad you brought it up because I’m a big believer that local compute and local storage are going to continue being important well into the cloud computing era.
The other thing about local storage is that it consumes something like 5,000x less battery to access content from local storage than over a cellular radio. Right now, the Moore’s-Law-equivalent for batteries is a doubling of power-to-weight every 50 years, so I think we need to find ways to make out batteries last longer, and local storage can be a tool for that.
That’s a great point I had not thought of…thanks.
“But even in cases where significantly more of the workload occurs on the server, the performance of the client matters,”
You left out a very important piece: network lag. The amount of CPU that you can offload to a server out there is always going to be limited by network bottlenecks. Anytime that the human using the device is going to care about responsiveness or speed, then your cloud-based solution is only as good as the slowest network it will ever be used on. And a non-cloud solution will always beat it anytime you have to deal with slow or laggy (or non-working) connections.
Yes, clearly network lag is a huge issue for any cloud service. I specifically pointed out in the beginning of the article that even if you compare different devices across the same network connection (thereby equalizing the network impact), you can still see big differences in performance. But, with a bad network connection, that becomes the biggest impact on performance and everything else can become nearly irrelevant.
Well that was pretty useless. A marketing pitch obviously.
The main issue with becoming reliant on the cloud is connectivity. There’s still a lot of times I just don’t have the ‘net.