What is needed to customize the cloud is a pair of data center ruby slippers called Infrastructure 2.0.

Frank Gens of IDC discussed the “New IDC IT Cloud Services Survey: Top Benefits and Challenges” in his blog and what is not surprising is that security continues to top the challenges associated with cloud services. What may be surprising to some is the increasing focus on customization. It shouldn’t be. As customers continue to push at the boundaries  of the cloud computing model they will inevitably find it unable to meet some need they have, such as customization.

See, when IT professionals said they didn’t want to worry about infrastructure that didn’t necessarily mean they didn’t care about the infrastructure. What they meant was they didn’t want to bear the operational and capital expenses associated with infrastructure if they didn’t have to. That’s a very different story than not caring about the infrastructure or about their ability to provision it, manage it, and ultimately control it. Applications are never deployed in a vacuum, after all, and part of the way in which they are secured, optimized, and made highly available is through its supporting infrastructure. Many of those options are simply no longer available in “the cloud”, and this is likely to be a bullet point in the “against cloud” column for many organizations who employ a more infrastructure inclusive strategy to delivering applications.

We could easily argue that “lack of interoperability standards” (cited higher on the challenge scale at 80.2% of respondents concerned to very concerned about standards in the survey) is directly related to this lack of customization capability (76% cited this as a concern). After all, interoperability standards across infrastructure of similar ilk would, ostensibly, make it easier for cloud computing providers to offer the infrastructure services required to customize the environment.

Infrastructure 2.0 is the means by which many of these concerns will eventually be addressed.

I will now shamelessly adopt terminology generally associated with SOA because cloud computing and “self-service” customization is, at its core, about leveraging a service-oriented architecture. That’s why we call them “services”, after all. That in the case of cloud computing the architecture is focused on infrastructure is irrelevant; the same principles embraced by composite applications built from software (business) services can be equally applied to a data center architecture built from infrastructure services.

Infrastructure 2.0 capable devices, whether virtual network appliances or physical hardware implementations, are solutions enabled with some sort of control-plane, usually REST or SOAP and accessible via an HTTP-based communication channel. These control planes provide the means by which cloud computing providers – or ISVs or regular old folks in the enterprise – can integrate infrastructure services into the application deployment and delivery chain.

This is nothing new. These capabilities have actually existed for nearly a decade now. What is new is cloud computing and virtualization and the need for automation and orchestration of the application deployment and delivery chain to enable efficiency and drive down the costs associated with delivering large-scale applications through rapid elasticity and scalability.

By exposing infrastructure services to customers it allows customization in a consistent way. The interesting thing about virtualization and cloud computing is that like SOA, the service implementation can vary without changing the interface through which the service is provisioned and managed. Some services may actually reside on physical infrastructure hardware while others might require the provisioning and deployment of a virtual network appliance (VNA). The customer may care about the implementation as it could effect cost or require specific management skills to include in their “virtual infrastructure” in the cloud environment.

For example, a cloud provider is going to provide load balancing as a means of scaling applications and, likely, virtualized infrastructure services. Using infrastructure 2.0 capabilities, the APIs and SDKs that manage and control infrastructure, the provider can offer a variety of options and billing structures based on the form factor and capabilities. One service might be a basic load balancing service, via a shared hardware Load balancer, with its only options being a choice of a few load balancing algorithms. Customers requiring more intelligent load balancing algorithms might be able to choose the same service on a shared hardware load balancer, but with more options and at higher costs. Customer desiring advanced application delivery capabilities such as network-side scripting or protocol optimization or security may be offered the choice of such services via a dedicated virtual application delivery controller, at yet a different cost rate. The reason this works is because the service interface is the same regardless of whether the form factor is hardware or virtual; it’s SOA in the network; an abstraction that allows for differences in implementation internal to an environment and, eventually, across environments.

As a customer chooses services to include in the application delivery chain it becomes essentially a composite infrastructure based on a chain of individual services. This is very similar to the way in which composite SOA applications would be composed: as individual services that combine to form a complete application.

What an infrastructure 2.0, service-based model offers both sides of the cloud equation – customer and provider – is choice. Choices in deployment form factor, choices in services offered and available; the customization cited as concerning by customers exploring cloud computing environments. This is the way in which cloud providers will be able to differentiate their offerings – by providing choices to customers in the infrastructure services available.

