Beruflich Dokumente
Kultur Dokumente
Accountability
Agility
Assurance
Financial
Performance
Security and Privacy
Usability
Interaction Patterns : An analysis of various cloud management use cases revealed that each
use case could be decomposed into a combination of interaction patterns. An interaction
pattern consists of a sequence of messages. For any interaction pattern, the specific messages
may vary from use case to use case, but the messages have similar characteristics at an
architectural level, particularly the protocol and security considerations.
Identify: A person or entity that interacts with the cloud service provider establishes their
identity and receives appropriate credentials, such as a session token. An identity token may
also be obtained through an external identity provider that has a trust relationship with the
cloud service provider. Operations and data are made accessible to the connection
authenticated by the credentials or identity token.
•Administer: These patterns work with the data that describe offerings, users, and other
administrative metadata information needed for interactions with the cloud service provider.
For example, an administrator or operator may browse a list of available offerings to select
one, to update its metadata to configure it for a particular purpose, and to retrieve details about
how to access instances of a service that is part of the offering.
•Deploy and Update: These patterns (there are actually two types of Negotiate/Provision Resources) are used
when selecting services and resources, and then making them into services. Included are any needed negotiations
about the amount and type of resource, operations to provision services including the infrastructure that supports
them, and tracking the status of what may be long-running operations.
•Steady State: These patterns are used after services and resources have been provisioned and are in use. They
include client-initiated requests such as a report request and notifications from a provider about situations that are
of interest to a consumer and that may require remediation actions.
Understanding
Cloud Security
Securing the Cloud
● According to the report “assessing the security risks of cloud computing”
the areas of cloud computing that were uniquely troublesome :
● • Auditing
● • Data integrity
● • e-Discovery for legal compliance
● • Privacy
● • Recovery
● • Regulatory compliance
In order to evaluate your risks, you need to
perform the following analysis:
• 1. Determine which resources (data, services, or applications) you are planning to move to
the cloud.
• 2. Determine the sensitivity of the resource to risk. Risks that need to be evaluated are loss
of privacy, unauthorized access by others, loss of data, and interruptions in availability.
• 3. Determine the risk associated with the particular cloud type for a resource. Cloud types
include public, private (both external and internal), hybrid, and shared community types. With
each type, you need to consider where data and functionality will be maintained.
• 4. Take into account the particular cloud service model that you will be using. Different
models such as IaaS, SaaS, and PaaS require their customers to be responsible for security at
different levels of the service stack.
• 5. If you have selected a particular cloud service provider, you need to evaluate its system to
understand how data is transferred, where it is stored, and how to move data both in and out
of the cloud.
The security boundary
● Security service boundary
Securing Data
● These are the key mechanisms for protecting data mechanisms:
• Access control
• Auditing
• Authentication
• Authorization
Brokered cloud storage access
● Under this system, when a client makes a request for data, here's what
happens:
● 1. The request goes to the external service interface (or endpoint) of the
proxy, which has only a partial trust.
● 2. The proxy, using its internal interface, forwards the request to the broker.
● 3. The broker requests the data from the cloud storage system.
● 4. The storage system returns the results to the broker.
● 5. The broker returns the results to the proxy.
● 6. The proxy completes the response by sending the data requested to the
client.
Establishing Identity and Presence
34
Recap – Service-Oriented Architecture SOA
40
■ UDDI is an XML-based standard for describing,
publishing, and finding web services. UDDI stands
for Universal Description, Discovery, and Integration.
■ Web Services Description Language; WSDL is
used to describe web services;WSDL is written in
XML.
■ Simple Object Access Protocol. It is an XML-based
messaging protocol for exchanging information
among computers. SOAP is an application of the
XML specification.
Business Process Modeling (BPM)
■ BPM addresses process flow and service invocations to form useful
works.
■ Two integration methods
■ Orchestration
■ Choreography
■ WS- BPEL (orchestration-like)
■ A language standard for WS interactions
■ View business process as a collection of activity graphs
■ Provides command for defining logic using conditional statements,
loops, variable etc.
■ Web Services Business Process Execution Language (WS-BPEL) is a
standard or language for automating business processes. It
is basically one of the programming language that aims to make to
describe any process possible
42
43
44
Recap (3) - SOA and Cloud
45
Service Models and their risks
47
Managing and Monitoring SOA
Software for monitoring and managing an SOA infrastructure
plays an important role in large SOA deployments. While SOA
offers a logical design and reusable components, it does not
make the task of network management any easier.
48
SOA management tools
■ HP Software and Solutions OpenView
SOA Manager
49
SOA security
■ Security Assertion Markup Language (SAML) is an XML standard that
provides for data authentication and authorization between client and service.
The SAML technology is used as part of Single Sign-on Systems (SSO) and allows
a user logging into a system from a Web browser to have access to distributed SOA
resources.
50
■ WS-Security Policy provides a set of network policies that extend WS-
Security, WS-Trust, and WS-SecureConversion so messages
complying to a policy must be signed and encrypted. The
SecurityPolicy is part of a general WS-Policy framework.
51
The Open Cloud Consortium
OCC working groups perform these functions:
■They develop benchmarks for measuring cloud computing performance. Their benchmark and data
generator for measuring large data clouds is called MalStone
■They provide testbeds that vendors can use to test their applications, including the Open Cloud
Testbed and the Intercloud Testbed that are part of the work of the Open Cloud Testbed and Intercloud
working groups.
■They support the development of open-source reference implementations for cloud computing. The
Working Group on Standards and Interoperability For Large Data Clouds extends the architecture for
data storage with a distributed file system, table services, and computing using MapReduce following the
model that is part of Google's offering.
■MapReduce is Google's patented software framework that supports distributed large data sets
organized by the Google File System (GFS) accessed by clusters of computers. The Apache Hadoop
(http://hadoop.apache.org/) open-source system is based on MapReduce and GFS.
■They support the management of cloud computing infrastructure for scientific research as part of
the Open Science Data Cloud (OSDCP) Working Group's initiative 52
Relating SOA and Cloud Computing
■ Cloud computing is still in its infancy, and although Web services can implement a
Service Oriented Architecture, it is not a requirement. Most of the large
implementations of cloud computing described in this book are single-purpose
applications that have been optimized on a grand scale: Carbonite's backup,
Google's Gmail e-mail, and Twitter's Instant Messaging (IM) are several examples
■ SOA is loosely coupled because the service is separated from the messaging. If a
component doesn't provide the capabilities required, it is an easy task to switch to a
different component, and switching requires almost no programming
■ SOA components are often best-of-breed service providers that can provide a
measured service level and can play a role in Business Process Management
(BPM) systems. The separation of services from their design allows for much
easier system upgrades and maintenance.
53
A service-level agreement (SLA) is a commitment
between a service provider and a client. Particular
aspects of the service – quality, availability,
responsibilities – are agreed between the service
provider and the service user.[1] The most common
component of an SLA is that the services should be
provided to the customer as agreed upon in the
contract.
A Service Level Agreement (SLA) is the bond for performance negotiated between the cloud
services provider and the client. Earlier, in cloud computing all Service Level Agreements were
negotiated between a client and the service consumer. Nowadays, with the initiation of large
utility-like cloud computing providers, most Service Level Agreements are standardized until a
client becomes a large consumer of cloud services. Service level agreements are also defined
• Customer-based SLA
• Service-based SLA
• Multilevel SLA
Service level agreements are also defined at different levels:
• Customer-based SLA: An agreement with an individual customer group, covering all the services they use. For
example, an SLA between a supplier (IT service provider) and the finance department of a large organization for
the services such as finance system, payroll system, billing system, procurement/purchase system, etc.
• Service-based SLA: An agreement for all customers using the services being delivered by the service
provider. For example:
◦ A mobile service provider offers a routine service to all the customers and offers certain maintenance as a
◦ An email system for the entire organization. There are chances of difficulties arising in this type of SLA as
level of the services being offered may vary for different customers (for example, head office staff may use
high-speed LAN connections while local offices may have to use a lower speed leased line).
• Multilevel SLA: The SLA is split into the different levels, each addressing different set of customers for the same
issues appropriate to every customer throughout the organization. These issues are likely to be less
◦ Customer-level SLA: covering all SLM issues relevant to the particular customer group, regardless of the
◦ Service-level SLA: covering all SLM issue relevant to the specific services, in relation to this specific
customer group.
A well defined and typical SLA will contain the following components:[5]
• Type of service to be provided: It specifies the type of service and any additional details of type of service to be
provided. In case of an IP network connectivity, type of service will describe functions such as operation and
• The service's desired performance level, especially its reliability and responsiveness: A reliable service will
be the one which suffers minimum disruptions in a specific amount of time and is available at almost all times. A
service with good responsiveness will perform the desired action promptly after the customer requests for it.
• Monitoring process and service level reporting: This component describes how the performance levels are
supervised and monitored. This process involves gathering of different type of statistics, how frequently this
statistics will be collected and how this statistics will be accessed by the customers.
• The steps for reporting issues with the service: This component will specify the contact details to report the
problem to and the order in which details about the issue have to be reported. The contract will also include a
time range in which the problem will be looked upon and also till when the issue will be resolved.
• Response and issue resolution time-frame: Response time-frame is the time period by which the service
provider will start the investigation of the issue. Issue resolution time-frame is the time period by which the
• Repercussions for service provider not meeting its commitment: If the provider is not able to meet the
requirements as stated in SLA then service provider will have to face consequences for the same. These
consequences may include customer's right to terminate the contract or ask for a refund for losses incurred by
mentioned below:
5. Warranties
What is cloud economics?
In the simplest term,economics of cloud computing deal with the knowledge concerning the
principles, costs, and benefits of cloud computing. For any organization to derive the greatest
value for the business, it must specifically determine how cloud services can affect IT budget,
security and IT infrastructure. There is no hard and fast formula to determine that, it all depends on
the assessing the costs pertaining to infrastructure, management, staffing need, research and
development (R&D), security and support All these factors are analyzed to determine if moving to
the cloud makes logical next step forward as per organization’s specific circumstances and needs.
How to calculate the cost of moving to the cloud?
To put the cost of a cloud solution into perspective, you need to calculate the total cost of
ownership (TCO) for the on-premises first. You can calculate that by figuring out the cost of the
equipment you need, cost of the capital and the project lifespan of the equipment. You can also
To precisely calculate the cost of your current data center, make sure to include all aspects. For
example, IT infrastructure consisting of hardware and software that can include physical
servers, software licenses, maintenance contracts, warranties, supplies, material, spare parts,
and anything else that you directly pay for. You need the cost of all these to correctly estimate
how much your current IT infrastructure cost. Then there are operational costs as well that
include labor, facilities used to house IT hardware, internet connectivity. These operational costs
Once the cost of your current data center is determined, you now need to calculate the estimated
cost of cloud infrastructure. While cloud pricing can vary depending on the number of factors and
can be quite complicated, it depends on your cloud provider to provide the simplified pricing
structure that is easier to understand. Alternatively, you can contact your cloud provider of choice
for a quote
.
Cost of cloud migration execution
The next step is accounting for the costs involved in executing the migration of the IT
operations to the cloud. It is determined by the scope of your current IT infrastructure and
how much of it you plan on moving to the cloud will be. Moreover, there is a cost involved of
An on-demand service provider typically charges a utility premium — a higher cost per unit time for a resource
than if it were owned, financed or leased. However, although utilities cost more when they are used, they cost
nothing when they are not. Consequently, customers save money by replacing fixed infrastructure with clouds
when workloads are spiky, specifically when the peak-to-average ratio is greater than the utility premium.
Cloudonomics Law #2: On-demand trumps forecasting.
The ability to rapidly provision capacity means that any unexpected demand can be serviced, and the revenue associated
with it captured. The ability to rapidly de-provision capacity means that companies don’t need to pay good money for
non-productive assets. Forecasting is often wrong, especially for black swans, so the ability to react instantaneously
Enterprises deploy capacity to handle their peak demands – a tax firm worries about April 15th, a retailer about Black
Friday, an online sports broadcaster about Super Sunday. Under this strategy, the total capacity deployed is the sum of
these individual peaks. However, since clouds can reallocate resources across many enterprises with different peak
Aggregating demand from multiple customers tends to smooth out variation. Specifically, the “coefficient of variation” of
a sum of random variables is always less than or equal to that of any of the individual variables. Therefore, clouds get
While large enterprises benefit from economies of scale, larger cloud service providers can benefit from even greater
economies of scale, such as volume purchasing, network bandwidth, operations, administration and maintenance tooling.
Cloudonomics Law #6: Superiority in numbers is the most important factor in the result of a combat (Clausewitz).
The classic military strategist Carl von Clausewitz argued that, above all, numerical superiority was key to winning
battles. In the cloud theater, battles are waged between botnets and DDoS defenses. A botnet of 100,000 servers, each with
a megabit per second of uplink bandwidth, can launch 100 gigabits per second of attack bandwidth. An enterprise IT shop
would be overwhelmed by such an attack, whereas a large cloud service provider — especially one that is also an
A real-time enterprise derives competitive advantage from responding to changing business conditions and opportunities
faster than the competition. Often, decision-making depends on computing, e.g., business intelligence, risk analysis, portfolio
optimization and so forth. Assuming that the compute job is amenable to parallel processing, such computing tasks can often
trade off space and time, for example a batch job may run on one server for a thousand hours, or a thousand servers for one
hour, and a query on Google is fast because its processing is divided among numerous CPUs. Since an ideal cloud provides
effectively unbounded on-demand scalability, for the same cost, a business can accelerate its decision-making.
Cloudonomics Law #8: Dispersion is the inverse square of latency.
Reduced latency — the delay between making a request and getting a response — is increasingly essential to delivering a range
of services, among them rich Internet applications, online gaming, remote virtualized desktops, and interactive collaboration
such as video conferencing. However, to cut latency in half requires not twice as many nodes, but four times. For example,
growing from one service node to dozens can cut global latency (e.g., New York to Hong Kong) from 150 milliseconds to
below 20. However, shaving the next 15 milliseconds requires a thousand more nodes. There is thus a natural sweet spot for
dispersion aimed at latency reduction, that of a few dozen nodes — more than an enterprise would want to deploy, especially
The reliability of a system with n redundant components, each with reliability r, is 1-(1-r)n. So if the reliability of a single
data center is 99 percent, two data centers provide four nines (99.99 percent) and three data centers provide six nines
(99.9999 percent). While no finite quantity of data centers will ever provide 100 percent reliability, we can come very
close to an extremely high reliability architecture with only a few data centers. If a cloud provider wants to provide high
availability services globally for latency-sensitive applications, there must be a few data centers in each region.
Cloudonomics Law #10: An object at rest tends to stay at rest (Newton).
A data center is a very, very large object. While theoretically, any company can site data centers in globally optimal locations
that are located on a core network backbone with cheap access to power, cooling and acreage, few do. Instead, they remain in
locations for reasons such as where the company or an acquired unit was founded, or where they got a good deal on distressed
but conditioned space. A cloud service provider can locate greenfield sites optimally.