Understanding Cloud Characteristics - Deploying and Managing a Cloud Infrastructure - page 12

on top of its cloud instance. This is one level above the VM segregation we just talked about.
Multitenant clouds usually offer units of resources that “look like” actual physical units but
are actually a portion of the actual physical resource. For example, AWS offers instances
that specify the number of cores you will get but not the type of CPU. The Amazon Elastic
Compute Cloud (EC2) micro instance has an older-generation Xeon-based server, but
Amazon does not offer the actual Xeon CPU as a unit of resource. Rather, it offers x number
of cores as the billable compute unit because the virtualization layer running on top of the
actual physical resource partitions the CPU into a given number of virtual machines, each of
which will have access to the same CPU but not be able to share the same compute load. The
same happens with network and storage. Your application's backend database may reside on
the same physical storage as your competitor's, but the data cannot seep through and cross the
boundaries set by the VM.
Having said this, not all clouds are multitenant. Let's take a quick look at the much smaller
niche segment, single-tenant clouds, and some of the aspects that need to be properly analyzed
when adopting either a single-tenant or multitenant cloud configuration.
Single-Tenant Cloud
With a single-tenant cloud, every tenant has physical and not virtual boundaries around
the allocated resource pool. This is common in bare metal cloud offerings where the vendor
guarantees physical resource allocation for a tenant and commits to not packing multiple
users on the same pool of physical resources. Offering single tenancy within a bare metal
cloud offering is relatively easier than offering single tenancy or physical segregation within
a virtualized cloud offering.
In a virtualized cloud, single tenancy may be implemented by ensuring that a tenant's
VMs cannot be packed with another tenant's VMs. To get a fair understanding, consider
this example: Your application awesome-app.com has spun 20 VMs, or EC2 instances on
the Amazon cloud. If the physical server on top of which your EC2 instance is running can
pack in 6 VMs in a single server, that would mean your instances would be distributed
among at least 4 physical servers. Now, one of those servers would still have the capacity
to pack in 4 more VMs after your last 2 VMs are packed into it. Because Amazon does not
offer or guarantee single tenancy, this would mean that the virtualization layer can pick
any other 4 VMs from another tenant or multiple tenants and pack them into the same
physical server where your VMs are running.
Cost Optimization
In the preceding example, consider that Amazon did offer single tenancy; that would mean
that the last physical server would have only 2 VMs running on it while it has the capacity
of 6. The virtualization layer may intelligently expand the allocated resources of those last 2
instances to span and utilize the complete compute, storage, and network resources available
on that physical server. But if this does not happen, Amazon would have idle resource pack-
ets sitting around in its data centers and this would lead to lost revenue. Therefore, single
tenancy would incur more operational costs and reduced revenue because the available
resources are not completely utilized.