Service Models

In addition to the three service models defined by NIST (SaaS, PaaS, and IaaS), CompTIA also adds Desktop as a Service (DaaS) to the mix. In the sections that follow, we walk through each of the four models and compare the key elements of each.

Software as a Service

According to the NIST, Software as a Service (SaaS) is defined as follows: “The capability provided to the consumer is to use the provider’s applications running on a cloud infrastructure. The applications are accessible from various client devices through either a thin client interface, such as a web browser (for example, web-based email), or a program interface. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.”

The words used are significant and the ones to focus on in this definition are that consumers can use the provider’s applications and that they do not manage or control any of the underlying cloud infrastructure. Figure 7.1 depicts the responsibility of each party in the SaaS model.

Platform as a Service

According to the NIST, Platform as a Service (PaaS) is defined as follows: “The capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages, libraries, services and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage, but has control over the deployed applications and possible configuration settings for the application-hosting environment.”

The important words to focus on in this definition are that consumers can deploy, that they do not manage or control any of the underlying cloud infrastructure, but they can have control over the deployed applications. Figure 7.2 depicts the responsibility of each party in the PaaS model.

Infrastructure as a Service

According to the NIST, Infrastructure as a Service (IaaS) is defined as follows: “The capability provided to the consumer is to provision processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, and deployed applications; and possible limited control of select networking components (e.g., host firewalls).”

The words to focus on are that the consumer can provision, is able to deploy and run, but still does not manage or control the underlying cloud infrastructure, but now can be responsible for some aspects. Figure 7.3 depicts the responsibility of each party in the IaaS model.

Desktop as a Service

IaaS, PaaS, and SaaS are the most popular models in use today, but virtually anything can have “aaS” tacked to the end of it and its subscription referenced “as a Service.” Desktop as a Service (DaaS) is an implementation of desktop virtualization that does not require you to build and manage your own infrastructure. It is important to note that this is a business model and not one of the three recognized service models by NIST. Other similar business models, as opposed to service models, include Communication as a Service (CaaS)—outsourced communications leased from a vendor(s) such as voice over IP (VoIP), videoconferencing apps, and Everything as a Service (XaaS).

After you have a service model selected, both CompTIA and NIST recognize the different delivery models, which are discussed next.

Deployment Models

Cloud deployment can be done in various ways. It is possible to isolate the cloud (a private model), make it widely available (a public model), or do something in between (a community model or hybrid model). In the discussion that follows, we look at deployment models and move into discussing cloud-based features.

Private Cloud

A private cloud is defined as follows: “The cloud infrastructure is provisioned for exclusive use by a single organization comprising multiple consumers (e.g., business units). It may be owned, managed, and operated by the organization, a third party, or some combination of them, and it may exist on or off premises.”

Under most circumstances, a private cloud is owned by the organization, and it acts as both the provider and the consumer. It has a security-related advantage in not needing to put its data on the Internet.

Public Cloud

A public cloud is defined as follows: “The cloud infrastructure is provisioned for open use by the general public. It may be owned, managed, and operated by a business, academic, or government organization, or some combination of them. It exists on the premises of the cloud provider.”

Under most circumstances, a public cloud is owned by the cloud provider, and it uses a pay-as-you-go model. A good example of a public cloud is webmail or online document sharing/collaboration.

Hybrid and Community Clouds

A hybrid cloud is defined as follows: “The cloud infrastructure is a composition of two or more distinct cloud infrastructures (private, community, or public) that remain unique entities, but are bound together by standardized or proprietary technology that enables data and application portability (e.g., cloud bursting for load balancing between clouds).”

A hybrid can be any combination of other delivery models. Not only are public and private listed in the definition, but also community. A community cloud is defined as follows: “The cloud infrastructure is provisioned for exclusive use by a specific community of consumers from organizations that have shared concerns (e.g., mission, security requirements, policy, and compliance considerations). It may be owned, managed, and operated by one or more of the organizations in the community, a third party, or some combination of them, and it may exist on or off premises.”

For real-world purposes, you should know that the key to distinguishing between a community cloud and other types of cloud delivery is that it serves a similar group. There must be joint interests and limited enrollment.

