The Loose Couple's Blog

Choices, as the old British adage goes, are rather like buses – you wait patiently for one to arrive and then, annoyingly, several of them arrive at once.

So true is this, that in my continued observation of our beloved tech industry, it appears to be the present day case for enterprises feeling their way around “strategic choices” for things such as cloud management software, smartphones, phablets (what?), software defined networks, API gateways and, perhaps more concerningly, the topic of today’s blog – mobile platforms.

As some of you may already know (and may have seen from a recent video showcase) mobile applications have played a significant role in the advancement of our products & services to support the work we do around the world, but, somewhat akin to our defunct and ultimately rhetorical public vs private cloud debate, I see a lot of enterprises (us included) approaching the new question of native vs mobile web with the same amount of confusion and tumult.

Well, as engineers, we love a good crisis, don’t we?

To understand where we’re going with this new debate, it’s probably worth understanding where we’ve been. At the peak of the great public vs private deliberation, I postulated via this blog post that most enterprises are stuck in a juxtaposition of wanting to move to public cloud but being prevented in doing so by a combination of existing application architectures and a lack of investment opportunity to “throw the whole smash away and start over”.

The reality of running two parallel cost streams (managing legacy version and developing new version) is pretty daunting and in many cases, is tantamount to an impossible sell to the internal bean counters and purse string holders. Period.

You may well be asking – what’s that got to do with mobile? Here goes. For enterprises looking to extend the useful life of today’s enterprise legacy applications (irrespective of whether they ended up private or public clouded), mobile offers a pretty compelling lifeline.

It does so via the concept of an “Enterprise API Strategy” where existing data sources are “tapped” for their rich content, with corresponding business logic and authn/authz honored as part of the magic, and surfaces such content in RESTful ways to be consumed by systems (M2M) and of course, by people, via mobile devices, including smartphones, tablets and…umm…ok…PHABLETS.

Although this may sound simple, let me provide a soupçon of harsh reality – a caveat emptor – if you please. In many cases, it feels like the expression of “putting lipstick on a pig” (1) ought to have its etymology firmly rooted in the results of the War of Irritation of trying to expose functionality or content of crapplications via RESTful APIs, where GET is your closest ally and PUT is your worst enemy.

(1) To put “lipstick on a pig” is a rhetorical expression, used to convey the message that making superficial or cosmetic changes is a futile attempt to disguise the true nature of a product.

Acknowledging that the results of the Enterprise API Strategy are worth the scars of battle places the Enterprise in a very powerful position and your APIs become a very useful currency indeed.

Onward then, to the crux of the today’s challenge, and, with that, the drawing of yet another parallel.

It’s often said that history doesn’t repeat, but it certainly rhymes. How to take advantage of a paradigm shift without attracting duplicate cost or effort? But this time it’s about which mobile platform to develop applications against, not just which flavor of cloud to deploy applications upon.

I struggle to believe there is an enterprise in the world that can make a serious financial / RoI case for developing mobile applications that have individual code bases to support the Big 4 platforms – iOS, Android, Blackberry & Microsoft.

I also do not subscribe to the notion that one can go “all in” on one platform over another, including a strategy based solely on mobile web (HTML5), especially if that enterprise plans to make those applications available to BYOD users (yeah, let’s grasp that nettle shall we?) or other external parties in their ecosystem or supply chain.

The real punch-line is in the rhyming of history. Two years ago, Adrian Cockcroft, Chris Hoff, Simon Wardley and I had pretty much the same discussion albeit on a different topic. The advice at the end of that is as sage now as it was then – understand what it is you’re trying to do, be clear on your objectives and use the right tool for the right job at the right time and the right cost.

The native vs mobile web conundrum is a burgeoning one and is, I believe, on the minds of Enterprise CIO’s everywhere. I’ve read a lot of expert opinion recently, telling me exactly the things I should think about and the steps I should take to arrive at the decision of whether to build native or mobile web, most of which is subjective and insipid, yet I have heard wisdom beyond comprehension from our own guys in the trenches ……“the API is the asset, the UI is simply throwaway”.

