IBM Autonomic Computing and Solution Installation David Cole IBM AC Customer and Partner Programs

2 Complex heterogeneous infrastructures are a reality!

3 Autonomic Computing helps solve customer challenges by building an on demand infrastructure Operational speed too slow IT flexibility too limited Operational cost too high, efficiency too low Management of complex, heterogeneous environments too hard The inability to manage the infrastructure seamlessly IT asset utilization is way too low Swamped by the proliferation of technology and platforms to support Privacy, security and business continuity

4 IBM’s vision for Autonomic Computing “Intelligent” open systems that:  Manage complexity  Know themselves  Continuously tune themselves  Adapt to unpredictable conditions  Prevent and recover from failures  Provide a safe environment Focus on business, not infrastructure Providing customer value  Increased return on IT investment  Improved resiliency and quality of service  Accelerated time to value

5 Autonomic Computing attributes Increased Responsiveness Adapt to dynamically changing environments Business Resiliency Discover, diagnose, and act to prevent disruptions Operational Efficiency Tune resources and balance workloads to maximize use of IT resources Secure Information and Resources Anticipate, detect, identify, and protect against attacks Self-managing systems that deliver:

6 Levels of autonomic maturity Level 2Level 3Level 4Level 5Level 1 Basic Managed Predictive Adaptive Autonomic Manual analysis and problem solving Centralized tools, manual actions Cross-resource correlation and guidance System monitors, correlates and takes action Dynamic business policy based management Evolution not revolution IBM’s autonomic computing initiative will become its most important cross-product initiative (as the foundation of on demand). —Thomas Bittman ” “

7 Core building blocks for an open architecture  An autonomic manager contains a continuous control loop that monitors activities and takes actions to adjust the system to meet business objectives  Autonomic managers learn from past experience to build action plans  Managed elements need to be instrumented consistently Knowledge AnalyzePlan MonitorExecute Element SensorsEffectors The autonomic computing control loop

8 Self-Healing/Problem Determination Solution Installation Unified Policy Management Common Integrated Solutions Console Autonomic Monitoring Engine Heterogeneous Workload Management Provisioning and Orchestration IBM Global Services Autonomic Computing core technologies provide the building blocks that enable key on demand capabilities Core Technologies

9 Autonomic computing has taken its first steps The cornerstones are in place:  Architecture  Open standards  Partners  Technology Momentum continues to build IBM brings autonomic computing from concept to reality. —InfoWorld “ ”

10 Autonomic Computing Solution Installation

11 Addressing the change/deployment problem Objective: Reduce the elapsed time, the amount of effort, and the skills needed to upgrade significant portions of the infrastructure. In order to understand what is needed, let’s put the “interactions” in the context of a change management process. Assess Change Impact for “x” Create Change Plan for ‘x” Verify Change Plan Test Change Plan Implement Change Roll Back Change The activities in the change management process that are “problem children” are: Dependency Management & Deployment planning & Change Management Element MonitorExecute Analyze Plan Knowledge SensorsEffectors Autonomic Element SensorsEffectors

12 Customer Pain Points  Inconsistent dependency management for planning and deployment  Ad hoc and inconsistent handling of versions of shared components  Duplicated configuration code in installer, software, admin tools  Runtime dependencies not addressed  Only a subset of configuration requirements described  Difficult or impossible to back out changes / return to known good state  Untrusted installer code  No repair or self-healing capability  Difficult to merge products, features, component from multiple packages  Altering original packages invalidates QA (no repackaging)  High degree of control for software producer, little control for management software or systems administrators

13 Installable Unit / Hosting Environment Design Patterns The design pattern can be used at all levels of the resource stack. Database Server Create Table D Web App Server J2EE App D Operating System Software Product D In general, things that gets installed or created can fit into the “IU – HE” design pattern. A “package” structure like a JAR file that includes a descriptor and some collection of files. A descriptor that describes the content of the installable unit. This is a hosting environment or container that can accept an artifact. An artifact that can be installed. A D Installable Unit (IU) This design pattern makes it possible to standardize many aspects of the technologies we used to install the various resource types.

14 Installable Unit Taxonomy Installable units may exist alone or be aggregated. A A A D Installable Unit An IU is composed of one or more artifacts for a particular container type. A A A D A D A D Solution Module Definition D A package that contains one or more IUs for many different containers, and may also contain other SMDs.

15 More Detail SensorEffector Collect details about the capabilities a hosting environment has Install (artifact) Change Manager Dependency Manager Hosting Environment A Extract from IU details about the capabilities a hosting environment needs to provide. Extract and prepare the artifact(s) ISSI A hosting environment is an AC managed element and the sensors and effectors for this managed are often referred to as a touchpoints. This web service needs to expose interfaces to collect dependency info (sensors) and install artifacts (effectors). D AD