Infrastructure as Code

Infrastructure as Code (IaC) involves using virtual machines and bare-metal servers to provision and manage data centers via machine-readable definition files (as opposed to physical hardware configuration). Those definitions are within a version control system and can either use scripts or declarative definitions. The two methods are known as push and pull: with the pull method, the server pulls its configuration from the controlling server, while the controlling server with the push method “pushes” the configuration to the destination.

With infrastructure automation, faster execution is possible as is increased visibility that can help other teams across the enterprise work quickly and more efficiently. The automation removes risks that can come from human error, thus decreasing downtime and increasing reliability. These outcomes can help the enterprise implement a DevOps culture combining development and operations. Complementing this, orchestration allows IaC to be arranged or coordinated across multiple systems: allowing a distributed application, or a set of services, to span multiple machines.

Connectivity Options

Most cloud providers offer a number of methods that clients can employ to connect to them. It is important, before making an investment in infrastructure, to check with your provider and see what methods it recommends and supports. One of the most common is to use an IPSec, hardware virtual private network (VPN) connection between your network(s) and the cloud provider. This method offers the capability to have a managed VPN endpoint that includes automated multidata center redundancy and failover.

A dedicated direct connection, known as a private-direct connection, is another, simpler, method. You can combine the dedicated network connection(s) with the hardware VPN to create a combination that offers an IPSec-encrypted private connection while also reducing network costs.

Amazon Web Services (AWS) is one of the most popular cloud providers on the market. It allows the two connectivity methods discussed (calling the dedicated connection “AWS Direct Connect”) and a number of others that are variations, or combinations, of these two.

Multitenancy

One of the ways cloud computing is able to obtain cost efficiencies is by putting data from various clients on the same machines. This “multitenant” nature, known as multitenancy, means that workloads from different clients can be on the same system, and a flaw in implementation could compromise security. In theory, a security incident could originate with another customer at the cloud provider and bleed over into your data. Therefore, data needs to be protected from other cloud consumers and from the cloud provider as well.

Elasticity

According to NIST, one of the five essential characteristics of the cloud is not just elasticity, but rapid elasticity. This characteristic is defined as follows: “Capabilities can be elastically provisioned and released, in some cases automatically, to scale rapidly outward and inward commensurate with demand. To the consumer, the capabilities available for provisioning often appear to be unlimited and can be appropriated in any quantity at any time.” The key words to focus on in this definition are provisioned and released, scale, and appear to be unlimited.

Scalability

Another feature that makes cloud computing valuable is scalability. According to NIST, “Performance can potentially be scaled to meet conditions of anticipated or real-world demand, within the parameters of a cloud service agreement.” To be able to scale, elasticity is required, and autonomic autoscaling of resources is critical.

Security Implications

Security is one of the most important issues to discuss with your cloud provider. Cloud computing holds great promise when it comes to scalability, cost savings, rapid deployment, and empowerment. As with any technology where so much is removed from your control, though, risks are involved. Each risk should be considered carefully to identify ways to help mitigate it. Naturally, the responsibilities of both the organization and the cloud provider vary depending on the service model chosen, but ultimately the organization is accountable for the security and privacy of the outsourced service.

Software and services not necessary for the implementation should be removed or at least disabled. Patches and firmware updates should be kept current, and log files should be carefully monitored. You should find the vulnerabilities in the implementation before others do and work with your service provider(s) to close any holes.

When it comes to data storage on the cloud, encryption is one of the best ways to protect it (keeping it from being of value to unauthorized parties), and VPN routing and forwarding can help. Backups should be performed regularly (and encrypted and stored in safe locations), and access control should be a priority.

The Relationship Between Resources

Just as the cloud holds such promise for running applications, balancing loads, and a plethora of other options, it also offers the capability to store more and more data on it and to let a provider worry about scaling issues instead of local administrators. From an economic perspective, this can be a blessing. From an administrative point of view, though, it can present some issues. Redundancy that occurs from having data in more than one location (local and remote) can be wonderful when you need to recover data, but problematic when you want to make sure you are always working with the most recent version. To minimize problems, be sure that files are kept current, and synchronization between local and remote files is always running.