Reclaiming space (30-50% is what we are typically seeing these days) means more headroom for growth WITHOUT purchasing new disk. This goes in line with the Symantec CEO stating earlier in the year to “stop buying disk.”

Besides the CAPEX savings, there are other green savings too, primarily Green House Gases (GHG). This will be an increasing important data center metric as many countries start negotiating and signing the upcoming Copenhagen Climate Change Treaty. CO2 emissions are a problems with countries needing to expand, and if that expansion is your data center then you need to get planning on reducing your current and future CO2 emissions. Storage can be a significant part of the data center GHG effect.

This latest Wikibon report validates the HDS notion (that we have had for years) that virtualization and thin provisioning can and will reduce GHG as utilizations are improved, and the cost of data growth can be done without adding CO2. This is an excellent article to add you’re your business case on investing in the right architectures now to reduce money (green) and green house gas (also green). These 2 points will play a major role in IT spending and planning in 2010 and 2011.

We have documented this effect for years, and put together costs models on the added expense needed for dedicated servers or excess servers required for the storage environment. Lately I have seen dialog around a return to DAS, cloud architectures and some silo storage architectures that require unnecessary burdens on servers or CPU cycles. Here are some examples:

• Remote replication run and managed by the hosts
• Host based local replication
• Snap copies
• Backup tasks that burden the application server, and that require specialized backup servers (whatever happened to server free, LAN free backups?)
• CIFS and NFS are obvious
• Migration effort that taxes the application hosts
• Moving volumes
• Compression
• Encryption

There are probably more CPU stealing examples from within various storage environments.

Now this topic becomes relevant now as new storage cloud architectures are emerging that return to a bundled CPU/Disk configuration, in that dedicated servers are needed for some pretty basic storage functions (copy, RAID, backup, etc.). As some storage arrays scale out, additional CPU nodes are added for capacity growth. Granted the CPU is imbedded in the storage control function, but there are new elements to power, cool, administer and purchase for a scale-out solution.

Architects need to be aware/sensitive to CPU cycles taken away from the hosts (virtual or not) that are required for the storage environment. There are storage solutions that are lighter-weight to the application host, and when you drill into the total cost of the solution, these costs can add up to a significant part of the storage infrastructure TCO.

• Cost of migrations can vary depending on they money you want to include, but we tend to estimate at $7-10K per TB
• HDS is completing a comprehensive survey on migration cost, and this 7-10K estimate that I have been using for the last 4 years is likely a gross underestimation of the real costs
• All things considered with migration, ROHS and tech refresh time and effort, the cost to de-commission large arrays can approach ½ the original purchase cost
• If you have more than 200TB, you are probably in a constant state of migration. In other words, above 200TB you have full time effort, staff or contractors working on storage migration tasks
• The time to complete migrations tends to run between 4-6 months. I had lunch with an investment client yesterday, and she told me that they plan on 6 months but that often and realistically tends to be 8-9 months
• With 4, 6 or 9 months to get off a platform and on to the next, the effective life of the asset is diminished by 10-30% (Depending on how long you lease or depreciate assets)
• Vendors often mask the cost of migration by offering ‘free’ migration services if you buy their replacement story. But there are real costs to your organization even if the heavy lifting is done by the vendor

So let’s break down all the costs associated with array and data migrations. I am co-authoring a more detailed paper on these costs, as well as how these costs compare to different migration methods available today. But for now, understanding the types of costs will help as you try to reconcile the real cost of storage/data migration:

1. Application change control
2. Server Change control
3. SAN Change control
4. Server Outage Cost
5. Application Outage Cost
6. Data Movement  Internal Labor
7. Data Movement  External Labor
8. Tape Resources
9. Specialized software for migration
10. Specialized hardware for migration
11. Added environmental costs
12. Duplicate Software license costs during the migration
13. Extended period Maintenance costs
14. Additional Network costs for switches and HBAs

More on these costs later (and in the paper), but the next blog will outline the methods and comparative options for migration. If there is a cheaper way to migrate from one array to the next (and is vendor independent), are you interested?

I like this definition of Cloud, as it relates to storage, from the 451 Group – “Cloud is a way of using technology, not a technology in itself – it’s a self-service, on-demand pay-per-use model. Consolidation, virtualization and automation strategies will be the catalysts behind Cloud adoption”

