EMC World 2016: Native Hybrid Cloud – A new platform for a new world

It makes getting up and running with Pivotal Cloud Foundry easy – orders of magnitude than using just the Pivotal Ops Manager (which NHC builds on).  Ops manager is great – but presumes that everything is “ready for it”.

• It makes the IT operations team the hero they want to be – connected to the developers, able to see/understand/automate/operationalize the infrastructure supporting the PCF stack in a way that links them to the developer.
• It makes the infrastructure elastic, easy, and integrated – NHC runs on top of VxRack System 1000 (bolting directly into VxRack Neutrino Node and VxRack Flexvariations) with vSphere, OpenStack and in the near future Photon Platform as the IaaS layer choices.

Q: How turnkey is “turnkey”?  A: NHC can be up and running in as few as 2 days.

NHC also doesn’t cost a lot for what you get. We’ve designed to start in an easy way, and scale like nothing else. NHC costs as little as $450K all in (PCF, the automation, the reporting, the abstraction IaaS layers, and the physical infrastructure itself).   It’s also super-automated – much lighter lift than getting EHC going (which invariably needs some material services)

Like everything we build in the Converged Platform division – we focus on platforms, not reference architectures. This our mantra and our goal for Vblock/VxBlock, VxRack, VxRail, the Enterprise Hybrid Cloud (EHC) and NHC. That means:

• Engineered as one. We always take a full “system stack” approach to design.
• Manufactured as one. We strive to always deliver the whole product with no on-site assembly.
• Managed as one. We aim to build the management and orchestration of the product as a single “thing”.   This is an area I’m focused on – we do OK, but can do even better.
• Supported as one.  We are maniacal on this – where we take not only first call, but all the way through up to the support demark.
• Sustained as one. We constantly treat the stack as a “product”, doing RCM (Release Certification Matrix) and ESSM (EMC Simple Support Matrix) updates for the stack.

This is NOT to say that Reference Architectures are bad, or that we’re perfect on the above (we’re not – and always striving to get better) – rather it’s this idea to look at the full “stack” of the offer as a single product, inclusive of sustaining and support, that is well… unique.

Sometimes this comes across as rigid – but that’s because the customer or the person sitting across the table has not crystalized in their mind the answer to this question:

“Do you want to consume/buy – or do you want to build?”

For people who have realized that they want to get onto the business of moving faster into Cloud Native development using Pivotal Cloud Foundry, there’s nothing like NHC in the industry. I’m sure I’ve drunk the koolaid – but take up my challenge and ask us to prove it - frankly if you want to deploy cloud native apps faster – the Pivotal and the NHC teams have worked to quantify the delta, and the delta is big:

• 93% faster to first moment the developer starts to code.   Speed = life.
• 77% faster from going from idea to prod. 

Now – is this “Cloud Native” stuff just buzz-word mania? What about “bi-modal”? Yeah – they do have that “gag in your own mouth” vibe because like “DevOps” they get thrown around like mad. “I’d like to buy some DevOps please”…

Yeah – they are buzzwords, but they also represent real ideas. This is what they mean to me:

• Cloud Native – means thinking about designing applications that are not only ABLE to run on cloud models, but are optimized for them, are “natively” designed to optimize in different ways than traditional enterprise IT apps. I think that that people get religious on these topics fast, but there are some real guidelines. I personally like http://12factor.net/ as a baseline because it puts some of the requirements out there in black and white terms – but that’s not sufficient. One of the best taxonomies I found was something my amigo on the other part of the business James Watters (heart and soul over at Pivotal on Cloud Foundry) retweeted a customer at a CF summit sharing their PoV:

• Bi-Modal – this really DOES play out at customers. Again, for some people this gets fanatical fast, and I get it – ideas are infectious. Here’s a “Chad chicken scratch” diagram.

“Platform 2” apps are the vast majority of the apps in an enterprise in my experience. They are the legacy, the technical debt. Before the cloud natives get too excited that I’m maligning them as “technical debt”, some perspective here is really important.   These applications are also usually the apps that pay for everything else.

My personal litmus test of whether a app is P2 oriented isn’t any one thing (and being “containerized” doesn’t make the difference – because that’s an abstraction model, doesn’t tell you anything about the app itself).  For me it’s the answer to 3 questions:

• Are you cool if I just pull out half the cables in the datacenter at random? Or, when the infrastructure hiccups, does the app have a heart attack?
• How hard is it to do an upgrade of the app in whole or in part? Do you need to plan an outage window?
• If you needed to scale the app up or down – would it be easy or hard?

The answers to those three basic questions really crystalize “Platform 2” apps – they are typically monolithic, very dependent on infrastructure resiliency (and that doesn’t = “hardware” – things like OS-level clustering, VM HA, DRS, Fault-Tolerance are all forms of infrastructure resilience, along with hardware appliances that has 99.999%+ availability design).

