Many hyperscalers take an “outside in” approach to delivering private cloud infrastructure, tightly tethering it to the mothership. But is that really what’s best for the customer?
It doesn’t matter what research report you read, we’re all moving workloads to the public cloud. And the reasons are pretty clear. That combination of immediacy of resource, agility and elasticity in service provision and a completely “hands off approach” to the care and feeding of the complex underlying infrastructure all makes for a compelling case.
It’s no surprise then, that when larger organisations come to the conclusion, as research suggests the vast majority do, that they have some workloads that aren’t (for a variety of reasons I dig into here) right for shifting off-site, they consider solutions like AWS Outposts and Microsoft AzureStack Hub.
The proposition is seductive.
Your chosen hypescaler will deliver to goods-in at your data centre (or co-lo facility) a pre-configured appliance or rack scale “slice” of their cloud, to place in your data centre but that they will manage for you. You get that “day one” immediacy of instant cloud resources, but you don’t get that “day two” headache of trying to lifecycle manage the complex array of hardware and software it would otherwise take you to try and replicate something similar yourself.
Of course, there’s a catch.
Your private cloud, rather than being a core part of your own IT infrastructure is, as the name suggests, merely an outpost of your chosen public cloud instance. You’re essentially bringing the outside public cloud world “in” to your world. That outpost is still, in effect, part of your public cloud service and is inextricably linked to that cloud, and only that single cloud. And the link cannot be severed, either temporarily or permanently.
In itself you (and maybe your regulators, your CSO, CIO etc.) may be OK with this. Maybe you are in the 10-15% of organisations that only work with one hyperscaler, and so the multi-cloud problem of having multiple “outposts” in your data centre from different cloud vendors is not an issue. And the limitation of that always-on “spoke and hub” configuration that must be maintained in order for the outpost to operate is not a limitation or a risk if there’s a connectivity or public cloud service outage.
Surely there’s a better way?
We believed so, and that’s the genesis of HyperCloud. By taking an “inside out” (and ground up) approach to building private clouds we’ve been able to preserve all that’s great about the public cloud experience, but deliver it in a way that’s on your terms and quite literally on your turf.
Instead of losing the “day one” immediacy and “day two” simplicity of tethering your private cloud to a public cloud, we designed a unique architecture to instead solve those infrastructure ownership challenges of adds, moves and changes deep in the technology.
HyperCloud worries about it so you don’t have to.
Instead of that “always on spoke and hub” model, you are free to architect your HyperCloud based private cloud in the way that you choose – placing cloud compute and storage infrastructure anywhere that makes sense in your owned or co-lo real estate, and to then grow, flex and re-deploy it independently and theoretically, limitlessly. And that always-on issue? With HyperCloud you can federate between your cloud instances, burst to public clouds or run them completely disconnected. It’s your choice.
Instead of being tied to a single public cloud, you can manage your relationship with the hyperscalers from within your own private cloud – shifting the power balance in your favour and enabling multi cloud configurations without requiring duplicate hardware. The best of all worlds.
And it’s not just about who owns and runs the hardware.
Ground to Cloud
The idea of building a “ground to cloud” strategy is one that is increasingly gaining traction in the industry. By building a true cloud-native environment on premise, you are also able to apply stricter controls on the environment within which apps are architected and/or deployed and the way in which data is stored and protected. In doing so you are then able to preserve the right level of application and data portability between different clouds, whether that be for technical or commercial reasons – truly delivering a multi-cloud strategy.
And lastly, if the reason you kept your workloads on prem. was about privacy and/or security, remember with HyperCloud you own and run your own infrastructure, backed by SoftIron’s unique secure provenance capability.
Your private cloud shouldn’t be a second class citizen or servant to the hyperscalers. Architected correctly it can help you regain some balance in your relationship with them.
