Windows Azure: Is the Relational Database Dead?

1. Windows Azure: Is the Relational Database Dead? Benjamin Day http://benday.com

2. Who am I? • Owner, Benjamin Day Consulting, Inc. • Email: benday@benday.com • Web: http://www.benday.com • Blog: http://blog.benday.com • Trainer, Consultant • Visual Studio Team System, Team Foundation Server • Microsoft MVP for VSTS • Microsoft VSTS/TFS Customer Advisory Council • Microsoft Cloud Services Advisory Group • Leader of Beantown.NET INETA User Group

3. Agenda • Big thanks to • Steve Marx @ Microsoft • Manuvir Das @ Microsoft • David Aiken @ Microsoft • Is the relational database dead? • What is Windows Azure? • Develop Your Application • Deploy To Staging and Production • Some Stuff To Think About

4. Is the relational database dead? • It depends. • (Probably not.) • Cloud will change everything. • Relational database “best practices” are probably dead……at least in the cloud.

5. Azure

6. The Azure Platform

7. The Azure Platform

8. The “cloud” in Cloud Services? • Think data-center somewhere on the internet • Allows you to run your app • Allows you to read and write data

9. Ok. So what’s Windows Azure? • Microsoft’s “cloud” • Every cloud has an Azure lining? • Custom version of Windows • Optimized for utility computing applications • Always runs virtualized on the Azure Fabric • Azure Fabric • Runs instances of your apps • Handles “everything” • Azure Storage • Azure SDK for Visual Studio

10. Why Azure? • “I’ve got my awesome data-center so…” • No more worrying about… • Buying, configuring, maintaining hardware • Buying, configuring, maintaining the operating system • Network infrastructure • Routers, Switches, Load Balancers • Your data-center’s power and internet connections • Failovers • Worry less about… • App deployment • Capacity planning • Focus on writing your app

11. Simple Scale Out • Changes in traffic • Need more servers? • Need fewer servers?

12. I want everything… • …and it should be easy. • Azure let’s you worry about writing your app • Don’t have to learn a whole bunch of new stuff • Leverage your existing dev skills

13. Azure: The Developer View • Write it in Visual Studio • New project types • Debug your code • .NET, ASP.NET, WCF, IIS7, LINQ • Azure Storage • Database in the cloud • (with a few caveats) • Desktop development versions of • Azure Fabric • Azure Storage

14. Demo 1: Hello, World

15. Hello, World: Discuss. • Doesn’t look like much but… • that’s “internet scale”-able • Highly available • Mostly stuff you already know

16. Debugging In The Cloud • We can debug a service in Visual Studio • How do you debug a service that has been deployed? • Answer: you don’t • Logging is the answer • RoleManager.WriteToLog(eventLogName, message) • Event log name values: Error, Information, Warning, Debug, Critical

17. Demo 1.1: Hello World + Logging

18. Azure Storage

19. Azure Storage • Simple database in the cloud • Tables (aka. “structured storage”) • Blobs • Queues • You don’t worry about replication • Scales like nobody’s business • Development version • DevelopmentStorage.exe • Uses SQL Server Express

20. Table Storage • Every row has RowKey & Partition Key • RowKey = primary key • PartitionKey • Helps you tell Azure how to scale your data • You have to think about how you’ll be querying • By State? By Hour? Other?

21. PartitionKey • Your partitions could be on different servers • Best practice: If you know your PartitionKey, add it to the WHERE clause • No PartitionKey in the WHERE  insane table scans • Recommendation: More partitions is (probably) better • Think hard about your partition key in the beginning • Else, roll your own re-partitioning

22. Column Data Types • Partition key and Row key • String (up to 64KB) • Other properties • String (up to 64KB) • Binary (up to 64KB) • Bool • DateTime • GUID • Int • Int64 • Double

23. Demo 2: Azure Table Storage

24. Relational vs Cloud

25. What is “relational” • Tables, Rows, & Columns • All rows in the table have the same column structure • You design the database BEFORE you add the data • Relationships between the tables • Constraints on the columns • Normalization eliminates duplicate data • Data “nuggets” stored in one place only • Makes it clear what the definitive version is

26. Relational in your app • Data is organized for the sake of the data rather than the sake of the app • App is temporary but Schema is forever. • Represents itself as normalization and relationships between the tables • Scales nicely on a single node but going to a cluster, it gets ugly

27. Relational DB Engine Does A Lot • Non-trivial • SELECT p.FirstName, p.LastName, ph.PhoneNumberFROMPerson pLEFT JOINPhone phONp.Id = ph.PersonIdWHEREp.LastName LIKE 'D%'

28. Performance Issues in Relational • Avoiding duplication can cause performance issues • De-normalizing • If you de-normalize and duplicate some data: • you can lower the number of required to build an "object" • You can lower the amount of "heavy lifting" that the db has to do to retrieve your data • That JOIN isn't easy • Indexes help but it still is a lot of work

29. Why Stored Procedures? (1 of 2) • Abstraction between the app & data • Externalize the queries • Remove them from the code • Makes the queries live with the data  more "database me meme!"

30. Why Stored Procedures? (2 of 2) • Security • lock down direct access to the tables • Users get rights to specific procs • Performance • Less compelling: cached execution plan • Largely irrelevant after SQL Server 7 • More compelling: the query logic is near the data

31. Stored Procedures In The Cloud • Azure can distribute physical location of data by partition key • Is the stored proc near the data anymore? • (Well, that pretty much wraps it up for stored procedures.)

32. What you won’t get in Azure Storage • Stored Procedures • Views • Triggers • Foreign Keys • Database enforced referential integrity • User defined indexes • (Maybe later.)

33. While I’ve “dissed” relational… • I’m not saying “skip best practices.” • Don’t put everything in the same table • You’ll still have relationships between tables • …the relationships just won’t be enforced by the DB

34. The Verdict?

35. What do you think?

36. Ok. Moving on.

37. More Than Just ASPX

38. Utility Compute without a UI • Azure uses the concept of “Roles” • Hello, World used a “Web Role” • The other role is a “Worker Role” • Think windows service in the cloud

39. Web & Worker

40. Demo 3: Worker Role and a Queue • In a web role, create an ASP.NET page • Creates a queue • Writes to a queue • Gets queue depth • Worker Role • Reads the queue • “Processes” the message

41. Deployment

42. Demo 4: Deploy To The Cloud • Change the storage config to use production servers

43. Miscellaneous

44. Things to think about • No foreign keys • No triggers • No stored procedures • In Table storage, strings can only be 64k • You’ll need to use a mix of Blob and Tables • Think hard about what config values you put in web.config/app.configvsServiceConfiguration.cscfg

45. The Big Questions • When? • Sometime in 2009 • An actual Service Level Agreement (SLA) • More data-centers • Now in US only • Global at go-live • What will it cost? • It will depend on what you use

46. More resources • My Blog • http://blog.benday.com • Sample code • More Azure content to come… • Steve Marx’s blog • http://blog.smarx.com/ • Evangelist for the Azure team • Azure.com

47. Final questions?

48. Who am I? • Owner, Benjamin Day Consulting, Inc. • Email: benday@benday.com • Web: http://www.benday.com • Blog: http://blog.benday.com • Trainer, Consultant • Visual Studio Team System, Team Foundation Server • Microsoft MVP for VSTS • Microsoft VSTS/TFS Customer Advisory Council • Microsoft Cloud Services Advisory Group • Leader of Beantown.NET INETA User Group