Cloud Computing: June 2009 Archives

by Chris Richter, Vice President of Security Services

In just the last few months there have been scores of articles written about the security risks of cloud computing in enterprise data centers. With a broad brush, commentaries have painted cloud computing environments as insecure infrastructures where tenants can more easily view other tenants' data, and even hack into their virtual servers, launching attacks on neighboring virtual machines without the victim knowing. One writer compared cloud computing environments to a multi-tenant office building where thieves can break through walls and steal content from the other side. Such views are fomenting a general perception that cloud computing is synonymous with high security risk. While some of these concerns are well founded, many are not. I believe the generally negative opinion about cloud computing security is based on the belief that all cloud computing environments are created equal. They are not.

There seems to be as many definitions of cloud computing as there are blogs about this subject. Ultimately, what cloud computing comes down to is the architecture and processes supporting the provider's infrastructure. All cloud infrastructures are located in one or more physical data centers which host various forms of server virtualization, networking and storage systems deployed in a myriad of ways. Some cloud providers tie in services from third-parties to build a "community" of services that are delivered in the cloud. But the differences between providers lie in the practices governing how these systems are deployed, configured, and managed, all of which can also vary greatly. The same basic principals of data security that apply to dedicated infrastructures must also apply to cloud computing environments. If the IT environment is not properly architected and managed, security risks will abound.

While I would still argue that most cloud infrastructures are far more secure than most of the dedicated environments in existence, I am not suggesting that enterprises select a provider without proper due diligence. Providers should demonstrate the "guts" of their environment. At the very least they should be willing to share details regarding:

• How their virtual machines are segmented from those of other customers
• How their data is isolated and handled, both at rest and in motion
• Who has access to the network, security and server/hypervisor management components
• Standard and optional security controls
• Overall architecture of the service provider's cloud computing infrastructure
• Level to which the service provider works with the technology vendors whose products make up the environment
• Who those technology vendors are
• General practices used in the provisioning and management of components within the provider' infrastructure, including but not limited to patch management, change control, and monitoring

Without adequate transparency about how service providers help their customers manage IT security risks, the perception that all cloud computing environments are plagued with inherent security issues will persist. We, as an industry, can change that to ensure that enterprises no longer view security as an obstacle to embracing cloud computing.

by Bryan Doerr, Chief Technology Officer

There exists, as I have previously noted, sufficient motivation for more advanced resource controls in IT infrastructure components. But while there are encouraging indications that component manufacturers are responding to this need, we have some distance yet to travel.

Horizontal aggregation

As we consider infrastructure components, we know that the physical and virtual worlds can diverge. This divergence gives us a chance to create new physical devices optimized for scale and equipped with more granular resource management functions, while preserving in virtual form the existing industry abstractions. Put a different way, the IT industry has an opportunity to rethink its physical deployment building blocks and, in the process, insert a new level of QoS control in the environments built with these components. Some vendors are already seizing this opportunity.

I'm excited to see the development of products and protocols on the part of Cisco and HP meant to address some of these needs. These new devices share common characteristics -- they have high levels of integrated functionality provided efficiently at scale with management software designed to independently operate in the virtual and the physical worlds. These are good first steps toward the types of devices that will be the heart of the next-generation data center, where more of the enterprise data center role shifts to that of service provider in multitenant environments.

In building these new devices, the old physical device boundaries are being redrawn. For example, Cisco's Unified Computing System UCS integrates server and switching functions and also reallocates the functions of each to achieve better economics. This form of "horizontal aggregation" will be common in the IT components of the future.

The stacker

New systems won't be only horizontally aggregated. They will be vertically aggregated, too, as software building block boundaries are also revisited. Database server, application server, and web server software can be combined with hardware, creating a new IT device ready for application integration. Oracle has started discussing these types of systems as a result of its proposed acquisition of Sun Microsystems. Other major consolidations could follow. The result may yield a new competitive landscape in IT components, where the old world of interoperable software stack components and general purpose servers and operating systems that support them (and all of the associated compatibility and integration complexity) gives way to the "stacker" -- a completely integrated application deployment platform component with sufficient resource capacity. The stacker supports several complete instances of virtualized application stacks and associated internal and external network in one physical device.

