At VMworld, we’re announcing our Native Hybrid Cloud (which quietly had it’s 1.0 GA earlier this year – time for us to continue to work out kinks). Version 1.1 will GA at the end of September.
What is the Native Hybrid Cloud (NHC)? Well – NHC starts with the DEVELOPER.
Let me make this contrast stark:
In the classic Scott Pilgrim vs. the World – in the climax, Scott encounters Nega Scott – his inverse doppleganger. NHC is to EHC as Nega Scott is to Scott. A strange reference, sure – but too perfect to not use :-)
It’s important to understand that this is a fundamentally different use case than infrastructure automation and “classic app” Enterprise IaaS (aka the target of the Enterprise Hybrid Cloud offering which is at version 4.0 – more on that here).
Developers don’t care about backups, or DR, or any of the infrastructure policy and implementation. They just care about their apps. Can they develop faster? Can they develop better? Can they do it using the tools, platforms and methods they like? How does that app perform?
Furthermore – tools that enforce cloud native app principles as a simple OUTCOME of using a structure, opinionated PaaS like Cloud Foundry accelerate creating apps that are elastic, and completely cloud portable – PERIOD.
It’s not that IT operations doesn’t matter, but they are not the target audience. Also, you can of course deploy Pivotal Cloud Foundry on vSphere (including VxRail) vanilla, or on EHC, or on AWS, Openstack – heck, almost anything.
What we’ve found however, is that customers want a simple button for PCF. They want something that bridges the Develop and IT Operations audience.
Again… the Native Hybrid Cloud and Enterprise Hybrid Cloud are the “Nega Scott” and “Scott” – similar idea, but inverted.
The Native Hybrid Cloud starts with the DEVELOPERS.
.
In a nutshell, the purpose in life for NHC is simple:
- Q: WHAT? A: NHC is the simplest, fastest way for developers to accelerate using Pivotal Cloud Foundry/SpringBoot, while bringing the IT operations people along for the journey.
- Q: HOW? A: By building a turnkey, opinionated platform from top (PCF) to bottom (IaaS and physical HCI). Jointly engineered with Pivotal, VMware and EMC. Delivered on Hyper-Converged Infrastructure. Supported and sustained by a single party.
Forget the talk… Check out the demo!
NHC can be deployed on VxRail (start small, VMware-oriented IaaS layer), and on VxRack Neutrino with Openstack KVM (start bigger, all open source IaaS). In the near future – we will make NHC available in a turnkey fashion on top of VxRack Neutrino using Photon Platform.
Regardless – in each case, because it ENFORCES cloud native principles (because of opinionated PCF use), all 3 are completely hybridized, and can leverage AWS, Azure, Virtustream in addition to the on premise HCI.
To get an idea of how far we’ve taken this idea – NHC pricing, in fact the whole economic model of NHC is build not around licenses, or infrastructure – but the number of Application Instances you are targeting.
Now – customers we’ve brought this idea to have been super-pumped – for ease-of, for simple “day 2” operations – but as much as anything else – that it brings the IT operations team along for the journey.
A simple, integrated set of dashboards that show health, performance, chargeback, etc – and all, critically, mapped into the context of the apps, as well as the CF stack elements.
BTW – not every customers will want that opinionated, that tightly integrated a technology stack that NHC represents. Some, that want just PCF on VxRail – think of that as a “reduced risk, accelerated” but a “build it yourself” way. NHC is at the other end of the extreme – extremely opinionated, extremely outcome oriented.
The demand for NHC has been… well… OVERWHELMING.
Many customers on their Cloud Native app journey have spend a lot of time building – only to find little progress on what matters – happy developers. Yes you have the whole “build” ecosystem here, from PCF on vSphere/VIC/VIO to OpenStack/KVM distros, to trying to leverage Docker/Swarm (or the commercial Docker Datacenter stack), to Mesos/Marathon, to Kubernetes… each with home brew microservices catalogs.
We contribute to these ecosystems – and we believe there are customers that can, will, should optimize their whole stack around optimizations of a “custom” PaaS.
That said – we have a point of view: don’t waste time building things that don’t make your developers go faster, enforces structured approaches to code that in turn enforce cloud native principles – instead, choose “easy”. Choose CF, and if you want the easiest route – choose PCF via NHC.
Comments