As discussed previously, the Service Catalogue is a key component of delivering storage as a service. In this post, I’ll explore some thoughts on developing a Service Catalogue and how its abstraction from technology allows the delivery of a more efficient operation.
What’s in a Name?
Some people call it Service Catalogue or Product Catalogue, even storage tiers. The name isn’t too important, however what’s essential is that the Service Catalogue should exhibit a number of key components:
- It should be abstracted from technology.
- It should provide service metrics — explaining what you get for your money.
- It should be able to scale up or down to meet customers requirements.
- It should provide charging information based on simple billable units.
Technology Abstraction
For those familiar with delivering IT, the concept of offering a service that is abstracted from the technology itself may seem a little confusing. However, by continually referring to technology, organisations tie themselves into being able to offer only that technology itself as part of their service catalogue. For example, if your “tier 1″ storage offering consists of 15K 300GB FC drives in an EMC DMX-4 array, then customers will expect you to deliver tier 1 storage from that kind of box. What happens if EMC can offer a lower cost alternative through their latest technology like V-Max? What happens if 300GB drives reach EOL? What happens if another vendor (e.g. HP or Hitachi) can offer the equivalent technology at 20% reduction in cost?
By retaining a connection between the service offering and storage, IT providers restrict their ability to introduce new technology that can reduce cost and improve service. If however, service tiers or product offerings are suitably abstracted from technology, then costs can be reduced by taking opportunities to (a) implement new, cheaper technology or features (b) implement a competitive environment with multiple vendors.
Of course, it’s easy to talk about bringing in cheaper technology, either by using newer, cheaper hardware or by bringing in a new vendor who is prepared to take a beating on price just to get into a new account. The implications of this kind of disruption may negate the potential savings because existing processes or architectural design can’t cope with the change. In many organisations the process for storage deployment is based around the hardware product, as is reporting and billing. The clear message here is that it’s essential to ensure both the operational and engineering functions will work across multiple varied technologies. The subject of new technology adopotion and integration will be the subject of a future post.
Comparison with Other Industries
As mentioned in previous posts, the concept of delivering Storage Services is typically compared to utility companies. Consider our functional requirements for service in comparison to say, an Electricity or Phone company.
- It should be abstract from Technology. This rings true for the delivery of say, electricity to a domestic dwelling. In the UK, everyone expects to receive 240V at 50Hz as a standard. Changing to another supplier doesn’t require a change in electricity standard; the process of electricity generation doesn’t affect the end delivery, whether it is generated from wind, wave, nuclear or coal.
- It should provide service metrics. Whether explicitly written into a contract or not, I think most electricity users would expect their service to be available on a 24×7 basis. In addition, the supply should be guaranteed to remain within certain tolerances — e.g. 240V ±10% and 50Hz ±1% for example. Deviation outside of these standards would have a seriously adverse effect on equipment using the supply.
- It should scale. Unless you’re a commercial user, most electricity companies would expect to be able to increase and decrease their electricity consumption without consideration of how that supply was provided and without contacting the provider. In fact in the UK the National Grid are responsible for monitoring demand and bringing supply in and out of use to match requirements. This is all part of the service and therefore included in the cost of supply.
- It should consist of Billable Units. Check your electricity bill; you’ll find your charge is based on a price per kWh, a standard unit of measurement of power. Your charges are directly related to your consumption and not to how the power was generated. It’s worth noting that some providers will offer multiple tariffs, for example providing cheaper electricity at night or tying consumption into green issues. These tariffs are analagous to storage tiers.
Building a Service Catalogue
How do you go about designing and implementing a storage catalogue? Here are a few pointers:
- Look to include functional requirements (availability, response times).
- Look for cost & service differentiation. Some organisations implement many different tiers of storage or product offerings. Implementing multiple tiers can become expensive and if they’re not all utilsed efficiently, then the potential cost benefit is lost. Implementing multiple tiers offers the ability to reduce costs by placing less active or less demanding data on cheaper resources.
- Look to drive behaviour; implement services that penalise lack of adherence to standards and so on, but reward forward planning and utilising forecasted resources.
A Basic Template
Here’s a generic example of delivering a service catalogue for Enterprise SAN Storage. It keeps things simple by offering only three tiers;. each can include extra features such as local or remote replication.
- Gold – Availability — 99.999%; Response time: <10ms on 99.9% of I/Os sampled over a 5 minute period. Connectivity — FC — $10/GB/Month
- Silver – Availability — 99.999%: reponse time <15ms on 99.9% of I/Os sampled over a 5 minute period — conncetiivty — FC — $5/GB/month
- Bronze — Availability 99.9%; reponse time < 20ms — connectivity = iSCSI — $2/GB/month
Additional “bolt-ons” for each tier include:
- Local replication. Add a local replica for an additional tier price per month (gold replica for $10/month)
- Remote replication. Add a remote replica for the cost of the replica plus 10% (e.g total cost per GB for gold is 22$/GB/month
Additional comments: Billing is based on average configured storage over the course of a calendar month, measured at 00:01 each day. Totals are based on the storage used per server, rounded to the nearest GB. Costs assume no more than 1 allocation/deallocation per server per month; additional requests will incur an additional configuration charge. Costs do not include and host software or hardware required to connect to the storage.
Every organisation will have their own specific requirements that determine the best way to structure a storage catalogue. In future posts, I’ll discuss more about the process of developing the catalogue, how it integrates with product selection and operational management.
