The Loose Couple's Blog

So, in perhaps one of the worst kept embargoes of 2012 to date, Citrix finally announces their intent to join the ASF (Apache Software Foundation) and “donate” the Cloudstack code to the open source community. 

Anyone with the requisite amount of brain cells to challenge algae could have seen this move coming and, despite it being touted as “brash, bold and brave”, it was really fairly obvious and I, for one, applaud Citrix, but not for the reasons you might think.

First, let’s credit Mark Templeton and the team with continuity. While others may pivot around their approach and their business models, Templeton has remained steadfast, unwavering is his commitment to open source and ensuring that, from the moment the acquisition of Simon Crosby and Ian Pratt’s XenSource (latter to become XenServer) was completed, every keynote and speaking engagement has led with the open source / open compatibility theme. Bravo.

Second, let’s make a subtle, yet important distinction between an Apache Project and the Apache License. Each official Apache Project is licensed under the terms of the Apache License, but not every piece of FOSS licensed under the Apache License is an Apache Project. 

According to Wikipedia:

All software produced by the ASF or any of its projects or subjects is licensed according to the terms of the Apache License. Some non-ASF software is also licensed using the Apache License. As of November 2010, over 6000 projects located at SourceForge.net were available under the terms of the Apache License. 

This is important to understand because, if I understand the Citrix strategy correctly, Cloudstack will become an official Apache Project via the incubator process, which immediately puts it in the same stable as other, more notable successes, such as HTTP Server, Cassandra and Hadoop. By cozying up to these new kids on the block, this arguably positions Cloudstack to be considered as a “natural relative” of these products when building out bottom-to-top next generation software stacks. That, in itself, holds some interesting possibilities for commercially supported deployments and services engagements. 

Additionally, the Apache Projects are characterized by a collaborative, consensus-based development process and an open and pragmatic software license. Sounds idyllic. Interestingly, OpenStack is Apache Licensed, but is not currently an official Apache Project. Read in to that what you will.

Should it be confirmed, I will not be in the least surprised by Citrix’ exit from OpenStack. The deep-rooted politic, hidden agendas and the overall return have made little sense in terms of commercial opportunity and the de facto positioning of “it [feature] will be available in the next release” will not have sat well within the corridors of power. Add that to the recent “insert coin to continue” trend within OpenStack and the dreadful, garish “loophole” in the Apache License (sigh) that almost begs for “embrace and extend but do not return code” will have contributed significantly to the sounding of the death knell. How the latter plays out for Cloudstack will be interesting to observe too.

Now, back to the topic at hand. On a personal note, I am a little disappointed that the “rabbit out of the hat” wasn’t the announcement of a deeper relationship with AWS. Since the recent announcement from Eucalyptus (which interestingly didn’t see the light of day as an official AWS statement), I have been feeling more and more perplexed as to why Citrix (who have a natural synergy with AWS via Xen today) were not able to nail this to make inroads into an “AWS compatible and supported Private Cloud” solution.

Perhaps unbeknown to many, cloud.com already had / has a layer called “Cloudbridge” (not to be confused with the other Citrix Cloudbridge) which essentially mapped certain pieces of functionality from the EC2 API such that anyone who had written management tools for Cloudstack could use those same tools to perform functions within AWS. While Eucalyptus, it must be stated, have literally set their stall out to emulate the EC2 API from their inception, they are nowhere near the size of muscle of a Citrix, yet they seem to have stolen a chink of the limelight. I am left scratching my head as to how that was allowed to happen.

To me, a Citrix / Amazon snuggle-fest, remembering that OpenStack recently dropped their original intent to support the EC2 API, would have made an interesting proposition and helped play into Citrix’ strength – the enterprise.

Finally, no assessment would be complete without thinking about the service provider side. This, as you may recall, is what kick-started cloud.com’s successes with Cloudstack and prompted Citrix to dig deep into their pockets to acquire the small startup. Even with a move to Apache, the value proposition to the service provider markets (and I can’t believe I am about to say this) will continue to be in the opportunity to sell “traditional” XenDesktop/App, licences, XenServer licenses, Netscaler licenses, EMS Cortex (whatever it became) Control Panel licenses and last but not least, CloudPortal licenses – BSS/OSS is critical to service providers and the Citrix solution is pretty neat overall.

The folks on Great America Parkway may be “brash, bold and brave” but stupid? They certainly ain’t.

Over the last few days, I’ve read a selection of articles from some so-called “leading” tech journalists who continue to position “cloud” and “cost savings” firmly in the opening sentences of their respective copy, baiting the target audience into joining their supposition that at the end of the unicorn rainbow, lies indeed, the proverbial pot of gold.

Personally, aided by numerous years of running large enterprise budgets, previous blog posts on the topic, practical experiences of cloud deployments and a posthumous hat tip to one Stanley William Jevons, I have made the mental switch from “how much does it cost?” to “how much value does it bring?”

