The Loose Couple's Blog

Sitting on the sidelines observing the recent glut of big acquisitions by even bigger tech companies has been fascinating. It’s not just because we are seeing young companies with lots of promise (but not so much revenue) be gobbled up with ant-eater like precision, but also because we are seeing some of the early pioneers and principle enablers of “this generation” of Information Technology be swallowed up, stripped of name and identity and re-aligned in larger, all-encompassing behemoths, jostling for the lucrative leadership positions in the “next generation” of the Digital Age.

Of course, this isn’t a new phenomenon. In 1992, I worked for a large technology manufacturer and service provider in the UK. They were called ICL.

They were huge….and now, they don’t exist anymore.

ICL was acquired, bailed out, snapped up, whatever, by Fujitsu and forty years of history attached with the brand – and the name – disappeared overnight.

For large organizations, let’s call them the “traditional enterprise”, the safe bet has usually been to buy technology products and services from big vendors, resting assured in the knowledge that the millions of dollars invested in R&D, marketing, sales and support means that you will be getting a quality product that meets, or in some cases, exceeds your needs.

That’s a pretty sound philosophy if you’re willing to juggle the pros of predictability and cons of cost, lock in, forced upgrades, etc etc etc…all of which leaves me wondering if today’s unrelenting dog-eat-dog world of big player acquisitions is actually confounding this problem, making the customer walk the proverbial plank a lot quicker than we may realize.

I’m sure there are many continued supporters of today’s version of the old adage “nobody ever got fired for buying IBM” and that may well hold true across many industries, but in the age of agility, flexibility and much shorter product lifecycles, the winds of change and opportunity are certainly blowing.

These opportunities lie with the start-ups and smaller vendors.

I like to call them “emerging vendors”. I like to think of them in the same way I like to think there are no such thing as strangers, just friends you haven’t met yet. They are open to new models of engagement, which can be broadly classified as partnerships.

Wikipedia describes a partnership thus : A partnership is an arrangement where entities and/or individuals agree to cooperate to advance their interests.

Note that this doesn’t use the word “sell” ? I will come back to that later.

I am lucky enough to wear my large enterprise hat as a forward-thinking architect, but twinned with the responsibility of what we term “strategic sourcing management”. Essentially, this means that I am able to combine the responsibilities of setting technical direction with the selection, management, and commercial term negotiations / agreements with vendor(s) large and small. I am not too sure of many organizations where one person has this same responsibility at a managerial (not CxO) level, but I can see a world, not too far away, where this makes total sense.

If CIOs of tomorrow are to become service aggregators, then the next generation of architects might just be the swiss army knife of technical, business and commercial savvy that plays a key supporting role in future organizational success.

In my recent experience, I have been fortunate enough to create and foster some really exciting partnerships, true partnerships, with some emerging vendors. I can’t name them in this post, but I can say that it has been an absolute pleasure and a breath of fresh air to work alongside some of the smartest folks in the industry to create solutions of real value to our business. These are not necessarily vendors that would have made it onto our radar a few years back, when the landscape and the mentality was different, they just would not have fit that mold, but in today’s world, they have more than a seat at the big table. They are key to our strategy and we treat them as we treat all our strategic vendors – as a part of the team.

What’s in it for them ? They get to work with smart people who can articulate challenges. They get help to understand real world use cases for their technologies. They get an ethical and honest prospect who appreciates their time and remunerates accordingly. They get feedback, open and regular. They get a conduit to other, maybe unknown, vendors in the ecosystem and contextual introductions to bigger vendors who may well be higher up the food chain.

Ultimately, the common goal is that they get a customer and a revenue stream. All off the back of the original partnership, and without the word “sell” ever being mentioned.

What’s in it for us ? We get to work with smart people who understand our challenges. We get to help define features, influence roadmaps and create solutions that plug into our existing environment(s), enabling the speed that is so critical to the IT services we deliver as a business. We get flexibility and choice. We get satisfaction from seeing these guys engaged in discussions with others in our ecosystem.