It is into this evolving physical landscape that we want to incorporate more complete QoS controls, thereby enabling enterprise-grade, multitenant cloud services. To accomplish this goal, the focus needs to be on both hardware and software resources. The stacker must support end-to-end QoS controls by preserving customer context, priority, and policy through all logical and physical resource dependencies, including required threads, memory, queuing, and concurrency controls to truly support multitenancy. The efficacy of this entire path affects the performance of the application from an end user perspective and thus must be assured.

As more and more enterprises seek to optimize their IT infrastructure spend, the challenge before IT industry infrastructure component manufacturers is to enable the service provider to deliver true shared environment economics for a wide range of enterprise applications. This will be achieved not just through large-scale systems, but through the continued enhancement of QoS controls that govern both the hardware and software resources in these environments.

The opportunity is now. The evolution of existing IT components toward the stacker and the separation of virtual and physical design forces provides the opportunity to incorporate these controls into the building blocks of the future service provider cloud. I'd like to see the industry accelerate efforts to harden and standardize newly emerging concepts and protocols in these areas.

This is the third post in a 3-part series. Please also see Part 1, Cloud Computing: A System of Control, and Part 2, Cloud Computing: Building Blocks for the Enterprise.

This post first appeared on Gigaom.com http://gigaom.com/2009/05/31/cloud-computing-enter-the-%e2%80%9cstacker/ as part of Structure 09 speaker series. Bryan Doerr is a featured speaker at Structure 09 conference http://events.gigaom.com/structure/09/?a=h300x60, scheduled to be held on June 25, 2009 in San Francisco.

by Bryan Doerr, Chief Technology Officer

When we consider cloud services -- and the apparent lack of significant quality of service (QoS) control in them -- we must also consider the relationship between QoS and capacity. Specifically, with sufficient capacity, do we even care about QoS controls?

Is it a question of resources?

For as long as we have been building computing systems, we've been see-sawing between the poles of plentiful and constrained resources. When resources are plentiful, we develop new abstractions to encapsulate design changes, increase reuse and improve user experience. These new approaches invariably consume more resources than the approaches they replace. And what good is capacity if you don't use it? During these times, QoS controls seem like an engineering extravagance involving needless complexity. The consequence of ignoring QoS resource limitations is predictable -- plentiful resources eventually become constrained resources and another round of capacity increases is desired.

During constrained resource times, we get more particular about how we want our systems to operate and attempt to introduce concepts, such as priority, scheduling, pre-emption and queuing, to achieve specific behaviors. Within a single application, one can usually design the appropriate behavior into the application itself if specific platform or framework controls are lacking. As we move to sharing resources within a single governance environment (such as the typical enterprise operating a virtualized infrastructure), this type of "application-level QoS" approach usually doesn't work as well and platform-level controls are desired. Even when these are lacking, however, management oversight and shared goals motivate all involved to work together to design acceptable cooperative resource partitioning, often with good results.

Interestingly, we can't generalize this QoS approach to cloud services. If we look at true multitenant clouds, assuring enterprises of the presence of resource controls in shared platforms is desirable whether resources are plentiful or not. Put another way, big clouds with a lot of capacity don't automatically assure acceptable application performance. Enterprises want resource guarantees for some applications, the presence of which assures consistent performance independent of the activities of other tenants in the environment.

So yes, we do require QoS controls in our application infrastructures, regardless of the level of resource contention, when delivering services in multitenant environments. With QoS controls available, cloud providers can offer a range of services and price points that provide more choice to customers and back these services with service-level agreements (SLAs) that go beyond uptime and mean time to repair (MTTR) specifications. The result for enterprises is lower-cost IT infrastructure, applicable to a greater range of application types, obtained by combining shared platform economics with high levels of performance assurance.