The latter, I believe, is often more difficult to quantify due to value often being talked about, though much less accurately measured or understood, in terms like direct and indirect – yet cost, generally, remains central to most tactical and strategic decision making processes and is certainly tangible to any organization, irrespective of size or stature.

While many of today’s traditional enterprises are in a relatively early stage of cloud adoption (whether that be private, public or and a combination of the two), they will undoubtedly be using “cost savings” as a driver as they plot their way through the many waypoints on the journey. However, there is another “C” word that is waiting in the wings, ready to spring a few unwelcome surprises as the enterprise bravely plows these new furrows.

Consumerization.

Now, unless you’ve been in under a rock for the last few years, it would be quite difficult to have missed the incredible growth in consumer driven technology and devices, along with a continued downward trend in the cost of acquisition. Even prior to the smartphone revolution and arguably at the start of the BYOC rush, there was a marked dive in the cost of “consumer-grade” laptop and netbooks, many of which were of a sufficiently good specification to meet the needs of many users.

Yet many enterprises remained stoic, rigid and largely unwilling to fully embrace an all-encompassing BYOC strategy, citing a myriad of reasons why this approach would be doomed for failure. Instead, they prefer to continue down the path of delivering users what they think they need rather than what the users actually want and at a cost point that often didn’t sit well with what those same users were seeing in the non-work environment.

In the recent past, I’ve had, and heard of, several discussions with folks inside large organizations who had a chargeback model for hardware. The question raised by cost-conscious staff dotted around the business goes something like “so, why do you charge me $350 per month for a laptop when I can go to Best Buy / PC World / Delete as applicable and buy one for that price?”

Of course, there is probably a very good answer for this, and, from my experience, it usually stems from either a) a lack of understanding on behalf of the end user of what constitutes the component(s) of the cost or b) a lack of basic transparency of the IT department and their inability / unwillingness to explain the cost model.

Either way, the aforementioned laptop, available at a consumer price point, is a clear example of how the consumer space is driving business demand and not, as has been the case historically, the other way around.

This “phenomenon” doesn’t stop at hardware. In my current world, I am fortunate enough to be working on a very interesting strategy for combining business challenges with API technology and mobile applications, for big enterprise consumption.

Cool stuff. Yet, in this current world, emerges a new challenge – how do we take the historic world of “traditional enterprise software development” with its long tails and relatively high upfront and running costs and deliver enterprise mobile applications, to devices that are consumer grade, at a price point that echoes what the end user would find in the Apple App Store and the Android Marketplace?

I ask the above somewhat rhetorically, for now.

As you likely know from your own experience, low price points and high numbers of downloads are the basic principles of success for commercial mobile application developers. I have rarely paid more that $9.99 for any given application – but can that expectation realistically translate into the enterprise? What model would look attractive to an end user of an enterprise mobile application? How can we compete, irrespective of whether we plan to deploy in a private enterprise app store?

In the same way that the $350 per month cost of the laptop often includes many components of the upfront acquisition, licensing, management and support costs, I fear an even bigger challenge is coming to enterprise mobile applications. Where smart organizations are lining up to enable their businesses, they must figure out how to set realistic expectations and internal price points that allow internal (and external) business opportunities to be turned into mobile application products, before end users find their own ways of working that marginalize internal development teams and IT organizations in general.

This isn’t a command and control discussion, it’s a basic alignment principle. There’s more than a fair chance that your initial foray into enterprise mobile apps will require some kind of connectivity to your current enterprise app / data silos. Your workforce simply can’t find commercial applications to meet all their needs. Fact.

I’m already convinced (having seen it first hand) that BYOA, Bring Your Own Applications, is upon us. Mobility shifts the paradigm to the other end of the spectrum from the “locked down desktop” of yesterday. It’s easier for users to acquire, use and be productive with applications that are available to them at giveaway prices and it’s far easier to install them on devices that they own and pay for.

How much would you expect your IT department to charge you for any given mobile application? Don’t know? If that’s the case, then maybe you’re focusing on the value, rather than the cost.

I hope so, because I’ve never heard of a really successful solution that began with a discussion about how much something cost. 

I’m convinced that long after the lights have been switched off on the yawningly dull public vs private debate, today’s progressive enterprise who has reasoned with, understood and accepted that there is absolutely and categorically no textbook answer to the dizzying and hard-to-demystify rhetorical questions around cloud and where one should put one’s stuff, will be sufficiently advanced to have moved from “thinking” to “doing” and the fruits of their labor, at least on the surface, should be starting to show.

Assuming, for the sake of this post, that my supposition is correct, the enterprise may now have become the custodian of an application and service portfolio of various sizes, which although perhaps considered more efficient than the previous incarnation, may still appear somewhat of a mixed bag.