MORE IMPORTANTLY – in the diagram, the “processes” point is perhaps the most germane.  People and processes inside IT organizations are driven by the intrinsic nature of the app – so in “P2 land” they are careful, slow/cautious, risk adverse, and change-control/SLA driven. And that’s a GOOD THING. Remember – a burp at the interface between the infra and the app = BOOM (and remember, these are paying the bills).

Conversely, “Platform 3” apps, written for elasticity, written around those “12 factor app” principles are clearly the future, and any new app not being developed that way… well… why? Well, there are some apps for which they might not ever be written that way – but that’s the exception rather than the rule. For every business – the core question starts with the apps (not the infrastructure). Can the app be re-written using Cloud Native principles (the best when you can)? Can it be “transitioned” (lots of people using SpringBoot to transition java-based code) to run on a modern Paas (won’t make it Cloud Native, but better than a kick to the head)?

OK – so now that we understand:

1. This apps are different.
2. Those differences drive

The Enterprise Hybrid Cloud is a highly opinionated, turnkey P2 optimized stack.

· EHC uses the best P2 optimized IaaS and abstraction layer (vRealize and vSphere). It has rich infrastructure services around availability, backup/DR, and infrastructure-level encryption. It has rich reporting and chargeback.

· EHC runs on an infrastructure layer optimized for resilience, performance and availability – Vblock, VxBlock Systems and VxRack System 1000 with Flex Nodes for people who want a scale-out hyper-converged model. We are on version 3.5 of the Enterprise Hybrid Cloud platform, and working on version 4.0 along with our brothers/sisters at VMware.

· I want to be FIRM and CLEAR on this: you can absolutely run P3 apps on P2 optimized stacks. In fact, most Pivotal Cloud Foundry deployment are on vSphere! Many of our Vblock customers using EHC also run PCF (some are presenting at EMC World this week). Running P3 workloads on P2 infrastructure is best generally for customers as they are getting into Cloud Native apps for the first time, and the percentage of load is small enough that cost-optimizations don’t really warrant “bi-modal”. The key for leaders is to recognize that the people/process pieces will pull in very different directions. P2 apps will pull towards “risk = bad” and P3 apps will pull towards “slow = bad” (very different!) but it can be done. Not easy – but can be done.

The Native Hybrid Cloud is a highly opinionated, turnkey P3 optimized stack.

· NHC uses the best P3 optimized PaaS layer (PCF), and the IaaS layer and infrastructure layer is optimized to be lightweight and elastic, rather than deeply resilient (light vSphere for people who want to stick with what they know, OpenStack, and a true P3-optimized IaaS in the VMware Photon Platform), and runs on infrastructure that is designed to operate with multiple cloud stacks, and at rack scales (VxRack System 1000 with Neutrino Nodes – more on this later).

What do I mean by “highly opinionated”? Conversations about them involve a lot of “NO”. Like using AWS or Azure, the answer to “I want it to do something that isn’t in their service package” is “NO”.

You can build on top of them – but the defining element of a “platform” is you build ON it, not IN it.

The biggest challenges we’ve had with EHC (and will be true of NHC too) is when customers say “I want it to do _____” our field and partners are geared to say “YES”, when the correct answer is “NO”.

This is rooted in people not being clear in their minds of what is important for them – and whether these sub-optimizations are valuable, or a waste of time. Frankly, it’s also because people often confuse “can I do something” with “should I do something”.

In my experience, customers need to (sadly) go through a “learning process” before they start to think clearly about this new Cloud Native world. What do I mean? Well – there’s a lot of learning (and learning is fun). Here’s a couple examples. First, they pick, learn, fight and debate over all of these:

Well – it’s actually a longer list. A lot longer. Expanding, adding – here’s a few more:

…. Oh – and this ecosystem is “dynamic”. That means “changing” and it’s changing at a rate that is shocking. Awesome, but shocking. The moment something becomes “cool”, its days away from becoming “not cool”. It’s VERY, very hard to most enterprises to wrap their heads around this – but invariably they have smart, smart people – and those people LOVE to play and learn. I get it, and I do too.

But then – after 6, 12, 18 months someone sends an email like this: “hey, the developers are still pissed, they just want a working stable environment against which they can develop. The only thing that is reliable is the vSphere stack, but they complain that the people running it are too focused on processes build for the traditional apps. When Jane was here we were making progress, but the OpenShift/Openstack or CF on Docker or Mesos on bare metal project has really suffered since she left – who is going to solve this?”

I’ve seen it so consistently, it’s ridiculously predictable. These skills are so rare, so valuable (hint good career path!) – Inevitably the story has “Jane” or “Jim” becoming the SPOF for the whole project.

If you think of the Phoenix Project, they are the “Brent” in the story. Some people LIKE to be the Brent, and Brent thinks he is a hero, but he’s not.

 

