Hi all,
I totally forgot the details of this. I wrote it in an early
stage of the project so some of the terminology should be changed, no doubt,
but I was playing with these ideas at the time.
So, as discussed and as a seed for further exploration, please
find relevant section of WP that addresses cloud computing below. The first scenario
is the least interesting (I’ve labeled the three scenarios for ease of
discussion). It involves the use of SAF by the consumer using a set of
published Symptoms provided by the Cloud Provider to report problems, ask for a
different agreement, etc. This is more of a traditional operational management
approach to cloud using SAF, which could probably fill the bill quite well,
although other ways of doing this are also possible.
The second scenario is more interesting in that the consumer
emits Symptoms to the provider who maintains the catalog. Appropriate Syndromes
are developed by the provider to address operational and security issues based
on Symptoms that are (in a sense) meaningful to the consumer only at a business
process level.
The third scenario is the most evolved because the consumer actually
provides a catalog of meaningful syndromes for the providers use and the
provider has a different catalog for his use. By owning up their diagnosticians
via sharing the catalogs to each other’s symptoms the two domains can
work cooperatively to solve problems in an automated fashion. For example, the
cloud provider can respond to customer symptoms by following protocols on its
end that might even result in the providing emitting symptoms back to the
consumer to do things or be aware of on their end (like “you are in
danger of using so much cloud resources that your rates are about to double so
don’t say we didn’t warn you.”). The power of this is
automated relationships between domains based on knowledge in two different (or
many) catalogs.
1.1 Example
2: Cloud Computing and SaaS
The newest paradigms in IT, such as Cloud Computing and more
specifically Software-as-a-Service (SaaS) or Platform-as-a-Service (PaaS), can
also reap significant benefits from proper application of the Symptoms
Framework. In such paradigms, user applications that are developed and deployed
outside of the enterprise domain, perhaps hosted by multiple service providers.
At the other extreme, it is possible for the enterprise to host applications or
services outside of the enterprise on IT infrastructure provided by the Cloud
Computing provider. This is commonly referred to as Infrastructure-as-a-Service
(IaaS). Despite the diverse nature of these types of paradigms, the Symptoms
Framework can enable both remediation of problems and optimization of
applications across multiple domains.
One of the major concerns for enterprises moving to a cloud
computing or SaaS environment is their ability to control the critical
parameters required to deliver quality service levels to their end users.
As such, new forms of collaboration around availability, performance and
security must be developed. The scenarios below highlight examples where
business logic, extensibility and data and/or programmatic sharing of
information address these requirements.
FIRST SCENARIO
First, the service provider enables customers to create
Symptoms by providing a Syndrome Catalogue of known (externally detectable)
behaviors. Customers can then report problems and optimize service behavior to
meet their business needs by forwarding these externally detected Symptoms to
the service provider.
For example, assume that a service level agreement is
present which governs the response time and bandwidth provided to the customer
by the service provider. If the customer experiences service-level violations
from the external provider, their applications or another Symptom Source acting
on behalf of the users or enterprise applications can emit a Symptom indicating
a business impact and send it to a service supplied by the service provider
that exposes its Diagnostician.
The combined analysis of these symptoms might be considered
either a request to remediate the service-level problem (within the
service-platform domain) or even for the service provider to upgrade the
customer’s SLA to meet new requirements. In essence, this scenario
documents the capability for a service provider to enable its customers to
request a new business requirement so that it might appropriately and optimally
respond to its customer’s business needs.
SECOND SCENARIO
The second scenario would be for the customer application to
emit Symptoms based on its own higher-level application and business concerns.
Such a Symptom may be unknown to the service provider, but when the customer
emits such a Symptom, the service provider’s diagnostician can evaluate
its Symptom space (Symptoms present in its environment) in the context of this
new Symptom provided by the customer application.
Advanced diagnosticians could recognize new patterns based
on the Symptoms from the customer and their own Symptoms, perhaps even
generating new Syndrome Catalogue entries. For example, the ability to
diagnose security attacks may require involvement from the customer’s
application logic to create symptoms for viruses or other anomalies only
visible to that customer. In addition, the customer may provide a
diagnostic routine that can interface to a peer diagnostic from the service
provider to share intermediate analysis
The service provider may not understand the full meaning of
that customer’s Symptom and may not need to. The diagnostician must
merely recognize and respond to the receipt of such a Symptom from the
application while any Symptoms from its own domain are present in the context
of that application. Such a diagnostician could recognize these patterns, be
taught by operators what to do (thus enriching its own Syndromes for the
application with additional Protocols and Prescriptions), or just by
recognizing repeating patterns applied to policy generate a meaningful default
response.
THIRD SCENARIO
Of course, it would be most helpful for the customer to
provide access to their own Syndrome Catalogue so that the service provider
might have a better understanding of the impact and importance of the Symptoms
that it receives from its customers. Thus, the third scenario would be for the
customer application to enable a service that provides access to its own
Syndrome Catalogue focused on its own higher-level application and business
concerns. When a Symptom is emitted by the customer, if the Symptom is unknown
then the service provider’s diagnostician queries the customer’s
service and evaluates the Symptom space (the customer’s and its own
active Symptoms) in the context of the customer’s Syndromes that might
explain the key issues such as the business impact of that Syndrome, allowing
the service provider to be more sensitive to the business/operational concerns
of their customer. For example, the customer application may provide
specific recovery routines (Prescriptions) in their catalogue which deals with
specific recovery sequence dependencies that the service provider can utilize.
In all of the above cases, the Symptoms Framework enables a
level of business agility, responsiveness, and optimization across multiple
enterprises that would not be possible without the standardization of knowledge
concerning operational and business conditions provided by the Symptoms
Framework and the ability of different entities to share Syndrome Catalogues as
well as Symptoms.
Regards,
Paul
Paul Lipton
VP, Industry Standards and Open Source
Member, CA Council for Technical Excellence
Phone (preferred number!): +1 215
539-2731
Mobile: +1 267 987-6887
Email: paul.lipton@ca.com
THIS MESSAGE MAY CONTAIN CONFIDENTIAL, PRIVILEGED OR OTHER LEGALLY
PROTECTED INFORMATION. IT IS INTENDED FOR THE ADDRESSEE ONLY. IF YOU ARE NOT
THE ADDRESSEE (OR SOMEONE THE ADDRESSEE AUTHORIZED TO RECEIVE THIS MESSAGE),
YOU ARE PROHIBITED FROM COPYING, DISTRIBUTING OR OTHERWISE USING IT. PLEASE
NOTIFY THE SENDER AND RETURN IT AT OUR COST. THANK YOU.