Understanding

Services and
Applications by Type

T
his chapter describes some of the different types of cloud computing models, categorized as a set of service
models. You may think of cloud computing applications as being composed of a set of layers upon which
distributed applications may be built or hosted. These layers include Infrastructure, Platform, and Software.
Depending on the type and level of service being offered, a client can build on these layers to create cloud-
based applications.

The service models described here—Infrastructure as a Service (IaaS), Software as a Service (SaaS), and Platform as a
Service (PaaS)—are useful in categorizing not only cloud computing capabilities, but specific vendor offerings,
products, and services. Infrastructure as a Service allows for the cre- ation of virtual computing systems or networks.

Software as a Service represents a hosted application that is universally avail- able over the Internet, usually through a
browser. With Software as a Service, the user interacts directly with the hosted software. SaaS may be seen to be an
alternative model to that of shrink-wrapped software and may replace much of the boxed software that we buy today.

Platform as a Service is a cloud computing infrastructure that creates a devel- opment environment upon which
applications may be build. PaaS provides amodel that can be used to create or augment complex applications such as
Customer Relation Management (CRM) or Enterprise Resource Planning (ERP) systems. PaaS offers the benefits of
cloud computing and is often com- ponentized and based on a service-oriented architecture model.

As cloud computing matures, several service types are being introduced and overlaid upon these architectures. The
most fully developed of these service types is Identity as a Service (IDaaS). Identity as a Service provides authenti-
cation and authorization services on distributed networks. Infrastructure and supporting protocols for IDaaS are
described in this chapter. Other service types such as Compliance as a Service (CaaS), provisioning, monitoring,
communications, and many vertical services yet to be fully developed are touched upon in this chapter.

Defining Infrastructure as a Service (IaaS)

You can broadly partition cloud computing into four layers that form a cloud computing ecosys- tem, as
shown in Figure 4.1. The Application layer forms the basis for Software as a Service (SaaS), while the Platform
layer forms the basis for Platform as a Service (PaaS) models that are described in the next two sections.
Infrastructure as a Service (IaaS) creates what may be determined to be a utility computing model, something
that you can tap into and draw from as you need it without significant limits on the scalability of your
deployment. You pay only for what you need when you need it. IaaS may be seen to be an incredibly
disruptive technology, one that can help turn a small business into a large business nearly overnight. This is a
most exciting prospect; one that is fueling a number of IaaS startups during one of the most difficult
recessions of recent memory.

Infrastructure as a Service (IaaS) is a cloud computing service model in which hardware is virtual- ized in the
cloud. In this particular model, the service vendor owns the equipment: servers, stor- age, network
infrastructure, and so forth. The developer creates virtual hardware on which to develop applications and
services. Essentially, an IaaS vendor has created a hardware utility service where the user provisions virtual
resources as required.

FIGURE 4.1
The cloud computing ecosystem

Business Process (SOA)

Application Services

Platform Services

Infrastructure Services

The developer interacts with the IaaS model to create virtual private servers, virtual private storage, virtual
private networks, and so on, and then populates these virtual systems with the applications and services it needs
to complete its solution. In IaaS, the virtualized resources are mapped to real systems. When the client interacts
with an IaaS service and requests resources from the virtual systems, those requests are redirected to the real
servers that do the actual work.

IaaS workloads
The fundamental unit of virtualized client in an IaaS deployment is called a workload. A workload simulates the
ability of a certain type of real or physical server to do an amount of work. The work done can be measured by
the number of Transactions Per Minute (TPM) or a similar metric againsta certain type of system. In addition to
throughput, a workload has certain other attributes such as Disk I/Os measured in Input/Output Per Second
IOPS, the amount of RAM consumed under load in MB, network throughput and latency, and so forth. In a
hosted application environment, a cli- ent’s application runs on a dedicated server inside a server rack or
perhaps as a standalone server in a room full of servers. In cloud computing, a provisioned server called an
instance is reserved by a customer, and the necessary amount of computing resources needed to achieve that
type of physical server is allocated to the client’s needs.
Figure 4.2 shows how three virtual private server instances are partitioned in an IaaS stack. The three
workloads require three different sizes of computers: small, medium, and large.

A client would reserve a machine equivalent required to run each of these workloads. The IaaS infrastructure
runs these server instances in the data center that the service offers, drawing from a pool of virtualized
machines, RAID storage, and network interface capacity. These three layers are expressions of physical systems
that are partitioned as logical units. LUNs, the cloud interconnect layer, and the virtual application software
layer are logical constructs. LUNs are logical storage containers, the cloud interconnect layer is a virtual
network layer that is assigned IP addresses fromthe IaaS network pool, and the virtual application software layer
contains software that runs on the physical VM instance(s) that have been partitioned from physical assets on the
IaaS’ private cloud.

