Here’s the Wikipedia page on hybrid. As used in almost every case the result is that you have a kind of equation:

A + B = C

As used today in cloud computing, hybrid is abused to mean CONNECTING, not COMBINING two kinds of clouds:

• Private + public clouds
• Internal + external clouds
• Physical servers + virtual servers

The fundamental issue with all of these (except arguably the third, but I’ll cover that shortly) is that the end result is not A + B = C, but rather:

A + B = A + B

As long as the industry misuses (some might even say ‘abuses’) the term hybrid by using it any time they connect two clouds, more confusion is added to what is already a difficult conversation:

Joe:  "Our new hybrid cloud is up and running!"

Bob:  "Which kind of hybrid is that?  Public and private?  Private and

private?  Internal and external? ..."

The most accurate use of the term I’ve seen to date is GoGrid’s use for their combination of physical and virtual servers. However, the assumption is that cloud computing is about virtualized servers, which it’s clearly not. Virtualization is a multi-tenancy strategy. It allows you to chop up a physical server into smaller bite-sized chunks.

Cloud computing is about on-demand self-service IT resources, whether it’s servers (physical or virtual), storage, or network. There is no need to make up a new marketing name for ‘physical & virtual’. Just say: “Our cloud now provides physical servers on-demand for high performance workloads!” Everyone gets that.

Precise language, especially when discussing the confusing bleeding edge, is critical. Fuzzy terms, which can be perceived as marketing fluff, are best left at the door. We (those of us in the cloud industry) do ourselves and our customers a disservice by misuse of the term ‘hybrid’ unless we truly have figured out how to do the equation of A + B = C and C is something brand new. I challenge all thought leaders (myself included) to figure something else out or reuse one of the above terms.

An aside: a ‘model’ is a way of doing things.  Technology models are ways of putting technology together.  Financial models are ways to arrange finances.  Service models are ways of providing a service that is consumed by someone else.

There are two primary ways you can use cloud computing[1]:

1. Outsourced to an external public utility that uses economies of scale to service many customers
2. Maintained in-house as an internal shared infrastructure (aka ‘private’ or more properly ‘internal’ cloud)[2]

The myth about private clouds above conflates 3 ideas worth digging into:

1. The cloud diagram was used only to represent the Internet by network engineers and means ‘outsourcing’
2. Cloud is a business model and must be delivered as a public utility
3. Implied: clouds cannot be ‘private’ and owned by a single entity

Understanding the importance of private clouds is important, because the cloud computing model (like the client/server computing model before it) is about how IT works, not where it works.

Let’s address each part of the “no such thing as an (internal) private cloud” myth.

The Cloud Picture
I can say with 100% certainty that cloud pictures were used for much more than the Internet in the early 90s when the commercial Internet was forming. I know this because I was a network engineer.  My peers and I used clouds to represent any ‘autonomous system’ or group of such in a routing architecture.  It was a convenience mechanism to simplify network diagrams.

One example was using it to represent a large private wide area network (WAN), consisting of Frame Relay circuits or T-1s.  A cloud was also frequently used to represent the entire public switched telephone network (PSTN) or even, at times, entire groups of internal enterprise datacenters & networks.

One of my colleagues at Cloudscaling who is also a network engineering expert says:

Want more?  Here are three of the first page of network diagrams that came up on a Google image search for ‘network diagram’: 1, 2, 3.  As you will see there is liberal usage of the cloud picture for purposes other than representing the Internet.  Many of these clouds also represent ‘private’ areas of the network.

Without the historical context, it is understandable how one could conclude that the term “the cloud” was used as another term for “The Internet”.

Clouds Are Shared Infrastructure, not Utilities
Let’s explore the “utility” concept outside the context of the IT function[3]. A common definition of a ‘utility’ amongst cloud pundits today is: a shared infrastructure with metered usage, which has a pay-as-you-go model. An example of a non-IT utility is power companies like Pacific Gas & Electric (PG&E) which are energy utilities.  Nick Carr’s famous books, Does IT Matter? and The Big Switch extensively examine the concept of shared infrastructures leading to the rise of utility computing.

