Cloud Computing

Deployment Models

[email protected]
 Cloud Computing
We covered so far…………….
 Cloud Computing
 Essential Characteristics
 On-demand self-service: (Service On demand)
 Broad network access
 Resource polling
 Measured service: Pay what I have use
 Rapid elasticity
 Cloud Computing Architecture
 Cloud computing stack
 Service Models
 Infrastructure as a Service (IaaS)
 Platform as a Service (PaaS)
 Software as a service (SaaS)
 Cloud Computing
We covered so far…………….
 Deployment Models
 Public Cloud
 Private Cloud
 Community Cloud
 Hybrid Cloud
 Advantages and Disadvantages of CC
 High Level Architectural Approach
 Major building blocks of CC Architecture
 Technical Architecture
 Deployment Operation Architecture
 CC Architecture vs. XaaS
 XaaS Stack Views: Customer View vs. Provider View
 Cloud Computing
We covered so far…………….
 XaaS
 Common Examples
 Other Examples
 Classical Service Model
 Key Impact of Cloud Computing For IT Function:
From Legacy IT to Evergreen IT
 Client Sever Model vs. Cloud Model
 SaaS, PaaS/ and IaaS Characteristics:
 Scenarios where they are useful
 Common / Well-known Providers
 “XaaS” different stacks
 Important Statements
 Network dependency:
 Subscribers still need IT skills:
 Workload locations are hidden from clients:
 Risks from multi-tenancy: (hard chnc of unwntd access)
 Data import/export, and performance limitations:
 Elasticity: illusion of unlimited resource availability:
 Up-front costs to migrate into the cloud:
 Potentially strong security from external threats:
 Limited visibility and control over data:
 Service Level Agreement:

5
General Cloud and Subscriber View

6
Scope and Applicability

7
 General Statements
 Network dependency:
The subscribers, need a working and secure network to access a cloud.
If the network is not reliable, the cloud will not be reliable from the
subscriber's point of view.

 Subscribers still need IT skills:

By operating the server computers, a provider may reduce the need for
IT staff in subscriber organizations, but subscribers will still access the
cloud from on-site subscriber-managed client systems that must be
maintained, secure.

 Workload locations are hidden from clients:

To manage a hardware resources efficiently, providers must be able to
migrate subscriber workloads between machines without disturbing the
clients. 8
 General Statements
 Risks from multi-tenancy:
The workloads of different clients may reside concurrently on the same
system, separated only by access policies implemented by a provider's
software.
A flaw in the software or flaw in the policies could compromise the security
of subscribers.
 Data import/export, and performance limitations:
Because subscribers access a cloud over a network, on-demand bulk
data import or export may exceed the network's ability to carry the data in
a timely manner.
Additionally, real-time or critical processing may be problematic because
of networking latency or other limitations.
 Organizations should consider these general statements and
their possible consequences for an organization's mission and
business model. Considering only the general statements, 9
however, is not sufficient.
 Understanding Who Controls
Resources in a Cloud
 As compared to traditional computing, cloud computing requires
subscribers to give up (to providers) two important capabilities:
 Control:
 the ability to decide, who and what is allowed to access subscriber data
and programs, and the ability to perform actions (such as erasing data
or disconnecting a network) both that the actions have been taken and
that no additional actions were taken that would subvert the
subscriber's intent (e.g., a subscriber request to erase a data object
should not be subverted by the silent generation of a copy).

 Visibility:
 the ability to monitor,, the status of a subscriber's data and programs
and how subscriber data and programs are being accessed by others 10
 Understanding Who Controls
Resources in a Cloud
 Security perimeter:
 It is a barrier to access: the entities that are located outside the
perimeter may access the resources inside only if allowed by a
boundary controller that enforces a policy over access.
 It describes the boundaries between different privilege levels of running
software, e.g., between applications and operating systems.

11
 Public Cloud
 Public Cloud - the cloud infrastructure is made available to
the general public or a large industry group. It is owned and
managed by the organization selling the cloud services. It
exists on the premises of the Cloud provider.

 Could be SaaS, PaaS and IaaS

 IaaS: Amazon cloud as infrastructure (EC2)
 PaaS: Microspft Azure as Platform
 Saas: Google as Services

e.g: Google Doc, Spreadsheet

12
 Public Cloud
 In the public setting, the provider's computing and storage resources