If the organization’s capability to execute matches the due diligence and planning effort, such a portfolio may now include a set of consolidated applications running on virtual machines, in both on and off premise locations, along with the usual appurtenances of enabling infrastructure and tools for management, monitoring, self-service, automation, orchestration and governance.

Not a bad start. But, if the general themes that I’ve witnessed in other large organizations hold true, then as we collectively prepare to wave adios to 2011, labeling it another foundational, if not relatively disappointing year, we aren’t yet seeing great swathes of investments in the fundamental and complete re-architectures of line of business applications in preparation for deployment on public clouds (specifically IaaS or PaaS) nor in the wholesale strategic migration of line of business application migrations to SaaS…..so isn’t it a case of if you always do what you always did, you’re always going have what you always got ?

Well, perhaps not…could, in fact, the enterprise that has successfully achieved at least some of the above actually be sitting in the box seat, ready to take a swing at a strategy to address the latest phenomenon to hit the buzzword bingo halls of our incessantly unforgiving industry…Big Data? Quite possibly.

To me, without context, the words “Big Data” are teeth-achingly dour. I can almost hear the countless wasted words of fist clenching opining, as those with presumed dogs-in-fights work tirelessly to craft definitions (ahead of positioning products) that outline “structured vs unstructured”, “what constitutes big vs small data” and more latterly, why you can’t do without it. Sound familiar?

Add a little context, however, and it’s easy to begin to see how the enterprise that has stuck to their plan and made progress will find that the work they undertook to consolidate the portfolio becomes incredibly valuable as the unit of value shifts from virtual machines to the discovery and presentation of aggregated data contained within. As we look, and in some cases, yearn, for that value, I believe we’re moving past the stuffy concepts of traditional Business Intelligence (BI), which, to many, still comes replete with the unwelcome specter of huge complexity and matching cost.

By consolidating, which I believe is a critical step in any practical enterprise cloud experiment, you may still have monolithic applications, often in silos, but you have reduced the number of moving parts and probably have a very good handle on some key information – which applications are consuming the least storage, the most storage (i.e. generating most data), you know where they are running and equally importantly, who owns them – that’s a very good position to be in.

As the old Management 101 adage goes, you can’t manage what you can’t measure, so how could you have any realistic chance with a comprehensive Big Data strategy if you don’t know what you have?

From my experience, I would suggest that in the lion’s share of today’s traditional enterprise environments, much of the data is of the structured variety. Relational databases are still the lynchpin of many enterprise systems. I still question, for example, the industry numbers of “percent of all servers virtualized vs physical” so if anyone were to try and convince me that there are tons of enterprise applications using NoSQL, I’d raise a quizzical eyebrow or three.

Although there are undeniably more and more sources of enterprise unstructured data (from the more obvious platforms like email to the less obvious ones such as social networks), it would make sense to me for enterprises to begin with what they have in their consolidated portfolio – intelligently questioning disparate data sets to see how many nuggets of data gold are buried deep within the bowels of the organization.

The evolution of big data will certainly be interesting to follow. I’m sure we will have the usual cycle of hype accompanied by a plethora of twists on definitions from visualization to aggregation and velocity to gravity and vendors small and large, jostle for position as the space continues to grow throughout 2012 and beyond.

Recently, I was giving some thought to, and trying to boil down, a simple sentence that an enterprise might use to justify a big data strategy. I ended up with this.

“We want to use the data we have to help the company be more competitive, to win more work, and we want to use the data we generate to be able to execute that work more efficiently.”

Perhaps it’s just me, but this is a much more compelling statement than anything I’ve heard on why enterprise needs cloud. Cloud, of whichever denomination, is moving toward it’s rightful role – being the engine room for tomorrow’s data factory – in which the end product is the delivery of real business value through new and inventive ways of making sense of a whole, huge heap of 1’s and 0’s.

Following the November 7 announcement of Rackspace’s tantalizingly named (and OpenStack-powered) Rackspace Cloud: Private Edition, I’ve found that I have descended into doing something I don’t normally do – getting all hot under the collar over what amounts to really nothing more than a clever positioning statement.

First, let me clear a few things up. I have no dog (left) in the OpenStack fight, nor do I really care to challenge Rackspace’s latest positioning as it relates to analyzing their strategy and what it may or may not mean. I am, and always have been, a believer in open source, a great fan of the OpenStack concept and have written about it many times in a positive light. However, as some of you may recall, I have always been vocal about the need for there to be more traditional enterprise customers (I have really gone past caring about SPs/MSPs/Telcos) to be involved in its development and today, with little evidence of that actually occurring, I remain convinced that the current OpenStack “product” is nothing more than a promising science project – making the announcement that Rackspace are now ready to fling open it’s genetically-modified doors to, gasp, the enterprise, more than a little bemusing.

