Yeah, sure – it looks like leaning into the flash media transition (2016 is the year of all-flash for transactional workloads), but someone who does this isn’t really “disrupting themselves”, they are “not being silly”. BTW – I don’t want to minimize this – it’s a far larger immediate customer impact than many other things that are more “disruptive”.
Sure – it looks like leaning into HCI (more on that here) – but likewise, while it’s early (and much smaller market that CI) – it’s obvious about the growth trajectory shows that customers want more simplicity, want operational complexity removed, and are willing to make some trade-offs to make that happen. Again – important, all over it, but not fundamentally “disruptive” (not at least at this point anymore). It’s in the other phase – disruption in flight, and scaling up :-)
I’ll tell you what I think early stage self-disruption looks like.
- It looks like what we’re doing at the OpenStack Day in Santa Clara this week: https://www.openstacksv.com/2016/08/02/turnkey-openstack-iaas-ready-set-go/ You’ll see more on that in New York at the OpenStack Day there on August 23-24. We aim to make OpenStack/KVM more turnkey (deploy, scale, lifecycle) than anything else out there. We’re going to do the same for the Photon Platform, and other stacks. We may fail, but we’re going to try :-) And, in general, when we try, we do something cool.
- It looks like at the RackHD/CF Bare-metal CPI work here: https://www.cloudfoundry.org/bosh-rackhd-cpi-running-cloud-foundry-on-bare-metal-with-bosh-2/ . RackHD plays a critical foundational “abstraction of a control point” for low-level infrastructure. It plays a critical role in our HCI stacks, and management and orchestration thinking… but here, it’s being used in an interesting use case, Cloud Foundry (which uses containers) on bare-metal. Now, I think MOST customers will run CF on vSphere, on the Photon Platform, on OpenStack/KVM as an intermediary abstraction – but an interesting option for some customer (to be sure!).
- It looks like the Apache Mesos 1.0 experimental storage support where EMC{code} team made critical contributions. https://blog.emccode.com/2016/07/29/apache-mesos-1-0-integrates-code-projects-for-experimental-storage-support/
- It looks like this cool new VMware patent: http://www.theregister.co.uk/2016/08/02/vmware_files_patent_os_hot_swaps/. People claiming that this isn’t needed for properly written apps (in some of the comments for example) are missing the point that: a) there’s a huge impact for current apps; b) there are many go-forward use cases where this could have a massive impact.
- It looks like “UniK” - a unikernel project which could have a huge impact in the IoT domain: https://github.com/emc-advanced-dev/unik
- It looks like taking the cool (literally!) developments built for eBay by the Dell Extreme Scale Infrastructure team (soon to be my brothers/sisters!) – and making it generally applicable to the web-scale/hyper-scale markets: http://www.nextplatform.com/2016/07/18/hpc-flows-hyperscale-dell-triton/
I love a comment in response to the video: “Custom 200 watt Xeon CPU? 400 watt per node? Either that is crazy or I heard wrong :D”
Now, each of these is furiously contested (trust me – I often find myself in the middle :-) with people passionately/furiously arguing for, and against each - but that’s the essence of self-disruption.
Inside, I get people saying “this isn’t relevant” or “this doesn’t align with the strategy”, or “this isn’t material to revenue” – to which I respond “that’s what self-disruption looks like and feels like in early stages”.
Will some not pan out? Sure. That’s OK. The fact that they exist (always with small teams, working hard, pushing against “inertia”) is a health sign of self-disruption.
