Chapter 5

Cloud Application Design

Book website: www.cloudcomputingbook.info Bahga & Madisetti, © 2014

Outline

• Cloud Application Design Considerations

• Cloud Application Reference Architectures
• Design Methodologies
• Data Storage
• Data Analytics
• Deployment & Management

Book website: www.cloudcomputingbook.info Bahga & Madisetti, © 2014

Design Considerations for Cloud Applications

• Scalability
• Scalability is an important factor that drives the application designers to move to cloud computing environments. Building applications
that can serve millions of users without taking a hit on their performance has always been challenging. With the growth of cloud
computing application designers can provision adequate resources to meet their workload levels.
• Reliability & Availability
• 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 is the probability that a system will perform a specified function under given conditions at a
prescribed time.
• Security
• Security is an important design consideration for cloud applications given the outsourced nature of cloud computing environments.
• Maintenance & Upgradation
• To achieve a rapid time-to-market, businesses typically launch their applications with a core set of features ready and then incrementally
add new features as and when they are complete. In such scenarios, it is important to design applications with low maintenance and
upgradation costs.
• Performance
• Applications should be designed while keeping the performance requirements in mind.

Book website: www.cloudcomputingbook.info Bahga & Madisetti, © 2014

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.info Bahga & Madisetti, © 2014

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.

Book website: www.cloudcomputingbook.info Bahga & Madisetti, © 2014

Reference Architectures –
Analytics apps

• Figure shows a typical deployment architecture for compute

intensive applications such as Data Analytics, Media
Transcoding, 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 MapReduce) 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.

Book website: www.cloudcomputingbook.info Bahga & Madisetti, © 2014

 Service Oriented Architecture

• 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 form a 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.

Book website: www.cloudcomputingbook.info Bahga & Madisetti, © 2014

SOA Layers
• Business Systems
• This layer consists of custom built applications and legacy systems such as Enterprise
Resource Planning (ERP), Customer Relationship Management (CRM), Supply Chain
Management (SCM), etc.
• Service Components
• The service components allow the layers above to interact with the business systems. The
service components are responsible for realizing the functionality of the services exposed.
• Composite Services
• These are coarse-grained services which are composed of two or more service
components. Composite services can be used to create enterprise scale components or
business-unit specific components.
• Orchestrated Business Processes
• Composite services can be orchestrated to create higher level business processes. In this
layers the compositions and orchestrations of the composite services are defined to create
business processes.
• Presentation Services
• This is the topmost layer that includes user interfaces that exposes the services and the
orchestrated business processes to the users.
• Enterprise Service Bus
• This layer integrates the services through adapters, routing, transformation and messaging
mechanisms.

Book website: www.cloudcomputingbook.info Bahga & Madisetti, © 2014

 Cloud Component Model

• 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.

Book website: www.cloudcomputingbook.info Bahga & Madisetti, © 2014

CCM Application Design Methodology

• CCM approach for application

design involves:
• Component Design
• Architecture Design
• Deployment Design

Book website: www.cloudcomputingbook.info Bahga & Madisetti, © 2014

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.
CCM map for an e-Commerce application
• 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.

Book website: www.cloudcomputingbook.info Bahga & Madisetti, © 2014

CCM Architecture Design

• In Architecture Design step, interactions between

the application components are defined.

• 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 Architecture design of an e-Commerce application.
storing session state outside of the component (e.g. in a
database), stateless component design enables distribution and
horizontal scaling.

Book website: www.cloudcomputingbook.info Bahga & Madisetti, © 2014

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 fiexibility in application design and
deployment, the application developers can ensure
that the applications meet the performance and cost
requirements with changing contexts.
Deployment design of an e-Commerce application

Book website: www.cloudcomputingbook.info Bahga & Madisetti, © 2014

SOA vs CCM

Similarities
SOA CCM
Standardization & SOA advocates principles of CCM is based on reusable
Re-use reuse and well defined components which can be used
relationship between service by multiple cloud applications.
provider and service consumer.

Loose coupling SOA is based on loosely CCM is based on loosely

coupled services that minimize coupled components that
dependencies. communicate asynchronously

Statelessness SOA services minimize resource CCM components are stateless.

consumption by deferring the State is stored outside of the
management of state components.
information.

Book website: www.cloudcomputingbook.info Bahga & Madisetti, © 2014

SOA vs CCM
Differences

SOA CCM
End points SOA services have small and well-defined set CCM components have very large number of
of endpoints through which many types of endpoints. There is an endpoint for each resource
data can pass. in a component, identified by a URI.

Messaging SOA uses a messaging layer above HTTP by CCM components use HTTP and REST for
using SOAP which provide prohibitive messaging.
constraints to developers.

Security Uses WS-Security , SAML and other CCM components use HTTPS for security.
standards for security

Interfacing SOA uses XML for interfacing. CCM allows resources in components represent
different formats for interfacing (HTML, XML,
JSON, etc.).

Consumption Consuming traditional SOA services in a CCM components and the underlying component
browser is cumbersome. resources are exposed as XML, JSON (and other
formats) over HTTP or REST, thus easy to consume
in the browser.

Book website: www.cloudcomputingbook.info Bahga & Madisetti, © 2014

Model View Controller

• Model View Controller (MVC) is a popular software design pattern for web applications.
• Model
• Model manages the data and the behavior of the applications. Model processes events sent by the controller. Model has no information about the views and controllers.
Model responds to the requests for information about its state (from the view) and responds to the instructions to change state (from controller).