It is a well known fact that Rackspace has poured a considerable amount of time and money into OpenStack and has by far and away (since the acquisition of Anso Labs) the largest percentage of contributors to the community. Hardly a surprise, you may conclude, considering they have bet their proverbial house on using OpenStack to power the next generation of their public cloud offerings, and with such potential revenue at stake in the great multi-billion dollar cloud-grab, they simply can not afford for it to fail – at any cost.

Is that why, perhaps, a peek behind the curtain may reveal a community governed by a benevolent dictator (BD) rather than one of a joyful meritocracy ? Is that a good thing ? Do we need a Cloud Spring ? Well, let me help you decide.

A BD project is led by a benevolent dictator and managed by the community. That is, the community actively contributes to the day-to-day maintenance of the project, but the general strategic line is drawn by the benevolent dictator. In case of disagreement, they have the last word. It is the benevolent dictator’s job to resolve disputes within the community and to ensure that the project is able to progress in a coordinated way. In turn, it is the community’s job to guide the decisions of the benevolent dictator through active engagement and contribution.

In the context of this post, this hypothesis alone gives me a very uneasy feeling. Anyone who has paid even the slightest passing interest in OpenStack’s progress will have witnessed a steady throng of the technology vendor hoi-polloi clamoring to contribute, desperate for a slice of the action and all in the name of the community. However, given the familiar nuances of the Apache License (where there is no requirement for any modified code, enhancement or additional special sauce to be returned to the community) and the fact that we are already seeing a growing number of both startups and large OEM vendors creating their own combinations of architectures, distributions and services on top of a frankly wobbly footing, I am beginning to wonder if this bright star may burn out before it has chance to really shine.

Despite what many of the regular twitter-contributing experts have said, I don’t believe that this trend in “calling everything Open” is represented in a level playing field. In fact, it’s positively lunar. In my extremely humble opinion, the parallels drawn between let’s say Facebook’s OpenCompute platform and OpenStack, are misleading and wholly inaccurate. They do not, for example, take into consideration the number of contributors (few vs many), the reasons (the real ones) for the many contributors involvement and last but not least, the revenue potentials of each. I remain to be convinced that there is a significant amount of money to be made from the release of the blueprint of efficient data center design and throwaway hardware - certainly not compared to why we’re already seeing a great jostling for position in the marketplace for the stuff that sits on top of it.

So, back to Rackspace for a moment. I actually think their “we can’t fail, so you can’t fail” approach is incredibly clever but it falls woefully short in the reality stakes and borders just a little on cloud fantasy. Other than at a few tech-savvy organizations, there has been little practical production deployment of OpenStack in large organizations and I can’t imagine (especially given my beta experiences of this offering which were, shall we say, less than mindblowing) that, and I quote, customers looking to build medium-to-large scale private clouds are going to be beating the door down to implement this from a reference architecture which, among other bizarre recommendations, suggests a hypervisor that:

a) is not one that most traditional enterprises will have any experience of
b) is not the best for running Windows workloads which make up the lion’s share of enterprise server installed base
c) is not the same as the one that Rackspace use today (so quite what expectation that sets for customers is a mystery)

Sobering to think that at the bottom of the cloud pile, unfortunately, sits the poor unassuming customer, increasingly perplexed by meaningless terminology and unwittingly drowning in choice. He dreams of openness and the idea of no lock in, yet the more I see the unwelcome combination of hidden agendas and greed-fueled fragmentation rearing their gorgonesque ugly head, the more I fear those dreams will never be realized.

Customers won’t buy what they don’t understand and perhaps my biggest, and until now most secret fear for OpenStack is that the fragmentation (not forking – people who say forking are either posh Brits swearing or people who don’t understand how open source projects work but like to think they do) reaches such a level that one can no longer be sure of the integrity of the OpenStack components themselves.

Can you imagine it ? “I am running Crackhouse’s version of OpenStack”…”ah yes, but I heard that’s not real OpenStack”. What a terrifying thought for the very compatibility OpenStack promised to do so much to solve.

So, my final word on this is somewhat rhetorical – overall and on balance, there have been relatively few major open source successes compared to those that offered promise and petered out weakly and cling to life as shadows of their once-promised greatness as ubergeek utilities wallowing in a sea of cool. I hope that in OpenStack we don’t end up missing a golden opportunity because the benevolent dictator was broadcasting when he should have been be tuning in.

If you whisper the word “Infrastructure” to me, I can guarantee that as quick as a flash, I will conjure up two very clear yet very different mental images, each telling an interesting story of the juxtaposition of my professional life.

One will be of a sterile data center, you know, the kind that we’ve grown up around (back when they were called machine rooms and then computer rooms and then…you get the drift) containing row upon row of dull 42U racks, a symphony of twinkly lights and the constant hum of a small country’s worth of drawn power.

