Data Center Strategies

VMware Acquisitions… New Management Direction or More of the Same?

Yesterday VMware acquired several products from EMC’s Ionix management portfolio: Server Configuration Manager (formerly Configuresoft), FastScale, Application Discovery Manager (formerly nLayers), and Service Manager (formerly Infra). In my opinion, the move makes sense because the products will get considerably more traction under the VMware brand than as part of the EMC Ionix umbrella. VMware has successfully launched several new management products resulting from acquisition or internal development - Lab Manager, Lifecycle Manager, CapacityIQ, and Site Recovery Manager – to name a few. I expect similar success for the products that were under the Configuresoft and Fastscale brands as well (prior to their acquisition by EMC).

While a broad management portfolio is needed, seamless integration is far more important to our clients’ cloud initiatives (with a heavy reliance on automation) than a platform consisting of several required but disjointed products. I recently discussed these concerns in greater detail in these posts:

• The Cloud Mystery Machine: The Need for an Infrastructure Authority
• VMworld Day 1 Keynote – A Few Thoughts

That brings me to VMware. The process of collecting “functionality checkboxes” is a longstanding strategy taken by leading management vendors. Rather than integrate, vendors too often rely on product marketing. I think this picture from oddlyspecific.com captures the essence of enterprise management product marketing pretty well.

Let’s face it. It’s far easier (and less costly) to tell an integration story via creative product marketing than it is to actually commit the engineering resources to build a truly integrated solution. In other words, let’s take a management platform built to solve a specific problem years or decades ago, and bolt on some other products to make it relevant to today’s management challenges. The big four in management (i.e., BMC, CA, HP, and IBM) have historically taken this approach, and one could say that VMware is doing the same. In addition, one could argue that CA's 3Tera acquisition is another "sign of the times."

When vCenter and its backend database were originally architected, enterprise cloud management wasn’t the goal. VMware has already commented on its work regarding a Linux-based vCenter VM appliance. I see the movement to the vCenter VM appliance as VMware’s chance to get vCenter right, with the extensibility needed to grow the vCenter schema as cloud management requirements further mature.

Over the last couple of years, VMware has worked to transition itself into a management company. I blogged about this transition at VMworld 2007 and my Gartner colleague Cameron Haight also discussed this trend in his 2007 document “Why VMware Must Morph into a Management Company.” If that transition follows historical patterns, VMware’s clients should worry. Automation and infrastructure-as-a-service are far too complex to be solved by legacy bolt-on management approaches. The existing disconnect between VMware’s DRS service and other management products or features such as vShield Zones and CapacityIQ are just two examples, but there are plenty more. VMware’s problem, like many, is not that the left arm doesn’t know what the right arm is doing. If the arms were attached to the same body, that would be a good start. Instead, we have a bunch of individual cooks, all with their hands in the virtual infrastructure pot. VMware made a good move yesterday to broaden it’s management portfolio; however, they have a lot of work to do. Cloud and infrastructure-as-a-service are highly disruptive to traditional IT operational management, and in turn creates opportunities for new vendors to unseat the big four in the enterprise management space. Following a path that leads to legacy bolt-on style disjointed enterprise management isn’t going to cut it. That being said, I know that VMware is smarter than that, and let's hope their clients won’t be led down a path with a familiar ending.

Computer Associates Acquires 3Tera: Smart Move

As many of us have seen, Computer Associates announced the intention to acquire 3Tera today. In my opinion, this is a good move by CA.

If you're unfamiliar with 3Tera, they are what I would call a "cloud enabler". 3Tera's grid-like platform -- called AppLogic -- enables cloud vendors and IT organizations to build cloud services (external or internal respectively) on top of their existing IT infrastructure. Applogic is built upon a virtualization platform that enables the cloud consumer to build virtual data centers and run applications (called virtual appliances) within the virtual data center.

