VMware vExpert

Disclaimer

  • Any views or opinions expressed here are strictly my own. I am solely responsible for all content published here. This is a personal blog, not a VCE blog. Content published here is not read, reviewed, or approved in advance by VCE and does not necessarily represent or reflect the views or opinions of VCE or any of its parent companies, partners or affiliates.
BlogWithIntegrity.com

Advertising

Recent Twitter Updates

    follow me on Twitter

    Enter your email address:

    Delivered by FeedBurner

    « Snippets | Main | VMware Ninja - Pulling Guest Disk Usage from the vCenter DB using Excel and Microsoft Query »

    03/15/2010

    Comments

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

    Chuck Hollis

    I think I'd disagree with you.

    My bet (and personal experience) is that service provider tenants want to know (a) what service they've paid for, (b) what service they're getting, and ultimately (c) is there a better offer for the service level I need?

    Breaking it down to exact portions of data on specific media (which can change several times per second) seems excessive and unwarranted for most tenant requirements. I would hope that the VCE team spoke of FAST v2 as well and sub-LUN tiering.

    To my way of thinking, there's a couple of ways to price FAST fairly. First, here's a give service level (IOps and response times) -- the fact that the service provider can deliver it with a mix of flash and SATA is an opportunity for margin expansion. Second, you signed up for a low service level, here's a "surge" capability that's transparently available (and paid for) should it be required.

    Most SPs think they're selling an SLA. Most of the time, though, they're selling insurance that the SLA was wrong :-)

    Thanks for the post ... we need to do a better job here.

    -- Chuck

    Jeramiah Dooley

    Honestly, I hope we can get to the position you describe with our customers, it would certainly solve a lot of the issues we are facing. I think our primary challenge in bringing these services to market are of our own making, but are challenges none the less. We have worked hard to make sure that we are positioning our Enterprise Cloud services in a way that our SMB/Mid-enterprise customers can relate to, and see the business value in, and I think you would be surprised at the level of transparency that our customers demand of us. It's not at all out of the norm for us to have fairly in-depth conversations with prospects on how we do what we do, not just the SLA we provide (or the insurance we are selling in case the SLA was wrong!) in our offerings.

    Some of that push-back is internal (educating the sales teams), but much of it is driven externally. The desire to know exactly where a particular VM lives with respect to the storage tiering available is a direct request from a customer, as he wants it to show the value of the solution to his execs. The hesitancy to thin-provision so as to better show the value/differentiation of our offerings is another place this shows up.

    Little to none of that do I expect our partners to fix for us; that being said, there are some ways to implement the current feature-sets that help us better manage the infrastructure (I'm sure there might be some margin expansion in there... :-) AND give the customers what they are asking for. Our products are successful and growing as they are now, and further advances in efficiency and management by ANY of our partners can only provide for more of the same.

    Andrew Mametz

    Ahhh Pareto strikes again. I think the dilemma that is created internally, is caused by trying to cater the infrastructure to a small segment of the existing or prospective users. While it is true that some (to stay with Pareto we'll call it 20%) of the customers/prospects are concerned about I/O and transparent storage views; the majority are simply in it for the "just make it work" results. So spinning off of what Chuck said, the "Insurance that the SLA was wrong approach" is closer to how I'm having to position this product today. Users of the platform won't question much unless performance is being affected. The situation that I wouldn't want to get into is, a poorly performing DB server or App server that is analyzed to be running on "tiered" storage for what (at that point at least) will be considered the financial benefit of the service provider and nothing more. I/O latency matched with perceived storage design failures would be akin to discovering (after years of living in it) that your house was completely wired incorrectly. When things were working, you were fine, but once that discovery is made, you hate the house and subsequently the builder. In the SP world that is known as churn.

    Not sure I have a clear answer...although a premium offered to customers for guaranteed I/O might be a way to appease the more demanding customer and yet still let the entire infrastructure reap the rewards of tiered storage.

    Keep blogging...conversations like these will advance the product sets and offerings much faster than designing in a one company box.

    -Andrew

    The comments to this entry are closed.