With Cloud, The PaaSibilities Are Endless…

I read a very interesting article from ZDNet UK this morning titled “Amazon Cuts Off Stack at the PaaS”

The gist of the article is that according to Werner Vogels (@werner,) AWS’ CTO, they have no intention of delivering a PaaS service and instead expect to allow an ecosystem of PaaS providers, not unlike Heroku, to flourish atop their platform:

“We want 1,000 platforms to bloom,” said Vogels, before explaining Amazon has “no desire to go and really build a [PaaS].”

That’s all well and good, but it lead me to scratch my head, especially with regard to what I *thought* AWS already offered in terms of PaaS with BeanStalk, which is described thusly in their FAQ:

Q: What is AWS Elastic Beanstalk?

AWS Elastic Beanstalk makes it even easier for developers to quickly deploy and manage applications in the AWS Cloud. Developers simply upload their application, and Elastic Beanstalk automatically handles the deployment details of capacity provisioning, load balancing, auto-scaling, and application health monitoring.

Q: How is AWS Elastic Beanstalk different from existing application containers or platform-as-a-service solutions?

Most existing application containers or platform-as-a-service solutions, while reducing the amount of programming required, significantly diminish developers’ flexibility and control. Developers are forced to live with all the decisions pre-determined by the vendor – with little to no opportunity to take back control over various parts of their application’s infrastructure. However, with AWS Elastic Beanstalk, developers retain full control over the AWS resources powering their application. If developers decide they want to manage some (or all) of the elements of their infrastructure, they can do so seamlessly by using AWS Elastic Beanstalk’s management capabilities.

While these snippets from the FAQ certainly seem to describe infrastructure components that enable PaaS (meta-PaaS?) when you combine the other elements of AWS’ offerings, it sure as heck sounds like PaaS regardless of what you call it.

In fact, a Twitter exchange with @GeorgeReese, @krishnan and @jamessaull well summarized the headscratching:

With all those components, AWS can certainly enable PaaS platforms like Heroku to “flourish.” 

However, suggesting that despite having all the raw components and not pointing to it and saying “PaaS” is like having all the components to assemble a bomb, not package it as such, and declaring it’s not dangerous because in that state it won’t go off.

I’d say the potential for going BOOM! are real.  It appears Marten Mickos was hinting at the same thing:

However, Mickos disputed Vogels’ claim that Amazon is going to let a thousand platforms bloom.

“He will always say that, and Amazon will slowly take a step higher and higher,” he said, before pointing to Beanstalk as an example. “[But] in my view PaaS has middleware components… and I could agree that it is okay to add [those] to an IaaS.”

In the long term, as I’ve stated prior, the value in platforms will be in how easy they make it for developers to create and deliver applications fluidly.

I may not be as good at marketing as some, but that sounds less like an infrastructure-centric business model and much more like an application-centric one.

Moving on up is where it’s at.  I saw the scratching on the cave walls when I wrote “Silent Lucidity: IaaS — Already A Dinosaur. The Evolution of PaaSasarus Rex” back in 2009.

What do you think?  Is AWS being coy?

Related articles

• Understanding PaaS (shop.oreilly.com)
• PaaS Makes Progress in 2011 (readwriteweb.com)
• Deploy Your Own Platform as a Service (PaaS) for .NET Applications in Minutes with Apprenda (rackspace.com)

QuickQuip: Vint Cerf “Internet Access Is Not a Human Right” < Agreed…

Wow, what a doozy of an OpEd!

Vint Cerf wrote an article for the NY Times with the title “Internet Access Is Not a Human Right.” wherein he suggests that Internet access and the technology that provides it is “…an enabler of rights, not a right itself” and “…it is a mistake to place any particular technology in this exalted category [human right,] since over time we will end up valuing the wrong things.”

This article is so rich in very interesting points that I could spend hours both highlighting points to both agree with as well as squint sternly at many of them.

It made me think and in conclusion, I find myself in overall agreement.  This topic inflames passionate debate — some really interesting debate — such as that from Rob Graham (@erratarob) here [although I'm not sure how a discussion on Human rights became anchored on U.S. centric constitutional elements which don't, by definition, apply to all humans...only Americans...]