By purchasing 3Tera, CA gets a cloud OS management infrastructure and consumer interface to the cloud....key pieces to building a cloud.By combining 3Tera software with CA's enterprise management capabilities, one could imagine customers migrating application workloads between internal IT infrastructure and external providers. Customers can begin to build hybrid clouds and blur the line between internal and external services using a combined 3Tera and CA interface. However, the are other pieces of cloud computing that CA will need to address. The first is virtualization. 3Tera has an affinity for Xen hypervisors. By not being hypervisor agnostic, 3Tera's Applogic competes with overlapping virtualization vendor hypervisors and management software such as vCenter, SCVMM, and XenCenter. Also, 3Tera was a quasi-service provider. Being a provider and an enabler can cause some conflicts of interest.

Nevertheless, this is an interesting -- and important move -- in the cloud market.

[posted by: Drue Reeves]

A Client Virtualization Story

This last week-end my elder brother was in town for a wedding in the family.  He’s an orthopedic surgeon practicing in northern California – way north near Oregon.  During our visit, he told me of some technology changes that have occurred at the hospital where he works.  An HMO was brought in to take over hospital administration at the end of last year.  One of the first things they did was install thin clients in each of the exam rooms of the hospital.  However, they installed thick clients in each of the doctors’ offices.  All the thin and thick clients are hard wired with Cat5 cabling -  no wireless to these units.

My doctor brother told me that he can’t use the thin clients in the exam rooms because “the digital x-ray images look more like a topographical map than an x-ray and as a result are nearly useless.”  What he is forced to do is leave the patient and got to his office and use his thick client in order to view the x-ray image.  Most everyone reading this blog has already said aloud “he needs to increase the resolution of the image so he’s not looking at 256 colors as he needs to be seeing the images in millions of colors.”  That’s what I mentioned to him.  He said that when the contracted technicians were testing the newly installed system, the doctors complained.  The hardware technicians quickly blamed the software technicians and vice-verse.  The end result was that the problem wasn’t solved before the contractors left.  My brother (and other doctors at the hospital) now have a very poor opinion of thin client technologies, and would like to just be rid of it all together.  My brother didn’t pay attention to the make of the thin client terminals nor does he have any idea if Citrix, VMware, or what other make of desktop or presentation virtualization software is being used (sounds like I need to get an excuse to go and visit him.)  I suspect that some simple modifications from default settings in either the remote display protocol software or the thin client devices is all that’s required – but without knowing the makes and models, that’s nearly impossible to judge.

This story illustrates that a successful thin client installation is not only dependent on good software and hardware, but proper training of the installation technicians and better end-user requirements gathering.  The doctors can view and update medical records so long as they are text only, but with the current equipment and configuration, any requirement for high resolution medical images is not being met.  Their poor opinion of thin clients may derail any future expansion or new projects in other hospitals.  The bottom line is that the technology, configuration, and deployment was not designed, tested, nor piloted to meet the requirements of the environment and this now will leave a bad taste in the customers' mouths.

[Posted by: Richard Jones]

The Cloud Mystery Machine

In some situations, mysterious is cool. Pop culture often embraces certain entertainers because “they’re mysterious.” When it comes to cloud, some folks appreciate the fact that cloud is mysterious too. In several conversations over the past twelve months, I’ve heard some semblance of the following phrase uttered “All you need to care about is the application and the SLA.” Factors like physical infrastructure don’t matter. Or do they?

In 2010, we need to take steps to make the cloud less mysterious. If it’s less “cool,” then that’s a good thing, because that probably means it’s becoming a more serious platform for enterprise IT. However, if we’re going to get serious about cloud, a lot of work remains. The following posts highlight areas that I think should be points of focus in 2010:

• Infrastructure Matters
• Metadata Standards
• Licensing
• The Need for an Infrastructure Authority

A large percent of our clients are very serious about cloud, but they want to see traction. They’re tired of making the same complaints about virtual infrastructure management and orchestration and seeing no results. A large portion of my 2010 Burton Group research will be devoted to private cloud architecture and management. Aside from highlighting what’s needed, I’ll be focusing on practical management methods that can be used today. Also, I think the issues I highlight in the posts below are just the tip of the iceberg. Cloud storage, for example, is still a work in progress. What else is needed? I welcome your comments.

