an insider's perspective, technical tips n' tricks in the era of the IT Revolution

September 01, 2015

VMworld 2015: Federation Enterprise Hybrid Cloud 3.1

Q: What is the Federation Enterprise Hybrid Cloud?

A: Simple. It is the “industrialization” at the highest level of the Federation stack of our PaaS/IaaS stack.

If you want to be even more specific, it’s our “Brownfield” stack (built on the VMware Unified Hybrid Cloud stack and technologies) - meaning you plan on running monolithic classic 3-layer apps with lots of infrastructure dependencies AND modern cloud native apps on the same stack (for more on this “brownfield” / “greenfield” observation - read here).

People ask - what is the intersection with the VMware SDDC stack? Doesn’t SDDC = an enterprise hybrid cloud? What about with what VCE does with VxBlock, VxRack?

here’s the simple framing - which starts at the lowest level of the value chain:

At the lowest level - stuff runs on some underlying hardware strata. You can either mix and match and build it yourself, or you can buy that layer as an “industrialized" turn key stack as converged/hyper-converged infrastructure.

At the next level - you abstract, pool and automate. You can either mix and match and build it yourself with VMware and other products,or you can buy that layer as an “industrialized" turn key stack as the VMware SDDC Stack - aka the Unified Hybrid Cloud (or for greenfield, the PCF/Photon Platform bundle). Deploying this is about to get a lot easier with the EVO SDDC Suite and EVO SDDC Manager - but that’s often not enough.

At the next level - you need to deploy it, protect/secure it, build workflows, and integrate it with the specific needs of a given customer. This is something you can learn for yourself, or you can buy that layer as an “industrialized" turn key as the Enterprise Hybrid Cloud.

At the next level up - you can either build and operate it - or have someone operate it for you (on or off premise).

At each level - these are manifestations of this idea:

There is a ton of engineering work (hundreds of thousands of man hours) - representing a ton of engagements with customers in deploying these hybrid cloud solutions - and this is about services as much as it is about point technology stacks. One way to accelerate to “outcome” is simply to buy the capability as a public cloud, or as a managed virtual private service - but sometimes due to a ton of factors - that’s not the right answer, and it needs to be built for the customer.

Let me give you a couple simple, visceral examples.

Customers have existing SLAs for backup and DR build around the app stacks that they want to deploy on their private cloud instance. Sometimes this is far beyond what one has “out of the box” with the VMware SDDC Suite and stack. How do you make your backup and DR services part of your ITaaS internal offer?

Answer - the Federation Enterprise Hybrid Cloud - DRaaS and BaaS:

Similarly, there are officially packaged capabilities around encryption services, big data options and more. We have a series of “Sidecar” solutions that have had some work, and people should expect to become formalized parts of the engineered solution stack - like PCF, VIO, and other examples.

Furthermore - experiences at customers have shown us that there are common “ecosystem players” who are part of the overall solution - and as we see them enough times, we formalize these 3rd Party Integrations. I can say out of personal experience - the overlap with customers deploying the Federation Enterprise Hybrid Cloud that also happen to be migrating from legacy ITSM stacks like Remedy to more modern models like ServiceNow is nearly 100%. Likewise, almost every customer has a fair amount of Puppet in play, and linking Puppet Enterprise with the capabilities in the elements of the Federation Enterprise Hybrid Cloud stack (the top parts of the vRealize suite in this case). Ditto with Palo Alto Networks. I’m seeing interesting CI/CD players like XebiaLabs pop up a lot also.

Yes - there is some competition amongst these stacks (visualize Venn diagrams with a small amount of overlap) - but thinking "customer first”, it’s about bringing the solution together - and delivering an outcome. Being able to industrialize the stack in this way, and deliver it as an outcome (often in 28 days or less - orders of magnitude faster than customers trying to self-assemble) - it’s far more valuable than any “point product”.

We’re on Federation Enterprise Hybrid Cloud version 3.1:

refreshed component technologies from VMware and EMC

much deeper NSX support

new capabilities around App-as-a-Service, Big-Data-as-a-Service

encryption as a service

multi-site affinity in an automated deployment fashion for continuous availability as a service, and integration with the BaaS to move backup policy as the workload moves

...and v3.5 is well underway. This is a ton of work, and a ton of value. It’s a reflection of the fact that more and more customers are looking for an outcome vs. as a set of component technologies.

Frankly - the ONLY even more assured “outcome oriented" way to get this capability is as a managed service. Hint, hint. That’s a story for another day.

So - have you tried to deploy these solution elements together yourself with no map? How did it go? How much work did it take? How much work when you had to re-test, re-integrate the stack as big elements were refreshed?

Search

Disclaimer

The opinions expressed here are my personal opinions. Content published here is not read or approved in advance by Dell Technologies and does not necessarily reflect the views and opinions of Dell Technologies or any part of Dell Technologies. This is my blog, it is not an Dell Technologies blog.