The other will be of an expansive construction site, you know, the kind that you see on TV shows – airports, railways, highways and the like – holding your bemused gaze as an under-qualified yet over-excited voice over man wills you to try to figure out how do they build that (as the synchronized yet precarious dance of a thousand heavy cranes lifts and guides these giant super-structure components into place with an unerring accuracy.)

Having been involved with building the physical implementations of the mental images in some of the more interesting parts of the world, it is certainly gratifying to deliver these, yet equally, it is sobering to come to the shuddering realization that none of it actually matters to the ultimate customer of the facility you’re building.

Seriously. It really doesn’t matter.

Now, the key piece here is ultimate customer. Let’s say you’re in the airport operations business, then you’re probably going to care a lot about the way your facility is built and the same is certainly true for the data center provider business.

In turn, your customer, whether it be airline or hosting provider, will certainly care about what you offer, but if you move that further along the chain, you end up at the ultimate customer – someone who is concerned only with acquiring a service and it’s probably a very safe bet that they will have no idea about how the facility they are receiving that service from was built, nor indeed how it operates.

This latest in the line of bizarre revelations came to me last week when, whilst standing in the truly vast space of a construction work-in-progress passenger terminal somewhere in the middle of the Arabian Gulf, I was tinged with a strange sadness to think that once the work is done and that magnificent airport is open for business, the people who pass through it will most likely only be concerned about making sure they can talk their way into getting the check-in agent to turn a blind eye to their overweight luggage or whether their name is being proudly displayed on a tattered clip-board, held up in the arrivals hall by a one-eyed limousine driver.

And. That. Is. A. Heinous. Crime. If only they knew…..if only they cared.

When that time arrives, the people that built the facility will be off doing something else, somewhere else, proud of what they have achieved, but playing no further part in the day to day operation of the facility. That’s what they do.

My experience of building clouds stretches back to around the same time that the construction work started on the very same passenger terminal. In fact, in a somewhat existentialist twist, I was building clouds to enable the things that would enable the putting of people into clouds, a process that took around 4 years of re-architecting, engineering, building and operationalizing one of the first (and obviously I’m going to say the best) private cloud infrastructures.

And. It. Has. Lots. Of. Twinkly. Lights.

Today, that very same cloud is now being used to deliver some incredible services to enable some amazing innovation, including the delivery of a new generation of mobile applications that will make a huge difference to the way work is done across the globe. That’s why it was built and that’s why it is successful.

Am I Proud? Yes.  Am I Attached? No

Just like the guys who are off doing something else, somewhere else, so must we all move on, but what is clear is that the ultimate customers of that cloud have no idea how it was built, nor how it operates, nor do they care – they are the passengers in a terminal, the riders on a train and the drivers on a highway.

Infrastructure is certainly a very important component of the civilized world and the not-so-civilized world of cloud computing. Without it, we have no foundation to provide essential services, but what would use a railway without trains, an airport without ‘planes or a highway without cars? Not much, I would argue.

Isn’t it time that we stopped focusing quite so much time and wasted energy on the bits that really don’t matter and switch instead to understanding how we apply what we’ve can build (or have built) to benefit those ultimate customers? Does anyone really care about squeezing the last living terrameh-flop out of a bunch of iron?

Next time you find yourself in a cloud mega data center take one quick mental picture and store it. When you find yourself at the airport at night, look across the apron, take another and store that.

Put your ultimate customer hat on. Close your eyes. Stitch the two photos together and whisper softly to yourself….

“Infrastructure, infrastructure, infrastructure….”

The result? Can’t you see?

It’s. Just. Lots. Of. Twinkly. Lights.

Almost a year ago, I was deep in conversation with other members of the Clouderati discussing (philosophically, I might add) where the future of cloud computing and the associated services might lead and, more importantly, what that may mean for the next generation of enterprise CIOs.

You may be aware of my enterprise background and recent experience in delivering business-aligned IT transformation (which included cloud, lots of it) and, it’s no secret that based on that very experience, I’ve written numerous blog posts that allude to the challenges that today’s crop of enterprise CIOs face when trying to identify, select, procure and manage cloud services to augment or replace their current in-house offerings.

You may not be aware that during the aforementioned Clouderati conversation, I offered the following two suggestions as food for thought:

As businesses demand even more agility, the next generation of Enterprise CIOs will be much more akin to service aggregators than those who managed the traditional but very complex, “buy long and buy for peak” software contracts.  

As the number of truly attractive cloud services increases, and the security, reliability and cost barriers to their adoption decreases, we will see a growing demand for a “Cloud Concierge”, almost a new generation of SI, who acts as a single point of knowledge for the new CIO, helping deliver a range of fit-for-purpose solutions.

(* In fact, I mention the concept of CIOs-as-service-aggregators in this post from November 2010)

