UNIT-III

➢Cloud Application Design:

➢ Design Considerations for Cloud
Applications,
➢Reference Architectures for Cloud
Applications,
➢ Cloud Application Design Methodologies:
➢SOA,
➢ Cloud Component Model,
➢ MVC,
➢Data Storage Approaches
 Design Considerations for Cloud
Applications
➢Scalability
➢Reliability
➢Availability
➢Security
➢Maintenance & Up gradation
➢Performance
 1.Scalability
➢Loose coupling of components:
➢Traditional application design methodologies with tightly
coupled application components, limit the scalability.
➢Tightly coupled components use procedure based tight
coupling and hard-wired links which make it difficult to
scale application components independently.
➢ By designing loosely coupled components, it is possible
to scale each component independently.
➢Stateless design:
➢Stateless designs that store state outside of the
components in a separate database allow scaling the
application components independently,
➢Asynchronous communication:
➢ In traditional application designs, it is a common practice to
process a request and return immediately.
➢This limits the scalability of the application.
➢ By allowing asynchronous communication between
components, it is possible to add capacity by adding
additional servers when the application load increases.
➢Database choice and design:
➢ Choice of the database and the design of data storage
schemes affect the application scalability.
➢ Decisions such as whether to choose a traditional relational
database (SQL approach) with strict schemas or a schema-
less database (No-SQL approach) should be made after
careful analysis of the application's data storage and
analysis requirements
 Design Considerations for Cloud Applications
➢ 2.Reliability & Availability
➢ Reliability
➢ Reliability of a system is defined as the probability
that a system will perform the intended functions
under stated conditions for a specified amount of
time.
➢ Availability
➢ Availability is the probability that a system will
perform a specified function under given
conditions at a prescribed time.
Design considerations to be kept in mind while
developing highly reliable and available
applications are:
➢ No single point of failure:
➢ Traditional application design approaches which have
single points of failure such as a single database server
or a single application server have the risk of complete
breakdowns in case the of failure of the critical
resource. To high achieve reliability and availability,
having a redundant resource or an automated fallback
resource is important.
➢ Trigger automated actions on failures:
➢ Traditional application design approaches handled
failures by giving exceptions. By using failures and
triggers for automated actions it is possible to improve
the application reliability and availability. For example,
if an application server experiences high CPU usage and
is unable to serve new requests, a new application
server is automatically
Graceful degradation:
Applications should be designed to gracefully degrade in the
event of outages of some parts or components of the
application.
Graceful degradation means that if some component of the
application becomes unavailable the application as a
whole would still be available and continue to serve the
users, though, with limited functionality.
For example, in an e- Commerce application, if a component
that manages a certain category of products becomes
unavailable, the users should still be able to view products
from other categories.
Logging:
Logging all events in all the application components can
help in detecting bottlenecks and failures so that
necessary design/deployment changes can be made to
improve application reliability and availability.
➢Replication:
➢All application data should be replicated. Replication is
used to create and maintain multiple copies of the data
in the cloud.
➢In the event of data loss at the primary location,
organizations can continue to operate their applications
from secondary data sources.
3. Security
➢Security is an important design consideration for cloud
applications given the out sourced nature of cloud
computing environments.
➢ In domains such as healthcare there are several
government laws that require the applications to ensure
security of health information of patients. Key security
considerations for cloud computing environments
➢Securing data at rest
➢ Securing data in motion
➢Authentication
➢Authorization
➢Identity and access management
➢Key management
➢Data integrity
➢Auditing
 4.Maintenance & Up gradation
➢ To achieve a rapid time-to-market, businesses typically launch
their application a core set of features ready and then
incrementally add new features as and when they are
complete.
➢ Businesses may need to adapt their applications based on
the feedback from the users. In such scenarios, it is important
to design applications with low maintenance and up
gradation costs.
➢ Design decisions such as loosely coupled components help in
reducing the application maintenance and up gradation time.
➢ In applications with loosely coupled components, changes can
be made to a component. without affecting other
components. Moreover, components can be tested individually
Other decisions such as logging and triggering automated
actions also help in lowering the maintenance costs.
 5.Performance
➢ Applications should be designed while keeping the
performance requirements in mind.
➢ Performance requirements depend on the type of
the application. For example applications which
experience high database read-intensive workloads,
can benefit from read-replication or caching
approaches.
➢There are various metrics that are use to evaluate the
application performance, such as response time,
throughput, etc.For a good user experience a
response time less than 4 seconds is generally
acceptable. However certain applications may have
even more strict requirements.
 Reference Architectures for Cloud Applications
