Virtual Geek

Seriously… DIY HCI or HCI Systems –are you SURE?

I want to be clear – I see REAL cases where customers cover the full spectrum for real reasons – from DIY to turnkey systems.    I know that we as Dell Technologies need to provide great choices for builders of IT, and consumers of IT.

That said – I see some bad examples of self-inflicted pain by customers, and by us (not just Dell EMC, or VMware, but the whole vendor ecosystem).

I see customers who hurt themselves by not being honest about how much time, money, brains they waste on silly low level things… because they LIKE to, for masochistic reasons I don’t understand.  

I’ll give you two examples from last week: 1) a mid-sized enterprise customer wanting to build their own vSAN cluster using open compute hardware (does anyone think that will help them be a better business???); 2) a customer who absolutely, desperately needs an system operating model – but someone said “if it doesn’t have this specific RAM configuration, I’m going to build it myself” (even though it’s not what the leadership in the customer is asking to prioritize).

I see vendors (including us) acting as enablers, because we’re USED to just saying yes, just quoting what we’re asked to quote, running a basic server/network/storage/software sales motion – because it’s what we’re used to.  

In each of the cases above – both VMware and Dell EMC teams are, in effect “enabling” this (because we are trying to respond to customer’s requests vs. challenging and asking “why?”…  and also because it’s what we’re used to with best-of-breed approaches).

Let me make this clear with a simple picture and analogy.

I love building my own PC systems for fun (I do this over the holidays because it’s like meditation for me) – and that means I get Newegg Canada email promos all the time.   Every email promo has a “DIY corner” with bundles – just like the below.

The link/picture on the left is for a bundle.   Bundles are validated, can be ordered together.   While you can sort of expect that because of open systems standards and multi-vendor support models the parts of the bundle will work together over time, there is no explicit promise of “working together” that over years and updates.   What about the economic value?   The components of the bundle are packaged, and in exchange, you generally pay a discount versus the sum of the parts of the bundle.  

The link/picture on the right is for a system – in this case a Dell Alienware Aurora R6.  It’s one thing.  from one place.   It’s integrated.  The vendor is responsible for how it works – for the life of the system.   What about the economic value?   The components of the system are integrated, often with additional software that ties them all together.   This means in exchange, you generally pay a premium over the sum of the parts – and that degree of premium is about the degree of integration, value add in all parts of the offer, inclusive of other software.

Think of the picture on the left as a vSAN + vSAN Ready Node for DIY HCI, or a buying VMware, Server, Storage network in more traditional DIY infrastructure.   These are examples of bundles.

Think of the picture on the right as VxRail (HCI system) or a VxBlock (CI system).   these are examples of systems.

There are other loads of examples of bundles and system analogs.   Think Dell EMC XC (system), or Nutanix software + PowerEdge (bundle), or VMware Cloud Foundation + PowerEdge (bundle) or VxRack SDDC (system).   That said, based on volume, the vSAN + vSAN Ready Node (bundle) and VxRail example is the largest volume example that plays out every day.

Now – there’s more to it than packaging.  There are critical product/product differences that result in a materially different decision.

MORE IMPORTANTLY:

The “DIY” decision represents THIS choice: “I’m going to keep doing what you’re used to – which feels familiar.  I recognize that I’m not freeing up a single ounce of time, or resources – I’m choosing to simply  just getting a more  fresh set of ingredients than I have now”.  

The “System” decision represents THIS choice: “I’m going consciously STOP doing what I’m used to doing and redirect that time, effort, neurons to other activities – and that feels strange.  I recognize that I’m making a conscious choice to free up time, resources – but that in exchange I’m not going to be able to tweak everything, and there is incremental value I will pay for”.

I want to be clear – vSAN and the vSAN Ready Node HCL program is a great thing.   We embrace vSAN Ready Nodes - and in fact, Dell EMC PowerEdge is the leading server platform attached to vSAN when customers choose the DIY route.

I want to be clear - VxRail is a very different thing.

Even if I drop things like integrated data protection, remote replication, cloud storage, NAS, etc that make them different, they are still two totally different offers.

Answer these questions “YES” or “NO” – and it will help you navigate the right choice for you:

Lifecycle Management:

• Do you expect that there is away to do a cluster-wide upgrade/update from soup to nuts, and versioning is done as a whole?
• Do you expect that lifecycle – from soup to nuts – has a nice simple REST API so you can scale?
• Do you expect a simple internet based update that automatically gets everything in a nice package – hardware, software, everything?
• Do you expect that BEFORE you add a node, update a node, remove a node (or a cluster) – that the software will check to make sure not only that the hardware/software is in a known good config, but also that the user hasn’t made configuration changes that are known to cause failures?
• Do you expect that AFTER you add a node, update a node, remove a node (or a cluster) – that the software will check to make sure not only that everything is healthy?
• Do you expect that everything needed for a lifecycle update – not just controller (which is in vSAN 6.6.1 via VUM), but BIOS, integrated systems management, NIC firmware, drive/SSD firmware, power supply, everything?

Deployment:

• Does the local image get checked before install?
• Does the network get checked for readiness before install?
• Does the hardware configuration get checked for readiness before install?
• Is there an ability to stage a multisite standard via config/reposistory?
• Is there an ability to batch deployments and cluster scaling?

Serviceability:

• Do you expect that your vendor gets telemetry for support and isn’t connecting dots when the chips are down?
• Do you need the ability to open a vendor support chat directly from the infrastructure?
• Do you need a simple way when you do a field/customer replacement part?
• Do you want someone to be tracking the SSD endurance/lifespan for you, and replacing when you need to?
• Do you want a simple way to shutdown a node with a single click?
• Do you expect that your partner has a simple mechanism for log collection for everything soup to nuts?

If you said “YES” more than “NO” = you are a VxRail customer.

If you said “NO” more than “YES” = you are a vSAN + vSAN Ready Node DIY customer.

VMworld 2017: XtremIO X2–the best clean-sheet AFA gets better.

This week marks the launch of the next generation of an incredible successful product – Dell EMC XtremIO.

The best way to think of X2 as the 2nd generation of XtremIO – it takes the great foundation of the strengths of XtremIO and builds on them.

