The concept of an “intercloud” is floating around the tubes and starting to gather some attention. According to Greg Ness you can “Think of the intercloud as an elastic mesh of on demand processing power deployed across multiple data centers. The payoff is massive scale, efficiency and flexibility.”

Basically, the intercloud is the natural evolution of global application delivery. The intercloud is about delivering applications (services) from one of many locations based on a variety of parameters that will be, one assumes, user/organization defined. Some of those parameters could be traditional ones: application availability, performance, or user-location. Others could be more business-focused and based on such tangibles as cost of processing.

Greg, playing off Hoff, explains:

For example, services could be delivered from one location over another because of short term differentials in power and/or labor costs. It would also give enterprises more viable options for dealing with localized tax or regulatory changes.

The intercloud doesn’t yet exist, however---It has at least one missing piece: the automation of manual tasks at the core of the network. The intercloud requires automation of network services, the arcane collection of manual processes required today to keep networks and applications available.

Until there is network service automation, all intercloud bets are off.

What I find eminently exciting about the intercloud concept is that it requires a level of intelligence, of contextual awareness, that is the purview of application delivery. We’re calling them services again, like we did when SOA was all the rage, but in the end even a service can be considered an application – it’s a self-contained piece of code that executes a specific function for a specific business purpose. If it makes it  easier to grab onto, just call “application delivery” “service delivery” because there really isn’t too much of a difference there. But intercloud requires a bit more awareness than global application delivery; specifically it requires more business and data center specific awareness than we have available.

On the surface intercloud sounds a lot like what we do today in a globally load balanced environment: application services are delivered from the data center that makes the most sense based on variables (context) surrounding the request including the user, the state of the data center, the networks involved, and the applications themselves. Global application delivery decisions are often made based on availability or location, but when the global application delivery infrastructure is able to collaborate with the local application delivery infrastructure the decision making process is able to get a lot more granular. Application performance, network conditions, capacity – all can be considered as part of the decision regarding which data center should service any given request.

I rarely disagree with Greg and, on the surface at least, he is absolutely right in that we need to automate processes before the intercloud can come to fruition. But we are also missing one other piece: the variables that are peculiar to the business and data centers comprising the intercloud and the integration/automation that will allow global application delivery infrastructure to take advantage of those variables in an efficient manner. That data, likely, is assumed in the need to automate as without that data there’s not nearly enough to automate decisions across data centers in the way in which Greg and Hoff expect such systems to do.

WHAT’S DIFFERENT ABOUT INTERCLOUD?

What makes the intercloud differ from today’s global application delivery architectures is the ability to base the data-center decision on businessy-type (non IT) data. This data is necessary to construct the appropriate rules against which request decision making processes can be evaluated. While global application delivery systems today are capable of understanding a great many variables, there are a few more nascent data points it doesn’t have such as cost to serve up an application (service) or labor costs or a combination of time of day and any other variable.

Don’t get me wrong – an intelligent global application delivery system can be configured with such information today, but it’s a manual process and manual processes don’t scale well. This is why Greg insists (correctly) that automation is the key to the intercloud. Assuming that the cost of power, for example, changes throughout the day and, in fact, might be volatile in general means that manually reconfiguring the global application delivery system would be necessary. That simply wouldn’t be feasible. A system for providing that information – and any other information which would become the basis for request routing across distributed data centers – needs to be constructed and subsequently able to be integrated into the massive management system that will drive the intercloud.

It makes a certain amount of sense, if you think about it, that global application delivery would also need to evolve into something more; capable of context awareness at a higher point of view than local application delivery. Global application delivery will be the foundation for intercloud because it’s already performing the basic function – we just lack the variables and the automation necessary for global application delivery solutions to take the next step and become intercloud controllers.

But they will get there.

The intercloud turns a global network of clouds (or virtualized data centers) into a cohesive, elastic and flexible mesh of on-demand processing power.  It shifts the balance of IT power from centralized to distributed architectures by allowing enterprises a wider range of on demand IT service delivery choices. 

Read more...

Cisco's intercloud vision may be the hottest topic in enterprise networking today and tomorrow, but it will require CIOs to rethink core issues like security and even addressing.

Read more...

Gartner analyst and cloud pundit Lydia Leong reminds us that without differentiation, all clouds look pretty much the same. 

“These are traits that it doesn’t take a genius to think of. Most are known requirements established through a decade and a half of hosting industry experience. If you want to differentiate, you need to get beyond them.” [emphasis added]

She lists traits common to most cloud providers: premium equipment, VMWare-based, private VLANs, private connectivity, and co-located dedicated gear but doesn’t really get into what really is – or should be – the focus of cloud offerings: services. To be more specific, infrastructure services.

A cloud provider of course wants a solid, reliable infrastructure. That’s why they tend to use the same set of “premium” equipment. But as Lydia points out differentiation requires services above and beyond simple hosting of applications in somebody else’s backyard.

Cloud providers need to differentiate based on what kinds of infrastructure services they can provide including but certainly not limited to management. Going above and beyond the basics, however, requires investment and some roll-up-your-sleeves coding at this point because the management and process automation systems simply don’t exist. The means to build those systems do exist – that’s part of the allure and value of dynamic infrastructure, a.k.a. Infrastructure 2.0.

Using the tools available it is wholly possible to build out the “self-service” for infrastructure services that folks have been led to believe will one day, hopefully, maybe be part and parcel of a cloud computing offering. Building this out is not trivial, but it’s certainly worth it if you’re trying to (a) differentiate from your competitors and (b) find yet another revenue stream on which you can ride smoothly into the next round of technology advances.

Lydia mentions that most cloud providers are built atop premium equipment and cites Cisco networks and F5 application delivery infrastructure among others. There are more than enough “services” that can be abstracted via both companies’ APIs to keep cloud computing providers differentiating their hearts out. There’s presence and location, application acceleration, application security, commonly used web application functions like rewriting URIs and customized “apology” pages via network-side scripting just to name a few. There’s a veritable cornucopia of specialized functionality above and beyond simple network and application network functionality that simply isn’t being exploited to its full potential, both in terms of the technological capabilities and the ability to differentiate for a cloud computing provider.

There’s no reason why such differentiation of cloud providers cannot be achieved through infrastructure services and, in fact, its about the only way to differentiate aside from better management/control over design and maintenance of the deployment. The rest is simply price wars – competing based on cost per mega or kilo or peda or tera byte of something. The problem may very well be that we’re just too early in the game for such large-scale differentiation; that not enough customers are even sure what to do with the basics let alone advanced infrastructure service offerings. Problem is that many times customers won’t sign on to anything – a service or a product – without the promise that they can do more, either right now or in the future. Whether they want to – or will use those services – is irrelevant. The fact that they exist tells the customer that the provider is serious, dedicated, and ready to do business.

It’s kind of a Catch-22. Without the demand there’s no reason for a provider to invest in such an undertaking, but without investing in such an undertaking there may well continue to be a lack of demand. Remember that in many organizations data center infrastructure is the underlying foundation for their competitive advantage. If you can’t offer tit-for-tat you’re simply not a good replacement no matter how much “cheaper” you may be in the short term or long run.

Differentiation of cloud services will eventually come down to management and infrastructure services because there’s really no where else for it to go. What and how those services are packaged and offered to customers will go a long way toward cloud providers differentiating amongst their offerings.

The webinar talks about the top DNS security threats, shares background on DNSSEC and adoption and discusses architectural, operational and organizational impacts.  It also talks about Infoblox’s novel and powerful One Click Management.  It runs about 56 minutes, but has a very easy and manageable interface for navigating between sections.

Read more...