We’ll call this one Automated Storage Tiering as it isn’t block based. Since I’m waiting for a massive synchronisation of the house’s music library to complete this should prove quick and easy.

So what are we going to do?

We’re going to automate the placement of files on Celerra storage tiers, some native volumes some deduplicated and compressed volumes, using Rainfinity policies and the Celerra FileMover API all while offering transparent recall during file access.

And what’ll that achieve?

Due to the reduced capacity it should deliver a smaller physical footprint, reduce energy consumption and do all nice things for your TCO over a number of years.

And how will it do that?

The same way you always do nice things for your TCO, drive efficiencies out of what you already have.

You’ll need:

-1x Rainfinity FMA. Physical or Virtual Appliance. Your choice.

-One or more tiers of secondary storage on your Celerra.

-A Web browser, a mouse and a keyboard.

-My dashing good looks and excellent personal taste. Okay so that’s a unrealistic for you and not an actual requirement but I just thought I’d give you something to strive for after you’ve implemented this.

How does it work?

Lets say we have three tiers of storage Tier 0 (Enterprise Flash Drives), Tier 1 (FC), Tier 2 (SATA). We create a filesystem, if one hasn’t been created already, on Tier 2 and enable Celerra Deduplication. We then create Archival policies for the Tier 0 and Tier 1 filesystems on the Rainfinity FMA and set them to run automatically.

These policies can be as basic as move anything which hasn’t been accessed in a few weeks or months to something with a much more specific set of criteria.

Rainfinity FMA communicates with the Celerra FileMover API which migrates files between tiers and creates a stub file in the source tier to allow for transparent access. Note that the Tier 2 destination can be on the same or a different Celerra.

And there you go, quick and easy Automated Storage Tiering for Celerra.

But my giant music sync still isn’t finished so now I’m going to have to think of something else to write about.

If you’ve been following this blog — or other similar conversations — you’ll know that my current focus is on private clouds.

A private cloud is a fully virtualized IT environment that can optimize the use of IT resources — whether they be internal, external or a combination of both.

Up to now, I’ve been covering what they are, how they’re built, why we need them, etc.

It’s now time to take on a big, hairy issue — how will they be paid for?

Because — at the end of the day — it all boils down to money and economics, doesn’t it?

A Starting Point

At its core, the private cloud discussion (or any cloud discussion) is no more than a different model of providing shared infrastructure — in this case, IT infrastructure.

As any student of economics will know, one of the most interesting parts of any shared infrastructure (or public good) is how it gets paid for.

Sure, you need to cover the economic costs associated with any shared infrastructure: resources, people, etc. 

But pricing models at their heart are a two-way communication: from consumer to provider “here’s what I want to consume“, and from provider to consumer “here’s what I want to provide“.

And — if these two sets of need meet successfully in the marketplace — we’ve got a winner.  Fortunately, there are many similar non-IT examples that we can look at and learn from.

An Interesting Topic Across The Spectrum

You might think the topic of infrastructure pricing might be most relevant to outsourcers, service providers, telcos and the like.  You know, people who are “in the business”.

And you’d be right — if they fail to get pricing models right (e.g. earn a superior economic return on invested capital), these people won’t be successful in the long term.

But there are also implications to those IT organizations who will be consuming these services, since — after all — many of these external costs will need to be passed on to the organization.

And, even if you never plan to use much in the way of external IT infrastructure services, you’ll probably have to wrestle with newer forms of chargeback for dynamic internal resources going forward.

Indeed, one of my co-workers sent along an interesting snippet from a recent Forrester note leading one to believe that we’ll see more of these of environments going forward.

(note: the original report can be found here)

That’s what makes this such an interesting topic — at least to me!

Pay For What You Use?

Most people start their journey here by proposing some sort of “pay for what you use” model as a way of allocating and recouping costs.

When it comes to hardware resources (server, storage, network), the idea is that these devices cost a certain amount to own and operate, and everyone should pay a proportional share based on actual usage over time.

When most IT was dedicated and physical, one could go down this sort of road.  This is your server.  This is your storage.  This is your fair share of shared costs.  And so on.

But in a dynamic virtualized world, the underlying resources are, well, dynamic and virtualized, making it more difficult.  That improved ability to share makes the economics so much more compelling — but also makes it devilishly hard to figure out fair and workable schemes for charging users.

For example, it’s a useful state of affairs when some excess capacity is left around, just in case it’s needed on short notice — but who pays for this excess reserve capacity — or decides how much to keep around, just in case?

It’s also the case that many IT costs are not prone to granular or proportional allocation, such as floor space or physical security.

And then there’s the “obsessive detail” problem.

