Over on ITToolbox the age old subject of dual versus single vendor strategy has raised its head again.
This time, the consensus, apart from yours truly, was that a single vendor strategy was best - mostly because it is easier to implement.
I'm still of the opinion that a correctly executed dual-vendor strategy works well and can be achieved without the headache people think is involved. Here's some pointers as a recap.
- Standardise Your Services. I've seen many sites where a particular vendor is chosen over another for certain services - for instance using EMC for remotely replicated storage and HDS for non-replicated. If you want a real dual-vendor environment, each platform should offer the same services (unless by real exception).
- Standardise Your Support Matrix. Here's another issue; using one vendor for Windows and another for Unix because of things like driver or multi-pathing support.
- Standardise your Configuration. Keep things consistent. Create a design which you treat as consistent between vendors; for instance, in an Enterprise array, create a standard model which shows front-end port/cache/disk ratios and set a "module" size. This may be 8 FEPs/100 hosts/100GB. This becomes your purchasing unit when requesting quotes.
- Standardise Your Provisioning. Lots gets said about having to train staff twice or maintain two teams. This just isn't necessary. What is important is to document how storage is selected and provisioned (port choice, masking, LUN size etc).
- Standardise Your Offering. Give your customers no reason to question where there storage comes from. All they care about is availability, performance.
Ok there are some problems with dual-vendor'ing.
- Implementing a common tool set. No-one really fully supports multi-vendor provisioning. You will have to use more than one tool. Accept it. You can mitigate the problem however, by sensible scripting where necessary. This includes creating scripts which will do failover/replication support on HDS and EMC equipment. It can be done but needs to be thought through.
- Migration. Moving data from one platform to another will be problematic cross-vendor. However there are tools out there to do it - host and fabric based (even some array-based tools). Migration techniques need to be given serious thought before you spread data far and wide.
- Functionality. Not all vendors are the same and functionality is an issue. For instance, until recently the "big-boys" didn't do thin provisioning. You may have to compromise on your functionality or accept a limited amount of "one vendor only" functions.
Dual vendor is not for everyone. Size and complexity of environment will determine whether you feel comfortable with investing the time to manage dual (or even multi) vendors. However it can work and save you a shed load of cash into the bargain.
Posts
2 comments:
Most surveys I've seen show that customers would rather upgrade their existing systems or go to a new set of systems with their current vendor than start with a new vendor. Familiarity breeds comfort.
That said, benefits to customers who implement or consider multiple vendors are the option to optimize for different environments, playing to vendors' strengths, and of course, keeping vendors honest in terms of costs. If you have a fallback plan (not a backup plan as that's different entirely), they will be less likely to be demanding the highest prices available.
While it's fun, as a vendor, to highlight "take outs" where vendors are swapped, the truth is that many customers have multiple vendors installed, and it makes sense to act as a drop-in complement to the existing infrastructure.
- Louis Gray (BlueArc)
Also worth considering that over time no-one will operate a single vendor policy as eventually IT shops will change supplier and not be able to migrate completely from the old to the new in one weekend! So by implication everyone will move dual vendor.
Post a Comment