Nick posits that all shared infrastructures, including roads, telegraph, the national air system, railroad system, electrical system, and gas system, are utilities.  Do you think of a road as a utility?  What about the air traffic control system?  I don’t and neither does Wikipedia nor is that term used commonly.  A public utility is “a company that performs a public service; subject to government regulation” according to WordNet.  In other words, a utility is a for-profit entity entrusted to perform an important public function and is commonly regulated.

There is a common notion in the discussion of cloud today, which is that “utility” or “utility billing” is a financial arrangement where usage is “metered” and you “pay-as-you-go”, paying only for actual consumption.  This idea comes directly from the way true public utilities such as water, gas, electricity, and telecommunications operate.  These are all systems we commonly consider to be utilities.

But other shared infrastructures do not use the utility billing model.  Certainly, some roads have tolls, but the bulk of roadways are paid for with public money and are unmetered.  The railroad system is not metered.  Neither is air travel.  You do not ‘pay-as-you-go.’  While these systems aren’t labeled as ‘utilities’, Nick Carr lumps them into the same bucket.

It might be heresy, but I think there are essentially two big buckets: shared infrastructure and utilities.  Public utilities are a subset of shared infrastructure as is illustrated in the Venn diagram below.

Infrastructure Can Be a Public Utility OR a Private Shared Infrastructure
Infrastructure is frequently deployed by private individuals or entities for the purpose of sharing with others. Private road and highways are commonly shared.  No, I’m not referring to a simple driveway; I’m talking about large-scale construction efforts in which on-campus roads are built on university campuses, enterprise businesses, military bases, etc.  People fly private planes all the time, yet they share the national air infrastructure in terms of air controllers and air space, but not the planes themselves.  The military or large federated organizations also have large-scale shared infrastructure that is not a ‘public’ service.  There are many more examples and it is clear that not all shared infrastructure is a public utility.

We now have a conundrum.  The  ‘utility’ concept isn’t as clear-cut as being simply a shared infrastructure.  It clearly implies a financial arrangement.  What do we do?

For me it’s clear:  There is ’shared infrastructure’ and there are ‘utilities’.  Utilities are usually shared infrastructure, but not all shared infrastructure is a utility.  Utilitization is the act of taking a shared infrastructure and applying a financial model to it that charges for metered usage.  That means that utilitization is a business model that can be layered on top of a shared infrastructure (aka ‘public cloud’).

“Cloud” or “cloud computing” are limited terms. Nick Carr predicted the rise of utility computing.  He did not call it ‘cloud’ or ‘cloud computing’, nor did he coin those terms.  Nick correctly predicted the advent of a cost/economics model that inevitably moves large amounts of computing infrastructure to specialized providers who operate as public utilities and can use their scale to cost effectively deliver this service.  That’s the utility model and there is absolutely no doubt that it exists, is real, and will eventually apply to every shared infrastructure that human beings will create now and in the future.

So What’s a Private Cloud?
To better understand the concept of a ‘private’ cloud, we need to explore the concept of cloud computing itself.

Cloud computing can be seen not as a utility business model, but as a technology infrastructure model. The infrastructure in play is ‘data infrastructure’, not electrical infrastructure, people moving infrastructure, or others.  This new model determines how data infrastructure will be delivered and was pioneered by Google and Amazon among others.  Amazon used their data infrastructure to drive new revenue (AWS), and Google later introduced its Google App Engine (GAE) to do the same.

Were Amazon and Google clouds before they added revenue generation models?  I, and many others, would say “yes”.  The utility financial model for revenue generation is being applied to their clouds, but it does not, and never has, defined their clouds.

What defines their clouds is the method by which they built the actual IT infrastructure.  It was designed to be completely self-service, has no major single points of failure, and relies on commodity software and hardware.

That’s cloud computing.  Cloud computing is a methodology for delivering IT that changes everything. This is similar to how client/server computing disrupted mainframe computing changing IT in the process. The diagram below clearly illustrates my point.

This diagram shows the evolution to client-server from mainframe computing. Cloud computing is the next progression in the evolution of IT. Public cloud proponents want us to believe that everything in that third column is subsumed by the financial & business model, which is not true.  If you extract cloud computing from the public utility business model, there are significant and important advantages to moving away from the client-server model.  These advantages will be embraced by larger businesses that cannot easily progress to the public cloud model. In fact, the private cloud model is a critical transitional step. It is an essential component to help larger organizations move their compute capacity to the public cloud.[4]