This ends up being much more of a complex moral issue than I expected in reviewing others’ arguments.

I’ve positioned this point for discussion in many forums without stating my position and have generally become fascinated by the results.

What do you think — is Internet access (not the Internet itself) a basic human right?

/Hoff

Related articles

• Silicon Alley Insider: VINT CERF: Internet Access Is Not A Human Right (businessinsider.com)
• Vint Cerf On Human Rights: Internet Access Isn’t On the List (yro.slashdot.org)
• Vint Cerf: Internet access isn’t a human right (news.cnet.com)
• Vint Cerf: Internet access isn’t a human right (venturebeat.com)
• Vint Cerf: ‘The internet is not a human right’ (go.theregister.com)

QuickQuip: Don’t run your own data center if you’re a public IaaS < Sorta…

Patrick Baillie, the CEO of Swiss IaaS provider, CloudSigma, wrote a very interesting blog published on GigaOm titled “Don’t run your own data center if you’re a public IaaS.”

Baillie leads off by describing how AWS’ recent outage is evidence as to why the complexity of running facilities (data centers) versus the services running atop them is best segregated and outsourced to third parties in the business of such things:

Why public IaaS cloud providers should outsource their data centers

While there are some advantages for cloud providers operating data centers in-house, including greater control, capacity, power and security, the challenges, such as geographic expansion, connectivity, location, cost and lower-tier facilities can often outweigh the benefits. In response to many of these challenges, an increasing number of cloud providers are realizing the benefits of working with a third-party data center provider.

It’s  a very interesting blog, sprinkled throughout with pros and cons of rolling your own versus outsourcing but it falls down in being able to carry the burden in logic of some the assertions.

Perhaps I misunderstood, but the article seemed to focus on single DC availability as though (per my friend @CSOAndy’s excellent summarization) “…he missed the obvious reason: you can arbitrage across data centers” and “…was focused on single DC availability. Arbitrage means you just move your workloads automagically.”

I’ll let you read the setup in its entirety, but check out the conclusion:

In reality, taking a look at public cloud providers, those with legacy businesses in hosting, including Rackspace and GoGrid, tend to run their own facilities, whereas pure-play cloud providers, like my company CloudSigma, tend to let others run the data centers and host the infrastructure.

The business of operating a data center versus operating a cloud is very different, and it’s crucial for such providers to focus on their core competency. If a provider attempts to do both, there will be sacrifices and financial choices with regards to connectivity, capacity, supply, etc. By focusing on the cloud and not the data center, public cloud IaaS providers don’t need to make tradeoffs between investing in the data center over the cloud, thereby ensuring the cloud is continually operating at peak performance with the best resources available.

The points above were punctuated as part of a discussion on Twitter where @georgereese commented “IaaS is all about economies of scale. I don’t think you win at #cloud by borrowing someone else’s”

Fascinating.  It’s times like these that I invoke the widsom of the Intertubes and ask “WWWD” (or What Would Werner Do?)

If we weren’t artificially limited in this discussion to IaaS only, it would have been interesting to compare this to SaaS providers like Google or Salesforce or better yet folks like Zynga…or even add supporting examples like Heroku (who run atop AWS but are now a part of SalesForce o_O)

I found many of the points raised in the discussion intriguing and good food for thought but I think that if we’re talking about IaaS — and we leave out AWS which directly contradicts the model proposed — the logic breaks almost instantly…unless we change the title to “Don’t run your own data center if you’re a [small] public IaaS and need to compete with AWS.”

Interested in your views…

/Hoff

QuickQuip: “Networking Doesn’t Need a VMWare” < tl;dr

I admit I was enticed by the title of the blog and the introductory paragraph certainly reeled me in with the author creds:

This post was written with Andrew Lambeth.  Andrew has been virtualizing networking for long enough to have coined the term “vswitch”, and led the vDS distributed switching project at VMware

I can only assume that this is the same Andrew Lambeth who is currently employed at Nicira.  I had high expectations given the title,  so I sat down, strapped in and prepared for a fire hose.

