Architecting for the Cloud

1. Richard Blewett Architecting for the Cloud

2. Agenda • The Problem Space • Managing State • Architect for Change • Dealing with Failure

3. Scaling Mainframe Approach

4. Scaling Cloud Approach

5. Effects of scaling • Applications run on many machines concurrently • Every request may hit a different machine • Hardware fails

6. Statelessness is King • Statelessness: Local state of any kind is unreliable • Store critical state in Azure Storage or SQL Azure • See Eric Nelson’s talk for more details

7. .NET Services Service Bus

8. Don’t be Scared of the Service Bus • Messaging backbone for the cloud • User Service Bus to bridge in-flight cloud data to full data on premise • Enables rich message exchange patterns

9. Prefer Asynchrony Synchrony is a form of coupling • Connect components using queues • Azure queue storage

10. Asynchrony = Load Levelling

11. Asynchrony = Scalability

12. Its OK to Degrade • Some functionality is mission critical • Other functionality can wait • Degrade service to maintain mission critical functionality • You can do everything else later

13. Not Everyone Needs Perfect Consistency • Many services move though “inconsistent” states • Email • IM • SMS

14. Update is Hard • Difficult to update and remain available • Design for rolling update • Azure supports two concurrent deployed versions • Azure will support update groups Update Group 1 Update Group 2 Update Group 3

15. Update Code *or* Data • Do not update code and data at the same time • Design data to handle multiple code versions • Design code to handle multiple data versions

16. Maintain Compatibility • Make sure that you can roll back change without breaking everything

17. Timing of Update can be Hard • Depends on location of users • Depends on work pattern of users • Don’t forget the Pacific Ocean is big with a low population

18. Change is Inevitable • Expect things to change • Don’t hard-code values • Use azure config string val = RoleManager.GetConfigurationSetting("LoggingLevel");

19. Azure configuration .csdef <ServiceDefinition name="PhotoGallery"> <WebRole name="WebRole"> ... <ConfigurationSettings> <Setting name="LoggingLevel" /> </ConfigurationSettings> </WebRole> </ServiceDefinition> .cscfg <ServiceConfigurationserviceName="PhotoGallery"> <Role name="WebRole"> <Instances count="1"/> <ConfigurationSettings> <Setting name="LoggingLevel" value="Error"/> </ConfigurationSettings> </Role> </ServiceConfiguration>

20. What Just Happened? • Debugging and Diagnostics non-trivial • Use local fabric for testing • Test against local storage • Test against cloud storage

21. Tracing is Key • Add trace statements in code • Can be filtered on log level from config • Critical errors raised as alerts if( RoleManager.GetConfigurationSetting("LoggingLevel") == "Verbose") { RoleManager.WriteToLog("Information", "Product Purchased"); }

22. Failures Often Transient • Build retry logic into your code • Remember to stop retrying eventually

23. Failures Can be “Catastrophic” • Don’t assume your “shutdown” logic will be executed • Try to keep state consistent enough at all times • Think about sanity checking on start

24. Fault Domains • Fault domains allow you divide application for fault tolerance • Not available yet Fault Domain 1 Fault Domain 2 Fault Domain 3

25. The Challenges are Not Just Technical • Cost • Estimating • Actual • Lock-in • Vendors have vested interest • Legal • Where is my data?

26. Thanks for coming Q & A richard@rocksolidknowledge.com http://rocksolidknowledge.com/blogs