Do You Really Need A SAN?

A great debate is shaping up in our industry -- one that everyone should take note of.

I saw with much interest Forrester's recent white paper "Do You Really Need A SAN Anymore?", with Andrew Reichman as the lead author.  It attempts to make a case that SANs (really shared storage) is dead concept, and needs to be replaced with something better.

To the casual reader, it appears well written and well reasoned.  To people hip-deep in this stuff (like me) I think it's dangerously wrong.  And I have a sneaking suspicion that we'll see copies of this being dropped off on desktops around the world before long.

I'll leave it up to you as to whether or not it's worth the $279 or not.

My suggestion? 

Bookmark this longish post -- because, at some point in the future, you may find yourself defending your storage strategy to someone who's read this paper.

Before We Get Started

You should know that typically I find Forrester's work quite good on many topics.  Frankly, this piece of work isn't up to the same standards as some of their other work, IMHO.

I of course have a certain bias and a vested interest as an employee of EMC.  But, putting that aside, there's some thinking here that's just dead wrong and can get you in trouble.

Finally, there's a nucleus of a fascinating discussion here, but the authors shoot too low, and don't get to the heart of the matter.  I'll try to aim a bit higher towards the end of this post.

The White Paper Part I -- The Promise

The white paper starts with Forrester's view of the four general benefits ascribed to SANs

1 -- Lower Hardware Cost through Improved Utilization

The authors state that one of the marketed benefits of SANs (or shared storage) is saving money.  They're right, to a certain degree.

Back when EMC started selling shared storage devices in the mid 1990s, storage was well over $1 per MB.  If you could share it, you'd save money.  Back then, most of the focus was on sharing individual drives between applications, something that isn't usually done these days.

Speaking as a vendor, though, there were other parts of the "shared" pitch:

- the ability to manage a pool and move storage around if needed. 

- the benefits unallocated pool for the inevitable rush jobs that came up. 

- the ability to upgrade storage technology independently of upgrading the server.

2 -- Less Complexity Through Consistent Storage Management

The authors do have a valid point, but it's an obsolete one.

Back then, we had a situation where every server, every OS and every database was attempting to manage their own storage in a DAS world.  There was a certain logic to using a centralized array to do things consistently, e.g. provision, protect, performance, etc. -- more of device management rather than the broader topic of storage and information management.

As things got more complex, though, it got harder and harder for vendors to deliver storage management frameworks that kept things under control -- a situation that persists to this day.

3 -- Better Performance Through Increased Spindle Count

Whoops!

I don't know where they got this one -- I've never really heard this used with customers, simply because you could usually get a decent number of spindles behind a server.  Theoretically, yes, you could get more spindles behind an app using an external array, but -- in reality -- this wasn't a big deal.

More to the point, we did find that nonvolatile cache, intelligent scheduling algorithms, flexible RAID choices and multipathing I/O did a lot to help performance, but not so much the "more spindles" argument.  Veritas Volume Manager (or whatever volume manager was at hand) always did a good job striping with internal storage, or a direct-attached storage enclosure.

At least, that's true for EMC.  Can't speak for other vendors, though.

4 -- Improved Data Protection Through Array-Based Replication And Backup

Yep, that's always been part of the pitch. 

Even in a world with server-based replication, database-based replication, etc. -- there's always been a strong preference to put the heavy replication -- whether local or remote -- in the array itself.

Usually, that's for three reasons: (1) you can use the horsepower of the array to move data, rather than the application server, (2) there'd be a consistent way of copying data across diverse applications, servers, operating systems, etc. and (3) array-based replication is usually more mature and feature-rich than other flavors.

So far, so good.

The White Paper Part II -- The Indictment

The authors then make four arguments as to why SANs have failed to live up to their promise.

1 -- Low Aggregate Utilization Means High Cost Of Infrastructure

The authors toss out a 20% to 40% "typical" utilization number, comparing "amount purchased" to "amount written".

A couple of thoughts spring to mind. 

I don't know if the authors are familiar with all the layers of overhead between raw capacity and what user applications see.  I would point out that these overheads are pretty much the same regardless of whether we're talking about internal storage, direct-attached storage, or SANs. 

For example, a RAID 1 overhead is a RAID 1 overhead, period.  Go see Chris Evan's interesting charts here.