From an architectural standpoint, the client in an IaaS infrastructure is assigned its own private network. The
Amazon Elastic Computer Cloud (EC2) behaves as if each server is its own separate network—unless you
create your own Virtual Private Cloud (an EC2 add-on feature), which provides a workaround to this
problem. When you scale your EC2 deployment, you are adding additional networks to your infrastructure,
which makes it easy to logically scale an EC2 deployment, but imposes additional network overhead
because traffic must be routed between logical networks. Amazon Web Service’s routing limits broadcast
and multicast traffic because Layer-2 (Data Link) networking is not supported. Rackspace Cloud
(http://www.rackspacecloud.com/) follows the AWS IP assignment model.

Other IaaS infrastructures such as the one Cloudscaling.com (http://www.cloudscaling.

com) offers or a traditional VMWare cloud-assigned networks on a per-user basis, which allows forLevel 2
networking options. The most prominent Level 2 protocols that you might use are tunnel- ing options, because
they enable VLANs.
 FIGURE 4.2
A virtual private server partition in an IaaS cloud

Virtual Machine Layer

Logical Unit Number (LUN)

Workload Partition 3
Workload Partition 1

Workload Partition 2

Cloud Layer Interconnection Layer

RAID Layer

Virtual Application Software Layer

Network Interface Layer

Ethernet

Consider a transactional eCommerce system, for which a typical stack contains the following
components:

l Web server
l Application server
l File server
l Database
l Transaction engine

This eCommerce system has several different workloads that are operating: queries against the
database, processing of business logic, and serving up clients’ Web pages.
The classic example of an IaaS service model is Amazon.com’s Amazon Web Services (AWS). AWShas several
data centers in which servers run on top of a virtualization platform (Xen) and may be partitioned into logical
compute units of various sizes. Developers can then apply system images containing different operating systems
and applications or create their own system images. Storage-may be partitions, databases may be created, and a
range of services such a messaging and notifica-tion can be called upon to make distributed application work
correctly.

Pods, aggregation, and silos

Workloads support a certain number of users, at which point you exceed the load that the instance sizing allows.
When you reach the limit of the largest virtual machine instance possible, you must make a copy or clone of the
instance to support additional users. A group of users within a particu- lar instance is called a pod. Pods are
managed by a Cloud Control System (CCS). In AWS, the CCS is the AWS Management Console.

Sizing limitations for pods need to be accounted for if you are building a large cloud-based appli- cation. Pods are
aggregated into pools within an IaaS region or site called an availability zone. In very large cloud computing
networks, when systems fail, they fail on a pod-by-pod basis, and often on a zone-by-zone basis. For AWS’ IaaS
infrastructure, the availability zones are organized around the company’s data centers in Northern California,
Northern Virginia, Ireland, and Singapore. A failover system between zones gives IaaS private clouds a very high
degree of availability. Figure 4.3 shows how pods are aggregated and virtualized in IaaS across zones.

When a cloud computing infrastructure isolates user clouds from each other so the management system is
incapable of interoperating with other private clouds, it creates an information silo, or simply a silo. Most often,
the term silo is applied to PaaS offerings such as Force.com or QuickBase, but silos often are an expression of the
manner in which a cloud computing infrastructure is archi- tected. Silos are the cloud computing equivalent of
compute islands: They are processing domains that are sealed off from the outside.

When you create a private virtual network within an IaaS framework, the chances are high that you are creating
a silo. Silos impose restrictions on interoperability that runs counter to the open nature of build-componentized
service-oriented applications. However, that is not always a bad thing. A silo can be its own ecosystem; it can
be protected and secured in ways that an open sys-tem can’t be. Silos just aren’t as flexible as open systems and
are subject to vendor lock-in.
 FIGURE 4.3
Pods, aggregation, and failover in IaaS
Pod

Cloud Control System Workloads

Zone 1 Zone 2 Zone 3 Zone 4

Pod 1 Pod 2 Pod 2 Pod 3 Pod 4 Pod 5 Pod 6 Pod 1

Failover Command

Pod 1 Failover Pod 1 Failover

Defining Platform as a Service (PaaS)

The Platform as a Service model describes a software environment in which a developer can create
customized solutions within the context of the development tools that the platform provides.
Platforms can be based on specific types of development languages, application frameworks, or other
constructs. A PaaS offering provides the tools and development environment to deploy appli- cations on
another vendor’s application. Often a PaaS tool is a fully integrated development envi- ronment; that is, all
the tools and services are part of the PaaS service. To be useful as a cloud computing offering, PaaS
systems must offer a way to create user interfaces, and thus support stan- dards such as HTLM, JavaScript,
or other rich media technologies.

In a PaaS model, customers may interact with the software to enter and retrieve data, perform actions, get
results, and to the degree that the vendor allows it, customize the platform involved. The customer takes
no responsibility for maintaining the hardware, the software, or the develop- ment of the applications and
is responsible only for his interaction with the platform. The vendor is responsible for all the operational
aspects of the service, for maintenance, and for managing theproduct(s) lifecycle.

The one example that is most quoted as a PaaS offering is Google’s App Engine platform, Developers
program against the App Engine using Google’s published APIs. The tools for working within the
development framework, as well as the structure of the file system and data stores, are defined by Google.
Another example of a PaaS offering is Force.com, Salesforce.com’s developer platform for its SaaS
offerings, described in the next section.Force.com is an example of an add-on development environment.

A developer might write an application in a programming language like Python using the Google API. The
vendor of the PaaS solution is in most cases the developer, who is offering a complete solution to the
customer. Google itself also serves as a PaaS vendor within this system, because it offers many of its Web
service applications to customers as part of this service model. You can think of Google Maps, Google Earth,
Gmail, and the myriad of other PaaS offerings as conforming to the PaaS service model, although these
applications themselves are offered to customers under what is more aptly described as the Software as a
Service (SaaS) model that is described below.

The difficulty with PaaS is that it locks the developer (and the customer) into a solution that is dependent
upon the platform vendor. An application written in Python against Google’s API using the Google App
Engine is likely to work only in that environment. There is considerable vendor lock-in associated with a
PaaS solution.

Defining Software as a Service (SaaS)

The most complete cloud computing service model is one in which the computing hardware and software, as
well as the solution itself, are provided by a vendor as a complete service offering. It is referred to as the
Software as a Service (SaaS) model. SaaS provides the complete infrastructure, software, and solution stack
as the service offering. A good way to think about SaaS is that it is the cloud-based equivalent of shrink-
wrapped software.

Software as a Service (SaaS) may be succinctly described as software that is deployed on a hosted service and
can be accessed globally over the Internet, most often in a browser. With the exception of the user interaction
with the software, all other aspects of the service are abstracted away.

Every computer user is familiar with SaaS systems, which are either replacements or substitutes for locally
installed software. Examples of SaaS software for end-users are Google Gmail and Calendar, QuickBooks
online, Zoho Office Suite, and others that are equally well known. SaaS applications come in all shapes and
sizes, and include custom software such as billing and invoicing systems, Customer Relationship
Management (CRM) applications, Help Desk applications, Human Resource (HR) solutions, as well as
myriad online versions of familiar applications.

Many people believe that SaaS software is not customizable, and in many SaaS applications this is indeed the
case. For user-centric applications such as an office suite, that is mostly true; those suites allow you to set only
options or preferences. However, many other SaaS solutions expose Application Programming Interfaces
(API) to developers to allow them to create custom composite applications. These APIs may alter the security
model used, the data schema, workflow characteris- tics, and other fundamental features of the service’s
expression as experienced by the user. Examples of an SaaS platformwith an exposed API are Salesforce.com
and Quicken.com. So SaaSdoes not necessarily mean that the software is static or monolithic.
SaaS characteristics
All Software as a Service (SaaS) applications share the following characteristics:

1. The software is available over the Internet globally through a browser on demand.
2. The software and the service are monitored and maintained by the vendor, regardless of
where all the different software components are running.
There may be executable client-side code, but the user isn’t responsible for maintaining
that code or its interaction with the service.
3. Reduced distribution and maintenance costs and minimal end-user system costs generally
make SaaS applications cheaper to use than their shrink-wrapped versions.
4. Such applications feature automated upgrades, updates, and patch management and
much faster rollout of changes.
5. SaaS applications often have a much lower barrier to entry than their locally installed
competitors, a known recurring cost, and they scale on demand (a property of cloud
computing in general).
6. All users have the same version of the software so each user’s software is compatible with
another’s.
7. SaaS supports multiple users and provides a shared data model through a single-instance,
multi-tenancy model.
The alternative of software virtualization of individual instances also exists, but is
less common.