➢Reference Architectures –
➢e-Commerce, Business-to-Business, Banking and
Financial apps
➢ Load Balancing Tier
➢ Load balancing tier consists of one or more load
balancers.
➢ Application Tier
➢ For this tier, it is recommended to configure auto
scaling.
➢ Auto scaling can be triggered when the recorded
values for any of the specified metrics such as CPU
usage, memory usage, etc. goes above defined
thresholds.
➢ Database Tier
➢ The database tier includes a master database
instance and multiple slave instances.
➢ The master node serves all the write requests
and the read requests are served from the
slave nodes.
➢ This improves the throughput for the
database tier since most applications have a
higher number of read requests than write
requests. Book website:
www.cloudcomputingbook.inf
 Reference Architectures –
➢Content delivery apps
➢Figure shows a typical deployment architecture for
content delivery applications such as online photo
albums, video webcasting, etc.
➢ Both relational and non-relational data stores are
shown in this deployment.
➢ A content delivery network (CDN) which consists of
a global network of edge locations is used for media
delivery.
➢ CDN is used to speed up the delivery of static
content such as images and videos.
 Reference Architectures –
Analytics apps
➢ Figure shows a typical deployment architecture for
compute intensive applications such as Data Analytics,
Media Trans coding, etc.
➢ Comprises of web, application, storage, computing/
analytics and database tiers.
➢ The analytics tier consists of cloud-based distributed
batch processing frameworks such as Hadoop which are
suitable for analyzing big data.
➢ Data analysis jobs (such as Map Reduce) jobs are
submitted to the analytics tier from the application
servers.
➢ The jobs are queued for execution and upon
completion the analyzed data is presented from the
application servers.
 Service-Oriented Architecture(SOA)
➢ Service Oriented Architecture (SOA) is a well established
architectural approach for designing and developing applications
in the form services that can be shared and reused.
➢ SOA is a collection of discrete software modules or services that
forma part of an application and collectively provide the
functionality of an application.
➢ SOA services are developed as loosely coupled modules with no
hard- wired calls embedded in the services.
➢ The services communicate with each other by passing messages.
➢ Services are described using the Web Services Description
Language (WSDL).
➢ WSDL is an XML-based web services description language that is
used to create service descriptions containing information on the
functions performed by a service and the inputs and outputs of
the service.
➢SOA allows users to combine a large number of
facilities from existing services to form
applications.
➢SOA encompasses a set of design principles
that structure system development and
provide means for integrating components into
a coherent and decentralized system.
➢SOA-based computing packages functionalities
into a set of interoperable services, which can
be integrated into different software systems
belonging to separate business domains.
➢There are two major roles within Service-oriented
Architecture:
➢Service provider: The service provider is the
maintainer of the service and the organization that
makes available one or more services for others to
use. To advertise services, the provider can publish
them in a registry, together with a service contract
that specifies the nature of the service, how to use
it, the requirements for the service, and the fees
charged.
➢Service consumer: The service consumer can locate
the service metadata in the registry and develop
the required client components to bind and use the
service.
➢The different characteristics of SOA are as follows :

➢ Provides interoperability between the services.

➢ Provides methods for service encapsulation, service

discovery, service composition,
➢service reusability and service integration.
➢ Facilitates QoS (Quality of Services) through service
contract based on Service Level Agreement (SLA).
➢ Provides loosely couples services.
➢ Provides location transparency with better scalability
and availability.
➢ Ease of maintenance with reduced cost of application
development and
deployment.
• Advantages of SOA:
• Service reusability: In SOA, applications are made from
existing services. Thus, services can be reused to make
many applications.
• Easy maintenance: As services are independent of each
other they can be updated and modified easily without
affecting other services.
• Platform independent: SOA allows making a complex
application by combining services picked from different
sources, independent of the platform.
• Availability: SOA facilities are easily available to anyone
on request.
• Reliability: SOA applications are more reliable because it
is easy to debug small services rather than huge codes
• Scalability: Services can run on different servers within
an environment, this increases scalability
• Disadvantages of SOA:
• High overhead: A validation of input
parameters of services is done whenever
services interact this decreases performance as
it increases load and response time.
• High investment: A huge initial investment is
required for SOA.
• Complex service management: When services
interact they exchange messages to tasks. the
number of messages may go in millions. It
becomes a cumbersome task to handle a large
number of messages.
• Practical applications of SOA:
• SOA infrastructure is used by many armies and
air forces to deploy situational awareness
systems.
• SOA is used to improve healthcare delivery.
• Nowadays many apps are games and they use
inbuilt functions to run. For example, an app
might need GPS so it uses the inbuilt GPS
functions of the device. This is SOA in mobile
solutions.
• SOA helps maintain museums a virtualized
storage pool for their information and content.
 Cloud Component Model(CCM)

