The Loose Couple's Blog

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.

It’s quite amazing to think and reflect on that fact that I’ve been in the business of helping build big stuff for the best part of 16 years.

When I say building big stuff, it’s not big, shiny new stuff like your Salesforce or your AWS but, y’know, real big, knock-your-socks-off awesome stuff like airports, refineries and power stations – it’s the kind of stuff that you gawk at with sheer amazement on “How Do They Do It”, watching teams of the world’s best engineers and construction workers, choreographed like a Russian ballet, come together to erect some of the most amazing facilities on the face of the planet.

Having been in the midst of it all, I can tell you that it’s nothing but absolutely awe-inspiring, unbelievable, incredible and a whole lot of fun to have worked in as many countries as I have done years.

As I get ready to embark on a new phase of my professional life and leave the world of dust bowls and diggers behind for now, I wanted to do so by finally being able to unveil one or two things about the way we transformed IT in the organization I am so fiercely proud to have served, and to share a little about why I am taking the chance to go in a different direction, one which I hope will ultimately be able to benefit other organizations, irrespective of their business, by focusing on building and delivering some truly world class solutions.

Ready ? Then let’s begin.

Bechtel is, in my humble opinion, one of the most truly amazing companies in the world and without doubt a great place to work. A privately owned, fourth generation run organization, founded in 1898 by Warren A. Bechtel, it has a history, a heritage, a culture and ethics that makes it the envy of the Engineering & Construction business, and, having been part of the organization since 1996, it really isn’t a surprise that 2011 marked the 13th year in a row that Bechtel has been named “Top US Contractor”.

Providing agile IT services to people and locations that are, quite literally, spread across the four corners of the globe to support a complex global business is not a challenge that is unique to Bechtel, nor to the construction industry in general, but the way in which “we” approached this challenge, culminating in the design and deployment of what became an industry-recognized poster-child for private cloud has proven to be an enormous success and is without question the basis of a solid platform from which the execution of future business-aligned IT strategy in Bechtel will be launched.

There is an argument for and against the notion that “great leaders are made, not born”. I am not sure which side of the fence I sit on with that particular hypothesis, but my experience tells me that there are not many people around who could have achieved what Bechtel’s visionary CIO & SVP, Geir Ramleth, did in leading the multi-year IT transformation. Inducted into the CIO Hall of Fame in 2008, Mr Ramleth has given several interviews over the recent years that capture the essence of the need for change and how that change was driven. Below are summaries of those.

• Network World – October 2008 – “The Google-ization of Bechtel“

• CIO Magazine – January 2009 – “Rebuilding“

I consider myself incredibly fortunate to have been given an opportunity to take over the Bechtel IT Global Systems Engineering Team back in 2006, culminating in my relocation to the USA in January of 2007. By virtue of that role, I became a part of the small core team that was hand-picked and tasked with defining and leading the new direction and making the vision a reality.

If I were asked to summarize the experience over the last 5 years, I would point to this quote from the CIO magazine article above:

Ramleth identifies three ways employees respond to change. “You have some people that just take you on blind faith and say, ‘This makes sense, let’s figure out how to do this,’” he says. Next, “there are some early followers who say, ‘I would like to be there, but tell me that I am not going to get hurt.’ They don’t need too much convincing.” In the third group “are the people who become part of the problem rather than part of the solution.”

The key to winning over the staff is to look for individuals in the latter group whom you can convert from pointing out everything that’s wrong with the new plan to helping you figure out what has to change to make it right. Notes Ramleth: “I often say to people, ‘I don’t know of anybody that embraced change that ever got hurt by it. Most people that embrace change benefit from it.’”

I have written previously about the “softer skills” I believe are needed to pull off such a major transformation without leaving blood on the floor and bodies in the corridor – ultimately, to succeed, one needs the kind of senior leadership support offered by Mr Ramleth, both as “boss” and “mentor” but then there must be a solid group of people who will operate on “blind faith” – that’s how the hard stuff gets done and I’d like to think I was firmly in that camp from day one.