The right building blocks?

For years, the IT industry has been optimizing its IT hardware designs for deployments aimed at the typical enterprise application, specifically applications with dedicated infrastructure. In these deployments, established boundaries exist around common functions, such as switches, routers, servers, and storage arrays and many suppliers have emerged to compete in these respective product component categories. We have developed integration standards to ensure that these products can work together. At this point, the components of IT infrastructure for dedicated application infrastructure are mature.

But are these the right building blocks systems for the next generation of IT applications, especially when there is a high probability that these applications will be hosted in virtualized, multitenant cloud environments? There is no question that the abstractions are useful and should remain, i.e., a "server," "firewall" and "switch" are good encapsulations of recurring deployment functions, but in many cases QoS controls are insufficient or missing. In my third and final post of this series, I'll discuss market forces and vendor activities combining to bring another level of control to the cloud and speculate on what this might mean for the next generation of IT components.

This is Part 2 of a 3-part series. Please also see Part 1, Cloud Computing: A System of Control. The third and final post will run tomorrow.

by Bryan Doerr, Chief Technology Officer

I've come to think of cloud computing as a system of control. The reference to the line in "The Matrix" aside, there is a reason to discuss the role of systems and the notion of control in emerging IT infrastructure and services. That reason is to motivate the development of IT equipment capable of supporting a new generation of application deployment. To do that, we must first revisit some design assumptions of our common IT building blocks and create some changes in the way we think and deploy IT today.

As we reflect on the evolution of IT in the global enterprise, IT-based differentiation is clearly fueling business growth across industries and forming new industries. IT benefits also clearly come with considerable cost. Reducing these costs by creating options for deploying applications is the spirit motivating the move toward cloud computing. Contrary to some descriptions, however, cloud computing isn't cheap computing; it is the delivery of more control to enterprises so they can deliver IT services more affordably and efficiently. The difference between these two statements is important -- one focuses on the underlying cost of a service, while the other focuses on the use of a service to reduce cost and enhance business value. Gartner analyst Lydia Leong recently observed on her blog:

The primary cost savings for cloud infrastructure does not come in the savings on the hard assets...Changing capex to opex, and taking advantage of the greater purchasing power of a cloud provider, can and will drive significant financial benefits for small to midsize IT organizations that use the cloud.

The customer control inherent in cloud services, coupled with new approaches to develop and deploy applications, can transform an enterprise significantly. Cloud-based services enable enterprises to adapt their spending to the application's value and to adjust these decisions continually over time. In today's cloud offerings, enterprises can purchase application, platform or infrastructure services based on this more flexible paradigm. By embedding more flexibility in service deployments, cloud services can increase control of IT costs in ways not previously available. I refer to this new control paradigm as "deployment control," by which I mean the active management of IT capacity aligned with application value using the features of cloud services.

Conversely, cloud services can also take away a form of control. Enterprises have traditionally owned and operated their own infrastructure and applications. (Even licensed applications were at least operated by the enterprise.) This lifecycle ownership came with a high level of control related to resource assignment (collectively called quality-of-service, or QoS, control). Applications running in dedicated infrastructures benefit from the highest levels of resource control. The move toward shared service platforms -- a basic tenant of all cloud service types -- reduces the exclusivity and, hence, enterprise control of the delivered service. Many enterprises view the loss of this form of control as risky, which may impede adoption of these cloud services.

A deeper review of cloud service control attributes reveals the risks are changing as the technology matures. In particular, the adoption of shared service platforms and the benefits of increased deployment control does not necessarily require the loss of QoS control. At the heart of this issue is the way cloud services are built and requires us to re-examine the old debate of capacity vs. fine-grained resource management. My next post will talk more about why now is the time for us to consider IT systems, how they are built today, and how they might be built to enhance benefits and reduce risks to enterprises.

This is Part 1 of a 3-part series. The second post will run tomorrow; the third, the day after that.