The Cranky Admin
Hyperconverged Infrastructure as 'Cloud-In-A-Can'
A review of HyperCloud by HyperGrid.
I've recently had a chance to do a review of HyperCloud by HyperGrid, and ended up pleasantly surprised. I've been a strong advocate of the creation of Infrastructure Endgame Machines (IEMs) for a few years now, and HyperCloud is dangerously close to actually being one.
An IEM is essentially a hybrid cloud solution with a recipe-based workload creation mechanism, integrated monitoring and several other basic infrastructure features taken care of in an automated fashion. The whole idea of IEMs is to bring what the public cloud can do not only to customers, but to service providers, and actually make it easy to use.
Layer on some automation and orchestration of best practices and tools for dealing with workloads at scale, and you have a revolution in workload provisioning that is to the client/server model what the client/server model was to mainframes: a revolution.
What Is HyperCloud?
HyperCloud is the solution offered by HyperGrid. HyperGrid is the result of a merger between Hyperconverged Infrastructure (HCI) vendor Gridstore and DCHQ, a company that focused on workload migration (predominantly of Java applications) to the public cloud.
Prior to the transformation into HyperGrid, one could have been excused for having forgotten Gridstore existed. They were very much a "me too" HCI player, and one that -- for reasons incomprehensible -- focused exclusively on Hyper-V. Yes, there is a hard core of True Believers that want Microsoft on Microsoft with added Microsoft, but Hyper-V was never going to grow much beyond that niche, so Gridstore stalled out and faded away.
DCHQ made some quick friends as a cloud brokerage solution, especially among organizations with strong internal development teams that had already made the leap to DevOps and embraced continuous integration. Those who understood desired state configuration and knew how to use it quickly adopted DHCQ, but this too was a limited market.
Put the two together, however, and you have an HCI cloud-in-a-can that can spin up workloads on your local infrastructure, on a service provider or in the public cloud. It can speak Hyper-V (naturally), VMware, Openstack/KVM and all the major public cloud providers. It can integrate block storage, object storage, and uses a recipe engine with agents to deploy workloads, getting us one step closer to that desired state utopia.
Separately, Gridstore and DHCQ were also-rans. Together, they're a viable challenger to Microsoft's Azure Stack. That warrants serious consideration.
Initial Impressions
HyperCloud's UI reminds me enough of OpenNebula that I had to ask if they had forked the project or if this was a completely custom solution. It turns out that the whole thing is proprietary to HyperGrid, and any similarities are largely accidental. Still, I find the similarities comforting. Working with clouds is hard enough without having to relearn basic interface queues.
While I largely have nothing but praise for HyperCloud, two downsides stand out to me; one I can blame on HyperGrid and another I must blame on myself. The issue I must blame myself for is that I didn't easily grasp how HyperCloud was going about handling networking.
I am assured by hard-core networking nerds and those who are very used to working with public clouds that the HyperCloud networking makes sense. Being largely a virtualization administrator, however, I must admit I struggled to understand how to make it go. With luck, there can be a happy middle ground in the future that makes it easier for simpletons like myself.
The big problem for me -- the one I have to point back to HyperGrid and demand a fix for -- is that HyperCloud doesn't offer proper console access to virtual machines (VMs) or containers, not even for the on-premises Hyper-V, VMware or OpenStack/KVM VMs. They currently have something called the "DCHQ Terminal" which offers a very function-limited pseudo-terminal, but no full sub-operating-system, "tinker with the guts of the VM" console.
As a virtual administrator that still has "pet" workloads that can't all be scripted, managed with desired state tools and automated to the nines, this is a showstopper. Some workloads just need to be babied. To their credit, however, HyperGrid acknowledged that this is a missing feature in HyperCloud, and said that a proper console is something on their roadmap for inclusion in the next two months.
Those gripes aside, it's hard to find fault with HyperCloud. It does VMs, it does containers. HyperCloud has a library that comes complete with a wizard to walk you through the creation of apps, VMs and even clusters. The library comes with over 400 recipes (called Blueprints by HyperGrid), and the ability to create your own.
Available recipes include basic OS environments such as Ubuntu, CentOS and Windows, multi-app platforms like nginx + Tomcat + MySQL, and individual applications such as Wordpress. You'll also find some library solutions that feed back into the platform itself. HyperCloud's canonical example is a Minio library that, when deployed, offers up an object storage solution that can be consumed by the HyperCloud UI.
Plugins can be created to enhance the HyperCloud UI, and it includes a reasonably detailed reporting engine. HyperCloud includes modest policy capabilities, though they are admittedly nothing to write home about, and some standard LDAP-backed identity services. All in all, about what you'd expect from a production-ready cloud management solution.
Practically Speaking
HyperCloud is very strongly influenced by the features and capabilities of the big public clouds. Their approaches to problems and even their limitations are frequently reflected in HyperCloud's design. This makes HyperCloud very approachable to the new generation of cloud natives, but makes adoption by the world's existing virtualization admins something of a struggle.
HyperCloud shows a lot of potential. I can certainly see using this to run an individual organization, or a department's infrastructure. HyperCloud commands other infrastructure solutions, and thus can be used as a self-service adjunct to, for example, an on-premises VMware infrastructure, rather than necessitating an all-or-nothing abandonment of existing IT practices.
From what little I could discern from within the demo environment provided, HyperCloud has a lot of potential to scale up. The existing demo environment didn't consist of that many hosts, but the ability to talk to so many different public clouds, on-premises infrastructures and even to register third-party service providers of your choice indicates to me that HyperGrid envisions some pretty large deployments.
With that in mind, the lack of nested multitenancy is troubling. Other solutions -- most notably Yottabyte -- offer this feature, and it is a strong enabler for service providers (note: Yottabyte is a client of the author’s). Nested multitenancy is the ability for the root cloud owner (the service provider) to carve up resources into virtual datacenters for customers who then create nested virtual datacenters for their internal customers.
This would allow a company to, for example, rent a fixed amount of infrastructure that it could break up into sub-clouds based on department. Those sub-clouds would have their own administrators and their own users, and possibly even their own authentication systems, but all of it on one bill and with unified reporting and control by the customer.
HyperCloud isn't at nested multitenancy yet, but I expect it won't be long before they are. What they do offer is a solution which exposes a lot of nerd knobs, logging, timelines, error reporting and -- most importantly -- monitoring. A HyperCloud strength is that its designers were obsessed with making sure that everything was tracked, logged, monitored and integrated into alerts. That's as it should be; it's as all our datacenters should be.
Solid Product, With Room for Improvement
HyperCloud works. For the most part, it works quite well. Now the hard work begins: making HyperCloud traditional admin-friendly before the advantage gained over their competitors expires.
About the Author
Trevor Pott is a full-time nerd from Edmonton, Alberta, Canada. He splits his time between systems administration, technology writing, and consulting. As a consultant he helps Silicon Valley startups better understand systems administrators and how to sell to them.