MS Cloud Day - Cloud Computing – A Crash Course for Architects
Upcoming SlideShare
Loading in...5

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






Total Views
Views on SlideShare
Embed Views



5 Embeds 37 24
url_unknown 8 2 2
http://localhost 1



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

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

  • 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!
    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
    Rapid access to new capabilities,
    tools or capacity to deliver
    business risk
    Latest features, all of the time
    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
    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
    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
    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
  • Design for any technology
    How to get started
  • Creating fault isolative architectural structures
    Nothing is shared
    Nothing crosses a swim lane boundary
    Transactions occur along swim lanes
    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
  • Splitting applications
    x-axis split
  • Splitting applications
    y-axis split
  • Splitting applications
    z-axis split
  • Splitting applications
    putting it all together
  • Splitting databases
    x-axis split
  • Splitting databases
    y-axis split
  • Splitting databases
    z-axis split
  • 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!
    © 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.