Posts Tagged Cloud

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.

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 to a white box server with memory acquired from the lowest bidder. Ditto for back end 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.

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.

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?