In these early days of clouds, implementations are few but strategic plans are increasingly in frequency. The economics of a cloud architecture really hinge on planning an integrated cloud vs. a cloud silo. As with any architecture shift, we must avoid building a new silo for cloud. I tend to see that in the planning for clouds, a net-new infrastructure is seen as needed to provide these new services. To me a new architecture, or a silo architecture = new and redundant costs:

• skills and management
• tools
• dedicated infrastructure components

Last week my son had to create a multi-media project for a class. I suggested a diorama, quickly ran to find a shoe box and suggested that we head to Wal-Mart to buy all the things to go in a diorama. We discovered that we had everything we needed in the garage or in closets around the house to adequately build the necessary story or exhibit. I was very proud that we avoided a trip to the store, and could use what we already had in place. Unfortunately, my son was not impressed with my diorama skills and quickly moved to create a PPT and flash presentation with music from U2 and the Chili Peppers. So much for my 60’s style version of multi-media.

The analogy is lame but point is somewhat the same, in that most medium to large enterprise shops have most of what they need to start building the agile cloud. Last week I was working with a client in Bangalore, and they expressed a need to go to their IT directors with a plan to develop a cloud. This retail client already were using USP-V, HP EVA and CX storage, Veritas tape backup, Netapp filers. When we showed them that they already owned most of the basic ingredients, and just needed to turn on some functionality and they have a cloud. Cool. There was no net-new HW to buy. Most of the software had already purchased, not fully implemented. They were ready to buy new ‘stuff’ to have a cloud, and were pleased to know that they are 90% of the way there. Now of course there would need to be some process and operation changes to consolidate operations console to 1 point; new provisioning methods, and some work to merge file and block services together (they also needed to create a storage services catalog), but they were basically there. This was a great example of the adaptive nature of some IT shops to evolve to cloud, and that this technology does not always need large new CAPEX requirements. In this case, having the USP-V as the cornerstone of the flexible cloud infrastructure was a real plus.

If you have been operating with ‘catalyst elements’ of a cloud (consolidation, virtualization and automation) then your cloud may indeed be an evolutionary journey. If these building blocks are not already in your IT infrastructure inventory, cloud or no cloud, you need to consider and plan for tactical elements for basic improvements, cost reductions and future enablement.

Future storage architecture necessitate key components: Virtualization, automation management, provisioning automation, dynamic tiering, policy-based management, multi-tenancy support, workload isolation. Sounds like a cloud recipe, but this is also what is working in production now to provide improved storage efficiencies.

I often talk about, write about, or consult about saving money. OPEX reduction is a hot topic and needs addressing, but there is another side of storage economics that can address increasing and generating new types of revenue from the right storage architecture. Granted, not all IT departments are revenue generating, but there are some basic concepts that can be applied from the list below even if you are a cost-center (as opposed to a profit center). Your boss may or may not ask you to “show them the money”, but there are architecture alterations that can increase or add to storage revenue for billable services.

Working with large SI and outsourcing customers in Asia and the Nordic countries this year, we have actively demonstrated architecture changes that can create new sources of billing revenue in the storage space. A partial list is shown below. I would like additional ideas to be submitted, if you have seen and measured the change in storage revenue.