So…if everything is so rosy in the garden, why would I possibly want to leave and go seeking a new challenge ? Fair question. Let me have a crack at it, in no particular order.

First, despite the fantastic things I have worked on and achieved, the fact remains that, like many other folks, “we” a hugely talented IT department supporting a business. The business is not IT, nor will it ever be. That alone comes with a set of constraints that are obvious – deliver and support what the business needs – driving too much change is hard.  Really hard.

Second, we are, I believe, at a very exciting time in the always-cyclical nature of the IT industry as a whole. There is a great coming together of the “promise and delivery” of cloud technologies that, based on my experience, will be absolutely game-changing for businesses if they are understood, assessed and applied with a clear business focus and a workable execution plan. Who wouldn’t want the opportunity to be part of helping define how that shakes out across a myriad of customers ?

Third, as you all know, I have been a passionate and sometimes (too) vocal a proponent of open standards, open source and private clouds. I firmly believe that there are many “traditional” enterprises (no, not like Netflix and no, I’m not going there again) who are truthfully only just getting to grips with what virtualization can do for them (P2V and ratios and all that jazz) but aren’t yet far enough along to realize that this is simply a cornerstone of their cloud strategy – the real benefits come as virtualization becomes embedded and organizations look for “what’s next?” in terms of automation, orchestration, advanced security and portability….all as a platform for what is really coming down the line – mobility and information value. It’s a challenge, sure, but it’s a heck of a good one.

I am not a particularly complex person, but I am absolutely driven by a professional curiosity that consistently challenges status-quo thinking, in which will I not accept that an unproven statement such as “it’s fine the way it is” is a valid answer and certainly not a realistic go-forward strategy.  My overall passion for technology is equally for how that technology is packaged, implemented, delivered and its valued derived by a business as much as how the core technology itself is created.

It didn’t take me a great deal of anxious introspection or deep soul searching for me to admit my myself that I have some bits missing from my proverbial canvas. If everyone is honest with themselves, they will see and feel gaps some too. There recently came I point where putting all the above into context, I figured that I couldn’t learn what I needed to learn, I realized I couldn’t scratch my itch and I conceded that to get the experience I need and make the difference I want to make, so it felt like a good time to move on.

That’s why I’m delighted to announce that I am joining the guys at cloud.com as the Vice President of Enterprise Solutions.

Now, this announcement isn’t exactly a bolt from the blue as I’ve known the guys there since the halcyon days of “VMOps” (their original name) and, in my now previous role, they had always been a fantastic company to partner with – great leadership, highly talented technical people but above all, a fantastic attitude to working with organizations big and small to understand and deliver the promise of their product. In fact, I’ve seen that flagship “CloudStack” product grow up from what was a pre-release Alpha, shoe-horned into the engineering lab into a slick, flexible product that is a core building block in powering some of the biggest and most successful clouds out there today.

I am thrilled that the guys at cloud.com feel my experience will be a natural and positive addition to their team and I am looking forward to getting going, being involved across the board, learning new skills, gaining new experiences and above all, committing to helping other organizations (I guess I call them customers now ?) to be successful in the design and delivery of their IT transformation programs by ensuring that they extend beyond virtualization to where the real benefits lie, now and in the future.

Above all, I believe that technology must be simple – simple to acquire, install, operate, upgrade and replace. As Arthur C Clarke said..”Any sufficiently advanced technology is indistinguishable from magic” – I feel that must be true of any creator, or deployer of, that same technology.

On a final note, I would like to extend a sincere debt of gratitude to all the amazingly talented people at Bechtel, especially those that I have had the pleasure to lead and influence over the last 5 years. There is a wealth of incredible knowledge and skill there and a simply great leader at the helm.

Thank you one and all.

At the recent Gluecon event in Colorado, I was fortunate enough to run into my friend Sam Ramji from Apigee and took the opportunity to grab some time with him after he had delivered his excellent panel presentation which was intriguingly entitled “Globalization, Black Swans, and APIs”.