➢ Cloud Component Model is an application design methodology

that provides a flexible way of creating cloud applications in a
rapid, convenient and platform independent manner.
➢ CCM is an architectural approach for cloud applications that is not
tied to any specific programming language or cloud platform.
➢ Cloud applications designed with CCM approach can have
innovative hybrid deployments in which different components of
an application can be deployed on cloud infrastructure and
platforms of different cloud vendors.
➢ Applications designed using CCM have better portability and
interoperability.
➢ CCM based applications have better scalability by decoupling
application components and providing asynchronous
communication mechanisms.
 CCM Application Design Methodology
• CCM approach for application design involves:
1. Component Design
2. Architecture Design
3. Deployment Design
➢ Component Design:
➢ Define Cloud Component Model for application
➢ Architecture Design :
➢Define interactions between application components
➢ Deployment Design
➢Assign application components to cloud resources
CCM Component Design
➢ Cloud Component Model is created for the application based
on comprehensive analysis of the application’s functions and
building blocks.
➢ Cloud component model allows identifying the building
blocks of a cloud application which are classified based on
the functions performed and type of cloud resources
required.
➢ Each building block performs a set of actions to produce the
desired outputs for other components.
➢ Each component takes specific inputs, performs a pre-
defined set of actions and produces the desired outputs.
➢ Components offer their functions as services through a
functional interface which can be used by other components.
➢ Components report their performance to a performance
database through a performance interface.
CCM Architecture Design
➢ CCM components have the following characteristics:
➢ Loose Coupling
➢ Components in the Cloud Component Model are
loosely coupled.
➢ Asynchronous Communication
➢ By allowing asynchronous communication between
components, it is possible to add capacity by adding
additional servers when the application load
increases. Asynchronous communication is made
possible by using messaging queues.
➢ Stateless Design
➢ Components in the Cloud Component Model are
stateless. By storing session state outside of the
component (e.g. in a database), stateless component
design enables distribution and horizontal scaling.
CCM Deployment Design
➢ In Deployment Design step, application
components are mapped to specific cloud
resources such as web servers, application servers,
database servers, etc.
➢ Since the application components are designed to
be loosely coupled and stateless with
asynchronous communication, components can be
deployed independently of each other.
➢ This approach makes it easy to migrate
application components from one cloud to the
other.
➢ With this flexibility in application design and
deployment, the application developers can ensure
that the applications meet the performance and
cost requirements with changing contexts.
Differences between SOA and CCM
 Model View Controller(MVC)
