Notes

Study of NIST model in Cloud Computing
AIM:
To study and learn about NIST model in Cloud Computing.
Theory:
Cloud Computing
Cloud Computing provides us means of accessing the applications as utilities over the
Internet. It allows us to create, configure, and customize the applications online.
What is Cloud?
The term Cloud refers to a Network or Internet. In other words, we can say that Cloud
is something, which is present at remote location. Cloud can provide services over public and
private networks, i.e., WAN, LAN or VPN.
Applications such as e-mail, web conferencing, customer relationship management
(CRM) execute on cloud.
What is Cloud Computing?
Cloud Computing refers to manipulating, configuring, and accessing the hardware and
software resources remotely. It offers online data storage, infrastructure, and application.
Cloud computing offers platform independency, as the software is not required to be
installed locally on the PC. Hence, the Cloud Computing is making our business
applications mobile and collaborative.
History of Cloud Computing
The concept of Cloud Computing came into existence in the year 1950 with
implementation of mainframe computers, accessible via thin/static clients. Since then, cloud
computing has been evolved from static clients to dynamic ones and from software to services.
The following diagram explains the evolution of cloud computing.
NIST
The National Institute of Standards and Technology (NIST) developed this document
in furtherance of its statutory responsibilities under the Federal Information Security
Management Act (FISMA) of 2002, Public Law 107-347. NIST is responsible for developing
standards and guidelines, including minimum requirements, for providing adequate information
security for all agency operations and assets; but such standards and guidelines shall not apply
to national security systems.
According to the official NIST definition, "cloud computing is a model for enabling
ubiquitous, convenient, on-demand network access to a shared pool of configurable computing
resources (e.g., networks, servers, storage, applications and services) that can be rapidly
provisioned and released with minimal management effort or service provider interaction
Purpose and Scope
Cloud computing is an evolving paradigm. The NIST definition characterizes important
aspects of cloud computing and is intended to serve as a means for broad comparisons of cloud
services and deployment strategies, and to provide a baseline for discussion from what is cloud
computing to how to best use cloud computing. The service and deployment models defined
form a simple taxonomy that is not intended to prescribe or constrain any particular method of
deployment, service delivery, or business operation.
NIST Visual Model of Cloud Computing
The NIST definition lists five essential characteristics of cloud computing:
On-demand self-service
A consumer can unilaterally provision computing capabilities, such as server time and
network storage, as needed automatically without requiring human interaction with each service
provider.
Broad network access
Capabilities are available over the network and accessed through standard mechanisms
that promote use by heterogeneous thin or thick client platforms (e.g., mobile phones, tablets,
laptops, and workstations).
Resource pooling
The provider’s computing resources are pooled to serve multiple consumers using a
multi-tenant model, with different physical and virtual resources dynamically assigned and
reassigned according to consumer demand. There is a sense of location independence in that
the customer generally has no control or knowledge over the exact location of the provided
resources but may be able to specify location at a higher level of abstraction (e.g., country, state,
or datacentre). Examples of resources include storage, processing, memory, and network
bandwidth.
Rapid elasticity
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.
Measured service
Cloud systems automatically control and optimize resource use by leveraging a
metering capability1 at some level of abstraction appropriate to the type ofservice (e.g., storage,
processing, bandwidth, and active user accounts). Resource usage can be monitored,
controlled, and reported, providing transparency for both the provider and consumer of the
utilized service.
The capability provided to the consumer is to use the provider’s applications running
on a cloud infrastructure2 . The applications are accessible from various client devices through
either a thin client interface, such as a web browser (e.g., 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 userspecific application configuration
settings.
Platform as a Service (PaaS)
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.3 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 possibly configuration settings for the
application-hosting environment.
Infrastructure as a Service (IaaS)
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 possibly limited control of select networking
components (e.g., host firewalls).
Deployment Models:
Private cloud
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.
Community cloud
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.
Public cloud
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.
Hybrid cloud
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).
Benefits of Cloud Computing
 One can access applications as utilities, over the Internet.
 One can manipulate and configure the applications online at any time.
 It does not require to install a software to access or manipulate cloud application.
 Cloud Computing offers online development and deployment tools, programming
