With his GigaOm post, Cloud is complex - deal with it, James Urquhart triggered quite a discussion in the cloudosphere. He described IT in general, and cloud in particular as a complex system. Complexity in this case does not necessarily mean harder to use, just that the whole is more than a sum of the parts. 

Sam Johnston led the response, but, along with many others, focused on the wrong meaning of complexity. I can understand the confusion - Urquhart’s headline and introduction focus on ease of use. But that’s not really what he was trying to say. His use of complexity was descriptive and particular to the science of complexity.

A complex system, such as Urquhart describes, is a system in which interconnected components lead to behaviors not directly predictable from the behavior of any given component. That can lead to extremely fragile systems - such as the web of automated traders mentioned in the original post, or a power grid where a few trees in Ohio can blackout 55 million people. It can also lead to very robust systems - like the packet-switched network that forms the backbone for all of this stuff we’re arguing about (and arguing on). While not a requirement for a complex system, you’ll find the amplifying effects of power laws underlying many instances.

When you take a complex system and imbue it with an “intelligent” change agent, you end up with an adaptive system. Intelligent in this case doesn’t necessarily mean driving with a purpose; rather some sort of feedback loop that influences the actions of the system. In the adaptive scenario, you end up with self-organization and potentially a whole host of emergent behaviors.

And that leads us back to cloud as a complex adaptive system as classified by Urquhart. As I mentioned above, the underlying communication mechanisms for the Internet and cloud are clearly a complex system. But the compelling value propositions of the cloud - self-service, infinite scale, pay-as-you-go - are all features that arise from an interconnected set of components working together. Add developers and businesses to the mix, and you get a rapid feedback loop that influences the direction of the cloud.

One interesting example is the adoption of the Amazon Web Services APIs as the de facto standard for IaaS management. Nobody decreed that AWS was the right way to manage infrastructure. Instead a critical mass of companies and individuals looked at their specific goals, and were influenced by the influx of adopters (i.e. network effects) such that the AWS API emerged as THE answer for IaaS management.

The AWS story is a great example of a complex adaptive system leading to simplification.  Rather than having a morass of competing options (and the resulting difficulty to use and manage), a single answer emerged.

That’s not to say the emergent behavior of an adaptive system always leads to the best answer, or even a right answer. There are plenty of dead-ends and failed pathways (think the ASPs of the dotcom era). But in general, the feedback mechanisms inherent in the adaptive ecosystem eventually lead to progress -without any grand design - and often before anyone even truly grasps what’s happening.

So while Johnston is right that end users should be protected from the difficulty inherent in executing a cloud environment, that should be true of any service IT provides. That should be the goal of any abstraction - and really isn’t a novel point.  The much more interesting endeavor is understanding the interconnected nature of all things cloud and identifying and influencing the emergent behaviors. The companies that can do that are the ones who are going to win.

Interesting numbers coming out of a RedHat survey at VMWorld.

.NET is essentially at par with Java in terms of in-house usage - yet very few cloud players have a .NET story.  (Disclaimer: I work for one that does, Apprenda.)  Everyone seems to be fighting over the Java / alternative languages market (see CloundFoundry, Heroku, OpenShift) which will likely lead to a bunch of fragmentation.

Not as surprising were the results around public cloud.  I think the security concerns will diminish with familiarity, but the portability and governance will require some concerted development effort and emergent standards across the vendors.

Yesterday at Structure, Amazon CTO Werner Vogels apparently showed a slide that eschewed the commonly used layer diagram to illustrate the different levels of service-delivered technologies.

Vogels instead portrayed the space as a cloud - indicating that the lines dividing the different layers was becoming blurred.

That may be true from a provider and an offering perspective (although I don’t think we’re actually there yet), but I don’t think it’s true from the consumer perspective.

The consumer is generally looking for a certain level of abstraction from their *aaS investment.  Those who purchase / build an infrastructure as a service want the virtual machine as the first class citizen.  Those who use an application PaaS view the application as the important component.  And the SaaS market is predicated on the business value being the driver for use.

They may go to the same provider for different tiers of abstraction (i.e. Amazon with EC2 and Beanstalk), or they may totally bypass the levels they don’t care about (just about any SaaS purchase), but that doesn’t mean we’re losing the sharp lines between the *aaS layers.

As Sinclair Schuller (disclaimer, my CEO at Apprenda) demonstrated when discussing private vs. public, cloud consumers only really care about their touch point. The underlying technology / provider is a black box. 

From a provider perspective, Vogels’ viewpoint is more correct.  There’s a lot of value to a company to owning multiple layers of the stack - whether it be a full offering to provide to customers, or leveraging specific features from the lower stack (see Microsoft Azure, which needs a very specialized hardware config).  We’ll definitely see more blurring of the lines with cloud providers - whether through acquisition or simply building out an existing offering.

But to a large extent, that’s navel-gazing.  Within the industry that’s important, but to the consumer, it matters little.  

So is Vogels right? Are the lines being blurred between the *aaS layers?  Yes, but not in a way that’s going to fundamentally shift how they’re consumed.

Yesterday, Ben Kepes posted about his vision of the evolution of PaaS.  The money section comes down near the end where he talks about the two distinct realms he sees platforms fitting into:  infrastructure and application.

I think he’s spot on with that breakdown (and he even stole used the acronyms I’ve been using to describe them), but I’d describe the application PaaS a little differently than Ben did.

Or perhaps I’d rename Ben’s application PaaS category to business PaaS (bPaaS?).  There’s clearly a lot of interest in very focused platforms that make it easy to build relatively simple, constrained applications.  I’d argue that Force.com, Longjump, Orangescape and many others fit in that category.  And they definitely have their purpose.

But I see an opportunity between the infrastructure PaaS (categorized by Amazon Beanstalk) and the business PaaS as described above that can more correctly be termed an application PaaS.

That’s the space that vmWare’s CloudFoundry, the non-VM role Microsoft Azure options, and Apprenda’s SaaSGrid (disclaimer: I work for Apprenda) fit into. These platforms abstract away the infrastructure from the developer, but still allow for robust, complete applications to be deployed on them, and will provide shared services to address cross-cutting concerns.

Each of these categories has its place in the full spectrum of IT delivery.  Each provides a different level of application abstraction - and choosing the right one will depend on your specific requirements.