The Cloud Mystery Machine: Infrastructure Matters

This post continues the discussion in my “The Cloud Mystery Machine” post.

Contrary to the utopian cloud model many espouse, underlying infrastructure still matters, especially when you consider application performance and the ability to satisfy SLAs. Most folks are well aware of virtualization live migration incompatibilities between Intel and AMD platforms, but what about substantially reduced performance between Intel platforms? For example, consider an enterprise application that realizes a substantial performance benefit from Intel’s hardware-assisted memory virtualization – Extended Page Tables (EPT). XenApp, Exchange, and SQL are among the many applications that benefit from EPT. Moving the application to a cloud platform without EPT support could result in significantly degraded performance. If you have no information on a cloud service’s underlying hardware infrastructure, you may not know about the lack of EPT support until you start getting complaints about application performance. Then what do you do? Ideally, when a user or application requests infrastructure services from a cloud provider, there should be a mechanism for specifying low-level hardware requirements such as EPT.

When it comes to trusting critical applications to cloud service providers, not all organizations are keen on the idea of trusting an application on a white box server with memory acquired from the lowest bidder. Ditto for backend storage. This is one of the reasons why initiatives like VCE are important. A cloud provider offering services on known and trusted hardware is important to many decision makers. Sure you may pay a little more for the service, but for many IT decision makers, that’s OK. SLAs are only as good as a provider’s capability to honor them. Without knowledge of the provider’s infrastructure, you may be rolling the dice. Take the recent HostV failure as an example. While phrases such as “All you need to worry about is the SLA” sound good in theory, today they’re simply not practical. If cloud providers truly want to enable services such as application bursting to cloud, then they need to provide interfaces that accept very specific infrastructure requirements. Open Virtualization Format (OVF) is the best option we have for importing VMs to foreign infrastructures, and it’s extensibility allows room for custom metadata today. So there’s really no reason why service providers can’t offer such capabilities today. Also, there’s no reason why a service provider shouldn’t be transparent about their physical and virtual infrastructure. If a provider isn’t offering the detail you need to feel comfortable, then move on. There are plenty to choose from.

The Cloud Mystery Machine: Metadata Standards

This post continues the discussion in my “The Cloud Mystery Machine” post.

Open Virtualization Format (OVF) is a good start for standardizing definitions for VM metadata; however, let’s not forget that today OVF is only used to import VMs to a proprietary virtual infrastructure, and has no use at runtime. That being said, if you move a workload to the cloud, do you know where it is? You may think “Why do I care?” Organizations concerned with issues such as data export restrictions and data privacy care. When using virtualization platforms in the cloud, some workloads will require the identification of the physical runtime location and physical data location. In addition, the location of the application execution in relation to other systems within the shared physical infrastructure is also important. An auditor should be able to collect such information via a standard query. Unfortunately, that’s not possible today. Today, thanks to OVF’s extensibility, it’s technically possible for a VM to communicate its security requirements to a service provider, although I have yet to see a cloud service provider use OVF in such a way.

Providing simple and industry recognized methods for identifying VM and data location in the cloud is a difficult problem to solve. Again, the question isn’t just about where, but also about the relationship to required isolation mechanisms, whether they be virtual or physical firewalls, isolated virtual or physical network segments, or isolated storage, for example. Of course, how the provider defines “isolated” is equally important.  Last year, I talked about the need for standardized cloud security models in this post. This is a difficult problem to solve, and that’s why all vendors that have a stake in cloud computing need to begin working on such standards today. And speaking of standards, unfortunately I doubt we’ll see an industry standard that addresses cloud infrastructure location and isolation issues anytime soon. Instead, I’m looking at vendor combinations such as VMware/EMC/RSA or Microsoft/Citrix/HP to deliver solutions that emerge as de facto standards in the coming years.