Last week, the folks at NIST (who appear to have either been nominated or nominated themselves as the digitized equivalent of the Custodian Of The Two Holy Mosques) released their Cloud Computing Reference Architecture document, which now includes a section on “Cloud Brokers”.

Despite my obvious (yet short-lived) joy at seeing something I had espoused turn up in something as powerful as a NIST document (yawn), I have a really hard time with the word “Broker” in the context of how NIST have tried to define it.

According to Wikipedia, “a Broker is a party that arranges transactions between a buyer and a seller, and gets a commission when the deal is executed.”

For me, it somewhat stereotypically conjures up pinstriped yuppies sipping bottles of Dom Perignon, vastly overpaid, incredibly indulgent, annoyingly arrogant and probably not the best mental poster child for an already over cloud-washed and double-dip recession fearing buying public.

Yet, let’s be sure to give credit where credit is due (pardon the pun).

If you spend a few minutes reading the NIST definition, they’ve done a pretty good job at explaining the specifics of what their “Cloud Broker” might do:

Service Intermediation: A cloud broker enhances a given service by improving some specific capability and providing value-added services to cloud consumers. The improvement can be managing access to cloud services, identity management, performance reporting, enhanced security, etc.

Service Aggregation: A cloud broker combines and integrates multiple services into one or more new services.  The broker provides data integration and ensures the secure data movement between the cloud consumer and multiple cloud providers.

Service Arbitrage: Service arbitrage is similar to service aggregation except that the services being aggregated are not fixed. Service arbitrage means a broker has the flexibility to choose services from multiple agencies. The cloud broker, for example, can use a credit-scoring service to measure and select an agency with the best score.

If I remove the myriad of technical, commercial and operational fundamentals that appear to have been glossed over, look objectively at the above, and substitute the word “Broker” for “Concierge”, it is much easier for me to understand, and further embellish, how this might logically work by simply considering what the Concierge at a hotel might do for its guests – typically the Concierge has a great deal of local knowledge of all services in the area, can source quickly, efficiently and usually from a list of known, trusted and proven suppliers.

They provide the guests with their expertise, on tap, 24×7, usually for little or no charge.

OK, so I concede that I might be simply dealing with semantics or I may be taking the word “Broker” too literally, but I prefer to view it this way because it is easier for me to mentally relate to something I have experienced and I am familiar with (Concierge), versus something I have never experienced (Broker).

In addition, I think we are a VERY long way from their being something that even comes close to being able to called a viable “Brokering” service. Cross-cloud management and governance tools such as enStratus & Rightscale are fantastic at what they do. SpotCloud was (is) a brilliant idea but way too early to market to grab widespread adoption today (hello, Zimory?).

None of these solutions, in my opinion, meet the magical definitions set forth above. Sure, they may be used as part of a toolset, but they don’t cover the full spectrum of cloud services, from IaaS to SaaS – nobody does (except the usual suspects who’d sell your Grandmother for a recurring yearly Cloudwash fee).

As NIST states in the opening paragraph of their Cloud Broker description:

As cloud computing evolves, the integration of cloud services can be too complex for cloud consumers to manage.

I would apply the same logic to their definitions….

Earlier this week, I was asked to present at the Silicon Valley Forum SIG event entitled “OpenStack – How Big Can This Get?”, which brought together some of the leading lights from the OpenStack community and helped deliver a very focused session, providing the packed and attentive audience with an incredibly honest assessment of the journey so far. The event was neatly summarized here.

Participating in these sessions, while educating genuinely interested people who are there to learn, is something I find incredibly rewarding, personally. Sharing the stage with luminaries such as Cisco’s Rick Clark & James Urquhart, Rackspace’s Vish Ishaya, Piston’s Josh McKenty and Cloudscaling’s Joe Arnold is, quite simply, always a pleasure and frankly, today’s dull and overly cloud-washed world needs more events with more people like this on the stage.

Between them, they possess some serious smarts, coupled with an unbridled passion for what they do. It’s abundantly clear that these guys, along with some of my Citrix buddies, including Ewan Mellor of course, are absolutely responsible for the huge traction OpenStack has obtained. And, despite it’s admitted shortcomings (some of which were laid bare in front of the audience) it’s hard to argue that the worldwide interest it has generated over the last 12 months has been nothing short of staggering.

Today, to me, the word disruptive is a much overused term when describing cloud-related technology trends or, in some cases, new products or services that are probably better defined as innovative rather than truly disruptive. In the case of OpenStack, however, I wonder if we are looking at the potential troublemaker; an unruly Native American upstart with the self-proclaimed ambition of becoming “the Apache of Cloud”. Now that’s fighting talk.

In Clayton Christensen’s much-heralded book The Innovator’s Dilemma, he summarizes the theory, thus:

Generally, disruptive innovations were technologically straightforward, consisting of off-the-shelf components put together in a product architecture that was often simpler than prior approaches. They offered less of what customers in established markets wanted and so could rarely be initially employed there. They offered a different package of attributes valued only in emerging markets remote from, and unimportant to, the mainstream.

Returning back to my presentation at the SIG…the objective of the 15-minute slot was to deliver an explanation of Citrix’ relationship with the OpenStack community, a recap of the previous and ongoing contributions to the effort, and a sneak preview on where this aligns with the portfolio, both today and tomorrow.

Given that someone (presumably from product marketing) had long since decided on the Project Olympus name as the working title for the Citrix/OpenStack effort, I couldn’t resist the opportunity to seize another aviation anorak moment and tossed in a couple of a apparently tenuous linkage slides explaining the history of the design effort around the Rolls-Royce Olympus turbojet aircraft engine and how it came to be selected to power the most beautiful thing to ever take to the clouds – Aerospatiale Concorde.

(Note: in my humble opinion, it’s actually a pretty good analogy, but you would have had to be there or see the slide deck to fully understand it…and for the sake of the illustration, forget the small yet significant fact that one Air France Concorde suffered a catastrophic demise and ultimately the entire fleet was retired on safety grounds…)

The more I thought about aviation analogies (and previous readers of my posts will know that they are unashamedly littered with them) mixed with the concepts of truly disruptive technology and the innovator’s dilemma, I remembered an article by Robert Goyer that I read in this month’s Flying magazine entitled “The Chart Is Dead”….

My guess is that the name Capt. Elrey Jeppesen is not a one that will be familiar to many of you, yet he could quite possibly feature in a list of the Top 10 People Who Made My Life Easier Without Me Actually Stopping To Think About It along with better known folks such as Thomas Edison, Frank Whittle, John Logie-Baird, Alexander Graham Bell, Louis Pasteur and Steve Jobs.

Elrey Jeppesen was a pioneer in every sense of the word. He was a pilot in the 1930s and is widely acclaimed as being the first person to provide the then fledgling airline industry with documented navigational charts – which have formed the basis of safer aviation for the last 80 years – and have provided you, and me, with a relatively simple airplane experience each time we fly. He later went on to establish the Jeppesen Company, and as part of their core business, they mapped, printed and sold literally billions of paper charts to serve the global aviation business.

Here’s the twist. In the 18 months or so since Apple launched the disruptive iPad tablet device, today’s Jeppesen Company have been doing something that is all to rare in the IT industry – they have accepted the disruption, embraced the change and, per Goyer’s quote below, have recognized that cannibalization of their existing business is actually a very sensible strategy.

“Jeppesen, a company that for many decades made its living producing and distributing paper charts is at the forefront to do away with them.”

The smart thing here is that Jeppesen have been quick to realize that it is the data and not the presentation that is at the core of their value. Quite brilliant, actually.

So, could we assume that OpenStack might be viewed as the cloud orchestration equivalent of the iPad? It arrived, with swagger, verve and gusto, challenging the big guns to accept it, or to try and out maneuver it by creating their own equivalent. At what point does the cloud orchestration simply be the equivalent of presentation and the real value generated on top of it become the equivalent of data?

Even at barely a year old, OpenStack is being embraced and extended by an interesting range of early adopters, from Rackspace to Dell and Piston to Nebula – if the promise of truly universal cloud computing requires a common underpinning, in the way that Capt. Jeppesen recognized and created the baseline for navigation, then we may be on the right path with OpenStack – but will there be sufficient acceptance to prevent the swathes of “me-too” products that simply serve to allow the huge, established OEM vendors to survive, not thrive, when the market share attack begins?

Well, If all the pilots of all the airlines in the world used different navigation charts, things that happened above the clouds would be a complete and unadulterated mess…wouldn’t they ? They say history doesn’t repeat, but it certainly rhymes.

In the three weeks that have passed since being subsumed into the high-velocity Citrix machine, I’ve been spending a fair amount of time meeting with, and listening to, a broad range of existing and potential customers, both service provider and “enlightened” enterprise, as they work through the planning and delivery phases of their respective cloud strategies.

First, let me qualify “enlightened” enterprise.

I have said many times recently that I believe we now have two very distinct types of enterprise – one is the traditional large corporation (let’s say Bechtel) and one is the new “digital native” enterprise (let’s say Netflix).

An “enlightened” enterprise, for the purposes of this discussion, is a traditional large corporation who actively seeks to emulate some of the constructs of public cloud providers, such as AWS, by architecting and delivering a true private cloud solution (not just server virtualization) to support their business activities and looks to augment those with public cloud services* from one or more service providers.

* These services may be IaaS, PaaS, SaaS or more recently a new variant, DaaS, which I will cover a little later.

