Google, Facebook and Amazon are often held up as examples of businesses that deploy hyper-converged architectures. If they can do it, and do it so well, then surely lots of other organisations should sit up and take notice of what hyper-converged platforms can do. This would be great, apart from the fact that none of their architectures mirror hyper-converged. They are web-scale companies. Does that mean people shouldn’t consider hyper-converged architectures? No. It’s simply a reminder that you need to find an architecture that suits your specific needs.
Here’s the thing: unless you’re a company trying to achieve the scale of Facebook or Google, web-scale probably won’t work for your environment anyway.
A closer look at the differences
Let’s take a closer look at some of the major architectural factors that differentiate hyper-converged systems from web-scale deployments.
First, consider the layer of abstraction—hardware vs. software. Hyper-converged systems use virtual disks over SCSI or SATA to provide a reliable hardware abstraction by replicating between machines. The reliable hardware layer sits underneath the application software. Storage and compute is consolidated on the same machines. The environment is designed to be free of custom hardware and for software and hardware to be decoupled.
By contrast, web-scale deployments rely on software abstractions because hardware abstractions that impose strong consistency requirements are extremely difficult to scale. Software abstractions can be tuned for a specific workload with reduced consistency and scale while retaining performance and availability. And while web-scale vendors might combine compute and storage for given services, they usually divide applications into micro-services that are separated by the network.
A second point of difference is the use of commodity vs. customised hardware. Hyper-converged infrastructure makes a virtue of commodity hardware but web-scale companies normally rely on custom built or heavily customised appliances. They match custom appliances to very specific application needs. It takes a web-scale company to make this customisation financially feasible, because Google, Facebook and Amazon build for applications at massive scale.
Finally, there is the coupling vs. de-coupling of hardware and software. Web-scale companies build hardware, infrastructure and application software designed purely for use in their environment. Tightly integrating the hardware and software can be an expensive approach for companies without huge scale, but it helps to simplify software and hardware management at companies that can realise those economies. By contrast, hyper-converged vendors decouple the infrastructure software from the hardware beneath it and the application software from the virtualisation infrastructure.
What does it mean for you?
As we have seen, web-scale infrastructure relies on a heavy amount of customisation. It uses custom software abstractions provided by applications for scale. Web-scale companies use custom hardware despite the initial development costs. Hardware, infrastructure and applications are heavily coupled and customised for their environment.
Hyper-converged architectures are very different. They are built on commodity hardware and while storage and compute live on the same device, there is a strong separation between software and hardware.
So which is best for you? If you’re not operating at the scale of Google, Facebook or Amazon, you likely have very different needs. Systems designed for large-scale environments won’t work in small organisations and vice versa. The system you choose needs to fit the task, be efficient and cost-effective. For many organisations, web-scale infrastructure can fail on all three measures. Similarly, hyper-converged often cannot scale to meet the needs of highly virtualised enterprises.
If you’re looking for a solution that will simplify storage you might need to explore new ground—for example, VM-aware storage. Not sure what that is? Google it.