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.

You might be interested in our initiative to bring cost awareness and quality service right up into the application runtime stacks abstracting the concept of a resource to something more more that networking queues using a metering engine that is based on activity based costing where cost can be latency, liability, leasing….

I know high-grade B.S. when I see it. This is corporate techno-speak B.S. It takes up a page instead of a short paragraph. Look, dude, this is about uploading and downloading a lot of stuff fast and reliably. When you figure out how to do it, or who is doing it in a first-rate way, get back to us. Otherwise save the electrons.