Building Highly Scalable and Available Applications and Services with Windows Azure AppFabric MID315

2. Building Highly Scalable and Available Applications and Services with Windows Azure AppFabricMID315 Bob Schmidt Program Manager Microsoft

3. Session Objectives • Provide an overview of AppFabric Application Development • Discuss key choices & tradeoffs when building highly scalable and available applications • Introduce stateful services

4. Service Bus Integration AppFabric: Next-generation Middleware Platform A platform and middleware services for Cloud and Server applications Applications Caching AppFabric Developer Tools Access Control AppFabricContainer SQL Server SQL Azure Windows Server Windows Azure Composition Model AppFabric Services AppFabric App Manager Custom Code Data Tier Web Tier Workflows Web Services Server Cloud

5. AppFabric Value Pillars • Ease of developmentQuickly build services and applications in Visual StudioUtilize infrastructure services provided by Microsoft • Low TCODevelop, deploy, and manage an application as a single logical entityRun middle tier logic in a high density container to optimize resource usage • Highly scalable and available applicationsFabric applications automatically benefit from load balancing, partitioning, failover, and state management provided by the platform • Cloud and premise symmetry

6. What’s in the Box (June CTP) • Custom web and middle tier logic • ASP.NET • WCF • WF • Code • Platform Infrastructure & Storage Services • AppFabric Cache • AppFabric Service Bus • AppFabric Access Control • Azure storage • SQL storage

7. AppFabric Developer Tools demo

8. Application Design Goals Distributed application requirements can include: • Performance • Scalability • Availability • Data Consistency • Security • Manageability • Serviceability • Portability • Cost An effective application platform must allow different apps to make different tradeoffs and choices about how to best meet operational and behavioral requirements One key aspect of application design is state management…

9. State Management • An app is state + logic (behavior) • Where is the state in your app? • Many choices supported by AppFabric out of the box • SQL storage • Azure storage • AppFabric cache • AppFabric stateful services (new!) • The right design for an app depends upon the scenario • Size and growth of the data set(s) • Read, write, and query patterns • Latency requirements • Data consistency requirements • Storage costs • …

10. Stateless App Design • Popular app design approach is to make as many components as possible stateless • A stateless component can be cloned • Inbound requests can be handled by any clone • Provides scalability, high availability (of the component) • Application state doesn’t disappear • Statelessness means pushing state away from the app logic • Introduces contention for the shared resource managing the state • Session state (shared by a set of requests) is common

11. Need to manage session state Clients LOAD BALANCER Clients Clients Presentation Presentation Presentation LOAD BALANCER Presentation Data Presentation Business Logic Need to manage a pool of connections

12. Adding a Cache • Bring data closer to the logic operating on it • Reduce contention on a shared resource • Need to carefully consider data consistency requirements • Internally, the cache is partitioned in order to scale • Different nodes are responsible for different cache items • Internally, the cache can use replication to achieve high availability • Can become the “primary” storage location for the data • Application development trend toward bringing (some) data off disk and out from behind relational abstraction

13. Clients LOAD BALANCER Clients Clients Presentation Presentation Presentation LOAD BALANCER Presentation Data Presentation Business Logic Cache A-F G-M N-P Q-Z

14. Stateful Services • Co-locate state and the logic that manipulates that state • Partition for scale • Divide the state up into n parts so that each node is responsible for a non-overlapping subset of the requests to access the state • Inbound requests are routed to the right node by the “router” • Replicate for high availability • Automatic failover • Relies on the same partitioning and replication infrastructure that the AppFabric Cache uses internally

15. Requests are routed to the right partition Clients LOAD BALANCER Clients Clients Presentation Presentation Presentation ROUTER Presentation Presentation Business Logic A-F G-M State and logic are co-located