It’s always great to bounce ideas and share strategies with someone who is so deeply involved with the “API Business” as it not only helps solidify one’s own architectural track but provides a reassuring affirmation that even for organizations and traditional enterprises who do not base their primary business on an API (like, say, Netflix – but don’t worry, I’m not going to beat that one to death) there is a huge amount of future potential to selectively use APIs as a powerful weapon against “locked in” data as part of a wider strategy to deal with the burgeoning trend of consumerization.

I’ve seen this comment…

Big Data is getting bigger, with some estimates suggesting that 90 percent of all data ever created was created in the last two years alone.

…appear in a few different guises recently (it was certainly a key theme at Structure Big Data back in March 2011) and although I have yet to find any compelling research to back up the claim, I have no reason to doubt the general suggestion. What I would doubt, however, is that the words “Big Data” are as close to the lips of most enterprise CIOs today – I think the words “Monolithic Systems” are far more likely to be the challenge – especially as it relates to the general malaise caused by the abject inability to access the vast swathes of data outside of the application (or system) in which it was created.

There is another phenomenon, Data Gravity, a quite brilliant term coined by another friend and Clouderati member, Dave McCrory, that I believe will further drive the need for enterprises to consider these disparate masses of data accumulated in years and years worth of incumbent systems as both a problem and an amazing opportunity.

In his original blog post, McCrory posits this, by way of scene setter:

Consider Data as if it were a Planet or other object with sufficient mass.  As Data accumulates (builds mass) there is a greater likelihood that additional Services and Applications will be attracted to this data. This is the same effect Gravity has on objects around a planet.

If one accepts, for the context of this post, the “Data” to be the monolithic systems described above, then it is fairly simple to assume that the Services and Applications drawn toward this mass will benefit by doing so via a standard method – as far as that is possible – and that’s where we circle back to the concept of delivering an enabling set of APIs to act as a interoperability layer between the existing data sources and the new breed of services and applications, which, of course, could easily include cross-platform native or HTML5 apps for mobile.

Sounds feasible so far, right ? I think it makes a ton of sense. No enterprise in the world would want the financial, technical or operational burden of re-platforming an entire metric ass-load of legacy crapplications, would they ? What could possibly cause a secure, solid API architectural approach to falter ?

A new breed of roadblock. The Data Hugger.

A few years ago, as server virtualization reached maturity (readiness) and organizations began to see the empirical value of data center consolidation efforts, the term “server hugger*” became synonymous with those who often refused to acknowledge the value in the virtualization technology, and (as Allan Leinwand stated), felt the emotional well-being and efficient operation of their servers requires them to be physically close at all times.

The Data Hugger is a slightly different beast.

First, he is not in the business of infrastructure. He is in the business of the business. He doesn’t share the unrequited love of beige boxes and synchronized flickering LEDs in RAID arrays as his odd  cousin, but he is equally as dangerous an inhibitor of progress as he puts a mental ring of steel around his data, believing that he is the guardian of the most precious, sacred, valuable and sought after information in the universe and he doesn’t trust his baby to anything except the application that was written to access it. He can not be swayed by IT, suffering from the dreaded “Not Invented Here” syndrome and taking a leaf out of the 20-plus-year-ago mentality of the machine room, when hardware was centralized and horrendously expensive, and only those with the keys to the kingdom had authority over what could be done.

In truth, the mortal danger is that the Data Hugger’s self-imposed sovereignty over their individual data materially affects the true value of the sum of the parts.

To paraphrase a quote from Larry Wall, creator of the Perl programming language, “Information doesn’t want to be free, Information wants to be valuable” – this is an opportunity to derive incredible value and one you don’t want to miss.

Get ready to fight the good fight against Data Huggers, people.

* Additional reading – Mark Thiele of ServiceMesh wrote a great post on the topic of “Ownership Disease”

Footnote : Dave McCrory followed up his initial blog with a later post entitled “Defying Data Gravity”

As I write this latest post, I’m somewhere over the US, cruising at 35,000 feet and hastily making vapor trails toward attendance at my first Gluecon event in Broomfield, Colorado.

And you know what, I’m pretty excited too.

