Yes, many people have tread this ground over the years, but I'd argue it's time for a re-definition of the term.
Properly framed, it can provoke a mindset that transcends historical thinking, and might help pave the way for storage architects out there who are looking for new ways to frame the discussion with their teams to move the ball forward.
You be the judge.
Use the phrase "storage as a service" and people will inevitably think of either:
a) some sort of outside service provider offering capacity by the slice
b) some sort of managed services offering inside the data center, or
c) some sort of storage services catalog listing the different storage classes available to the business.
These are all IT-centric views. They are not views constructed from the point of the consumer of the service.
EMC is extremely guilty here. We do all three, in fact, and use the phrase "storage as a service" to describe all three concepts. In fact, all trends point to a consumer-centric abstraction that sits above all three concepts.
Learning To Think More Like A Service Provider And Less Like A Traditional Data Center
Whether we call our next-gen environment a cloud, or a next-gen data center, or whatever, there are three things that are at the center of the discussion.
One is architecture -- these environments are (ideally) built differently, mostly as aggregated and dynamic pools.
The second is the operational model -- think as close to zero-touch as possible.
And the third is the consumption model -- fine-grained metering combined with convenient consumption, e.g. pay-as-you go as an example.
All of these concepts apply to a "storage cloud" (whether internal or external, public or private) that delivers storage services to applications and users. To get this right, you want to focus on the boundaries between all the storage stuff, and all the people who want to use it.
That's what makes it a service.
Considering The Consumption Model
There are some uses of storage where it's acceptable to consider it as an independent entity: imagine a large digital archive, for example. And there are other uses of storage where it's hard to consider independent of the application using the information: a SQLserver database, for example.
This leads you to the inevitable conclusion that -- ideally -- there would be two "consumption portals": one oriented around (presumably) large amounts of relatively cold data, and perhaps a second one oriented around that exposes storage services in the context of an application, presumably sitting in a virtual machine.
What this line of thinking discourages is attempting to think about applications and their storage separately -- as is done in many IT environments today. Instead, a new bimodal consumption model emerges.
For one consumption model, here's a giant pool of storage for colder data.
Feel free to log on to the portal, set up an account, and put your stuff there. Maybe we'll give you a few choices on redundancy, service level, encryption, policy, etc. -- but nothing fancy. Point your applications at it if you need to.
IT will tell you how much you're using, and bill you monthly.
You -- as a user of this service -- have no idea as to whether this service is being provided internally or externally, and -- frankly -- you don't really care.
For the application-oriented consumption model, here's a portal that give you access to a giant pool of storage for you to associate with your application(s). You provision your app modules, your middleware, load balancers, etc into something like a vApp, and tie a pool of storage to it, and toss it onto the infrastructure.
You -- the application owner/manager -- are responsible for how much, how fast, how many copies, want DR, etc. You're free to move the knobs up, down or sideways as you see fit.
IT will tell you how much resource you're using (compute, network, storage), and bill you monthly.
You have no idea as to whether this service is provided internally or externally, and -- frankly -- you don't really care.
Considering The Operational Model
In this world, consider the new storage operational model from a storage admin's perspective. It's really, really close to zero-touch. You're responsible for the aggregate environment (performance, capacity, availability), but don't really care so much about the individual application users. Users don't bug you when they need more or less capacity, more or less performance, more or less protection and so on.
They take care of that stuff by themselves.
Sure, you get involved in the occasional special case, but -- by and large -- people take care of their own needs. Ideally, you'd never zone or carve another LUN again. Same for file systems. Or manage a replication session. Or ... well, you get the idea.
You -- the storage administrator -- can now focus on bigger issues. You can architect an environment that does this internally, work with any number of outside providers, or a combination of the two.
Your goal is to provide an infrastructure service, and not a specific technology.
Consider The Architectural Model
So, if you're designing the ultimate storage pool behind this environment, what would you want in it?
Well, you'd want support for the two self-service portal environments I've described above. You'd want a storage architecture that could vary performance and availability levels up and down without you having to get involved.
You'd want to provide the storage service in a way that was largely independent of geographical location -- information goes where it needs to go. Different forms of replication, caching, archiving, etc. would be invoked automatically -- you'd never see it, though.
And, of course, you'd want all sorts of efficiency goodies: virtual provisioning, flash, dedupe, spin-down, etc.
Since you're running a service at scale (and presumably measured on service delivery!) you'd be interested in things like automatic migrations between different technologies and locations, zero-downtime upgrades and patches, and all sorts of aggregated reporting and analysis tools to tell you how your giant storage pool is being used, and how well it's doing.
Ideally, you could do this sort of thing on a special purpose device (think array), a mix of storage devices (think leveraging the legacy), perhaps internal server DAS -- or maybe over a wire.
Or any dynamic combination and transparent combination of the above.
There's more, but I think you're starting to see the picture.
Back To The Starting Point
Way back at the beginning of the post, I pointed out that when you said "storage as a service" people thought of a variety of things -- a static service level catalog, or a managed service, or perhaps an external service provider.
Well, maybe the best way to think about "storage as a service" is from the correct perspective: what the consumer wants, rather than what the provider wants.
And that leads to a very differnt picture, doesn't it?