MS Cloud Day - Cloud Computing – A Crash Course for Architects

Architecting Cloud Applicationsa view on cloud scale apps
Darryl Chantry
Platform Strategy Advisor
Microsoft Singapore

Introduction
About Me
Setting expectations
Where the information comes from:

Agenda
Remember the WHY
Processes are your friends
Architectural Principles for the Cloud
Architecting Cloud Solutions
Choosing What to Move to the Cloud
Choosing Which Clouds for you
Learning to Juggle

Remember the why!
Driver
Focus Areas for Key Executives
Lower cost
of ownership
Lower total cost with higher predictability
Improved reliability
Low-cost, Enterprise class systems
with improved access
Speed to
market
Rapid access to new capabilities,
tools or capacity to deliver
Reduced
business risk
Latest features, all of the time
Improved
agility
Ability to quickly respond to customer demand, competitive or regulatory challenges
Organizational productivity
Fewer LARGE IT programs (e.g. fewer upgrades)

Processes are your friends
Why Processes
Create repeatable actions (automation)
Free time for the valuable or fun stuff
Knowledge transfer
Create processes for
Application Lifecycle Management
Managing Cloud Deployment
Managing Incidents and Problems
Managing Crisis and Escalations
Managing Change in Production

Architectural Principles for the Cloud
What are Principles
Defining Principles
Specific
Measurable
Achievable
Realistic
Testable
12 Principles I think make sense for Cloud

PR 01: Design to be monitored
Look beyond error logging, CPU, IO, or memory utilizations
Is-ness vs. Ought-ness
Monitor
All interaction points i.e. databases, 3rd party services
User behaviour
Platform behaviour (where possible)
Volatile areas of your system
Reports help with predict future requirements

PR 02: Favour asynchronous design
Synchronous design tends to higher failure rates
Scale is harder to achieve with synchronous systems
Slow synchronous calls effect all downstream actions
Look for opportunities to turn synchronous processes to asynchronous processes
BASE vs. ACID Transactions
Layer Synchronous call behind queues

PR 03: Design for multiple live sites
DR strategy is critical to most business systems
Active / Passive DR common
Run multiple live sites
Active / Active / Active
Potential cost savings
Design from ground up key
Retrofit after the fact not easy

PR 04: Favour Stateless System Design
State = Expense
Reduces scalability
Introduces points of failure
If you must have state
Measure against ROI
Attempt to store state with the client
Consider centralized state service
In multi-tenant environments segment state by customer or transaction class

PR 05: Design for scale out
Scale out offers best chance for growth
Reduces constraints for scale
Design systems to be split
By data
By transactions
By customer

PR 06: Design to scale on multiple axis
AKF Partners Scale Cube
Will discuss in detail later
Buy the book:

PR 07: N + 1 design
Design at least 1 redundant channel
Design principal of 3
1 for you
1 for customer
1 for fail
Windows Azure + SQL Azure uses this principal

PR 08: Design to handle failure
Cloud applications use 3rd party services
Design to handle service failure gracefully
Compartmentalize applications
More on this later

PR 09: Design for rollback
Critical for Web 2.0, SOA, and SaaS
Maintain backward compatibility
Make sure you can Rollback any release
Failure might show up days after release
Design to rollback, push, or deploy systems in a live environment (if possible)

PR 10: Buy when non core
Focus on competitive advantage
Focus on core competencies
Focus on strategic areas of your product or service
Commoditize everything else

PR 11: Design to be secure
Secure Software Concepts
Security Profile, Risk Management, Governance, Regulations, Privacy, Compliance, Security Models, Trusted Computing, Acquisitions

PR 12: Use mature technologies
Hard to do with cloud
However
Platforms that support industry standards
Platforms that use industry standard frameworks
Platforms that support technologies you are familiar with
Are your best option…

Architecting Cloud Solutions
Design for any technology
Creating fault isolative architectural structures
AKF cube
Splitting applications
Splitting databases

Ask the architecture question
Architecture vs Implementation
Technology agnostic design
Cost
Risk
Scalability
Availability

How to get started

Creating fault isolative architectural structures
Principles
Nothing is shared
Nothing crosses a swim lane boundary
Transactions occur along swim lanes
Approach
Swim lane the money maker
Swim lane the problem areas
Swim lane natural barriers

AKF cube
x axis split
cloning entities or data, equal distribution
least costly
limited instruction size, and dataset
y axis split
separation of work by activity or data
more costly than x split
solves instruction size, and dataset issues
creates some fault tolerance
z axis split
separation of work by customer, location, or some identifier
most costly split
Often greatest scale, solves dataset issues, may solve instruction set issues, allow for global distribution
z axis
y axis
x axis
(0,0,0)

x-axis split
x

y-axis split
y

z-axis split
z

putting it all together
z
y

Splitting databases
x-axis split

Splitting databases
y-axis split
y

Splitting databases
z-axis split
z

Choosing what to move to the Cloud
Know your self
Decision Frameworks
Partner Assessments

Choosing which Clouds for you
Know the platform architecture
Appreciate the differences

Learning to Juggle

References

Thank you!
darrylch@microsoft.com
© 2010 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.
The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

MS Cloud Day - Cloud Computing – A Crash Course for Architects

by Spiffy

Accessibility

Categories

Upload Details

Usage Rights

2 Embeds 32

Statistics

MS Cloud Day - Cloud Computing – A Crash Course for Architects Presentation Transcript

http://spiffy.sg	24
url_unknown	8