• View
• View prepares the interface which is shown to the user. Users interact with the application through views. Views present the information that the model or controller tell
the view to present to the user and also handle user requests and sends them to the controller.

• Controller
• Controller glues the model to the view. Controller processes user requests and updates the model when the user manipulates the view. Controller also updates the view
when the model changes.

Book website: www.cloudcomputingbook.info Bahga & Madisetti, © 2014

RESTful Web Services

• Representational State Transfer (REST) is a set of architectural principles by which you can
design web services and web APIs that focus on a system’s resources and how resource
states are addressed and transferred.
• The REST architectural constraints apply to the components, connectors, and data
elements, within a distributed hypermedia system.
• A RESTful web service is a web API implemented using HTTP and REST principles.
• The REST architectural constraints are as follows:
• Client-Server
• Stateless
• Cacheable
• Layered System
• Uniform Interface
• Code on demand

Book website: www.cloudcomputingbook.info Bahga & Madisetti, © 2014

Relational Databases

• A relational database is database that conforms to the relational model that was popularized by
Edgar Codd in 1970.
• The 12 rules that Codd introduced for relational databases include:
• Information rule
• Guaranteed access rule
• Systematic treatment of null values
• Dynamic online catalog based on relational model
• Comprehensive sub-language rule
• View updating rule
• High level insert, update, delete
• Physical data independence
• Logical data independence
• Integrity independence
• Distribution independence
• Non-subversion rule

Book website: www.cloudcomputingbook.info Bahga & Madisetti, © 2014

Relational Databases

• Relations
• A relational database has a collection of relations (or tables). A relation is a set of tuples (or rows).

• Schema
• Each relation has a fixed schema that defines the set of attributes (or columns in a table) and the constraints on the attributes.

• Tuples
• Each tuple in a relation has the same attributes (columns). The tuples in a relation can have any order and the relation is not sensitive to
the ordering of the tuples.
• Attributes
• Each attribute has a domain, which is the set of possible values for the attribute.

• Insert/Update/Delete
• Relations can be modified using insert, update and delete operations. Every relation has a primary key that uniquely identifies each
tuple in the relation.
• Primary Key
• An attribute can be made a primary key if it does not have repeated values in different tuples.

Book website: www.cloudcomputingbook.info Bahga & Madisetti, © 2014

ACID Guarantees

• Relational databases provide ACID guarantees.

• Atomicity
• Atomicity property ensures that each transaction is either “all or nothing”. An atomic transaction ensures that all parts
of the transaction complete or the database state is left unchanged.
• Consistency
• Consistency property ensures that each transaction brings the database from one valid state to another. In other
words, the data in a database always conforms to the defined schema and constraints.
• Isolation
• Isolation property ensures that the database state obtained after a set of concurrent transactions is the same as would
have been if the transactions were executed serially. This provides concurrency control, i.e. the results of incomplete
transactions are not visible to other transactions. The transactions are isolated from each other until they finish.
• Durability
• Durability property ensures that once a transaction is committed, the data remains as it is, i.e. it is not affected by
system outages such as power loss. Durability guarantees that the database can keep track of changes and can recover
from abnormal terminations.

Book website: www.cloudcomputingbook.info Bahga & Madisetti, © 2014

Non-Relational Databases

• Non-relational databases (or popularly called No-SQL databases) are becoming popular with the growth of
cloud computing.
• Non-relational databases have better horizontal scaling capability and improved performance for big data at
the cost of less rigorous consistency models.
• Unlike relational databases, non-relational databases do not provide ACID guarantees.
• Most non-relational databases offer “eventual” consistency, which means that given a sufficiently long period
of time over which no updates are made, all updates can be expected to propagate eventually through the
system and the replicas will be consistent.
• The driving force behind the non-relational databases is the need for databases that can achieve high
scalability, fault tolerance and availability.
• These databases can be distributed on a large cluster of machines. Fault tolerance is provided by storing
multiple replicas of data on different machines.

Book website: www.cloudcomputingbook.info Bahga & Madisetti, © 2014

Non-Relational Databases - Types

• Key-value store
• Key-value store databases are suited for applications that require storing unstructured data without a fixed schema.
Most key-value stores have support for native programming language data types.
• Document store
• Document store databases store semi-structured data in the form of documents which are encoded in different
standards such as JSON, XML, BSON, YAML, etc.
• Graph store
• Graph stores are designed for storing data that has graph structure (nodes and edges). These solutions are suitable for
applications that involve graph data such as social networks, transportation systems, etc.
• Object store
• Object store solutions are designed for storing data in the form of objects de?ned in an object-oriented programming
language.

Book website: www.cloudcomputingbook.info Bahga & Madisetti, © 2014

Further Reading

• Roy T. Fielding, Richard N. Taylor, Principled Design of the Modern Web Architecture, ACM
Transactions on Internet Technology (TOIT), 2002.
• A. Bahga, V. Madisetti, Rapid Prototyping of Advanced Cloud-Based Systems, IEEE Computer, vol.
46, iss. 11, Nov 2013.
• E.F. Codd, A Relational Model of Data for Large Shared Data Banks, Communications of the ACM
13 (6): 377–387, 1970.

Book website: www.cloudcomputingbook.info Bahga & Madisetti, © 2014