Just what is a private cloud?  Private clouds are the cloud computing methodologies that Amazon and Google pioneered but applied in such a fashion that only a single tenant uses them.  They are owned by a single entity and optionally shared.  If Amazon deploys a copy of their Elastic Compute Cloud (EC2) for a customer, that copy of EC2 is a little private cloud used only by that customer.  It’s the same technology and methodology wrapped up in one little neat ‘cloud’ ball for the client.  It’s private, it’s a cloud, and the financial model it uses is not the utility billing model.

Summary
Will cloud be delivered as a utility?  Absolutely.  It is today.  In fact, the public utility model will be the dominant financial paradigm for cloud computing within the next two decades.  Most people will consume cloud computing built and delivered by others.  The cost economics are too compelling.

However, there will always be a demand for a private, unshared, cloud option.   This option could be outsourced or not, but it is ‘private’ because organizations will have some kind of requirement that disallows public cloud usage.  It could be security, regulatory, performance, or just plain old paranoia driving these requirements that prevent the ‘public cloud option’.

The old client/server computing paradigm is no longer good enough, just as the mainframe computing model before it wasn’t good enough.  The cloud computing model is displacing both client/server computing as the de facto way to deliver IT services.  At the same time, cloud computing pioneers (i.e.Amazon and Google) are finding that by utilitizing their cloud services, they can leverage their leadership while offering unprecedented value. Large enterprises will eventually move much of IT outside their walls. However, there will be areas which cannot be moved. That which remains inside their walls will be delivered using internal private cloud technologies.

I predict that 2010 will be the year of the private cloud.  We are at the beginning of a huge growth curve and this is the year it will start to see significant traction.

    Xen Cloud Platform offers ISVs and service providers a complete cloud
    infrastructure platform with a powerful management stack based on
    open, standards-based APIs, support for mutli-tenancy, SLA guarantees
    and deteailed metrics for consumption based charging.

From the website:

    In a classical router or switch, the fast packet forwarding (data path)
    and the high level routing decisions (control path) occur on the same
    device. An OpenFlow Switch separates these two functions. The data
    path portion still resides on the switch, while high-level routing decisions
    are moved to a separate controller, typically a standard server. The
    OpenFlow Switch and Controller communicate via the OpenFlow protocol,
    which defines messages, such as packet-received, send-packet-out,
    modify-forwarding-table, and get-stats.

This means you can create a fully multi-tenant, highly secure, extremely flexible, cloud network topology that maps exactly to your requirements.  This contrasts starkly to the current cloud networking today, which is either extremely restrictive (Amazon’s EC2), has scaling problems (e.g. 802.1q VLAN tagging), or doesn’t give you complete control (Rackspace Cloud, et al).

Let me clarify what I mean by complete control before anyone is offended. Rackspace Cloud does provide more control than EC2, but it doesn’t put you in the driver’s seat.  Imagine that instead of having a fixed network architecture like, every customer has a ‘frontend public network’ and a ‘backend private network’, you have something that allows arbitrary network configurations?  Customers get a ‘private’ network by default and buy networks as their applications need them.  Now having a separate network for database servers per PCI compliance (or other) rules is trivial.

Many other things are possible if you move towards an OpenFlow-based network architecture with a centralized control system, including:

• Distributed firewall just like Amazon EC2’s distributed firewall
• On-demand network introspection / tapping
• On-demand in-line firewall / IPS
• N-tier network topologies
• Distributed Virtual Switch (a la Cisco Nexus 1000V)

There are many other possibilities.  The eventual promise here is network virtualization as good as storage or computing virtualization is today.

Way to go Nicira and Citrix!

In particular, a number of articles posted here last year were extremely widely read.  In fact, the #1 article had well over 10,000 pageviews and almost 9,000 unique visitors.  3,500 pageviews came in that first week of posting 09/27/09 – 10/03/09.  That’s an average of 500 per day.

Here’s a chart showing our blog traffic growth over 2009:

As you can see we had tremendous growth and we’re expecting more in 2010.  Thanks for your readership and especially your comments.  We’re looking forward to even more conversation this year.

Here’s a list of our top ten blog posts in 2009 (in order of most read) if you want to go back and review.

1. Amazon’s EC2 Generating 220M+ Annually
2. VMware vs. Amazon … ROUND ONE … FIGHT!
3. Why is Amazon’s SAS70 Audit Bogus?
4. EngineYard uses Chef, a Puppet Alternative
5. The “Open” Cloud is Coming
6. VMware’s vCloud API Forces Cloud Standards
7. Amazon Threatens VPS Market
8. On Second Thought…How Big Is AWS Really?
9. Infrastructure-as-a-Service Builder’s Guide v1.0
10. Defining Infrastructure Clouds

It’s worth pointing out that the Infrastructure-as-a-Service Builder’s Guide made #9 in the list, but was posted on 12/19/09.  It made #9 in only 12 days time.  The actual white paper has been downloaded almost 1,000 times in less than one month.

Again, thanks so much for readership.

Best,

–Randy Bias, CEO, Cloudscaling

As you know, since then quite a bit has changed.  Amazon’s Elastic Compute Cloud crossed the Atlantic to Europe, EC2 opened up a U.S. West Coast presence, AWS also recently pre-announced their Asian expansion, and a number of other clouds sprung up across the globe, including a very strong new Australian entrant, Cloud Central.[1]

All of this goes to show that my prediction around the importance of reach in cloud computing is coming true.  One of the examples that brings this home that I enjoy talking about is Friendster.

For those of you new to social networking, Friendster was one of the very first social networks.  They were a true first mover in the space, but due to some strategic and tactical errors, they quickly fell behind sites like MySpace, Facebook, and LinkedIn. Except in the AsiaPacific region!

Friendster is one of the largest social networking sites still within that geographic region. You can see how they have re-tooled their business to be friendly to the AsiaPac region by providing localization in many Asian languages.

Now here’s the kicker: Friendster’s initial infrastructure was all in the United States.  What happens when your market changes underneath you?  How do you respond?  What tools are there to adapt?

As cloud computing goes global, it’s very nature provides a whole new opportunity in how businesses think about responding to market shifts.  Now you can follow-the-sun, follow-the-moon, follow-the-law, and up and move your entire application to a new country with much less effort than ever before … and, it will get even easier over time.

Cloud computing is going global and it’s going to change the way we think about service delivery models completely.

Of course, we welcome comments and feedback.  They will be incorporated into future revisions.  The paper itself does go into some technical depth in a few areas, but we can provide quite a bit more color in our workshops.

For your reading pleasure, I present our first big technical whitepaper:

• The Infrastructure-as-a-Service Builder’s Guide v1.0 (PDF)

Thanks!

The Cloudscaling Team

Ps. We realize the definition of ‘workload’ or ‘cloud workload’ is not as crisp as it could be and request your feedback and thinking on better nomenclature or definitions.  Credit will be given as appropriate.

To be clear, the top three U.S. clouds do not use iSCSI SANs: Amazon’s EC2, Rackspace Cloud, and GoGrid, all use local RAID subsystems.  This is common knowledge.  Of the early cloud pioneers, as far as I’m aware, mostly the U.K.-based clouds such as ElasticHosts and FlexiScale use iSCSI SANs.  The latest set of new cloud entrants, such as Savvis, Terremark, and Hosting.com all use either iSCSI or Fiber Channel-based SANs.  This is also commonly known.

Your Mileage May Vary on these performance numbers.  I’m not trying to highlight any ‘right’ way to build a cloud here.  I’m simply trying to show what the difference in performance is between a single SATA disk and a VM disk drive backed by an iSCSI SAN over a single Gigabit Ethernet.

This is not a robust performance and benchmarking analysis.  It’s a simple “run the numbers and compare” blog posting.  These are by no means authoritative performance numbers and that’s not their purpose either.  Their purpose is to highlight how performance differs between a single spindle and many in a RAID configuration, even when that RAID is available via a SAN over Gigabit Ethernet.