16. class ShoppingCartService : IShoppingCart • { • // There is no copy of this data -> single point of failure • private Cart cart; • public void AddItem(Item item) • { • this.cart.AddItem(item); • } • public void RemoveItem(ItemID id) • { • this.cart.RemoveItem(id) • } • public CartInfoGetCartInfo() • { • return this.cart.Info; • } • }

17. class ShoppingCartService : IShoppingCart • { • public void AddItem(Item item) • { • Cart cart = this.LoadCart(); // Network latency • cart.AddItem(item); • this.SaveCart(cart); // Network latency, maybe a write conflict • } • public void RemoveItem(ItemID id) • { • Cart cart = this.LoadCart(); // Network latency • cart.RemoveItem(id) • this.SaveCart(cart); // Network latency, maybe a write conflict • } • public CartInfoGetCartInfo() • { • Cart cart = this.LoadCart(); // Network latency • return cart.Info; • } • }

18. class ShoppingCartService : IShoppingCart • { • [Replicable] • private Cart cart; • [ReplicateOnExit] • public void AddItem(Item item) • { • this.cart.AddItem(item); • } • [ReplicateOnExit] • public void RemoveItem(ItemID id) • { • this.cart.RemoveItem(id) • } • public CartInfoGetCartInfo() • { • return this.cart.Info; • } • }

19. Stateful WCF Service demo

20. Partitioning Example • It’s important to choose a good partitioning strategy • Partitioning of shopping carts • Could use first letter of cart owner’s user name • Partitions are: { “A”, “B”, … “Z” } (aka 1-26) • Possibly an uneven distribution • Could assign a unique identifier to each cart • Hash the cart id to a partition id in the range 1..n • More evenly distributes the state

21. Scalability of a Stateful Service Service with n partitions 2 1 (each is a partition) The initial load on the service can be handled with 2 machines, each owns n/2 partitions. 8 4 7 2 3 1 6 5 10 9 The app is popular and load is increasing. We add machines and partitions are automatically spreadacross them. It will scale out further should the need arise. 4 2 3 1 5 The app is being used less. It’s easy to scale back down as load decreases.

22. Availability of a Stateful Service Let’s look at one partition 1 Without copies (secondary replicas) this is a single point of failure. 1 x We configure the service to maintain n copies per partition. [In this example, 2] 1 If the machine hosting the primary replica fails, one of the secondary replicas becomes the new primary.A new secondary is also instantiated in order to maintain the desired redundancy.

23. Data Consistency • Synchronous replication • Inbound request is held until replication completes • Strong consistency, but higher latency • Asynchronous replication • Occurs sometime after inbound request • Weaker consistency, but lower latency • These tradeoffs have traditionally been made in the DB • Techniques can be borrowed and used in the middle tiere.g. handling read requests on secondaries

24. Getting Started with Stateful Services • Choose a partition policy • Hash-based [string -> 1..n] • Fixed set of keys [e.g. “A”, “B”, “C”] • Indicate what to replicate, when to replicate • [Replicable], Replicable<T> • [ReplicateOnExit], ReplicationScope • If needed… • Configure write-through or write-behind to secondary storage • Participate in memory management (handle low memory situations) • Participate in low level replication operations • WCF is a natural choice for many scenarios • Can also derive from StatefulServiceReplica base class

25. The Big Picture AppFabric Dev Tools AppFabric App Manager Publish [Application Definition][Application Artifacts] Deploy to Container Deploy to Web Fabric Node RO U T E R Fabric Node Azure Web Role Fabric Node Fabric Node Fabric Node Clients

26. Summary • Experiment with the Azure AppFabric June CTP • Can start with simple services & workflows • Use AppFabric infrastructure services • Build end to end applications • Explore options for state management Tell us what you think - your feedback matters!

27. Service Bus Integration Timeline: AppFabric CY11 Strategy: 2-3 releases/year on Azure, 2-3 year release cadence on Server April May June CY11 H2 GA – Caching GA – Access Control CTP – Pub/Sub CTP - Queues CTP – AF Dev Tools CTP – AF App Mgr CTP – WF/WCF GA – SB Pub/Sub & Queues CTP2 – Dev Tools/App Mgr/WF/WCF CTP – Integration Caching Access Control CTP2 AppFabric Developer Tools GA GA GA CTP CTP2 AppFabric Container Composition Model Custom Code AppFabric App Manager CTP2 Workflows Web Services Cloud

28. Required Slide Speakers, please list the Breakout Sessions, Interactive Discussions, Labs, Demo Stations and Certification Exam that relate to your session. Also indicate when they can find you staffing in the TLC. Related Content • MID201 An Overview of the Microsoft Middleware Strategy • MID310 Windows Communication Foundation Futures • COS318 A Lap around Windows Azure AppFabric • COS311 Introduction to Windows Azure AppFabric Composite Applications • MID313 Workflow in Windows Azure AppFabric • MID271-INT Futures: Integration Capabilities in Windows Azure AppFabric

29. Resources • Connect. Share. Discuss. http://northamerica.msteched.com Learning • Sessions On-Demand & Community • Microsoft Certification & Training Resources www.microsoft.com/teched www.microsoft.com/learning • Resources for IT Professionals • Resources for Developers • http://microsoft.com/technet • http://microsoft.com/msdn

30. Required Slide Complete an evaluation on CommNet and enter to win!

31. Required Slide Your MS Tag will be inserted here during the final scrub. MS Tag Placeholder Slide

32. © 2011 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.