The Cloud Mystery Machine: Licensing

This post continues the discussion in my “The Cloud Mystery Machine” post.

Cloud computing and hardware infrastructure as a service (HIaaS), in theory, should allow organizations to move workloads to the cloud and manage licensing just as they always have with managed hosting services in the physical world. However, the problem with current licensing models such as Microsoft’s Service Provider Licensing Agreement (SPLA) is that they require licenses to be bound to physical hardware. Physical hardware bindings removes the capability of IT organizations to manage licenses when they have no idea of the hardware on which their applications reside (it may change from day-to-day). So far, service providers have dealt with the licensing issue by building licensing costs into their service fees. In other words, you need to tell the service provider your application needs and the provider must manage licensing compliance on your behalf. If you want to take your already-purchased Microsoft licenses to the cloud, you’ll need to lease dedicated physical hardware from the service provider.

Asking service providers to take on license management for thousands of applications is impractical and is one more barrier to public cloud infrastructure adoption. Some service providers may support a few dozen applications today, but many organizations have thousands of applications. 2010 marks a year where Microsoft can show industry leadership and change licensing so that application license management is transferred from the service provider to the end user organization. The SP provides the virtual infrastructure, the organization uses it. Application licensing based on concurrency or user seats has always been infrastructure agnostic. Heck, Microsoft already has a similar model with its Client Access License (CAL). All that’s needed is to remove the physical binding requirement for application server licenses. As I’ve said before, we are moving away from device-centric computing. We’re shifting away from hardware as the definition for a user’s working environment, and that includes both client and server applications. It’s time the major players in the enterprise application market evolve their licensing policies to meet the agility requirements of today’s enterprise.

The Cloud Mystery Machine: The Need for an Infrastructure Authority

This post continues the discussion in my “The Cloud Mystery Machine” post.

Private cloud is a key 2010 objective for many Burton Group clients. However, our clients are consistently frustrated by the difficulties of on-demand service and mobility in virtualized environments. Until we get closer to having a virtual infrastructure center of the universe, these problems will persist. For example, suppose you setup soft security zoning using VMware’s vShield Zones. Does your third party orchestration product consider zoning restrictions prior to moving a VM to a particular server? Considering that VMware’s own Distributed Resource Scheduler (DRS) service doesn’t have such capabilities, it’s unlikely that any third party tool will either. In fairness, VMware hasn’t exposed such features through their SDK, so its unfair to ask vendors to support something in which they have little control.

When it comes to orchestration, everything falls apart without a central metadata store. Call it an infrastructure authority (IA), or whatever you like. The bottom line is that if a tool wants to place an object somewhere within a cloud infrastructure, there needs to be a central place where it can check to make sure the physical location offers the necessary resources (compute, memory, networking and storage I/O) and security policy isn’t violated in the process, among other concerns. We don’t need to re-invent the wheel. Instead, we need to take existing virtual infrastructure management databases and evolve them so that they can act as the central authority for all infrastructure decisions. Microsoft’s System Center suite of products already supports some extensibility and third party integration. VMware’s Virtual Center (VC) supports third party plug-in integration, but extensibility is taboo. If the VC database was extensible, issues such as downstream storage I/O would factor into VM placement decisions today. Virtual Instruments, for example, has the technology to do it, but their hands are tied. I’m hopeful that the infrastructure authority is something that VMware and Microsoft can lead in 2010. No vendor can own the universe. How many have to try and fail to prove it doesn’t work? Server hardware vendors acting as though each enterprise infrastructure should be homogeneous is a perfect example. VMware, Microsoft, Citrix, and other members of the virtualization community need to get serious about the complexities of managing an increasingly agile infrastructure, and give their software partners the APIs and meta database extensibility they need to fuel innovation.

