Comptia Cloud+

Cloud Provider: maintains and manages resources in the cloud (ownership

can be uncoupled), collecting subscriptions from users and allow users to
concentrate on the core business.
Cloud Consumer: subscriber to cloud provider's offering (by entering a
contract with SLA).
Cloud Service Owner: can be either the provider or consumer.
Cloud Service Business Models: define in a coherent manner the goals and
needs of a consumer to focus them on their business and on their business
perspective.
-as a Service (concept common to cloud service business models): names the
highest level managed by the provider applied to almost anything that can be
digitized (Infrastracture, Software, Platform, Desktop, ...) and from the
business perspective should be maintains, managed, offered by the provider
(ownership can be uncoupled). Main characteristics: self-provisioned,
metered, on-demand, ubiquotous access.
Accountability and Responsibility are split among infrastructure provider (i.e.
ISP providing access), cloud consumer and provider based on contract and
related infrastructure. The split depends ans well on the model: in SaaS
provider assumes almost all responsibility, in PaaS and IaaS providers are
responsible for underlying resources, consumers for their products.
Infrastructure as a Service (IaaS): Computer resources, Storage, Networking
offered by the cloud provider as a service. Consumer will provision (web
interface or automatic API, either proprietary or cross-cloud standard) and
use them to develop and deliver its software and will be charged on a pay per
use basis.
Best commercial use cases are: provide extra capacity for short-term peak
workload (i.e. e-commerce during campaign/sesonal peak), use as storage
system for media/streaming that demands a huge amount of storage
capacity.
Hardware as a Service can be included in IaaS as a form of grid computing
for Big Data.
Platform as a Service (PaaS): the cloud provider manages and maintains the
frameworks/middleware for consumers' application development (as well as
Infrastructure), i.e. runtime libraries, programming SDK, database,
middleware. It is mainly seen as a facilitator to achieve immediate business
requirements (application design/dev/testing).
Best commercial use cases are: use a platform to test new business
ideas/services (limit upfront costs/set up to make ideas testing viable),
website hosting (to achieve scaling and ability to grow).
Software as a Service (SaaS): the cloud provider manages and maintains (i.e.
update/patches) the application that will be accessible to the consumer
throgh thin client or web. The concept of Application service provider and
SaaS are similar, however ASP normally run an instance for each customer on
a shared data space, while SaaS run on a single instance of software.

Consumers will subscribe (monthly or annual renewal) and lower upfront

costs.
Best commercial use cases are: web based services/software (i.e. e-mail,
social and blogging), file storage/sharing (allowing scalability, ubiquotous
access and availability), vertical (i.e. sales) applications like CRM.
Data as a Service (DaaS): the cloud provider manages and maintains the
solution/application (therefore DaaS is similar to SaaS) to allow the consumer
to access on demand and regardless geographical and organizazional
separation the data it owns (data quality and cleansing might be also granted
as part of the data service).
Communication as a Service (CaaS): the cloud provider will manage and
maintains form of communcation (i.e. VoIP, IM, Collaboration, VideoConf).
Desktop (Workstation) as a Service (DaaS): the cloud provider will offer a
virtual desktop infrastructure to the consumer to allow them same userdesktop
experience.
Everything as a Service (XaaS): can refer to a combination of services or any
of the -as a service.
Cloud Delivery Models
Regardless of delivery model, hosting for cloud can be on-premise or offpremise (depending on who will be maintaining the resources). In general,
on-premise hosting carries higher costs, as a provider will leverage and pass
along savings from having multiple customers.
Private Clouds: cloud resources with a single consumer usually to tightly
maintain privacy and security (no multiple tenants or less complex to secure).
It maintains advantage of thin provisioning and a more efficient use of
resources (capital/energy and storage) provided by virtualization. However,
flexibility of fast scaling not possible as lower resources can be destinated to
a single tenant (not many stand-by/flexibility). Private clouds can integrate
with public clouds either permanently (hybrid cloud) or as needed (with cloud
bursting).
Public Clouds: off-premise hosting of cloud resources where multi-tenancy
occurs (public cloud providers are not consumer of their own service). The
benefits of public clouds are scalability, cost effectiveness, reliability,
flexibility, geographical independence, multi-provider usage.
Security is tipically ensured in multitenant models with network isolation,
data segragation (tagging data to allow they will be used outside the
domain), and extra measures to achieve compliance.
Hybrid Clouds: combination of public and private clouds permanently to
leverage security of private clouds (if regulatory/storage compliance is
needed) and cost effectiveness\scalability of public cloud.

Community Clouds: are implemented as closed clouds by consumer with

common interests (i.e. industry consortium/project), can be managed by a
tenant or a third party.

