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

2. Introduction About Me Setting expectations Where the information comes from:

3. 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

4. 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)

5. 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

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

7. 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

8. 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

9. 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

10. 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

11. 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

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

13. 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

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

15. 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)

16. 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

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

18. 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…

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

20. Design for any technology Ask the architecture question Architecture vs Implementation Technology agnostic design Cost Risk Scalability Availability

21. Design for any technology How to get started

22. 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

23. 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)

24. Splitting applications x-axis split x

25. Splitting applications y-axis split y

26. Splitting applications z-axis split z

27. Splitting applications putting it all together z y

28. Splitting databases x-axis split

29. Splitting databases y-axis split y

30. Splitting databases z-axis split z

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

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

33. Learning to Juggle

34. References

35. 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.