When VMware entered the production data center it was the beginning of a massive IT disruption with profound implications for careers, vendors and the next tech innovation cycle, driven by deep reductions in network operating expenses and equally uplifting increases in network flexibility and intelligence. 

VMware set the stage for the multibillion dollar system virtualization category by allowing operating systems and applications to be easily set up and moved on top of commodity server hardware.  They automated systems that had been requiring ever increasing amounts of manual labor as data centers grew ever more complex by creating an abstracting layer between software and hardware.

Read more...

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.