Capacity Planning in Distributed Environments

1. Capacity Planning in Distributed Environments Dr Bernie Domanski City University of New York/CSI

2. Should Capacity Planning Be Treated With the Same Reverence As in the Past? Let’s all sing the hymn - “But That’s How We’ve Always Done It.” ©B. Domanski,1997. All Rights Reserved

3. Objectives & Agenda • View IT as a Service Provider; focus on service delivery for the survival of the company; • Does doing CP the same old way make sense because “That’s How We’ve Always Done It”? • Does the mainframe costing model make sense today? • When does make sense to do CP ? • There are alternatives to complex tools that model down to the disk revolution. ©B. Domanski,1997. All Rights Reserved

4. CP in a distributed environment should allow IT to make intelligent, cost-effective decisions regarding the resources required that will rapidly enhance the service given to its customers. The Key Message

5. Moore’s Law - Capacity Doubles Every 18 Months ©B. Domanski,1997. All Rights Reserved

6. Service Delivery • Timely delivery of services to customers • Global view of resource use • Cost mainaining a CP staff - what is the ROI? Cost of studying vs. just buying! • The difference for making mistakes is orders of magnitude different in price. ©B. Domanski,1997. All Rights Reserved

7. What’s the Real Reason to Do Capacity Planning? • If mission-critical business applications become overloaded, • Then poor performance could have a very serious consequence: • Revenue can be lost if dissatisfied customers move to the competition. • If you can't do it right yourself, pay someone else to do it for you! ©B. Domanski,1997. All Rights Reserved

8. Key Questions • Providing too much capacity? Ties up $$$ • When is CP done? If that new appl could negatively impact customers • Why is CP done? To be competitive; new features/functions implies sizing the underlying architecture correctly • What about business vs. technical requirements? Needs are ASAP and cheap => use modeling for broad evaluations ©B. Domanski,1997. All Rights Reserved

9. Scaleability and Compatibility • Success is a lousy teacher - Bill Gates • Out-of-date? 8-track tape player, vacuum tube television, or the monolithic mainframe computer. • The key to understanding mistakes is the need to initiate rather than to follow trends. Let’s look at some actual history: ©B. Domanski,1997. All Rights Reserved

10. History • 50’s / 60’s: Different machines/op. Systems for different computing purposes • 65: IBM/Tom Watson => scaleable 360 architecture; you could move your work up • DEC/Ken Olsen => PDP alternative; VAX in 77 offered scaleability too ©B. Domanski,1997. All Rights Reserved

11. What’s the Lesson Here? • IBM & DEC saw a need that business had … • to fill incremental computing needs in different ways ... • … without having to waste prior IT investments • This same need is still with us today! • Need more computing power? Get it for the mission-critical application software ©B. Domanski,1997. All Rights Reserved

12. Market-driven Compatibility • Originally is was difficult and expensive to “change brands” • Amdahl, HDS, StorageTek, EMC => where would we be today? • Proliferation of UNIX • IBM PC clones - Look at Apple! • Internet acceptance: Netscape, IE cross platforms • JAVA allows dynamic distributed systems ©B. Domanski,1997. All Rights Reserved

13. CP is Driven by New Business • What Drives CP for Distributed Systems? • Scaleable architectures • Market-driven compatibility • The key: the network - it’s the glue! • CP becomes less about counting MIPS, & • … becomes more about being driven by anticipated new business that has to be processed ©B. Domanski,1997. All Rights Reserved

14. WhadaWeWant? • we want to scale our applications up to process more work; • we want them to run on the new hardware we acquire; • we need to connect applications (i.e. data) that currently exist on different platforms; and • we don’t want to re-invent or convert anything, if we can help it, to keep our costs down and our productivity up. ©B. Domanski,1997. All Rights Reserved

15. Bill Gates - “It’s a little hard to appreciate how far we’ve come from the good old days where just to get the sales report formatted in a nice way, you might wait nine months! … we’ve really gone way beyond anything that ever happened on the mainframe. … you really will be able to do simple, multiserver applications. Just sit down, write a few lines of business logic, and boom - connect all that up.” ©B. Domanski,1997. All Rights Reserved

16. Sam Greenblatt - CA’s Senior VP of Advanced Technology “Integrating application, system and network management is helpful only if it yields useful business information. Nobody cares whether or not a system is down if it doesn’t impact their business.” ©B. Domanski,1997. All Rights Reserved

17. Is Capacity Planning a Checkoff Item? • Rather than burden the planner with commodity shopping, users took on that responsibility. • Do we even need CP any more? • it might be easier to just buy new gear when you need it, period, and not do any Capacity Planning at all! • Consider, too, the cost of doing a CP study ©B. Domanski,1997. All Rights Reserved

