The Enterprise Cloud

Warning: this is a long, complicated post. But, as I’ve explained before, that’s what I think a blog is for. If you want brevity, try Twitter. Caveat emptor.

Cloud computing. Buzzword ascendant. And for a good reason — it’s a big deal. I’ve been studying and thinking about it for the last year and half or so, and I’m convinced of that, at a minimum — it’s a big deal. But, having said that, as usual, I’d like to get a bit more precise.

As with many buzzword ascendancies, this one is fraught with confusion. What is cloud computing, exactly? I got a chance to hang out with a group of really smart people from a wide cross section of industries in October, by taking part in the Leading Edge Forum’s (LEF) annual Study Tour. If there was a single source of discontent amongst the attendees (CTOs, CIOs, CSOs, chief architects, and the like), before, during and after the tour, then that there is no one, simple, precise definition of the term. A different “definition” emerged with each vendor pitch — indeed, we came to see that the definition sometimes varied on the basis of a given usage scenario. Many people found this frustrating, and I suspect they were not, and are not,…

Warning: this is a long, complicated post. But, as I’ve explained before, that’s what I think a blog is for. If you want brevity, try Twitter. Caveat emptor.

But I also think there is an essential truth lurking there. The fact that the term “cloud computing” means different things in different contexts is telling. There was a feeling of “If somebody could just explain to me what this stuff is, then I would know if it’s of interest to me, or not” amongst many of the other members of the aforementioned group. The problem, however, I think, is that there is more than one type of “cloud computing”, and that the type that might interest an enterprisey CTO hasn’t really emerged yet — certainly not to the extent that the other primary type has. Now, by “type”, I explicitly don’t mean the whole soup of assorted buzzwords that are tightly correlated with “cloud computing” — things like SaaS, PaaS, IaaS, and all the other *aaS’s that Simon has grown fond of poking fun at. Instead, I mean categories that are distinct from one another in the same way that, say, the category of “the financial services industry” is distinct from “the health care industry”. Within these broad categories, many of the details of the different types of cloud computing will be the same (or similar) — including correlations to their *aaS’s. So what types (or categories) am I talking about then? Well, here’s where it gets tricky, as these are still emerging, and therefore there is quite a bit of fuzziness with regard to demarcating them.

But I do think that there are at least two categories that have become distinct enough to identify and talk about, although as we’ll see in the next few sentences, I’m going to struggle with naming them. So what are they? Well, for the lack of a better idea, I’ll call them “startup cloud computing” and “enterprise cloud computing“. This isn’t an original insight — several people have made the same observation. James Urquhart, recently acquired by Cisco to be their cloud computing Poobah, for example, calls the same categories “scale out” and “enterprise” clouds, riffing of of terminology from Frank Gillett, Forrester’s cloud analyst, who called them “scale out” and “server clouds”. Whatever we call them, these are very different beasts. “Startup cloud computing” is the easier category to understand (and define), because it’s the model that is already fairly prevalent, in place, and well documented. The defining characteristic of this category is that it has no (or an insignificant) need to integrate software running in the cloud with software running outside of it. In the purest, simplest example, it is software that is deployed to and runs exclusively in a cloud computing context — such as a green-field application, developed by a spanking new startup company (hence, the name). This is the model exemplified by the Animoto’s of the world, the Flickr’s of the world, and also by the MySpace’s and the Facebook’s of the world. This is the demographic that has enthusiastically embraced cloud computing, and why not? The benefits that accrue from this approach for this sort of a use case are significant, and compelling. Significantly, this is also the sort of cloud computing that you will find in most of the examples, descriptions, case studies and write-ups now blooming all across the web.

Enterprise Cloud Computing

But if you’re an enterprisey CTO, that’s not entirely unproblematic. The point is that the model that these startups embody doesn’t fit precisely to the requirements of an existing enterprise. Enterprises have a number of requirements that distinguish them rather sharply from cloud computing’s early adopters. Enterprises typically have a significant existing base of infrastructure and applications, most (if not all) of which are carried as capital assets on their books. Whether they want to or not, they are compelled to seek ways to capitalise on these existing assets. Even if they can dimly perceive potential benefits from the cool things the startups are doing in the cloud, they need to “protect their investments”. That drives them to seek ways to integrate these with the cloud. Rather than “running their business” in the cloud, as many web solution providers can (and do), enterprises are looking to see how the cloud can be leveraged to provide economical (and secure) ways of adding capacity to their existing environments.