1. With dynamic (non-disruptive) tiered storage, different levels of $/GB can be offered, each with a varied level of margin. Incentives can be given for consumers to move to lower tiers, while dis-incentives for higher tiers.
2. Again with the tiered option, a charge can be levied for data movement between tiers (a one time charge of $/GB moved) just like a brokerage service charges for buying or selling.
3. Providing an option to sell allocated volumes or ‘actual-use’ volumes to the end user (different rates and margin levels).
4. Offering an archive tier with different price/performance rate and different margins of profit for the service being offered.
5. In addition to a lower cost archive tier, you can offer Tier 0 capability for the customer. This may be small at first, but if tightly integrated with tiered allocation their tier 0 (solid state drives) can have a good profit margin and extends the levels of storage service you can offer clients.
6. Within the archive solution, offer discovery and index-search capabilities for faster discovery (important for legal and medical applications).
7. Different price points for buying thick volumes or thin volumes of disk capacity (provider has to cover the cost of the pool supplying the thin volumes, but that is covered in the overall margin calculation).
8. Using a virtual and consolidated storage architecture, management effort and tool costs decrease, changing the calculation rates for storage management tasks such as load balancing, snap copies, DR protection, etc.
9. Offering different target-tiers of storage for DR protection; again at different rates and margins.
10. Virtualization-driven lower migration services may appear to have a negative impact on future revenue (especially if you have a profitable migration business), but the endearing of your customer for lower costs in one area may entice them to purchase other services from you, such as DR or disk based backup.
11. Premium provisioning services – with thin volumes and virtualization it may be possible to present user-requested LUNs in hours or days, rather that weeks or months. A premium can be attached for rapid provisioning requests. Some customer would be willing to pay, others can wait if the delay is not worth the added cost.
12. Also on the fast provisioning service – if you can get a customer on your storage service faster, then you can start recognizing revenue for the capacity faster. This is simple cash flow planning, and if you do the math you may find that you do not need to offer a premium price for faster provisioning since the increased revenue stream will make up for the added service and processes to allow for fast provisioning.
13. Capacity on demand, or policy-driven provisioning. Capabilities exist to have applications or hosts now make the request (keeping the humans out of the loop) for new capacity. The consumption levels are measured and the consumer is charged for what was allocated/consumed during that period. Some upward and downward fluctuations are possible, but with a captive client the business growth is impacting your storage revenue.
14. De-duplication services to help your customer use less space. You charge for the de-dupe function, which can impact (negatively) your future capacity revenue stream to an extend.
15. Offering block and file services on the same pool of (tiered) disk, thus diluting the management costs and effort typically associated with SAN or NAS or iSCSI storage pools.
16. Disk backup options vs. traditional tape options. Different prices (and margin) for faster RTO and RPO to meet the users requirements.

More flexible storage service catalog, incorporating fast provisioning, multiple tiers, archive tiers, different DR and backup options. In total these added features and functions can enhance your storage portfolio offering, thereby attracting new clients. We often call this ‘storage as a service’ and gets away from selling dumb capacity to new vending models that allows targeting of the need to the price that warrants the particular service. Storage as a service can apply business intelligence and value to the storage infrastructure, and that provided better alignment of the value one sells to the price one receives.

If you purchase your storage from a service provider, the above list may be a clue to you that your vendor is adopting new architectures and solutions in order to increase there share of your wallet. Consider yourself warned…

Another aspect of the endowment effect is that people place a higher value on objects they own than objects that they do not. This is a certain fact in the IT world where spending has been curtailed, and people desire to sweat their existing assets to maximize the investments, defer additional capital expenses and “hunker-down” to ride out an economic and capex-sensitive storm. Some of the observable results can be seen as more and more IT shops are turning to server and storage virtualization to extend useful life of large assets, and to squeeze out every opportunity for capacity. When you have servers and storage running at 20-40% of capacity, there are compelling reasons to place a high value on these sunk assets and to make a small incremental investment to unlock stranded or unused capacity within the servers or storage arrays.

I have noticed medium and large clients taking a very proactive approach to asset utilization, because in part they value these assets that they own and are not in a position to get new assets. Moving from thick to thin volumes, changing RAID levels, virtualizing older arrays can produce some very impressive results with reclamation of 30-60% of capacity being very common. When we work with a client and help them reclaim enough capacity to run the operations “in growth mode” for an additional 12-15 months, then the assets get worked harder and a positive ROA measurement can be presented to management. As a vendor, we are always asked to lower our purchase price (and will always be a customer request), but our options now to help reclaim and better utilize existing assets is a stronger and more relevant approach in today’s climate.

I always thought it was our charm and wit that persuaded people in this way, but the endowment effect tells me that we are all economic creatures and that behaviors can be observed and measured (in part) with business or finance theories.

Backups were tough, and to supply off-site protection, we would take turns driving 9-track tape and cartages to a second facility in beautiful downtown Inyokern California. We affectionately called this our Chevy Truck Access Methods (CTAM); the ultimate in remote protection…

I had forgotten those old methods and ways until I read on the Register today about one cloud vendors approach to data recovery and export from a cloud. “If you wish to export data store from S3, you can send Amazon an email manifest and a storage device. The company will then download your data and ship it back to you through the mail.”

