A Fit for Purpose discussion
-
Upload
claude-riousset -
Category
Technology
-
view
152 -
download
1
description
Transcript of A Fit for Purpose discussion
© 2010 IBM Corporation
“Fit for Purpose” – Systems Selection
IBM Systems Technical University – Lyon, France - 25-29 October, 2010
Claude RioussetExecutive IT ArchitectIBM Systems & Technology Group
« Lite version »
2 © Copyright IBM Corporation, 2010
IBM Systems Technical University – Lyon, France - 25-29 October, 2010
Each tool offers varying levels of capabilities…
Lear Jet 60 (Corporate)
Capacity = 7 (8 with belted toilet)
Range = 2,691 miles
Cruise Speed = 514 mph
MD – 90 (Regional)
Capacity = 153
Range = 2,400 miles
Cruise Speed = 503 mph
Boeing 747-400 (Large Capacity)
Capacity = 420
Range = 8,827 Miles
Cruise Speed = 563 mph
The right ‘tool’… All of these tools can move a person from one place to another…real fast….
3 © Copyright IBM Corporation, 2010
IBM Systems Technical University – Lyon, France - 25-29 October, 2010
But…which is the right tool… to move 1 person? 100 people? 400 people?
4 © Copyright IBM Corporation, 2010
IBM Systems Technical University – Lyon, France - 25-29 October, 2010
Many Factors Affect Choice
Car Server
Purchase price Purchase price
Gas mileage, cost of repairs, insurance cost
Cost of operation, power consumption, floor space
Reliability Reliability
Safety, maneuverability, visibility, vendor service
Availability, disaster recovery, vendor service
Storage capacity, number of seats, towing capacity
Scalability, throughput
Horsepower Chip performance
Dash board layoutSteering wheel location
Instrumentation and skills
Handling, comfort, features Manageability
Looks, styling, size Peer and industry recognition
Would you purchase a family car solely
on one factor?
5 © Copyright IBM Corporation, 2010
IBM Systems Technical University – Lyon, France - 25-29 October, 2010
Key Concepts and Terms
6 © Copyright IBM Corporation, 2010
IBM Systems Technical University – Lyon, France - 25-29 October, 2010
How do most companies select a platform for their applications?
� First question is – “Will it run there?”
� Second question is– “How much does the hardware cost?”
� Done!
� But this is just a TCA view ……Is that all we should be thinking about?
7 © Copyright IBM Corporation, 2010
IBM Systems Technical University – Lyon, France - 25-29 October, 2010
What did we miss? Non -Functional requirements
� Shouldn’t they have asked some questions about:– Scalability? Availability? Backup? Site Disaster Recovery?
– Security? Reliability? Data Integrity? Maintainability?
– Volumes and Service Levels? Scale?
– Space? Power? Cooling?
– Operations? Scheduling? Monitoring? Server Management?
– Integration? Performance and Value of Data Proximity?
� Fit-for-Purpose thinking leads to a holistic or TCO view?
8 © Copyright IBM Corporation, 2010
IBM Systems Technical University – Lyon, France - 25-29 October, 2010
Platform Selection
9 © Copyright IBM Corporation, 2010
IBM Systems Technical University – Lyon, France - 25-29 October, 2010
Selecting a Platform
Systemz
System x
Power
Time HorizonISV Support
Non-FunctionalRequirements
Power, cooling,floor spaceconstraints
Strategic Directionand Standards
Cost ModelsSkills
Politics
PlatformArchitecture
TechnologyAdoptionLevel
DeploymentModel
Scale
GeographicConsiderations
10 © Copyright IBM Corporation, 2010
IBM Systems Technical University – Lyon, France - 25-29 October, 2010
Local Factors are Important
� Platform and workload type
� Local factors (constraints)– Skills
– Technology adoption levels
– Platform management practices
– Number of servers
– Organization considerations
� Develop comparison metrics– Consistent, collectable, usable
� Become best of breed P
latfo
rm F
acto
r (
e.g.
Ava
ilabi
lity)
Platform A
Industry Average
Best of Breed
Below AverageIndustry Average
Best of Breed
Below Average
Platform B
11 © Copyright IBM Corporation, 2010
IBM Systems Technical University – Lyon, France - 25-29 October, 2010
Strategic and Tactical Platform Choices
All Tactical Choices
• Can Lower decision costs
• Based upon history, convention, momentum, skills, and previous strategic decisions
• Narrow focus can lead to sub-optimal solutions
All Strategic Choices
• Can lower long term costs
• Can run afoul of legacy
• Strategic direction important
• New technologies will change strategies
Tactical Strategic
Complete Business Case
IT Decision
• Balance tactical & strategic
• Develop reference architectures
• Mergers and acquisitions can introduce non-strategic solutions
• Balance of visionary and established patterns
12 © Copyright IBM Corporation, 2010
IBM Systems Technical University – Lyon, France - 25-29 October, 2010
Reference Architectures
�Pattern for repeated decisions– Lower decision making cost
– Lower implementation variability
� Larger than single decision - unlike a standard
�Based upon – Actual implementations
– Architectural decisions
�Can be long term decision setting
13 © Copyright IBM Corporation, 2010
IBM Systems Technical University – Lyon, France - 25-29 October, 2010
Functional and Non -Functional Requirements
Functional“What it does”
• Correct business results
• Inputs
• Outputs
• Behaviors
• External interfaces
• Screen layouts
Non-Functional“How well it does it”
• Availability requirements
• Transactions per minute
• Security requirements
• Ease of provisioning and support
• Disaster recovery requirements
• Future growth
Select platforms based upon non-functional requirem entsdriven by business value
Select or design applications based on functional r equirements driven by business process, and non-functional requ irements
14 © Copyright IBM Corporation, 2010
IBM Systems Technical University – Lyon, France - 25-29 October, 2010
Common Deployment Models
OS
UI
OS
App
OS
Data
OS
UI App Data
Centralized
� Components are all together
� Very granular resource sharing
� OS workload management
� Strongly integrated and stacked
Virtualizer
OS OS OS
UI App Data
Virtualized
� Components split across virtual images
� Coarser grained resource sharing
� Virtualizer workload management
� Stacked and integrated over network
Dedicated
� Components split across servers
� No resource sharing between servers
� Limited workload management
� Integrated over physical networks
15 © Copyright IBM Corporation, 2010
IBM Systems Technical University – Lyon, France - 25-29 October, 2010
High Level Workload Definition
�Workloads are a combination of:– Application function: What it does and how it does it
– Data structure: Data residency, topology, access model
– Usage pattern: Utilization profile over time, mix of use cases
– Service level: Non-functional requirements
– Integration: Interaction between application & data components
�The workload requirements will create varying deman ds when determining server alternatives
16 © Copyright IBM Corporation, 2010
IBM Systems Technical University – Lyon, France - 25-29 October, 2010
Workload Attributes and Market Segmentation
Transaction Processing and Database
High Transaction RatesHigh Quality of ServicePeak WorkloadsResiliency and Security
Analytics and High Performance
Compute or I/O intensiveHigh memory bandwidthFloating pointScale out capable
Web, Collaboration and Infrastructure
Highly threadedThroughput-orientedScale out capableLower Quality of Service
Business Applications
ScaleHigh Quality of ServiceLarge memory footprintResponsive infrastructure
17 © Copyright IBM Corporation, 2010
IBM Systems Technical University – Lyon, France - 25-29 October, 2010
Server Architecture - More Technical Workload View
Mixed
• Highly threaded
• Shared data and work queues
• Parallel data structures
• Small discrete applications
Parallel Data Structures
Mixed
Highly Threaded
Shared Data & Work Q
Small Discrete
18 © Copyright IBM Corporation, 2010
IBM Systems Technical University – Lyon, France - 25-29 October, 2010
Consolidating Workloads Optimizes Efficiency
� Single workload model assumptions:
– Average: 21%; Peak: 79%
– Random arrival rate
� As copies of this workload are added:
– Average approaches peak
– Total CPU grows at slower rate
Single Application Server (2 CPUs)
0%
10%
20%
30%
40%
50%
60%
70%
80%
Average 21%, Peak 79%
8 to 1 Consolidation (8 CPUs)
0%
10%
20%
30%
40%
50%
60%
70%
80%
Average 39%, Peak 76%
64 to 1 Consolidation (36 CPUs)
0%
10%
20%
30%
40%
50%
60%
70%
80%
Average 61%, Peak 78%
19 © Copyright IBM Corporation, 2010
IBM Systems Technical University – Lyon, France - 25-29 October, 2010
Hit the earth
Miss the earth
Apollo 13
2%
Which environment would you like to _______?
�Not all workloads scale linearly�Deployments change with size and scale�Server proliferation can impact operations
– Patching, Clustering, Cabling, Disaster Recovery
�Strategies– Standardization, Virtualization,
Centralized Deployment, Automation
20 © Copyright IBM Corporation, 2010
IBM Systems Technical University – Lyon, France - 25-29 October, 2010
Scope Limitation Leads to Sub -Optimization
�A single application or departmentview is easiest to understand
� Issues– May be driven by politics
– Runs counter to enterprise IT optimization
– May make an enterprise view harder to establish
– Can lead to large hidden costs
– Server sprawl
�Enterprise wide, scope specific, reference architec tures
21 © Copyright IBM Corporation, 2010
IBM Systems Technical University – Lyon, France - 25-29 October, 2010
Developing a Cost Model
22 © Copyright IBM Corporation, 2010
IBM Systems Technical University – Lyon, France - 25-29 October, 2010
Cost per Unit of Work
�Shared costs tend to fall– Centralized & virtualized
– Level of sharing
�Dedicated costs tend to rise– Complexity
– Software
– Datacenter factors
� Local factors affect curves
�Acquisition vs. total costs
Cost per Transaction
Workload Volume
Cos
ts p
er T
rans
actio
n
Dedicated
Shared
TCA TCO
23 © Copyright IBM Corporation, 2010
IBM Systems Technical University – Lyon, France - 25-29 October, 2010
Cost Models have Different Purposes
Selection
� All measurable costs for all environments over time
� Not based on step costs such as new book, frame or chassis
� Friendly to new technologies such as virtualization & cloud
� The choice of cost and value elements can dictate what is considered the lowest cost
Acquisition
� Will include step costs such as new books, frames, chassis
� May ignore redeployed or on the shelf software licenses
� May ignore infrastructure costs for power, network, & space
� May ignore increased utilization of existing capacity
Chargeback
� Designed to recover costs
� Often simple and incomplete
� May distort choices between alternatives
� May need multiple models
� Public clouds incorporate all three cost models
� IT should own IT infrastructure
Would car choices be different if someone else paid for the gas?
24 © Copyright IBM Corporation, 2010
IBM Systems Technical University – Lyon, France - 25-29 October, 2010
Wrap Up
25 © Copyright IBM Corporation, 2010
IBM Systems Technical University – Lyon, France - 25-29 October, 2010
Also:
Beware hidden cost of sub optimization.
Large reliable servers are best for virtualization
Don’t trust benchmarkresults that scale
“nearly linearly”
Ask IBM for a “Fit for Purpose” discussion with your IBM Systems Architect
• Will this platform run my solution? • How well will it run? • What will it cost me? • What is the impact on my enterprise? • Can I operate and manage it well enough? • Will my organization accept it? • Is this platform effective for the application
scope? • How does this platform fit into my current
infrastructure? • Is this solution shared or dedicated to a single
business process? • Do I know all the inherited requirements?
Scaling with Core Count
Cores
Effe
ctive Cores
64 to 1 Consolidation (36 CPUs)
0%
10%
20%
30%
40%
50%
60%
70%
80%
8 to 1 Consolidation (8 CPUs)
0%
10%
20%
30%
40%
50%
60%
70%
80%
Local Factors Matter
System x
Power
Systemz
26 © Copyright IBM Corporation, 2010
IBM Systems Technical University – Lyon, France - 25-29 October, 2010
When to consider “Fit-for-Purpose”
� Lifecycle Refresh
�Server Consolidation
�Re-Platforming
�Data Center relocations or Consolidation
�Business case development– Early in the application design process
© 2010 IBM Corporation