What really bothers me, though, is the inherent logical flaw: it speaks more to how the technology is managed and used, rather than the technology itself.   It's like saying "email is worthless because so much junk comes into my inbox".

Here's what we know: many EMC customers run north of 80% utilization. 

I'd venture to say that -- because these customers manage storage well, they'd probably do mostly the same if it was internal storage, or DAS, or whatever.  I'd also go as far to say that they'd probably appreciate the ability of a SAN to move capacity around as needed as supporting those high utilization rates.

Not only is this a flaw in their logic, it demonstrates a certain lack of understanding about how people actually use storage in the real world.

2 -- Limited Workload Sharing Creates Application Islands

The authors point to a reluctance of many IT shops to share multiple applications on the same array (not SAN!). 

And they also point to the project-oriented funding model of many organizations where every project gets its own infrastructure.

They then go a bit farther, and state that array vendors are too restrictive in allowing users to mix workloads, and that quality-of-service tools are too clunky to be of any practical value.

This line of reasoning appears pretty shaky to me.

While it is true that some IT shops have a per-project mentality for acquiring storage arrays, that argument has absolutely nothing to do with the underlying merits of the technology.  And, I must say, the authors are confusing "shared storage arrays" with "SANs". 

One could have a SAN with individual per-project or per-application arrays, if one desired.  Or one could consolidate multiple workloads into a single array, and not have a SAN at all.  Or -- more frequently -- a combination of both.

But let's focus in on the "can't share workloads" claim for the moment.

At EMC we *expect* people to mix workloads on our arrays (and our SANs!) -- that's what they were *designed* to do.  I mean, think about it, not too many people are going to fork over for a big honkin' DMX or CX and then only put a single application on it.  Now, for certain ginormous applications, people will buy one or more arrays and dedicate them to a single application, but we're talking some pretty specialized environments here.

I think we all need to make a clear distinction between *being able* to easily share workloads, and *choosing* to share workloads.  And, once again, this is a discussion about "shared storage arrays", rather than SANs specifically.

Now, I am aware that other storage vendors offer different classes of technologies, and -- in some cases -- it might make sense to limit a single application to an array. 

But as an indictment of an entire class of technology?  Well, it's just way off base.  It just doesn't map to the real world -- at least, the world I live in.

Besides confusing a few concepts, the real problem here is more political and organizational, rather than technological, I'd offer.

3 -- Vendor Heterogeneity Limits Compatibility

OK, score one for them.  They're right.  It's not relevant to this particular discussion, though.

Although all of us storage vendors can live well on the same SAN (with a bit of careful forethought), we all manage very differently.  While we vendors can do a half-decent job of upper-level reporting tools (topologies, inventories, utilization, etc.) in a heterogeneous environment, the underlying devices are configured and provisioned very differently. 

Making matters more problematic is that all of us storage vendors have unique features that are unlike the others -- making 100% consistent management virtually impossible. 

However, I see this is an indictment on "mixing and matching multiple array products in the same shared environment", if you think about it.

As a matter of fact, this is also true when you mix and match different servers and operating systems, different database management systems, different networking gear -- I think it's the nature of infrastructure, folks. 

Mix in a bunch of stuff from different vendors, and you can usually make the same sort of statements.

Storage infrastructure isn't that much different, when you think about it.  Hardly a worthy indictment of the entire SAN category, in my opinion. 

And, when you get to their proposed solution, this problem just moves to a different domain -- it doesn't go away.

4 -- Block Storage Devices Have Very Little Context About Information

Score one for them again -- sort of.  The real problem is that nothing has good context about information.

This argument is brought up in the context of storage tiering and ILM, and the ability to match storage service levels with application requirements. 

And, for most use cases, they're right.  I mean, EMC does have some dynamic optimization capabilities that aredriven entirely off of data usage patterns (Symmetrix Optimizer and Rainfinity's file archiving capabilities come to mind), but it's not a generic capability, and only covers certain use cases.

Later on, the authors will argue that applications inherently have better context, but I will argue that -- when you really look at it closely -- they are subject to many of the same limitations as storage arrays, and are perhaps worse off in some regards.

The White Paper Part III -- The Proposed Alternative

The new approach they propose really isn't all that new -- it's commodity storage managed by the application. 

