• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
MS Cloud Day - Cloud Computing – A Crash Course for Architects
 

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

on

  • 1,278 views

 

Statistics

Views

Total Views
1,278
Views on SlideShare
1,242
Embed Views
36

Actions

Likes
0
Downloads
29
Comments
0

4 Embeds 36

http://spiffy.sg 24
url_unknown 8
http://192.168.6.184 2
http://192.168.6.179 2

Accessibility

Categories

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.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
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!
      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
    • 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
      z axis
      y axis
      x axis
      (0,0,0)
    • Splitting applications
      x-axis split
      x
    • Splitting applications
      y-axis split
      y
    • Splitting applications
      z-axis split
      z
    • Splitting applications
      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.