➢ Model View Controller (MVC) is a popular software design
pattern for designing or developing web applications.
➢ MVC is one of the most frequently used industry-standard
web development framework to create scalable and
extensible projects.
➢ It is also used for designing mobile apps.
➢ The Model-View-Controller (MVC) is an architectural
pattern that separates an application into three main
logical components:
➢ the model,
➢ the view,
➢ and the controller
• Components of MVC :
• The MVC framework includes the following 3 components:
• Controller ,Model and View
• Controller:
• The controller is the component that enables the interconnection
between the views and the model so it acts as an intermediary. The
controller doesn’t have to worry about handling data logic, it just
tells the model what to do. It process all the business logic and
incoming requests, manipulate data using the Model component
and interact with the View to render the final output.
• View:
• The View component is used for all the UI logic of the application. It
generates a user interface for the user. Views are created by the
data which is collected by the model component but these data
aren’t taken directly but through the controller. It only interacts
with the controller.
• Model:
• The Model component corresponds to all the data-related logic
that the user works with. This can represent either the data that is
being transferred between the View and Controller components or
any other business logic-related data. It can add or retrieve data
from the database. It responds to the controller’s request because
the controller can’t interact with the database by itself. The model
interacts with the database and gives the required data back to
the controller.
Let’s understand the working of the MVC framework with an example:
➢ Let’s imagine an end-user sends a request to a server to get a list of
students studying in a class. The server would then send that request
to that particular controller that handles students. That controller
would then request the model that handles students to return a list
of all students studying in a class.
➢ The model would query the database for the list of all students and
then return that list back to the controller. If the response back from
the model was successful, then the controller would ask the view
associated with students to return a presentation of the list of
students. This view would take the list of students from the controller
and render the list into HTML that can be used by the browser.
➢ The controller would then take that presentation and returns it back
to the user. Thus ending the request. If earlier the model returned an
error, the controller would handle that error by asking the view that
handles errors to render a presentation for that particular error. That
error presentation would then be returned to the user instead of the
student list presentation.
➢ As we can see from the above example, the model handles all of the
data. The view handles all of the presentations and the controller just
tells the model and view of what to do. This is the basic architecture
and working of the MVC framework.
• Popular MVC Frameworks:
• Some of the most popular and extensively used MVC
frameworks are listed below.
• Ruby on Rails
• Django
• CherryPy
• Spring MVC
• Catalyst
• Rails
• Zend Framework
• Fuel PHP
• Laravel
• Symphony
 Data Storage Approaches

■ Storage and processing on the cloud are intimately tied to one another.
• Most cloud applications process very large amounts of data. Effective data
replication and storage management strategies are critical to the computations
performed on the cloud.
• Strategies to reduce the access time and to support real-time multimedia
access are necessary to satisfy the requirements of content delivery.
■ Sensors feed a continuous stream of data to cloud applications.
■ An ever increasing number of cloud-based services collect detailed data
about their services and information about the users of these services. The
service providers use the clouds to analyze the data.
■ Humongous amounts of data - in 2013
The Internet video will generate over 18 EB/month.
Global mobile data traffic will reach 2 EB/month.

(1 EB = 1018 bytes, 1 PB = 1015 bytes, 1 TB =1012 bytes, 1 GB 1012 bytes)

 • Evolution of storage technology
■ The capacity to store information in units of 730-MB (1 CD-ROM)

1986 - 2.6 EB ➔ <1, CD-ROM /person.

1993 - 15.8 EB ➔ 4 CD-ROM/person.
2000 - 54.5 EB ➔ 12 CD-ROM/person.
-295.0 EB➔ 61 CD-ROM/person.
2007
■ Hard disk drives (HDD) - during the 1980-2003 period:
Storage density of has increased by four orders of magnitude from about
0.01 Gb/in2 to about 100 Gb/in2
Prices have fallen by five orders of magnitude to about 1 cent/MB.
HDD densities are projected to climb to 1,800 Gb/in2 by 2016, up from 744
Gb/in2 in 2011.
■ Dynamic Random Access Memory (DRAM) - during the period 1990-2003:
The density increased from about 1 Gb/in2 in 1990 to 100 Gb/in2 .
The cost has tumbled from about $80/MB to less than $1/MB.
•Storage and data models
■ A storage model ➔ describes the layout of a data structure in a
physical storage - a local disk, a removable media, or storage
accessible via the network.
■ A data model ➔ captures the most important logical aspects of a
data structure in a database.
■ Two abstract models of storage are used.
• Cell storage  assumes that the storage consists of cells of the same
size and that each object fits exactly in one cell. This model reflects the
physical organization of several storage media; the primary memory of a
computer is organized as an array of memory cells and a secondary
storage device, e.g., a disk, is organized in sectors or blocks read and
written as a unit.

Journal storage  system that keeps track of the changes that will be
made in a journal (usually a circular log in a dedicated area of the file
system) before committing them to the main file system. In the event of
system crash or power failure, such file systems are quicker to bring
back online and less likely to become corrupted.
Cell storage
Journal Storage
•Data Base Management System (DBMS)
• Database ➔ a collection of logically-related records.
Data Base Management System (DBMS) ➔ the software that
controls the access to the database.
Query language ➔ a dedicated programming language used to
develop database applications.
Most cloud application do not interact directly with the file systems,
but through a DBMS.
Database models ➔ reflect the limitations of the hardware available

at the time and the requirements of the most popular

each period.
navigational model of the 1960s.
relational model of the 1970s.
object-oriented model of the 1980s.
NoSQL model of the first decade of the 2000s.