« Looking back on 2017: A turbulent year but also a year of IT pragmatism | Main | Looking forward to 2018Part 2: Hint, its not about infrastructure. »

December 19, 2017


Feed You can follow this conversation by subscribing to the comment feed for this post.


*** Disclosure, I work for Datrium ***

Hi Chad, I hope you are well.

I have a problem with your characterization of 'build' vs. 'buy'. More on the 'build' side, and especially when you mention "vSphere + vSAN and pick the open ecosystem of servers that are part of the vSAN ReadyNodes HCL."

From where I stand, a customer picks a hypervisor, vSphere in this case, which already has software-defined-storage built-in and requires only a few clicks to enable. Then this customer adds an extra module that has been pre-integrated, let's say VIO. In this model, you are giving customers the hardware vendor flexibility, but the stack is a 'buy,' not a build. Just because you enable them to pick server vendors doesn't make it a 'build' solution or stack. That's just vendor choice.

'Build' require a more comprehensive set of assumptions. Examples: Pick hardware, Deploy Linux, deploy GlusterFS, deploy OpenStack, deploy Kubernetes, deploy Apache Mesos, now stitch it all together. 'Build' means that you are creating a solution out of disjointed components, and that is not the case for vSphere + vSAN with ReadyNode HCL servers. This is no different than buying a pre-assembled solution.

On the 'buy' model, what you can say is that because you pre-assemble the solution customers have an additional software that manages part of the stack in an integrated fashion.

Please note that I am not criticizing products or making this a competitive comment, but rather trying to debate on the definition of 'buy' vs. 'build'.




I've been thinking a lot about this build vs buy evolution we're in the middle of and my own conversion from a strict builder to a more mature buyer.

I'd love to chat (we only really get to chat on podcasts and at craps tables) about the details but I do want to question ReadyNodes as really build. I would class them closer to buy. A ReadyNode customer who loves iLO or UCS Manager has a small number of configs to choose from and is still exporting the expertise of picking SSDs, setting the performance to capacity, RAM to core, core to storage and other ratios a full roll-your-own VSAN setup would take.

Sure ReadyNodes are more flexible than EVO:RAIL was but it seems to me more about letting the customer choose the intangibles of the vendor relationship than building.

The comments to this entry are closed.

  • BlogWithIntegrity.com


  • 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.