Remember Dorothy thought she needed the Wizard of Oz to get her home. Only after she saw that the wizard actually wasn’t, that he was just a man moving levers and pushing buttons behind the covers, was it revealed that she’d always had the power to go home on her own: those red, ruby slippers. Infrastructure 2.0 are the customers red, ruby slippers; providing the means by which they can customize their cloud-based application delivery infrastructure in the way that best suits their needs, without the help of the Wizard of Cloud.

An Infrastructure 2.0 services-based model is vital to addressing several of the challenges still raised in surveys: lack of interoperability standards, ease of integration with internal applications/infrastructure, migration back to the enterprise data center. If data center architectures are based on services, and not specific hardware or virtual implementations, it will be a lot easier to migrate that architecture between cloud computing providers and the local data center (“in house”) because the over-arching orchestration, the model, is a composite of infrastructure services. It essentially becomes an architecture built on solutions, not products.

That’s not to say there aren’t challenges associated with an infrastructure 2.0 services-based data center model. Differences in service implementation right now make it difficult to migrate services between vendor implementations, something that must be addressed before complete portability is possible. But this is the next evolutionary step in cloud computing: the abstraction and normalization of infrastructure services. Without this step customers will continue to raise the same integration, portability, and customization issues as they do today, and the growth of cloud computing will eventually slow to a crawl.

I wouldn't even be a member of the Infrastructure 2.0 blogging group if it wasn't for the fact that I love the opportunity that cloud presents to enterprises. I know, where's the "but"? Keep reading....

But, as much as the benefit of cloud is relatively well understood, like any complex activity you can't just plug it in, turn it on and assume everything will work out just fine. I've talked to a number of people over the last few years who've complained that projects to implement virtualization were complex or difficult and I couldn't agree more. Here's the rub, every change we ever make, in life, IT or otherwise is difficult and often complex if it's worth pursuing. There are few people if any who can say that the well executed implementation of virtualization hasn't been a boon to enterprises all over the world, even though they were complex & often difficult.

So how does foreseeing this problem created by dumping cloud into our environments early help you develop a strong team and an excellent service?

Introducing cloud to your environment without a strategy of ownership could set back your efforts for years. At many levels cloud will change the very nature of how we deliver services, even how we own or don't own hardware and data centers. My belief is that at a minimum you should consider having the following high level cloud use or ownership strategy goals fleshed out;

• What is the required end result of your move to cloud? This might sound like it's easy, but it's not. This is more than money and it's more than improving your DR or eliminating the need to buy hardware. The move to cloud should have well defined links to your enterprise strategy. Unlike many IT infrastructure solutions (Yes, Cloud is IT Infrastructure) cloud has the distinction of being a technology that could actually change the way your enterprise does business.
  • Does it accelerate your ability to reach new customers
  • Can it improve your ability to expand into new areas
  • Does it allow you to do business with a new class of customer (I.e., you can play with the big kids now)
  • Can it reduce your cost of doing business
  • Does it enable a completely new level of enterprise agility and customer satisfaction
• How will the implementation of your cloud strategy affect your IT group? At a minimum you're going to need to do some retraining, and if you don't plan you might find yourself in a position to have to replace staff. I'm a firm believer that making your team a part of the future will only strengthen your hand and lower the risk you're carrying. There's nothing wrong with investing a little energy in the "Leadership" portion of your management job so you can build team and staff loyalty. Some basic thoughts on the potential change to the organization:
  • Dramatically reduced requirement for
    • sys admins
    • hardware support skills
    • data center ops staff
  • New or Elevated skills will be needed
    • Architecture in the application stack
    • Performance & Reliability tuning and reporting
    • Security
    • Policy development and management
    • Business liaison/engagement managers
    • Contract management
    • Vendor Management and hardware selection strategies
• The good news is that with proper planning your groups natural growth and attrition will mean that if you begin your team transformation now, in three years you'll have the team you need and won't likely need to reduce head count.