The core architecture of keeping all the metadata in memory, all the time, and architecting that as a distributed system that is tightly coupled scale-out cluster (see Understanding Storage architectures).   That has been, and continues to be the essence of what customers love about XtremIO – fantastic consistent performance, and data services that are global, and always on.

What hasn’t changed = the core strengths of XtremIO. 

• XtremIO continues to be the platform and stack to beat when it comes to inline data reduction and incredible copy services – because of the distributed in-memory
• XtremIO continues to be one of the simplest external storage array platforms to design and manage, because it’s scaling model is simple, it’s behaviors so linear, so constant.

What has improved are the points of where XtremIO could get better:

1. Scale up, and out = multi-dimensional scaling model.   This gives customers a fundamentally better economic model than we were able to do before.
2. Improved data services – a 25% improvement in data reduction rates – and a peek at some fascinating things coming around remote replication.
3. Simplifying the hardware stack.   People that know XtremIO know that the battery backup unit in each appliance and relatively complex cabling was an unnecessary complication.
4. Simpler management in general.

As I’m here at VMworld 2017, and talk to a lot of customers – it’s worth making a “step back and see the forest for the trees” comment.  

The Dell Technologies position (therefore the shared position of Dell EMC and VMware) on what is happening in the storage world is that the majority of x86 workloads are ready to run on SDS like ScaleIO and vSAN, and their HCI system instantiations (VxRail, VxRack). 

At the same time, there are workloads that will remain on external storage arrays for the foreseeable future: ones that have very specific data services needs, ones that have very specific capacity density needs that outstrip industry-standard x86 hardware designs, ones that have performance latency jitter requirements that exceed what you can get with loosely coupled distributed systems.   These are important, but exceptional cases.

• XtremIO has EXCEPTIONAL copy data services and data reduction services, and now an amazing new remote replication capability.
• XtremIO has EXCEPTIONAL of the most linear low-latency behaviors with it’s tightly coupled architecture and shared memory model.
• XtremIO now has EXCEPTIONAL multi-dimensional scaling behavior – both in performance and capacity densities.

These are amongst the sustained sweet spots for the External Storage array market – and why we’re really excited about this new release!

One other element of food for thought.   Of the 350,000 vSphere customers, about 20,000 or so of them are using SDS and HCI in some form – if you look across the HCI/SDS ecosystems (and where vSAN DIY and VxRail lead the way).   

Now expand your perspective to contemplate the whole universe of things that are not vSphere.  

While there’s no question that there is huge growth in SDS/HCI – it’s simply no a zero-sum game.   The place for external storage systems are cases where either specific data services, or extreme capacity/performance density that exceeds industry standard hardware, or the very tight latency jitter characteristics of tightly coupled systems.  External Storage arrays are here for the long term, and XtremIO X2 is a great update to a key player in that universe!

Congrats to the whole XtremIO team!

Now – for more details – please check out Itzik Reich (XtremIO CTO and blogger extraordinare) here, and if you want more of my thoughts, read on past the break!

VMworld 2017: re-inventing Data Protection for VMware

This is cool.

Every customer needs Data Protection for their VMware environment – local backup and recovery, and protection from disaster recovery.

I’ve seen every chapter of this – from the birth of Site Recovery Manager in 2008 (to Jay Judkowitz – shout out to you buddy!, the birth of CBT in 2009, along with VDP and VADP, and the emergence of Metro Stretched Clusters in 2011.

If I pull out VMworld sessions from years gone by, I can see engineering blood sweat and tears, customers, and more.

What’s the common thread?   For as long as information persistence matters (and it always will) – data protection matters… a lot.*

* even in the world of cloud native apps – where most persistence is in geo replicated object stores and next generation data fabrics (vs. monolithic RDBMS databases), there’s room for innovation around data protection.  More on this in another future post.

Data Protection is also an area ripe for reinvention and disruption.   We have a great offer today with Data Protection for VMware leveraging VADP, DDBoost, and Data Domain.  This is part of our HCI strategy – where customers choosing VxRail, VxRack, and even XC can integrate a great backup choice deeply integrated with VMware.  

That said – this is an area that is hot, and filled with startups.   You can see a lot of startup activity here for a good reason – there’s customer pain, and there are new an interesting approaches that can be taken.

We’re one of the backup leaders, with overwhelming market share leadership with Data Domain, but that means you can’t rest on your laurels.  In fact, when you are the leader, everyone comes gunning for you.  It’s natural!

Today’s announcement is the first part of of a multi-chapter saga: 1) tackling how we move data; 2) how we build next-generation management, policy/automation and build in AI and ML for data protection; 3) how we persist copies of data; 4) how we reinvent data protection for cloud native apps.

I’m going to start with a story.

We have a customer in APJ who is one of the largest Horizon projects that I’m aware of in the world.   It’s a very challenging case, and it’s a customer leaning into new ways to tackle massively distributed branch locations.   They have 25,000 branches – and their business is part of the country running.   Part of tackling a new way forward, they don’t just want to do what they do today better – but they want to offer services that they couldn’t before.

They want (are demanding in fact) to deliver something these branches have never had before – simple and fast disaster recovery.   Previously if the branch had a local disaster – that was pretty well it.

Our solution for them is Recoverpoint for VMs 5.1.

Several weekend ago, we ran a disaster recovery and failback test for 2000 branches.   We failed them over in an average of 27 minutes.   They ran for a day remotely, and then failed back in  an average of 19 minutes.

Think about that.   Big scale.  Support for sync and near-sync replication.  Best-in class data reduction.  VM-level implementation.  100% software.   Runs on any infrastructure stack.

It’s for that reason that I think that Recoverpoint for VMs (RP4VM) is one of the most powerful tools in the Dell EMC/VMware arsenal. 

It’s not an accident that RP4VM is included with VxRail, and we will be bringing it to VxRack SDDC.

With RP4VMs 5.1 it’s better than ever, and simpler than ever.   There’s better scale, better automation of network changes.   Can we make it better?  You bet.  Will we?  Count on it.

But – RP4VMs can be thought of not just as a DR tool, but a copy-data management and data transfer engine – one of 3 critical pieces for a next-generation data protection strategy (the other two being a policy/AI/management, and next generation purpose-built backup targets).

This is what we’ve done today – we’ve made RP4VMs an integral part of Dell EMC’s Data Protection Suite for VMware, and in the process, created a “Hypervisor-Direct” data path that is 5x faster and more efficient than CBT and VADP.

