Reconsidering Storage As A Service

Yes, this is a blog about service providers, and -- yes -- I work for EMC, so it's inevitable that sooner or later we'd get around to this topic in one form or another.

But it's not going to be the usual shameless product plug, although I'll be happy to indulge you if that's what you're looking for.

No, this post offers up some thoughts about newer approaches that I see evolving for delivering storage-as-a-service as an underpinning for a variety of SP business models.

The Envisioned Model

I have this basic reference picture that I keep coming back to -- an SP business model built on a fully virtualized pool of resources, where service levels can be dynamically varied up or down based on the tenant's willingness to pay.

The Vblock is an example of this thinking; there are undoubtedly other examples to be considered.

This sort of fully virtualized platform can be the underpinning for all sorts of SP offerings -- everything from "private cloud" infrastructure/app hosting models, to delivering aspects of IT as remote service (e.g. backup), or even vertically-oriented application offerings.

So how, then, might we come to eventually think of storage-as-a-service in this fully virtualized world?

Phase 1 -- Making Physical Storage More Virtual

That's the dominant theme that most product technologies seem to be chasing today, including EMC. 

Create big pools of storage, and allocate them on-demand to requestors, usually something running in a virtual machine (but not always). 

Be able to vary service level and capacity up-and-down nondisruptively on a moment's notice.  Be able to add value-added services like backup, or remote replication, or compliant archiving as an upsell.

And, of course, be able to isolate workloads from each other, and reasonably secure the environment.  Eventually, be able to dynamically sling around workloads from data center to data center nondisruptively.

EMC's VMAX and VPLEX are perhaps one of the best examples of this sort of thinking that's in the marketplace today.  But, it one sense, it does all of this magic using a dedicated storage array, albeit one that's tightly integrated with the server virtualization layer.

But what if we went "full virtual" -- e.g. implement tenant storage services using software that entirely runs in a VM?

Phase 2 -- Completely Virtualizing Storage?

At its underpinnings, storage is a physical entity.  Whether it's disk, flash or (ugh!) tape, at some point you're dealing with physical block devices.  Everything else is a software abstraction, if you think about it.

So, as many people have considered, why not run these software abstractions in a VM, rather than on the array hardware itself?

I discussed this topic a bit on my other blog, highlighting not only a few technical concerns for specific use cases, but also offering up some practical offerings from EMC where "storage" isn't really physical any more, it runs completely in a virtual machine.

Use Cases

Basically, I see three.

The first might be service providers running a hosted application on behalf of their tenants -- whether it's the tenant's app, or the service provider's app.

The second is the oh-so-familiar economics-driven "cloud storage" discussion, where it's more about $$/GB and less about value-added services.

And, finally, there are several use cases where external storage services are more valuable that anything an enterprise IT organization can do itself.  Remote backup targets and compliant repositories spring to mind, as do global content distribution networks.

[BTW -- a shout-out to PEER 1 and their Atmos-based cloud storage service!]

All three are somewhat amenable to this idea of "storage as a virtual machine" concept.

So why might this approach ultimately be of interest to many service providers?

Glad you asked ...

Advantage #1 -- Consistent Model

In this model, everything gets provisioned as a virtual machine. 

Need something that looks like a NAS filer?  That could be a VM.  How about an iSCSI SAN that looks physical, but is under the control of the tenant -- and not the SP?  That could be a VM.

Rich object-based metadata models, like Atmos?  That's a VM today.  Intelligent file management, archiving, tiering, etc.?  That's a VM today as well.

All the SP has to do is provide a nice block abstraction that all the VMs can see.  Sure, there are some high-end use cases where physical storage infrastructure makes sense, but you can also see plenty of use cases where a VM will do just as nicely.

Advantage #2 -- Inherently Multitenant and Tenant-In-Control

In this model, the tenant of the SP can control the storage abstraction -- what it does, how it's configured, how it's administered, etc.  Performance isolation boils down to (a) making sure that the block abstraction provides enough IOPS or bandwidth, and (b) making sure that there are enough server resources for the storage abstraction.

Going a bit further, when we get to per-VM encryption, the tenant can elect to encrypt the virtual machines that hold the storage abstraction, and manage the keys if they want.  Again, architecturally clean.

Advantage #3 -- Portability

I know that most SPs can't bear to think about applications and workloads flowing out of their environment (instead of into!), but it's going to increasingly be a requirement that applications and workloads can move into and out of SP environments with much less friction than in the past.

In this model, moving the "storage array" means nothing more than moving the VM that implements its abstraction -- as well as all the information it contains.

Besides, portability works both ways.  If enterprise IT users get comfortable with running storage abstractions as a VM, well, so much the better for the SP who does the same thing :-)

Advantage #4 -- Big Potential For Low-Cost Entry and Upsell

Cost-to-serve for entry requirements are about as cheap as it can get -- basically, media costs, a VM and a bit of software.  As mighty oak trees start as small acorns, there's opportunity to grow and grow.

For SaaS providers (whether horizontal or vertical), there's a nice play as well here.  Your tenant can choose to play with underlying storage, or not, as their tastes dictate.  Very small initial engagements are now more cost-effective, and there's plenty of room to grow.

Today's software NAS becomes tomorrow's dedicated physical storage infrastructure.  Today's lightweight software remote replication becomes tomorrow's robust and scalable capability.  The tenant sees what they've always seen -- what looks like a physical hunk of storage capability -- but its implementation just gets progressively more capable as requirements grow.

There's also great opportunity for differentiation from the underlying block abstraction -- from very low-end to the very high-end, as well as the growing demand for geographic relocation of workloads with technologies such as VPLEX.

Talk Back

I don't work for a service provider.  I work for a technology vendor, albeit an interesting one these days.

Part of what I want to do is identify technology themes that -- ultimately -- will help SPs become more successful at what they do today, and what they'll want to do in the future.

Being from EMC, storage has to a be a part of any discussion.  So, what do you think? 

Would provisioning "storage services as virtual machines" be an interesting theme to pursue?

Comments

[IT Support Memphis]

Here, you can gauge the standard of their service and determine if they really have got the expertise you're looking for. With more non-custodial parents seeking the same benefit (irrespective of parenting time) and more parents looking to balance parenting time between both parties, the issue of dependency has tended to crop up more and more with parents who are not parenting on the front line but still getting the benefit of the tax breaks. To improve your chances of , make a list of pluses and minuses about preventing.