CEC315 - Introduction To Cloud Computing - Module 3

University of Buea,
College of Technology (COT),

Department of Computer Engineering -
2021/2022 Academic Year
CEC315: INTRODUCTION TO
CLOUD COMPUTING
Enjoy Your Ride to the Cloud!
Module 3
Copyright ©Kometa Denis; komtanis@gmail.com; Dpt. of Com. Engineering, COT, University of Buea, 2021
1
CEC315: Introduction to Cloud Computing – Module 3
Module 3: Types of Clouds and Cloud Architectures
3.1 Introduction
 In the first module, we saw how cloud computing evolved as illustrated in Figure 3-1 and had the
universally accepted definition of cloud computing by NIST which is a cloud model composed of five
essential characteristics, three service models, and four deployment models.
Figure 3-1: Evolution of Cloud Computing.

 The deployment models are also referred to as type of clouds, which include: public, private, hybrid
and community clouds.
3.1.1 Public Clouds
 Service providers offer their resources as services to the general public. The public cloud infrastructure
is available for public use alternatively for a large industry group and is owned by an organisation
selling cloud services.
 Benefits:
➢ no initial capital investment on infrastructure
➢ shifting of risks to infrastructure providers
 Drawbacks:
➢ Lack fine-grained control over data, network and security settings
➢ hampers effectiveness of many business scenarios.
3.1.2 Private Clouds
 Designed for exclusive use by a single organisation.
➢ Known as internal clouds
➢ Built and managed by the organisation or by external providersorganisation selling cloud
services.
1
2
 The private cloud infrastructure is operated for the exclusive use of an organisation. The cloud may
be managed by that organisation or a third party. Private clouds may be either on or off-premises.
 Benefits:
➢ Offer the highest degree of control over
➢ performance, reliability, and security.
 Drawbacks:
➢ Do not provide the benefit of no up-front capital costs.
3.1.3 Hybrid Clouds
 A hybrid cloud combines multiple clouds (private, community of public) where those clouds retain
their unique identities, but are bound together as a unit. A hybrid cloud may offer standardized or
proprietary access to data and applications, as well as application portability
 A combination of public and private cloud models
➢ part of the service infrastructure runs in private clouds, the rest runs in public clouds.
➢ address the limitations of each approach.
➢ tighter control and security over application data compared to public clouds,
➢ on-demand service expansion and contraction.
 Problem
➢ Designing a hybrid cloud requires carefully determining the best split between public and private
cloud components.
3.1.4 Community Clouds
 A community cloud is one where the cloud has been organised to serve a common function or
purpose.
 Examples: Healthcare, Education, and Religion, etc..
Figure 3-2: Deployment Models.
2
3
3.2 Service Model

 Also known as SPI (Software, Platform and Infrastructure) Model presented in Figure 3-3.
 There are many different service models described in the literature, all of which take the following
form: XaaS, or “<Something> as a Service”
 Three (3) service types have been universally accepted.
Figure 3-3: SPI Model- Cloud Services ( XaaS ).

3.2.1 Infrastructure as a Service (Iaas)
 IaaS provides fundamental computing resources:
➢ Processing
➢ Memory
➢ Storage
➢ Networks, etc.
 Enabled via virtualization technologies
➢ Virtual Machine is a common deployment unit.
➢ E.g., AWS EC2
 Users can deploy and run arbitrary software.
➢ E.g., operating systems and applications
 No control of underlying hardware
➢ Can allow limited control of networking components
➢ Full control of OS
 Examples of IaaS Service Providers
➢ Amazon Elastic Compute Cloud (EC2)
➢ Eucalyptus
3
4
➢ GoGrid
➢ FlexiScale
➢ Linode
➢ RackSpace Cloud
➢ Terremark
Figure 3-4: IaaS Architecture.
Table 3-1: Amazon EC2 Characteristics
3.2.2 Platform as a Service (PaaS)

 PaaS provides virtual machines, operating systems, applications, services, development frameworks,
transactions, and control structures.
4
5
 The client can deploy its applications on the cloud infrastructure or use applications that were
programmed using languages and tools that are supported by the PaaS service provider.
 The service provider manages the cloud infrastructure, the operating systems, and the enabling
software. The client is responsible for installing and managing the application that it is deploying.
 A PaaS service adds integration features, middleware, and other orchestration and choreography