16 Base Scenario Overview InstallShield Install Engine Java API 1 PackageX.zip (SMD) SI Runtime -Installed if not there -Dependency checking -OS Actions Java API Web Services 3 Cloudscape DB’s IU DB TP DB 47 HE Touchpoint S E List Installed Software Add files Pkg X files 562

17 Use of Solution Installation V1.2 packagedIU.xml Function Group/ Component Owner Packaged IU Packaged Offering IU/SMD Authoring (ISSI) BuildDeploy Solution Module Developer Solution/Offering IDE SI Dependency Mgmt: - Elem. Checks - Dependencies Touch Points -Registry -Checks -Install -Uninstall -Verify -Rollback -Configure SI Change Manager −Plan, Coordinate Installer Software −Install/Uninstall −View Media −Verify Legacy Artifact Native Installer = SI Framework

18 Tooling Solution Install – Version 1 SE SE SE Dep. Checker Installer IU DB IU Tooling IU X-Sys Dep. Check Deploy Logic Tooling X-Sys TP Registry IU Instance IU Discovery TP Discovery TP Reg. Tooling V1 IU Instance IU Type DB Multiple HE Single Machine SE SE SE Dep. Checker TP Discovery TP Reg. IU Instance. IU DB. Installer TP Discovery Future Solution Install across multiple machines Solution Install on single machine Multiple HE Multiple Machines

19 Offering perspective Brand new offering Composed of parts of other offerings Offering 1 Offering 2 Offering 3 Unique IU Combine components with no impact to developers New Offering

20 Benefits of Solution Installation  Value to Customers –Reduced time/effort (cost) to deploy and maintain solutions Spend IT $ more efficiently (more on software/hardware, less on services required to install) –Increased availability through more stable & reliable system changes Known dependencies and relationships among components, including runtime Ability to return to known good state Repackage to suit business requirements  Value to ISV’s –Simplifies increasingly complex and componentized software build & packaging steps –Easier to respond to marketing’s request to create new bundled offerings –Consistent description of solution available to all stakeholders –Differentiator in the marketplace

21 Value proposition to Developers Product Developer – Now How do I check for X? What will break if I uninstall Y? Do I need to migrate Z? How can I update my dependency information now I’ve shipped the product? Platform Developer – Future I can easily deploy to multiple test topologies I can automate more of the configuration, so that the user makes fewer errors Platform Developer – Now How can I define cross-machine dependencies? How can I help the user set up the cross-machine configuration? How can I specify valid topologies for my platform? How can I help automate the deployment of the platform? Product Developer – Version 1 I don’t need to write code to check for other products I can detect what might be impacted if I remove or upgrade a component I can ship new dependency and signature information I can handle fixes and updates Dependencies are accurate Consistent way to relate to install developers Any Hosting Environment, not just OS

22 Development perspective (today) Component Developer Install Developer Other (QA, ID, etc) Create specific software, hardware, storage, etc. deliverables Identify prereqs Create install & deploy logic Identify & copy files Create package Identify prereqs

23 Development perspective Component Developer Install Developer Create deliverables Identify prereqs Create general install logic Copy files Create package Custom install/deploy logic Identify files Enhance communications with Component Developer who best knows how to describe the component. Free the Install Developer to focus on combining applications. Tooling is available to help!

24 Who can develop with Solution Installation? Customers (Data center) In-house developed applications Integrated into build/package process Deployed internally or externally ISV’s Applications and solutions written for commercial sale Differentiating feature Reduce complexity to deploy Customer time/effort Support costs Install Vendors Development tools to support SI packages Create/install packages using SI format IBM Consistent install experience across brands Enhanced customer satisfaction Reduced support costs

25

26 " While independent in its ability to manage itself, an autonomic computing system must function in a heterogeneous world and implement open standards – in other words, an autonomic computing system cannot, by definition, be a proprietary solution." Paul Horn, autonomic computing: IBM's Perspective on the State of Information Technology, IBM 2001 " While independent in its ability to manage itself, an autonomic computing system must function in a heterogeneous world and implement open standards – in other words, an autonomic computing system cannot, by definition, be a proprietary solution." Paul Horn, autonomic computing: IBM's Perspective on the State of Information Technology, IBM 2001 To enable autonomic computing architectural framework Common APIs, protocols, taxonomy for interoperability across elements Instantiation through technology and reference implementations Autonomic Computing Standards Focus

27 D IU Standardization EARs Tables Middleware Portlets Applications Change Manager (Dependency Checker) Touchpoints Hosting Environment Key Points Requiring Standardization 1. Installable Unit Descriptor 2. IU Package Format Future: Hosting Environment Touchpoints Installable Unit Package

28 Key Solution Install points in summary  Declarative –Allows introspection and customization  Dependencies –Rich language for expressing dependencies and relationships –Solution Install performs the heavy lifting  Componentization  Standards based  Addresses complexity of today’s enterprise (and SMB) heterogeneous environments  Extendable to address growing future complexity

29 Questions and Answers