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!

In this section, we will discuss various workloads being deployed on the cloud. These could be in-premise systems moved to the cloud, on-premise product versions replaced by cloud-based offerings, and new applications being developed for cloud-only environments.

There are several reasons for organizations wanting to migrate their applications to the cloud. These reasons typically include driving cost efficiency, improving productivity, supporting faster go-to-market strategies, achieving better operational efficiency, and others. Additionally, there are also several different strategies employed to move a portfolio of applications to the cloud.

One of the most commonly used approaches is the lift-and-shift, or rehosting, existing applications in the cloud. This approach can lead to some cost savings, especially if the infrastructure is right-sized and expensive commercial licenses of proprietary products replaced with cloud-based services (from the cloud service provider or third-party service providers) or using equivalent open-source products.

This approach is very popular compared to other approaches as it can be quicker to implement, and some benefits may be realized right away. However, design limitations and application inefficiencies in the existing in-premise application also get migrated to the cloud along with the application. Typically, steady-state applications that are service-oriented, loosely coupled, and with minimal inter dependencies with other applications are the best candidates for using this approach.

A rehosting strategy can lead to disappointments when a changeover to a cloud environment does not yield the expected levels of cost savings or a simpler operating environment. This may be because the full benefits of the cloud are fully realized only when cloud-native designs are implemented for various parts of the architecture. However, resizing infrastructure as per application requirements or replatforming the application to use cloud services or open-source products will definitely lead to increased cost advantages but also take longer to implement.

Most times, subscribing to a product's cloud-based offering or shifting to another equivalent or better cloud product can prove to be an advantageous strategy. For example, shifting to cloud-based offerings of SAP or shifting over to Salesforce for CRM functionality is increasingly becoming a favored strategy in many organizations. Finally, for some systems, it is best to re-factor and/or re-architect the application for deriving the maximum benefits of a migration to the cloud. Whatever the reasons and the strategy for migrating systems to the cloud, it needs to be a well-planned exercise that includes infrastructure, application, and data migration, with significant verification and validation effort at each step in the process.

Typically, migration projects start with an analysis of the existing portfolio of applications to figure out the sequence and strategy for each system to be migrated. Additionally, the speed of such projects picks up as a result of increased exposure to the cloud environment based on the initial set of migrations. The overall strategy in many cases is a mass lift-and-shift followed by iterative improvements introduced in the application architecture over a period of time. Sometimes these migrations are timed to avoid expensive lease and license renewals, and/or hardware refreshes. The portfolio analysis exercise often consolidates and/or rationalizes the hardware and software stacks used in an organization, identifies applications that can be retired at specific points along the journey, and other applications that will never be migrated due to regulatory or other concerns.

Cloud-native applications are specifically designed and implemented to operate in cloud-only environments. The nature of the application, infrastructure requirements, and data volumes can significantly influence the decision to use the cloud. Smaller organizations and startups often use the cloud for all their infrastructure and software/applications needs. Many such organizations also offer their products on a subscription-based licensing model to their customers (SaaS model).

Applications having wide variability in their usage patterns are great candidates for the cloud. The infrastructure costs in such cases can be reduced significantly by scaling up resources to match the increased demand, and scaling down subsequently to serve lighter loads. Similarly, it is common to scale up for a specific task, such as training a machine learning model (at certain intervals) instead of maintaining high capacity infrastructure, continuously. Specialized workloads requiring high memory, short bursts of high-compute server usage, GPUs, and so on, can leverage the ability to provision resources on demand (as per the requirements). For example, running large-scale deep learning workloads typically require GPU-based instances for quicker turnaround times. These server instances can be spun up and used, only when they are actually required.

Both streaming applications with incoming data at very high velocities and batch systems with very high data volumes, can benefit from easy availability and scalability of cloud resources. Additionally, applications using unstructured data such as vast document corpuses, image repositories, and audio and video libraries, can leverage the storage and processing power available on-tap in the cloud. The variety and number of ready-to-use cloud services that are available (via simple APIs) to developers, allows them to build applications without having to worry about the complexities of the underlying service.

We would like to conclude our introduction to cloud computing by getting you started on AWS, right away. The next section will help you set up your AWS account and familiarize you with the AWS management console.