Please avoid overly critiquing the testing technique here.  It’s not meant to be robust, so nitpicking it serves no purpose.

Setup & Methodology
This is a very simple test in the Cloudscaling hosting & cloud lab environment.  Both servers running the test are on latest Ubuntu Jaunty Jackalope release.  One is a physical server with a single SATA disk and the other is a VMware vSphere VM backed by an iSCSI LUN.  The iSCSI LUN is provided by a ZFS-based SAN product called NexentaStor from Nexenta Systems.  This is an OpenSolaris derivative and a very cost effective alternative to say a NetApp or EqualLogic system.

The iSCSI SAN hardware is a simple Sun x2200 M2 with a Sun J4200 JBOD and 6 15K RPM SAS drives.

The bonnie++ command line was as simple as possible:

bonnie++ -n 512

Basic Numbers
Here is a basic high-level chart showing the numbers.

Figure 1. High level of SATA vs. VM disk

The first thing you will notice, of course, is the two big spikes for sequential and random file reads.  These numbers are artificially inflated as clearly 325,000 IOPS for sequential and 460,000 IOPS for random reads are ridiculous.  This is likely due to caching either in the OS or the controller on the physical box.  bonnie++ is supposed to account for this, but for some reason, in this instance it did not.  So it might be a little easier to evaluate the relative performance on a logarithmic scale:

Figure 2. Logarithmic scale for test Results

Much better.  What is easier to notice here is that the VM generally performs better on both standard measures of disk speed: raw throughput and disk operations (I/O per second or IOPS) with the obvious exception of the two aberrant data points.

Removing those two data points will give us an even clearer picture:

Figure 3. Normalized test results

Great.  Now this is very clear.  As you can see, the first half of the chart shows raw throughput (Kbytes/second).  When reading blocks from the VM disk we’re nearly saturating the gigabit ethernet link which should top out at 125Mbps theoretical, and we’re hitting 107MBps on average over 10 runs, so this is quite acceptable.  The SATA disk, in comparison gets just over 60MBps, which is about right, even though the SATA spec and controller are capable of more.  Sustained block reads from SATA disks will typically be 60-80MBps in the real world.

Much more interesting is the number of IOPS.  Many real world disk workloads, like a database spend the majority of their time doing large amounts of their ’seeking’ from one position of the disk to another, meaning lots of random file access.  They will bottleneck on waiting for the disk ‘head’ to move from one position to another on a disk drive and read new data.  It’s hard to tell the difference above because the SATA disk is so slow it barely registers on the chart.

If we change to a logarithmic scale again the data becomes much easier to read:

Figure 4. Normalized logarithmic scale test data

Now you can see that doing random seeks (i.e. moving the head of the disk drive from one location to a new one to read a piece of data) are starkly different.  A single SATA disk gets about 185 IOPS while a set of 6 SAS disks in the SAN is right around 10,000 IOPS.  This is a huge performance difference.  There are several reasons for this.  One, a typical SATA disk has an average latency of 8.5ms and a 15K SAS disk has only 3ms.  Also, with 6 disks in a RAID configuration, I have 6x more disk heads to read with.

It’s still a bit hard to see with this chart, but for most of the rest of the IOPS tests above, the SAN solution is roughly 3x the performance of the single disk.  For example, Sequential File deletion is 2,573 (SAN) vs. 840 (SATA).

Rather than going through the entire set of results, I recommend you download my simple spreadsheet.

Note that for Amazon, Rackspace, or GoGrid, local VM disk results will likely look very similar to the iSCSI SAN results for IOPS and sequential read/write (first half of chart) will be much higher.

Amazon’s Elastic Block Storage (EBS) would have similar performance characteristics to the iSCSI SAN above and hence you can see why it can be acceptable for running a database.

Summary
My point here is very simple.  I want to highlight the difference between purchasing a dedicated server with a single (or small number of) SATA disks vs. going with a cloud solution that uses a shared iSCSI SAN or local RAID on a single physical node.  Purchasing your  own dedicated server solution with a RAID can be extremely costly compared to a similar cloud solution.