In the current climate, choice is a big word. I no longer see this as “either, or”, “big versus small” vendor decision – it’s both. It’s a consensus that the one size fits all model is an antiquated approach.  If that isn’t recognized by everyone today, I am convinced it’s only a matter of time.

I am also pretty much convinced that a good proportion of emerging vendors sets their sights on gaining momentum, a customer base, a revenue stream and then either aims to :

a) be acquired

b) IPO

Either one is usually considered a good result,  just how good, depends on the terms of the deal. What is important to me as a customer (or even a prospect) is not the end result, but the other end of that spectrum – finding these guys at the right time, finding the ones who are willing to listen and learn and above all, finding the ones who truly understand the process (and value) of “partnerships” between themselves and large organizations to help provide the solutions that drive our business forward.

Following my presentation entitled “Why A Major International Construction Company Needs Cloud” at the recent OpenStack Design Summit in San Antonio, I’ve been asked a lot of follow up questions on two of the points I made during the talk:

1)   Server virtualization “not being particularly attractive” to enterprise CIOs

2)   Why I think it is important that OpenStack itself (via the core “products”) goes someway to differentiating themselves from other available “IaaS” solutions by “moving up the stack” and addressing the real challenges that I see becoming more prevalent in the enterprise space

My trains of thought seems to have caused some consternation (and / or “meh”) in certain quarters, so I thought I would take this opportunity to clarify my comments and offer a little more in the way of context as I think some people were either:

a)    Not physically there during the presentation and have picked up out of context comments and threads via twitter

b)   Asleep, catatonic or heads-down in their laptops during the presentation and missed the end-to-end story, which is based solely on my experiences of the last few years during the build out of  “our” next-gen global IT platform *

* For the purposes of this post, I won’t name the organization I work for. If you were there, you will know it. Google will also tell you easily enough.

Firstly, let me give a little background. Over the last three and a half years, I have been part of a relatively small team that has architected and deployed a brand-new IT environment for a large multinational organization. This has been done partly by consolidation, partly by changes in operating models, partly by ruthless standardization of the back-end platform and partly through new the adoption of new technologies.  However, all of it was done with strong business alignment – through our constant engagement with the business, we knew that the way we were “doing IT” was not in line with the changing needs of the business and hence we had to innovate – and quickly, with their understanding and buy-in. I would go as far as to say that today’s Enterprise IT can’t effect meaningful change without this kind of alignment.

The new environment is what I lovingly call “the accidental cloud”, simply because our efforts around it were planned for and started long before every single conversation around IT included the words “public, private or hybrid”.

The architecture and deployment started with infrastructure, largely because the IT department owned the budget. The infrastructure included new global network(s), new global data centers (reducing the total from “many” to three), and above all, it included virtualization technology, both for the “servers” and the “applications”. To clarify, by “applications”, I am purely talking about the “client” portion of the many, many client / server applications that we operated, and still operate, as LoB today.

You can think of that application virtualization approach as tactical, it’s a “bridge” from the old to the new. The smarter ones will figure out the underlying technology easily enough. It’s not exactly the moon landing.

So that brings me on to server virtualization and as I mentioned during my presentation, we have over 95% of our production servers (somewhere north of 2500 VMs) running as “virtual servers” today, supporting our application and service portfolio.  Overall, we are very happy with our hypervisor and as with any hypervisor, it has brought some obvious efficiency, but here’s the main problem:

We are highly virtualized BUT NOT highly automated.

There is no doubt, nor will I contend, that virtualization, in any format, but specifically for servers, is a key part of cloud, whichever derivative you like…but…servers run applications. Applications automate business processes. Business processes make organizations money and profit. Profit is what most business is about.