18. More Important Questions • Is the network yielding adequate performance? • What should we get/do if it isn’t? • How are scaleable distributed appl’s built? • How many more users can be added while preserving response time? • We seek a new perspective that is more closely tied with application-specific measurement. ©B. Domanski,1997. All Rights Reserved

19. Key to CP Success • Delivery of IT services, where ... • Scaleability and compatibility are key. • Deploying new applications on a specific architecture may be wonderful today, but • … may become disastrous tomorrow if that architecture becomes a dinosaur and new/faster/cheaper gear is available. ©B. Domanski,1997. All Rights Reserved

20. YOU MUST ... • become application savvy • understand the network. • focus attention identifying the parts of an application that won’t scale up well • offer alternative solutions. • keep compatibility across platforms at the forefront of your thinking. • be able to anticipate bottlenecks and propose alternative components ©B. Domanski,1997. All Rights Reserved

21. Tools to Help Find How Much Capacity is Needed • Cottage industry originated for the mainframe • Costs: $20K = $120K (*MXG) • Not meant for distributed applications • No end-to-end response time measurement • Queuing models ignored the network • No standout predictor of workload growth ©B. Domanski,1997. All Rights Reserved

22. Needed Measurement Tools • Populate a PDB with data from distributed applications • Display status of every resource in the distributed environment + drill-down • Need summarized data across systems for trending • Need simulation models along with queuing ©B. Domanski,1997. All Rights Reserved

23. Just-in-Time Capacity • Use the tools … • monitors • collections of performance data • models • … to findwhento add more resources • Adding at the right time implies: • no interruption in service quality • no paying for services before they are needed ©B. Domanski,1997. All Rights Reserved

24. Costing for Distributed Systems • A great advantage is being able to buy needed capacity in small increments. • Scaleability is key for capacity planning • You buy enough capacity to do your processing now ... • if additional capacity is required in the future, • then it is acquired at a reduced unit-cost • because of the constant improvement in price/performance ratios. ©B. Domanski,1997. All Rights Reserved

25. Is Costing That Simple? • Incur both acquisition and installation costs. • Over time, you incur operational costs (licensing fees, support personnel, and maintenance). ©B. Domanski,1997. All Rights Reserved

26. What Happens When Additional Capacity Is Needed? • Yes, you acquire a bigger server, but • Most companies would rollover the server • Causes a cascading effect, … costs that have to be incurred when installing each old machine in a new place, e.g. installing new software, testing, support personnel costs, etc. ©B. Domanski,1997. All Rights Reserved

27. Leilani Allen ”By the year 2000, it will cost more to keep old technology than to upgrade.” Bottom Line: change the focus of financial mgmt strategies from acquisition. The realities of the life-cycle of equipment dictate that ongoing operational costs demand more attention (consider rollover) ©B. Domanski,1997. All Rights Reserved

28. Service Levels • Service level measures should be reported by business unit and application - • availability, • response times and • workload volumes • Obstacles: • client instrumentation • different communication paths/protocols ©B. Domanski,1997. All Rights Reserved

29. ARM • Transaction instrumentation becomes the applications’ responsibility • ARM SDK addresses appl’s written in • C/C++, - Visual Basic, • MicroFocus COBOL, - Delphi • Approach systems management from the end-to-end appl. workload perspective, rather than as a collection of physical components. ©B. Domanski,1997. All Rights Reserved

30. Summary & Thoughts • The critical questions we must face -- • Is CP helping IT deliver the best service possible to its customers? • Are you building scaleable architectures that have market-driven compatibility? ©B. Domanski,1997. All Rights Reserved

31. More Key Questions to Ask Yourself ! • Perhaps a “checkoff” item CP philosophy may prove to be a real cost saver • Include the true costs associated with adding incremental capacity. • Without application-level instrumentation across platforms, service-level management across the enterprise may not be possible ©B. Domanski,1997. All Rights Reserved

32. More of What We Need • Reporting software must manage the volume of customer data across platforms, • It must address the network, the client and the server. • We need graphical modeling tools to make it easier to define the network • Modeling tools must be able to model any combination of hardware & software • Need predictions of IT service and usage from a global perspective as well as a detailed focused perspective ©B. Domanski,1997. All Rights Reserved

33. That’s It For Now! Thanks for listening Any questions??? Dr Bernie Domanski Phone: 732-303-1500 Fax: 1503 Email: drbernie@superlink.net ©B. Domanski,1997. All Rights Reserved