This line of thinking is being driven in the industry by -- surprise -- the application vendors, and to a certain extent, some of the server vendors.

So we know where the battle lines are -- but how do the arguments stack up?

First, if you have a copy of their report, take a look at the "quick comparison chart" on page 5.  This where consultants become downright dangerous, in my humble opinion.  It is a scary oversimplification with all sorts of sharp edges.

If you can't see the chart, it's organized left-to-right, comparing internal and/or DAS storage, networked storage and application-oriented storage.  And of course, the message is "bad, bad, good".  Scary stuff.

Some of the arguments they present are worthwhile of discussion, though.

1 -- It will make it easier it to design, manage and deliver service levels.

Really?  How might that be?

The arguments behind this is the claim that arrays "struggle to prioritize important data" and "a block is a block is a block".  Although not accurate, it's really an argument against shared storage arrays, and not SANs specifically, if you think about it.

More insidious is the claim that the application owner knows best what's important in delivering service levels, and is much better positioned to manage the end-to-end experience than, say, a storage admin.

I don't know about you, but most application people I've met are not particularly adept when it comes to storage performance characteristics and their relationship to application performance.  Storage admins know, for example, that you don't put transaction logs and data stores on the same spindles. 

I think that they're proposing an entirely new class of application administrators that have advanced knowledge of storage design.

But there's more to the discussion that's worthy of exposing.

By going to internal storage (or something similar), you lose all of the array-specific service level delivery features.  You lose nonvolatile cache, you lose intelligent scheduling algorithms, you lose multipathing  I/O, you lose access to the ability to upgrade your storage technology to the latest-greatest without touching your server environment.

Now, one could argue that (a) none of these things are needed, or (b) the proposed internal storage model has reasonable alternatives, but you'll have to admit there's a lot you're taking away with their proposed approach.

I should point out that any service level management magic that an application might offer will work equally well for internal storage as well as SAN.  As a matter of fact, I could create a case that it would work better in a shared storage environment than just using internal storage.

But, if you really think about it, this isn't an indictment of SANs and shared storage; the author is just sharing an opinion on who's best positioned to control and manage service levels for an application -- and that discussion is somewhat independent of the underlying technology, isn't it?

2 -- Applications are more likely to have success with tiering than with storage systems.

There is a bit of merit to this discussion, as we're just starting to see the very first attempts by application vendors do a bit of smart tiering with the data they own.  We've started to hear that application vendors consider this sort of thing of growing importance, which is good.

Because any help is good help, right?

But, let's do a bit of deconstruction here, shall we?

First, any storage device can be used to expose the different service levels that an application might want -- internal storage, DAS, SAN or a shared storage array.  I'd argue that you'd get a far broader set of choices with external networked storage, though.

Second, this is all a relatively new discussion by the application vendors.  Like everything else in this industry, we'll have to see it in practice to evaluate whether it's useful or not.

But the real issue is that people use applications in unpredictable ways.  Do I really need tiering in my test and dev environment?  Does my application understand that it's the end of the quarter, and more performance is needed?  Or that this particular application is owned by a group that doesn't have any funding, so they get the cheap kit?

Yes, even applications will have their limits to do effective storage tiering.  They can help, but they won't solve the problem. 

And whether they use internal storage or external storage to do this is largely irrelevant.

3 -- The application-centric model can significantly reduce acquisition costs

Ahhhh ... the siren song of cheap(er) kit -- always a popular theme in our industry.

At a high level, we've done more than a few side-by-side capex/opex analyses for these environments.  Once in a while, they're cheaper to acquire.  Most of the time, though, the costs show up in other places, and are somewhat larger.  And, once you factor in opex, we rarely see them beat a traditional shared storage approach.

So, why is that?

Let's use the popular examples shared in the paper: Microsoft Exchange 2007 using DAS, and Oracle/HP's new Exadata data warehousing "appliance".

If you were to do side-by-side compares of, say, two different ways of doing Microsoft Exchange, you'd notice that the DAS approach has far more servers, and far more copies of data. 

The shared-nothing approach (e.g. DAS) means that if a key server fails, you can't get to the data it's storing, so you need another copy of data (and its storage) attached to another server.  Plus, all those servers are continually busy making copies amongst themselves to keep everything updated.  More servers, more licenses -- and more storage, due to the need to keep redundant copies around.