More importantly, for those workloads that require random I/O and file access, like database applications, RAID is clearly a winner.  That’s why using a shared RAID (via an iSCSI SAN or a local RAID) on a physical node for your cloud VM can be a clear advantage of the cloud today.

Regardless, a bit more light has been shed on Amazon’s controls and measures in their recent security webinar.  You can access it here.

At a high level, CJ Moses, who presents the webinar talks to the core areas they covered in the control objectives, which are:

1. Security organization
2. Amazon employee lifecycle
3. Logical security
4. Physical security
5. Environmental safeguards
6. Change management
7. Data integrity, availability, and redundancy
8. Incident handling

This looks pretty reasonable at a high level.  Of course, it would be nice to see the actual controls and objectives, but at least they are covering the appropriate areas of security.  I do notice that there isn’t much around perimeter or related security.  I’m guessing they are trying to gloss over the AWS distributed firewall.  It would be nice if someone besides Amazon was vetting the way this was built.  They appear to consider it a piece of core intellectual property despite the fact it would be trivial to reproduce.  I’m not exactly certain why.

Unfortunately, a SAS70 audit isn’t what most people think it is. Worse yet, Amazon’s reluctance to provide details of the audit provides a false sense of security with no tangible benefits.

Let me explain.

Understanding the SAS70 Audit
The SAS70 is a methodology for performing an audit, not the audit rules themselves. The SAS70 can prove whatever you decide it needs to prove. From taking the garbage out to turning the lights on.

From Wikipedia:

For a SAS70, you must specify a series of “controls” and “control objectives”. Like it sounds, you are asserting that a given ‘control’ meets a goal or objective. An example of a control might be the ‘new user creation process’ or a ‘firewall’. An example of a control objective might be the following[2]:

Now here’s the rub: Who decides what the control objectives are? An outside agency? A regulatory body?

None of the above. The company being audited decides and can make the control objectives anything they like. Here’s a SAS70 FAQ response on the topic right from the SAS70.com website.

Again, the SAS70 is just an auditing framework. Why then do so many think it’s useful?

Background on the SAS70 Audit
The SAS70 comes out of the financial industry and is a relatively generic framework for that reason. The financial industry has tons of different regulatory requirements that vary from state to state and country to country. Moreover, within the financial industry these kinds of audits are undertaken all of the time, the parties involved know what they are testing for, and how to negotiate it.

For example, a large bank might outsource work to a secondary institution and have a desire to see that institution provide proof they are following certain guidelines or regulations. A good example is the Bank Secrecy Act. The large bank in this case knows what the BSA requires and how to evaluate the secondary institution’s SAS70. This knowledge allows them to assess secondary institution’s level of compliance with the BSA. At the same time, the secondary institution is familiar with what its large partners will require and sets up its annual Type 2 to cover the ‘usual suspects’ of controls and control objectives.

So how did we get here?

Hosting Companies and the SAS70
In recent years as financial institutions began to outsource they required that various hosting (and other) businesses perform the audit as well. Unlike their usual partners it hasn’t been clear what hosters need to be compliant with. Because of this most folks have simply done these SAS70s as simple Type 1s that are one-offs. This allowed the hosters to keep their costs down while allowing the bank to outsource and the hosters to generate revenue.

Here’s the problem: Cloud computing is ushering in whole new ways of delivering IT services.

It demands greater transparency than ever, especially when it comes to security. If the average person doesn’t understand the SAS70 and if you don’t provide your control objectives so that others can vet the objectives you sold then you are creating a false sense of security.

You could have one control objective that simply says: “we must keep the power in the data center on” and successfully pass by fulfilling that over 3 days or 6 months.

The Need For A Cloud Security Standard
There are a couple of security and IT standards that can be used as the basis for a good SAS70 audit. For example there is CoBIT and the ISO27002 (formerly ISO17799). There are probably others I’m unfamiliar with. Unfortunately, most of these standards really focus on the Enterprise and not on a multi-tenant public cloud or hosting companies, who have some issues specific to their particular business models and architectures.

So, even if Amazon used one of these, it’s still not good enough for them to keep their controls and control objectives hidden from public view. How are we to be certain that they are sufficient? [3]