Concepts
Elasticity: ability of a consumer to scale without purchasing
hardware/middleware internally (individual scalability + flexibility to
distribute the workload across multiple systems).
On-demand self-serve: consumer ability to achieve just-in-time and with rapid
deployment resource provision, on demand and without provider involvement
(saving effort and time) and to pay for them as they are used. The provider in
order to achieve this (just-in-time provisioning) has to put in place specific
resource management (clean-up, compression, diversion of unused
resources) and pooling. Provision can be also totally automated with
orchestration platform.
Orchestration Platforms: allow the automated provisioning of cloud resources
by using process awaraness to determine the needs and templated to quickly
translate them to a (complex) configuration.

Pay as you grow: the service is by subscription and charges only for what is
consumed (advantage: less upfront cost and cost comes as bussiness
(revenues) grows, costs can be calculated up-front).
Chargeback: applying an organization's cloud usage to the actual consumers
(business line), might be charge back (invoicing) or assignment (for
accounting reason and cloud justification).
Ubiquitous Access: ability to access the cloud from anywhere (device,
location independent).
Metering: cloud ability to meter consumer for what they use and charge
them. It is useful for provider/consumer also to monitor how resources are
used.
Multitenancy: ability of the cloud to serve multiple consumer (tenants) with a
single instance of a resource (with transparency from a tenant's perspective
and granting security without requiring tenants to change underlying
application or data).
Resource Pooling: ability to keep resources common to all tenants in a pool
and dispatch them based on needs of individual tenants without affecting
others (infinite resource perception).
Cloud Bursting: ability to augment privat clouds with public clouds when
needed.
Data Storage - Cloud: unstructured data in the cloud are stored as objects
(not files/block as the paradigm of putting files in the cloud instead a local
SAN/drive will not work the same way as in the latter). The object paradigm in

storage can even allow to access a larger information in the time it takes to
process data. Objects = data + metadata and with unique object ID.
Object ID: numerical id + partition id identify univocally an object;
Metadata: data about the object that is stored with the object (i.e. for
indexing, lifecycle mgmt); can be extensible and grow as attributes that
describe the object;
Policies: additional metadata as a security mechanism to limit the
rights of user
accessing the objects (access control: mandatory,
discretionary, role-based);
Replicas: duplicate objects to increase availability/performance;
Data BLOB: data stored (BLOB) as a single object.
Virtualization
Hypervisor:
Type I: known as bare metal hypervisor, runs on the physical machine (no
further OS). Examples: Hyper-V, Xen, VMware ESX. Type I hypervisors
generally ensure better performance and scalability and it is the typical
choise (as also more robust) for enterprise users. In terms of requirements,
type I needs an underlying compatible HW architecture (as it acts as OS).
Type II: kind of hypervisor running on top of an host OS (OS dependent).
Examples: Virtual PC, VMware Workstation, KVM, OracleVM. In this case, there
is another layer of accountability (Host OS) and the Hypervisor need to
understand how to map Guest OS needs on the Host OS and Host OS failures
will affect guests. In addition, the Type II OS competes with guests
(overhead).
Proprietary vs Open Source: Proprietary hypervisors are generally well known
and teached to IT staff/professionals and backed by vendors; open source
hypervisons are free to implement and potentially more secure.
1. Virtual machine templates: allow to define standard configurations
(CPUs, RAM, drives) that can be deployed (lower cost and risk of
mistakes and speed up development). Can also allow hierarchical
templating (start with a basic template and add specialized features)
2. Install guest tools: offered by hypervisors to add virtual drivers for
better performance\usability in guest OS or management tools (i.e.
time sync, drag&drop, file transfer).
3. Snapshot: capturing the virtual machine at a moment in time to restore
an earlier state (it is a temporary milestone and not to be used as a
structural backup replacement)
4. Cloning: is a duplicate that can be deployed to create new VM that
evolve differently (different identifiers, i.e. MAC address, securities),
but cannot be used to restore the original VM.
5. Image backup: perform a bit for bit backup (more complete than filelevel backup and might not mount)
6. File backup: more specific file based backup (less space and easily
recoverable), however complete recovery (system state) is not
addressed.

7. Virtual NICs configuration: connect the VM to the virtual network (and

eventually then to the real LAN with different configuration at
hypervisor level, i.e. bridged to obtain settings configuration from the
real LAN) with standard settings (IP, default GW, netmask).
8. Virtual Switches: can give the flexibility\decoupling to isolate VM
netwotk traffic to go on the outside (real) LAN and to configure VLAN
as well or virtual switch interface configuration (i.e. policy
enforcement, QoS, mirrored port to allow the port to be promiscuosly in
the internal and external network, i.e. for packet capturing).
9. VLAN configuration:
create VLAN (unique ID and custom name)
bind the interface to the VLAN (VLAN is transparent to the VM as
tags are assigned for inbound traffic and removed by the swith
before transmission to VM)
1. Virtual Disks: do have limits in term of number of drives or capacity
(i.e. with thin provisioning more drive space can be allocated than is
available) and number of devices vary by vendor or by design (SCSI
60-256 / ATA max 4).
2. Virtual Storage Area Network (VSAN): allow for privatized a single SAN
implementation or merge separate SAN implementations.
Open Points:
VLAN vs Subnet (even on the same switch)
Is file backup really VM file backup
VSAN