I may be stating the obvious when I posit that there is a clear difference between the positioning of the service provider and the enterprise – the former clamoring to enter the growing cloud services market and hunting revenues with new, innovative offerings (and believe me, not everyone is trying to imitate AWS) while the latter aims to find smarter, more efficient ways to deliver solutions or consume services that meet or exceed the growing business demand.

My new role affords me a chance to sit in-between these two very different worlds and offers me a valuable insight into “what people really want and where they might get it”. Even in a relatively short timeframe, I am gaining a sense of this “demand and supply” landscape and using these listening efforts as an opportunity to identify where the likely challenges (let’s not call them roadblocks) may arise in the months ahead.

Unsurprisingly, there are common themes that can be easily observed between the respective “drivers” – Consumerization. Cost. Speed. Agility. Flexibility. Choice – all are words I’ve heard with a heart-warming regularity, but there is one area that comes up time and again, with a little less certainty around the winning formula.

It’s name? Identity.

Clearly, the word Identity alone is enough to strike fear in the heart of most people and covers a multitude of areas, but what is really interesting are the contexts in which it arises, and what is really fascinating are the potential complexities of each contextual discussion. The more I think through this, the more I convinced myself that this area could be one that proves an incredibly tough nut to crack – possibly proving a bigger stick in the wheel of widespread cloud adoption than yesterday’s fears around security, availability and reliability.

Intrigued? Then let’s get to the crux.

In my ideal world, there would be some kind of uber single sign-on what-cha-ma-call-it that made everything so simple to use that I would never have to worry about remembering usernames to login to different applications or having to remember their individual accompanying passwords.

In fact, the entire experience, authentication and authorization, would be so smart that I would not even notice when I switched between application contexts. I wouldn’t care whether I was interacting with web applications, client-server applications, private or public cloud hosted applications and I certainly wouldn’t care whether I was interacting as a user to an application or whether, once authorized to do so, any given application was talking to another application or service on my behalf.

But we don’t live in my ideal world. Yet. Today, we live in a world that is in the throes of a massive transformation.

We (to coin a phrase) are undeniably moving from the PC era to the Cloud era, but as we do so, we continue to stretch the limits of the practicality of mixing old and new technologies, specifically around identity, and my over-arching concern is that the more we are forced to do this, the more difficult it becomes to comprehend, the more mired we become in mind-bending levels of operational complexity and worst of all, we run the risk of the user experience become fatally affected as the digital natives we will serve want to provide their own identities, especially social identities, to further underline their already blurred view of where their work and non-work lives collide.

So, rewind to the pre-cloud days of yesteryear, when by and large, Microsoft ruled the enterprise world…OK, the still do and that’s thanks to the quite brilliant (and free) Active Directory. Although there were a decent set of other enterprise directory services around, AD became extremely pervasive because, above all else, it provided a pretty darn good single sign on experience as long as you were inside the corporate firewall.

Something changed.

Enter the SaaS brigade – Salesforce, Google and their ilk, tempting customers large and small with innovations in delivery and pricing that put complex software in a browser, outside the firewall, in a cloud, and in such an intuitive way that it had no training requirement and no user manual.

Wow. Suddenly the traditional AD didn’t look so comfortable. Gone was my relatively simple world of Windows Integrated Authentication.

Enter the challenge – How do I now create a seamless user experience by providing single sign on from my enterprise to these SaaS applications ?

Of course, like good engineers, we figured it out with some SAML magic – products like Citrix CloudGateway and vmware’s Project Horizon fit the bill very well – but, ultimately, in the same way that Terminal Emulation programs in client-server computing gave us a window back into the past, I can’t help but think this feels like another necessary, but complexity-adding, half-step to the future.

This “inside > out” identity strategy is one I’ve talked about many times. I believe it is important to the user experience, but it really only addresses one set of issues. I don’t hear much discussion about “outside > in”, where an organization is hosting an application (typical DMZ would do just fine here, not a big SaaS player) and wants to authenticate users who already have a social identity, for example? Call it federation, call it Web SSO, call it what you like, but is that too far a leap for mere mortals today?

And that’s just SaaS…consider what happens when we add in other “hosted” services such as the single-tenant version of “Exchange Online” (where providing a seamless user experience for client-server access, requires the instantiation of dedicated networking and Windows trusts for replication) and the advent of DaaS, or Desktops as a Service, which is a relatively new term and certainly something that I am seeing a lot of discussion and interest around.

The initial concept of DaaS will be very appealing to certain sectors of the market, especially the SMB space, but will also come with challenges around identity as it matures and grows towards a set of differentiated offerings – from server-based desktops to VDI – each requiring different variations on an identity theme.

I have no reason to doubt that we, as an industry, will continue to make huge innovations in the identity arena, but for now, I would certainly suggest that as we see these new, unprecedented arrivals of “demand and supply”, my ultimate goals of security, simplicity and a delightful user experience are going to get much more complex before they become much easier.