Embed Size (px)
DESCRIPTION
Citation preview
Architecting Cloud Applicationsa view on cloud scale apps
Darryl ChantryPlatform Strategy AdvisorMicrosoft 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
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
Requirements Design Development Testing
AcceptanceDeploymentOperations / MaintenanceDisposal
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
Design for any technology
>Ask the architecture question• Architecture vs Implementation
>Technology agnostic design• Cost• Risk• Scalability• Availability
Design for any technology
>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
x axis
y axis
z axis
(0,0,0)
Splitting applications
>x-axis split
x
Splitting applications
>y-axis splity
Splitting applications
>z-axis split
z
Splitting applications
>putting it all together
y
z
Splitting databases
>x-axis split
Splitting databases
>y-axis splity
Splitting databases
>z-axis splitz
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
The Art of Scalability Scalable Web Architecture, Processes, and Organizations for the Modern Enterprise • Martin L Abbott, Michael T Fisher• AKF Partners
Moving Applications to the Cloud on Microsoft Azure• Eugenio Pace, Et Al• Microsoft Patterns and Practices
Architecting Cloud Applications – The Essential Check List• Anna Liu• UNSW
Just Enough Software Architecture• George H Fairbanks
Thank you!
© 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.