Not only has Gluecon got a great lineup for 2011 and a promise of being an excellent event thanks to the organization skills of @defrag and the quality of the attendees (including many of my esteemed members of the Clouderati) but for me personally, it signifies another interesting shift in my daily focus – away from the murky underbelly of bare metal, speeds, feeds, virtualization, automation – hell, even away from all *aaS in general – and to a place where I never thought a classically trained infrastructure guy ¹ would operate.

1 – That’s where I spent most of my career, growing up.

This week, my new world is that of the API – touted by many as an important part of the fabric of the next wave of internet innovation – and in the same way that one experiences the immediate delight upon landing at a foreign airport for the first time, it feels good, yet quite strange to be here.

I’ve written before about my assertion that to make fundamental changes in technology adoption to support new business paradigms, organizations must equip themselves with change agents, employees who ooze a professional curiosity from every pore and possess a hedonistic attitude to want to render their current skillset effectively redundant, all in the name of progress.

Well, what do you know? Here I am walking the talk and looking for yet more change.

In a recent post entitled “If You’re API And You Know It” I posited my initial thoughts of how a well planned and well executed API strategy might be a trick that is being overlooked by traditional enterprises as they embark upon their individual cloud strategy. The always engaging Lori McVittie recently sounded out her thoughts around performance metrics of APIs and her post sparked me back into life – I’d been contemplating writing this one for a few weeks.

I’m lucky to be able to talk to a lot of different companies about their plans for future IT environments. Unsurprisingly, many of those large enterprises that I talk today are at various stages of their next generation IT planning efforts, wrestling with a myriad of choices from virtualization to automation and private cloud to SaaS.

I don’t envy them, having been there and got the scars to prove it, but most interestingly, I hear many of them talking about “clouds” of one form or another but I don’t hear many of them talking about “what happens when my applications are cloudified?” and specifically, not many at all are talking about how they will enable the information from the traditional, hugely complex, monolithic application stacks or even from newer applications which have been architected for cloud to be put the hands of increasingly savvy and impatient users who will drive that demand from a growing number of different, yet always connected mobile devices.

Are enterprises truly gearing up for how they will deal with meeting the demand that will inevitably come from the burgeoning consumerization phenomenon?

My somewhat educated guess, today, is “no”.

Could it be then, that an API strategy such as I previously hypothesized may serve as an enabler of a new, agile and information driven business in which APIs can be used to expose functionality and content while providing the basis for new, lightweight applications to be written quickly and simply in either native languages or HTML5 for almost any mobile device?

Probably. Now I’m in full Gluecon mode.

It’s a safe bet to suggest that most enterprises have had at least some kind of mobile strategy, for the last 10 years or more, pretty much ever since RIM burst on to the scene and enabled the first widely adopted mobile email and application platform. However, that approach was certainly pre-consumerization, very much modeled in the Draconian style of “IT defines the policy, secures the whole environment, makes no distinction between corporate and personal data and in most cases owns the device”.

Many traditional MDM (Mobile Device Management) tools have, in my opinion, taken an “all or nothing” approach, reflective of the “command and control” mentality of restrictive IT departments, hell bent on throwing a containerized ring of steel around the device, the applications and the data all in the name of compliance, risk management or some other coat peg to hang the blanket strategy on, the more restrictive the better and whatever it takes to make the CIO feel comfortable.

I believe this model is not sustainable. It’s in need of a serious re-think.

As consumerization takes a vice-like hold and user demand grows exponentially, the proliferation of devices will come fast and without warning. These devices won’t always be corporately issued, standardized or controlled and the applications and data that reside on them won’t always be third party delivered by external marketplaces – in fact, a growing number will be applications (enabled in some cases by your API strategy) that you write, you deploy, you manage, you choose the appropriate levels of security for and more amazingly, you provide the storefront for.

Now we come to an interesting space. The Enterprise Mobile App Store. Or lack thereof.