are potentially large; the communication links can be assumed to be
implemented over the public Internet; and the cloud serves a diverse
pool of clients (and possibly attackers).

13
 Public Cloud
 Workload locations are hidden from clients (public):
 A provider may migrate a subscriber's workload, whether
processing or data, at any time.
 Workload can be transferred to data centers where costs
is low.
 Workload may be relocated anywhere at anytime unless
provider has offered (optional) location restriction policies
 Risks from multi-tenancy (public):
 A single machine may be shared by the workloads of any
combination of subscribers (a subscriber's workload may
be co-resident with the workloads of competitors or
adversaries)
 Introduces both reliability and security risk
14
 Public Cloud
 Network dependency (public):
 Subscribers connect to providers via the public Internet.

 Connections depends on the Internet's infrastructure.

 Domain Name System (DNS) servers
 the router infrastructure
 the inter-router links
 Limited visibility and control over data regarding security:
 The details of provider system operation are usually
considered proprietary information and are not disclosed
to subscribers.
 In many cases, the software employed by a provider is
usually proprietary and not available for examination by
subscribers.
 a subscriber cannot currently verify that data has been
15
completely deleted from a provider's systems.
 Public Cloud
 Elasticity: illusion of unlimited resource availability:
 Public clouds are generally unrestricted in their location or
size.
 Public clouds potentially have high degree of flexibility in
the movement of subscriber workloads to correspond with
available resources.

 Low up-front costs to migrate into the cloud (public):

 You pay and use it.

 Don’t need many things for cloud in comparison with

private cloud
 Restrictive default service level agreements (SLA) (public):
 The default service level agreements of public clouds
specify limited promises that providers make to
subscribers. But SLA can be as per consumer demand 16
 Private Cloud
 Private Cloud ( Build a cloud and use it)
 – the cloud infrastructure is operated solely for an
organization. It may be owned and managed by the
organization, a third-party or some combination of them.
 It may exists on or off premises of the Cloud provider.

17
Private Cloud

18
 On-site Private Cloud
 The security perimeter extends around both the
subscriber's on-site resources and the private cloud's
resources.
 Security perimeter does not guarantee control over the
private cloud's resources but subscriber can exercise
control over resources.

19
 On-site Private Cloud
 Network dependency (on-site-private):
 May be limited, because it depending on N/W resources,
over which a subscriber has control
 Subscribers still need IT skills (on-site-private):
 Subscriber organizations will need the traditional IT skills
required to manage user devices that access the private
cloud, and will require cloud IT skills as well.
 Workload locations are hidden from clients (on-site-private):
 To manage hardware resources, a private cloud must be
able to migrate workloads between machines without
inconveniencing clients.
 However, a subscriber organization chooses the physical
infrastructure, but individual clients still may not know where
their workloads physically exist within the subscriber
20
organization's infrastructure.
 On-site Private Cloud
 Risks from multi-tenancy (on-site-private):
 Workloads of different clients may reside concurrently on the
same systems and local networks, separated only by access
policies implemented by a cloud provider's software.
 A flaw in the software or the policies could compromise the
security of a subscriber organization by exposing client
workloads to one another.

 Data import/export, and performance limitations(on-site-

private):
 On-demand bulk data import/export is limited by the on-site
private cloud's network capacity, and real-time or critical
processing may be problematic because of networking
limitations.
21
 On-site Private Cloud
 Potentially strong security from external threats :
 In an on-site private cloud, a subscriber has the option of
implementing an appropriately strong security perimeter
to protect private cloud resources against external
threats to the same level of security as can be achieved
for non-cloud resources.
 Significant-to-high up-front costs to migrate into the cloud:
 An on-site private cloud requires that cloud management
software be installed on computer systems within a
subscriber organization. If the cloud is intended to
support process-intensive or data-intensive workloads,
the software will need to be installed on numerous
commodity systems or on a more limited number of high-
performance systems. ….
22
 On-site Private Cloud
 Installing cloud software and managing the installations
will incur significant up-front costs, even if the cloud
software itself is free, and even if much of the hardware
already exists within a subscriber organization..

 Limited resources :
 An on-site private cloud, at any specific time, has a fixed
computing and storage capacity that has been sized to
correspond to anticipated workloads and cost
restrictions.
 missing power of illusion of
Owing to the
unlimited resource availability
23
 Outsourced Private Cloud
 Cloud is private but outsource it in term of like maintaining
