The deal is not closed and it’s not useful to speculate too much on what’s going to occur post-close. Everything is looking great and it looks like we’ll be a combined entity relatively soon. At that point there will be further clarity. But let me talk about what we already have stated publicly. What we’ve stated is that the converged platform business of the combined entity would continue to partner with Cisco as the core technology ingredient inside Vblock and VxBlock. The reason for that is pretty simple and straightforward: Customers are voting with their feet and they like that system design. The second thing is we’re going to continue to use Cisco universally as the networking componentry inside our hyperconverged portfolios. We’ve stated that publicly and customers can move forward with confidence knowing that in the future that’s not going to change.
The other thing we’ve stated publicly is that inside the hyperconverged infrastructure appliance business, a huge component of the system cost is actually the x86 server. While the software provides the bulk of the value, the cost of goods is very much wrapped up inside the hardware platform.
+ MORE ON NETWORK WORLD Hyperconverged infrastructure requires policy-based security +
A hypothetical example: Inside a VxRail appliance, and this would be analogous to anybody with a hyperconverged appliance, if the list price for an entry unit is $60K, it’s very likely that the cost of goods for hardware is somewhere around $30K. What that means is that for anybody to be a viable, at-scale player in the hyperconverged market - as hyperconverged goes from a $1 billion to $2 billion market to becoming a tens of billions of dollars market over the next few years - if you do not have access to a global, world-class, just-in-time supply chain of x86 componentry that can leverage everything that comes from the entire ecosystem quickly, you will not be able to compete effectively as a hyperconverged player. You will simply not be able to have a critical component that is inside the stack. What should customers expect inside our hyperconverged appliances? Would we be leveraging the Dell PowerEdge supply chain and innovation and speed and time to market? Heck yeah.
Just so I’m clear, will there continue to be Dell converged infrastructure solutions and VCE converged infrastructure solutions?
Ultimately, over time there would be a single combined entity. The idea of calling it Dell Products and EMC Products fades to black. I think the other question that you’re asking is, will some of those products that are currently Dell products continue?
I think it’s more of a branding and positioning issue, so will the converged and hyperconverged infrastructure solutions be VCE branded or Dell branded? What would people expect from that?
We’re working through those things. The VCE brand is a very strong brand. The VCE brand was originally born as a company brand. In other words, VCE, Inc., a company. But VCE really represents a product brand. It’s a brand promise that is pretty simple. It basically says if you’re at the point where you’ve chosen to no longer build what is not a differentiator for you and instead want to view that as a commodity you now buy and consume, we deliver a turnkey outcome. Ultimately I think that will continue to move forward for things that are inside the combined entity’s portfolio.
You talked about your position on the Cisco relationship but is there any risk that Cisco changes the relationship? They’re going to be competing head-on against Dell/EMC. They’re doing a lot of work with NetApp already. I see that IDC has them as the leader in the certified reference system. What if Cisco changes direction?
Is there a risk of that? The short answer is no, period, end of sentence. Let me explain. The first thing that’s important to understand is actually rooted in this idea of what are certified systems or reference architectures relative to a converged system? In a converged system, the entirety of the system is bought, assembled, designed, supported and lifecycled through a single entity. A reference architecture is where different componentry is brought together and assembled through distributors or resellers and then delivered as a combined set of parts to the customer. The real litmus test is what happens six months from now when there needs to be an update? Who will you turn to? In a converged system the answer would be VCE. In referenced architecture it would be Cisco, NetApp and whomever.
There is a very important distinction. In one case I’m buying a car. In the other case I’m assembling a car. I’m doing it with a distributor or a partner as my helper but I’m buying the components, not the car. Business people understand these are two very different value propositions. What was really interesting about that IDC study is that it highlighted how converged systems are growing and hyperconverged systems are growing even faster but reference architectures are actually declining. Customers are getting smart. They don’t want to build this anymore. A reference architecture is de-risk but build. There’s a validation of the work but the responsibility is still fundamentally yours. When you go to converged and hyperconverged, it’s our problem.
Not only do we have a great partnership with Cisco, not only do we have strategic alignment but very importantly, VCE, as a part of EMC and ultimately of Dell, is the single largest UCS customer in the world. We buy Cisco componentry, it goes into a factory and out the door comes Vblock and VxBlock products that we own and support. Let’s just say hypothetically Cisco says -- Forget it, I want to do something different and we want to compete directly. Do you think that they would say no to their single largest customer for all of UCS?
It seems unlikely.
It seems unlikely. And we would continue to go down that path regardless of what Cisco chooses to do. In other words, the risk is nonexistent because this is really an OEM structure. Above and beyond that, we have a partnership, we have alignment, we have more customers than anywhere else and, by the way, that business is growing like gangbusters. Those are all reinforcing points but the main thing is that the business structure means that we have responsibility for the customer. They’re an OEM supplier to us. We have longstanding support agreements and buying models that will allow us to continue to operate that model no matter what.
I spoke with Hewlett Packard Enterprise CEO Meg Whitman in the spring and a lot of what we talked about was their approach to converged and hyperconverged infrastructure, which is a big part of her strategy. What do you think of their whole Composable Infrastructure strategy they’re rolling out?
Our strategy and theirs are pretty divergent. We believe that no one has shrunk their way to success. Customers are telling us that as they are moving through this very disruptive time they want to have fewer technology partners not more. We’re entering into a period of consolidation which we’re going to lead. Inside that world, one element of the technology stack - one element - is server design. There are software changes that are going on; there are changes in abstraction models, containerization, etc. There are dramatic changes in sub-componentry, whether it’s flash, NAND, next-generation non-volatile memory, all that stuff. The one thing inside that path is server design. We went through an era where servers were towers and then towers became racks, which dominated for a really long time. Then blades became a huge growth factor. People were using lots of externalized storage and having extremely dense memory and compute designs where blades ruled the day. By the way, that’s why bladed designs win inside converged infrastructure, because they have the densest CPU/memory configurations and they attach to externalized storage inside a converged infrastructure design.
However, as we move to increasing use of hyperconverged designs, the server is the least interesting component. The more interesting component is the software stack that drives it. We’re seeing all of those hyperconverged systems be built on, once again, rack mount. Why is rack mount resurgent? In hyperconverged, there is no longer an externalized storage array. In other words, the server needs to have persistence. It needs to have dense flash, or for people who are still living in the previous generation, flash and magnetic hybrids. That’s a new server design point where you have modularity of compute, network fabric, memory persistence and longterm persistent storage.
Today, the primary use cases for that are where workloads are wildly dynamic, cloud native workloads, workloads that are extremely elastic, environments where the customers’ environments have wildly changing ratios of compute, network and storage over time. The composable server market is a fraction of the blade market, it’s a fraction of the rack mount market, it’s a fraction of the CI market, it’s a fraction of the ACI market. It’s much, much smaller. Over time, those workloads will become more dominant. The new workloads that are cloud native are going to grow in count. Will composable servers play a critical role inside that ecosystem? The answer is yeah. Is that where the innovation really lies or do you think that the innovation is actually inside Cloud Foundry? Do you think the innovation is in Mesos? Do you think the innovation is inside the next-generation software stacks that drive that infrastructure?
Composable systems will be part of the answer. You bet. Will we see composable server designs go from being a nit to becoming more than a nit? Yeah. But I think the bulk of the value will actually be in the software that runs on those stacks. The difference, of course, between HPE and Dell Technologies is not only will we have the best industry server platforms, composable and others, but we’ll also have the strongest software portfolio, not only in Dell/EMC, but also in VMware and Pivotal.
Long term, will customers simply move the bulk of their workloads into the cloud versus building their own private or hybrid clouds?
It’s a really good question. When I find a customer who says: We’re all in on public cloud, they expect me to push back on that. I actually ask: What percentage of your workloads currently run in the public cloud? Not many but that’s where we’re going to go. I say, fantastic. I’d encourage you to do that as quickly as you possibly can. What I’ve found is that customers don’t have a good grasp of where public cloud models are ideal and where they’re less ideal. They don’t have a good grasp on public cloud economic models, where they’re fantastic and where they’re poor.
The best cloud model is where you’re using SaaS. Certain workloads are moving to SaaS at the speed of light. Moving to a SaaS model is something where, after they’re done, customers say: Wow! That was really good. It is perhaps the ultimate manifestation of the buy versus build choice. The next thing they realize is where the public cloud IaaS is the strongest fit for them are for workloads that are extremely elastic, workloads that scale up, down, which is very common for cloud-native workloads, the application is designed to scale dynamically. Within the enterprise today, that’s a small subset of the workloads but it’s an important and growing set.
There are certain workloads that are economically not well suited to the cloud, if the workload is static. I’ll give you an example. S3 storage from AWS is about three times as expensive as a VMAX, which is not the least expensive storage platform in the market if you are going to run a transactional workload for three years. By the way, that’s not including ingress and egress costs. Customers get to a point where they’re more educated about where do I put workloads. Where do I put SaaS? Where do I put IaaS? Where do I put PaaS? Where do I put some workloads that are governed and workloads that are not governed? Will the public cloud play a more important role inside every enterprise? The answer is yes. We’re trying to support and drive that as quickly as we can and we’re trying to make things like Cloud Foundry be the best way to deploy those new applications on top of Azure, on top of AWS or on-premise.
However, there is clearly going to be an enormous amount of footprint where the customers realize -- I also need an on-premises part of Azure. I need an on-premises VMware-powered cloud. I need an on-premises cloud native optimized cloud stack. It will be both.
As you look out on the year ahead, what should folks expect from VCE?
They should expect an incredible torrent of customer focus and innovation. They should expect that our hyperconverged portfolio is going to rapidly grow and we anticipate that we will very quickly be the No.1 hyperconverged infrastructure player. They should expect that we’re going to leverage the Dell technology portfolio like crazy in hyperconverged and they should expect us to stay aligned with Cisco in terms of what we do in converged and blade-oriented converged system design. The last thing I would say is we will have a unique superpower inside the whole IT ecosystem and that superpower is pretty simple. I’ll ask it to you as a question, John. Do you think that tomorrow, more customers will have some form of utility economic model even for their on-premises IT than they do today?
Of course.
The answer is obvious. Of course they would. Will it all be utility economic models? No. There are going to be some use cases where capital that depreciates is better than a utility but more customers than today will use utility models. Why doesn’t EMC do that a ton today? Why doesn’t HP do that a ton today? Why doesn’t IBM do that a ton today? Why doesn’t anybody do a ton of that model since clearly customers want to do more of that?
I’m assuming that’s a rhetorical question and you’re going to give me a great answer to that.
What is the best time of the year to buy something from HP or Cisco or EMC?
End of the quarter.
End of the quarter and if you have to pick a quarter where you want to get the best possible price, what quarter would it be.
Fourth quarter.
The end of their fiscal year. Why is that the case?
Customers are trained for it.