Design Consideration for Cloud Applications Agenda How cloud - - PowerPoint PPT Presentation

Design Consideration for Cloud Applications

Agenda

• How cloud applications are different?
• Quick view on challenges?
• Design consideration
• Key take away

2

How cloud applications are different?

On Demand Self service Mandatory network Pay per use (no commitment ,utility pricing)

3

Location independent resources pooling Elastic capacity scale up and scale down on demand Resources are abstract and virtualized

Design Challenges of cloud application Development

Typical cloud Application Example application Key Design challenges Traditional applications Multi-tier J2EE applications which are generally design for stable demand. Security of sensitive data, performance, availability and consistency Synchronous applications End user interaction is primary

• focus. Such as web application

where large number of users Elastic scalability. Shared nothing architecture preferably stateless. where large number of users may be hitting the application in short time. preferably stateless. Location independent resource pooling. Asynchronous applications Typically batch application which do not support end user

• interactions. They work on

large set of data, extracting, inserting data into database. Self provisioning, High reliability, Resource monitoring , Eventual consistency, multi- tenancy, vendor lock-in

4

Ref - NIST http://csrc.nist.gov/groups/SNS/cloud-computing/index.html

Grid

computing 1990s

Utility Computing Software as a service 2001s Cloud Computing Network based subscription to applications Next generation internet computing Next generation data centre Provide a scalable

Genesis of design decisions for cloud application

5

1990s

Solving large problems with parallel computing. Negotiation and management of resource sharing. Schedulers Multi domain Non commercial and public funded. Offering computing resources as metered service Remote provisioning Server virtualization Business continuity applications Progress in processors Internet access In expensive servers Distributed storage Application virtualizations Provide a scalable standard environment for network centric application development, testing, deployment. Single user provider model pay per use Single domain commercial

Genesis of design decisions for cloud application

Your Application

Your Problem Testing, Monitoring, Diagnostics, and verification

LifeCycle (Provisioning, growth, Failure, Recovery, Reallocation) Architectural View (Scalability, Availability, Recovery, Data Quality, Security)

Cloud Governance

6

Ref http://www.slideshare.net/DSPIP/cloud-computing-introduction-2978287

Facilities & Logistics Software & Hardware Infrastructure Basic Monitoring Resource Management Cloud Infra (Private or Public)

Element Management (Split Responsibility) Web of Meta Data Categories, Capabilities, Configurations & Dependencies (Provisioning, growth, Failure, Recovery, Reallocation)

Cloud Servers

Genesis of design decisions for cloud application

7

Design Consideration

Let’s

Consideration

• How to make application

more secured? Security of sensitive data at rest (Social security, Credit Card, bank account)Security of data in

Suggestions

• Have sufficient logs in application
• Use encryption to secure your sensitive data

like PII, PCI etc. at rest but store the “Key” on- premise.

• Use federated identities for Authentication.

Let’s Look at Security

account)Security of data in flight

• How to ensure data is stored

in a particular data center

• How to ensure whether

“delete” actually deleted the data from cloud & from all the places (log files, Storage, services)

• Use federated identities for Authentication.

You may use standards like SAML, OAuth etc.

• Use delegated Authorization to externalize

it from application. May use Standards like XACML.

• Use tombstone concept to ensure all data

are deleted. Data to be deleted are update with tombstone value for deletion. Delete service make sure to delete all data.

• Consider using Security Development life

cycle http://www.microsoft.com/security/sdl/defaul t.aspx

8

Design Consideration

Consideration

• How to Scale out and

scale in? Why scale up is not possible

• How to built Fault

Suggestions

• Make your application Stateless.

Defer application state. Use cache, databases, NoSQL storages etc.

• Do not use local storage of VM, as

Elastic Scalability

• How to built Fault

tolerant

• Do not use local storage of VM, as

it is not durable.

• Design your application to be

loosely coupled

• Create object as late as possible

“Late binding”

• Use Dependency Injection
• Use Service Orientation
• Use staged event driven

architecture

9

Design Consideration

Self

Consideration

• What to built inside application
• Redundancy
• Stateless behavior
• When to trigger provisioning?
• Whether binary measurement of

Suggestions

• Use automated configurations to

deploy new instance

• Use Phi accrual failure detection

to find “suspicion level” to trigger provisioning.

Self Provisioning

• Whether binary measurement of

availability is good enough? provisioning.

• Do staged deployment over cloud.

10

Design Consideration

Design

Consideration

• Should we do big bang

approach to cloud application development or staged? Suggestions

• Do staged design for cloud application.
• Suggested stages of design
• Virtualization - Virtualized infrastructure

and applications

Design life cycle

staged?

• Whether cloud

infrastructure is matured enough for reliable deployment? Should we take pessimistic approach?

• Cloud experimentation - Experiment in

EC2 : Define reference architecture

• Cloud foundation - Lay foundation of

scalable application architecture

• Cloud exploitation – select cloud

environment and begin broad base deployments : manual provisioning and deployment

• Hyper cloud – Achieve dynamic sharing
• f application workload, capacity

arbitrage, and self service application provisioning.

11

Design Consideration

Consideration

• Latency Factor
• Shared Environment
• Is it due to Hybrid

environment? Suggestions

• Fewer network calls, ask for more data

at a time. This will help controlling the throttling (some clouds throw you out if application is excessively using the bandwidth)

Performance

bandwidth)

• Use caching and replication with read

slaves.

• Keep you dynamic data closer to

compute.

• Use Multi version concurrency

control (MVCC) to avoid locking while reading.

• Use bloom filter which is a special kind
• f cache to reduce key lookups.

12

Design Consideration

Consideration

• CAP Theorem

Suggestions

• Most of cloud application

follow eventually consistency model.

• Use gossip protocol to

keep state of each servers.

Availability: Each client can always read

Weak consistency

keep state of each servers.

• Use hinted hands off for

data consistency/

• Use Multi version

concurrency control (MVCC) to avoid locking and read consistency.

13

Pick Two

Consistency: All client always has the same view of the data

Partition Tolerance: The system work well despite physical network partition

and write

Design Consideration

Consideration

• Do you know Everything

is a cost?

• Computation power is

cost

• Data storage is cost

Suggestions

• Estimate cost for different usage

scenarios including testing

• Take cost into consideration

when estimating features

• Optimize the utilization of each

Cost consideration

• Data storage is cost
• Integration is cost
• Management is a cost
• Optimize the utilization of each

resource

• Shut down the services

automatically

• Use caching, compression and

batching to minimize the data transfer

• Avoid vendor lock-in by using

standardize API to minimize switching cost.

14

Key Take Away

Analyze fitment of application for cloud Get familiar with application design patterns e.g. Gossip protocol, eventual consistency, hinted hands

• ff, bloom filter

Account for unreliability of underlying infrastructure

15

Factor cost considerations into Architecture Considerations Loosely coupled cloud application is difficult to diagnose. Avoid vendor lock-in by the use of standard API and abstraction

Thanks