Home > Cloud Computing, Cloud Security, Virtualization, Virtualization Security > Incomplete Thought: The Cloud Software vs. Hardware Value Battle & Why AWS Is Really A Grid…

Incomplete Thought: The Cloud Software vs. Hardware Value Battle & Why AWS Is Really A Grid…

Some suggest in discussing the role and long-term sustainable value of infrastructure versus software in cloud that software will marginalize bespoke infrastructure and the latter will simply commoditize.

I find that an interesting assertion, given that it tends to ignore the realities that both hardware and software ultimately suffer from a case of Moore’s Law — from speeds and feeds to the multi-core crisis, this will continue ad infinitum.  It’s important to keep that perspective.

In discussing this, proponents of software domination almost exclusively highlight Amazon Web Services as their lighthouse illustration.  For the purpose of simplicity, let’s focus on compute infrastructure.

Here’s why pointing to Amazon Web Services (AWS) as representative of all cloud offerings in general to anchor the hardware versus software value debate is not a reasonable assertion:

  1. AWS delivers a well-defined set of services designed to be deployed without modification across a massive number of customers; leveraging a common set of standardized capabilities across these customers differentiates the service and enables low cost
  2. AWS enjoys general non-variability in workload from *their* perspective since they offer fixed increments of compute and memory allocation per unit measure of exposed abstracted and virtualized infrastructure resources, so there’s a ceiling on what workloads per unit measure can do. It’s predictable.
  3. From AWS’ perspective (the lens of the provider) regardless of the “custom stuff” running within these fixed-sized containers, the main focus of their core “cloud” infrastructure actually functions like a grid — performing what amounts to a few tasks on a finely-tuned platform to deliver such
  4. This yields the ability for homogeneity in infrastructure and a focus on standardized and globalized power efficient, low cost, and easy-to-replicate components since the problem of expansion beyond a single unit measure of maximal workload capacity is simply a function of scaling out to more of them (or stepping up to one of the next few rungs on the scale-up ladder)

Yup, I just said that AWS is actually a grid whose derivative output is a set of cloud services.

Why does this matter?  Because not all IaaS cloud providers are architected to achieve this — by design — and this has dramatic impact on where hardware and software, leveraged independently or as a total solution, play in the debate.

This is because AWS built and own the entire “CloudOS” stack from customized hardware through to the VMM, management and security planes (much as Google does the same) versus other providers who use what amounts to more generic software offerings from the likes of VMware and lean on API’s and an ecosystem to extend it’s capabilities as well as big iron to power it.  This will yield more customizable offerings that likely won’t scale as highly as AWS.

That’s because they’re not “grids” and were never designed to be.

Many other IaaS providers that have evolved from hosting are building their next-generation offerings from unified fabric and unified computing platforms (so-called “big iron”) which are the furtherest thing from “commodity” hardware you can get.  Further, SaaS and PaaS providers generally tend to do the same based on design goals and business models.  Remember, IaaS is not representative of all things cloud — it’s only one of the service models.

Comparing AWS to most other IaaS cloud providers is a false argument upon which to anchor the hardware versus software debate.

/Hoff

  1. October 18th, 2009 at 08:08 | #1

    Maybe I'm misunderstanding your point but it seems to me that the infrastructure AWS has built thus far is almost the opposite of a grid. In a grid you have large numbers of completely homogeneous nodes that can be federated at will to collaborate on specific tasks. The focus from the client's point of view is almost purely upon the computation they want to be performed not on the nuts and bolts of how to do it and certainly not on the details of individual compute nodes.

    AWS on the other hand has a vast number of heterogeneous compute resources that really want to be treated completely independently. You have to expend considerable effort to actually get a bunch of them to cooperate on one logical task and, at least until ELB/Autoscale was introduced, that cooperation happened in spite of rather than because of the tools they provided to you.

    Google App Engine seems much more like a grid model to me.

    Mitch

  2. Christofer Hoff
    October 18th, 2009 at 08:19 | #2

    Your definition of grid is exactly what AWS provides. The task it's infrastructure yields is to deliver fixed unit measures of workloads (instances) above the VMM in the form of AMI's.

    Regardless of what the AMI's contain, to the VMM and infrastructure, it's all homogenous.

    You are confusing the variability of what's IN the AMI vs. the AMI boudary itself.

    Re-read it with that perspective….

  1. March 9th, 2010 at 18:22 | #1