and installing etc

 Outsourced private cloud has two security perimeters, one

implemented by a cloud subscriber (on the left) and one
implemented by a provider (on the right) in Fig.

 The two security perimeters are joined by a protected

communications link.

 The security of data and processing conducted in the

outsourced private cloud depends on
 the strength and availability of both security perimeters
24
 and of the protected communication link.
Outsourced Private Cloud

25
 Outsourced Private Cloud
 Network dependency (outsourced-private):
 In the outsourced private scenario, subscribers may have
an option to provision unique protected and reliable
communication links with the provider.
 Workload locations are hidden from clients (outsourced-
private):
 The implications are the same as those for an on-site
private cloud.
 however, provides an opportunity for the subscriber's
organization to have some visibility and control regarding
workload locations.
 Risks from multi-tenancy (outsourced-private):
 The implications are the same as those for an on-site
private cloud. 26
 Outsourced Private Cloud
 Data import/export, and performance limitations
(outsourced-private):
 On-demand bulk data import/export is limited by the
network capacity between provider and subscriber, and
real-time or critical processing may be problematic
because of networking limitations.

 In the outsourced private cloud scenario, however, these

limits may be adjusted, although not eliminated, by
provisioning high-performance and/or high-reliability
networking between the provider and subscriber.

27
 Outsourced Private Cloud
 Modest-to-significant up-front costs to migrate
into the cloud (outsourced-private):
 In the outsourced private cloud scenario, the resources
are provisioned by the provider.

 Main start-up costs for the subscriber relate to:

 Negotiating the terms of the service level agreement (e.g.,
agreeing on suitable protection mechanisms)
 Possibly upgrading the subscriber's network to connect to the
outsourced private cloud
 Switching from traditional applications to cloud-hosted
applications
 Porting existing non-cloud operations to the cloud
 Training
28
 Outsourced Private Cloud
 Potentially strong security from external threats
(outsourced-private):
 As with the on-site private cloud scenario, a variety of
techniques exist to harden a security perimeter.

 The main difference with the outsourced private cloud is

that the techniques need to be applied both to a
subscriber's perimeter and provider's perimeter, and that
the communications link needs to be protected.

29
 Outsourced Private Cloud

 Extensive resources available (outsourced-private):

 In the case of the outsourced private cloud, a subscriber
can rent resources in any quantity offered by the
provider. Provisioning and operating computing
equipment at scale is a core competency of providers.
 As with the on-site private cloud, an outsourced private
cloud has a fixed capacity at any given time, and
providing elasticity for clients is achievable only if the
cloud is large enough and there is sufficient diversity of
workloads.
 As with an on-site private cloud, an outsourced private
cloud will exhibit maximum capacity limits similar to those
of traditional data centers.
30
 Community Cloud
 Community Cloud
 –The cloud infrastructure is shared by several organizations and
supports a specific community that has shared concerns (e.g.,
mission, security requirements, policy, and compliance
considerations) or same type of work flow.
 It may be owned and managed by one or more of the
organization in community, a third-party or some combination of
them.
 It may exists on or off premises of the Cloud provider.
 Examples:
 HEC Cloud, Banks etc

31
 Community Cloud
 Community Cloud is made up of a set of participant
organizations.
 Each participant organization may provide cloud services,
consume cloud services, or both.
 It is necessary for at least one community member to
provide cloud services for a community cloud to be
functional.
 Assuming that each organization implements a security
perimeter,
 the participant organizations are connected via links
between the boundary controllers that allow access through
their security perimeters.
32
 Community Cloud
 The access policy of a community cloud may be complex:

 if there are N community members, a decision must be made, either

implicitly or explicitly, on how to share a member's local cloud
resources with each of the other members.

 A number of policy specification techniques role-based access

control and attribute-based access control might be used to express
sharing policies.

 Additionally, identity management is important in this scenario since

clients from multiple participant organizations access a common
pool of resources.

33
Community Cloud

34
 Community Cloud
 On-site Community Cloud is applies to community clouds
implemented on the premises of the customers composing
a community cloud.

 Out-sourced Community Cloud is applies to community

clouds where the server side is outsourced to a hosting
company

35
 On-site Community Cloud
 Network dependency (on-site-community):
 The subscribers in an on-site community cloud need to
either provision controlled inter-site communication links
or use cryptography over a less controlled
communications media (such as the public Internet).
 The reliability and security of the community cloud will
