How Fluffy is Portability in the Cloud ?

I fly around a lot for a living, it's as much a pro as it is a con but one of the cool things about having that "downtime" in airport lounges and in the air is time away from noise and time to catch up on reading articles and white papers from across the industry. From sources both open and proprietary and all points east and west of the commercial doctrines that I've spent my working life trying to be more reflective of the realities of being more open and transparent. I often find myself (and I've been known to be frowned at by other passengers) avidly shaking head as I scrawl short punchy rude words across print offs of articles that I've thrown in my flight bag mouthing them quietly as I'm doing it like a idiot savant who just happens to have every gadget known to man accompanying him on a long haul flight. Having a reliance on an iPad and an Android 4.0 ICE 10" tablet hasn't helped as I don't really want to use a third party proprietary app to dump a page to a PDF so I can "read it later" and bookmarking something to read at 38,000 ft doesnt tend to work well without WiFi (most routes I travel don't have inflight WiFi). So I'm back in 1993 technology territory with my highligher pen / marker and a sheath of paper that I try not to confuse with boarding passes (yes I know you can get an app for that - I have one but I'm anal about organisation) and other travel ephemera that I carry.

It was during a period of melancholy catchup on a flight to Finland to talk at a Cloud Tour Red Hat were organising and where I was speaking that I found myself reading three or four various journalists take on what Cloud Application Portability actually was. It's a scary world where if you took their output, broke it down to core essential bullets took out the chaff and the hyperbole that all four disagreed with each other as to the true definition of application portability in Cloud. These are thought leaders so having my own ideas I went away and talked to some of the crew in the Cloud BU at Red Hat.

Now the cool thing about working for any Open Source company is not only are they often meritocracy based organisations but there is no such thing as a wrong answer, only a different methodology or construct to get to a reasoned answer. We just announced our most successful trading year and a $1.13 billion dollar turnover which considering the amount of time the good and the great at Red Hat putting care and conviction into what we do isn't therefore surprising. So I was looking, for a definition, from the movers and shakers at Westford our offices just outside Boston where the engineering pulse of Red Hat has a strong beat. It was therefore more surprising that given I'd read and scrawled over in luminous yellow marker four different takes on portability that those I approached came back with 95% of the same answer even though asked seperately to a man and without knowledge I was consulting with others across a massive business unit.

Taking this counsel aside I then looked into reasoning why so many educated thought leaders whose editorial is enjoyed and respected had their own opinion and direction. None of it wrong by definition but certainly differing paths to a differing conclusion.

It bugged me. It bugged me because some of the editorial and reasoning I read slightly misunderstood portability and took it as re-deploying applications to specific clouds with engineered boundaries and challenges and varying standards. Thats not portability - thats porting in the traditional sense. If you have to make your application fit a variety of vendor SLAs or engineering tenets then you're just adding workload and change control schema into your existing workload and process control management, whilst only slightly avoiding the lock in issue of being stuck with one Cloud Provider partner.

The issues around the lack of Cloud standards and their impact on interoperable stacks in Cloud providers again becomes a moot point if you consider that true portability doesn't start the day you finish your application and then think about where you are going to deploy it and the necessary major modifications or changes you'll have to make to get that to Cloud safely and with confidence and to be able to then deploy it on premise or a local stack or even on another provider. Scalability, the mandatory and additional security controls needed to deploy securely, the ability to orchestrate and to define scripts and provision all then become these parts of the portability piece that then get talked about in hushed tones and added to the project plan as "costs" and a guesstimate made as to how long that will add to the deployment / dev piece. And then start thinking about ongoing slightly different SVN/Git/CVS repositories for slightly varying versions of the same app or package and the necessary security controls and patching controls if you've had to dovetail your apps into a container type Cloud environment.

A journalistic appreciation of the issue that appeared in December then confounded me by making the sweeping statement that the only way application portability would happen is when embracing a PaaS offering from a specific vendor or using a proprietary platform (in this case Stackato). Answering 25% of her own question with 10% of the answer, not necessarily the wrong answer but not one I'm sure a lot of enterprises wanted to read given the fact that doing this right first time out isn't hard as long as you use open standards and technologies to do it.

The annoying thing for me was that a few weeks before the article that made me frown and scrawl rude words on it with a marker pen at 38,000 feet almost spilling my Duerrs and Ginger Ale, a blog article written by a good friend of mine James Labocki  had appeared (@jameslabocki if you want to follow his Twitter feed which I do advise as he's one of our brightest and best Cloud gods). The article gave a short but kickass editorial around portability to the layman and CloudForms, the Red Hat IaaS piece that we've been polishing and getting ready to package for release this year.

At this point I'm going to say if you want to avoid me ranting further on a Friday afternoon and you want to really be able to get the portability piece then I'm going to pass you into the safe care of James whose article you can read here.

Footnote: If you're a journalist wanting to write about portability then I also suggest that you read this post and follow James' blog as he's right on the money and you won't go far wrong using the right sources.

Addendum: I should have posted a link to the authoritative bible on the topic ! - Bryan Che's started out with a deep dive into the autonomy and power that can be evolved from understanding what we mean by open - feel free to read and share, here's the link.