During my interview for the lead QA position at Parascale, the company’s founder, Cameron Bahar, asked me what worries me most about quality.  Coming from a prominent storage appliance vendor (hardware + software) my answer was immediate: Interoperability.

Here’s why this scares me (hypothetical, yet realistic, numbers):

* Hardware Driver Versions: 3 (3)
* Hardware Head Models: 6 (3×6=18)
* Disk Shelf Types: 3 (18×3=54)
* Disk Sizes: 10 (54×10=540)
* Disk Types: 2 (540×2=1080)
* Clustering Options: 3+ (1080×3=3240)
* Network Cards: 6 (3240×6=19440)

With this many options, a single NAS test case has to be executed 19,000 times to qualify the hardware for a single software release.  Multiply that by 1,000 test cases and you have 19 million individual test executions per software release.

The incumbent large storage vendors approach this problem in two ways: 1) they build a football stadium sized interoperability test lab, or 2) denial - they pretend the problem doesn’t exist.  Either way, their customers pay.  They pay for the test lab, the years-long release cycles, the business outages due to bugs, or, as is more likely the case, all of the preceding.  Stadium-sized labs might be impressive, but somebody has to pay for them.  Guess who?

Cameron explained to me how Parascale’s pure software approach eliminates these problems.  Parascale Cloud Storage (PCS) software is designed to work with commodity hardware, running standard 32 or 64 bit Linux operating systems.  The hardware is already qualified to work with the operating system by hardware vendors (http://www.redhat.com/rhel/compatibility/hardware/), so our test and release cycles are significantly more efficient.  We just test our software on standard platforms.

Further, PCS has no hardware dependency, so a complete distributed storage cloud can be developed and tested on virtual machines.  My testing workstation includes NAS client virtual machines (VMs), several Storage Node VMs, and two Control Node VMs.  I can easily revert the virtual machines to their stable snapshots and reinstall our software.  Of course we test with hardware too for large scale system or performance testing, but much of the functional qualification testing can be done with VMs.  This is why our software costs less.  Testbeds are cheap when you don’t sell proprietary hardware.

Thanks, Cameron.

Appliance storage vendors can only give away Frisbees and key chains at trade shows.  If you want to evaluate their solution, you need their hardware.  So you order it, you clear the space in your lab, you wait, you wait, you wait, the crates arrive, you wait, the hardware is racked and cabled, you wait, the network services are configured, you wait, you wait…  Now you can try it.  What if you don’t like it?  More of the same.  The appliance approach makes it painful to try the product.

Did I mention there’s a lot of waiting with storage appliances?

Potential customers can download an entire PCS cloud similar to the one I use for testing from our site and try it on just a single host (http://www.parascale.com/index.php/library/evaluating-parascale/download-parascale-software).  The whole pre-configured VM cloud fits on a USB thumbdrive that you can carry around in your pocket.  Better than a Frisbee, right?

This is why I’m excited about Parascale.  Proprietary appliance hardware is an albatross that costs customers money.  Inefficient testing translates to an expensive product.  This is why software clouds are the future.  And Parascale is the bleeding edge.

Todd Shoenfelt
Parascale Lead QA Engineer