services to the IaaS model.
 Examples of PaaS services are:
➢ Force.com
➢ GoGrid CloudCenter
➢ Google AppEngine
➢ Windows Azure Platform
Table 3-2: Microsoft Azure Characteristics
3.2.3 Software as a Service (SaaS)

 SaaS is a complete operating environment with applications, management, and the user interface.
 Good examples of SaaS cloud service providers are:
➢ GoogleApps
➢ Oracle On Demand
➢ SalesForce.com
➢ SQL Azure
5
6
Figure 3-5: SaaS architecture/Maturity Levels.
Table 3-3: GoogleApps Characteristics
Figure 3-6: XaaS Comparison

6
7
3.3 The Cloud Cube Model

 A Jericho forum focuses on the protection of cloud networks. (The Open Group maintains this
association.)
 The group has an interesting model that attempts to categorize a cloud network based on four
dimensional factors which is published in a paper titled “Cloud Cube Model: Selecting Cloud
Formations for Secure Collaboration.”
 What problem does it try to solve?
 One of the key challenges that businesses face when considering cloud computing as an option is to
determine how to choose the cloud formation best suited to their various types of business operations.
 Four (4) dimensional factors are:
➢ Physical location of the data
➢ Ownership
➢ Security boundary
➢ Sourcing.
3.3.1 Physical location of the Data
 Physical location of the data: Internal (I)/External (E) determines your organisation's boundaries.
 This is the dimension that defines the physical location of the data: where does the cloud form you
want to use exist - inside or outside your organisation’s boundaries?
 If it is within your own physical boundary, then it is Internal. If it is not within your own physical
boundary then it is External.
 For example, virtualised hard disks in an organisation’s data centre would be internal, while Amazon
S31 would be external at some location “off-site”.
 Note: Be wary of making a false assumption that Interna is more secure than External. The effective
use of both is likely to provide the most secure usage model.
Figure 3-4: Physical Location of Data.
7
8
3.3.2 Ownership
 Ownership: Proprietary (P)/Open (O) is a measure of not only the technology ownership, but of
interoperability, ease of data transfer, and degree of vendor application lock-in an organisation’s
servers.
 This is the dimension that defines the state of ownership of the cloud technology, services,
interfaces, etc. It indicates the degree of interoperability, as well as enabling “data/application
transportability” between your own systems and other cloud forms, and the ability to withdraw
your data from a cloud form or to move it to another without constraint. It also indicates any
constraints on being able to share applications.
 Proprietary means that the organisation providing the service is keeping the means of provision
under their ownership. As a result, when operating in clouds that are proprietary, you may not be
able to move to another cloud supplier without significant effort or investment. Often the more
innovative technology advances occur in the proprietary domain. As such the proprietor may
choose to enforce restrictions through patents and by keeping the technology involved a trade
secret.
 Clouds that are Open are using technology that is not proprietary, meaning that there are likely to
be more suppliers, and you are not as constrained in being able to share your data and collaborate
with selected parties using the same open technology. Open services tend to be those that are
widespread and consumerized, and most likely a published open standard, for example email
(SMTP).
 An as yet unproven premise is that the clouds that most effectively enhance collaboration between
multiple organisations will be Open
Figure 3-5: Ownership.

3.3.3 Security Boundary
 Security boundary: Perimiterised (Per)/Deperimiterised (D-p) is a measure of whether the
operation is inside or outside the security boundary or network firewall.
8
9
 The third dimension represents the “architectural mindset” – are you operating inside your
traditional IT perimeter or outside it? De-perimeterisation has always related to the gradual
failure/removal/shrinking/collapse of the traditional silo-based IT perimeter.
 Perimeterised implies continuing to operate within the traditional IT perimeter, often signaled by
“network firewalls”.
 In effect, when operating in the perimeterised areas, you may simply extend your own organisation’s
perimeter into the external cloud computing domain using a VPN and operating the virtual server
in your own IP domain, making use of your own directory services to control access. Then, when
the computing task is completed, you can withdraw your perimeter back to its original traditional
position. We consider this type of system perimeter to be a traditional, though virtual, perimeter.
 De-perimeterised, assumes that the system perimeter is architected following the principles outlined
