Welcome to my Cloudscaling brothers and sisters? So – this post will be about “Why Cloudscaling” and “Why now?”.
Clearly – there is a real and growing model where customers are looking at different ways of building clouds. I don’t entirely agree with all the points Randy Bias’ post here (https://www.cloudscaling.com/blog/cloud-computing/an-openstack-dream-team/) – but I agree with his main point – that we’re a good match.
I **DO** think that there is a legitimate cloud model which is self-service, fully automated infrastructure on vSphere. Heck – I think I can prove it (a ton of Enterprise Hybrid Cloud customers using vSphere, vRealize Suite, Vblock, vCloud Air). Many LOVE it. Here’s an example – customer speaking in their own voice. It’s important to recognize a fundamental reality – MOST enterprise applications demand infrastructure that is resilient (aka platform 2 apps)
But… Randy is right at the same time, there’s another cloud architecture that exists – for applications “designed for failure”, “application-level resiliency”. Aka – the thing we call “Platform 3”. This has huge impacts for how you design IaaS, converged infrastructure, data fabrics and more.
So – the debate for every customers is:
- “do I deploy one architecture for BOTH platform 2 applications, and platform 3 applications (works fine, but costs way more $$$ and drives unnecessary complexity if you have more than an “light sprinkling of P3 workloads)
- “do I deploy two architectures and manage them as the applications go through their lifecycle?
This core debate is at the root of why EMC will be supporting VMware power Hybrid Clouds, and the VMware-Integrated Openstack (VIO) intiative, but our view is that we had to do more. That this is one of those cases where our independent model demanded a “native” Openstack intiative. BTW – I did a post on this debate here (including more on VMware’s VIO intiative), so if you want to double-click, well – click :-)
This “design your cloud for P2 vs. P3” is not an “OR”, but rather an “AND” in the market in general (and for many customers)… some specific customers may find that depending on their workloads, it may be an single one for both – in which case you need to design for P2 (resilient infrastructure) because that’s the lowest common denominator.
So – that said – why Cloudscaling and why now?
Read on for more!
The “first why” (why invest down this path now) was really answered above (customers demand, architectural fit – for both P2 stacks and P3 stacks), but I’ll elaborate.
If you’re EMC – you start to work like crazy to keep refining and taking share in the Infrastructure that support rich resilience (Platform 2) through things like XtremIO, VMAX3, VNX2, etc. You make sure that you build the best converged infrastructure to accelerate IaaS models that demand those capabilities (Vblock, EVO:RAIL). That’s good – and that’s the BIG SWATH OF THE MARKET.
But – you also face some harsh realities (those that don’t end up sideways) – the architecture of how platform 3 applications will be deployed – well, if we think it’s on a platform with rich infrastructure (not necessarily “hardware appliance resiliency” – could be “software based resiliency in the infrastructure layer”) – you’re adding value in dimensions where it’s not needed – and instead could be adding it in different dimensions. Ergo, VMAX3 is awesome, but it’s not ideal for P3 workloads.
This is the answer to the “Why now”.
You build the ViPR Object/HDFS layer. You acquire DSSD. You acquire ScaleIO. You build a software-only Isilon – and enhance ONEFS HDFS support. You start to think about “what would CI look like for these new workloads” – it’s not likely to be ideal for a Vblock, but could be something else (see thinking here).
The other thing you would do – you would start to double down on your own organic Openstack contributions. After all – in open source (which is at the center of these new platform 3 architectures), contributions is what counts, the rest is just talk :-) Starting this summer, that’s what we did.
Level of Contribution (LOC) for EMC = 42,857, but you can see that it went from zero to material quickly. This compares with favorably against NetApp (32,424) who’s been at it for longer than us and catching up fast on Solidfire (60,846) who has been focused on Openstack for admirably long, and is also huge Cinder contributor. BTW for perspective, that’s still dwarfed by VMware (326,080) – lest anyone say that VMware is not committed to Openstack!
…Even further ahead is HP (1,444,828) and Redhat (1,912,827). Not claiming that we AREN’T late to the party, and don’t have more to do – but we’re all in.
The result matters – here’s our core organic support for various releases (and some of the new stuff we added for Juno)
BTW – for those that are not in the release propose (ViPR and ScaleIO), the EMC github repo for openstack stuff is here.
But… All that, wasn’t enough – not even close.
The biggest barrier to Openstack deployment is well understood. Rough edges in Openstack exist to be sure – but its the overall complexity of deploying and maintaining Openstack is widely understood to be a challenge. I’ve personally spoken with customers that have many thousands of Nova instances deployed (that’s pretty big!) – and they all conclude that the cost of deploying and maintaining are comparable to a commercial software product, but instead come in the form of staff and services.
There is a clear opportunity to “harden” Openstack deployments.
Now – everyone is racing to this target at this point – each through a variety of means. Some focus on “managed private off-premises”. Some have focused on hardening a highly modified distribution. Some are ultra services focused.
We think that the biggest opportunity for Openstack is in the private cloud domain. EMC’s approach is to support VMware’s approach, but also on the part of the Federation that is EMC II, we must deliver a solution for customers that want a “open source appliance targeting purely P3 workloads”.
If we wanted to accelerate that… Well, that’s the answer to “Why Cloudscaling”. They have have had a lot of experience (as one of the earliest “enterprise Openstack” startups) in the space. Their GTM is “Your Hardware, Your Data Center” – and while they are open on hardware, they drive certain commodity hardware platforms they have the most experience with. In the end, they deliver to their customers something called “Open Cloud System”.
This (particularly the expertise!) can help accelerate creating Enterprise Openstack appliances – yes on things like Vblock, but more importantly – in 2015, on alternate converged infrastructure models – designed from the ground up for Platform 3 workloads exclusively, with a maniacal focus on that domain. This is linked to the VCE topic I talked about here.
We also really liked that Cloudscaling for the most part stays on the track of using the core Apache trunk of Openstack. That’s not to say that various distros don’t have strengths/weaknesses – but our view is that for the “hardened appliance” model – the closer you stay to the open source trunk, the better. Leverage the heck out of it!
Of course, there’s another advantage – which is that naturally, many customers that choose Openstack will not choose OCS and our appliance/single support model… for a variety of reasons. But, they will want the core platform integration that exist generally. So, of COURSE, EMC will continue to partner with the ecosystem (Red Hat, Ubuntu, Canonical, Mirantis, etc).
So – EMC’s Openstack GTM will look like the below..
… with the addition of supporting VMware’s VIO initiative for customers that like that model.
Fundamentally – today’s announcement is an example of the Federation “Choice” principle. Huge work around the Enterprise Hybrid Cloud Federation SDDC edition + the beginnings of a Enterprise Hybrid Cloud Openstack edition.
Cool! Cloudscaling team – welcome to EMC!