Wonderful. Just let that sink in for a moment or two.

I’ve long since given up the perennial quest of predicting “what this year will bring”, skillfully leaving this particular exercise in bland rhetoric to those bold enough to want to suggest whether 2013, 2014, 2015 or 2021 will indeed finally prove be the year of VDI, Linux on the Desktop or herald the arrival of other such recondite concepts like Hypervisors-on-Smartphones (TM).

Instead, for this first post of MMXIII, I’ve opted to provide a single further interested observation from my daily vantage point, betwixt and between the past, present and future of Enterprise IT. Consider it, if you will, a post that delivers a semi-hypothetical “what might happen next”, assuming that you are sufficiently far enough advanced in your journey of change to have put the moribund discussions of “what is cloud, is it secure, should I choose public v private and what’s the difference between IaaS, PaaS and SaaS” behind you and focused on the important tasks of addressing the needs of your business.

The assumption that an enterprise has navigated the first waypoints along the journey of change is broad, yet required for a realistic appreciation of this post. It doesn’t require any technical expertise (thankfully – who needs another software-defined-meh discussion?) but it does require at least an acknowledgement that consumerization is, and will continue to be, a major force in how Enterprise IT shapes itself for an exciting future and, perhaps more importantly, is a willingness to accept that that very same Enterprise IT has already lost control and succumbed to a wave of change that makes it futile to try to put the proverbial genie back in the bottle.

I’ll follow up the last sentence’s revelation with a suggestion that Enterprise IT has progressively been losing control for the last 10 years or so, but, to borrow a well-worn adage, this time, it’s different.

I’ve been around large Enterprise IT environments for more years than I care to remember. I’ve driven change, I’ve seen reluctance to change, I’ve seen new technology come in, I’ve seen old technology stay in, but one thing that I have witnessed that has remained constant is the incredible ability of end-users to circumvent the ball-and-chain approach of many Enterprise IT shops and find their own “innovations” that, first and foremost, enabled them to be more effective in their daily work. Many of these innovations came in the form of snippets of software, or micro-applications, usually created through a combination of necessity, whatever was available on their desktops and sheer bloody-mindedness.

Where I come from, they call it Skunk Works.

The original Skunk Works has it’s genesis deep within the bowels of Lockheed Martin’s Advanced Development Programs of the mid 20th Century and spewed out some pretty incredible hardware, including the U-2 and the SR-71, among other things (many of which you really wouldn’t want to wake up to flying over your house), but, according to Wikipedia, the term has become generalized over the years:

The designation Skunk Works is widely used in business, engineering, and technical fields to describe a group within an organization given a high degree of autonomy and unhampered by bureaucracy, tasked with working on advanced or secret projects.

In the case of the end-user circumvention described above, it’s the reference to being “unhampered by bureaucracy” that most resonates. There must be a million stories and demonstrable use cases of end-users bypassing the applications they are told to use, abandoning them in favor of a “little MS Access database that I wrote” which fits their work process well enough to get the right results, on the end-user’s terms. The same must be true for “complex Excel spreadsheets we created, with pivot tables, charting and reporting” all created because the end-user was empowered, the tools were relatively simple and the results were equal to, if not better than, those from the cumbersome, complex applications that were foisted upon the end-user.

The smarter reader will already be about to arm-wave furiously and say “yes, yes, we’re also seeing this in the way anyone with a credit card can go out and sign up for SaaS. In fact, we, yes, us, have already “found out” that <gasp> people are actually doing this in our company.” Welcome back to 2009.

That’s all great, but perhaps unsurprisingly, given my recent focus in our business (discussed in this Cloudcast “API” session with yours truly and the erstwhile Sam Ramji), it’s where this same concept goes when we focus on the explosion in mobility, yes, that elusive Post-PC Era, that piques my immediate interest – and hopefully yours too.

