Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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


Published on

Published in: Technology, Business
  • Be the first to comment

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

  1. 1. Architecting Cloud Applicationsa view on cloud scale apps<br />Darryl Chantry<br />Platform Strategy Advisor<br />Microsoft Singapore<br />
  2. 2. Introduction<br />About Me<br />Setting expectations<br />Where the information comes from:<br />
  3. 3. Agenda<br />Remember the WHY<br />Processes are your friends<br />Architectural Principles for the Cloud<br />Architecting Cloud Solutions<br />Choosing What to Move to the Cloud<br />Choosing Which Clouds for you<br />Learning to Juggle<br />
  4. 4. Remember the why!<br />Driver<br />Focus Areas for Key Executives<br />Lower cost <br />of ownership <br />Lower total cost with higher predictability <br />Improved reliability<br />Low-cost, Enterprise class systems <br />with improved access<br />Speed to <br />market<br />Rapid access to new capabilities, <br />tools or capacity to deliver <br />Reduced<br /> business risk <br />Latest features, all of the time<br />Improved <br />agility<br />Ability to quickly respond to customer demand, competitive or regulatory challenges <br />Organizational productivity<br />Fewer LARGE IT programs (e.g. fewer upgrades)<br />
  5. 5. Processes are your friends<br />Why Processes<br />Create repeatable actions (automation)<br />Free time for the valuable or fun stuff<br />Knowledge transfer<br />Create processes for<br />Application Lifecycle Management<br />Managing Cloud Deployment<br />Managing Incidents and Problems<br />Managing Crisis and Escalations<br />Managing Change in Production<br />
  6. 6. Architectural Principles for the Cloud<br />What are Principles<br />Defining Principles<br />Specific<br />Measurable<br />Achievable<br />Realistic<br />Testable<br />12 Principles I think make sense for Cloud<br />
  7. 7. PR 01: Design to be monitored<br />Look beyond error logging, CPU, IO, or memory utilizations<br />Is-ness vs. Ought-ness<br />Monitor<br />All interaction points i.e. databases, 3rd party services<br />User behaviour<br />Platform behaviour (where possible)<br />Volatile areas of your system<br />Reports help with predict future requirements<br />
  8. 8. PR 02: Favour asynchronous design<br />Synchronous design tends to higher failure rates<br />Scale is harder to achieve with synchronous systems<br />Slow synchronous calls effect all downstream actions<br />Look for opportunities to turn synchronous processes to asynchronous processes<br />BASE vs. ACID Transactions<br />Layer Synchronous call behind queues<br />
  9. 9. PR 03: Design for multiple live sites<br />DR strategy is critical to most business systems<br />Active / Passive DR common<br />Run multiple live sites<br />Active / Active / Active<br />Potential cost savings<br />Design from ground up key<br />Retrofit after the fact not easy<br />
  10. 10. PR 04: Favour Stateless System Design<br />State = Expense<br />Reduces scalability<br />Introduces points of failure<br />If you must have state<br />Measure against ROI<br />Attempt to store state with the client<br />Consider centralized state service<br />In multi-tenant environments segment state by customer or transaction class<br />
  11. 11. PR 05: Design for scale out<br />Scale out offers best chance for growth<br />Reduces constraints for scale<br />Design systems to be split<br />By data<br />By transactions<br />By customer<br />
  12. 12. PR 06: Design to scale on multiple axis<br />AKF Partners Scale Cube<br />Will discuss in detail later <br />Buy the book:<br />
  13. 13. PR 07: N + 1 design<br />Design at least 1 redundant channel<br />Design principal of 3<br />1 for you<br />1 for customer<br />1 for fail<br />Windows Azure + SQL Azure uses this principal<br />
  14. 14. PR 08: Design to handle failure<br />Cloud applications use 3rd party services<br />Design to handle service failure gracefully<br />Compartmentalize applications<br />More on this later <br />
  15. 15. PR 09: Design for rollback<br />Critical for Web 2.0, SOA, and SaaS<br />Maintain backward compatibility<br />Make sure you can Rollback any release<br />Failure might show up days after release<br />Design to rollback, push, or deploy systems in a live environment (if possible)<br />
  16. 16. PR 10: Buy when non core<br />Focus on competitive advantage <br />Focus on core competencies <br />Focus on strategic areas of your product or service<br />Commoditize everything else<br />
  17. 17. PR 11: Design to be secure<br />Secure Software Concepts<br />Security Profile, Risk Management, Governance, Regulations, Privacy, Compliance, Security Models, Trusted Computing, Acquisitions<br />
  18. 18. PR 12: Use mature technologies<br />Hard to do with cloud<br />However<br />Platforms that support industry standards<br />Platforms that use industry standard frameworks<br />Platforms that support technologies you are familiar with<br />Are your best option…<br />
  19. 19. Architecting Cloud Solutions<br />Design for any technology<br />Creating fault isolative architectural structures<br />AKF cube<br />Splitting applications<br />Splitting databases<br />
  20. 20. Design for any technology<br />Ask the architecture question<br />Architecture vs Implementation<br />Technology agnostic design<br />Cost<br />Risk<br />Scalability<br />Availability<br />
  21. 21. Design for any technology<br />How to get started<br />
  22. 22. Creating fault isolative architectural structures<br />Principles<br />Nothing is shared<br />Nothing crosses a swim lane boundary<br />Transactions occur along swim lanes<br />Approach<br />Swim lane the money maker<br />Swim lane the problem areas<br />Swim lane natural barriers<br />
  23. 23. AKF cube <br />x axis split<br />cloning entities or data, equal distribution<br />least costly<br />limited instruction size, and dataset<br />y axis split<br />separation of work by activity or data<br />more costly than x split<br />solves instruction size, and dataset issues<br />creates some fault tolerance<br />z axis split<br />separation of work by customer, location, or some identifier<br />most costly split<br />Often greatest scale, solves dataset issues, may solve instruction set issues, allow for global distribution<br />z axis <br />y axis<br />x axis<br />(0,0,0)<br />
  24. 24. Splitting applications<br />x-axis split<br />x<br />
  25. 25. Splitting applications<br />y-axis split<br />y<br />
  26. 26. Splitting applications<br />z-axis split<br />z<br />
  27. 27. Splitting applications<br />putting it all together<br />z<br />y<br />
  28. 28. Splitting databases<br />x-axis split<br />
  29. 29. Splitting databases<br />y-axis split<br />y<br />
  30. 30. Splitting databases<br />z-axis split<br />z<br />
  31. 31. Choosing what to move to the Cloud<br />Know your self <br />Decision Frameworks<br /> Partner Assessments<br />
  32. 32. Choosing which Clouds for you<br />Know the platform architecture<br />Appreciate the differences<br />
  33. 33. Learning to Juggle<br />
  34. 34. References<br />
  35. 35. Thank you!<br /><br />© 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.<br />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.<br />