Bare Metal Clouds – Performance and Isolation Drive Consideration
I’ve been talking to a number of users and providers of bare-metal cloud services, and am finding the common threads among the high-profile use cases both interesting individually and starting to connect some dots in terms of common use cases for these service providers who provide the ability to provision and use dedicated physical servers with very similar semantics to the common VM IaaS cloud – servers that can be instantiated at will in the cloud, provisioned with a variety of OS images, be connected to storage and run applications. The differentiation for the customers is in behavior of the resulting images:
- Deterministic performance – Your workload is running on a dedicated resource, so there is no question of any “noisy neighbor” problem, or even of sharing resources with otherwise well-behaved neighbors.
- Extreme low latency – Like it or not, VMs, even lightweight ones, impose some level of additional latency compared to bare-metal OS images. Where this latency is a factor, bare-metal clouds offer a differentiated alternative.
- Raw performance – Under the right conditions, a single bare-metal server can process more work than a collection of VMs, even when their nominal aggregate performance is similar. Benchmarking is always tricky, but several of the bare metal cloud vendors can show some impressive comparative benchmarks to prospective customers.
So why use a bare-metal cloud if you are going to end up running your workloads on dedicated physical servers? The pressures that drive workloads to bare-metal clouds are in essence the same ones that push virtualized workloads to clouds, dominated by two factors:
- Agility – The bare-metal cloud vendor maintains a vast (in relation to any single customer’s requirement) inventory of servers, just waiting to be called forth, presenting exactly the same metaphor of unlimited capacity as a VM IaaS cloud. Behind the scenes the CSP is working like mad to provision and manage their capacity, but that’s not visible to the end user.
- Network data locality – Many emerging customer-facing applications, especially those driven by mobile device access, require the extreme low-latency access to major data feeds that only a large CSP with special network connections can provide.
What are the workloads? We’re seeing a mix of the same workloads that people put into VM-based clouds, but the use cases are dominated by what could best be described as time-bounded transactions, where there is an externally imposed window within which a transaction must occur, such as credit card validations, advertising placement, or other high-volume transaction. As providers of these services strive for differentiation, one of the emerging levers they can manipulate is the amount of compute that they can perform during this bounded interval, and one of the “tricks” that can be applied is to slice any processing latency to the bone by using a bare-metal cloud as the execution platform. We’ve seen numerous cases of these kind of bounded transactional applications running on bare-metal clouds, and will be spending more time investigating this interesting ecosystem of suppliers and workloads in the future.
Today there are a relatively limited number of players in the market, including IBM SoftLayer, Internap and OVH, to name a few, but we expect the roster to increase as the benefits of this solution become more widely recognized.