In today’s world, when people think about the “cloud” in the context of applications, they often think of web-based apps like Google Office or Salesforce.com. While these are both great examples of cloud-based apps, they tend to cause people to think that cloud-based apps are the same as web apps. (Or that they’re *only* web apps.)
Cloud as a concept
No one has agreed yet on what exactly the definition of “cloud” is. Part of the reason for this is because it changes depending on the perspective of who you’re asking.
For example, IT Pros think of “cloud” in terms of a sort of unlimited, on-demand, flexible computing fabric that’s just sort of “there” whenever it’s need.
But when end users think of “cloud,” they’re really thinking more along the lines of “off premise” applications provided as a service. To them, a provider of cloud-based apps might not even use any cloud technologies. To a user, a vendor who sells them hosted Exchange is providing them with Exchange “in the cloud,” although to that vendor, they might just have a datacenter full of regular old Exchange servers.
From the end-user’s perspective, there are a few key characteristics of cloud-based apps:
- The application is accessible from anywhere.
- Maintenance tasks are not performed by the end user.
- Software is “rented” instead of “bought.”
Cloud as a technology
Continuing to think from the perspective of the end user, a lot of people automatically think “web apps” when they think of “cloud.” While it’s true that web apps are one type of application that can be rented from an off-premise cloud-like application service provider, the reality is that there are several different ways “cloud” apps can be delivered to users. For example, a cloud app could be a:
- Web app running via a browser
- Rich Internet App (Silverlight, AIR, Gears, Prizm) running quasi-locally and remotely
- Windows app running remotely delivered via a remote display protocol in an SBC way
- Windows app running locally, but streamed on-demand (App-V, InstallFree, ThinApp, etc.)
The reason I make a big the deal about customers thinking simple “off premise” apps are the same as “cloud” apps is because traditional Windows apps don’t really lend themselves to being ported to “the cloud.”
For years we’ve talked about how Terminal Services is kind of a “hack” to the Windows kernel, which it is, because Windows and Windows apps were never meant to be installed on one computer and accessed from another. Companies like VMware help us add a lot of cloud-like characteristic to our Windows application workloads, but unfortunately all Windows applications have to fundamentally run inside of their own Windows environment.
Contrast that to a “real” cloud app—perhaps one that was written for the cloud with the Google App Engine or something—and you’ll see that there’s a big difference in application architecture. For today’s Windows apps, the best we can do is use technologies like platform and application virtualization to add as many cloud-like characters into our non-cloud apps as possible.
So what’s my point?
If you separate the “concept” of a cloud from the “technology” used to deliver cloud apps, you’ll see that these two things are not necessarily related. In this is important because a lot of people talk about “cloud apps” when the really mean “web apps,” and so when they wonder about the impact and adoption rate of cloud apps, they’re really asking, “So when do you think web apps will replace windows apps?”
The problem we’re facing is that the corporate world is a Windows world. Yes, we can use web apps here and there, but the vast majority of corporate apps will continue to be Windows apps for a long, long time. Why? Would you rather use Outlook Web Access all day or regular Outlook? Of course you’d choose regular Outlook, because “real” GUI Windows applications are more responsive and rich and flexible than web apps.
There’s an argument to be made that Rich Internet Apps will change that, which could be true, but the problem there is that this requires companies to rewrite their apps for whichever RIA they choose. (And besides, people are up-in-arms over Windows Server 2008 R2 Terminal Services being x64 only, because it doesn’t support 16-bit apps, even though 32-bit Windows has been around for more than 15 years!)
Some people have suggested that with Microsoft’s “cloud” technologies, like Silverlight and Azure, that you won’t have to rewrite your apps, you’ll just have to recompile your apps. This is true. But a client-server desktop app compiled as a Silverlight RIA talking to an Azure-based database is still a “desktop” app, even if it’s delivered remotely.
And that brings me to my point: We are going to have Windows desktop apps for a long, long, very long time. But that doesn’t mean that we can’t take those apps into the cloud or get them from a SaaS provider. It just means we’ll get them from those provides via technology we’re already familiar with (remote display protocols, app streaming, etc.)
Answers to the most common cloud questions I get
I’ve been getting a lot of questions about “the cloud” and cloud-based apps over the past few months. So using the thoughts I’ve outlined above, I’ll answer the most popular questions I get:
Q: How long before Windows apps are replaced by cloud apps?
A: It depends on what’s meant by “cloud”? Apps delivered like cloud apps can be Windows apps, and we can get that today. All Windows apps replaced by some future app, like web apps or rich Internet apps, will be a long time away. 10+ years.
Q:How long until Google’s cloud office replaces Microsoft office?
A: Depends on what you mean by “replaces.” People like my mom are using it today. But most companies want a richer user experience that Google can’t yet deliver. And even when Google adds more features and has their office suite working offline, even then if they displace Microsoft office, great! Now how does a company deal with the rest of its hundreds of apps? If it takes a multi-billion dollar company like Google five years to write a version of office that could replace Microsoft Office, how long will it take before all our apps are rewritten that way? Bernie Madoff will be a free man first!
Today’s SaaS offerings are niche applications. Email. Word processing for your mom. Salesforce.com. Is this powerful? Yes! Transformational? Yes! But not yet.
Q: Are today’s Software-as-a-Service (Saas) providers the same thing as the Application Service Provider (ASP) concept form ten years ago?
Q: What about the “internal cloud?” How soon until companies are building those?
A: Again, this depends on which definition of “cloud” you subscribe to. If you’re talking about the datacenter architecture, you could argue that once you get 100% of your servers onto VMware that you now have a cloud. If you’re looking at applications, you could say that once you get all of your applications provided from the datacenter via remote display protocols or streaming, that you have a cloud.
Honestly the biggest thing that I’ve seen that turns a “datacenter” into an “internal server provider” has nothing to do with technology—it’s about the chargeback model. As soon as an IT department starts billing other departments for services provided, well, there you go!