Insight and analysis on the data center space from industry thought leaders.
First Key to Brokering IT Services Internally: Know What You’ve Got
Internal Cloud delivery is about managing your supply and demand to meet and exceed your client’s expectations, writes Dick Benton of Glasshouse Technologies. In this series of posts, he explores what teams can do to build a better strategy of service for internal clients.
September 12, 2012
Dick Benton, a Principal Consultant for GlassHouse Technologies, has worked with numerous Fortune 1000 clients in a wide range of industries to develop and execute business aligned strategies for technology governance, cloud computing and disaster recovery.
Dick-Benton-sm
DICK BENTONGlasshouse
Last month, we outlined seven key tips IT departments should follow if they want to begin building a better service strategy for their internal users. The first step, which we’ll explore today, is knowing what you’ve got. You must ensure that you can run a supply and demand model and inventory management on those resources you intend to deploy as an Internal Cloud service Provider (ICSP). Internal cloud delivery is about managing your supply and demand to meet and exceed your client’s expectations.
It’s sad but true that many organizations don’t really have a good handle on their asset base, or on how fast their resources are being consumed. Overcoming this deficiency is an essential component for those wishing to operate as an Internal Cloud Service Provider (ICSP). To address this deficiency, we first need an agreed standard unit of deployment for each resource and must know how many of these resource units are available, deployed and utilized; basic inventory control. The more mature organization might even include an aged usage assessment of how long a cloud resource has been deployed and the average time to live (TTL) of returnable resources. These metrics are key to building a supply and demand model as an ICSP.
Defining Deployable
The first step in knowing what you’ve got is developing a policy defining the deployable resource. Deployable resources are usually defined as GB of storage, GB of bandwidth, GB of memory and a CPU. Sometimes CPU and Memory are combined in several size options as the deployable resource unit. It’s equally as important to define what we mean by each. For example, is it raw or configured GB of storage? What is the definition of a CPU (via Amazon)? Does it include memory or not? Does the resource include failover capability natively, or is this a service extra?
Secondly, we need a policy that defines the “trigger point” when more head room is needed, also known as your utilization factor. This threshold will trigger the purchase of additional resources. Thirdly, we need a tool that allows us to monitor the resource units and report on their state as needed. This inventory information is then fed into the supply and demand model for both physical and virtual resources.
Tracking Demand
The ICSP must also know what is happening in the demand patterns that consume the available resources. This needs to be dynamic and reflect daily/hourly trends, if not by the minute in the more progressive organization. The ICSP must also be able to identify average TTL for returnable resources. All of these factors are essential in ensuring that supply can meet reasonable forecast demands. It is important to ensure your policy on head room (utilization) is signed off and agreed upon by your management. No model can cost-effectively cater for wild swings in dynamic demand.
As you can see, an effective inventory management system and a dynamic supply and demand model is a prerequisite for those wishing to deliver IT resources as an internal Cloud Service Provider.
In our next post, we will look at how to "figure what it costs." I will discuss how to develop a cost model so you can determine the cost per deployable unit of your cloud resources.
Industry Perspectives is a content channel at Data Center Knowledge highlighting thought leadership in the data center arena. See our guidelines and submission process for information on participating. View previously published Industry Perspectives in our Knowledge Library.
About the Author
You May Also Like