What do I mean when I say "Ownership"? I use the term regularly when I talk about data centers. My definition doesn't involve actually physically owning a data center structure, but rather a strategy for understanding and being responsible for all things related to your data center. In other words, having an ownership strategy that's aligned with thinking of the data center as a system ala the Data Center Pulse "Stack". In the case of Cloud "Ownership" I mean the same thing. In order to ensure you have the necessary skills, budget, and vision in place for your cloud, you need to see it as a system and understand what it means to own that system.

Are Multiple Clouds In Your Foreseen Future?

Going forward I strongly believe that most organizations will have multiple clouds, probably greater than three. These clouds will be a combination SaaS, public (EC2, Terramark, etc) and private (vmware, Citrix, etc). As you consider what the cloud enables (agility, flexibility, commoditized hardware, no vendor lock in, etc., etc.) you will start to see that if you want to leverage these benefits you can't fully capitalize on them if you're only using one. Also, the best of breed approach becomes a reality, without the issues of lock in.  

So, if you're going to have multiple clouds how are you going to manage them? Great question, I'm glad you asked.

The last thing you'll want to do is buy/build or contract your way into multiple clouds and not have a strategy for how you'll manage their use and support. This is where cloud Orchestration comes in. The ability to spin up a stack of vm's that fit an infrastructure profile (websphere, .Net, Java) at a moments notice, regardless of the cloud you're requesting it from is key. It's key not just because it's easier, but because it will help you ensure that your governance and enterprise policies are always applied in a consistent fashion. This orchestration and governance also dramatically improves your ability to provide self service to your customers, regardless of whether those customers are IT staff or end-users.

Seeing as how cloud is still a relatively new concept, you can bet there are few solutions in the cloud management & orchestration arena. I believe that ServiceMesh is the only company on the market today that is capable of enabling the opportunities and capabilities discussed in this blog. I will make the disclosure that I've recently taken a position with ServiceMesh, so I'm naturally biased. However, that doesn't change the fact that the statement is true.

How are you going to capitalize on this oportunity?

The future of the enterprise is about to change forever. While many large tech vendors are looking to find ways to lock in their customers, the pursuit of the right to choose is a "given" when it comes to cloud, or at least it should be. The vendors that are most successful in supplying cloud solutions or IT infrastructure for the enterprise will be those companies that adjust their approach and find ways to offer technologies that are measured against new factors like, energy consumed to produced compute, and ease of acquisition with fail in place options.

It's a bold new future and we're on the cusp of being able to realize some incredible new benefits through this revolution in the use of technology. Strap in and hold on, because change is coming. You can be a part of it, or you can be buried by it, the choice will be yours. If you choose to be a part of it, proper planning and execution of strategy can mean your risks can be dramatically reduced and your opportunities improved. Problems Forseen are Opportunities Created.

The much anticipated divorce between Cisco and HP that was announced in recent weeks is a harbinger for the network equipment industry.  Note Alexander Wolfe’s comments from his Wolfe’s Den blog:

Cisco has made what can only be characterized as an aggressive move emphasizing its strategic surge from a networking-centric vendor into a unified computing powerhouse.

Read more...

HP joins the infrastructure 2.0 conversation as IT and network automation pressures build.  We celebrate the brilliant telephone operator comedy of Lily Tomlin with a photo courtesy of YouTube.

Read more...

Agreed that cloud vendors need to differentiate on services. Disagreed that cloud standards will not forward that cause and that virtualization platform makes a difference.   

The battle for virtualization platform dominance rages on, but it will not be virtualization that makes or breaks a cloud computing offering; it will be the diversity – or lack thereof - of the services it offers. We need to stop focusing on virtualization as the be-all and end-all of cloud computing and start bending our efforts toward what really matters: the ability of providers to efficiently offer a broad set of differentiating services and of customers to take advantage of them to architect a cloud-based solution that delivers their applications efficiently, securely, and as fast with as little manual interference as possible. Citrix CTO Simon Crosby touches on this point in a recent interview with John Furrier, “VMWare Had Nothing To Do With The Cloud Trend. Their Strategy is Flawed”, on the topic of cloud computing and virtualization.

I don’t see any viable opportunities for cloud vendors if all of them are offering a homogeneous set of services designed by one company called VMWare. That whole concept is broken.