in the Jericho Forum’s Commandments and Collaboration Oriented Architectures Framework. The
terms Micro-Perimeterisation and Macro-Perimeterisation will likely be in active use here – for
example in a de-perimeterised frame the data would be encapsulated with meta-data and
mechanisms that would protect the data from inappropriate usage.
Figure 3-6: Security Boundary

3.3.4 Sourcing
 Sourcing: Insourced or Outsourced means whether the service is provided by the customer or the
service provider.
 We define a 4th dimension that has 2 states in each of the 8 cloud forms: Per(IP,IO,EP,EO) and D-
p(IP,IO,EP,EO), that responds to the question “Who do you want running your Clouds?”:
 Outsourced: the service is provided by a 3rd party.
 Insourced: the service is provided by your own staff under your control.
 These 2 states describe who is managing delivery of the cloud service(s) that you use. This is
primarily a policy issue (i.e. a business decision, not a technical or architecturaldecision) which must
9
10
be embodied in a contract with the cloud provider. In the Cloud Cube Model diagram we show this
4th dimension by 2 colors; any of the 8 cloud forms can take either color.
Figure 3-7: Sourcing

3.4 Cloud Architectures
Figure 3-8: Cloud Computing Architecture.

3.4.1 Business model
 Service-driven business model – used in all other layers
➢ hardware and software resources are provided as services on an on-demand basis
➢ every layer is a service to the layer above
➢ every layer is a customer of the layer below
 Categories of services
➢ Software as a service (SaaS)
➢ Platform as a service (PaaS)
➢ Infrastructure as a service (IaaS).
10
11
Figure 3-9: Some entities can be both users and providers for other users.
Figure 3-10: The Infrastructure Layer.

 IaaS – Infrastructure as a Service
➢ On-demand provisioning of infrastructural resources (physical machines, CPU, storage, GPUs,
etc.)
➢ Partitions the physical resources by using virtualization technologies: e.g. Xen, KVM, VMware
➢ Examples of IaaS providers: Amazon EC2, GoGrid and Flexiscale, Google Cloud Platform.
 PaaS – Platform as a Service
➢ Provides platform layer resources
➢ Operating system support
➢ Software development frameworks
11
12
➢ Examples of PaaS providers

• Google App Engine, Microsoft Windows Azure, and Force.com.
• Google App Engine supports
• implementing storage, database, and business logic of typical web applications
Figure 3-11: The Platfom Layer
 SaaS – Software as a Service

➢ Refers to providing on demand applications over the Internet
➢ Leverages the automatic-scaling feature to achieve
• better performance
• availability
• low operating cost
➢ Examples SaaS providers
• LinkedIn, Twitter, Skype, Google Drive, Evernote, Salesforce.com, Rackspace, etc.
Figure 3-12: The Application Layer

12
13
3.5 Cloud Federations (Interclouds)

 Cloud federation, which enables cloud providers and IT companies to collaborate and share their
resources, is associated with many portability and interoperability issues.
 Cloud developers and researchers have proposed or implemented numerous federation architectures,
including cloud bursting, brokering, aggregation, and multitier.
 These architectures can be classified according to the level of coupling or interoperation among the
cloud instances involved, ranging from loosely coupled (with no or little interoperability among cloud
instances) to tightly coupled (with full interoperability among cloud instances).
3.5.1 Loosely Coupled Federation
 This scenario is formed by independent cloud instances—for example, a private cloud
complementing its infrastructure with resources from an external commercial cloud—with limited
interoperation between them.
 A cloud instance has little or no control over remote resources (for example, decisions about VM
placement are not allowed), monitoring information is limited (for example, only CPU, memory, or
disk consumption of each VM is reported), and there is no support for advanced features such as
cross-site networks or VM migration.
3.5.2 Partially Coupled Federation
 This scenario typically consists of various partner clouds that establish a contract or framework
agreement stating the terms and conditions under which one partner cloud can use resources from
another.
 This contract can enable a certain level of control over remote resources (for example, allowing the
definition of affinity rules to force two or more remote VMs to be placed in the same physical cluster);
can agree to the interchange of more detailed monitoring information (for example, providing
information about the host where the VM is located, energy consumption, and so on); and can enable
some advanced networking features among partner clouds (for example, the creation of virtual
networks across site boundaries).
3.5.3 Tightly Coupled Federation
 This scenario usually includes clouds belonging to the same organisation and is normally governed by
