Short-Sighted about Cloud Computing
May 30th, 2008
There seems to be a group myopia around so-called ‘cloud computing’ and it’s definitions. What we’re really talking about are ‘cloud services’ of which, ‘computing’, is only a subset. It gets worse when you have people talking about Software as a Service (SaaS) as a ‘cloud’ service. Things continue to become murkier when the SaaS crowd, bloggers, and reporters start making up new definitions for cloud services using SaaS-like terms such as Platform as a Service (PaaS) and Infrastructure as a Service (IaaS).
Soon we’ll have Hosting as a Service (HaaS), Services as a Service (SVCaaS), and Name Your Flavor as a Service (*aaS, better known as just plain ‘aaS’). Of course SaaS is just the re-hashing of the whole Application Service Provider (ASP) model from the late 90s anyway. You remember?
Let me explain what cloud services are, where they came from, and where they are going.
Cloud Services
Cloud services are not SaaS. They are far more akin to web services and this is part of why Amazon’s cloud services are simply called ‘Amazon Web Services‘. Cloud services encompass a number of different kinds of service, but they share some common attributes with each other and web services, including:
- simple point services meant to be integrated into a larger application
- machine-consumable via network-based APIs (commonly REST or SOAP)
- ‘infinitely scalable’ (meaning: ‘no practical limit’)
- in-the-cloud
- self-service
- on-demand
By contrast, most Software-as-a-Service products are fully-baked applications such as Salesforce.com’s CRM application. Another quick way to identify SaaS is that the user interface is usually the primary interface with the API being an afterthought. In comparison, most cloud services have an API as the first interface and a UI as a
secondary interface if one even exists.
Cloud vs. Web Services
Web services are historically a large business (i.e. ‘enterprise’) based technology trend. SOAP and the WS-* standards defined web services and their consumption. Web services, for this reason, existed mostly behind the firewall and were created and consumed within large organizations. Cloud services are similar to web services, but differ in terms of who uses them and where they are deployed (i.e. ‘in the cloud’).
Cloud services are fundamentally game changing, where web services are just ‘ho-hum’. They are the final democratization and commoditization of ‘web services’ out in the cloud, usually created by many different organizations, and consumed by anyone. This is a natural response to market forces seeking to have more control, scale, and usage from ‘web services’. Web services, like most recent Internet related technologies are more interesting when the power of ‘the net’ is applied. In other words:
web services (’ho-hum’) + network effect == cloud services (’holy cow!’)
If nothing else shows us how much cloud services look like web services, then ‘Amazon Web Services’ product offerings should. A short list of what they provide:
- Compute
- Storage
- Database
- Messaging / Queuing
- Payment processing
- Search
As you can see, these are all simple point applications, consumable via an API, for use as part of a larger application and of minimal use by themselves. They are not even marginally related to SaaS. As individual services they aren’t terribly interesting, but in terms of their ability to provide you leverage for your application, to quickly accelerate some need that you have when initially developing, or to allow you to get a large amount of ‘scale‘ once you grow is of tremendous value.
Clouds as Platforms and Infrastructure (aaS)
This recent RightScale blog entry inspired this post and what I think they are really talking about here is breaking ‘cloud services’ down into two main categories: platform-based models and infrastructure-based models. Both of these are defined fairly well in the RightScale blog posting (other than the association with SaaS terms). What is important to notice is that this isn’t an either/or situation. You don’t need to pick one or the other: platform or infrastructure. You’ll almost certainly wind up using both.
Build your prototype in Google’s AppEngine and have it use Amazon’s Flexible Payment System (FPS) to process payments. Or build it on Amazon’s Elastic Compute Cloud (EC2) and have it use Google Checkout. Do what is right for your application.
Cloud Service Trends
The continued trend is towards self-service, democratized, vote-with-your-dollars, cloud services that can be used to composite together or bolster your application development, decrease time to market, and provide new kinds of software development leverage. This means that cloud service providers, and the developers who build value added services on top of them, need to compete using strategies where their services have inherent synergies (a la the AWS ‘ecosystem’), on service or service level agreements, or by continuing to innovate in advance of competitors. Right now it looks like Amazon is doing this across the board while most others are playing catchup.
The continued driving forces will be ease-of-use, choice, and ability to use cloud services as part of larger applications for startups, small businesses, and soon larger enterprises.
Future of Cloud Services
The future of cloud services is one where you will select and composite the best (or cheapest) services for your application. Some combination of services will be right for your application and the tools that help you build and put together these services will be critical to your success. This means that tools that support multiple providers or abstract them in such a way that ease your ability to integrate and consume them will be clear winners.
Entry Filed under: Technology, Cloud Computing, Storage
4 Comments Add your own
1. Peter Laird | June 2nd, 2008 at 3:10 pm
Randy - nice work. Rolling up all of Amazon’s services into a single “Cloud Services” label is useful. But I believe the “aaS” terms can also be useful here. I think “aaS” can go overboard, which has led to new acronyms such as XaaS (whatever - as a service).
I would say that S3 is NOT SaaS, and would call it Hardware as a Service (HaaS), since it is primarily offering up disks on demand. Admittedly there is software there, but it is primarily focused on getting bits on and off disk.
I disagree with your characterization that SaaS is just apps. Take the term literally, and something like Amazon SQS is a SaaS offering. It offers a software solution (queuing) as a service offering (pay as you go, delivered by a 3rd party, etc).
BTW - I did a blog post last week about the “aaS” terms and offered a visual map to organize them:
http://peterlaird.blogspot.com/2008/05/saas-soup-navigating-a-service-acronyms.html
I also did a blog posting with an industry map a few weeks prior that shows how I place the vendors into the buckets.
2. Markus Klems | June 19th, 2008 at 10:18 pm
Randy, great blog post. I agree with you that people are missing the main point when they declare SaaS to be cloud computing. For me the main difference here is that SaaS is a enduser-facing business whereas cloud computing (and the other services you pointed out) are developer-facing business. I would say that processing + persistence (EC2+S3) is the core of the cloud whereas services like FPS and Search are something on top. The great thing about the Amazon cloud is that developers themselves can introduce such cloud services. Another interesting link might be Marc Adreessens “Web as Platform” terminology from the 90s. He recently wrote an interesting blog post on this: “A platform is a system that can be programmed and therefore customized by outside developers — users — and in that way, adapted to countless needs and niches that the platform’s original developers could not have possibly contemplated, much less had time to accommodate.” (http://blog.pmarca.com/2007/09/the-three-kinds.html)
3. Michael Sheehan | June 27th, 2008 at 3:28 pm
Randy,
This is a very thoughtful analysis and very topical (of course). I too, as the Technology Evangelist for GoGrid (http://www.gogrid.com), have been struggling to categorize the various cloud offerings in a way that people who are not completely tapped into the industry can (hopefully) understand. I’ve been calling it the “Cloud Pyramid” for lack of a better term, which has the categories as: Cloud Applications (e.g., SalesForce), Cloud Platforms (e.g., Google App Engine) and Cloud Infrastructure (e.g., EC2 and GoGrid). Details are here.
But I like your term Cloud Services and I’m trying to figure out if they would span the categories that I have described or simply be sub-sections within the Infrastructure Cloud (or even the Platform Cloud). Obviously this whole environment is in its infancy, in terms of market adoption, but the uptake is incredibly quick it seems.
I look forward to reading more of your insightful posts.
Thanks,
Michael
4. Brian Nelson | August 14th, 2008 at 12:40 am
Nice post, Randy. I think one of the big problems with any new technology is lexicon. As an example, look at any given ’security suite’. Mixed-metephors abound. (Virus and Firewall - what do those have to do with eachother?)
@Peter:
I think that’s part of the problem. We want familiar buckets to put everything in, especially as engineers defining this field, but it’s not there yet. It’s not ready for buckets, and it limits the mindset on what a CIO, Engineer, or average Joe can expect from these things.
It’s pointless to append ‘aaS’ if you have to reduce it to such a general term as ‘hardware’ or ‘people’ and adds no clarity to what you are looking for, or what you mean when you say something. If you were to say ‘we run entirely on HaaS’, how much different is that to saying ‘we run entirely on SaaS’.
I feel it’s overloading new technologies with terms intended for entirely different purposes. If you look at both of your graphs, they put the ‘app’ services on one side, and the ‘cloud’ on the other — with the only connection being the broken terms.
As a more concrete analogy, it’s rarely necessairy, if ever, to be talking about front-end, user facing apps in terms of the APIs running them, except to engineers looking to extend an existing platform. I am hard pressed to think of a time I would be writing article about ‘Using Firefox’ and ‘Using the Gecko API’ that would have any coherence.
These are just my opinions, and I see the desire to tie the similarities together. After all, libraries (APIs) are software. The kernel is software. The access to your hardware is (largely) software, however, SaaS is more like ‘Applications as a Service’, overloading the term Software.
Anyway, enough ranting. :)
Leave a Comment
Some HTML allowed:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>
Trackback this post | Subscribe to the comments via RSS Feed