Managing ApplicationsStatus of Standards

Today

February 5 2003

Open Group Members Meeting

San Francisco

Karl Schopmeyer

An Application Manageability Group

Objectives Today Determine what such a group can contribute

to application management Determine if we want to make such a group

work. Determine what the basic charter for such a

group is Determine who we want involved.

User side Supply side

The changing IT environment

Business Awareness Shift Tactical: Management of IT resources Strategic: Optimization of Business

Fundamental architecture shift From

Distributed, n-tiered topology Difficult and expensive to manage Big footprint Marginally reliable computing Many I/O media

To Distributed, n-tiered topology Rich, policy-based management Reduced footprint Highly scalable, reliable computing Converged I/O medium

Application transparency

Network-based, loosely coupled tiers enabled bydistributed computing and management technologies

Loosely coupled tiers enabled bydistributed computing and management technologies

Today’s Challenges

New web-based applications introduce unpredictable loads on IT infrastructure, increasing cost and problems

Complex, heterogeneous, n-tiered application environments are difficult and costly to manage

Lacks insight into application resource inventory and utilization, and how the state of application infrastructure affects business performance

Unable to meet user expectations for Application Quality of Service Systems management offerings have failed to deliver on their

promises Business priorities are not reflected in IT infrastructure. Management is not important until after a system is developed and

installed.

Fundamental OS Shift

• Limited instrumentation• No control• Limited visibility

Result:1. Configurators and Monitors2. Ineffective Policy Mgt

• Rich instrumentation• Complete control• Great visibility

Result:1. Measure, analyze, and Affect2. Powerful Policy Mgt

What is Application Management?

Means different things to different people Deployment Management Configuration Management Fault Management Resource Management Performance Management Service Level (QoS)

Management Business Service

Management Operational Control

Different Views Of Application Management Business Management Service Management Fault Management Etc.

The Changing Requirements The user requirements are changing faster than

the solutions technologies. Users want business and Service management The suppliers are still trying to instrument Users want to integrate applications across

platforms Suppliers don’t really have a model for applications

management Architectures are changing

Dynamic, Components, runtime integration Integrating WEB Services

Manage the business, not the technology But we cannot manage the business until we

manage the technology. Modeling the “management” components of the

Business is even more difficult than managing the technology

Applications are becoming largely integration We still cannot instrument the base, thus cannot

manage the integration

BusinessManagement

ServiceManagement

ApplicationManagement

DeviceManagement

En

d-t

o-E

nd

IT

Man

agem

ent

Climbing The Management Mountain

Resources-Devices

Resource - Device Management

Systems Management

Applications

Business

The Users

SLA, QOS Business

Managmenet

The User requirements are growing

The suppliers are significantly behind the user requirements

We cannot build on “empty air”. Management functionality must be a growing infrastructure.

Solution Requirements

Measure, analyze, and affect the entire application environment

Affect and visualize in real-time, dynamic infrastructure changes and understand their effects on the business

Provide integrated dashboard to measure business productivity against objectives

Install, maintain and operate easily Be non-disruptive Standards-compliant Secure Reduce management TCO; deliver fast and measurable ROI Common and interoperable information.

Why Standards?

Common Instrumentation Difficult to instrument for management

Nobody works on management until the end of the project

Manage across components Need common data

Integrate management information from multiple components into common management views The user wants to manage the environment, not

islands Instrument for what we want to manage

Service Level, Business Management, etc. Models must drive instrumentation

Why is modeling Important?

Common Information The right Information

Ex. Service Level management needs information

Putting Semantics on information Create common Semantics, not simply

common syntax Provide interoperability of information Providing a management “abstraction”

Some people simply do not understand the value of data models

We have not convinced the world why they are important yet.

Management info Models In Context

Applications

Applications need management APIs

ManagementApplicationsManagementApplicationsManagementApplicationsManagementApplicationsManagementApplications

ManagementModels

And Information

Manageability InterfaceCommon protocols and

Information