Boy did I get one…

27 paragraphs amounting to 1,601 words worth that basically concluded that server virtualization is not the same thing as network virtualization, stateful L2 & L3 network virtualization at scale is difficult and ultimately virtualizing the data plane is the easy part while the hard part of getting the mackerel out of the tin is virtualizing the control plane – statefully.*

*[These are clearly *my* words as the only thing fishy here was the conclusion...]

It seems the main point here, besides that mentioned above, is to stealthily and diligently distance Nicira as far from the description of “…could be to networking something like what VMWare was to computer servers” as possible.

This is interesting given that this is how they were described in a NY Times blog some months ago.  Indeed, this is exactly the description I could have sworn *used* to appear on Nicira’s own about page…it certainly shows up in Google searches of their partners o_O

In his last section titled “This is all interesting … but why do I care?,” I had selfishly hoped for that very answer.

Sadly, at the end of the day, Lambeth’s potentially excellent post appears more concerned about culling marketing terms than hammering home an important engineering nuance:

Perhaps the confusion is harmless, but it does seem to effect how the solution space is viewed, and that may be drawing the conversation away from what really is important, scale (lots of it) and distributed state consistency. Worrying about the datapath , is worrying about a trivial component of an otherwise enormously challenging problem

This smacks of positioning against both OpenFlow (addressed here) as well as other network virtualization startups.

Bummer.

Related articles

• What’s Nicira? Read this and find out. (gigaom.com)
• Bits Blog: What Is Nicira Up To? (bits.blogs.nytimes.com)
• A Contentious Question: The Value Proposition & Target Market Of Virtual Networking Solutions? (rationalsurvivability.com)
• What is Nicira really up to? (ioshints.info)
• The Killer App For OpenFlow and SDN? Security. (rationalsurvivability.com)

When A FAIL Is A WIN – How NIST Got Dissed As The Point Is Missed

Randy Bias (@randybias) wrote a very interesting blog titled Cloud Computing Came To a Head In 2011, sharing his year-end perspective on the emergence of Cloud Computing and most interestingly the “…gap between ‘enterprise clouds’ and ‘web-scale clouds’”

Given that I very much agree with the dichotomy between “web-scale” and “enterprise” clouds and the very different sets of respective requirements and motivations, Randy’s post left me confused when he basically skewered the early works of NIST and their Definition of Cloud Computing:

This is why I think the NIST definition of cloud computing is such a huge FAIL. It’s focus is on the superficial aspects of ‘clouds’ without looking at the true underlying patterns of how large Internet businesses had to rethink the IT stack.  They essentially fall into the error of staying at my ‘Phase 2: VMs and VDCs’ (above).  No mention of CAP theorem, understanding the fallacies of distributed computing that lead to successful scale out architectures and strategies, the core socio-economics that are crucial to meeting certain capital and operational cost points, or really any acknowledgement of this very clear divide between clouds built using existing ‘enterprise computing’ techniques and those using emergent ‘cloud computing’ technologies and thinking.

Nope. No mention of CAP theorem or socio-economic drivers, yet strangely the context of what the document was designed to convey renders this rant moot.

Frankly, NIST’s early work did more to further the discussion of *WHAT* Cloud Computing meant than almost any person or group evangelizing Cloud Computing…especially to a world of users whose most difficult challenges is trying to understand the differences between traditional enterprise IT and Cloud Computing

As I reacted to this point on Twitter, Simon Wardley (@swardley) commented in agreement with Randy’s assertions, but strangely what I found odd again was the misplaced angst by which the criterion of “success” vs “FAIL” that both Simon and Randy were measuring the NIST document against:

Both Randy and Simon seem to be judging NIST’s efforts against their lack of extolling the virtues, or “WHY” versus the “WHAT” of Cloud, and as such, were basically doing a disservice by perpetuating aged concepts rooted in archaic enterprise practices rather than boundary stretch, trailblaze and promote the enlightened stance of “web-scale” cloud.

Well…

The thing is, as NIST stated in both the purpose and audience sections of their document, the “WHY” of Cloud was not the main intent (and frankly best left to those who make a living talking about it…)