What’s important to understand, with regard to the Study Tour full of discontented CTOs, however, is that they were hoping for the definition of the category that is relevant to them — they wanted to hear about the category “enterprise cloud computing”. The problem was (and is) that this category doesn’t really exist yet — “emerging” may be a bit understated here; perhaps “making it up as we go along” is a better way of describing the current state of the practice.

Despite that, there are a number of things that we can already say about “enterprise cloud computing”.

One: the goal. This is already quite clear: the reason for an enterprise to use cloud computing is agility. Time to market. Speed. There may be some contexts where there are also other benefits, such as reduced costs, but the primary benefit (and therefore, the optimal goal) is clearly agility. I’ve worked in enterprises where provisioning a single UNIX server for an experimental sandbox — to try out and test some promising bit of technology, for example — can take three months. In such circumstances, innovation is hindered, to put it mildly. Cloud computing brings with it the possibility of provisioning resources on a minute-based timescale, and (even more importantly), doesn’t bind us to needing capital assets to experiment — we can switch a virtual server in the cloud off when the experiment is over, and it’s gone, accruing no further costs. That’s a game changer, and the enterprises that figure the rest of the puzzle out in order to exploit it will have a significant competitive advantage (for a time) over those who do or can not.
Two: it needs to be secure. This is a slippery one, though. Consider: often, when I talk to a CIO or an architect in a big enterprise about “security”, what we’re most often (and primarily) talking about is Active Directory. Or LDAP, or RACF, or some other technology (or a combination of same) that is used to control access to resources. Considerations like encryption and the like — the stuff that hackers tend to think about when you say the word “security” to them — are usually secondary. That does not mean unimportant! 😉 Just secondary. Thus, when a CIO says to me “How can I make cloud computing secure?” what I think she is often really saying to me is “How can I integrate this with my existing access control mechanisms such that my people can use it as they are allowed to, and other people are kept out?” The answer to that question will necessarily involve things like data encryption, but that will only be one part of the overall solution.
Three: it needs to integrate cloud-based resources with my existing resources. I need to hook up my internal data centre to these cloud-based resources, and be able to use them as if they were just another resource in my data centre. That has lots of implications, the most significant one being: all of the things that I’ve already done in my data centre to meet the security needs alluded to in point number two need to apply to the new cloud resources as well. An iota less significant, but still very important to me are the means available to integrate my stuff with resources in the cloud — the lower the barrier to adoption is, the better.

There are enterprises using the cloud today. But, in my opinion, there aren’t too many getting the same sort of bang-for-a-buck return out of it that most startups are getting. If there are some, they’re being secretive about it (and who can blame them, given our current location on Simon’s commoditisation curve?). Some enterprises I know of are making use of the cloud as a startup might — they’re using it for isolated, green-field contexts. Some (rather dim-witted) pundits, noticing this, have even gone so far as to speculate that this is the optimal — or even only! — potential use of the cloud for an enterprise. Some are even already spouting nonsense about “best practices” (beware anyone who uses that term, and be particularly afraid of ones who do it with regard to “still making it up as we go along” stuff like cloud computing). That’s just stupid. But it is true that the “enterprise cloud computing” category hasn’t been a complete one, up until recently.