runtime environment through PaaS model.
 Cloud resources are available over the network in a manner that provide platform
independent access to any type of clients.
 Cloud Computing offers on-demand self-service. The resources can be used without
interaction with cloud service provider.
 Cloud Computing is highly cost effective because it operates at high efficiency with
optimum utilization. It just requires an Internet connection
 Cloud Computing offers load balancing that makes it more reliable.
Risks related to Cloud Computing
Although cloud Computing is a promising innovation with various benefits in the world
of computing, it comes with risks. Some of them are discussed below:
Security and Privacy
It is the biggest concern about cloud computing. Since data management and
infrastructure management in cloud is provided by third-party, it is always a risk to handover
the sensitive information to cloud service providers. Although the cloud computing vendors
ensure highly secured password protected accounts, any sign of security breach may result in
loss of customers and businesses.
Lock In
It is very difficult for the customers to switch from one Cloud Service Provider (CSP) to
another. It results in dependency on a particular CSP for service.
Isolation Failure
This risk involves the failure of isolation mechanism that separates storage, memory,
and routing between the different tenants.
Management Interface Compromise
In case of public cloud provider, the customer management interfaces are accessible
through the Internet.
Insecure or Incomplete Data Deletion
It is possible that the data requested for deletion may not get deleted. It happens because
either of the following reasons
 Extra copies of data are stored but are not available at the time of deletion.
 Disk that stores data of multiple tenants is destroyed.
Conclusion:
Thus, we have studied about NIST model In Cloud Computing.