I’m going to agree with Simon with the caveat that he could have ended his statement at “homogeneous set of services” and the concept would still be broken. Cloud computing isn’t about any one virtualization platform, it’s about the services that it can provide – from the network to storage to application network to ease of provisioning and management. Those services must eventually encompass the whole of a traditional IT infrastructure and they must be accessible and manageable by the customer. And they need to be portable across cloud implementations lest customers continue to balk at the prospect of locking themselves in to any one cloud computing provider or architecture. Crosby questioned the need for Cloud APIs and standardization a little later in his interview saying, “Should Cloud APIs be standardized? If there was a standard then all the clouds would look the same.”

I disagree. The existence of standards would allow cloud providers – and more importantly cloud customers – to differentiate. Would all clouds look the same from the outside with standards? Yes. Would they act the same way on the inside? Absolutely not – at least one hopes not. The creation of standardized Cloud APIs is about portability and management and accessibility on the outside, which is really about interoperability from a service offering point of view. A standardized Cloud API really has very little to do with the internal implementation; it’s simply an abstracted communications layer interface. It’s SOA in the purest sense – the separation of the interface (API) from the implementation (the underlying “cloud” infrastructure). Standards are certainly part of what’s needed, eventually, to allow potential customers to explore cloud computing offerings and enable organizations to take advantage of concepts like cloud balancing, but Simon’s point about offering up homogenous services being dangerous to the longevity of cloud providers is really about services on the inside not the outside, and it is on the inside that standardization is absolutely necessary to bring about the ability for providers to offer up not only a heterogeneous set of infrastructure services, but simply to provide the choice and control that is inherently lost when moving an application to a cloud provider today.

The existence of APIs and standards inside, a la Infrastructure 2.0, would increase the ability of providers to integrate into their comprehensive management and orchestration systems more choices across infrastructure offerings, thus providing a broader set of options for customers in architecting a cloud-based infrastructure that best suits the needs of their applications. Without such standards cloud providers are faced with a limited set of choices and all of them lead to the same result: a restricted set of services that may or may not allow the provider to differentiate and add value atop the value already offered by what is essentially cheap, managed compute resources. It’s what cloud providers can build using those standards to expose services that will give them a competitive advantage.

Simon later says, “At the end of the day the IT job is to deliver applications, and those applications today are sophisticated things composed of multiple runtime entities or multiple virtual machines.” I couldn’t agree more and Simon’s reminder is timely as we begin to see more and more interest in long-distance migration of “applications” across physical locations. The focus of any IT infrastructure and architecture is to deliver applications to customers, users, and partners and to do it in a way that’s fast and secure. In many cases the application – whether by design or accident – simply can’t meet these goals. In some instances it’s the case that the application, in order to be secure against attack and compromise, needs the assistance of IT infrastructure because some classes of attacks are directed not at the application, but at its supporting infrastructure: the application server, the network stack, the operating system, the physical device.

We know that the choice of load balancing algorithm has a direct impact on both the efficiency and performance of applications, yet many of the load balancing offerings today are “one size fits all” and do not allow customers control over what algorithm is used, or whether optimizations are applied. It is well understood that some application delivery services require visibility on both the client and server side of the delivery equation, yet this visibility is denied to customers. The purpose of application delivery is to extend the reach of the application out into the network, to be able to leverage services residing in the network to improve performance, increase capacity, and make more efficient the practice of securing the application. It’s about an architecture that’s designed to make the most of out all resources, not just remove the burden of acquiring and managing physical servers.

The existence of standards would allow these kinds of services to be offered, and allow them to be more varied. If every application delivery solution could provide its services via a standard API – and similarly expose what services are available – then cloud providers could leverage those APIs to offer up more choice to customers, including services from competing solutions. Cloud computing is about integration and collaboration; it’s about flexibility not just in scalability but in architecture. What should be offered is the means by which customers can pick and choose from among a broad selection of infrastructure services based on capability, price, and the specific needs of each application. Such an offering is highly unlikely to come to fruition without standards simply because of the time and effort required to integrate fifteen or twenty different APIs with a single, cloud management and orchestration system.

Taking Simon’s statement slightly out of context, I agree: the whole concept of offering homogenous services is broken. But I’ll go further and say that no single virtualization vendor (or any other vendor, for that matter) is going to be able to offer to providers – and thus customers – the entire set of infrastructure services required to efficiently and securely deliver an application.