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

Verify your Comment

Previewing your Comment

This is only a preview. Your comment has not yet been posted.

Your comment could not be posted. Error type:
Your comment has been saved. Comments are moderated and will not appear until approved by the author. Post another comment

The letters and numbers you entered did not match the image. Please try again.

As a final step before posting your comment, enter the letters and numbers you see in the image below. This prevents automated programs from posting comments.

Having trouble reading this image? View an alternate.


Post a comment

Comments are moderated, and will not appear until the author has approved them.

Your Information

(Name and email address are required. Email address will not be displayed with the comment.)

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