the same cloud OS type.
 In this scenario, a cloud instance can have advanced control over remote resources—for example,
allowing decisions about the exact placement of a remote VM—and can access all the monitoring
information available about remote resources.
13
14
 In addition, it can allow other advanced features, including the creation of cross-site networks, cross-
site migration of VMs, implementation of high availability techniques among remote cloud instances,
and creation of virtual storage systems across site boundaries.
3.5.4 Bursting (Hybrid) Architecture
 Cloud bursting or hybrid architecture combines the existing onpremise infrastructure (usually a private
cloud) with remote resources from one or more public clouds to provide extra capacity to satisfy peak
demand periods.
 Because the local cloud OS has no advanced control over the virtual resources deployed in external
clouds beyond the basic operations the providers allow, this architecture is loosely coupled. Most
existing open cloud managers support the hybrid cloud architecture and is used in infrastructures such
as StratusLab (http://stratuslab.eu).
3.5.5 Broker Architecture
 The central component of the broker architecture is a broker that serves various users and has access
to several public cloud infrastructures. A simple broker should be able to deploy virtual resources in
the cloud as selected by he user.
 An advanced broker offering service management capabilities could make scheduling decisions based
on optimization criteria such as cost, performance, or energy consumption to automatically deploy
virtual user service in the most suitable cloud, or it could even distribute the service components across
multiple clouds. This architecture is also loosely coupled since public clouds typically do not allow
advanced control over the deployed virtual resources.
 Brokering is the most common federation scenario. Examples include BonFIRE (www.bonfire-
project.eu), Open Cirrus, and FutureGrid ( http://futuregrid.org).email accounts, their LinkedIn
account, their MySpace page, and so forth.
3.5.6 Aggregated Architecture
 Cloud aggregation consists of two or more partner clouds that interoperate to aggregate their resources
and provide users with a larger virtual infrastructure. This architecture is usually partially coupled,
since partners could be provided with some kind of advanced control over remote resources, depending
on the terms and conditions of contracts with other partners.
 These partner clouds usually have a higher coupling level when they belong to the same corporation
than when they are owned by different companies that agree to cooperate and aggregate their
resources. The Reservoir federated infrastructure is an example of an aggregated cloud architecture.
14
15
3.5.7 Multitier Architecture

 The multitier architecture consists of two or more cloud sites, each running its own cloud OS and
usually belonging to the same corporation, that are managed by a third cloud OS instance following a
hierarchical arrangement.
 This upper cloud OS instance has full control over resources in different cloud sites—a tightly coupled
scenario—and it exposes the resources available in the different cloud sites as if they were located in
a single cloud.
 This architecture is beneficial for corporations with geographically distributed cloud infrastructures
because it provides uniform access. It is also useful for implementing advanced management features
such as high availability, load balancing, and fault tolerance..
Figure 3-13: Cloud Federation Architectures: (a) Bursting (Hybrid); (b) Broker; (c)Aggregated; (d)
Mulitier
15

CEC315 - Introduction To Cloud Computing - Module 3

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CEC315 - Introduction To Cloud Computing - Module 3

Uploaded by

Copyright:

Available Formats

University of Buea,

College of Technology (COT),

Module 3: Types of Clouds and Cloud Architectures

Figure 3-1: Evolution of Cloud Computing.

Figure 3-2: Deployment Models.

3.2 Service Model

Figure 3-3: SPI Model- Cloud Services ( XaaS ).

Figure 3-4: IaaS Architecture.

Table 3-1: Amazon EC2 Characteristics

3.2.2 Platform as a Service (PaaS)

Table 3-2: Microsoft Azure Characteristics

3.2.3 Software as a Service (SaaS)

Figure 3-5: SaaS architecture/Maturity Levels.

Table 3-3: GoogleApps Characteristics

Figure 3-6: XaaS Comparison

3.3 The Cloud Cube Model

Figure 3-4: Physical Location of Data.

Figure 3-5: Ownership.

Figure 3-6: Security Boundary

Figure 3-7: Sourcing

Figure 3-8: Cloud Computing Architecture.

Figure 3-10: The Infrastructure Layer.

➢ Examples of PaaS providers

Figure 3-11: The Platfom Layer

 SaaS – Software as a Service

Figure 3-12: The Application Layer

3.5 Cloud Federations (Interclouds)

3.5.7 Multitier Architecture

You might also like