How to Be a Cloud Computing Vendor

An executive at a Software-as-a-Service vendor talks about the issues involved with selling software over the Internet.


You Can't Detect What You Can't See: Illuminating the Entire Kill Chain

On-Demand Webinar

(Page 1 of 2)

Lately, it seems that people can't get enough of cloud computing: anything goes, from public clouds to private clouds to a mix of both.

Honestly, it seems like anything and everything using hardware virtualization automatically forms a Cloud and so everybody offers one. Trying to understand cloud computing is not the easiest task since all the heavy jargon confuses things even more.

As a result, it becomes increasingly important to deal with the confusion of cloud computing or hardware virtualization as it relates to Software as a Service (SaaS). And more importantly, SaaS platforms.

I want to touch on a couple of the things that SaaS vendors need to deal with so that we can better understand where I’m coming from. But before I do that first let me clarify something: all software delivered over the Internet is not created equal, but in fact falls into a “purity spectrum.”

Delivering software over the Internet is nothing new, but some of the purest, most robust forms of delivering software over the Internet are, in fact, new and are much better than traditional mechanisms. The idea of consuming software over the Internet has existed for a long time – if you remember we used to call the previous iteration “The ASP model.”

What really differentiates the old ASP model (at the less efficient end of the spectrum) from modern SaaS applications (at the more efficient end of the spectrum) is the architecture of the applications themselves.

Let me explain: SaaS is really just a game of numbers, and if you want to win the game or even play long enough to actually enjoy it, then you have to be as good as possible at fine tuning those numbers. Arguably, the most important number in this game is the cost of delivering a SaaS offering to your customer.

We generally refer to this as ‘Cost of Service.’ Essentially, it’s analogous to ‘Cost of Goods Sold’ in a product world; it takes a dollar amount of variable material input per dollar amount of revenue: the better the ratio, the better the margins.

In SaaS, having an inexpensive means to deliver your services (a good ratio) means that the odds of becoming and remaining profitable skyrocket. The reason why the ASP model failed and SaaS companies are gaining steam today is because SaaS companies figured out a much more efficient way to deliver software over the Internet.

As you’ll come to appreciate, the efficiencies in Cost of Service are directly related to how efficiently the software is delivered, which is directly related to how the application itself is engineered.

To continue the theme of efficient delivery, it really is all about how well you can utilize the resources available at your disposal; whether they are hardware resources or human resources or both.

The real magic is captured in two key words: customer density and automation. Customer density is essentially a measure of how many customers can be serviced from some well-known set of resources. For instance, if it takes one server or virtual machine instance to service a single customer (a throwback to the days of ASP), we have a 1:1 density. If my application is architected in a fashion where 50 customers can be serviced from one server or virtual machine, I’ve achieved a much more efficient density.

The denser you can run your application on the hardware resources you have available, the more efficient you’ll be at delivering the software and hence the better you will be at those numbers!

The next important measure, automation, describes how efficiently a SaaS company can grow and manage density on a well-known set of resources.

For example, an automated customer provisioning system allows a SaaS company to move from X:1 density to (X+1):1 density without a fixed, manually driven cost. This means that the application needs to become intimately involved with its own delivery by explicitly dealing with the density and automation problems within its own architecture.

ASP attempted to ignore this by sacrificing density and automation for ease of architecture, leading to its rapid (and thankful) demise. Looking at today’s SaaS enablement and “SaaS platform” landscape, it seems that some of ASP’s mistakes are being evangelized, but it’s the same unsatisfying gift with new wrapping paper.

Page 1 of 2

1 2
Next Page

Tags: cloud computing, services, virtualization, SaaS

0 Comments (click to add your comment)
Comment and Contribute


(Maximum characters: 1200). You have characters left.



IT Management Daily
Don't miss an article. Subscribe to our newsletter below.

By submitting your information, you agree that datamation.com may send you Datamation offers via email, phone and text message, as well as email offers about other products and services that Datamation believes may be of interest to you. Datamation will process your information in accordance with the Quinstreet Privacy Policy.