Case study on Google App engine (PaaS)
Aim:
A complete Case Study on PaaS (Google App Engine) on cloud computing.
Theory:
Platform-as-a-Service (PaaS): Cloud computing has evolved to include platforms for
building and running custom web-based applications, a concept known as Platform-as-a-
Service. PaaS is an outgrowth of the SaaS application delivery model. The PaaS model makes
all of the facilities required to support the complete life cycle of building and delivering web
applications and services entirely available from the Internet, all with no software downloads
or installation for developers, IT managers, or end users. Unlike the IaaS model, where
developers may create a specific operating system instance with homegrown applications
running, PaaS developers are concerned only with web based development and generally do
not care what operating system is used. PaaS services allow users to focus on innovation rather
than complex infrastructure. Organizations can redirect a significant portion of their budgets to
creating applications that provide real business value instead of worrying about all the
infrastructure issues in a roll-your-own delivery model. The PaaS model is thus driving a new
era of mass innovation. Now, developers around the world can access unlimited computing
power. Anyone with an Internet connection can build powerful applications and easily deploy
them to users globally
Google App Engine:
Architecture:
The Google App Engine (GAE) is Google's answer to the ongoing trend of Cloud
Computing offerings within the industry. In the traditional sense, GAE is a web application
hosting service, allowing for development and deployment of web-based applications within a
predefined runtime environment. Unlike other cloud-based hosting offerings such as Amazon
Web Services that operate on an IaaS level, the GAE already provides an application
infrastructure on the PaaS level. This means that the GAE abstracts from the underlying
hardware and operating system layers by providing the hosted application with a set of
application-oriented services. While this approach is very convenient for 50 developers ofsuch
applications, the rationale behind the GAE is its focus on scalability and usage-based
infrastructure as well as payment.
Costs:
Developing and deploying applications for the GAE is generally free of charge but
restricted to a certain amount of traffic generated by the deployed application. Once this limit
is reached within a certain time period, the application stops working. However, this limit can
be waived when switching to a billable quota where the developer can enter a maximum budget
that can be spent on an application per day. Depending on the traffic, once the free quota is
reached the application will continue to work until the maximum budget for this day is reached.
Features:
A Runtime Environment, the Data store and the App Engine services, the GAE can be
divided into three parts.
Runtime Environment:
The GAE runtime environment presents itself as the place where the actual application
is executed. However, the application is only invoked once an HTTP request is processed to
the GAE via a web browser or some other interface, meaning that the application is not
constantly running if no invocation or processing has been done. In case of such an HTTP
request, the request handler forwards the request and the GAE selects one out of many possible
Google servers where the application is then instantly deployed and executed for a certain
amount of time . The application may then do some computing and return the result back to the
GAE request handler which forwards an HTTP response to the client. It is important to
understand that the application runs completely embedded in this described sandbox
environment but only as long as requests are still coming in or some processing is done within
the application.
The reason for this is simple: Applications should only run when they are actually
computing, otherwise they would allocate precious computing power and memory without
need. This paradigm already shows the GAE‘s potential in terms of scalability. Being able to
run multiple instances of one application independently on different servers guarantees a decent
level of scalability. However, this highly flexible and stateless application execution paradigm
has its limitations. Requests are processed no longer than 30 seconds after which the response
has to be returned to the client and the application is removed from the runtime environment
again. Obviously this method 51 accepts that for deploying and starting an application each
time a request is processed, an additional lead time is needed until the application is finally up
and running. The GAE tries to encounter this problem by caching the application in the server
memory as long as possible, optimizing for several subsequent requests to the same application.
The type of runtime environment on the Google servers is dependent on the programming
language used. For Java or other languages that have support for Java-based compilers (such
as JRuby, Rhino and Groovy) a Java-based Java Virtual Machine (JVM) is provided. Also,
GAE fully supports the Google Web Toolkit (GWT), a framework for rich web applications.
Persistence and the datastore As previously discussed, the stateless execution of applications
creates the need for a datastore that provides a proper way for persistence. Traditionally, the
most popular way of persisting data in web applications has been the use of relational databases.
However, setting the focus on high flexibility and scalability, the GAE uses a different
approach for data persistence, called Bigtable. Instead of rows found in a relational database,
in Google‘s Bigtable data is stored in entities. Entities are always associated with a certain kind.
These entities have properties, resembling columns in relational database schemes. But in
contrast to relational databases, entities are actually schemaless, as two entities of the same
kind not necessarily have to have the same properties or even the same type of value
The most important difference to relational databases is however the querying of
entities within a Bigtable datastore. In relational databases queries are processed and executed
against a database at application runtime. GAE uses a different approach here. Instead of
processing a query at application runtime, queries are pre-processed during compilation time
when a corresponding index is created. This index is later used at application runtime when the
actual query is executed. Thanks to the index, each query is only a simple table scan where
only the exact filter value is searched. This method makes queries very fast compared to
relational databases while updating entities is a lot more expensive. 52 Transactions are similar
to those in relational databases. Each transaction is atomic, meaning that it either fully succeeds
or fails. As described above, one of the advantages of the GAE is its scalability through
concurrent instances of the same application. But what happens when two instances try to start
transactions trying to alter the same entity? The answer to this is quite simple: Only the first
instance gets access to the entity and keeps it until the transaction is completed or eventually
failed. In this case the second instance will receive a concurrency failure exception. The GAE
uses a method of handling such parallel transactions called optimistic concurrency control. It
simply denies more than one altering transaction on an entity and implicates that an application
running within the GAE should have a mechanism trying to get write access to an entity
multiple times before finally giving up. Heavily relying on indexes and optimistic concurrency
control, the GAE allows performing queries very fast even at higher scales while assuring data
consistency.
Services:
As mentioned earlier, the GAE serves as an abstraction of the underlying hardware and
operating system layers. These abstractions are implemented as services that can be directly
called from the actual application. In fact, the datastore itself is as well a service that is
controlled by the runtime environment of the application.
MEM CACHE: The platform innate memory cache service serves as a short-term storage. As
its name suggests, it stores data in a server‘s memory allowing for faster access compared to
the datastore. Memcache is a non-persistent data store that should only be used to store
temporary data within a series of computations. Probably the most common use case for
Memcache is to store session specific data. Persisting session information in the datastore and
executing queries on every page interaction is highly inefficient over the application lifetime,
nce session-owner instances are unique per session. Moreover, Memcache is well suited to
speed up common datastore queries. To interact with the Memcache GAE supports JCache, a
proposed interface standard for memory caches.
URL FETCH:
The GAE restrictions do not allow opening sockets, a URL Fetch service can be used
to send HTTP or HTTPS requests to other servers on the Internet. This service works
asynchronously, giving the remote server some time to respond while the request handler can
do 53 other things in the meantime. After the server has answered, the URL Fetch service
returns response code as well as header and body. Using the Google Secure Data Connector an
application can even access servers behind a company‘s firewall.
MAIL:
The GAE also offers a mail service that allows sending and receiving email messages.
Mails can be sent out directly from the application either on behalf of the application‘s
administrator or on behalf of users with Google Accounts. Moreover, an application can receive
emails in the form of HTTP requests initiated by the App Engine and posted to the app at
multiple addresses. In contrast to incoming emails, outgoing messages may also have an
attachment up to 1 MB.
XMPP:
In analogy to the mail service a similar service exists for instant messaging, allowing
an application to send and receive instant messages when deployed to the GAE. The service
allows communication to and from any instant messaging service compatible with XMPP , a
set of open technologies for instant messaging and related tasks.
IMAGES:
Google also integrated a dedicated image manipulation service into the App Engine.
Using this service images can be resized, rotated, flipped or cropped. Additionally, it is able to
combine several images into a single one, convert between several image formats and enhance
photographs. ofcourse the API also provides information about format, dimensions and a
histogram of color values.
USERS:
User authentication with GAE comes in two flavors. Developers can roll their own
authentication service using custom classes, tables and Memcache or simply plug into Google‘s
Accounts service. Since for most applications the time and effort of creating a sign-up page and store
user passwords is not worth the trouble, the User service is a very convenient functionality which gives
an easy method for authenticating users within applications. As by product thousands of Google
Accounts are leveraged. The User service detects if a user has signed in and otherwise redirect the user
to a sign-in page. Furthermore, it can detect whether the current user is an administrator, which
facilitates implementing admin-only areas within the application.
OAUTH:
SCHEDULED TASKS AND TASK QUEUES:
Because background processing is restricted on the GAE platform, Google introduced
task queues as another built-in functionality (18). When a client requests an application to do
certain steps, the application might not be able to process them right away. This is where the
task queues come into play. Requests that cannot be executed right away are saved in a task
queue that controls the correct sequence of execution. This way, the client gets a response to
its request right away, possibly with the indication that the request will be executed later (13).
Similar to the concept of task queues are corn jobs. Borrowed from the UNIX world, a GAE
cron job is a scheduled job that can invoke a request handler at a pre-specified time.
BLOBSTORE:
The general idea behind the blobstore is to allow applications to handle objects that are
much larger than the size allowed for objects in the datastore service. Blob is short for binary
large object and is designed to serve large files, such as video or high quality images. Although
blobs can have up to 2 GB they have to be processed in portions, one MB at a time. This
restriction was introduced to smooth the curve of datastore traffic. To enable queries for blobs,
each has a corresponding blob info record which is persisted in the datastore (8), e. g. for
creating an image database.
ADMINISTRATION CONSOLE:
The administration console acts as a management cockpit for GAE applications. It gives
the developer real-time data and information about the current performance of the deployed
application and is used to upload new versions of the source code. At this juncture it is possible
to test new versions of the application and switch the versions presented to the user.
Furthermore, access data and logfiles can be viewed. It also enables analysis of traffic so that
quota can be adapted when needed. Also 55 the status of scheduled tasks can be checked and
the administrator is able to browse the applications datastore and manage indices.
App Engine for Business: While the GAE is more targeted towards independent developers
in need for a hosting platform for their medium-sized applications, Google`s recently launched
App Engine for Business tries to target the corporate market. Although technically mostly
relying on the described GAE, Google added some enterprise features and a new pricing
scheme to make their cloud computing platform more attractive for enterprise customers (21).
Regarding the features, App Engine for Business includes a central development manager that
allows a central administration of all applications deployed within one company including
access control lists. In addition to that Google now offers a 99.9% service level agreement as
well as premium developer support. Google also adjusted the pricing scheme for their corporate
customers by offering a fixed price of $8 per user per application, up to a maximum of $1000,
PaaS Advantages:
 User does not have to manage low level computing
resources and services
 Provider handles most of the non functional requirements
of your applications
 Scaling is automatically managed by the platform
 Easier and Agile application deployment
 Simplifies prototyping and application startups
 Lower costs
 Pay for only what is used
 More fine-grained cost model than in IaaS
Conclusion:
Thus, we have studied about PaaS (Google App Engine) Cloud Computing.