Today’s applications, both in our environment, and I would suggest in many other enterprises like ours, are usually made up of more than one server. There are very few (if any) true LoB applications that are single server, single stack (a la LAMP).  They are a combination of n-tiered client / server or n-tiered web applications that have multiple servers stitched together to make that “workload”. This isn’t so much a legacy as a reality – would we build them the same tomorrow as we did yesterday? Of course not. But the harsh reality is that it would cost a prohibitive amount of money to “cloudify” our 800+ “legacy” applications for a perfect cloud world and we can’t find anyone to bankroll that. Could you in your enterprise?

When our line of business people ask for the application to be made available for a new project or department, they ask for just that – the application – not the ability to have IT spin up individual servers and have them handed over such that they can configure their own pieces to get their application functional. They want the application, and almost always, “need it ASAP”.

Now here’s a somewhat generic problem with ASAP.

• No automation = constant manual intervention.
• Constant manual intervention = greater time to deploy (x more defects)
• Greater time to deploy = lag to the business.
• Lag to the business = potential loss of revenue.
• Potential loss of revenue = frustrated business leaders.
• Frustrated business leaders = pressured CIO.
• Pressured CIO = (well, you know the rest, I’m sure)

In summary, I would strongly contest that the CIO isn’t looking at server virtualization as a panacea, nor does he care too much about the underlying hypervisor technology other than from maybe a price and / or lock-in perspective.

I’ll be willing to bet a few bucks that the CIO is looking at how long it takes to predictably and repeatedly delivery applications to the business (if that means SLA, then so be it). Does the CIO truly get excited about server virtualization alone? You’d be hard pressed for me to say “yes” to that.

Being smarter around how to define, deploy and manage the entire application workload on top of the enabling cloud platform is where I think the wise enterprise architects need to be looking, if they aren’t doing so already.

So, now that clears up my comments around server virtualization, I wanted to clarify my points (and hopes) around OpenStack.

First and foremost, as I have mentioned many times before to some of the key players, I think it is a fantastic opportunity for the OpenStack community to win the race to be recognized as the first true, mature, open and usable platform for both service providers and enterprises who are looking to build or offer cloud services.

By the nature of where the lifecycle of the platform is today, there is some way to go until it is polished, but this is a rough diamond, no doubt about that. The energy around the recent design summit, combined with the commitment of many large tech vendors, suppliers and OEMs is testament to the buzz and I am sure that will grow over the coming months.

As an open platform, there will be “services and support” opportunities (very probably for the likes of Rackspace, Citrix, etc) as well as a rapidly growing eco-system of partners and emerging vendors, keen to offer their niche solutions to “embrace and extend” the OpenStack platform.

I love this eco-system approach, but I strongly believe that if one of these niche areas remains the “application workload opportunity” that I outline above, perhaps OpenStack is missing a vital trick that puts it right up, front and center, against at least more of what, say, vmware can offer today via vApp. The fact is, rightly or wrongly, the typical enterprise is wary of niche vendors.

In my very humble opinion, this is far too important and far too good an opportunity to not be part of the “core” OpenStack thinking.

I’m both excited and nervous, so I will cut to the chase as I round out this post.

Today, I don’t know how I would sell and enterprise CIO on the real value of rushing out and deploying the OpenStack platform. Before I’m shot down, I am fully aware that there are not very many other “cloud” platform vendors who offer the utopia that I am describing, but that is exactly the point – this is a unique opportunity for a open platform (hypervisor and hardware agnostic) to become the central cog in the wheel of enterprise application deployments as they work their way from the past to the future.

I’ve experienced how hard this is without it. All I can do is ask, I suppose.

A few short years ago, whilst still living in England, I changed my cell phone provider. (In fact, we called it mobile phone in England, but I suppose I am becoming Americanized – with a z - so cell will have to do for the purposes of this discussion). “So what ?” My guess is that’s what you’re thinking. If so, then perhaps today’s blog entry isn’t for you. If you don’t want to read on, go and spend a few moments looking at my other passion in life. Manchester City FC.

If you’re still with me, let me explain what this has to do with Cloud Computing. It’s a bit of a strange analogy, so bear with it, though it’s probably not something you haven’t heard of, come up against or at least thought about, however.