You've just moved the problem to another place -- at usually more cost.  But, if you're in the business of either selling servers, or application software licenses, there's a certain attractiveness to the argument.

The problem is even more pronounced on Oracle's Exadata box.  One server can support only 12 disks, and only half of them are usable.  In a big DW environment, that's a lot of servers, and half your storage is wasted for redundancy purposes. 

I found it interesting that the authors did not bring up the subject of operational costs -- power, cooling, floorspace, administration, backup and recovery, migrations, etc. etc.  I can only imagine why.

4 -- Managing storage from the application can cut out the middleman.

The logic presented here is a bit convoluted, so I need to quote it in its entirety to do it justice:

"The politics in many firms favors the application teams over the server teams, so as application offers more capabilities, the money is likely to flow in that direction, favoring trusted application vendors over storage vendors, who have built something of a reputation for being predatory.

What’s more, the relationship between storage teams and application teams is characterized by limited communication, and at times is downright hostile. This often leads to provisioning taking
too long and application teams asking for more than they need to buffer against future delays.

Eliminating the game of telephone between the teams and putting more control into the hands
of those who know the application best will likely result in more responsible resource utilization
and faster changes to the environment."

There's a lot here to dissect, isn't there?

First, in this case, the "middleman" adds value -- the storage admin knows how to configure the resources to do what the business needs.  The application people, in most cases, don't. 

There's also the question on who's keeping an eye on aggregate storage expenditures and overall architecture -- it won't be the application teams, will it?

Having seen the interactions between application teams and storage teams, yes -- there's frustration.  The storage guys are frustrated that the application guys don't get it, and the application guys are frustrated that the storage guys are making things so difficult for them.  That conflict is there for a good reason.

Note the characterization of application vendors as "trusted" and storage vendors as "predatory".  From my point of view, all of us vendors all predators, including maybe certain analysts at Forrester?

The White Paper Part IV -- The Application Vendors Are Getting Busy

The authors talk about Microsoft Exchange 2007 first, and point to the fact that Microsoft is pushing this environment.  This is quite true -- they've been doing this for a while.  The authors point to CCR as a replication technology that doesn't need an array.

First, Microsoft officially supports both DAS and SAN architectures, and will most likely do so for the foreseeable future.  They've offered up a new choice, though, which should be compared with other choices.

CCR is an excellent example -- it meets the needs for most Exchange environments -- but not all of them.  And, if you have more than one application than needs business continuity, you could end up living in an interesting world where you have a half-dozen or more different remote replication schemes to protect your business, instead of a common way of recovering all of them.

As far as generic storage management capabilities, yeah, there's some useful stuff there that would probably do OK for most moderate environments, but nothing like the sophistication you'd find with external SAN shared storage.  It's an option, though.  And, of course, Exchange's storage management capabilities work with both internal and external storage.

Next up is the Oracle Exadata example.  From EMC's perspective, pointing at ASM as an example of a storage management capability is probably not the best industry example to serve up.  And when you start probing around at topics like backup, archiving, remote replication and other storage capabilities, there's a pretty thin story.

Besides, we're still waiting for real-world experience on the new gizmo -- it's still early days.

The authors then point to vMware as putting more features into their environment.

Bad example, folks. 

To use any of VMware's more powerful features (DRS, HA, etc.), you need, well, external storage.  And let's not forget VMware is doing a great job of orchestrating features found in arrays today.  I'd point to the wonderful SRM replication management environment, VCB and a few others. 

Simply put, I don't think VMware would agree with Forrester's characterization in any regard.

The White Paper Part V -- The Storage Vendors Fight Back

The authors do point out that the storage specialists offer specific application integration, superior performance and functionality, advanced availability features and bring useful expertise to the table.

Whew!  I'm glad we're not totally irrelevant yet.

The authors then take an interesting turn by pointing to the server vendors as beneficiaries of this "trend" by offering stripped down, RAID boxes that fit neatly behind a single server.  Ummm ... EMC and others offer this sort of thing as well, and position it where it makes sense, so it's not just the server vendors that understand cute storage bricks.

There's a bit of hand-waving around "storage blades", which -- frankly speaking -- don't really bring anything new to the discussion, architecturally speaking.

The White Paper Part VI -- Recommendations

The overall recommendation?  Challenge conventional wisdom on SANs!