Common understanding of protocols, syntax,

and semantics

ApplicationsApplications

Applications

Manageability/Management Interface

Why is Application Management Important?

Managing systems is not managing the applications that run on them

Getting information from applications and controlling them is the key to the next step, managing services and managing the IT business.

Applications are becoming inherently “multi-system” Users buy IT to do work, not to look at their OS. OS performance, quality, etc. is often not a direct

indication of application performance, quality, etc.

Some inhibitors There are so many of them They are different, every one of them Everybody has a different view of what it means to manage

applications Applications are becoming highly dynamic with very late binding. Management is an afterthought There is very little “long-lasting” instrumentation support for

applications. Many key applications are legacy – We will never touch them

again but they will run for years.

Some Laws of Nature•You can’t push on a rope•Water flows downhill•Management only becomes important when it’s too late

Separating the Problem

Management vs. Manageability We want to define manageability so that

applications can be managed in a common open manner

Good manageability will drive good management

Components of managing Applications Lifecycle – Deployment management RunTime Management

The Standards Players Today

The Open Group APIs

ARM API AIC API XSLM – License Mgt API

QOS DMTF

Modeling Application deployment App Server Runtime Database model (based on SNMP

MIB) Application runtime management Unif of Work Metrics Policy

SNIA SAN based open management

IETF SNMP

App based MIBs XMLConf Polichy Mgt

Global Grid Forum Generalized view of

resources and their management

Oasis Web services management

W3C Web services management

architecture Java JCP Process

JMX Interface JMX – CIM model mapping Etc.

TMF QOS Modeling

And yet today we really cannot effectively manage applications, much less services or business in

an open interoperable manner.

Management Lifecycle

initiallife cycle

deployable installable executable runningappstatus

multiplicity

sub-model

1:n 1:n 1:n

transport

setup

installation

runtime(structure)

A Runtime Model

initiallife cycle

executable runningappstatus

sub-model

installation

runtime model

function

systems

structure

dataexternal systems

workflow = default+rollback+exception

best practices (tasks):routine (daily/weekly/...)

configurationanalysis

workflows

config

ura

tion

indica

tion

sh

istory

methods

Application Architecture: Views and Elements

SystemSystem

ProcessingElements

ProcessingElements

CodeComponent

CodeComponent

ResourceResource

ActionAction DataData

External SystemExternal System

OS/HostOS/Host

Logical

Structure

OS

DataFlow

Scenario

LifecycleTime: shipping -> running

SoftwareService

SoftwareService

Application View Application ElementApplication Element

Models and Instrumentation

Measuring Unit of Work Performance ARM Unit of Work Metrics

Interfacing General Instrumentation models to CIM AIC – Application Instrumentation and Control JMX Characteristics of the models

Dynamic management objects Application defined management objects (defined by the

business) Requirements

Strong on semantics Dynamic creation of “definitions” Metrics and operations.

Key Interoperability Interfaces

CIM Object Manager

CIM Object Manager

CIM ProvidersCIM Providers

ApplicationApplication

Manageability to Manager•Multiple management systems•Common open manageability

Object Manager / Providers• Multiple Providers•Encourage common providers

Management System

Management System

EnterpriseManagement

Console

EnterpriseManagement

Console

ApplicationApplicationApplicationApplication

ApplicationApplication

Provider / Resource Interface•Protect Applications•Make application management easy

Some of the Issues

No clear understanding of the importance of models to management

Instrumentation and models are not connected ARM and Unit of work metrics are different

App management is two different worlds Technical management Management of the services delivered

Application management has to be built on lower layers

There are REAL Opportunities here

APIs Service Level / QOS TOG is unique in having a real user input

Requirements Generation Integrating other Standards Defining application management End-End

with specific goals Ex. Perforamance, availabiliy, etc.

NOTE:

However we will only draw interest if we: Do something Do something that is of interest to some of the

supplier community Do something so that there are results in a

short measureable time Work with the other standards groups in this

area, not by ourselves.