Chapter
Cloud Application Design
Outline
• Cloud Application Design Considerations
• Cloud Application Reference Architectures
• Design Methodologies
• Data Storage
• Data Analytics
• Deployment & Management
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.
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: Bahga & Madisetti, ©
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.
• CDN is used to speed up the delivery of static content such
as images and videos.
Book website: Bahga & Madisetti, ©
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: Bahga & Madisetti, ©
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: Bahga & Madisetti, ©
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: Bahga & Madisetti, ©
CCM Application Design Methodology
• CCM approach for
application design involves:
• Component Design
• Architecture Design
• Deployment Design
Book website: Bahga & Madisetti, ©
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 CCM map for an e-Commerce application
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: Bahga & Madisetti, ©
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 Architecture design of an e-Commerce application.
• 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.
Book website: Bahga & Madisetti, ©
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: Bahga & Madisetti, ©
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: Bahga & Madisetti, ©
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: Bahga & Madisetti, ©
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: Bahga & Madisetti, ©
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: Bahga & Madisetti, ©
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: Bahga & Madisetti, ©
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: Bahga & Madisetti, ©
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: Bahga & Madisetti, ©
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: Bahga & Madisetti, ©
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: Bahga & Madisetti, ©
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: Bahga & Madisetti, ©