The problem wasn’t changing the provider. In fact, that wasn’t a problem at all. The new provider gave me not just the promise of, but a better deal, more bells and whistles, less cost, more free stuff……great, isn’t it ?. That’s what I thought at first.

In all of my new found excitement, I realized that what the new provider didn’t give me was the ability to use the handset that I already had (it was “locked in” to the incumbent carrier) and worst of all, I couldn’t take my number with me (it wasn’t possible to “port” numbers back then). In essence, all the time and effort I had spent to remember and then dish out my number to my network of family, associates and, ahem, special friends was wasted. Gone. Up in smoke. The price I paid for a better deal was a complete rebuild of my personal cellphone hardware and it’s core data (my contacts) from the ground up. A sticky and minefield ridden path of trying to learn a new piece of hardware, trying to export and import settings and then, worst of all, a text message (and associated cost) to all the people I needed to share my new contact details with – all whilst trying to continue to be productive. Seems improbable that an IT dude would struggle with something so simple, but struggle I did.

And. It. Was. Painful.

Thankfully, since then, the cellular telephone industry has grown up to the point where the challenge I faced a few years ago is really no longer a challenge. Cellphones are commodity, numbers are portable, core data can be moved between SD cards and cloud storage with ease. I can move between devices and carriers without too much stress and in a pretty quick time. Above all, I am no longer inconvenienced by the search for a better solution.

To try and draw a technical comparison between cellphones and cloud computing would probably stretch the imagination of most technically-savvy people, so I won’t try. The comparison is more of a philosophy than a technology – it’s more about the (lack of) maturity of the standard, operators, environment and the market as a whole.

From my experience of building and deploying cloud-based services today , I am where I found myself a few years ago holding that new cellphone. There are very few clearly defined and understood mechanisms or methods for seamlessly moving workloads in and out of “cloud” environments that absolutely guarantee that the application workloads do what they’re supposed to do. There are some, of course, that “enable” movement (including Cloudswitch) but to quote Beaker (Chris Hoff) – “this is just the revenge of IPSEC and PKI”. I love that quote. Simply brilliant.

In my ideal world, the movement of component services, irrespective of their layer in the stack (from entire to components of) will absolutely need to be as simple as switching cellphone carrier today. I want to not have to worry about hardware, not have to worry about the incompatibility or inability for me to be able to port a component or a full workload from one “carrier” (provider) to the other – on-premise, private, hybrid, public, whatever. Let freedom of choice with the guarantee of compatibility be the guide. Don’t let anyone convince you that cloud is a commodity today.

vmware & DMTF President Winston Bumpus and I discussed this at length and agreed that “for cloud to become commodity, it has to become as standardized and available as USB”. (That’s interesting in and of itself as once USB was de-facto, a lot of companies made a lot of money on selling products based on it). Does standardized mean open ? Not always, but in this case, I think it is an absolute requirement.

There are tools today that allow me to build, deploy and manage cloud platforms, but I don’t have a great degree of confidence that I can seamlessly move these across providers with 100% success. Notice I have never said “instantly”. I am willing to be “real time enough” to ensure that I get my service up and running somewhere else, exactly as I left it before.

I think Ruv Cohen is making a really interesting play with his SpotCloud offering. I have no idea how the vagaries of the various cloud providers will play out when it comes to offering services through a clearing house. Maybe time will tell. It’s hard for me to believe that it could be achieved across cloud providers today.

In my mind, this starts with the definition, then widespread adoption of standards, twinned with the vendor’s acceptance that “all must be created equal”. Some vendors are better than others at recognizing this. They shall remain nameless on both sides of the divide.

To use a Moore’s Law anaology, I would hope that as a technology industry, our capacity to learn from what has gone before, doubles in a shorter or smaller window of time. If so, then I hope to be able to juggle workloads across a myriad of platforms by the time that I have fully and truly understood how to use the keyboard on the iPhone without accidentally typing in Polish.