The reason why some folk have reached a conclusion that “well, we can do useful work inside our data centre, and we can do (isolated from that, largely) useful work in the cloud, but we can’t seamlessly mix the two” is that there is a bit of a “last mile” problem. The “last mile” term is one used in telecoms to describe the problem of getting from the backbone infrastructure (which is often super high capacity (e.g.. fibre)) to the infrastructure of a given consumer’s home (which may also be fairly high capacity, such as Ethernet) — crossing the “last mile” to that consumer’s home is often the most difficult (and expensive) part of the overall problem space. Enterprise cloud computing, as a category, has suffered from a similar problem. Enterprises know how to configure LAN’s, setup and administer UNIX boxes, and run software applications on them — that’s what enterprise IT does all day, every day in their own data centres, after all. Thus, enterprises posses all of the skills and knowledge needed to exploit something like Amazon EC2 — it’s just more of the same. The tricky bit, to date, has been the “what now?” moment, after they contemplate doing so — how do they integrate the boxes running in the cloud with their existing IT landscape? That’s changed, recently. Before I explain why I think so, however, it’s worthwhile addressing a third category of cloud computing that is emerging.

“The” Cloud

I think it is both reasonable and useful to draw a sharp distinction between the terms “the Cloud” and “cloud computing”. Moreover, when speaking about “the Cloud”, if the emphasis is on “the”, then we are talking about the sum of all publicly available resources on the Internet. If that’s so, you might ask, why not just use the term “the Internet”? Why come up with yet another term for something that people already struggle with (is “the Internet” == “the Web”, for example?)? Good question — and the distinction (or lack of one) between the terms “the Internet” and “the Web” is helpful in understanding why. I’ll spare you a link circus of references, and just blunder on with some of my own observations about these terms. In my mind, the distinction between “the Web” and “the Internet” is fairly easy to make — “the Web” is the subset of “the Internet” that is reachable via the HTTP protocol. “The Internet”, in turn, is the network of all resources reachable via all known internetworking protocols. However, the Internet is exclusive of those resources — it is just the plumbing that lies between them. In other words, the Net is what lies between resources — it does not subsume them. And that’s the difference, in turn, between “the Internet” and “the Cloud”. The Cloud does subsume the resources that make it up. Google’s internal network is not a part of “the Internet” — it is attached to the Internet. But Google’s network is a part of “the Cloud”. The Cloud is therefore not a physical thing — it is a conceptual thing, a pure abstraction.

Collaborative cloud computing

“OK,” you might say. “That’s borderline pedantic, but I’ll buy it, for the sake of this argument. But what, then, is ‘cloud computing’?” Well, within the framework I’ve established thus far, we can now define the term “cloud computing” as something like this: “A family of architectural styles, each of which categorises a particular way of using resources in and of the Cloud”.

“OK,” you sigh, “I can accept that — although it took us way too long to get here. Is that fairly simple definition why we went off on this tangent? You were going to talk about something that’s changed about the ‘last mile’ stuff recently?” No, that’s not entirely why we went off on this tangent (and yes, I am still going to talk about what’s changed with regard to the “last mile” recently. Patience, please).

We went off on this tangent because I think it’s worth pointing out that there is a third category of cloud computing emerging — and it’s the hardest one to talk about. It’s hard to talk about because it’s at once orthogonal to and yet also overlaps with the other two categories (enterprise, and startup cloud computing). I will call it “collaborative cloud computing“.

Collaborative cloud computing is what people mean when they speak of the promise of cloud computing to leverage all of the various resources in the Cloud. It’s what they mean when they talk about the promise of “mashups”. It’s what they’re getting their shorts all twisted up about when they argue about the problems of federated identity and the merits — or lack thereof — of various attempts to achieve the same. It’s what people are talking about when they speculate on the pros and cons of using Google Maps as your GIS software, or Flickr as your image storage mechanism. Collaborative cloud computing is what lots of people smarter than me seem to think is the point of “cloud computing” — or more precisely, the purpose of the Cloud. I’m not going to disagree with that assertion — as far as I can tell, it seems to be a reasonable one. It just seems prudent to me, again in the interest of precision, to point out a few things about this purpose.

Achieving it is something that both startups and enterprises have to think about. And for both of the other categories of cloud computing, there are challenges involved — largely similar. Questions of intellectual property and control of digital rights, for example — suddenly we stumble across yet another perspective on the slippery term “security”.