To highlight the gap between consumer and enterprise, and the challenge of providing your very own enterprise mobile app store, let’s consider the consumer experience of Apple’s App Store versus what the very same company provides in the way of anything at all useful for enterprises to use as an equivalent. See? Unless I want to go through the pain of getting my application into the official Apple App Store, I’m pretty much limited to an essentially worthless Over-The-Air capability that, in and of itself, masks the horrid complexity and tedium of the mechanisms forced on enterprises by Apple relating to their Developer Program and the ludicrous Enterprise Provisioning Profile fan dance that must accompany every iOS application that you wish to distribute internally (even if you could do so with any finesse).

I’m not fruit bashing deliberately, but I’ve long held a suspicion that Apple really doesn’t care about enterprises and in fact, does just enough in the enterprise space so that they don’t suffer total organ rejection.

This problem isn’t unique to Apple, however. With slightly less effort, I could probably create an Android application and get it on to a Marketplace of one kind or another. Not trivial but not too hard. I’m not so sure about Windows Phone 7 apps or RIM apps or whatever mechanism will come with the advent of WebOS apps, but I’m still perplexed by a couple of burning questions.

Why would it be pre-supposed that I actually want to put my internal applications, specific to my business, on an external app store – can I not provide a enterprise mobile app store to manage entitlement and access to cross-platform, native or HTML5 applications with a combination of  Mobile Device and Mobile Application Management driven by flexible and adaptable security policies to support the next generation of mobility in the enterprise?

The reality, per the graphic below, is that it is likely that enterprises will need to consider a strategy to deal with MDM and MAM for at least 5 major platforms by 2012 – I would add the capability to provide a cohesive enterprise mobile app store that emulates a consumer-like experience and simplicity is undoubtedly going to be a major factor in any successful go-forward mobile strategy.

(graphic courtesy Ojas Rege of MobileIron – thanks dude – click to enlarge)

There are a couple of startups that are doing some very interesting things in the enterprise mobile app store-meets-MDM and MAM space (and although I am not at liberty to name them a brief Google search may yield good results) and although each of them are initially focusing on the iOS and Android platforms, it is a very young market but one that if my positive vibes about Gluecon and the potential velocity around APIs for the enterprise are confirmed, could be a very hot one in the coming months.

As I board the plane to head to Las Vegas for 2011′s Interop and Enterprise Cloud Summit, predictably, yet somewhat rhetorically, the great AWS outage post mortem continues to rumble on.

Exactly two weeks after the event, blog after blog and article after article continues to serve up a veritable range of delights from the easily digestible to the downright unpalatable, each doing its best to provide levels of interpretation and added commentary on AWS’ frankly excellent and honest explanation of what really happened on April 21. Quite why, I am not sure.

Here’s the good news. I’m not going to add anything to the debate. As far as I (and a number of others I’ve spoken to on the topic) are concerned, it’s water under the bridge, a closed chapter, time to move on…..and for those affected by it, once they learn to love their provider again, I am sure they will be much wiser and better prepared for a recurrence, should there be one (and there likely will), by having understood the parameters in which their application or service is operating and if deemed necessary, designing to address the potential of such a failure.

In the fortnight (yes, fortnight – please excuse my Britishness) since the outage, I have had a number of interesting conversations with a range of folks across the industry on what the potential effect, or otherwise, the outage may have on the speed of traditional enterprises adopting public cloud services and indeed, whether this kind of outage serves to strengthen the case for private cloud adoption in those same enterprises. The conversations have hinted at the prospect of a shift, perhaps, signaling a movement away from “security” to “reliability” as the principle barrier to entry. Could it be more FUD or could it be a true reflection of the general feeling at the CIO level ?

Interesting question, but again, in my opinion, largely a rhetorical one and certainly not a question that is easily answered. What it does do, however, is  serve to underline that despite the tremendous buzz around “cloud” and the undeniable success stories of those organizations who have embraced public cloud and been hugely successful, we are at such an incredibly early stage in this massive shift that I believe as a true enterprise proposition, no denomination of cloud has reached sufficient levels of maturity and understanding to be a strategy that more than just a handful of CIOs will feel comfortable signing off on.

Dice or no dice ? You decide.

