PageRenderTime 479ms CodeModel.GetById 33ms RepoModel.GetById 0ms app.codeStats 0ms

/spec/data/hyp-planning.org

https://github.com/wallyqs/org-ruby
Org | 335 lines | 255 code | 79 blank | 1 comment | 22 complexity | d4ef5623808614c593d7f8bf5e266106 MD5 | raw file
  1. #+TITLE: Introduction to Hyper-V Pre-Planning and Planning
  2. #+AUTHOR: Brian Dewey
  3. #+EMAIL: bdewey@microsoft.com
  4. #+DATE: December 9, 2009
  5. #+DESCRIPTION:
  6. #+KEYWORDS:
  7. #+LANGUAGE: en
  8. #+OPTIONS: H:3 toc:t \n:nil @:t ::t |:t ^:t -:t f:t *:t <:nil
  9. #+OPTIONS: TeX:t LaTeX:nil skip:nil d:nil todo:nil pri:nil tags:nil
  10. #+INFOJS_OPT: view:nil toc:nil ltoc:t mouse:underline buttons:0 path:http://orgmode.org/org-info.js
  11. #+EXPORT_SELECT_TAGS: export
  12. #+EXPORT_EXCLUDE_TAGS: noexport
  13. #+LINK_UP:
  14. #+LINK_HOME:
  15. * DONE Introduction
  16. CLOSED: [2009-12-09 Wed 15:18]
  17. CLOCK: [2009-12-09 Wed 15:00]--[2009-12-09 Wed 15:18] => 0:18
  18. CLOCK: [2009-12-09 Wed 10:02]--[2009-12-09 Wed 10:14] => 0:12
  19. The pre-planning activities for Hyper-V proceeded in three
  20. phases. In the first phase, we identified and wrote down a set of
  21. /business value propositions./ These are things we could pitch to
  22. customers as new value they would get from using Windows 8. To wrap
  23. up phase one, we worked with Mike Neil's team in Windows Server to
  24. rank the business value propositions. This step ensured that COSD
  25. and Windows Server operated from a common, agreed-upon set of
  26. priorities.
  27. For the second phase of pre-planning, we brainstormed all of the
  28. features we would need to implement to deliver on the value
  29. propositions from phase one. We captured a short description of each
  30. potential feature in a one-page spec.
  31. In the final phase of pre-planning, the dev team estimated how much
  32. dev effort would be required to implement each feature.
  33. By the numbers, our pre-planning work generated:
  34. - 19 different value propositions
  35. - 159 one-page specs
  36. - A 770-line spreadsheet containing dev estimates
  37. - 4.5 times the amount of dev work than we can tackle in a single release
  38. Moving from pre-planning to planning, our objective has been to
  39. understand and to shape overall Windows priorities so we can pick
  40. the /right/ 20% of work to commit to for Windows 8.
  41. This document gives an overview of the different pre-planning
  42. activities we did. It provides pointers to the pre-planning
  43. artefacts we produced and shows how we've been able to map our
  44. pre-planning work into planning.
  45. * Business Value Propositions
  46. CLOCK: [2009-12-07 Mon 09:09]--[2009-12-07 Mon 09:50] => 0:41
  47. CLOSED: [2009-12-01 Tue 10:52]
  48. One of the first pre-planning activities we did in Hyper-V was
  49. define a set of /business value propositions/ (BVPs). A business value
  50. proposition is an end-to-end hook that can convince a customer that
  51. Windows 8 is worth buying.
  52. Our BVPs are stored in the [[http://windows/hyper-v/initiatives/Value%20Propositions/Forms/AllItems.aspx][Hyper-V Portal]].
  53. ** Anatomy of a BVP
  54. Each BVP followed a simple, one-page template with the following
  55. parts:
  56. - Customer Summary
  57. - Storyboard
  58. - Requirements
  59. - Partner teams
  60. The following sections walk through each section and give an
  61. example from one of our BVPs, [[http://windows/hyper-v/initiatives/Value Propositions/DynamicDatacenter-ValueProp.docx][Resource-Smart Virtualization
  62. Infrastructure]] (also called /Dynamic Datacenter/).
  63. *** Customer Summary
  64. The /customer summary/ section is a one-sentence description of
  65. the customer value proposition, written from the customer's point
  66. of view. Each customer summary starts with the phrase, /I want.../
  67. The purpose of this section is to make sure we can give a concise
  68. description of what we expect the customer to accomplish.
  69. #+BEGIN_QUOTE
  70. /Example:/
  71. I want to add or remove computing resources to company owned
  72. virtualization infrastructure automatically, on-demand in
  73. response to rapidly changing business needs without any loss of
  74. business availability.
  75. #+END_QUOTE
  76. *** Storyboard
  77. To help people understand the customer scenario, the /storyboard/
  78. section walks through the steps the customer would take to get the
  79. new value from Windows 8.
  80. #+BEGIN_QUOTE
  81. /Example:/
  82. Comsco warehouse IT provides access to multitudes of different
  83. workloads including database servers, LOB applications, and
  84. homegrown three-tier distributed applications spread across two
  85. sites. Tim, administrator at Comsco IT, wants to see VM life cycle
  86. management (create, deploy, service, move and destroy) utilizing
  87. their existing tools and want it to be more efficient process than
  88. managing physical servers. Tim wants Microsoft software to
  89. automatically create new VM on server from a pool of physical
  90. servers and deploy workload in the VM when combined criteria of
  91. load balancing and resource utilization he defined are met. While
  92. Tim will continue to monitor real-time usage and Joe, who works in
  93. CIO office, wants historical trending of resource utilization of
  94. CPU, memory, power, storage, network bandwidth, storage bandwidth
  95. and backup bandwidth for selected VMs and workloads across all the
  96. servers. Based on historical trend analysis, Tim receives business
  97. logic requirements from the office of CIO and he defines per VM
  98. multi dimensional policy in Microsoft software to automatically
  99. control resource usage allocation, resource prioritization and
  100. resource move for above resource types. Tim also wants to service
  101. storage hardware without any downtime to running workloads. Tim
  102. wants MS software to freely move workloads between his primary
  103. site and across the town secondary site as needed without any
  104. downtime.
  105. #+END_QUOTE
  106. *** Requirements
  107. This section captures the core requirements for delivering the
  108. customer value. Knowing we would not be able to do everything, we
  109. categorized requirements into those needed for delivering good
  110. value, a better value, and best value. To minimize the
  111. randomization that could come from the bucketing, we identified
  112. the customers who would be satisfied by a given level of value.
  113. #+BEGIN_QUOTE
  114. /Example:/
  115. | Target Level | Customer | Example Requirements |
  116. |--------------+-----------------------------------------+-----------------------------------------------|
  117. | Good | Large/medium enterprises | Storage migration with zero business downtime |
  118. | Better | Early adopters at the Dyanmic I/O model | VM migration for load balancing |
  119. | Best | Hosters | Chargeback infrastructure |
  120. #+END_QUOTE
  121. *** Partner teams
  122. Because BVPs describe end-to-end value, none can be delivered just
  123. from the Hyper-V team. This section notes the partner teams we
  124. would need to reach out to.
  125. #+BEGIN_QUOTE
  126. /Example:/
  127. SCVMM, Failover clustering, Kernel, Intel & AMD
  128. #+END_QUOTE
  129. ** BVP Ranking
  130. Working with Mike Neil's team, the Hyper-V trio and PM leads ranked
  131. the BVPs based on the information we'd gathered through CFD
  132. sessions and on the importance of competing with VMWare. The
  133. consensus opinion is stored in a spreadsheet [[http://windows/hyper-v/initiatives/Value Propositions/ValueProposition-BucketTemplate-Master.xlsx][here]].
  134. For each BVP, we also identified the target value level -- would we
  135. aim for good value, better value, or best value?
  136. Here's our ranked BVP list.
  137. | Value Proposition | Customer Statement | Target Bucket |
  138. |----------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------|
  139. | Resource-Smart Virtualization Infrastructure | I want to add or remove computing resources to company owned virtualization infrastructure automatically, on-demand in response to rapidly changing business needs without any loss of business availability. | Best |
  140. | Server High Availability | I want to ensure that my server applications are highly available. | Better |
  141. | Server Disaster Recovery | I want to ensure my business can quickly resume operations in the event of a disaster. | Better |
  142. | Platform Extensibility | I want a rich ecosystem so I'm not locked into a single vendor for storage, networking, etc. | Better |
  143. | Hosting | I need to be able to deploy thousands of physical servers into one or more farms dedicated for hosting. Provisioning of virtual machines must integrate fully into my back end network topology. Virtual machines must have strong network isolation. I must be able to monitor, change, charge for and throttle usage dynamically. I must be able to move virtual machines to another server in my farm with little or no downtime. | Better |
  144. | Scale Up | I want to get the maximum utilization from my hardware investment. | Better |
  145. | VDI | I want to control cost by deploying thin desktops and letting employees connect to a completely virtualized desktop. | Better |
  146. | Cloud Integration | I want to be able to dynamically enable movement of workloads between on premise and off premise without changing the operational or application model. | Better |
  147. | Security | I want to enhance the security of my system by making it more difficult for malicious programs to attack my operating system core. | Good |
  148. | Deployment | I want to increase efficiency in managing my datacenter & desktop infrastructure. | Better |
  149. | Green IT | I want to increase energy efficiency in my datacenter infrastructure. | Good |
  150. | Server test/dev | I want to quickly and easily create and test server applications. | Good |
  151. | Appliance Development Model | I want to reduce development costs by shipping a server application in a pre-configured VM. | Good |
  152. | Application Compatibility | I want users to have access to old applications even when I upgrade their desktop operating systems. | Cut |
  153. | Client test/dev | I want to quickly and easily create and test desktop applications | Cut |
  154. | Integration Testing | I want to quickly and easily test new applications and updates before deploying them | Cut |
  155. | Employee-owned hardware | I want to let employees use their own hardware to run corporate applications and connect to the corporate network in a secure way. | Cut |
  156. * DONE One-Page Specs
  157. SCHEDULED: <2009-12-07 Mon> CLOSED: [2009-12-07 Mon 16:39]
  158. CLOCK: [2009-12-07 Mon 16:26]--[2009-12-07 Mon 16:39] => 0:13
  159. Armed with the prioritized list of customer value propositions to
  160. consider for Windows 8, we started work on the next level of detail:
  161. What features would we need to implement to deliver the value
  162. proposition? Two main tasks refined our thinking in this
  163. area. First, we brainstormed all of the features required to deliver
  164. the target level of value in the BVP. Then, to reduce ambiguity, we
  165. wrote a /one page spec/ for each feature. What exactly does
  166. /cross-cluster live migration/ mean? The one-page spec tells
  167. you. The goal of the one page spec was to capture just enough
  168. information that a developer could estimate how expensive the
  169. feature would be to implement. Our one-page spec library is [[http://windows/hyper-v/w8/Specs/Forms/AllItems.aspx][here]].
  170. #+BEGIN_QUOTE
  171. /Example: Cross-cluster live migration/
  172. Key customer scenario: An enterprise is building large scale Hyper-V
  173. based infrastructure to run vast majority of server workloads with
  174. High-Availability is a requirement. Customer builds multiple
  175. clusters for one or more of the following business needs:
  176. # NOTE, for formatting reasons, don't fill the following.
  177. - To keep cluster size to be manageable based on preconceived perception of node failure time is linearly proportional to cluster size,
  178. - Due to increased business need they need to build new cluster once maximum supported cluster size is reached,
  179. - There are departmental clusters and temporarily there is a need to use extra capacity of a cluster when one cluster experiences capacity peaks.
  180. Customer would like ability to live migrate, quick migrate or move
  181. VMs from one cluster to other cluster for above mentioned needs.
  182. The goal is to provide more flexibility in VM mobility space without
  183. cluster as a boundary. Hyper-V needs to perform two operations in a
  184. transaction:
  185. - Live migrate VM from one cluster node to destination cluster node.
  186. - Live migrate VMs storage from one clusters shared storage to another clusters shared storage.
  187. If any of the above fails, VM must continue to run on the source
  188. node.
  189. A user should be able to orchestrate live migration through Hyper-V
  190. manager, Failover cluster UI, WMI or Powershell.
  191. Live migration should perform necessary checks to ensure live
  192. migration requirements are met. Some of the examples in addition to
  193. other migration checks are, performing estimation of time to migrate
  194. VM, access to the VM storage and same IP network on destination to
  195. ensure VM will be able to migrate successfully without dropping a
  196. TCP connection. If Hyper-V cannot reliably guaranty retaining TCP
  197. connection live migration should fail and must ensure VM continues
  198. to run on source node.
  199. Administrator should be able to set cluster wide, Hyper-V wide or
  200. per VM policies around allowing or denying live migrating one or
  201. more VMs from one cluster to any particular cluster or any other
  202. cluster.
  203. User experience and workflow of orchestrating live migration within
  204. a cluster or across the cluster site should be the same.
  205. #+END_QUOTE
  206. * DONE Feature SWAGS
  207. CLOSED: [2009-12-09 Wed 08:57]
  208. CLOCK: [2009-12-09 Wed 08:46]--[2009-12-09 Wed 08:57] => 0:11
  209. SCHEDULED: <2009-12-07 Mon>
  210. Using the one-page specs, the dev team estimated the dev time it
  211. would take to implement each feature identified to deliver on the
  212. business value propositions. The estimates are kept in this
  213. [[http://windows/hyper-v/w8/BVP/BVP%20Feature%20Expansion.xlsx][spreadsheet]]. The estimaes are fine-grained. To stretch an analogy,
  214. instead of t-shirt sizes, we've got estimates of the yards of thread
  215. required to make the t-shirt. For each feature we identified in the
  216. BVP process, the dev team estimated how to break apart the work and
  217. estimated the number of weeks of senior, mid-level, and junior dev
  218. time it would take to implement the feature.
  219. The key conclusion from the exercise: Our eyes are *way* bigger than
  220. our wallets. In the BVP process, we identified about five times as
  221. much work as we will be able to deliver in Windows 8.
  222. * DONE Moving From Pre-Planning to Planning
  223. CLOSED: [2009-12-09 Wed 15:20]
  224. CLOCK: [2009-12-09 Wed 09:56]--[2009-12-09 Wed 10:01] => 0:05
  225. CLOCK: [2009-12-09 Wed 09:00]--[2009-12-09 Wed 09:01] => 0:01
  226. Pre-planning identified a significant amount of work we /could/ do
  227. in Windows 8. Our challenge in planning has been to identify the 20%
  228. of the work on our list that best aligns with the overall Windows
  229. vision, so we can commit to this as work we /will/ do for Windows 8.
  230. The business value propositions we defined in pre-planning lined up
  231. well with planning themes & subthemes. As we moved from pre-planning
  232. to planning, we narrowed down the list of BVPs that we focused on,
  233. and we worked through the established theme & subtheme
  234. planning. Through the Windows planning process, we have been able to
  235. work with our partner teams to find alignment on priorities.
  236. The following table shows how we mapped our BVPs to planning themes
  237. for the planning process.
  238. | BVP | Planning Theme (Subtheme) |
  239. |--------------------------------------------------------------------------+----------------------------------------------------------------------------------------|
  240. | Resource-Smart Virtualization Infrastructure, Hosting, Cloud Integration | Infrastructure Scaled for SMB, Enterprise, & Service Providers (Hosted Private Clouds) |
  241. | Server High Availability | Continuous Availability (Contiuous Availability) |
  242. | Server Disaster Recovery | Continuous Availability (Business Continuity) |
  243. | Platform Extensibility | Big Bet: Scale for Datacenters |
  244. | Scale Up, Green IT | Infrastructure Scaled... (Leverage the Hardware Ecosystem) |
  245. | VDI | Work Anywhere (Centralized Desktops) |
  246. | Deployment | Management (Solution Deployment) |
  247. | Server test/dev, Client test/dev | Streamline the developer experience *or* Desktop for enthusiasts |
  248. | Appliance Development Model | Infrastructure Scaled... (Virtual Appliance for Partners) |
  249. * TODO Conclusion
  250. Because of our pre-planning work, we've had good alignment between
  251. COSD (and now Windows Core) and Windows Server on overall Hyper-V
  252. priorities and directions. The work on estimating feature costs has
  253. enabled us to set realistic expectations on the scope of work we can
  254. deliver in Windows 8. Taken together, our pre-planning work should
  255. have made Hyper-V a more predictable and transparent partner team to
  256. work with in the planning process.