You will need to create an account on Amazon before you can use the Amazon Web Services (AWS). Amazon provides a 12-month limited fully functional free account which can be used to learn the different components of AWS. With this account, you get access to many services provided by AWS but there are some limitations based on resources consumed. The list of AWS services is available at http://aws.amazon.com/free.

We are assuming that you do not have a pre-existing AWS account with Amazon (in case you do then please feel free to skip this section).

1. Point your browser to http://aws.amazon.com/free and click on Create a Free Account.

2. Click on Create a new AWS account, as shown:

3. Enter your email address, select I am a new user option, and then click on Sign-in using our secure server button:

4. A series of intuitive screens shown, as follows, will guide you easily through the process of creating an AWS account. Provide your name, email address, and a password in the form. Click on the Create account button to proceed to the next step:

5. Provide the Contact Information details as requested in the form shown here. Select Personal Account for your initial learning purposes. Amazon uses this information for billing and invoicing:

6. Provide Payment Information in the form as shown in the following screenshot. When you create an AWS account and sign up for services, you are required to enter the payment information. Amazon will execute a $1 transaction against the card to confirm its validity:

7. Next, Amazon executes an identity verification step. It includes a call back via an automated system to verify your telephone number. You will also need to enter a four digit PIN (displayed on your screen) when prompted. After the verification process is completed, click on Continue to select your Support Plan button:

8. Select your Support Plan: You can subscribe to one of: Basic, Developer, Business, or Enterprise plans. We recommend subscribing to the Basic plan at this stage. The Basic plan costs nothing but is also limited. You should one of the other plans for production accounts. However, the Basic plan is an acceptable option for learning purposes. Click on Continue to proceed to the next step:

9. At Confirmation stage, you have completed all the steps requiring your input for setting up an AWS account (see all the steps checked at the top of your screen as shown). Click on Launch Management Console:

10. At this stage, you have successfully created an AWS account, and you are ready to start using the services offered by Amazon Web Services. On clicking Sign-in to the Console button, you will be requested to log in:

The AWS management console is the central location from where you can access all Amazon services. The management console has links to the following:

• The home screen of the console is shown as follows:

• Click on All services to expand the display. This view lists all the AWS services available in a specific Amazon region. Clicking on any one of these launches the dashboard for the selected service:

• Shortcuts for Amazon Web Services: On the console management screen you can create shortcuts of frequently accessed services by clicking on the pin (located after the Services and the Resource Groups links) in the title bar. We can drag and drop the services from the list to the title bar to add it:

• The modified title bar after adding EC2, S3, RDS and VPC components to it is as shown:

• Account-related information: This allows you to access your account-related data. It includes security credentials needed to access the AWS resources, and the My Billing Dashboard option gives you real-time information on your current month’s billing:

• Amazon regions: This option allows you to access the Amazon Web Services in a specific region. For example, the list of Amazon Web Services, shown earlier, were for the Asia Pacific (Mumbai) region:

• Help: Click on the Support menu (located on the title bar) to access help-related items. You can navigate to help, forums and support pages:

• Services: Click on the Services menu (located on the title bar) to access specific dashboards. For example, click the EC2 menu item to open the EC2 Dashboard:

• EC2 Dashboard: Shows the summary of EC2 resources and service health information for the region and associated Availability Zones. You can also launch a new EC2 instance from here:

In this chapter, we introduced you to a few cloud computing concepts and terminologies. We described the basic features of public, private, and hybrid clouds. We introduced the main cloud delivery models, namely, IaaS, PaaS, and SaaS. We described various multi-tenancy models, and some of their main implications and challenges. We also described typical cloud-based workloads including both traditional in-premise systems and new generation applications built for cloud-only environments. Finally, we listed the steps for creating your AWS account and described the salient features of the AWS management console.

With the basics out of the way, in Chapter 2, Designing Cloud Applications – an Architect’s Perspective, we will describe some familiar and not-so familiar architectural best practices in the cloud context. We will deep dive into the technical details of how multi-tenanted cloud applications are different from traditional multi-tiered applications. We will also walk you through creating a sample application (using Spring and MySQL) that will be used to illustrate key cloud-application design concepts through the rest of this book.