The first post described the primary impacts of the FAST technology, and noted similarities / synergies between the virtualization of servers and the continuing virtualization of storage.
The second post juxtaposed FAST technology with other storage efficiency technologies, and offered up a new take on storage tiering, most of which is generally available as of today.
This post goes even further, and talks a bit about how people and process will likely change going forward, especially for those of you who touch storage on a daily basis.
When considering storage, we tend to think in terms of physical entities such as disk drives, LUNs, file systems and specific storage arrays. When storage people consider servers and applications, we usually think in terms of the precise mapping from application to server to ports to array to specific devices -- especially for important applications.
I would humbly submit that all of that has been changing for a while, and will change even faster in the future. And, as a result, how we handle storage in the enterprise is subject to change.
By comparison, when I'm working with people who are proficient in server virtualization (specifically VMware), they've lost most of their concerns with physical stuff altogether. I think the same think has started to happen in the storage world as well.
Thinking In Terms Of PoolsWe've had the newer virtual and auto provisioning tools in the market for a while now. For large VMware farms, we now assign big pools of storage to virtual machine farms, and provide a simplified mechanism to assign storage to VM.
The old process of hand-mapping VM->server->port->array->LUN is now dramatically improved. Far fewer clicks, far fewer chances to make mistakes, and improved flexibilty when things inevitably change.
All that has been in place during 2009, and people who've used the technology understand the benefits.
Now, let's add in FAST.
Those virtually provisioned volumes are now dynamically optimized between enterprise flash, FC drives and SATA. And that has big implications.
Running out of performance? Simply adjust your policies to re-balance between your different classes of storage services if you need a quick fix.
If you need to go a bit further, pop a few flash drives in -- the array will figure out how to use them to boost I/O performance. That is, if you let it ...
Running out of capacity? In most cases, you'll buy a chunk of SATA capacity, pop it into the frame -- the array will figure out how to use them to increase capacity without sacrificing I/O performance.
Without disturbing information protection, replication, snaps, etc. -- it's pretty transparent.
In this picture, we've got a pool of VMs, a pool of servers, a pool of paths, and a pool of different storage media types.
This sort of picture wants to be managed very differently than traditional server/fabric/storage approaches. It wants you to set policy, stand back -- and simply add more resources if an when they're needed.
Storage Architecture Is Changing, Storage Administration Is Changing
Just a few weeks back, I was looking through an EMC publication on storage fundamentals. It's good material, and provides a good conceptual framework for IT professionals that are new to the storage world.
But, as I was reading through the material, I kept asking myself -- how much of this will be relevant in 18 months? 36 months? Yes, things are changing that fast.
In just a few short years, virtualization concepts have changed forever how we think about server environments: how we build them, and how we run them.
From my perspective, virtualization concepts are now beginning to change forever how we think about storage environments: how we build them, and how we run them.
And, for those of us who've been in the business for a while, it's pretty exciting stuff!

Hi Chuck
I have been reading your blog since 6 months and have never been as excited - FAST !!!
FAST looks exciting . For FAST to be implemented , lets say between Flash , FC & SATA does one have to ensure all these disks need to have the same RAID groups ?
Once implemented , how does one assign the I/O pattern requirement for different Applications ..is it by GUT feel or is it that , we use the Storage Device normally for about 2 months and FAST will automate this functionality based on the 2 months data pattern of I/O reqired ?
Also , This means the internal bandwidth needs to be better than what it used to be . Was it that the internal bandwidth's were underutilised or is it that the current Storage Device Backends are better ( like the 8Gbps ) .
By , the way , I used to work to EMC India ( from 2004 to 2007 ) as a Enterprise Account Manager and now am with EMULEX India heading their Sales .
Thanks & Regards ,
Manu
Posted by: Manu Shankar | December 08, 2009 at 07:09 AM
Hi Manu
Sorry for the delay in the response.
I would suggest you check out Chris Kusek's excellent link page here.
http://www.pkguild.com/2009/12/one-stop-shop-for-symmetrix-v-max-fully-automated-storage-tiering-fast-docs/
Posted by: Chuck Hollis | December 09, 2009 at 07:06 PM