For some time now, the generally agreed upon classifi cation scheme for cloud computing has been coined the Software-Platform-Infrastructure (SPI) model. This acronym represents the three major services provided through the cloud: SaaS, or Software as a Service; PaaS, Platform as a Service; and IaaS, Infrastructure as a Service.
Although there are a few other concepts circulating that suggest variations on this schema (we’ll address some of these in the section “Alternative Deployment Models”), the SPI framework for cloud computing is currently the most widely accepted cloud computing classifi cation. NIST follows this framework, and most CSPs (cloud service providers) support this concept.
SPI Evolution
To understand how the SPI framework evolved, perhaps it’s helpful to place it in context with the development of Internet Service Providers (ISPs). A com- mon way to look at how ISPs developed is through generational versions, as described in the following simplifi ed list:
1.0 — As ISPs originally began to provide Internet services, dial-up modem service for homes and organizations proliferated, making the Internet a com- mercial commodity.
2.0 — During a period of merging and consolidation, ISPs began offering other services, such as e-mail and off-site data storage.
3.0 — The increasing demand for infrastructure to host their customers’
applications and data led to the creation of data centers known as collocation facilities, where multiple customers could centralize their servers, storage, and communications systems on the ISP’s premises.
4.0 — The commoditization of collocation facilities led to the development of application service providers (ASPs). ASPs provided software applications tailored to an organization, owning both the application and the infrastructure.
c02.indd 34
c02.indd 34 6/24/2010 7:38:56 AM6/24/2010 7:38:56 AM
5.0 — The ASP model eventually evolved into cloud computing, which brought new delivery models, such as the SPI framework, with its SaaS, PaaS, and IaaS service models, and various deployment models, such as private, community, public, and hybrid cloud models.
To better visualize this progression, Figure 2-1 shows data center evolution through basic virtualization into a full SPI framework, thereby increasing fl ex- ibility and lowering costs.
Figure 2-1: SPI evolution through virtualization Flexibility,
Higher value, Lower cost
Physical/Legacy Virtualization 1.0 Virtualization 2.0/Cloud Cloud
Infrastructure as a Service, Platform as a Service, Software as a Service
LEGACY
Datacenter, Hardware, and Server oriented
Virtualization
Servers, Applications, and Desktops
The SPI Framework vs. the Traditional IT Model
Although a lot of cloud computing infrastructure is based on existing technology, there are many differences between the SPI framework and the traditional IT model.
For instance, a traditional enterprise-wide application rollout requires resources and coordination from many parts of the organization. This rollout may require numerous new hardware (servers, perimeter network devices, workstations, backup systems), operating systems, communication link provisioning, and user and management training, for example.
One advantage of the traditional model is that software applications are more customizable, but even this advantage often comes at a high cost in resources and effort.
In the traditional IT model, software applications may require substantial licensing and support costs. These licensing costs may be based on formulae that don’t translate well to the actual intended use of the application, such as hardware requirements (number of servers, processors, communication links) or other company characteristics unrelated to the original intent of the application (total number of employees in the organization, total number of remote offi ces, etc.).
c02.indd 35
c02.indd 35 6/24/2010 7:38:56 AM6/24/2010 7:38:56 AM
In addition, changes in the original licensing structure due to usage increases (additional per-seat needs) may create substantial costs down the line, such as additional hardware, support SLAs, and IT resources.
In the traditional IT model, security is often owned “in-house,” with security professionals and supporting security infrastructure (fi rewalls, intrusion detec- tion/prevention systems, e-mail and web monitoring systems, etc.) under the direct control of the organization. This may make it easier to provide regula- tory compliance for auditing purposes using the traditional model. However, the drawback of this security ownership is the infrastructure overhead, which requires considerable resources of manpower to secure properly.
Typically, organizations employing the SPI framework don’t own the infra- structure that hosts the software application. They instead license application usage from the cloud provider, by employing either a subscription-based license or a consumption-oriented model. This enables companies to pay for only the resources they need and use, and to avoid paying for resources they don’t need, thus helping them avoid a large capital expenditure for infrastructure.
The cloud service provider that delivers some or all of the SPI elements to the organization can also share infrastructure between multiple clients. This helps improve utilization rates dramatically by eliminating a lot of wasted server idle time. Also, the shared use of very high-speed bandwidth distributes costs, enables easier peak load management, often improves response times, and increases the pace of application development.
Another benefi t of adopting the SPI framework for organizational comput- ing is reduced startup costs. Eliminating the resource requirements mentioned above lowers the barrier to entry, and in many cases provides an organization much quicker access to computing power and software development than the traditional IT model did. Table 2-1 shows the three primary SPI framework ser- vices, paired with an example of the service the vendor supplies for that layer.
Table 2-1: SPI Services Delivery Vendors SPI FRAMEWORK
SERVICE DESCRIPTION VENDOR EXAMPLE
IaaS Shared Internet infrastruc- ture, such as servers and storage
Amazon EC2 and S3, Sun Microsystems Cloud Services, Terremark, Dropbox
PaaS Application platform that
provides developers with quick deployment
Google App Engine, force .com (from salesforce.com), Microsoft Azure
SaaS Stateless cloud-enabled
multiple-instance applica- tions on a pay-per-use pricing model
Zoho Suite, Apple’s MobileMe, Google Docs
c02.indd 36
c02.indd 36 6/24/2010 7:38:56 AM6/24/2010 7:38:56 AM
The following sections take a closer look at these three primary cloud delivery models.
SECURITY VS. EXTENSIBILITY
According to the Cloud Security Alliance (see www.cloudsecurityalliance .org/guidance/csaguide.pdf), it’s important to continually “be aware of the trade-offs between extensibility (openness) and security responsibility within the three Cloud Service Delivery Models:
SaaS (Software as a Service) — Least extensibility and greatest amount of security responsibility taken on by the cloud provider
IaaS (Infrastructure as a Service) — Greatest extensibility and least amount of security responsibility taken on by the cloud provider
PaaS (Platform as a Service) — Lies somewhere in the middle, with extensibility and security features that must be leveraged by the customer.”