There is a growing movement to abstract hardware completely away, as we have discussed previously. Docker with SocketPlane and other application virtualization technologies are abstracting hardware away from the developer. Or are they? The hardware is not an issue, that is, until it becomes one. Virtualization may require specific versions of hardware, but these are commonplace components. Advanced security requires other bits of hardware, and those are uncommon; many servers do not ship with some of this necessary hardware. Older hardware may not deliver the chipset features needed to do security well. This doesn’t mean it can’t be done, but the overhead is greater. Hardware is dead to some, but not to others. This dichotomy drives decisions when buying systems for clouds or other virtual environments of any size. The hardware does not matter, until it does!

This is the failing of many an architecture: many people are so concerned with containerization that they miss the hardware requirements. People want security, so they use encryption without thinking about the hardware requirements. These items seem disjointed, but they share a common antecedent: the hardware. Let us think about this one some more:

Encryption Needs Hardware

Encryption needs hardware—specifically, hardware acceleration gained by using the AESNI chipset features within modern Intel processors. Without AESNI, encryption can exceed 38% of total CPU usage within a virtual machine. With AESNI, the CPU overhead drops to 2% or less. In addition, to do encryption well, uniquely generated keys are needed. These can be generated using a hardware security module (HSM), as is done within the Amazon Web Services cloud, or by exposing the DRNG via the RDRAND/RDSEED instructions. Both of these systems provide truly random data, not pseudo-random or normalized data. The more “randomness” that exists in the system, the less chance there is of encryption keys being broken. However, RDRAND is only available in modern Ivy Bridge hardware, and RDSEED will only be available in the yet-to-be-released Broadwell chipsets. Nevertheless, random numbers can be generated today with a cryptographically safe method using an HSM. Even more interesting, Intel’s upcoming Software Guard Extensions (SGX) look like they may change the entire picture.
SGX provides an encrypted enclave on chip to hold encryption keys and the like. Doing so allows decryption to take place on the chip and not in-system or in virtual machine memory. The limitation to in-VM encryption is that the keys are also in memory. This is the flaw that allowed VMware Transparent Page Sharing to determine encryption keys present in the VM’s memory. With SGX, while the keys are in memory, they are in an encrypted enclave that can only be decrypted by the CPU. The enclave’s keys are not in memory accessible by the VM. This alleviates the main issue with in-VM encryption, which has been discussed for years. However, how to pass this enclave via vMotion or live migration is still up for debate, since it is CPU-specific. But now the basics exist within the hardware.
The only way to take advantage of these performance and security improvements is to have them exposed to the virtual machines running within clouds and on-premises. But to do so means you have to worry about the hardware once more. Granted, if you are not security conscious and perhaps live under a rock, given all the current breaches, then you do not need the power of these new hardware modifications.
However, given the number of high-profile breaches that a little encryption could have prevented, it is worthwhile to have the hardware to do the trick and to do it with great performance, better randomness, and better security.

Performance Needs Hardware

As chipsets improve, they begin to offload increasing functionality into the CPU. We started with math coprocessors, and today we have technology that speeds up not only mathematics but complex, repeatable operations, which improves performance and simplifies our lives. What really helps now is the influx of memory and other CPU features that enable any CPU in a multi-CPU system to access the memory of any other CPU quickly and with only a minimum hit to performance. This technology also includes things like NUMAlink from SGI (previously Cray), which reduces latency when accessing CPUs in other boxes within the cluster.
We need hardware to improve storage performance, in the form of specialized offload host bus adapters, more memory, or faster memory, or in the form of solid state drives that require specific host bus adapters (SCSI HBAs) to perform optimally. In order to take advantage of PernixData, VMware VSAN, and other SSD-based storage caching solutions, the first thing to inspect is not the type or size of SSD, but whether or not the SCSI HBA will actually support SSD properly. This is why each company that sells hardware-based caching software also has a hardware compatibility list. Companies like Atlantis Computing and Infinio, on the other hand, just require the use of an increasing amount of memory to improve storage performance. There may be limits on the amount of memory you can place within older hardware. However, modern hardware has high enough limits that it is not a major issue anymore.
We need hardware to excel at application performance, and we need hardware to improve response time. In addition, the introduction of Intel-VT (and AMD RVI), Intel VT-d, and other technologies has allowed us to improve virtualization performance with just a hardware upgrade. Now we can easily add network adapters direct to VMs and gain all the performance of using native and perhaps specialized drivers.
Graphics Processing Units (GPUs) are the last batch of hardware to be virtualized, most recently with efforts by NVIDIA. I expect the others are working hard to catch up. GPUs improve the performance of many systems that rely on graphics algorithms to do processing. One clear winner is desktops. However, in order to use GPUs, you need to pay close attention to the hardware involved. The GPUs that can be virtualized are currently aircooled, which leads to bulky implementations. Heat becomes a major issue with GPUs in general, and with aircooled ones is even more so.
Once more, we have performance improvements that end up requiring specialized hardware to use.

Final Thoughts

In essence, we abstract the hardware, but we need the hardware to improve our applications. Without these and other hardware functions, large-scale virtualization today would not be here, and we would not have large-scale clouds, either. The hardware matters. As such, we should not ignore the hardware when we create our hybrid-cloud architectures. If you do, your results may vary greatly. In-use hardware and future hardware matters, and our solution choices depend on our choices of hardware.
How many of your architectures have a minimum hardware requirement? Do you even think about the hardware? If so, for what types of solutions does it matter the most: VDI, security, storage, networking, etc.?