What’s in NHC?

• The latest Pivotal Cloud Foundry Release
• It uses PCF Ops Manager to assist on deployment and lifecycle.
• It includes CI/CD tooling above and beyond the PCF baseline that we’ve found commonly used, along with application performance management tools.
• It includes a set of critical tools for the IT operations side of things – usage, forward-looking consumption monitoring, as well as performance – correlated into the context of the PCF developer spaces and apps.
• A pluggable Data Analytics module for next gen data fabric elements.
• The IaaS/Infrastructure layer – two simple choices: VxRack System 1000 Neutrino (OpenStack day one, and Photon Platform soon), and VxRack System 1000 Flex (vSphere) for customers who want to use vSphere because that’s what they know best and trust.
• Out of the box connections to other public clouds for off-premises workload elasticity -

Rather than talking about it more – it’s useful to see. Check out the demo below:

I’ll talk a little more about the VxRack System 1000 Neutrino Nodes in another blog post (here) – that’s a story unto itself.

So there you have it – for the first time, people wanting a simple, dependable turnkey developers platform – engineered as a single thing, supported and sustained as a single thing – those people have an awesome, simple choice in NHC.

And – let’s be clear from me (as the leader of this business) NHC is HIGHLY opinionated.

• If you want mix and match, if you want to tune/optimize inside the stack – NHC IS NOT FOR YOU.
• If you want alternatives to PCF or if you actually think you can home-brew a better PaaS stack – NHC IS NOT FOR YOU.
• If you think that optimizing below the PaaS layer will differentiate you – which is possible – NHC IS NOT FOR YOU.

To be blunt – those things are NOT the thing holding up most enterprises in their “digital business” efforts.  So why do they something these tweaks and “build approaches” might be good?  Answer: optimizing the whole stack makes all the sense in the world… if you’re a startup or a at scale hyper-scale player with one, two or a few apps, then you SHOULD build your own.   That “build your own” vibe is very strong when you go to conferences

BTW – if that is what you want… we have answers for you.   Those answers are not NHC – it’s all the point products and integrations with the ecosystem.    We are charging full force with integration at the product level with with the VMware Photon Platform.  We are charging forward with integrations with the open-source Data Fabric ecosystem.   We contribute to OpenStack as EMC (and VMware contributes a ton also).   We’ve contributed code to the persistence layers and volume management ecosystems of Docker and Mesos.   We’re all over Ansible, Puppet, Chef and others.    You you want to build – go to EMC{code}, and build your brains out :-)   All those answers all awesome for builders, for tinkerers/inventors in the infrastructure layer.

BUT…

… If you instead are what I see all day long, which are enterprises who desperately need an answer on how to jumpstart innovation, to restart their software development engine, to get their developers faster – if you are one of those, the Native Hybrid Cloud is for YOU.

Yes, this is v1.0 of the Native Hybrid Cloud platform, and I’m sure we’re going to learn a lot – but I think even 1.0 is a leap above what I see people achieving on home-brew efforts after many moons. And we’ll keep doubling down.

I think if you’re thinking of going the Cloud Foundry route, and conclude you need some on premises part of a hybrid cloud operating model… and critically, you’ve come to the conclusion that you want to consume vs. wasting months trying to “build” what is a commodity – then you want the Native Hybrid Cloud.

Comments

[David Holmes]

Hi Chad

Another fabulous post that's got my mind racing. A couple of questions:

1. If I do want to 'roll my own' PAAS stack, then Is Neutrino still right for me if NHC isn't?
2. If I've made an investment in Mesos, can I still leverage this with the PCF integrations delivered through EMC{code} et al?
3. Presumably, as a developer I can lean hard into NHC without caring at all which underlying IAAS (OpenStack, Photon, Apache) my IT ops team prefers?

PS your last two links (to the demo and Neutrino post) didn't make it into the post :-)

[Chad Sakac]

@David - thanks, and I do have "post EMC World" clean-up to do on this and other posts. So much happens so fast, that invariably as a human, I drop some balls :-)

1) If you want to "roll your own" PaaS stack, then VxRack Neutrino Nodes can still be for you, but NHC is not. VxRack Neutrino is a turnkey "cloud native optimized IaaS platform" - one you can layer PaaS on top of. Of course, if you ask me, I would go turnkey all the way up to the PaaS layer.

2) Right now, VxRack Neutrino and Mesos are mutually exclusive. One way to think of Mesos is as a form of "cloud native optimized IaaS". We support, embrace the "built it yourself" approach (all that EMC{code} goodness as an example. Perhaps over time, we can add deeper Mesos integration, but for now, if you go the Mesos route - it's a "build" not a "buy".

3) Leaning in hard to NHC means that you are leaning in hard into the "just make everything up to PCF turnkey, and I'll focus there".

Thanks for the questions - keep 'em coming!