Arguably, APIs in the Enterprise context help democratize data. They are the key to unlocking information, but what they don’t do is democratize that information. Today (depending on your position in the journey of change) that’s the job of a new swathe of developers, creating slick and sexy mobile UIs – native or web – for the provision of information and updating of data. Tomorrow, I suggest, there will be a shift toward the empowerment of end-users, providing a mechanism for the self-same approach to “giving me what I want versus what you tell me I need” but with a strategic, unprecedented welcome.

BYOA will mean Build Your Own Applications. That’s powerful stuff. Funny how history doesn’t repeat, but it definitely rhymes.

There are a number of subtle, yet key differences in our Skunk Works of today versus that of tomorrow. Yesterday’s efforts were powered, almost exclusively, by Microsoft Office applications on the desktop. On-ramps were relatively small and technical barrier-to-entry low. Tomorrow’s efforts will come in a myriad of shapes and sizes, and on across a plethora of mobile device platforms – iOS, Android, WP8, Ubuntu…and whatever comes next, but today, the technical barrier to entry is relatively large and barrier-to-entry high.

To a large extent, leveraging the true power of an Enterprise API today in the form of an app for a mobile device requires the skills of a developer. Not many of the end-users that are able to create MS Access databases for their own purposes have the required skills to code HTML5, Xcode or Java and are not familiar with how to interpret a JSON payload.

As we’ve seen time and again, the complexity of any sufficiently new technology paradigms eventually becomes obfuscated by simplification. In turn, user friendliness grows and ultimately drives adoption. We’ve seen this in many cloud IaaS services (remember ElasticFox?) and in the emergence of MBaaS (Mobile Backend as a Service).

We’re also beginning to see the shoots of this in my newly defined “BYOA” space with services such as Tiggzi – which is providing a very slick drag and drop interface, with pre-built REST connectors / plug-ins that allow connectivity back to Enterprise APIs. One of the real benefits of an approach like this is that not only are the end-users ultimately empowered, but they are able to use the APIs to effectively guarantee that their “home built” application is connected to the latest data from the underlying source – something that further works to assure the quality of the results. Tie that to the capability to track application and API usage (we’ll leave “Information Accounting” for another post) and the landscape looks pretty exciting.

Are we there yet? No, of course not. There continue to be challenges around application deployments, provisioning profiles, all kinds of things that would be alien to even the smartest end-users, but my hypothesis is that these will be addressed in the not-so-distant future, providing pretty much all of the toolkit necessary to address the question of “Make An App?” in the diagram below (click to enlarge).

Let’s see if my non-prediction proves to be right.

While not yet having reached the cringe-factor of “cloud”, the term “big data” is certainly becoming much discussed, and, as I’ve done many times with it’s buzzword stable-mate, I find myself asking, “What exactly is it?”

Thankfully, NIST have yet to offer an insipid and face-numbingly trite definition (hooray) but unfortunately, the leading definition of big data is hardly one that will set Enterprise IT minds racing and many CxO’s reaching for their wallets.

In fact, I only have to turn to Wikipedia for my suspicions to be bolstered that we are indeed seeing yet another business-context-less overture that is, unsurprisingly, helping us collectively miss the point.

In information technology, big data is a collection of data sets so large and complex that it becomes difficult to process using on-hand database management tools.

The Technology Purist in me longs to agree entirely with this, but the Business Practitioner in me wants to challenge the positioning and offer up a rather more palatable opinion. I’ve done just that routinely over the last few years, from cloud to mobility; so let’s take a swing at big data, chunk by chunk.

In organizations like mine, and indeed in many other industries, including manufacturing, automotive, pharmaceutical, aerospace – in fact, pretty much anything with a large supply chain – there are two distinct types of data.

