Insights, Best Practices and Forward Thinking from the Customer Facing Team, Solution Architects and Leaders on Extreme Performance Applications, Infrastructure, Storage and the Real-World Impact Possible

The Register asks why you would put traditional enterprise workloads on an All Flash Array? Here's why.

by VIOLIN SYSTEMS on February 13, 2015

The Register asks: why would you put traditional enterprise workloads on All Flash Arrays (AFA)?

infographic-same-cost

Here are some reasons why.

Because they don’t run batch jobs in ½ the time but in 1/10th time or 1/50th the time, and suddenly that batch job can be run as a real time dashboard, or the batch order processing that produced the morning report can give you the results before the end of today.

Because the reason the legacy batch job actually fit in the morning window is due to the fact that you had eliminated all the things you really wanted to do and left in only what you absolutely needed to.

Because when you are migrating apps to new storage as you continuously refresh your data center, you no longer need to wonder if a given set of apps will interfere with each other when they share a given storage array.

Because the latency for the user in front of the screen is directly associated with the storage backend holding the data they are trying to call up. And user efficiency has long been shown to exponentially improve with shortened computer response times.

Do you remember what it was like using your laptop before you put an SSD in it (or got a Macbook)? Would you ever go back to a HDD? Then, why do you think that anything worse than HDD IOPs/latency is OK for your VDI users?
But that’s not legacy, you might say.
Sure it is; from the user perspective, it’s the same app. It is just being run differently on the backend.

How much improvement can a user in front of a keyboard see? Enough that we have had customers with highly-instrumented call center VDI setups (who can tell you every possible statistic imaginable), switch from MLC array to SLC arrays and being fully cost-justified due to the improved call handling rate.

Yes - I bet you never thought of call center operators as a high performance workload?
Turns out when the latency for the user in front of the screen matters, the differences in response times from your storage become anything but insignificant.

How many times have to been dealing any form of customer representative of a company who had to tell you, "I'm sorry my computer system is slow"? If you speed everyone one of those delays up even a little, much less slash them, how many more customers will be handled by the same (or fewer reps)? How much more work gets done when whatever you want from the system returns immediately rather than after you go get a cup of coffee?

How about because it will take far fewer servers to run the same set of batch jobs on an AFA?
First, because if the job finishes in ½, 1/10th, 1/50th the time, then the same server can handle 2X, 10X, 50X the number of jobs in the same amount of time.
Second, when the available storage IOPs are huge and the latency low, you don’t need giant amounts of data cached in server DRAM, and so the same server can run more jobs at the same time.

We have done the math with some of the largest companies in the world. Once you include the floor space, power, cooling, and OPEX considerations such as backup and restore speed, not needing multiple, full copies of giant data sets for testing/QA because the array with the primary dataset can handle both the live and test loads at the same time (using thin snaps, etc.), then it is evident that you can have flash performance for the price of disk storage.

And we are hardly the only ones saying this.

Really, the question should be why would you put your enterprise work load anywhere but an AFA?