I Was a Cloud Service Provider, and Didn’t Know It!

I realized this summer that I was a player in The Cloud really early on. Yeah, me. The one who spent the last two years calling it “Clown Computing” rather than “Cloud Computing”. Yes, I will now fully admit that I was once a cloud junkie.

I will explain this in this post.
SoftwareWow
Tim in SoftwareWow shirt It goes back to the period 1999-2000. This was the peak of The DotCom Bubble. The company was a small startup in Boston called “SoftwareWow”.

Most of you reading this know me in relation to the Microsoft Application Virtualization product “App-V”. Microsoft acquired the technology when they bought the company Softricity, which had called the underlying technology and product SoftGrid back then. And while I was there at the beginning of Softricity to create the product, I was also at the original company that renamed itself as Softricity when it decided to become a software vendor.
The original company was named SoftwareWow.com. We were cool. We were bold. We were going to change the way that people dealt with software forever. Brian Madden recently found an old photo of me wearing a SoftwareWow shirt at the very first BriForum conference (shown on left).
SoftwareWow was a Cloud Service Provider. It’s just that the term Cloud hadn’t been coined yet. We thought of ourselves under the term “Software as a Service”. But looking back at what we were doing and what we think of as the Cloud today, we fit into that category. In the companies trademark filing, the business was described as :
Promoting the goods and services of others, namely, making available the software of others in a wide range of fields for temporary use by end users via a global computer network.
Huh? Just gotta love technology statement made by marketing. What we did is make standard Windows-based software applications available to be run by consumers, on demand, over the internet, controlled and stored from our internet data center.
We had a Data Center where consumers could remotely access software applications over the internet using our “Distributed Software Delivery Architecture” . The Data Center was nothing more than a cage in a hosting center near Boston providing power and internet, a few servers and a load balancer. While I had joined the company to run Software Development, somehow I ended up inheriting the Data Center and the team to run it. I actually built out a second Data Center in California and added a global load balancer, but on the day we were to light it up we pulled the plug on SoftwareWow to focus on Softricity.
The applications that consumers could access didn’t run on our servers. We stored them on our servers and streamed them over the internet to be executed on their local PC. While they ran without being “installed”, they were not virtualized apps with the isolation that is typically provided today. We just streamed down all the bits, scripted a registry import, and then cleaned up when the app was done.
These applications were all freeware/shareware apps, or time-bomb enabled “try before buy” versions of apps, so licensing of the applications were not an issue for us. Mostly these were games and small “productivity apps”.
The consumer needed an agent/client to make this work. We called this the “Wow Player” and it was a one time install. The running application would be framed in a window created by this player and it would add a banner advertisement so we could generate revenue.
While our Data Center was the backend, the front end that the consumer saw was one of many website partners we had. Consumers would go to a popular download site like ZDNet, which is now part of CRN, Lykos.com, and a bunch of others I have long forgotten. Click on a Wow enabled app at one of those websites, it ran a client javascript that checked to see if you had the Wow Player (and installed it if needed), streamed the app, and ran it. At the peak before we pulled the plug, I think we had 50,000 registered users.
I also had a team that took in application suggestions (from software vendors or partner websites) and did the packaging of the apps to place in the data center. This was basically a snapshot comparison process of before and after install. This was a free service to get the inventory seeded.
OK, so was this Cloud? The NIST definition of Cloud Computing lists five essential characteristics:
  • On-demand self-service
  • Broad network access
  • Resource pooling
  • Rapid elasticity
  • Measured Service
We nailed the first three, for sure.
Consumer customers accessing apps through partner web portals; on-demand self-service, check.
Available from any public internet connection; broad network access, check.
We had multi-tenancy with different partners sharing a single computing infrastructure in our back end; resource pooling, check.
We didn’t really have rapid elasticity, but that was because we had not grown large enough to need it yet. Two servers could meet the current world-wide demand for on demand apps. So, maybe not a check, but it would have been a natural progression.
We had implemented measured service, but choose to rely on the banner ads for revenue and not to charge based on usage; so measured service, also a check.
We either had, or would have added each of these “essential characteristics”.
NIST also defines three Cloud Service Models. “Cloud Software as a Service” (SaaS), “Cloud Platform as a Service” (PaaS) and “Cloud Infrastructure as a Service” (IaaS). We fell into the SaaS bucket, and in fact were using that term in the day. So, yes, we were a “Cloud Service Provider” using todays terms. We just didn’t know what to call it back then.
Of course, we failed as a CSP (but regrouped to do something way better). What went wrong? It was the revenue model.
Revenue from Banner Ads displayed at the client didn’t pan out as advertisers figured out they weren’t getting the sales boost from web banner ads they expected (not just from us, but across the board. The original banner sales pitch to advertisers was a less expensive way to get in front of people than print media. When there were only a few ads, consumers responded well, but once they started showing up everywhere on the web, consumers just tuned them out; the price companies would pay for this dropped significantly). Since we depended on that revenue, that sent us searching for a better business model.
Fortunately, we learned from those 50k users. One lesson was just how screwed up consumer PCs are. So we came up with App Isolation to avoid it. Another lesson was how slow consumer links are. The average user was running on a 12.4kb modem from their home back then. This led to adding client caching (so you only streamed once), as well as the unique “Jigsaw file system” of the SFT to enable the application to start executing before all of the files, or even all of the exe file itself has streamed over. Based on those lessons, we started Softricity and built the SoftGrid platform for others to implement.
What does this mean for CSPs today? I am not implying it means anything. Not only has technology changed significantly since then, the computing problems and opportunities today are vastly different than what we had ten years ago.

By Tim Mangan

Tim is a Microsoft MVP, and a Citrix CTP Fellow. He is an expert in App-V and MSIX.

1 comment

  1. Nice story Tim, and while I’d agree your conclusion that opportunities are indeed different today, but sometimes it feels that problems are – at core – still the same as we had in 10 years ago; at least in the PC land..!

Comments are closed.