Organisations that find ways to exploit usage of the Cloud to enhance and increase collaboration are going to have a significant advantage over those that do not — I’m convinced of that. But I’m also convinced that this is the most advanced, sophisticated usage of the Cloud imaginable (at the moment). If using resources in the Cloud for an isolated use case of a given organisation is “Cloud Computing 101”, then using it for that same organisation to collaborate effectively with other entities is graduate level work — it’s much more advanced, and difficult. It is this category of cloud computing that carries with it the baggage of solving the federated identity problem, of finding ways to securely mashup resources and resolve issues of intellectual property that have boggled an entire generation of jurisprudence.

It’s also worth pointing out that this is the category of cloud computing where we find the PaaS offerings. Some folk only want to focus here, finding infrastructure boring. Simon, for example, explains that this is a simple (and logical) consequence of the model of innovation and commoditisation that he has developed, and as also informed by his own experiences with things like Zimki. I don’t dispute Simon’s conclusions, but I also don’t think they’re universally applicable. And the enterprises that I work with generally aren’t mature enough to exploit PaaS in the manner that Simon suggests they should. Yet. And as my friend Doug Neal of the LEF has repeatedly pointed out, there are going to be use cases for enterprises to utilise cloud computing at each layer of the “stack” — which layer and why will be context dependent.

Collaborative cloud computing is the category that contains all of the really hard problems, most of which, from an enterprisey perspective, remain unsolved (or incompletely solved, at best) at the moment. It is the category of cloud computing that promises the most compelling returns on investment, but also the one that requires the highest investment, and carries the highest level of risk.

But the point of this post is to ruminate on the nature of enterprise cloud computing, and that’s a category we can talk about — and implement — without necessarily getting bogged down in the accompanying complexity of collaborative cloud computing. We can do that eventually, but we don’t have to do it right off the bat — we can plan a roadmap, in which there are clear and obvious ways to leverage enterprise cloud computing in small, incremental steps. Ideally, such a roadmap will lead to collaborative cloud computing. But we don’t have to wait for all of the challenges associated with that ultimate end goal to be solved before we start profiting from increased agility by leveraging cloud computing. It’s within that context that I want to describe some of those potential steps, and it’s within that context that we can talk about a recent development that changes the circumstances of the “last mile” problem.

So what’s the first, baby step an enterprise can take? I think it is “experiment with (and implement) virtualisation technologies and techniques within the on premises data centre”. There are some (frighteningly smart) people who disagree with (or at least, question) that assertion — people who point out that one can achieve all the same benefits of cloud computing using dedicated hardware provisioning and a provider smart and clever enough to do it really, really (really!) well. I don’t disagree with that necessarily, but I do question the usefulness of the observation. Providers who are capable (skillsets, economies of scale, etc.) of achieving the same degree of provisioning agility as Amazon EC2 has (for example) are rare, to put it mildly. For the broadest possible consumer population, these providers are unlikely to be available. Since I have already established, for the sake of argument, that I think the purpose of cloud computing for an enterprise is agility, that’s a big deal. Moreover, as we’ll see shortly, having experience with (indeed, having) virtualisation technology in the data centre is a pre-requisite to the solution I’m going to describe to the “last mile” problem. So let’s establish this as a first order rquirement: the first thing an enterprise must do is build a “private cloud” of virtual resources within their data centre.

Note, however, that this “private cloud” doesn’t need to be very sophisticated — it doesn’t have to be elastic, or automated, or anything particularly complex. Two or three VMware images that are robust (backed-up, monitored, reliably online) and that can route network traffic to both one another and to the overall enterprise Intranet at large is really all that’s needed, for example.

Once you’ve got that, you can leverage it to utilise a product released in late October called VPN-Cubed (see also here), from a company called CohesiveFT. And VPN-Cubed (which, for reasons that will hopefully become apparent, I find to be a sub-optimal product name) solves the “last mile” problem. In fact, it not only solves it, it does it in such a way that it effectively becomes the linchpin of a successful vision of what enterprise cloud computing will be.

All right, then. So what is this VPN-Cubed stuff? And why is it interesting? Well, here’s the best description currently available from CohesiveFT:

VPN-Cubed is a customer-controlled solution for use within a cloud, across clouds or to connect private infrastructure to clouds. It is a novel implementation of VPN concepts but extended for use in cloud computing (and other 3rd party controlled computing environments). VPNs have the typical use cases of connecting 2 LANs together or desktop clients to a LAN over the Internet. VPN-Cubed builds on these core VPN concepts, but can be thought of as a customer controlled “overlay network.” An overlay network is “a computer network built on top of another network. Nodes in the overlay can be thought of as being connected by virtual or logical links, each of which corresponds to a path, perhaps through many physical links, in the underlying network.” VPN-Cubed provides this function, putting it in customer control across multiple locations, allowing the customer to control their topology, their network addressing, their encrypted communication, and their desired network protocols, all in a scalable, highly redundant form.

Here’s the picture, courtesy of CohesiveFT.

Figure 1

“Um, yeah, but… What is this VPN-Cubed thingamajig, exactly?” you say. Well, that’s not an easy question to answer — it’s something new, so no direct comparison is going to be entirely accurate. I think it comes closest to being a software network switch, but it also does routing, so it’s arguably a router (a debate over “what’s the difference between a router and a switch?” that’s almost as old as I am rears its ugly head and is firmly ignored by your correspondent). It also has peer-to-peer characteristics (as do, say, high end routers). It also does network data encryption, hence the “VPN” bit in the name, and there’s even some messaging middleware functionality somewhere in the mix. And did I mention that one consequence of this complex stew is that you can suddenly do fascinating things like multicast protocols (UDP) on cloud computing infrastructure that doesn’t otherwise support such things (like, say, Amazon EC2)? Here’s a picture of the stew, courtesy of CohesiveFT.

Figure 2

Got that? All clear? … Well, if not — no worries. I didn’t understand it at first either, and my experiences trying to explain it to other people, once I had grokked it, were what drove me to write this post. I will step us through it, one bit at a time. Before I do, it’s probably worth reading the technical deep dive that the above quote cites — don’t worry if you don’t grok all of it yet (and if you do, you probably won’t need the rest of this post).

Let’s start with a simple model of a typical, bog standard enterprise data centre. It houses servers (whether they’re mainframes or UNIX or Windoze boxes, or any mix of the same, is irrelevant), networking infrastructure to connect them all up, and the usual plumbing to make sure their use (access) is properly controlled (an Active Directory server, or RACF on the mainframe, whatever). Since this is a modern enterprise, it is also possible for both employees and some select collaboration partners to access its resources via the Internet — to that end there are mechanisms in place to serve as a secure, controlled gateway (DMZ, firewalls, etc.). Here’s a picture.

Figure 3

There is no virtualisation in play here, no cloud, nothing at all of the sort of thing I have been discussing so far. This is our Ausgangspunkt — our starting point on a short little journey of transformation. Given this starting point, I will go step by step through the process of taking this enterprise to the goal of utilising enterprise cloud computing.

For reasons already explained, the first such step is to get some virtualisation tech running in this data centre. Frankly, VMware monopolises this market in the sorts of enterprises I work with, so let’s assume the use of their tech for the purposes of this example. Here’s the same picture, but with a handful of boxes running a handful of VMware images added to the mix.

Figure 4

That is — and again quite frankly — probably close to the bleeding edge for the vast majority of enterprises today. But if they’ve gotten that far, then they have the hardest part arguably behind them — the rest of the enterprise cloud computing model is almost mechanical to implement. For the purposes of my example here, the next step is to (buy and) install VPN-Cubed software on one (or more — we’ll come back to that point) of those VMware images.

Here’s a picture of our simple data centre, with one of these things added to the mix.

Figure 5

Simple enough.

Now, let’s get interesting. We buy some space / time on Amazon EC2 (for example), configure a handful of VM images there (AMIs), and in particular, make one of them a VPN-Cubed box. Here’s a picture.

Figure 6

Note that this is now not a bad picture of the real bleeding edged of enterprise usage of the cloud — some usage of the cloud is happening, but it’s not very well (or at all) integrated with the rest of the IT landscape hidden inside the perimeter of the data centre.