It is hard to believe that data center operations would/could still rely on the CTAM approach for exporting or moving data. Granted sending a 1 or 2TB USB drive is more efficient that a 9-track tape, but the methods we have to consider in some cloud architectures makes me wonder about moving forward or backward as an industry. This Byte and Switch blog supports the notion of care and planning in working out cloud operations, DR, data movements etc.

Now to be fair, we have to differentiate one cloud from another. HDS and other large enterprise vendors have been touting DC clouds for some time. Our approach with Virtualization at the core, along with dynamic tiering, the ability to de-reference data so that it can be access on different platforms, by different hosts and apps is one real version of cloud that works in a highly structured environment. We need to be sure that the methods and access approach to data (cloud or otherwise) is done with forward thinking operations and protections. Lets not return to a 20 yr old CTAM methods to chase a new an upcoming architecture scheme.

This is why – now during a tough economy more than ever – new storage architectures are necessary to better control data and storage growth requirements. Stand-alone storage, DAS, mini-SANs cannot sustain an economically viable state with the growth rates quoted by IBM, even in the mid-markets.

In reviewing my subscription to Financial Forecasts, some trends or forecasts that may have a larger impact on the mid-markets (although large markets are not entirely immune either).

1. Interest rate forecast (prime rate)
   • 2010 – 3.25%
   • 2011 – 4%
   • 2012 – 5.25%
2. GDP growing by .5 to 1% over the next 3 years
3. Inflation holding or declining over the same period

So with data growth, rising rates (impact on lease and other OPEX costs), the right storage architecture should be implemented now to optimize the future cost of growth.

My old truck is a 1999 Ford F-150. It is a ‘state law’ to own a truck in Texas. Luckily I still drive a 2006 F150 so after this trade-in I can keep my Texas citizenship. The old truck still ran well, had good A/C and decent gas mileage. Insurance was low and it was paid off 7 years ago. The operating costs were low (relatively) and I did not feel compelled to make a CAPEX investment until it completely broke-down. To me it was a great car for a 23-yr old son to drive to work.

Now the long-term economics for him and me seemed to become aligned when a government program gave me cash towards the price of a new Nissan. I was surprised to learn that insurance was the same on the new vehicle, and with a 3-year warranty my son will enjoy some trouble-free driving for the next few years. The new fuel economy will save him ½ the cost of fuel for his driving. Happy day for him.

I have thought a lot about the economics of my car situation, and the motivation that I needed to make this trade. We had been talking about a trade for many months, but with a perfectly good and working car, it was hard to make the new capital investment. The operating costs of the old car were reasonable. No long trips were required. This was simply a tier 3 automobile. But there was a tipping point, and the government helped us make that change.

Now let’s shift gears to storage. I met another large customer in Asia 2 weeks ago that had a moderately sized storage infrastructure, with old and new storage arrays virtualized behind a USPV in production, and SVC for the dev/test environment. They were strong believers and users of storage virtualization. They were using storage arrays long past the depreciation life. They were paying 3rd party maintenance, T&M on some arrays, and on the lower tiers they just had spare array groups in the case of failure. The cost/performance ratios were perfect for the lower tiers of storage. The CFO and CIO loved the fact that they were able to sweat the assets. When asked what or when they would be motivated to eventually replace the oldest arrays that were virtualized, they answered:
1.    When the failure rate was high enough to make a change
2.    The array, microcode was EOL
3.    The power and cooling costs on a per-TB basis exceeded a pre-defined limit

Now there were some old arrays, with 36 and 73GB drives. They must have met the criteria since they were in the virtual pool. These solution were meeting important (but not critical) business needs since they had a loosely defined catalog of services and these disk pools were operating within OLA and SLA limits of the virtual capabilities of these older arrays.

I am sad to say that there are not government “Cash for Clunker Storage Array” programs that I am aware of. There are some interesting options with different free offers that can be compelling, depending on your situation. So your tipping point has to be defined by:
•    CAPEX pressures or limitations
•    Growth rates
•    Definitions that come from a defined process (catalog) with SLA and OLA parameters that keep you protected when using these technical extensions
•    Metrics and management triggers that tell you when old enough is old enough

When it comes to old trucks, I do not give my government enough economic credit; especially when they help me buy an upgrade. In the business and IT world, we need to watch for, and define our own planetary alignment. We need to create economic metrics and measurements to extend and wear-out, as well as upgrade and refresh when appropriate.