Re: Same architecture as others... what's different?
(Disclosure - Kaminario employee here)
Good questions are being asked here, which confirms that there's a lot of (marketing) noise in the all-flash industry.
I'll try to address question - "same architecture - what's different?".
There's the scalability aspect:
Scale-up, which allows adding more capacity under the management and name space of the array but without the ability to add compute (==performance) to the array.
Scale-out, which allows adding more capacity and compute to the array, which will bump up the $/GB when all you need is more capacity.
So what's different? Kaminario's architecture can scale-up and scale-out, allowing customers to grow their storage according to their needs in the most cost efficient way. The storage vendors you've mentioned will be limited to only one way of scaling (one vendor doesn't really have a product...)
There's the data reduction aspect:
Dedup and compression are now a commodity - notice that the storage vendors you've mentioned do not necessarily support them. Why is it important? Gain more GB for your $, as simple as that.
So what's different? True, Kaminario is not the only storage vendor to have inline deduplication and inline compression, however it is the only vendor that can enable or disable deduplication on the LUN level, so you don't waste cycles (==performance) on DB applications that do not dedup.
And lastly, how does the MLC-TLC-3D-NAND come into play?
Flash prices are declining, SSD capacities are getting bigger and new technologies are being introduced to the market. Integrating these technologies to storage arrays require them to manage more capacity and metadata using their existing architectures.
So what's different? Kaminario's architecture is not limited to having all the metadata in DRAM, or in other words, is not limited on the amount of capacity it can manage or the data reduction it can achieve. Combine this architectural differentiation with the ability to scale-out, and you have yourself the most cost-efficient AFA without compromises.
To your more practical questions -
How many VMs can be cloned? As many as your ESX cluster allows you.
Time to manage LUNs and FC? Reduced to none (I guess you do have to create and delete LUNs once in a while...)
Hope this answers the questions