Ten years ago, ASPs (application service providers) were the rage. Five years ago, SaaS (Software-as-a-Service) exploded. Lately, everyone is talking about cloud computing. Countless companies claim to provide one, some, or all of these. Some aspects of ASP, SaaS and cloud computing are very similar; some are very different. How can you tell the difference? I use two simple “acid tests” to figure this out.
That “blurry” starting point
ASP, SaaS and cloud all provide some basic common attributes: management of resources for you, broad access to many from location you do not need to own or manage, provision of service without needing your own IT teams, purchase without capital investment. However, from here the similarities end. Those differences that emerge greatly affect items of critical business importance: responsiveness to change requests, access to new features, and ability to scale quickly in response to increased demand.
Culling out ASPs from SaaS and Cloud providers
ASPs build, configure, host, and support applications on your behalf. One word, Self-service, separates SaaS and Cloud providers from ASPs:
The Self-Service Test: If a company needs to have software engineers modify code and provide a new build to provision your service, it is an ASP, “plain and simple.”
Many people who claim to provide SaaS and cloud computing are simply ASPs. Their software does not allow customers to pick, configure, and deploy the service without the intervention of software engineers. As a result, their teams (or partners) will need to commence (slow and costly) projects to make changes on your behalf. As a customer, this translates into: 1) higher service price, 2) slower implementation timelines, 3) slow response to changes, and 4) lack of automatic access to upgrades and new features (available to newer customers).
Culling out SaaS-based delivery from “True Clouds”
The line between SaaS and cloud providers is hard to see at the start. However, the line becomes clearer as you use the service more. One word, Elasticity, separates true cloud computing from basic SaaS-based delivery:
The Elasticity Test: A company is only a true cloud provider if it lets you scale capacity by 10x or more, without noticeable performance changes, with 1-2 days’ notice.
Many people who claim to provide cloud computing do so with software that only distributes some of the resources you need to scale. (True clouds distribute all of the resources). As a result, they need to commence an IT project, such as migrating data to a bigger database server, when one of their customers needs to support a dramatic increase in volume. As a customer, this translates into: 1) slower performance during peak demand, 2) downtimes for maintenance and upgrade, 3) cost spikes or delays to support things like big advertising campaigns, and 4) ability to only grow so big before you need a bigger provider.
Ask these questions, the next time you are looking at a “cloud-based” service
Then next time you are looking to procure a “cloud-based” service, apply these acid tests by asking the following:
- Can I implement this myself? If so, how long will it take me to do this?
- When you upgrade your service do I get the changes automatically (and for free)?
- Can I change [X, Y, or Z] myself? Does this cost anything? Can I do this without whenever I want and see the changes immediately?
- Can you provide a performance SLA for high and low usage periods? Do I need to do anything if, I am running a project or ad campaign that increases traffic by 10x, 100x or more? How does my cost [per X] change when this happens?
You don’t need to be a “geek” to ask these questions. However they will tell you very quickly what you are truly buying.
Additional resources and references:
- NIST’s cloud computing definition highlights the importance of self-service and rapid elasticity. It also highlights the importance of scaling all computing resources (e.g., networks, servers, storage, applications, and services)
- Amazon Elastic Compute Cloud demonstrates this in action.
- Scaling everything on-demand is not a trivial exercise. Here are posts on scaling dynamic data and future-proofing architecture.