depend on the reliability and security of the
communication links.
 Subscribers still need IT skills (on-site-community):
 Organizations that provide cloud resources, the IT skills
required are similar to those required for the on-site
private cloud scenario except that the overall cloud
configuration may be more complex and hence require a
higher skill level.
36
 On-site Community Cloud
 Identity and access control configurations among the
participant organizations may be complex;
 organizations considering a community cloud should
ensure that the IT staff from the participant organizations
negotiate and clearly document the access policies that
are planned within the community cloud.

 Workload locations are hidden from clients (on-site-

community):
 To participant organization providing cloud services to
the community cloud may wish to employ an outsourced
private cloud as a part of its implementation strategy.

37
 On-site Community Cloud
 Data import/export, and performance limitations
(on-site-community):
 The communication links between the various participant
organizations in a community cloud can be provisioned
to various levels of performance, security and reliability,
based on the needs of the participant organizations.
 The network-based limitations are thus similar to those of
the outsourced-private cloud scenario.

38
 On-site Community Cloud
 Potentially strong security from external threats
(on-site-community):
 The security of a community cloud from external threats
depends on the security of all the security perimeters of
the participant organizations and the strength of the
communications links.
 These dependencies are essentially similar to those of
the outsourced private cloud scenario, but with possibly
more links and security perimeters..

39
 On-site Community Cloud
 Highly variable up-front costs to migrate into the cloud
(on-site-community):
 The up-front costs of an on-site community cloud for a
participant organization depend greatly on whether the
organization plans to consume cloud services only or also
to provide cloud services.
 For the consume-only scenario, the up-front costs appear
to be similar to those for an outsourced private cloud (i.e.,
modest-to-significant).
 For a participant organization that intends to provide cloud
services within the community cloud, the costs appear to
be similar to those for the on-site private cloud scenario
(i.e., significant-to-high).

40
 Outsourced Community Cloud
 This scenario is very similar to the outsourced private cloud
scenario:

 server-side responsibilities are managed by a cloud

provider that implements a security perimeter and that
prevents mingling (mixing) of community cloud resources
with other cloud resources that are outside the provider-
controlled security perimeter.

 A significant difference is that the cloud provider may need

to enforce a sharing policy among participant organizations
in the community cloud.
41
Outsourced Community Cloud

42
 Outsourced Community Cloud
 Network dependency (outsourced-community):
 The network dependency of the outsourced community
cloud is similar to that of the outsourced private cloud.
The primary difference is that multiple protected
communications links are likely from the community
members to the provider's facility..
 Workload locations are hidden from clients (outsourced-
community):
 Same as for the outsourced private cloud scenario.

 Risks from multi-tenancy (outsourced-private):

 Same as for the on-site community cloud scenario.

43
 Outsourced Community Cloud
 Data import/export, and performance limitations
(outsourced-community):
 Same as for the outsourced private cloud scenario.

 Modest-to-significant up-front costs to migrate into the cloud

(outsourced-community):
 same as for the outsourced private cloud scenario.

 Potentially strong security from external threats:

 Same as for the on-site community cloud scenario.

 Extensive resources available (outsourced-community):

 same as for the outsourced private cloud scenario.

44
 Hybrid Cloud
 Hybrid Cloud
 –The cloud infrastructure is a composition of two or more
clouds (private, community, or public) that remain unique
entities but are bound together by standardized or proprietary
technology that enables data and application portability.
 Interpretability has high degree of importance

 Examples:
 Windows Azure
 VMware vcloud

45
 Hybrid Cloud
 The a hybrid cloud is composed of two or more private,
community, or public clouds.

 They have significant variations in performance, reliability,

and security properties depending upon the type of cloud
chosen to build hybrid cloud.

 A hybrid cloud can be extremely complex.

 A hybrid cloud may change over the time with constituent

clouds joining and leaving.

46
 Hybrid Cloud
 Why hybrid cloud is useful or important.
 It depends, what are the uses patterns we have ? Like
 If more critical mission, security issues involved than keep it private
 In university, labs of students for computing (less security) can be
made public while students record and examinations cannot be
outsourced, ( even more economical) so it is combination of private
and public cloud.
 It is difficult to handle or manage the categorization of data
and applications in case of hybrid cloud.
 These applications and data belongs to public etc

47
Hybrid Cloud

48