And here’s where we can now throw the switch that closes the circuit.

Figure 7

Configuring the VPN-Cubed servers to talk to each other results in a secure (encrypted) VLAN whose “virtual” perimeter is the sum of our data centre VMware cloud, plus the Amazon EC2 cloud (note that this picture is more or less equivalent to the diagram from CohesiveFT in Figure 1). Notice that, from the perspective of the “outside world”, nothing has changed! As far as the outside world is concerned, they are still talking to the same enterprise, via the same means, with the same interfaces and the same points of contact. The extra capacity added via the Cloud is inside the “virtual” perimeter, and completely opaque to outside consumers. This is a virtual data centre.

This is enterprise cloud computing — the enterprise cloud.

Now, having said that, it’s also the simplest possible example of the same. And there are a number of things we can add to this example without getting burdened with the sort of potentially crippling complexity the collaborative cloud computing category brings with it. For example…

Figure 8

The “plumbing” we have thereby installed can do more than just add cloud-based capacity to our (now) virtual data centre. It can also solve the ”eggs in one basket” problem. We can add another cloud provider, and use that fact to make the overall system more robust. We can mirror things, load balance things, distribute things. Conceivably, we can also start to do things like leverage one vendor’s pricing to pressure another, and we can shift resources more or less at will, on the basis of services levels, cost, or any other enterprisey metric that turns us on. Note that VPN-Cubed only allows us to make the connection to an additional provider — it won’t do any of the value added stuff I’m speculating about here. But because VPN-Cubed’s “overlay network” just looks like a “network” to software and devices that interact with it, we can leverage all of the things and the know-how we already have in the enterprise data centre, internally, to achieve such goals. That’s nothing to sneeze at.

Moreover, because we’ve abstracted away the problem of “integrating a new provider”, we get much closer to the true promise of cloud computing for the enterprise: effectively limitless, elastic capacity. Need more? Add another. Done with that? Shut it off.

Figure 9

Note also that this architecture allows us to mix and match cloud providers using differing underlying technologies. A VMware image is a very different beast from a XEN-based AMI on EC2 (OVF notwithstanding). VPN-Cubed runs on a long list of different image types (providers), and therefore allows an enterprise to build a homogenous “overlay network” on top of a very heterogeneous mishmash of providers. This is a very big deal. Of course, to take advantage of such a network, the enterprise will also need a fast, easy, low cost way to move entire application stacks — effectively, virtual appliances — from one underlying VM platform to another. As it happens… CohesiveFT sells just such a service — Elastic Server is, in fact, their original, primary offering. There are competitors in this space as well, notably RPath. The point is — rapidly and easily configuring virtual appliances is increasingly a solved problem, even if not yet widely known in the halls of enterprise IT, and enterprises will have to become consumers of such technologies to fully leverage enterprise cloud computing.

“But wait!” you might cry. “What about scalability and performance? Aren’t all those VPN-Cubed thingamajigs now major bottlenecks?” Good question. The best answer I can personally offer, at the moment, is “maybe”. It’s certainly not a definite “yes”. The reason why is yet another fascinating aspect of this product’s architecture. I mentioned earlier that there is a peer-to-peer element to the product. The way it manifests itself is a strong answer to the scalability and performance (and reliability, while we’re at it) questions that any reasonable architect should now be asking. How? Well, the various VPN-Cubed boxes all know of one another, and synchronise data with all of their peers. Clients, in turn, can be configured with a “rollover” list, such that, if their primary VPN-Cubed gateway stops responding, they can fail over to another one. This feature can be leveraged in an awful lot of ways — it can be used to setup a fail-over architecture, using one cloud provider as a backup for another. It can be used to deploy multiple VPN-Cubed boxes within a VLAN, and divide the load amongst them, as in the picture below…

Figure 10

And in potentially the most fascinating of all constellations, you could, conceivably, install VPN-Cubed on every VM image you have. That would make them all peers of each other, and would lead to a mesh topology. As far as I know, no one has done such a thing yet, but it appears to be technically possible, and it certainly hints at the sort of complexity that can be architected into solutions of this sort.

