1. â Unit 5
â
Cloud Applications
Ms. Mary Jacob
Assistant Professor, Department of Computer Science
Kristu Jayanti College (Autonomous)
2. 5 Design Considerations for Cloud Applications
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 compo nents, 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,
3. 5 Design Considerations for Cloud Applications
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.
Stateless design: Stateless designs that store state outside of the
components separate database allow scaling the application components
independently.
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.
4. 5 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
Ă It is the probability that a system will perform a specified function
under given conditions at a prescribed time.
5. 5 Design Considerations for Cloud Applications
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 a unable to server new requests, a new application server is automatically
6. 5 Design Considerations for Cloud Applications
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.
7. 5 Design Considerations for Cloud Applications
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.
8. 5 Design Considerations for Cloud Applications
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.
9. 5 Design Considerations for Cloud Applications
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
10. 5 Design Considerations for Cloud Applications
4. Maintenance & Upgradation
Ă To achieve a rapid time-to-market, businesses typically launch their appl 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 upgradation costs.
Ă Design decisions such as loosely coupled components help in reducing the
application maintenance and upgradation 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.
11. 5 Design Considerations for Cloud Applications
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.
12. 5
The design methodologies for cloud applications are:
Ă Service Oriented Architecture
Ă Cloud Component Model
Ă Model View Controller
Cloud Application Design Methodologies
13. 5
Ă It is a architectural approach to design applications in the form of services
that can be shared and reused.
Ă It is a collection of discrete software modules or services that collectively
provide the functionality of the application.
Ă It is developed using loosely coupled modules with no hard wired calls
embedded in the services.
Ă Services communicate with each other by passing messages.
Ă It uses Web Services Description Language(WSDL) to create service
descriptions containing information about the functions performed by the
service and the inputs and outputs of the service.
Service Oriented Architecture
14. Concepts of WSDL
5
WSDL is XML based web services description
language.
A WSDL 2.0 description contains:
Service- It describes discrete system function exposed
as a web service.
End Point - It is the address of the web service.
Binding - It specifies interface and transport protocol.
Interface- It defines web service and operations that
can be performed by the service and the input and
outputs.
Operations- It defines how the message is decoded
and the actions that can be performed.
Types - It describes the data.
Service Oriented Architecture
15. 5
Ă SOA services communicate using SOAP(Simple Object Oriented
Protocol).
Ă SOAP is a protocol that allows exchange of structured information
between web services.
Ă WSDL in combination with SOAP is used to provide web services over
the internet.
Ă SOA allows reuse of services for multiple applications.
Ă As each service is designed to perform a small function developers can
orchestrate existing SOA services in an ad-hoc manner to create a new
application without the need to re-implement the existing services.
Service Oriented Architecture
17. Service Oriented Architecture
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.
Services might aggregate information and data retrieved from other services or create
workflows of services to satisfy the request of a given service consumer. This practice is
known as service orchestration .
Another important interaction pattern is service choreography, which is the coordinated
interaction of services without a single point of control.
18. 5
The layers of SOA are:
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 componemts allows the layers above to interact
with the business systems.The service components are responsible for realizing the
functionality of the services provided.
Composite Services - They are coarse-grained services which are composed of two
or more service components.It 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 layer the compositions and orchestrations of
the composite services are defined to create business processes.
Service Oriented Architecture
19. 5
Presentation Services - This is the
topmost layer that includes user
interfaces that exposes the services
and orchestrated business processes to
the users.
Enterprise Service Bus - This layer
integrates the services through
adapters, routing, tranformation and
messaging mechanisms.
Service Oriented Architecture
20. 5
Ă Cloud Component Model (CCM) is a application design methodology that
provides a flexible way of reating an application in rapid, convenient, platform
independent manner unlike the existing approaches that use architecture-specific
and domain-specific templates.
Ă It is architectural approach that is not tied to any specific programming language
or cloud platform.
Ă It can contribute to innovative hybrid deployments in which components of an
application can be deployed in cloud infrastructure and platforms of different
cloud vendors.
Ă It has better portability and interoperability
Ă CCM based applications have better scalability because of asynchronous
communication and decoupling of application components.
Cloud Component Model (CCM)
21. 5
Ă CCM makes maintainability of cloud application easier as each component of the
application can be improved or upgraded independent of other components.
Ă CCM provides cost benefits to the cloud application as components can be
carefully mapped to cloud resources and by scaling the resources up only for
components which require additional computing capacity.
Ă The steps in CCM approach are as follws:
1. Component Design
2. Architecture Design
3. Deployment Design
Cloud Component Model (CCM)
23. 5
1. Component Design
Ă Cloud Component Model is created for the application based on the
comprehensive analysis of the applicationâs functions and building blocks.
Ă Cloud Component Model allows to identify the building blocks of cloud
application which are classified based on the functions performed and the 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 pre-defined set of actions and
produces the desired outputs.
Ă Components offer their services through functional interface which can be used
by other components.
Cloud Component Model (CCM)
24. 5
Component Design
Ă Components report their performance to a performance database through
performance interface.
Ă Components have number of resources like web pages,images, documents,
database tables etc.
Ă Auto Scaling performance constraints and conditions can be specified for each
component.
Ă Component based approach is applicable to web based applications and mobile
applications.
Cloud Component Model (CCM)
25. 5
2. Architecture Design
In this step the interactions between the application components are defined.
CCM Components have the following characterestics:
Loose Coupling :
Ă Components in the Cloud component model is loosely coupled.
Ă Instead of hard-wiring the links the components interface through clearly defined
functional and service boundaries.Link between the components are established
and broken as they respond to service requests.
Ă Loose coupling of components relies on REST communication protocol that
allows components developed in different programming language to communicate
to each other.
Cloud Component Model (CCM)
26. 5
Architecture Design
Asynchronous Communication :
Ă Loosely coupled components communicate asynchronously through message
based communication using message queues.
Ă The benefit of messaging queues is that the overall application can continue to
perform even though individual components may go offline temporarily.When the
component becomes temporarily unavailable the messages are buffered and
processed when the component becomes avaiable again.
Ă Loose coupling isolates the components of the application and each component
communicates in an asynchronous manner treating other components as black
boxes.
Ă Because of asynchronous communication it is possble to add additional servers
when the application load increases.
Cloud Component Model (CCM)
27. 5
Architecture Design
Stateless Design :
Ă Components in Cloud component model are stateless.
Ă By storing session state outside of the component,stateless component design
enables distribution and horizontal scaling.
Ă In distributed computing with horizontal scaling of components successive
requests to a component may be serviced by different servers.
Cloud Component Model (CCM)
28. 5
3. Deployment Design
Ă In this step the application components are mapped to specific cloud resources
such as web servers, database servers , application servers etc.
Ă As the application components are loosely coupled and stateless with
asynchronous communication the components can be deployed independently.
Ă Moreover multiple clouds can be used for application deployment.
Ă This approach makes it easy to migrate application components from one cloud to
another easily.
Ă With this flexibility in application design and deployment the application
developers can ensure that the applications meet the performance and cost
requiremnets with changing contexts.
Cloud Component Model (CCM)
29. 5
Ă MVC ia apopular software design pattern for web applications.
Ă MVC pattern has three parts:
1. Model
2. View
3.Controller
Model View Controller (MVC)
30. 5
1. Model :
Ă Model manages the data and behaviour of the applications.
Ă It 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 the controller).
2. View:
Ă View prepares the interface which is shown to the users. Users interact with the
application through views.
Ă Views present the information that the model or controller tells the view to
present to the user.
Ă It also handles the user requests and sends them to the controller
Model View Controller (MVC)
31. 5
3. Controller:
Ă Controller glues the model to the view. Controller processes the user requests
and updates the model when the user manipulates the view.
Ă Controller also updates the view when the model changes.
MVC seperates the data,logic and user interface.
MVC improves the maintainability of the application and allows the reuse of code.
Applications developed using MVC can be updated easily because of the seperation
of model and view.
Both view and controller depend on the model but model doesnât depend on either ,
which allows model to be developed and tested independently.
Similarly the seperation between view and controller is also well defined for web
applications.
In MVC views can be changed without affecting model.
Model View Controller (MVC)