The ESXi integrated splitter in the vmkernel is much more perfomant than VADP – but we retain all the beautiful elements of software-only data movement (no Recoverpoint appliances need), and VM-level policy.   You can hit Data Domain, and you can also leverage external Object storage, any S3-compliant cloud storage and also of course our own Virtustream Storage Cloud – all to crush the cost of long-term copy retention.

How do you “drive” this?   Simple.  It’s integrated right into the two most important tools for a VMware admin: vCenter (including the HTML 5 client of course) and also deep vRA integration.

Furthermore – at VMworld, VMware announced availability of the VMware Cloud on AWS.   That data needs protection too – and the idea of moving it out of AWS is insane (darn data gravity).  How are people going to back that s#$% up?!?!

Answer = simple.   The same core Dell EMC Data Protection we’re talking above… is the first data protection for customers using VMware Cloud on AWS.  Tada!

 

Remember how I said that a couple other things are needed to complete a real next-generation, ground up data protection strategy?   One of the other parts was policy, automation and management.

Enterprise Copy Data Management (eCDM) does the this.   There are guardrails to automate like crazy:

We aren’t stopping there.  Any next-gen data protection strategy needs to also include AI – no human on their own can manage the data protection copies, and ensure that they are compliant.

Add it all up – what do you get with a modern data protection approach?  

• Up to 72x Data Reduction rates.
• Less than 5 minutes to deploy and configure a proxy – and almost completely hands off.
• Up to 98% reduction in network usage.
• 20x faster than traditional recovery.
• 50% faster backup time.
• … With new
• … all easier to scale, with broad use case support, and support for both a software-defined datacenter, and also things like VMware Cloud on AWS.

People – if you’re still backing up over your LAN, and for goodness’ sake to tape, there’s a better way.

Awesome work, and a huge congratulations to the Data Protection team, and my sister in the “Gang of 5” (inside reference), Beth Phalen and her team!

We’re not stopping here.   We are the Data Protection leader, and are working overtime.  Lots to do – and lots of hints laid in this blog post.  We’ll be continuing this dialog in posts to come…   But even right now, the Dell EMC Data Protection Suite for VMware just took a giant leap forward for our customers!

VMworld 2017: Continued Advances in Hybrid Cloud – DIY Choices

If you’re coming here first – I strongly recommend reading the “Lessons Learnt” post in this series, here.  It will help with context, and understanding your options and choices.   Also – I strongly recommend reading this “DIY” and “Consume” blog post here – it’s very useful.

Ok, with that context – lets talk about something new for us at Dell EMC – a renewed effort around supporting Hybrid Cloud DIY choices.

For Dell EMC – for the last 4 years, we’ve been maniacally focused on full turnkey cloud stacks (EHC/NHC).  I want you to internalize what that mean by that.   The Dell EMC team has taken on the mission of design/engineering, testing/validation, packaging, full lifecycle support and single support – FOR EVERYTHING.   This is analagous to what we do at the virtual infrastructure layer with CI (VxBlock) and HCI (VxRail and VxRack).

This is a material challenge.   We’ve made a ton of progress in EHC (as you can see here) and NHC (as you can see here).

That said – invariably, these cloud stacks have a couple fundamental challenges that result in them not being the right answer for every customer for these reasons:

• Market need for a DIY approach.  Some customer want a turnkey sustained system “consume” approach at the HCI infrastructure (VxRack, VxRail) – but want to pursue a guided DIY approach for the IaaS/PaaS/CaaS layer of the stack.    This can be for very real reasons (constraints of turnkey cloud platform is not a fit, for example).
• Component lag.  By definition – this fully engineered, sustained, supported as one approach of the Hybrid Cloud platforms lags releases of the component ingredients like vRealize, or NSX.   This is also true of the DIY vs. Consume choices at the virtual infrastructure layers (HCI) – but the lag is more material.   This isn’t because people aren’t working hard – it’s because the moving pieces are more complex, and interoperability needs work.
• We’ve made it harder than we needed to.  It’s notable that with public cloud IaaS/PaaS/CaaS models, you can’t make a lot of choices – but they work well.   Conversely, when customers started asking for on-premises clouds, it started with a TON of variation.   We’ve learnt hard fought lessons about the price of even small variations.   It’s not a coincidence that our turnkey systems are focused on HCI going forward.   It’s not a coincidence that we support DR-as-a-service in EHC only using Recoverpoint for VMs – and not SRDF, and other forms of replication.   Variation = failure when it comes to simplicity and lifecycle management.   You need the barest minimum variation (there is a point where you don’t have enough flexibility to be compelling) – and no more.
• “Native” Lifecycle Management is improving.   In relatively recent timeframes, there are growing “Apollo moon missions” to make LCM of the stacks easier.   This is true for IaaS (vRealize + VMware Cloud Foundation), or a PaaS (PCF + PCF Ops Manager and Ops Director) or a CaaS (like Pivotal Container Services aka PKS) has gotten a lot more focus in each company.   Historically the focus of VMware, Pivotal, Dell EMC (at least from where I sit) has been on innovation in each layer, rather than how the layers all work together and are life-cycled together.   In the Converged Platforms and Solutions team (where I work) – our whole life has been this simplification purpose, so it’s very familiar to us at every level of the stack.   But – lack of stack LCM automation meant that DIY approaches historically involve a lot of expertise – either at the customer, or via professional services from the vendor and partner ecosystem.   This is changing.

This means we can now:

1. Create a new option – DIY Hybrid Cloud on top of turnkey “consumed” HCI VxRack SDDC systems – these are VMware Ready Systems and Pivotal Ready Systems.
2. Continue to offer EHC and NHC for customers who want a “consumed” model for Hybrid Cloud.
3. Work the roadmaps for VMware Ready Systems, Pivotal Ready Systems as a rally point for several key pieces: VMware Cloud Foundation, VMware’s efforts to simplify the LCM of vRealize, and Pivotal’s efforts to simplify the LCM of PCF and Pivotal Container Services.  

VMware Ready Systems are available now – their first incarnation are VxRack SDDC using VMware Cloud Foundations and the VMware Validated Design for vRealize.   We actually use the VVD program as the “base building element” for the full blown EHC – so this is a natural step.

Pivotal Ready Systems will take some time to complete, but will be ready soon.