Summary
Until there is a security standard for running a cloud then SAS70 audits with unpublished controls and control objectives like the recent AMZN announcement are simply smoke and mirrors. They provide little or no real assurance to the average consumer of the AWS public cloud and serve only to provide a false sense of security.

UPDATE: @wpauley says he has a copy of the AWS controls, but I haven’t seen them yet. When I get a copy I will post them.
UPDATE2: Apparently @wpauley was a special case. AWS is keeping the controls under wraps. If you have a copy send them to me anonymously and I will get them posted.

Guest Author Andy Schroepfer is VP of Strategy at Rackspace. You can follow Andy’s content on www.NoMoreServers.com and via Twitter @shrepfur.

Determining the exact revenue size of Amazon’s Web Services (AWS) unit is akin to finding the exact server that an Amazon customer’s code is running on in the cloud. In both cases, only Amazon knows the specifics whereas the rest of us are left to guesstimate. I have previously praised a few blog researchers for their good efforts and wanted to contribute to the discussion with an analysis of a different type. My approach, using just the financial detail in Amazon’s SEC filings, suggests AWS might be smaller than the much more detailed assessments grounded in usage data. To that end, I suggest that all of AWS is below $200 million annually, and perhaps closer to $150 million.

Before the detail and thought process, I want to begin by noting that whether Amazon’s Web Services unit has $150 million, or well above $200 million, they have achieved success. As a competitor, we both admire their accomplishments and remain steadfast in our pursuit to catch and surpass Amazon since this is a multi-decade opportunity. The game is already on, but before I put my gloves back on, here is some detail worth considering.

The infamous “Other” revenue bucket is where Amazon counts the sales from AWS. While EC2 is well understood, and agreed, to be the likely dominant component of revenue within the AWS portfolio, there are several services that combine to equal the AWS component. The first service launched out of beta was S3 (online storage) in March of 2006. The SQS (hosted message queue) followed in July 2006. While EC2 (compute) entered limited beta in August 2006, unlimited beta was not until October 2007 and then the production launch in October 2008. Of note, the European launch for S3 was not until November 2007 the European release of EC2 happened last December (2008). A few other offerings remain in limited beta (Mechanical Turk, SimpleDB, Import/Export). This link shows where I gathered these dates.

With only the tiniest of exceptions, the AWS revenue stream would have only started adding in any noticeable way in 2006 given these release dates. Even for 2006, the revenue generated from AWS is likely to have been minimal. The year of 2007 is sure to have included some noticeable revenue, but it would be 2008 and especially 2009 where most of the revenue from AWS services would be showing. These general assumptions, based largely on release dates, guide my thinking in the following analysis.

I begin with a look at the annual totals reported in Amazon’s “Other” bucket. In 2004, Amazon achieved $132mn of Other revenue. This grew by 74% in 2005 to $230mn. Growth then slowed back to 23% in 2006 when Other revenue totaled $283mn. In 2007, growth increased to 35% bringing Other to $383mn. Other revenue accelerated again in 2008 to 41% such that Other reached $542mn. Lastly, when annualizing 3Q09 “Other” revenue of $163mn, we find a yearly run-rate of $652mn in Other revenue. All of these numbers can be found in the 10-K filings with the SEC and are worldwide totals.

Before I continue, we believe analysis is more accurate when looking at the North America revenue line for “Other,” rather than the worldwide totals listed above. Why? Because as shown from the release dates of the AWS offerings, there should be minimal revenue until 2008. This is interesting since International “Other” revenue was:

• $2mn in 2004
• $8mn in 2005
• $20mn in 2006
• $57mn in 2007
• $94mn in 2008

Of course, some of the $94mn in 2008 should be from AWS services, but how much? Since Amazon has been expanding its core business internationally over these years, and presumably is garnering the same growth of non-AWS-other revenue from this international expansion. It is even possible that all of AWS revenue is counted in the North America segment. Why would I even suggest this? Because the 3Q09 “Other-International” revenue line shows $25mn, which when annualized equals $100mn…barely up from the 2008 total. Since I doubt Amazon has less than 10% growth from international customers for AWS services (especially in the year following the full production version of EC2 and S3), I am giving Amazon the benefit of the doubt that AWS revenue is either being under-reported for some reason (accounting rules or otherwise) in the International-Other revenue reporting line, or is completely included in the North America-Other reporting line.