From the NIST document preface:

Stuff I’ve Really Wanted To Blog About But Haven’t Had the Time…

This is more a post-it note to the Universe simultaneously admitting both blogging bankruptcy as well as my intention to circle back to these reminders and write the damned things:

1. @embrane launches out of stealth and @ioshints, @etherealmind and @bradhedlund all provide very interesting perspectives on the value proposition of Heleos – their network service virtualization solution. One thing emerges: SDN is the next vocabulary battleground after Cloud and Big Data
2. With the unintentional assistance of @swardley who warned me about diffusion S-curves and evolution vs. revolution, I announce my plan to launch a new security presentation series around the juxtaposition and overlay of Metcalfe’s + HD Moore’s + (Gordon) Moore’s+ (Geoffrey) Moore’s Laws. I call it the “Composite Calculus of Cloud Computing Causality.”  I’m supposed to add something about Everett Rogers.
3. Paul Kedrosky posts an interesting graphic reflecting a Gartner/UBS study on cloud revenues through 2015. Interesting on many fronts: http://twitpic.com/7rx1y7
4. Ah, FedRAMP. I’ve written about it here. @danphilpott does his usual bang-on job summarizing what it means — and what it doesn’t in “New FedRAMP Program: Not Half-Baked but Not Cooked Through”
5. This Layer7-supplied @owasp presentation by Adam Vincent on Web Services Hacking and Hardening is a good basic introduction to such (PDF.)
6. via @hrbrmstr, Dan Geer recommends “America the Vulnerable” from Joel Brenner on “the next great battleground; Digital Security.” Good read.
7. I didn’t know this: @ioshints blogs about the (Cisco) Nexus 1000V and vMotion  Sad summary: you cannot vMotion across two vDS (and thus two NX1KV domains/VSMs).
8. The AWS patchocalypse causes galactic panic as they issue warnings and schedules associated with the need to reboot images due to an issue that required remediation.  Funny because of how much attention needing to patch a platform can bring when people set their expectations that it won’t happen (or need to.)  Can’t patch that… ;(
9. @appirio tries to make me look like a schmuck in the guise of a “publicly nominated award for worst individual cloudwasher.” This little gimmick backfires when the Twitterverse exploits holes in the logic of their polling engine they selected and I got over 800,000 votes for first place over Larry Ellison and Steve Ballmer.  Vote for Pedro

More shortly as I compile my list.

Enter the Data Huggers…

Image via Wikipedia

A tale of yore:

And from whence the light of the heavens did shimmer upon them from the clouds above, yea the Server Huggers did at first protest.

Yet, as the virtual supplanted the corporeal — these shells of the buzzing contrivance –  they did wilt wearily as the compression of the rings unyieldingly did set upon them.

And strangely, once shod of their vestigial confines, they learned once again to rejoice and verily did they, of their own accord, assume the mantle of the make-believe server clan, and march forward lofting their standards high  to readily bear their mark of the VM.

But as the once earth-bound, now ethereal, ascended their offers to the heavens and their clouds, the vessels of their capital dissolved their curtailment once more.

The VMs became vapor, their service, the yield.  This tribe, once coupled to the shrines of their wanton packaging, became unencumbered once more.

Yet when these offers were set free upon the land, their services — compliant, supple and malleable — were embraced as a newfound purse, and the Clan of the App guarded them jealously once again, hoarding their prize from the undeserving.

Their reign, alas, did not last; their bastions eroded as the platforms that once gained them allegiance crumbled with the surfeit of consumption — their dispersion widespread and resources taxed.

Thus became the rule of the Data Clan whose merit lay in wait as the pretenders of the Cloud were forced to kneel in subservience.

For their data was big and they clutched it to their bosom as they once did their apps, VMs and carnal heat pumps…

It’s interesting to see how in such a short time we’ve seen the following progression:

Server Huggers > VM Huggers > App Huggers > Data Huggers

I wonder what’s next in the lineage of hugs?

/Hoff

802.bah – Beware the SiriSheep Attack!

On the heels of a French group reverse-engineering the Siri protocol by intercepting requests to the Internet-based server that Apple sends Siri requests to, Pete Lamonica, a first-time Ruby developer has produced another innovative hack.

Lamonica has created an extensible proxy server to enable not only interception of Siri requests, but provide connectivity/interfacing to other devices, such as his Wifi-enabled thermostat.

Check it out here:

What I think might be an interesting is if, in the future, we see Siri modified/deployed in the same way as Microsoft’s Kinect is today used to control all sorts of originally-unintended devices and software.

Can you imagine if $evil_person deployed (via Proxy) the Siri version of the once famed Starbucks pwnership tool, FireSheep?  SiriSheep.  I call it…

Your house, your car, your stock trades, emails, etc…all Siri-enabled.  All Siri-pwned.

I have to go spend some time with the original code — it’s unclear to me if the commands to Siri are sent via SSL and if they are, how gracefully (or ungracefully) errors are thrown/dealt with should one MITM the connection.  It seems like it doesn’t give a crap…

Thanks to @JDeLuccia, here’s the github link to the original code.

/Hoff

Related articles

• Siri proxy adds tons of functionality, doesn’t require a jailbreak (hackaday.com)
• SiriProxy Adds Custom Commands to Siri to Control Anything on Your Home Network [Video] (lifehacker.com)
• Coder creates Siri proxy (go.theregister.com)
• Siri reverse-engineered and its inner workings exposed (intomobile.com)
• Siri Argument (laughingsquid.com)

Cloud: The Turducken Of Computing? [Oh, and Happy Thanksgiving]

In these here United States Of ‘Merica, we’re closing in on our National Day of Gluttony, Thanksgiving.

As we approach #OccupyStuffedGullet, I again find myself quizzically introspective, however frightening the prospect of navel gazing combined with fatal doses of Tryptophan leaves me.

Reviewing the annual list of consumables for said celebration in conjunction with yet another interminable series of blog posts on “What Cloud *really* means for [insert target market here,]” I am compelled to suggest that what Cloud *really* means and *really* represents is…

A Turducken.

According to the Oracle of Mr. Wales, a Turducken is as follows:

A turducken is a dish consisting of a de-boned chicken stuffed into a de-boned duck, which itself is stuffed into a de-boned turkey. The word turducken is a portmanteau of turkey, duck, and chicken or hen.

The thoracic cavity of the chicken/game hen and the rest of the gaps are stuffed, sometimes with a highly seasoned breadcrumb mixture or sausage meat, although some versions have a different stuffing for each bird.

I’ll leave it to you to map the visual to the…Oh, who am I kidding?

What does this *really* have to do with Cloud? Nothing, really, but I’m rather bloated with the resurgence of metaphors and analogs which seek to clarify new computing recipes in order to justify more gut-busting consumption, warranted or not, diets-be-damned.  But really…sometimes a dish is delicious in its simplicity and doesn’t need any garnish.

In fact, this comparison isn’t really at all that accurate or interesting, but I found it funny nonetheless…

Frankly, it’s *really* just an excuse to wish you all a very merry ClouDucken Day

May your IT be stuffed and your waistline elastic.

/Hoff

Oh, c’mon…

Story here from Network World.

Frankly, XML Signature-Wrapping and XSS don’t represent “massive security flaws in cloud architectures.”

They represent unfortunate vulnerabilities in authentication mechanism and web app security, but “cloud architecture?”

These vulnerabilities were also fixed.  Quickly.

Further, while the attack vector will continue to play an important role when using Cloud (publicly) as a delivery model (that is, APIs,) this story is being over played.

Will this/could this/is this type of vulnerability pervasive? Certainly there are opportunities for abuse of Internet-facing APIs and authentication schemes, especially given the reliance on vulnerable protocols and security models?

Perhaps.

Is it scary?

Yes.

See: Cloudifornication and Cloudinomicon.

Related articles

• Researchers demo cloud security issue with Amazon AWS hijacking attack (infoworld.com)
• Shared security flaws of cloud computing (ritcyberselfdefense.wordpress.com)
• Hackers could have taken over AWS (theregister.co.uk)