Like all things in Dell EMC Ready Solutions – Ready is how we make things easier for the DIY customer.   Think “Redbook”.   Think Cisco Validated Design.   Think VMware Validated Design.   These are all programs and real work to de-risk customers who are taking a DIY path.

• Ready Nodes are more than just a server + software packaged around a given workload…  it’s READY.  Tested, validated, documented – and setup for easy acquisition.
• Ready Bundles are more than just server + network + storage + software packaged around a given workload…  it’s READY.   Tested, validated, documented – and setup for easy acquisition.
• Ready Systems are more than just CI/HCI + software packaged around a given workload.  It’s READY.  Tested, validated, documented – and setup for easy acquisition.

Now, it’s important to understand who is responsible for what in Ready Systems – the picture looks like this:

This means there’s a very nice degree of clarity.   As is always the case with CI/HCI – the full lifecycle is the Dell EMC responsibility.   We own the VxRack SDDC and VxRail experience, with single support – for that layer.  Our job is to nail the easy simple consumption of this layer – taking the complexity and opex away from the customer.

VMware is responsible for how the customers deploy and lifecycle the vRealize Suite using the VVD program, coupled with VMware PSO and partner capabilities.

Pivotal is responsible for how the customer deploy and lifecycle of Pivotal Cloud Foundrty and Pivotal Container Services.   The lifecycle for this using PCF Ops Manager and Ops Director is improving.

Is there a “single throat to choke” like EHC/NHC?  No.  That’s what makes this a DIY path to Hybrid Cloud vs a consume path – logically it is this path:

Over time – there’s an opportunity for great simplification in new option.   You can see total Pivotal/VMware/Dell EMC alignment in VMware and Pivotal Ready Systems – RIGHT NOW.

Clearly – each party leads the efforts in their domain.  We have alignment on the full technology stack.   Unlike EHC/NHC – it has what it does in the name.   VMware.  Pivotal.   Unlike EHC/NHC – the “who does what” is clear.   Each party does their piece.   We work together to bring it together for the customer.

It will get better over time as we align work and roadmaps around this rally point.

• Imagine that VxRail and VxRack SDDC become closer – sharing hardware variability, and a common base low-level LCM element.   At that point – we can align everything on VxRack SDDC – because there would be an easy path for customers to start with VxRail, and then move to VxRack SDDC as they wanted the on-premises foundation for a cloud.
• Imagine if VMware cracks the code of LCM for the full vRealize Suite and it was integrated with VMware Cloud Foundation and VxRack SDDC.  That would be a huge simplification.  
• Imagine that VMware Cloud Foundation targeted PCF and PKS as first-order use cases for the workload-domain behavior, and aligned for things PCF needs naturally, like multi-az handling (to understand this, read this post here).

If we were to do these things, we ultimately simplify this aligned technology stack – and close the gap with EHC/NHC.   At that point – they become one thing – with the simple choice of do you want multi-vendor or single vendor as your preferred acquisition and support model.  

Are we working on these things and more?  Of course :-)

Stay tuned to this space for more about VMware Ready Systems and Pivotal Ready systems.

I’m very curious for your thoughts – the perspectives of our customers, our partners, and our VMware/Pivotal/DellEMC employees are very valuable to me. 

Do you see what we’re doing here?  

Do you get the delta in the value proposition of a Ready System relative to a Hybrid Cloud Platform?

VMworld 2017: Pivotal Container Services (PKS)

IMO – this is one of the biggest announcements at VMworld this week.   It is a major shift to the Dell Technologies strategic perspective, and important for our customers.

It’s something we’ve been spending a lot of time on internally for a while – I’ve spent hours at end with Scott Yara and James Watters at Pivotal, and with Ray O’Farrell and Paul Fazzone at VMware, and it’s not just me, but others in Dell EMC too.

Let’s start from the start.  There are 4 abstractions customers need as they develop cloud native apps:

 

Each has a purpose – one that the others are not ideal for.

• Kernel-Mode VM =   an instantiation of an abstraction of a physical host.  Useful when you need to get low-level for one reason or another, including hardware abstraction.   It’s notable that almost all containers run on some form of kernel mode virtualization.   Things like hardware abstraction, security abstraction, software defined networking are insanely valuable even when the sole purpose of the VM is to host containers.   Yes, in the 100% container scenario some functions like VM consolidation, HA, resource scheduling have reduced value – but those other things = valuable.
• Container/Cluster Manager = an instantiation of an abstraction of a OS including a namespace, and meta filesystem.   Useful when you can’t use a structured PaaS, but need your own specific set of tools, functions, runtimes, micro-services – in other words, build your own DIY PaaS on top of the container/cluster management layer.
• A structured PaaS = an instantiation of an abstraction of a given set of runtimes and given platform services.  Useful when you want a turnkey platform and it’s a fit for what you need.
• Data Services and persistence = an instantiation of given set of data services (like Dynamo, RDS, but also SQL, Redis, you name it) and object/blob storage.  Useful when you need to store/pricess stateful information.

The preference is always to use the highest order abstraction you can…  that means you need to do less, and can focus on things that have value.

Now – as Dell Technologies – we’re already doing great when it comes to 3 out of 4.

• VMware has the best Kernel Mode abstraction platform on the planet.  Mature.  Widely deployed.  Feature rich.
• Pivotal is the leader in structured PaaS abstractions with Pivotal Cloud Foundry.
• Dell EMC has great object storage abstraction models for developers with Elastic Cloud Storage – and Pivotal Data services is a rich set of data service abstractions of all types.

We all collectively participate and contribute (and use) the container ecosystem – but didn’t have a strong opinionated point of view.

• Dell EMC {Code} makes tons of contributions to volume controllers into Docker, Mesos, Kubernetes. 
• Pivotal make Docker a choice underneath Diego. 
• VMware integrates Photon platform elements and vSphere Integrated Containers (VIC) with the whole ecosystem.

But… historically, our point of view on the container/cluster manager abstraction ecosystem wasn’t clear.

