Wikipedia defines cloud computing as:

The National Institute of Standards and Technology (NIST) gives the following definition of cloud computing:

There are several other broadly accepted definitions of cloud computing. Some explicitly emphasize configurability of the resources, while others include the need for rapid on-demand provisioning of resources, still others drop the requirement of access via the internet. We define cloud computing as a model that enables the features listed as follows:

• Users should be able to provision and release resources on-demand
• The resources can be scaled up or scaled down, automatically, depending on the load
• The provisioned resources should be accessible over a network
• Cloud service providers should enable a pay-as-you-go model where customers are charged, based on the type and quantum of resources they consume

Some of the implications of choosing to use the cloud for your computing needs are:

• The illusion of infinite processing and storage resources available on demand reduce the need for detailed advance planning and procurement processes.
• The model promotes the use of resources as per customer needs, for example, starting small, and then increasing resources based on an increase in need.
• Provisioning development and test environments on a smaller scale, and enabling them only during working hours to reduce the cost of development.
• The staging environment can be provisioned for a short duration to be a replica of the production environment. This enables testing using production configuration (and scale) and for improved production defect resolution.
• The ability to auto scale in order to better manage spikes in demand and variations due to business cycles or time-of-day reasons, and so on.
• It encourages experimentation by trying out new ideas and software by quickly provisioning resources rather than requisition for resources through time consuming and cumbersome processes.

These and other implications of using cloud services to design scalable, highly available and secure applications are discussed in depth in the subsequent chapters.

Basically, there are three types of clouds in cloud computing, they are public, private and hybrid clouds.

In a public cloud, third-party service providers make resources and services available to their customers via the internet. The customers' applications and data are deployed on infrastructure that is owned and secured by the service provider.

A private cloud provides many of the same benefits of a public cloud but the services and data are managed by the organization, or a third-party, solely, for the customer's organization. Usually, a private cloud places increased administrative overheads on the customer but gives greater control over the infrastructure and reduces security-related concerns. The infrastructure may be located on or off the organization’s premises.

A hybrid cloud is a combination of both a private and a public cloud. The decision on what runs on the private versus the public cloud is usually based on business criticality of the application and sensitivity of the data. But in some cases, spikes in demand for resources, or spillovers, in the private cloud are also handled in the public cloud.

There are three cloud-based service models. The main features of each of these are listed as follows:

• IaaS provides a capability for users to provision processing, storage, and network resources on demand. The customers deploy and run their own applications on these resources. Using this service model is closest to the traditional in-premise models but without the lengthy procurement processes. The onus of administering these resources rests, largely, with the customer.
• In PaaS, the service provider makes certain core components such as databases, queues, workflow engines, email, and so on, available as services to the customer. The customer then leverages these components for building their own applications. The service provider ensures high service levels, and is responsible for scalability, high availability, and so on, for these components. This allows customers to focus a lot more on their application functionality. However, this model also leads to application-level dependency on the providers' services.
• In the SaaS model, typically, third-party providers using a subscription model provide end user applications to their customers. The customers may have some administrative capability at the application level, for example, to create and manage their users. Such applications also provide some degree of customizability, for example, the customers can use their own corporate logos, colors, and so on. Applications that have a very wide user base most often operate in a self-service mode. In contrast, the provider provisions the infrastructure and the application for the customer for more specialized applications. The provider also hands over the management of the application to the customer's application administrator (in most cases this is limited to user management tasks).

From an infrastructure perspective, the customer does not manage or control the underlying cloud infrastructure in all three service models.

The following figure illustrates who is responsible for managing the various components of a typical user application across IaaS, PaaS, and SaaS cloud service models. The shaded boxes represent the service-providers' responsibilities, while the other boxes represent the users' or end customers' responsibilities.

The level of control the user has over operating systems, storage, applications, and certain network components (for example, load balancers) is the highest in the IaaS model while the least (or none) in the SaaS model.

Multi-tenancy and multi-tenant architecture come up, repeatedly, especially in the context of cloud product design and architecture discussions. Given that most SaaS products are offered as a subscription, it is vital to understand this concept clearly as it can often be the difference between having a highly profitable and an easy-to-manage product, and a failed product or venture.

Multi-tenancy is a principle in software architecture where a single instance of the software serves multiple tenants or customers. The realization of this concept in software design is probably one of more complex tasks in implementing and operating a cloud-based product.

Let's start by examining three basic models of a multi-tenant application. The following figure illustrates these models:

In the first model, (A) Shared Nothing architecture, each customer has a separate copy of the application and the database for their exclusive use. In some cases, the hardware infrastructure is also separated out for each customer. Large enterprises may insist on this separation mainly due to security concerns but also due to service-level concerns associated with resource sharing. This is essentially application hosting rather than application multi-tenancy.

The second model, (B) Shared Application architecture, shares the same application instance but the data is separated for each customer. And in the third model, (C) Shared Everything architecture, both the application and the database instances are shared resources among all the customers.

In real life, it is fairly common for customers to request a dedicated application and infrastructure stack. Most smaller companies and start-ups give in under pressure, especially if it is a major customer. However, this can be a very expensive option to sustain over a period of time. Before you know it, you are maintaining several different versions of the application and technology stacks, multiple database schema, operational and support-related overheads across a set of customers. This makes application maintenance, QA/testing effort, upgrades/releases, and customer support impossibly complex or expensive or both. You are no longer an SaaS application provider!

It is very common and reasonable to expect a majority of customers to request that their data be kept separated from other customers. It is also common for smaller businesses and price-sensitive customers to not care how and where you store their data, as long as they are satisfied by the security measures you have implemented. In all cases, it is imperative to use encryption for the securing of sensitive data-at-rest.

Hence, in reality you end up with a mix of models where the concern is more focused on data security rather than shared infrastructure or application code (as long as you can provide a certain level of application customizability per customer and meet their service-level requirements).

In this scenario, apart from security considerations (discussed in a later chapter) some of the challenges that arise are listed as follows:

• Increased costs of development: Isolating each customer's data in a separate database is easier and faster to build, while using a shared approach requires a larger development effort and initial costs, but can result in being able to serve more tenants per server at a lower overall operational cost.
• Isolating each tenant's database can give you more flexibility in handling each customer's individual requirements (but there could be severe complications when you release product upgrades, especially if your database schema is not designed to handle such changes).
• Regulatory considerations can directly impact your design and leave you with no choice in terms of using a shared approach.
• Backups and restores are simpler operations in the case of isolated databases. In the shared database approach, the impact of servicing a particular tenant's backup or restore request will impact other active customers. These kinds of issues can lead to SLA-related issues and other management overheads related to explaining and issuing appropriate communications to all other customers, and so on.

Normally, businesses charge their customers differently based on whether a customer requests a separate database instance, or a fully segregated infrastructure for their exclusive use only. Suppose you have grouped your customers into three categories such as Platinum, Gold, and Silver. Your Platinum class customers are your biggest and the best. They are willing to pay a premium for additional features and/or better service levels. Let's say, you decide to provision separate infrastructure and database instances, for such customers. Simultaneously, you decide to share the infrastructure and use a single database instance for all your regular, or Silver class, customers. Imagine the operational complexity of a situation where one of your Platinum class customers (Shared Nothing) wants to downgrade their subscription level to the Silver class (Shared Everything) the following year!