The first suggestion is to build islands around applications you care about, especially in larger shops. 

I don't think that's a new piece of advice -- customers routinely talk about storage pools used for mainframes, SAP, Exchange, etc.  The authors are trying to tell people not to build one, honkin' pooled and shared fabric in a large enterprise.  I don't think most larger shops even consider that.

But -- once again -- this has nothing to do with an indictment of SANs, or shared storage, does it?

The second suggestion is that size matters. 

Smaller shops should consider shared, converged storage platforms, but not larger ones.  Yes, but there are places where larger shops could benefit from this approach as well, for example tiering within a larger array, or combining multiple apps in a single array, or common replication backbones.

The third suggestion is that infrastructure can be an inflection point for application consolidation.

The authors suggest that if you're using infrastructure to make your applications work better, you might want to think about rewriting your applications. 

I won't even touch this one.

General Thoughts And Future Discussions

So, I'd be interested in the storage community's take on this whole line of thinking. 

To me, storage is infrastructure.  And shared infrastructure is usually better than infrastructure that's not.  We could argue about the right way of sharing it, but -- on this basis alone -- there's a very flawed argument being proposed here.

Even if you might agree that it's a poorly thought-out line of reasoning, make no mistake -- there's a power play going on here in the industry, and this is probably the first salvo of many.  So be prepared!

The real architectural question -- for me -- is the broader question of orchestration of the end-to-end environment: service levels for applications and the information they use. 

Can applications orchestrate themselves, or is something else needed?

Does an application know that it's just a link in a longer chain?  Or that what it does is very important right now, or maybe not so much later?  And in a world of multiple applications demanding resources (server, network, storage), who mediates?

And, more importantly, does an application understand budget constraints?  :-)

That I'd like to save for a subsequent post ...

Your comments are always welcome -- especially on industry topics like this!

Comments

[Matthew Zito]

It seems like, on the Exadata side, at least, there's a couple of red herrings being thrown about. I'd like to go through them one by one:

- "One server can support only 12 disks, and only half of them are usable. In a big DW environment, that's a lot of servers, and half your storage is wasted for redundancy purposes. " - but that's true in many SAN/shared array environments too. RAID-1, you lose half the disks. The fact you have more servers is part of the design, because now queries can be pushed out to the storage. If I do a full table scan with a predicate on a Symm, I'm going to have to read the entire table in. On an exadata, that FTS is going to execute on the storage itself. Clearly, in this situation, having more servers is a benefit for performance.

- "From EMC's perspective, pointing at ASM as an example of a storage management capability is probably not the best industry example to serve up. And when you start probing around at topics like backup, archiving, remote replication and other storage capabilities, there's a pretty thin story." - Well, I'll concede that compared to really elegant software volume managers like Veritas, ASM looks dumber'n a pile of rocks.

But when it comes to backup and remote replication, etc., Oracle has a massively better story than anything EMC has come up with. Oracle's Flashback query and table is unbelievably elegant, and far smarter than anything at an array level. The ability to say, "hey, snap back an individual table to 9am this morning", or even better, "let me run a query on this database as it looked like at 9am" is not even possible with a shared array without knowing in advance that you want to be able to look back at that time, and requires spawning off a whole separate Oracle instance.

When it comes to remote replication, I've always given EMC credit for making the industry's more robust and reliable remote replication solution. It's not the smartest, though. For example, with Oracle's Data Guard, I can say something as elegant as, "remotely replicate every transaction that is committed, but wait 2 hours to apply it, unless I have a failure, then roll the transactions automatically". With SRDF, I've got the basic "synchronous or async" question. With synchronous, I drop a table by accident on the near side, and on the far side it's promptly dropped as well. Whoops.

I agree with some of your assertions that Forrester makes it look a lot simpler than it will be, but the reality is that at the Oracle level, the application is in a position to be far smarter than a storage array ever will be. Oracle is leveraging that as far as they can go. Large arrays still have value with very strong availability and throughput, but I see more and more organizations using the database as the conduit for HA, DR, backup, and archiving, because it's simply a better way to do it.

[Chuck Hollis]

Hi Matthew -- you've got a very unique perspective.

Let's see what we can do here ...

You first claim is that arrays use RAID 1 too. This is true, but it's one of many storage protection options, including (most notably) space saving RAID 5 and RAID 6. A 14+1 RAID 5 scheme, for example, in a DW environment wouldn't be entirely out of the question.