I’ve heard some folks vehemently and passionately argue that container/cluster managers aren’t needed (“just use a structured PaaS!”.   I’ve heard others argue that developers don’t need Kernel Mode VMs.  I’ve heard others claim infrastructure doesn’t matter. 

Hint – none of those are correct.  There is a lots of confusion…. and that’s not a surprise, this is a VERY dynamic/chaotic ecosystem right now.

The container/cluster manager ecosystem seems to be starting to settle.

From my point of view, and it’s a broadly held point of view in Dell Technologies – Kubernetes is the likely “winner”.   It seems that it’s hit critical mass – and enough people are rallying around it – just like people have rallied around Cloud Foundry as the structured PaaS of choice.

The strategic pivot was to acknowledge that we needed to do our part, and that meant a couple things:

1. Make our point of view clear – anyone inside the company that thinks there isn’t a need for container/cluster managers is not aligned with our strategy.   PCF is great – but it isn’t the answer for need of a developer, of a customer building new cloud native apps.
2. Continue to be open to the container/cluster ecosystem, but have a strong opinion.  We do – Kubernetes.
3. Find the way where we can best contribute and help.    The answer is around contributing, hardening, and generally making Kubernetes enterprise-ready in every way we can.

Google is the primary contributor to Kubernetes – and saw the great opportunity of us adding to the community – and thus Kubo was born.   Kubernetes on BOSH – the same very bottom level part that underpins Pivotal Cloud Foundry.   BOSH performs an analagous function to the BORG layer within google itself – a low-level lifecycle management and physical resources scheduling function.

This is an area where we have a lot to give.  We can make core Kubernetes services liked etcd easier to deploy, to lifecycle.  We can build integrations with the VMware Cloud Foundation stack that make Kubernetes stronger and better – and we announced material resources working on Photon at VMware shifting to focus there.   We can take the concepts of Developer-Ready Infrastructure and NSX/PCF integration and extend that to the Kubernetes ecosystem.   Dell EMC can integrate ECS more tightly.   We can build and integrate object snapshot/versioning schedulers and managers as a “backup” analog for cloud native apps.

Personally, the team I lead can work to make VxRack SDDC and VxRail the best way, hands down, to deploy this stack on premises.

Today – Pivotal, VMware, and Google announced Pivotal Container Services – which has an acryonym of PKS – with the K signifying Kubernetes.   Pivotal Container Services is the enterprise distribution of Kubo.

Here is is in a simple picture I’ve sketched up:

There are some key observations here:

• We will now give developers – all four abstractions, and leaders in each.
• While we continue to be open – we’re now strongly aligned and opinionated on the best way to do this – something the whole of Dell Technologies can and will rally around:
• Pivotal Cloud Foundry is the most mature, most deployed structured PaaS.
• Pivotal Container Service is the best Kubernetes based container/cluster manager for the enterprise.
• VMware stack is the most mature kernel mode virtualization stack on which to build in the enterprise, and it’s one you already know.
• Dell EMC VxRack SDDC (build on VMware Cloud Foundation and extended with additional services like ECS) and VxRail (for customers who want to start really small) will be the best turnkey HCI optimzed for the full stack.
• We know that not every customers will want/need it all.  Some will be OK with just PCF.  Other OK with just PKS.  We will not connect the licensing model – ergo, while PKS shares an architectural underpinning with PCF in BOSH, a customer doesn’t need PCF to use PKS.

BTW – this is one of the elements behind the Pivotal Ready System announcement I talked about here.

What you have today is a cool technical announcement, a sign that Pivotal, VMware, Dell EMC are embracing Kubernetes.

But – as a leader in the company, I also see something else. 

We now have a Cloud Native/Digital Transformation stack where there is a SINGLE target we are furiously running towards now as VMware, Pivotal, and Dell EMC – no mis-alignment, no differences in PoV. 

Today you see the hand of the leadership of the new Dell Technologies company (Michael Dell) and the CEOs of the strategically aligned companies (VMware – Pat Gelsinger & Pivotal – Rob Mee) all saying: “we’re going THIS way, come with us”.

Lots of exciting work going on here – and I’m pumped to finally get to talk about it!

VMworld 2017: Continued Advances in Hybrid Cloud - NHC

If you’re coming here first – I strongly recommend reading the “Lessons Learnt” post in this series, here.  It will help with context, and understanding your options and choices.

Ok, with that context – lets talk about the Native Hybrid Cloud (NHC) 1.4 

NHC is designed to be a full cloud stack – built, designed, sustained as one full entity.  It’s analagous to VxRail/VxRack relative to vSAN/VCF in the “DIY” and “Consume” picture.   Some customers want to build clouds.  Some want to consume a cloud.

NHC is a turnkey PaaS focused on the most lean way to stand up a developer platform centered on Pivotal Cloud Foundry, and giving the infrastructure team the tools to join the developers on their DevOps cultural shift.

It’s core principle matches a PCF core principle – “focus above the value line”. 

All those things are NOT things that a developer really wants to spend time worrying about (though arguably as you move further up to the right, security, app management and marketplace are things they think about to some degree).

The goal of the NHC team is to take a platform approach to everything below the value line.

NHC 1.4 is built around PCF 1.11, and runs on VxRail, and always includes an Elastic Cloud Storage Object store – not only does every developer need an object store they can count on, but it’s also used for multi-AZ, multi-datacenter NHC behaviors. 

First, let’s talk about what’s new in PCF 1.11 – since this is at the core:

• CredHub: Secure Place to Manage Credentials - https://docs.pivotal.io/pivotalcf/1-11/credhub/
• Container to Container Networking (GA) - https://docs.pivotal.io/pivotalcf/1-11/concepts/understand-cf-networking.html
• NFS v3 Volume Services (GA) - https://docs.pivotal.io/pivotalcf/1-11/devguide/services/using-vol-services.html
• BOSH Backup and Restore (Beta) - https://docs.pivotal.io/pivotalcf/1-11/customizing/backup-restore/backup-pcf-bbr.html
• Support for Private Docker Registries
• Support of NSX Integration via OpsManager – this is a critical place of VMware/Pivotal collaboration.
• For more functionality in 1.11 read the release notes and the blog:
• https://content.pivotal.io/blog/moving-at-the-speed-of-startup-with-pivotal-cloud-foundry-1-11
• https://docs.pivotal.io/pivotalcf/1-11/pcf-release-notes/
• https://docs.pivotal.io/pivotalcf/1-11/installing/highlights.html
• Issues documented - https://docs.pivotal.io/pivotalcf/1-11/pcf-release-notes/runtime-rn.html#knownissues

Now, NHC embraces the multi-availability zone approach in Pivotal Cloud Foundry (read more here: https://docs.pivotal.io/pivotalcf/1-11/customizing/understand-az.html)

Multiple HA deployment approaches are supported in NHC:

• Single Site
• Multi AZ
• Multi Foundation
• Multi-Site
• Multi-AZ
• Multi Foundation

Note that multi-AZ requires an expansion NIC on VxRail, and that means you cannot do it on G-series nodes.   Furthermore, external vCenter is Mandatory for HA on VxRail.   Note that system-level design and single support is filled with these sort of critical gotchas.

This is an example of a single site HA multi-AZ configuration of NHC.

 

NOTE: For Virtual Geek readers wondering why VxRail and optionally VxRack FLEX for NHC rather than VxRack SDDC/VCF – this is the root of the technical answer.  

This comes up often at customers where the VMware team is laser focused on VCF, which is great – but don’t know about PCF… a couple quick comments:

• We are doing an early adopter program around VxRack SDDC – this helps drive feedback into the VCF/VxRack SDDC roadmap
• You can see why VxRail and not VxRack SDDC – VCF workload domain behaviors mean that today, configuring for an multi-AZ PCF deployment is tricky.   External vCenter also is another example.

As we work on the VMware Ready System roadmap together with the VCF team – this is an opportunity for simplification.   If we can make configuration of VCF/VxRack SDDC optimized for PCF, and make tweaks to the VMware CPI and PCF Ops Manager Director for VMware it would be a big leap forward.

ECS is included in every NHC.

It’s used for several functions:

• ECS serves as the Blob Store for PCF
• It is the anchor for backup and restore of NHC Stack (beta)
• It is the Object Store for Application Developers (Future)
• It will be the target for backup for data services in the future.
• The customer can utilize the ECS for other functions.
• A minimum of 5 nodes as part of the starter kit.

Now… Always interesting – where are we going next?

There’s a clear chance to simplify.

1. If we could shift some VCF behaviors, VxRack SDDC would be an ideal deployment platform for PCF and KUBO.  It’s not yet, but both VMware and Dell EMC are working to get it there.
2. Clearly, there’s an opportunity to make the object store an embedded, vs. bolted on option.  The ECS appliance form factor is ideal at scale (almost all ECS deployments are big – many hundreds of TB, generally more in PB ranges – and there appliances are obvious.   But – at small scale – a software-only ECS would be great.
3. Some of the automation we do really should ideally be contributions to Ops Manager Director, rather than NHC itself.
4. We need to build tighter integration with Concourse for CI/CD that is aligned with Pivotal’s strategy.

We’re going to rally around Pivotal Ready Systems on VxRack SDDC as the vehicle for us to pull the roadmaps on 1, 2, 3 closer and closer together.

VMworld 2017: Continued Advances in Hybrid Cloud - EHC

If you’re coming here first – I strongly recommend reading the “Lessons Learnt” post in this series, here.  It will help with context, and understanding your options and choices.

Ok, with that context – lets talk about the Enterprise Hybrid Cloud (EHC) 4.1.2. 

EHC is designed to be a full cloud stack – built, designed, sustained as one full entity.  It’s analagous to VxRail/VxRack relative to vSAN/VCF in the “DIY” and “Consume” picture.   Some customers want to build clouds.  Some want to consume a cloud.

EHC is a turnkey IaaS focused on enterprise use cases and workloads – and built completely around the VMware stack.

EHC 4.1.2 is critical, and a big achievement for the team and customers for a couple reasons. 

The first is increased overall alignment with VMware’s stack, versions, and strategic direction.

The second is a big leap forward in automation, particularly on VxRail.

Here’s the whole scoop:

• VxRack SDDC support.   This is critical, because customers who are aligned with VMware view VMware Cloud Foundation as what it says in the name “the foundation for a cloud”.   Not supporting VCF/VxRack SDDC created some tricky mis-alignment.  
• VMware Validated Design alignment.   We are maniacal about using the VVD program as the baseline – and this also helps align EHC with the future of VMware Ready Systems, which also build on the VVD program on top of VCF and VxRack SDDC.
• Major software stack updates:
• VMware vRealize Automation 7.3 (another critical VMware/Dell EMC alignment point) which includes the addition of Microsoft Azure as a public cloud end point
• VMware vRealize Operations Manager 6.5
• VMware NSX for vSphere 6.2.7
• VMware vSphere ESXi 6.0.x
• Dell EMC ViPR 3.6
• Major platform Release Certification Matrix alignment
• VxBlock 6.0.5 – 6.0.13
• VxRail, 4.0.301
• Dell EMC Avamar 7.4
• Dell EMC Recover Point CL/EX 5.0.0
• Dell EMC Recover Point for VM 5.0.1
• Dell EMC VPLEX GeoSynchrony® 6.x
• CloudLink 6.0
• Huge updates for VxRail-based deployments – which is the easiest EHC path – period.
• 4 site multi-site object model.   This is something that EHC customers demanded – the ability to have a full cloud model that spanned sites, so workflows, templates, all policy behavior was able to operate across multiple vRealize Suite instances, and be replicated.
• Enhanced multi-site DR.  In EHC 4.1.1 on VxRail, we added Recoverpoint for VMs support.  In EHC 4.1.2 we have extended the multi-site policy engine and object model to DR on VxRail.
• Total automation.  In 4.1.1 we automated the install.  In 4.1.2 we can automate the full stack (including the full vRealize Suite) LCM on VxRail deployments.   Ultimately we will “hand over” this LCM responsibility to vRealize as VMware keeps enhancing their native capability here at which point it becomes available on VMware Ready Systems on VxRack SDDC.   For now though, this ultimate easy button is on EHC on VxRail.

That last one is worth a demo, because it’s that cool.

Ok – internalize what’s happening in that video.   Complete LCM of the full stack.  From VxRail itself, to NSX, to vRealize Automation/Business for Cloud/Operations, to RecoverPoint for VMs, to the Data Protection Suite for VMs.  All workflows maintained.  

That’s an amazing achievement.  

The automation framework (codenamed “Ozone”) was developed completely as a cloud native app, modularized with sets of microservices.   we cannot automate VxBlock deployments to the same degree (more complex, manual platform updates, ViPR/VPLEX considerations and more).   But it shows what is available now on VxRail with EHC.

It also shows where we will get VVDs and VMware Ready Systems directionally over time.  

It will take some time between us and VMware – but ultimately we know we need to make LCM easier more generally – and we will apply a lot of the learnings from EHC to accelerate VMware Ready Systems on VxRack SDDC and work with the VMware vRealize team to keep partnering about full stack LCM.

Pretty cool.   Would love your thoughts!

VMworld 2017: Continued Advances in Hybrid Clouds - Lessons Learnt.

4 years ago a great team of people responded to what we were starting to see over and over again: customers wanting to consume an on-premises cloud as part of a hybrid cloud.

Frequently, these customers had personal experience trying to instantiate their own “DIY” variant – picking hypervisors, picking Cloud Management Platforms (CMPs), and building their own standardized infrastructure stack.   Frequently they also learnt about just how hard it was to deploy, and how much harder it was to lifecycle the whole stack.

This brave set of individuals have been cloud builders now for 4 years.  

They gave birth to the Enterprise Hybrid Cloud – completely oriented around the VMware stack and targeted making instantiating and sustaining an enterprise-worthy IaaS as a turnkey stack.

2 years ago that same team delivered the first Native Hybrid Cloud – targeting developers and infrastructure teams trying to build cloud native apps and build DevOps cultures completely oriented around the Pivotal Cloud Foundry stack in a turnkey PaaS instantiation.

We’re now on EHC 4.1.2 and NHC 1.4 – and there are few folks with the degree of experience, scars, and knowledge about what it takes.  

It’s one thing to put together a stack and write it up.   It’s another thing entirely to take a platform approach and deliver/sustain a brand promise to sustain the platform from release to release.

What have we learnt?  A lot.

• Forget doing this on a set of “what ever you have” infrastructure.  It’s not about the infrastructure, but variation at the bottom is insanely difficult.   We quickly stopped offering EHC on “bring your own mess”.   You can build a cloud on your own of course – but good luck.
• Doing it on traditional 3-tier infrastructure – even when it’s a VxBlock is still almost as hard.   We have to abstract the storage using things like ViPR (adds complexity), and the very manual process driven lifecycle management of the VxBlock (and remember, we do this more and better than anyone else) through the Release Certification Matrix is hard.   VMware and Dell EMC have MASSIVE customers on VxBlock, and we will continue to support them and evolve EHC – but we know that this cannot be sustained forever.
• HCI is a huge simplifier.  As we introduced VxRail – we were able to make massive order-of-magnitude leaps in automation of the upper parts of the stack.  It’s not a coincidence that our EHC automation on VxRail is far beyond what we do on VxBlock.   It’s not a coincidence that EHC is now available on VxRack (both SDDC and FLEX).   It’s not a coincidence that NHC was born on VxRail and VxRack FLEX, and is now available in early access on VxRack SDDC
• When your offer is all about LCM – versioning of elements is critical.  It’s important for people who specialize in one part of the stack, the features/functions of said stack to internalize this.   When you look at vRealize Automation, Operations, vCO, NSX, vSphere all as linked – how you version the whole thing is really, really hard.  An example is that many EHC customers felt a long “pause” before we versioned from vRealize 6.5 to vRealize 7.x   There were reasons.  There were periods where you couldn’t brownfield update workflows.  There were periods where NSX and vRealize versioning was out of sync.   Add into this that customers needed security fixes on another interval pace – and validation of the whole stack in those periods was very hard.   Huge progress was made, but also hard lessons learnt.
• We have a lot to do to simplify the lifecycle of the upper parts of the stack.   There are big improvement in vRealize Automation 7.3 with out-of-the-box integration with Puppet Enterprise, and since vRealize Automation 7.2 there has been out-of-the-box integration with ServiceNow.  These are critical ecosystem partners in EHC, but also what our customers want generally.   That said – we have GOT to make big leaps forward together with VMware around full vRealize Suite LCM, and we have, and will.   Likewise, with NHC, we could use Pivotal Ops Manager to help with core LCM – but the concept of LCM has to extend to the whole ecosystem around the stack – Concourse for example.

I want to be clear.  The Dell Technologies (VMware, Pivotal, Dell EMC) technologies here are best of breed.  We have more maturity about sustaining these stacks than anywhere else.  

We’re continuing down this path.   Our customers need turnkey cloud stacks more than ever.   But together with EHC and NHC experience, as well as the joint development with Microsoft around Azure Stack has shown us something else:

1. We have to embrace a more “guided” DIY path, not only maniacally follow the turnkey path.  Not only do some customers want that path (“consume” at the virtual infra layer, and DIY at the cloud layer) but it creates more alignment and a faster vehicle for software releases.  This is what VMware Ready Systems and Pivotal Ready Systems are all about.   They assume a “consume” path for the underlying infrastructure using VxRack SDDC and then leverage VMware Validated Designs to assist customers in building their own cloud.   Furthermore, as native LCM improves (see below), these get closer and closer to the value of EHC/NHC.  
2. We have to recognize that each of us need to do our piece – and focus on how it all comes together.  VMware, Pivotal are the leaders in each of their domains – and have active efforts to refine the LCM of their own stacks.   I’m super pumped about what I see coming from the vRealize team, from the VCF team.   The efforts to construct VMware Cloud on AWS required (by definition) a huge effort around simplification of LCM of the stack.   Likewise, the learnings about KUBO and how to use BOSH for lifecycle managemnt at Pivotal is priceless.   

This is a big development – because clearly the work for LCM for each stack is best done in the team that is closest.  They get the feedback more directly from the customer.  They have a vested interest in nailing simplicity at their layer.

That all said – I want to be crystal clear. 

Today, if a customer wants a turnkey IaaS, PaaS – the answer is EHC/NHC.

Today, if a customer wants a turnkey a cloud foundation on which they can build DIY Clouds aligned with VMware Validated Designs, and the VMware and Pivotal LCM roadmaps – the answer is VMware Ready Systems and Pivotal Ready Systems built on VCF/VxRack SDDC.

So – what’s new at VMworld on this front?

• Read here for the latest on Enterprise Hybrid Cloud
• Read here for the latest on Native Hybrid Cloud
• Read here for the latest on VMware Ready Systems and Pivotal Ready Systems.

VMworld 2017: Thoughts on VMware Cloud on AWS

I love that finally the VMware Cloud on AWS is now out in the wild, and customers can try, buy, evaluate.   This may surprise some people – after all, from Dell EMC eyes, isn’t it bad?

Not these Dell EMC eyes.  I think it’s great.

The Dell Technology cloud strategy can be summarized in a couple strategic principles:

• We think that Cloud is really an operating model, not a place.
• We think that there is a clear market need for both on-premises and off-premises clouds.   Hybrid is the answer.   This means that technologies which “connect” on and off-premises models are very important.   NSX is an example.   vRealize is an example.  Data Protection is an example.
• We think that there there will be multiple cloud stacks – all optimizing for slightly different things and delivering multiple different services.   This means that technologies that “span” different clouds are important.  Pivotal Cloud Foundry is an example.  Pivotal Container Services is an example.  Boomi is an example.

Simple, and obvious right?   Operating model, not a place.  Hybrid.  Multi.

The biggest challenge I see at customers is them literally intractably stuck – trying to navigate choices.   Confused as all get out.   Listening to whomever says “I have the answer”.  It’s a great time to be a consultant :-)

VMware on AWS is something powerful in a time of confusion – a simplification.

Customers using the VMware software stack on premises now have a choice where they can directly extend that software defined compute, storage, network and run it on AWS hardware, in AWS datacenters.  

I was deeply skeptical at first – not understanding why a customer would want an IaaS on and IaaS – but that’s not what VMware Cloud on AWS is. 

The VMware Cloud on AWS is the SDC (vSphere), SDS (vSAN), and SDN (NSX) stacks from VMware running on AWS bare metal – provisioned and supported by VMware, and something they can buy directly from VMware.

It’s familiar to customers – to the point where it looks like a linked vCenter datacenter in the web client.   VMware Cloud on AWS runs any workload you can run on premises – not just cloud native ones. 

• Yes, I think it’s really cool that VMware Cloud on AWS helps customers use the public cloud in a way that is easy – not all apps can be rebuilt using cloud native principles (it’s not a technical barrier – sometimes there are other barriers).   It’s also a great way for VMware IP to be extended into the public cloud.
• Yes, I think it’s really cool that the Dell EMC Data Protection Suite for VMware is already built in and ready to go with the VMware Cloud on AWS.
• Yes, it’s not perfect – but it’s ready enough for day one.   There evident features/functions that are needed in the roadmap (from the top of my head - flat overlay NSX networking/peering, the ability to span AWS AZs for more resiliency, etc) but those will come over time.

But – what I REALLY like about it may not be what you think.

I like that it’s SIMPLE & CLEAR.   I like that it will SHINE A LIGHT on a topic of enormous confusion.

In one easy step, it clears up all the **ahem** fog there is about cloud being about straight up economics.  

I’m so tired of people claiming (without doing the math) about the economics of steady-state workloads, or workloads with high persistence:compute ratios in public cloud.  

Watch this.   I have a homework assignment for you dear reader! 

Look at the economics of VMware Cloud on AWS with pay-as-you go, 1 year commit, and 3 year commit pricing.   Assume a solid, but normal consolidation ratio. 

Then do a comparison with the relative economics of the DIRECT on premises peer with the same assumptions.   The direct peer is VxRack SDDC.

Do that comparison looking at VxRack SDDC – as 100% capital.  This is close to analagous to the 3 year VMware Cloud on AWS model assuming a 3 year depreciation term.    Also do that comparison VxRack SDDC via CloudFlex (which delivers a cloud economic model with built-in annual price declines, 100% opex monthly payments, and full right to scale down/return after 1 year).    This is close to analagous to the 1 year VMware Cloud on AWS model.   In both cases, make some assumptions about power/space/cooling – but otherwise it’s a 1:1 compare.

PLEASE share your findings in the comments.  I’ll update the post in a couple weeks as the dust settles.

The ability to solve the Gordian Knot of customers struggling with the the reasons for on/off-premises and capex/opex economic models by having a simple direct item for them to price compare will be very interesting!

VMworld 2017: making DIY HCI easier – vSAN Ready Nodes

While clearly I have a point of view (perhaps naturally a bias) towards customers choosing the “consume” path and choosing VxRail and VxRack if they want Hyper-Converged Infrastructure, I don’t want ANYONE to misunderstand and think that Dell EMC doesn’t lead the “DIY” route.  We do.

Consider:

• YES, a vSAN Ready Node is in essence, a server.  It’s a server on a VMware HCL.   vSAN Ready Nodes don’t differentiate even nearly as much as VxRail.   That said not all vSAN Ready Nodes are created equally.
• YES, the easiest “easy button” (and on this VMware and Dell EMC agree) for a customer who has standardized on vSphere and is ready for vSAN is VxRail.   BUT, there are huge numbers of vSAN Ready Node customers who chose the “DIY” route.

More vSAN Ready Node customers choose Dell EMC PowerEdge than any other vSAN Ready Node – by a long shot.

Why?  Well:

• DIY always gets access to tech faster – though of course, the customer does testing/validation at the system level.   That means that Dell PowerEdge 14G is supported now.  Support for 14G comes for VxRail in November.  If you need the latest hardware NOW (and can’t wait a couple months – even though you will likely spend that time doing stack-level testing), then vSAN Ready Nodes.
• Dell EMC Ready Nodes are always accurate.  Some don’t tweak past the base HCL test.  For example – vSAN 6.0 Ready Nodes will not ship with 512e HDDs while vSAN 6.5/6.6 will ship with either 512e or 512n so customers always get known good configs.
• More configurability than vSAN Ready Node competition - 3 models (640, 740, 740xd) available now plus 6 more launching in Sept.  Massive configure-to-order flexibility across cpu, mem, drive sizes and networking.   Interestingly even more configuration support exists in VxRail – but if you’re comparing vSAN Ready Nodes – there are FAR more variations with Dell EMC.
• BOSS boot (bigger, more robust than SD cards + allow for local log file capture) or redundant 16GB SD cards
• Dell EMC OpenManage™ integration for VMware vCenter integrates all of OM’s hardware management right into vCenter so there’s no need to switch mgmt. apps
• ProSupport™ – vSAN-trained support is contextual hardware support for an SDS environment & ProDeploy™ – installation and configuration of the hardware and the vSAN software.