Microsoft Dynamic Infrastructure Toolkit for Systems Center (DIT-SC) is hopping forward, literally, into the network. With or without established standards, this dog is going to hunt.

It takes time to develop standards, something we often overlook. When the foundational standards upon which the Internet were being developed there were (almost) no users, no broadband, and no real urgency to get something available. The adoption of disruptive, highly volatile technologies such as virtualization and cloud computing result in an environment in which today’s standards groups are not afforded the luxury of time. Organizations want, nay they need, standards now and if they aren’t forthcoming vendors and customers alike will move steadily forward with their own implementation.

The myriad “cloud APIs” submitted to various standards organization indicate this pattern of behavior has already begun and will continue until the dust settles and one (and hopefully only one) API comes out on top. Microsoft may have come “late” to the cloud computing table, but it’s certainly making up time by moving forward with its Dynamic Infrastructure Toolkit for System Center.

The Dynamic Infrastructure Toolkit for System Center is a free, partner-extensible toolkit that will enable datacenters to dynamically pool, allocate, and manage resources to enable IT as a service. Whether you’re an enterprise customer, a systems integrator, or an independent software vendor, the toolkit will help you create agile, virtualized IT infrastructures.  

-- Microsoft Cloud Computing Infrastructure solutions

What’s a bit different about Microsoft’s Dynamic Infrastructure Toolkit for System Center (DIT-SC) is that it’s not focusing on standardizing the interface to the cloud, a la Yet Another Cloud API, but rather it’s focused inward, on operations, much in the same way the cloud API of Yahoo! is highly focused on internal rather than external operations. 

The DIT-SC provides a framework – not an API but a framework – that allows partners and customers to manage resources, including infrastructure such as load balancers, firewalls, and other network-hosted services. By providing a framework Microsoft can leave the implementation up to vendors and customers which is of course cost-effective on their part but also provides the means by which those infrastructure solutions that are not yet Infrastructure 2.0 enabled can still be supported. 

Assume for a moment a device, X, does not have a standards-based control plane accessible for automation and remote control. This does not mean it cannot be automated, it simply means alternative methods of communication and control must be used. Holistic identity management systems used this technique extensively to manage accounts on operating systems and applications for which there was no programmatic interface, and administrators have used remote scripting playback to automate tasks for what seems like eons. Using PowerShell the integration of both Infrastructure 2.0 and non-enabled systems can be accomplished, resulting in unified data center management of resources via System Center. load balancing is one of the planes of control, and will be primarily enabled through the existing Infrastructure 2.0 capabilities of various vendor implementations such as F5, Citrix, and Cisco. 

Microsoft is approaching Infrastructure 2.0 and the integration of network-hosted resources in a very implementation agnostic way. Rather than simply lay the entire responsibility at the feet of individual vendors, it has taken a more “standardsy” approach in that the definition of the PowerShell interfaces to network and application delivery network infrastructure will be normalized across similar component functionality. Standardized, essentially, into a common task and model-oriented set of interfaces that can be used to basically plug-in any vendor solution in a particular data center niche. This “normalization” is very close to “standardization” and thus it is not inconceivable that in the future we may see the model and interfaces developed to support the DIT-SC framework proposed as a standard in much the same way other vendors have put forth their models and interfaces as potential “cloud” standards.

Not the framework, mind you, but rather the collection of infrastructure and resource control that result from ongoing efforts to integrate infrastructure and network and systems’ resources into a unified dynamic management system.

That’s the target of Infrastructure 2.0 standards efforts; the definition of a model and interfaces unified across the network and application delivery network as well as “interclouds.”

The problem is that there’s no one really to “blame’ for what’s almost certainly going to happen: the rise of de facto standards. Certainly some vendors and organizations are counting on that happening, and for others it’s just going to happen because, well, that’s the way things work in a rapidly evolving environment. Standards are not forthcoming fast enough at this point to address the rapid evolution of data center operational needs. Given the scope of the task at hand – developing a set of standards that will ensure interoperability of infrastructure and cloud computing environments – it’s no surprise that it’s taking some time. At least it’s no surprise if you expect that such standards will  be long-lived, well-thought out, and as future-proof as standards can be.

It may be that efforts such as DIT-SC will, in fact, be helpful to creating “accepted” standards in the future. Anyone who was involved in IT before TCP/IP rose to the top of the standards heap and became the accepted industry standard, beating out Novell’s IPX/SPX and IBM’S SNA will recall that there was a time when it was not clear which “standard” would ultimately “win”. A similar situation will almost certainly arise in the arena of cloud computing, if not at the cloud API layer, then internally, at the operational layer. By tossing the infrastructure models developed to support vendor and provider frameworks into a hat it may be that a unified set of standards can be developed that make the internal integration (collaboration) required to orchestrate IT operations and allow organizations to fully realize the benefits of virtualization and cloud computing.

In the meantime, Microsoft has (somewhat quietly) joined the Infrastructure 2.0 movement by ensuring the means by which network and application delivery network infrastructure can be automated and orchestrated through a centralized “cloud management” system with DIT-SC. That’s certainly a leap forward in the right direction.

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...