With Exadata, there's just no choice whatsoever. You'll waste half your disks whether you want to or not. Trust me, you'll want to go fix this. Bad enough in the general case, really painful when we start talking about things like enterprise flash drives.

Your second claim has to do with "pushing queries to the storage". Pure marketing hyperbole from a factual perspective, amigo. What you're really doing is pushing queries to multiple commodity servers attached to a low-budget RAID card and SATA disks.

This approach is architecturally no different whatsoever than any other divide-and-conquer architectural approach. A query that wants to bring in all the data will bring in all the data, regardless of approach. Please spare us the hand-waving magic juju.

We go head to head now with Exadata using standard storage and standard servers -- sometimes with Oracle as the software, but more often not -- and kick patootie almost every time.

We must have very different ideas of what "storage management" means, as you described the Veritas volume management product as "storage management".

Goes to my point about application and database people not usually having a good idea about how storage really works.

I think Oracle's Flashback is a great feature, one of many. As a matter of fact, there are lots of great application and file system specific features in the marketplace.

So, how many "great features" does it take to run a modern data center? Part of the argument is that there's more than Oracle on the floor, and complexity grows unmanageable when each and every application has it's own set of "great features".

Oh, and I should point out that if for some reason you'd like to make copies of databases to run on different kit for testing, etc. -- a common use case --- you're pretty much hosed with the Exadata case. Don't get me started on DR, either.

BTW, I'd truly enjoy going head-to-head with you on replication functionality using RecoverPoint. It can rewind indidividual tables, logs and indexes to arbitrary points in time -- do a query on a previous logical view of a database without requiring a separate instance across multiple instances -- multiple servers -- multiple non-Oracle applications -- either local or at a distance -- on anyone's storage.

Lessee Oracle's Flashback do that, shall we? You should know that one of the more popular environments for RecoverPoint is -- of course -- larger Oracle databases.

BTW, your knowledge of SRDF is very dated as well. Longer lags are possible if desired. And your "whoops" scenario an happen with Datagaurd as well, can't it?

More organizations using the database to implement HA, DR, backup and archiving? Really? In what markets and use cases? If this is happening, we haven't seen it.

If anything, it's just the opposite -- standard infrastructure for ALL your applications, and not just the ones running on an Oracle database. The data center environment is just a tad more complex than that.

I know you're trying to make your case that "applications are smarter", but -- given your comments here -- you haven't scored a single valid point, IMHO.

You guys need to go back to the whiteboard, and think about this whole thing a bit harder. It's a nice marketing schtick, but I don't think it's going to get too far.

Cheers!

[Taylor Allis]

Hi Chuck –

Well, I thought I’d offer my 2 cents – and you may find me more “agreeable” now that I have left Sun and started a Storage Consultancy that is also an EMC reseller (ahhh, the irony). But I will say that before I was asked to pick up the “Open Storage” mantle at Sun I was a STKer – and our new company is founded by ex-EMCers and STKers. Ever imagine the day when EMC and StorageTek are working together? ;- )

I have not read the report (nor will I spend the $279) so my comments are based on your comments:

Utilization – I’d be interested in how the report talks about “utilization” because most in the industry misuse the term. Utilization is how often data is referenced or used – and utilization tends to be pretty good with shared storage. Allocation is really the measure of how efficiently you use the storage you buy. Allocation should be the focus and always needs to be improved – but for every storage device, not just SANs.

Mixing people processes with technology issues - I think you wisely state that the report mixes technology issues with people issues and this can be dangerous. “Project-oriented funding models” and “workload sharing” are issues with processes and management – and not limited to SANs. Often business processes can cause storage inefficiencies more than storage technology does. In storage – you need to focus on both. This line of reasoning is like buying a new car in order to fix your stalling issues with your stick-shift truck (when the issues are caused by you simply popping the clutch too early!)

Storage Managed by Applications – I can write a book on this since I came from StorageTek (back office storage) and Sun (front-office Server Vendor). In a nutshell, applications support business objectives and storage supports applications. So, it looks like Forrester did articulate a TOP issue with storage management – “the relationship between storage teams and application teams is characterized by limited communication.”