In the end, the IA may not comprise just a single vendor solution, but involve collaboration from multiple vendors on what may emerge as one or more de facto standards. Many technical (e.g., CPU, memory, network, and storage requirements) and non-technical (e.g., security, location, organizational policy, and SLA) requirements determine the feasibility for VM mobility and placement. In my opinion, enterprises will continue to lack confidence in true virtual infrastructure/private cloud self-service and automation until we have some type of centralized infrastructure authority. What do you think?

Cisco is fastest - Not!

While scanning through my RSS feeds last night (yes, I know, I need a life :-) I came across a block from Cisco titled:

VMware’s VMMark Benchmark: Number One Position for UCS on Intel Xeon for 8 Core 2 Socket Systems

My interest was peaked, so I went and read the blog. I can’t say I was impressed, first and foremost, because the claim simply isn’t true. The UCS result is actually the second fastest result for an 8-core, 2-socket system, here’s a snapshot of the top four results:

I asked Cisco why they’d made the clearly incorrect claim, and the response was that they were ignoring the Fujitsu result because the RX300 S4 used an Intel XEON W5590, which Intel primarily markets as a workstation processor. I don’t buy that, the only differences between the W5590 and the X5570 (which Cisco used) are:

• Clock speed – the 5590 clocks in at 3.33 GHz, vs.. 2.93 GHz for the 5570.
• Power consumption – the 5590 has a TDP of 130 watts compared to the 5570 at 95 watts.

In all other aspects, the two processors are identical. If you want further confirmation that the RX300 is a server, a quick glance at its web page should make the point.

Unfortunately, the nature of the VMmark benchmark means that the real Cisco advantages are invisible. What you should care about as a consumer is that the Fujitsu system delivers roughly 0.4% greater performance using a substantially more power hungry and expensive processor. Unfortunately, since VMmark doesn’t capture price or power consumption data you’ll have to work that out for yourself!

There are two other points that are worth noting:

1. All the Xeon 55xx numbers are within a few percentage points of each other, so performance wise there is little to choose between the vendors (at least on this benchmark.)
2. Bumping the CPU speed up by almost 14% (2.93 to 3.3 GHz) yielded a whopping 0.4% performance gain! That lack of improvement suggests strongly, that the benchmark is not CPU-bound, it’s either I/O-bound, memory bandwidth-bound, or both.

We’ll find out whether the benchmark is sensitive to memory bandwidth later this year, when AMD ships a dual socket processor with four DDR3 memory channels instead of three.

Posted by: Nik Simpson

Desktop Virtualization Performance Testing

Citrix released their latest XenDesktop single server scalability test results today; showing a dual socket Intel Xeon x5570 (Nehalem) server with 72GB RAM running 130 Windows XP VMs per host. This is a significant improvement on Citrix’s previously published results, and certainly enough to bring it back into line with results VMware previously published. 

More important than the results though is the test methodology that Citrix has adopted this time around.

For the past year I have been trying to encourage desktop virtualization vendors to adopt a standard testing methodology for virtual desktop workloads and I am very happy to be able to say that it looks like Citrix has come into line with my way of thinking. Rather than relying on an in-house developed test, Citrix have adopted Login VSI 2.0 from Log•in Consultants as the core of their testing process. Login VSI is a specifically designed benchmark for server-based computing and desktop virtualization environments. You may know it better as part of Project Virtual Reality Check the joint project by Log•in Consultants and PQR. Project VRC is the only fully independent benchmark of desktop virtualization workloads running on diverse physical and virtual platforms. By establishing themselves as trustworthy independent subject matter experts, the Project VRC team has benefited not just their customers but a global audience of IT organizations who can take advantage of the research performed under the Project VRC banner. Even more importantly the breadth and quality of information presented through Project VRC is acting to improve the quality and credibility of all server hosted desktop virtualization vendor issued performance benchmarks.

Now that Citrix have seen the light, I hope that all server hosted desktop virtualization vendors will follow suit and adopt Login VSI as their testing benchmark. Anyone who doesn’t should not be surprised if their performance data is called into question.