Data that is used during the creation of the final product, which at various stages is turned into information, and usually accompanies that final product into its operational lifecycle.

Data that is used during the creation of the final product, which at various stages is turned into information, but once it has been used, it becomes a by-product of the overall creation process.

In organizations with multiple entities or business lines, the data landscape differs significantly based upon a number of factors, usually as a result of the combination of the business itself plus the people, process and technology that support it. However, it has been my recent observation that the hypothetical 3V’s of big data (volume, variety, velocity) is indeed a valid construct for helping map even the most complex data landscape, especially when suffixed with my additional 2V’s (value, variability) that help round out the north and south end of the initial big data trail.

The diagram below is intended to help visualize the representation of The 5V’s of the Data Landscape.

In the context of The 5V’s of the Data Landscape, the definitions of each V may be subtly different than the purists would have us believe, so, for the avoidance of doubt, let’s be sure we are all on the same page.

Volume – The size of the overall data created by the line of business in the course of normal business operations.

Variety – The number of individual systems and / or distinct data types utilized by the line of business in the course of normal business operations.

Velocity – The combined rate and which data flows in and out (internal and external vectors) of the line of business during the course of normal business operations.

Variability – The level to which source data can be unintentionally modified throughout its lifecycle, where non-immutable data affects information quality.

Value – The derived value from the overall data created by the line of business, considering both data types (from earlier definition).

It is the V for Value that I am particularly interested in, especially in the context of applying a real business case for big data, focusing very clearly on the data type that is considered the by-product or waste data. My suspicion is that within the waste, the global exabytes of by-product data, there is a significant amount of rich information waiting to be turned into applied knowledge, helping businesses of all kinds be more efficient and effective in their respective arenas.

Can big data methods and visualizations be applied to bring new levels of understanding and potentially even new revenue opportunities by driving up the Value of “crap” – well, why not – “where there’s muck, there’s brass” as the phrase goes.

(Note: You may have to Google the phrase if you’re not from England).

Over the last few months, we’ve begun to see the emergence of what I’ve called “The Face of Big Data” with companies like Edgespring, Datameer and SensePlatform (among others) who have grasped the concepts of how to bring big data to the masses, through intuitive UIs, and without the need to understand the inherently complex underbelly of Hadoop-style environments.

My view is that this is where the big data war is going to be won. If the “Average Joe” in a line of business can use tools (as easily as he or she can use a search engine or a spreadsheet application) to effortlessly ingest and correlate data and ultimately bring never-before-seen business dimensions, then we are really onto something truly remarkable.

Regular readers will know that no Loose Couple blog entry would be complete without an analogy, so let’s wrap this up with a simple example.

Natural gas that comes from oil wells is typically termed ‘associated gas’. This gas can exist separate from oil in the formation (free gas) or it can be dissolved in the crude oil. For many, many years, oil refineries and other downstream facilities simply used flare stacks to burn off this unwanted by-product of crude oil production.

A few short years ago, the clever folks at GE Jenbacher realized that there was an opportunity to re-use the flare gas and they set about creating a flare gas capture solution that was first installed in Italy in 1998.

Today more than 330 units, with a total electrical output of more than 450MW run on associated petroleum gas worldwide. These plants generate about 3.6 million MWh of electricity a year – enough to supply about 1.2 million European homes. Generating this amount of electrical power with flare gas allows for savings of approximately 900 million liters of diesel fuel per year.

Ain’t that a happy ending?

It usually starts with some ghoulish headline about “big data” and ends in a look toward the heavens, accompanied by a shake of the head and a deep, woeful sigh. The kind of big data they are talking about is not applicable to me, not yet, maybe not ever. It hasn’t reached the point where I can convince even myself that I could explain, at a kindergarten picnic, the difference between a structured and unstructured big data in an enterprise that has been collecting, and storing, “stuff” since before dirt and fire were invented.

