This document is part of a collection of documents that comprise the
Reference Architecture for Private Cloud
document set. The Reference Architecture for Private Cloud documentation is a community collaboration project. Please feel free to edit this document to improve its quality. If you would like to be recognized for your work on improving this article,
please include your name and any contact information you wish to share at the bottom of this page.
This article is no longer being updated by the Microsoft team that originally published it. It remains online for the community to update, if desired. Current documents from Microsoft that help you plan for cloud solutions with
Microsoft products are found at the TechNet Library
Solutions or Cloud and Datacenter
Manageable applications make day-to-day operations a more predictable, efficient process. However, the benefits of manageable applications are not restricted to the operations team. With many current applications, when a problem occurs with an existing application,
the operator attempts to diagnose the problem and may solve the problem by either modifying the configuration of the application or modifying the system at a lower level (for example, by making changes to the operating system, the hardware, or the network).
If the operator is unable to diagnose or fix an application problem, the operator may have to report it to the development team so a fix can be produced. One of the main reasons this happens is because of insufficient or irrelevant instrumentation. If architects
and developers create manageable applications, they can reduce the number of times they are called upon to fix problems through additional development.
Similarly when fabric management orchestration is developed the author must instrument each management operation as the orchestration steps through the operation to provide sufficient content information into the management operation state and the state of
the resource that is acted upon.
This article demonstrates how to understand applications from different perspectives and describes how knowledge of the operations perspective can lead to applications that are designed to be manageable.
Depending on their relationship to an application, different people in an organization will have a different perspective about an application. The different perspectives include the following:
Each of these perspectives is held by multiple job roles, all of whom should be involved in developing and consuming a manageable application. For example, the developer perspective will typically be held by one or more architect roles, along with the application
Before developing manageable applications, it is important to understand the challenges that operations typically face when managing applications.
Operations consists of a series of interrelated tasks, including the following:
The operations layer is responsible for ensuring day-to-day availability of the application, yet often provided with applications that are difficult to effectively manage. This often results in a number of problems, including the following:
These problems affect the efficiency of the operations team to manage the application and can ultimately affect the experience of the users consuming the application.
To solve these problems, the work of the operations team needs to be considered throughout application design, development, test, and deployment. In many cases, this will be an iterative process. For example, the experience gained from the day-to-day operation
of the system should guide improvements to the application design over time. With manageable applications, it is generally easier to transfer system knowledge between all phases of the IT life cycle.
From an operations perspective, applications always execute on a platform and generally communicate over a network. Applications are dependent on their own underlying system and network layers, but they may also communicate with, and be dependent on, other
applications and services.
Operators collect information that corresponds to each of these layers, using the information to ensure that applications continue to run smoothly. Understanding each layer as a separate entity, and understanding the relationships between the layers, often
allows the operations team to quickly isolate the source of any problem.
For example, if a computer running a SQL database that provides data to an application becomes unavailable, the functionality of the application could be affected. In this situation, the operator needs to know several things:
Typically, developers are not concerned with the details of the lower layers. However, an architect that is designing for operations should at least have a greater awareness of these details, because issues at a lower level can lead to problems with the
health of the application itself.
If you are going to design manageable business applications, you must consider manageability as an integral part of the initial design of the application; it should not be just an afterthought. Manageability should also be refined and improved through feedback
from the operations team after you get better insight about how applications behave after deployment. The process of designing manageable applications is the result of collaboration between multiple parties who must agree to a number of core principles, including
This list of core principles is not comprehensive. In many cases, additional core principles will be established to cover areas such as task management and configuration management.
A number of the problems with product shipping faced by Northern Electronics stem from the existing product shipping application. The operations team for this application face the following challenges:
The solutions architect is committed to making the new product shipping solution a manageable application. However, he faces several challenges in achieving this goal:
The solutions architect plans to use a management model for the application to help him overcome these challenges.
This section examined the different perspectives that interact with an application and focused more closely on the operations perspective, which must be well understood to design manageable applications. It introduced some core characteristics that should
be followed when designing manageable applications.
Providing Infrastructure as a Service depends on fabric management tools and orchestration that have been designed to be highly manageable. Architects developing applications that integrate with private cloud fabric management must exhibit these highly manageable
characteristics to maintain predictability in offering Infrastructure as a Service capability.
These characteristics extend up through the Reference Model into the Platform and Software as a Service Layers.
The high-level process for manageable applications defines four interconnected stages that capture the application through design, development, deployment, and operations, as shown in Figure 1.
Figure 1: High-level process for manageable applications
This section describes each stage and demonstrates how the stages are used together in manageable applications. As illustrated in Figure 1, the stages are the following:
The order of these stages is important - adding the appropriate instrumentation to an application on an as-needed basis at the end of the development process—or, even worse, after completing testing and deployment—is unlikely to produce a manageable application.
However, in many cases, feedback during the cycle leads to further development of the management model.
The following four roles are primarily involved in the high-level process:
Figure 2: High-level Process Showing Job Roles
Many additional job roles participate at some point in the life cycle of a manageable application. The following table lists these roles and the perspectives that they would hold on the application. For more information about application perspectives, see
"Understanding Manageable Applications."
To understand how manageable applications are designed, implemented, deployed, and managed, it is important to look at the process in more detail.
The management model forms the starting point for a manageable application. One of the great challenges of creating manageable applications is determining, at design time, the needs for the application in daily operations. By investing time in creating an
effective management model early, you can dramatically increase the likelihood that your application is manageable later.
Creating a management model for the application does not prevent you from using an iterative approach when designing your application—the model should be flexible enough to be altered as changes occur in later iterations.
Typically, the infrastructure architect and the solutions architect are the main roles involved in creating a management model. The infrastructure architect provides input about the environment in which the application will be deployed, which may include
factors such as network connectivity, network zones, and allowed protocols. This information is critical to the overall design, because it can affect the way instrumentation will be implemented in the application. For example, if the application is to be deployed
in a low-trust environment, it is typically not possible to write events to an event log. In some cases (for example, for a shrinkwrapped application), it may not be possible to determine in advance what the deployment environment will be, so multiple trust
levels may have to be supported.
Generally, the solutions architect is responsible for the specifics of the management model. The management model defines how the application is broken into manageable operational units (known as managed entities). It also contains abstract information about
the application, which defines how the application is developed, deployed, and, ultimately, how it is managed. This information includes an instrumentation model, which indicates all the instrumentation points for the application, and a health model, which
indicates the various health states for the application.
After an effective management model is created for the application, the application itself needs to be developed, and the information contained in the model must be incorporated. The developer is responsible for taking the abstract elements in the model
and generating concrete artifacts in the code. In particular, the developer typically incorporates specific instrumentation, such as the following:
The developer may also need to incorporate specific health indicators, which are used to determine the health of an application, and configurability support, which are used to modify what instrumentation is used at run time.
After the application is developed, it must be deployed (for simplicity, testing is intentionally omitted from this process). For an application to be truly manageable, you should have a high degree of control over the deployment of that application. This
allows you to more easily manage the process of changes to the application. Also, during deployment, specific configuration settings for the application may be chosen.
After the application is deployed to its target environment, it must be operated. The operator is responsible for managing the application, using an administrative console, and supporting tools such as Event Viewer and Performance Logs and Alerts. The operator
may also use more advanced fabric management tooling available on the private cloud platform, with the application.
In many cases, information contained in the management model can be consumed at run time by operations. This may be as simple as the operator using a report generated from the original model to understand the workings of the application, or it may be exported
from the original management model and imported into the Private Cloud Management and Operations Layers.
This chapter examined a high-level process for designing, developing, deploying, and operating manageable applications. It examined the roles that participate in that process and the responsibilities that each role holds. It also examined the artifacts that
are available to facilitate the process of designing manageable applications.
The previous sections discussed manageable applications and monitoring of those applications. A process for development of manageable application characteristics is discussed.
In this section we expand on the scope to include platform monitoring and the activities involved in creating a highly manageable private cloud management orchestration that provides complete and meaningful instrumentation that can be consumed by the Private
Cloud Management and Operations Layers and by operators.
Platform monitoring is the monitoring of platform instrumentation created by private cloud resources during the normal deployment and management of these resources. Platform monitoring also includes the monitoring of fabric management orchestration that
is performing management operations upon the resource or its configuration properties.
Consider an example where a job has been created to stand up a service consisting of an n-tier application that includes a data layer, business logic application layer and a presentation later. Assume the presentation layer consists of five appropriately sized
and configured compute resources. These five compute resources will likely be provisioned by fabric management in parallel. It is also likely this presentation tier would be provisioned after the data and business logic tiers since these are a dependency that
has been defined in the management model.
When provisioning of the presentation tier occurs the private cloud fabric management component will initiate the provisioning of these five compute instances within a private cloud shared resource pool. These five instances will be allocated, imaged and initialized
concurrently and as this happens platform instrumentation will be emitted by fabric management that shows:
When a compute resource instance initializes it begins exposing platform instrumentation that is specific to the context or scope of the instance. At this point there is both fabric management and resource instance instrumentation contained in the management
Associating this platform and resource instrumentation with the provisioning job is referred to as correlation. The ability to correlate instrumentation to a fabric management job is provided by the private cloud Infrastructure as a Service platform.
The architect is responsible for designing appropriate instrumentation into custom developed orchestration and integrated into fabric management to maintain a highly manageable private cloud.