Is this sort of architecture possible without VPN-Cubed? Yes, absolutely, but you have to roll your own. And once you’ve started going down that route – do you want to have some kind of fail over between the VLAN links? Roll your own. Want to be able to scale the VLAN links horizontally, so that you can avoid it becoming a bottleneck of its own? Roll your own. Want encryption with that? Roll your own. Before you know it, you’ve begun developing what is effectively a software implementation of a network switch. Do you build your own hardware switches? Not likely. And you probably aren’t going to enjoy the experience of writing one in software either. That’s where VPN-Cubed comes in — they’ve already written the thing. It’s the classic build-or-buy evaluation, and it will startle me if there are enterprises that come to the conclusion that writing this particular bit of software themselves is a good idea.

And we’ve left a whole raft of issues unexamined in this post: those UNIX (Linux) images you’re deploying to the cloud had better be hardened, for example. But these are all issues that there are known solutions for — the change of context that applying them to the cloud implies does not change the solutions themselves.

“Hmm. OK,” you say, having suffered through all this, and not yet run screaming for the hills. “Now that you’ve explained it that way, it seems fairly straightforward. Why hasn’t somebody done it before this?” Ah, very good question. I don’t know. But, as always, I’m happy to speculate wildly. To an extent, part of a comprehensive answer would be, “They have.” The folks at VMware, for example, are very, very smart. They grok the importance of virtual networking, within an overall virtual data centre architecture like the one I’ve sketched here — they grok it completely. As such, there is technology in their stack that serves a similar purpose. VMware ESX has a virtual networking layer, as part of their overall stack, which, among other things, includes the concept of virtual switches, implemented in software (and ESX comes with a default implementation of the same). This is essentially the same architecture as depicted here, but limited to the scope of a VMware-based cloud. Could VMware develop a thing like VPN-Cubed, that extends the virtual network to include other VM providers? Sure, I bet they would find it almost trivial to do so. But why should they? If the overall market moves in a direction that make that a profitable proposal for them, I have no doubt they will do exactly that. But failing such a market development, it’s certainly not in VMware’s interests to push the market in that direction. If VPN-Cubed gets significant traction, expect VMware to respond. 😉 What about some of the other players — say, Cisco, for example? Again — good question. I suspect Cisco is already busy answering it — things like the Nexus 1000V (which replaces the default VMware switch in an ESX-based cloud) are too close to being this already for this not to be the case. And recent ruminations in the blogosphere give me the feeling that I’m not the only one who thinks so. To quote James Urquhart again, he said of VPN-Cubed, shortly after its release, that he thinks it might be a “game changer” (particularly with regard to the way it allows an enterprise to manage control of resources). Even more recently, there’s been a fair amount of chatter about how the network, in general, has been neglected by cloud technology providers, which have concentrated on CPU and storage to date. Consider this post of James’, as well as this one, and a whole series of posts by Greg Ness (and here), Lori MacVittie, and Greg Hoff, for example.

So, let’s sum up. Enterprise cloud computing is a type of cloud computing that is suited to the specific requirements of existing companies, and allows them to leverage resources in the Cloud to provide economical ways of adding capacity to their existing environments. First, their existing data centre (or some portion of it) is virtualised. Once this is accomplished, capacity from external cloud providers can be added (and dropped) dynamically, using technologies like VPN-Cubed, allowing enterprises to use the cloud to elastically (and transparently) scale out to the cloud. And because all network traffic is securely encrypted, enterprises can effectively make use of public, cloud infrastructure as if it was part of their internal datacentre — entirely behind the (virtual) firewall. Moreover, the same technology can be leveraged to allow the use of multiple, disparate cloud providers, effectively solving the ‘eggs in one basket’ problem. Different cloud providers can be leveraged to allow for failover redundancy, load balancing, even the leveraging of different providers on a dynamic basis, using metrics such as SLA compliance, or changes in cost. And an enterprise might want to do this not because it will reduce costs, or allow a switch from capital to operating expenditures (although both of those things might be true or not, depending on the context), but because it will increase their overall agility.

Sounds good to me. What do you think?