But in my experience, and yours too it looks like, putting all the power in the application owner’s hands sounds good but seldom works (I know from personal experience). Storage is a lower priority for them – and they rarely have the insight or training on just how storage impacts their application goals and performance. They also don’t want to be in the storage business (this is why they are in the application business!)

I think storage management needs to get better at interviewing application managers on their critical business and IT needs; then deliver to their needs while communicating how they improved/met their needs.

You nail that and everyone’s happy. And, oh, by the way – this has NOTHING to do with SAN technology…

[Chuck Hollis]

Hi Taylor -- sounds like you're enjoying your new gig! I think storage consultancies are good and valuable businesses, especially with people like you who can look beyond the vendor fog and steer people in a practical direction.

And, hey, I'd say that even if you weren't an EMC reseller :-)

So, I guess you reacted to that report pretty much the way I did -- not only is it wrong, it's really badly wrong on so many levels.

I'd be interested to see what others will have to say.

Thanks for the thoughtful comment!

-- Chuck

[David Vellante]

Great post Chuck. This argument has been going on and off over the years in the industry and I thought it was put to bed. I too have great respect for Forrester's work and even in this case I'm happy they're getting the discussion going-- makes for a good reality check.

Like you I fundamentally disagree with the premise of the piece. I mean from the point of view of a specific application and from an application vendor's standpoint, sure, cut out the middleman and reduce the overhead-- hard to argue. The problem is this assumes an ability to manage the performance and availability for each and every application which is not only silly and impractical; it's a nightmare.

You are right, the proposed 'new' alternative isn't new at all. This is what the world did before SAN. It didn't work. Application people always over-provisioned storage because they couldn't accurately forecast demand. Then eventually, they ran out of storage and reacted to a crisis. This proved FAR more expensive than sharing resources with a SAN. That SAN hasn't lived up to ALL its promises is worth noting but really is immaterial.

If you have an application where I/O is a bottleneck and you have a really clear reason that a SAN would get in the way then go for it. Otherwise you'll find this model way too time-consuming and expensive. Let's not go forward to the past... -Dave from Wikibon.org

[John Webster]

Chuck

I know and respect Andrew and I'm sure he's given this much thought. However, I’m not going to pony up for this paper - not that I fundamentally disagree with the paper’s premise as I’ve often wondered if the industry created something of a monster ever since SANs first appeared. So I haven’t read it and probably won’t unless someone sends it to me.

That said, I’ve always seen this issue in fundamentally different terms. For me it's never been about DAS vs. SAN. Rather I see the dichotomy as DAS vs. networked storage. In terms of sharing, its shared infrastructure vs. shared data. NAS is ignored in this discussion as is the potential need for shared data (i.e. true data sharing).

NAS is sometimes called the “poor-man’s SAN” because it’s often a cheaper way to network storage and share it. So if the cost of SAN infrastructure bothers you, but you still want to share infrastructure that you would otherwise duplicate along with and all of the required management processes in going with DAS, NAS has always been there for you. And with unified storage and DCE on the horizon the differences between SAN and NAS begin to blur for me and I’m again left with a DAS vs. networked storage debate.

Re infrastructure sharing vs. true data sharing, I wonder if application-centric model that Andrew appears to be promoting considers that? From this posting of yours I would guess not. However, there may be food for thought on this issue in conjunction with the application-centric storage model. However, in this case, data sharing may or may not be heterogeneous as practiced in reality by the app vendors.

If not, then were left with two arguments for app-centric storage: “cut out the middle man” and manage storage from the application layer. There are ways to cut out the middleman without making the app guy the storage manager. I’ve liked the concept of the storage ATM for example and see some vendors promoting it. As for managing storage from the application layer and doing server based data management (replication for example), for me that debate has resurfaced with VMware. Veritas made a big push years ago to host data replication at the server level. It was good for some users, but bad for most. Veritas didn’t get very far. VMware has a different playing field in that there are potentially more server cycles available now to do this….Or are there? Maybe, and maybe not if you’re a user looking to run the critical apps on VMware.

In the end, the app-centric model may be more well suited for smaller IT environments. But those have traditionally shunned SANs in favor of NAS or DAS anyway. For me, SANs won’t go away. NAS gets more market share. And then there’s the cloud – plug in your app and off you go. That’s ultimately where I think the industry is headed long-term.