I was able to attend a recent ISV workshop titled “Design For Operations” where members of the Microsoft Developer and Platform Evangelism Team provide much focus on a single question: “How much does it cost to know if my application is working?”
Now that is a seemingly simple question with multiple viewpoints. For example, the person asking “is it working” could be:
· the Application Developer, testing a version of an application
· the Solutions Integrator, piloting a distributed application on a high-availability platform
· the IT Operations Manager, concerned about how a new platform performs under stress
· the IT Service Manager, assessing how new software in the end-to-end service meets the Service Level Agreement
Through multiple sessions across two days, this workshop provided guidance as to how ISVs can provide the hooks and features into applications under development which enable dynamic management functionality. I suggest keeping an watch on MSDN.Microsoft.Com for any recordings and content from this workshop.
What I hope to do in this SML_Insight post is to provide you with a view into the workshop guidance for developers.
The Reasons Why: DSI
The session opened with reviews of trends in IT spending. From research conducted in 2005 and elsewhere, IT spending is focused more (70%) on maintenance of existing systems, and less (30%) on new software. Even though IT management recognizes that the greatest gain from investments can be found in salesforce automation, spending priorities are in security and project management. This allowed for introduction of two approaches to making reduced IT spending stretch farther: Microsoft’s Dynamic Systems Initiative, where software is managed by IT Ops through models created by Developers; Design for Operation, where developers encode a market advantage into apps by including management and monitoring functionality with new applications.
Context: This is the point where I remembered more than one Microsoft IT software deployment project from my days in MSIT security operations. During initial meetings between developers, project management, operations staff and service managers, a key question was “what tools are provided to manage and monitor this application, after deployment?”. Responses to this question meant more meetings where scripts were identified for creation, to use as tooling for the app and to monitor service state; also meetings with IT Database Administrators (DBAs) to devise queries against the backend database to assess “how many” measures of transactions, and pseudo transactions allowing assessment of service health. There were some MSIT projects we refused to accept due to a missing instrumentation, lack of tooling, no monitoring capability upon application delivery.
The key guidance from this section of the Design For Operations workshop:
Instrument Your App: Ensure Events and Log entries are well-described with actionable details. This aids the IT Operations staff with their diagnostics process both in piloting (for performance evaluation) and in support project phases.
Provide Configuration Tools: Availability of a detailed Microsoft Installer (MSI) file that can be adapted by IT Ops staff can much expedite pilot testing of applications. Also a means of globally configuring application settings, such as Microsoft Group Policy, can ensure the application is configured (and kept) in a state of compliance per requirements for business processes, security rules, and regulatory statues.
Provide Administration Tools: Most IT Operations staff members are excellent scripters, but not tenured developers. By building tools that IT Ops needs to deploy and monitor your application, and your app will get deployed and used and monitored. Microsoft's new Windows PowerShell interface provides a resource where developers can use simple controls (cmdlets) on the OS / services / system / software, and Providers to extend management to other data sources (such as using the WMI Provider to examine the Registry or OS Version).
Facilitate Monitoring: The Microsoft Operations Manager (MOM, known in its next release as Systems Center Operations Manager) Management Packs provide ways for server, client and service management teams to determine the current states of their owned resources, and dependent systems, as well as to be altered to possible or actual problems with these resources. Software Developers providing the management packs help to establish the baseline measures needed during pilot testing and initial deployments; the rules in management packs can be later tuned to take advantange IT Operations knowledge and environment observations.
Create Models: Use existing and emerging tools to create management models for your applications, which IT Operations will use across all application lifecycle phases:
· Configuration (Management) Model: The prescriptive means of managing configuration at installation and update. A great DSI example of this, based on underlying Service Modeling Language (SML) models for server “roles” in Windows Server Longhorn is the Service Manager console – for each server role (such as DNS Server), XML model documents were created by the role (app) development team, and which allow for consistent configuration (and later, comparison) to a known good state.
· Health Model: An exhaustive “what it means when this happens” assessment roadmap. By noting what each Event of the instrumented app means, and what it means when specific thresholds of performance or state are reached, IT Ops can assess when a system / application / service is in a state of “known good health” and the level of service can be assessed against acceptable levels of delivery. Context: I recall a time in Microsoft IT when a bulk migration of directory service objects was completed near the end of an infrastructure retirement project; an application that tracked all objects became severely stressed after this migration, but did not crash. So - what was the health of the app in this situation?On a daily basis during the week it took for this app to resolve all migrated objects and abate the increased stress which resulted in measurable performance delays, we had to answer two questions: “What is the current health of the system?” and “When will the system return to a preferred state of health?”. The bad thing was that the app was not instrumented for performance assessment; the good thing was that the app developer was still available, and able (after investigation) to provide an ETA for ruturn to an preferred performance level. In hindsight, it would have been valuable to have required performance instrumentation as a component of the application during development.
· Assessment (Monitoring) Model: As noted above in sections above, provide ways for server, client and service management teams to determine the current states of their owned resources and dependent systems, as well as to be alerted to problems with these resources. This not only reduces overall Total Cost of Ownership by minimizing outage periods with early detection, but also reduces TCO by allowing trending service delivery to determine other factors (interaction of other applications, workload peaks, and resource limitations) that may impact the performance, availability, or reliability of an application.
For More Information:
· Health Modeling White Paper:http://www.microsoft.com/windowsserversystem/dsi/designwp.mspx
· Management Modeling Designer Download:http://www.microsoft.com/downloads/details.aspx?FamilyID=5C42C049-CAE3-464E-BE89-61F070F7C8E8
· And Especially: View David Aiken’s DFO-SHOW on Windows PowerShell at Channel9:http://blogs.msdn.com/daiken/archive/2006/06/07/620484.aspx