Moving Toward the Future: Dynamic Systems
Initiative
Knowledge is a key component for systems
management. This includes knowledge of the deployed systems,
knowledge of the environment in which they operate, knowledge of a
designer's intent for those systems, and knowledge of IT policies.
Specifically, knowledge may include the following:
-
Developer constraints on settings of a
component, including constraints on related systems that the
component is hosted on or communicates with
-
IT policy that further constrains settings or
deployments
-
Installation directives that describe how a
system is to be installed
-
Health models that describe system states and
the events or behavioral symptoms that indicate state
transitions
-
Monitoring rules, ranging from polling
frequency to event filtering and forwarding to diagnostic or
corrective action in response to problems
-
Schemas for instrumentation, settings,
events, and actions
-
Service-level agreements that define
performance and availability
-
Transaction flows and costs of processing
steps for performance analysis
-
Reports
As IT organizations have become more geographically
dispersed and individual roles more specialized, IT professionals
tend to operate in silos focused on their area of specialization.
This makes it increasingly difficult to communicate relevant system
knowledge across the IT lifecycle. As a result, organizations find
it very difficult to collaborate across roles, promote continuous
improvement of a system's design and operation, and conduct typical
management tasks such as deployment, updating, and patching.
The silos that form across IT organizations
interact with an application or system at some point during its
lifecycle. However, each silo possesses its own pocket of
system-relevant knowledge that does not get communicated
effectively to the rest of the organization.
Software models can be used to capture
system-relevant knowledge and facilitate the communication and
collaboration around this knowledge that is required to improve the
efficiency of the entire IT development, deployment, and support
lifecycle. A software model provides a level of abstraction for
administrators similar to what a blueprint provides to an architect
or a prototype provides to a product designer. But for a dynamic
and distributed software environment, a static model or blueprint
is insufficient. The model must be a living organism and should
evolve throughout the life of a system. Having the right tools for
systems management can help to keep these models current and enable
users to have dynamic views of the system model based on an
underlying operational system.
When a system is developed, basic rules and
configurations are defined. As the system is deployed, the details
of its configuration, environmental constraints, and requirements
are added. As operational best practices are developed or enhanced,
they can be incorporated into the model as well, providing a
feedback loop between the operations staff and the model. In the
end, the model becomes a live, dynamic blueprint that captures
knowledge about a complete distributed system in terms of its
structure, behavior, and characteristics. The following benefits
can be gained as a result of these models:
-
The system model captures the entire system's
composition in terms of all interrelated software and hardware
components.
-
The system model captures knowledge as
prescriptive configurations and best practices, allowing the
effects of changes to the system to be tested before the changes
are implemented.
-
Tools that take advantage of the system model
can capture and track the configuration state so that
administrators do not need to maintain it in their heads. The
software maintains the desired state so that humans do not need
to.
-
Administrators do not need to operate
directly on real-world systems but rather can model changes before
committing to them. In this way, "what if" scenarios can be tried
without impact to a business.
-
The system model becomes the point of
coordination and consistency across administrators who have
separate but interdependent responsibilities.
The modeling system becomes the integrated platform
for design and development tools that enable the authoring of
system models. It also becomes the platform for operational
management and policy-driven tools used for capacity planning,
deployment, configuration update, inventory control, and so on.
In Microsoft's initial implementation of the
Dynamic Systems Initiative, the System Definition Model (SDM) is a
foundational component of dynamic systems. SDM is a model that is
used to create definitions of distributed systems. In this context,
a distributed system is a set of related software and hardware
resources working together to accomplish a common function.
Multi-tier applications, Web Services, Internet web sites
supporting e-commerce, and enterprise data centers are examples of
systems. Using SDM, businesses can create a live blueprint of their
systems. This blueprint can be created and manipulated with various
software tools and is used to define system elements and capture
data pertinent to development, deployment, and operations so that
the data becomes relevant across the entire IT lifecycle.
Today, an SDM can be defined using tools available
with Visual Studio 2005. Going forward, SDM will be the basis for
design of system models, used to deploy systems based on the model
defined and will be kept up-to-date by an SDM service that
dynamically modifies the SDM to reflect the current state of
operations. While the SDM will be incorporated into the Microsoft
management solutions, third parties will also be able to develop
solutions based on the SDM to extend the capabilities of these
models and the tools that consume or produce them.
Several key capabilities of IT organizations and IT
systems become possible when software models are used to capture
all relevant system knowledge. Through the DSI efforts and SDM,
Microsoft aims to enable innovation in its products and from its
partners in four areas: Design for Operations, System-Level
Management, Policy-Driven Operations, and Hardware Abstraction.
Design for Operations
When creating mission-critical software,
software architects often find themselves communicating with their
counterparts who specify data center and infrastructure
architecture. In the process of delivering a solution, an
application's logical design is often found to be at odds with the
actual capabilities of the deployment environment. Typically, this
communication breakdown results in lost productivity as developers
and operations managers reconcile an application's capabilities
with a data center's realities.
With new model-based development tools, such
as Visual Studio Team System, these differences are mitigated by
offering a logical infrastructure designer that will enable
operations managers to specify their deployment environment and
architects to verify that their application will work within the
specified deployment constraints. These tools use software models
to capture the knowledge of a designer's intent, knowledge of an
operational environment, and knowledge of IT governing policies to
ensure IT systems are designed with operations and manageability in
mind from the start. The models described can be built using Visual
Studio 2005 and then consumed by Microsoft management tools and any
other third-party tools that are built to consume the models, which
are based on an open specification.
System-Level Management
Models
can capture the entire structure of an application, including all
the underlying and interrelated software and hardware resources.
Management tools, such as future versions of MOM, will use those
models to provide a system-level view of the health and performance
of that application, enabling administrators to understand the
impact of changes or errors in the system and to manage the
application more effectively.
This system-wide view will enable future
versions of management tools, such as MOM, to perform robust health
monitoring and problem solving, as well as end-to-end performance
and service-level management.
Policy-Driven Operations
Models can also capture policies tied to IT
and corporate governance, such as Sarbanes-Oxley compliance or
basic security standards and operating system versioning.
Management tools, such as future versions of Microsoft SMS, will
use these models for desired-state management.
By comparing the model of the real-world state
with the model of the compliance definition, management tools can
make systems compliant before allowing them access to corporate
resources.
Hardware Abstraction
Software models can capture an entire
system's composition in terms of all interrelated software and
hardware components. As a result, a system will contain a specific
description of the hardware requirements of the environment into
which it will be deployed.
This knowledge will enable new resource
management technologies, such as Microsoft Virtual Server, to
interpret these hardware requirements and to be used by management
tools to ease the initial provisioning, ongoing change, or removal
of hardware from an application based on changing business
needs.