And, worse still, It hasn’t had enough true, practical implementations to give me the ammo needed to convince any of the top brass what a “data set too large to be handled by traditional enterprises databases” would have the brass-neck to be doing in the confines of our shiny privately clouded data centers, let alone how throwing such an egregious data set on top of a smorgasbord of open source technologies with names as attractive as Pig and Zookeeper would suddenly reveal the path to true enlightenment.

The kind of big data that I am dreaming of doesn’t live inside Twitter, or Facebook, or enterprise file shares, or corporate email. It doesn’t care how many times the word “Coke” appears within the faceless ramblings of a marketeer’s unknowing congregation. No, the kind of big data I am dreaming of lives in the ceilings or behind the walls, in the air, underground, in every day equipment and (with a huge hat-tip to the venerable Dr Crosby) “the cloud in your pocket”.

Humans are (so writes my good friend Chris Hoff in a superb response to a really great post by Alex Williams) “an intelligently-complex species, and define even heady things like emotional responses as a function of two fundamental neurotransmitters — chemical messengers — the biogenic amines serotonin and dopamine” [sic]. The problem with humans, I believe, is that we are generally extremely inefficient as a species (compared to ants or bees) and, as a result of an eternity of cohabiting on top of this mantle of ultramafic rock that we call home, we have unwillingly allowed these emotional responses to become part of a bias when faced with making many kinds of decisions.

In both the posts referenced above, there are (probably correct) indications made that, over time, “machines will become social” and perhaps begin to form communities of like (excuse the pun) by using similar approaches to the ones we use today in our interactions with friends, family members, colleagues and so forth. Pretty interesting concepts, but, for the sake of my big data dream, I hope that machines never learn to display their emotional side.

Let me try to collate this a little.

I’ve written before about a universally understood metric named wrench time which, in our industry is a critical consideration for the owner/operators of many of the facilities that we build. It is so critical, in fact, that any delays to planned maintenance / outages caused by poor information and / or poor quality of work can realistically end up costing the owner/operators millions of dollars in lost revenue.

As buildings get smarter, the collective intelligence inside them grows exponentially and, as a simple example, the opportunities for “smart maintenance” get bigger and better.

The key to this is sensors. A colossal ad-hoc network of sensors. Yes, millions upon millions of them. They are already at work in many of the airports around the world, gathering vast swathes of information from emissions measurement and environmental compliance to security monitoring and advanced building management (for controlling lighting, power, etc).

Now add to that the hundreds of fixed installations inside any airport that need regular or break-fix maintenance, all with sensors of their own. Add location based services, socially aware machine to machine (cross-system to cross-system) communications, intelligent and proactive component refresh and you have the embryo of my big data dream.

But wait. There’s a problem. We still need humans. Of course we do.

In my vision for smart maintenance, we have to take one step further than our psyche may be programmed to take us. The machines know nothing of emotion. In the ideal world, the capabilities and historical performance of the humans that form part of the maintenance crew are known to the machines. The decisions on who should carry out the work (and of course, the tasks are issued to the worker via a web-socket aware tablet device which also tracks and reports back response times etc) that are based solely on the computed outcome of the combined data that the machines understand and process ahead of every request.

Then, a continual cycle (feedback loop) lets the machines learn, and adjust. They are free to share this information with other machines – they can build their own social environment where other machines are free to take and make decisions based on this information, but only ever based on facts. Pure facts, and always without emotion. Ruthless efficiency. Smart maintenance.

Of course, I would chose an aviation analogy, and not without reason. If you think this post touches a little on the “science fiction”, I can assure you this is very real. I’ve written this post from the point of view of the “back of house”, but what happens to all these sensors and the social interaction of machines when we find ourselves in the “self service airport” – will machines know and judge us by the data collected at the “front of house”?

You might not have to wait too long to find out.

Photo Credit : Peter & Maria Hoey from this WSJ Article on “The Self Service Airport”