If you were an early user of the iPhone on AT&T’s services, you’ll probably remember the stories of customers getting their first bills in multiple FedEx boxes — thousands of pieces of paper, with precise detail on each and every internet access that was made in the previous month.

At some point, billing for exactly what you use loses its appeal.

If we turn our attention from hardware to software — specifically application software — it gets even more problematic. 

For example, if I have a software application open in an inactive browser window, am I really using it?

Classes And Bundles?

Rather than line item each and every resource used, the next usual approach is to create packages and bundles of shared services that aren’t too picky on exactly what each consumer is using.

We’re all familiar with wireless plans that have buckets of minutes and access to a handful of useful applications.   The result is usually a handful of standard packages, with the option of adding a-la-carte extras above and beyond the package.

But these sorts of packages create challenges for many consumers — what if you don’t have a good idea of how much you’ll consume?

In the case of calling plans, buy too much of a package, and you’ll waste money.  Buy too little of a package, and you’ll be hit with extra usage charges.

For those of you who have children who are just discovering the joys of mobile technology, you’ll appreciate the challenge

Not to mention that when it comes to IT infrastructure, one has to question whether most business users are educated enough to make informed decisions on such issues as high availability, or frequency of backups, or required security capabilities.

Guaranteeing Service Levels?

The previous discussions work well — up to a point — if you can live with occasionally being denied service from your shared resource.

As a matter of fact, this issue alone seems to be the primary sticking point when attempting to convince larger business users to consider a shared, fully virtualized environment, e.g. what if I need resources, and they’re being used by someone else?

In reality, there’s no such thing as guaranteed service, in IT or anywhere else for that matter — all you’re really doing is paying an increasing premium for a decreasing likelihood that there will be a problem.

To make matters more interesting, many forms of variable IT service delivery in a private cloud are nothing more than fungible hardware resources.

Want more surge performance?  We’re talking more CPU and memory, more I/O paths, and perhaps more use of enterprise flash storage for your data on a dynamic basis. 

Want more availability?  You’ll likely need a second instance of your application running somewhere to support some sort of failover, not to mention a recoverable instance of your information with better RTO/RPO.

It All Gets So Complex, Doesn’t It?

Rather than try to immediately solve the IT infrastructure pricing problem in one go, let’s look around at a few other forms of shared infrastructure, and how they’re priced.

We’re all personally familiar with wireless calling plans.  They’re clever on many levels once you start looking at how they are put together.

For example, there are starter packages that are aggressively priced to incentivize you to use one carrier over another.  The analogy for internal IT might be a nice offering to keep people from using external services (such as Amazon’s) if that’s your concern.

The midrange packages are an interesting combination of features you’d like to use, and features you don’t really care about, but — on the whole — the packages are attractive compared to a-la-carte arrangements.

The larger packages are incredibly efficient, but require much higher minimum commitments.  Of course, if you join together (family plans, corporate plans, etc.) you can reach these minimums more easily.

And, of course, there’s no explicit guarantee of service.  In general this isn’t a concern, but — occasionally — your provider may not be there when you want them to be.

Several years ago I was traveling on the West Coast when a moderate earthquake hit.  I wasn’t able to get a wireless call out for some time afterwords.  Would I have paid extra to have that “dedicated capacity” guarantee?  I honestly don’t know.

Another useful shared infrastructure example that we’re all familiar with is air travel. 

Now, instead of averages, we’re talking about pricing discrete services — a dedicated airplane seat on a specific flight at a specific time.

The farther you can make your wishes known in advance, the better the price you’ll pay.  The more flexibility you show in class of service, arrival and departure time, etc. the better the price you’ll pay.  Last-minute changes are very expensive, indeed.

I find airline pricing models interesting for several reasons, mostly because when an airplane takes off, any empty seats have a near-zero value.  The airline has a strong economic incentive to fill every seat — much to the displeasure of us who travel regularly.

And, if you’re a frequent traveler, you know there’s no real guarantee of service

A third example that we’re all familiar with is power generation. 

There’s a certain minimum cost to consume any at all (unless it’s a subsidized service), but — after that — it’s pure variable pricing.

In countries like the US, this power service is provided by a federated network of providers.  If you’re a power provider, you’ve either got the relationship with the consumer (the infamous “last mile”), or have invested in desirable production capacity (cost reduced, environmentally sensitive, geographically convenient, etc.).

There’s not much room in between

Where Does That Leave Us?

All I’ve really done is laid a preliminary foundation for delving into what I believe are the really important issues — what will be the value characteristics demanded for these new, dynamic IT services — and how will they be priced?

More soon …