Accordingly, looking just at the North America-Other revenue line, we find the following from the past five years. “Other” revenue was $130mn in 2004 and grew 71% in 2005 to $222mn. In 2006, growth slowed to 18% as revenues totaled $263mn for the year. As a reminder, I noted above that given the release dates of the AWS services, this $263mn in 2006 Other-North America revenue likely has minimal AWS revenues. This means the debate of figuring out AWS’ contribution should start with the assumption for 2007 where Other-No.America revenue grew 24% to $326mn. This continues with estimating the contribution as Other-No.America revenue grew 37% in 2008 to $448mn and has grown 23% to $552mn when comparing the annualized 3Q09 Other-No.America revenue.

If one were to assume AWS was $10 million in 2006 and is responsible for all growth above 20% in the Other-No.America revenue line, this would lead one to a finding AWS revenue of $22mn in 2007, $84mn in 2008, and $115mn of the annualized 3Q09 results. These are not poor results at all since this would still represent growth of 120% in 2007, 281% in 2008, and 37% for the annualized 3Q09 results over the calendar year of 2008. However, these are meaningfully lower than the recent estimates proposed by other bloggers.

If I use a different estimate, we still conclude there is a smaller outcome for the AWS contribution. As a reminder, this is merely a back-check on the plausibility of Amazon’s AWS revenue estimates made by third-parties such as Cloudscaling.com. However, if we give AWS credit for all growth above 15% starting in 2007 (instead of the 20% used in the preceding paragraph), we would find AWS growing from:

• $10mn in 2006 to
• $36mn in 2007
• growing 214% to $113mn in 2008, and
• growing 48% to $167mn within the annualized 3Q09 results

Essentially, one would need to assume that all of the non-AWS components within the Other revenue line have generated less than 10% of the reported annual growth in 2007, 2008, and the annualized 3Q09 results in order for the AWS portion to equal over $200mn on an annualized basis within the 3Q09 results.

To save some of you from needing to post “what-if” corrections and comments, I will admit (again) that none of this is definitive or factual. This is merely one man playing with the numbers that are publicly reported by the company and mixing in some context. Randy Bias did a great job with starting the discussion of how big is AWS really! Until Amazon confirms the actual size, I thought this would be a useful contribution to the discussion.

Issues such as currency impacts on the reported numbers could, and likely do, influence each of the reported revenue figures that this analysis draws upon. Amazon’s A9 service likely has declining revenue, which if significant in prior size and pace of decline, would justify altering the assumptions used herein. Also, there is no description in the Amazon filings of whether the reported revenue is counted net of credits, or not. There are basically many different revenue recognition accounting details that would need to be described by Amazon to truly know how to best interpret the reported numbers.

With the disclaimer out of the way, I will point out that even if the $167mn tally for AWS within the annualized 3Q09 results is closer to reality, this would represent 30% of Other-No.America revenue (and just shy of 25% of worldwide Other revenue). I mention this point because during the Q&A portion of Amazon’s earnings call, the only question into AWS/Other was one asking for which AWS services were seeing stronger uptake. To paraphrase the response, Amazon said AWS in total is certainly part of the “Other” revenue increase along with marketing and Amazon Enterprise Services, which are the larger pieces of “Other.” I hear/read this to mean that Amazon had three core items with Other that are all meaningful to the “Other” total. One-third equals 33%. I am not taking this as validation of our attempts to better pick an estimate of AWS revenue, but I am inclined to think that if AWS was the largest of the “Other” components, the comments from management might have suggested this in their remarks.

As always, your thoughts, comments, objections, criticisms, support, and even praise are invited and welcome in the comment section below, or in the comment section of www.NoMoreServers.com. Regardless, I hope you will become a regaular at NoMoreServers!

OK, I am getting my gloves back on and simply concluding that Amazon is a good competitor, but mindful that this is a long war where there will be many battles as businesses of all sizes continue to trial both Amazon and Rackspace’s cloud offerings. The market is big enough for both of us to succeed, but that won’t stop Rackspace one bit from our pursuit of long-term leadership.