Last week, I was fortunate enough to have a “customer success story” published by our friends at Apigee. It’s not something our organization tends to do very often, but in cases like this one, where we feel that there is sufficient industry-relevant and generally interesting content to stir other people’s imaginations, then we give these opportunities great deal of consideration before agreeing to “go public” with what we’re up to as our journey to, above, and beyond the cloud continues – all as a direct result of the insatiable demand from our business.

I received some great feedback on the content. Some people are keen to understand more about why a massive organization would once again turn to the consumer internet leaders (yes, that includes you, Netflix) for inspiration on how to attack specific business challenges differently than ever before (the why), while others are more enticed by the technology applied and how we approached the end to end design and delivery of APIs and mobile applications (the how).

It was, however, a question I received somewhat anonymously that gave me cause to consider what we are working on and whether it is something that can be “pigeon holed” in the current nomenclature of cloud.

The question was pretty simple and seemingly innocuous.

Do you consider what you have done with your API strategy to be “Data Virtualization”?

My initial reaction was “eh?, umm. not really.” – but like all good geeks, I turned to Wikipedia for help to wrap my mind around what Data Virtualization is currently classified as.

Data virtualization describes the process of abstracting disparate systems (databases, applications, file repositories, websites, data services vendors, etc.) through a single data access layer (which may be any of several data access mechanisms).

The more I thought about it (and specifically with Dave McCrory’s recent concept of Data Gravity still rattling around my intercranial space) the more I wondered if perhaps this approach is a new form of data virtualization, employing the API to assist in delivering the required functionality of the mobile UX by abstracting both the subsets of functionality and its corresponding, sometimes aggregated data from the typical silo of it’s complex “parent” application. Hmm.

To help understand our overall approach a little better, I offer the following extract from the success story mentioned above:

In our traditional application deployments, we often assumed that each user might need to understand 100% of how any given application worked and trained them on all functionality, irrespective of their role. Across our overall application portfolio, it became clear that we have two types of “users” – those who create data and those who consume information. In some cases, the percentage distribution of those who consume versus those who create can be as high as 80/20.

Using this new understanding of how our users used their applications, we began to consider how we might fulfill the growing demand by “deconstructing” the incumbent applications and delivering subsets of the application’s functionality across smartphone and tablet devices. This approach included the creation of standardized APIs to provide an alternative access method to the back-end systems and the development of new, intuitive user interfaces (or lightweight applications) that could be delivered, monitored, managed and analyzed via a combination of our Apigee infrastructure and private enterprise app store.

The key to our strategy is that we have very deliberately, and with crystal clear intent, not set out to replicate the entire functionality of the incumbent applications on smartphone / tablet devices. This, I believe, would be a recipe for disaster. We are (initially) concentrating on the information consumers, the people that demand information as and when they need it, as and when it suits them – the APIs and the functionality of the mobile UI reflect this – lightweight, agile, responsive and able to aggregate disparate data sources where necessary. Nobody here has enough time, nor inclination, to want to boil any one of the world’s five oceans – we’re much too schedule driven for that.

While I am largely unconvinced that anything we are doing is beyond the grasp of other enterprises looking toward mobility as a major strategy for 2012 and beyond, I am utterly convinced that if we had not started our cloud efforts back in 2007 (hey, look – another story here) and consolidated-then-cloudified what we had in our global estate, then we would have been in an almost impossible position to layer an efficient API strategy on top. Call it dumb luck, I guess.

Interestingly, the benefit of the API strategy for us has been the capability to unlock our vast swathes of siloed data and turn that into information. This is only truly achievable because that data, despite being tied to monolithic systems, is in a very limited number of physical locations today. It’s in those very same locations that we’ve begun to build these next generation enabling services – each positioned and deployed adjunct to the ever-growing mass of data we own.

Does Data Gravity drive Data Virtualization? It would appear so for us, but, I guess we better let McCrory answer that – after all, it’s his idea – isn’t it?

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.