One truly surprising undertone that comes up time and time again in these conversations is the presupposition that one day, all enterprises will operate exclusively on public cloud infrastructures, platforms and software delivery mechanisms (IaaS, PaaS, SaaS) and that any private cloud effort is merely a stepping stone. If I had a crystal ball, I would almost certainly be looking for next week’s lottery numbers and not prediciting cloud futures, but I have to say that even if an eventual only-public-cloud-deployment became the norm, the tail until the very last enterprise crapplication (TM) is re-architected, abandoned, retired or otherwise eradicated from the “on premise” data center will be so long, that it could almost be comparable to that of the Halley’s Comet *

* geek fact – Halley’s Comet is approximately 24 million miles long. See what I did there ?

So, that, in a rather labored way, brings me to the point of this post. Private Cloud. The great undead Private Cloud. Yep,  here we go again.

If I were an enterprise CIO today, I would be basking in the sound advice of my good friend Chris Hoff – I’ve quoted this before and I will quote it again, today and in the future:

Use the right tool for the right job and the right time and the right cost

I have absolutely no doubt that given the incumbent complexities, legacy application architectures, existing sunk investment and cautious risk aversion that Private Cloud will play a part, sometime and someplace in enterprise technology strategy. It has, without any doubt worked brilliantly for us (despite the incorrect conclusion others have jumped to) and if planned and executed with diligence and commitment, will certainly work for others.

I don’t usually “do” Top 10′s as I find them to be largely pointless – too high level and not prescriptive enough to have any value – but for once, I will break with that tradition and provide my simple ten most important reasons why it just might make sense to consider a Private Cloud deployment.

• Improve deployment time metrics for existing applications individual servers or combinations of servers as full application workloads in a single data center or across multiple geographically dispersed data centers by automating many of today’s manual end-to-end deployment processes
• Remove the IT function from the critical path of service delivery by empowering self-service functionality for business users to decide when to deploy their applications and allowing visibility into the cost of the components that comprise the LoB application (note: I never said “chargeback” but that could be applicable in certain businesses)
• Reduce human error rate, complexity and variability by using application or server templates within the private cloud automation and orchestration platform to ensure consistency with each new application deployment
• Retain visibility into physical (and logical) resource allocation and line of business usage of those resources with comprehensive monitoring, measurement and reporting
• Eliminate vendor lock-in by choosing Private Cloud automation solutions that are open source and support mutiple hypervisor technologies
• Automate previously labor intensive tasks such as server builds and application configurations, enabling the IT organizations to free up human resources to work on tasks with more business value-add (differentiators)
• Use Private Cloud to leverage and extend existing investments in virtualized infrastructures that are today simply providing better levels of utilization than traditional physical server deployments
• Use Public Cloud “pay as you use” paradigms to help drive flexible commercial discussions with traditional enterprise software vendors as you build the Private Cloud environment
• Free up committed opex or planned capex funding (not necessarily cost savings) by consolidating numbers of physical locations, standardizing on a common infrastructure platform, streamlining operations and allowing redirected funds to be used for opportunities to drive innovation
• Don’t think of Private Cloud as just “compute, storage and bandwidth”, think of how to consolidate, streamline and better provide any IT service as if your IT organization was a multi-faceted service provider, with your users (and business) as your customers.

Of course, I am not ruling out Public Cloud, why would I ? The above is simply based on my experience and assessment of where some other large organizations that I talk to are at in their thinking. I couldn’t end a post without making the point that it is not only completely possible, but already proven that a full-scale move to Public Cloud is, in fact, a winning strategy for those who’s business lends itself.

Wondering how ? Then check out this slide deck from Adrian Cockcroft, my friend and sparring partner on the other side of the fence. In it, he provides some excellent insight in how Netflix have become the poster child for bold Public Cloud adoption – Fortes fortuna adiuvat – in his case, for sure.

And there you have it. A post that raises some interesting questions and deliberately answers none. We all seek the “right” information as we try to quench our insatiable desire for knowledge to be better predictors of the landscape. Well, I’m not a betting man but I’d happily double down on the odds that more than one person this week is going to ask the question of public versus private here at Interop……

Stay thirsty, my friends.