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