Extend Your Application to the Cloud with SQL Azure Database

Editor's Notes

• #4: “At the end of this session we will give away this Dell Netbook (hold it up to show it to the crowd).  To enter this free drawing please fill out this card (hold up a sample) and we’ll collect them at the end.  If you need a card raise your hand and we’ll get one to you.   We’ll draw a winner at the end of my presentation and the winner must be present to win. When you turn in your card you will receive an 8GB USB stick”.
• #8: Initial services – core RDBMS capabilities as a service SQL Azure Database(SADB), Data SyncFuture OfferingsAdditional data platform capabilities as a service: BI/DSS, DWNew services: Reference Data, Secure Data HubSQL Azure is an umbrella brand that covers all the services we intend to offer over time. Post v1 services are in grey. Data sync will be in CTP.Key takeaway: Start with core RDBMS features and expand from there. Integrate with on-premise SQL.High-Value Database ServicesRich data platform capabilities as a service: Reporting, Analytics, Integration, DW, … New services: Data Hub, DataPlex, Association Hub (Data->Information), …Extending our Data Platform to the cloud, generating a network effect:Benefit cloud business with Enterprise connectionsBenefit Enterprise business with cloud connectionsEnable new uses of data to drive additional business value – e.g. “Federated data”
• #9: I looked at how I could port one of the DB to SDS and what kind of changes that are required. Here are the ones by simply looking at the scripts, and those are the ones you can talk about during demo, although it will run against a local SQL instance. No “use” support, so in code it will have to specify different connection string. Not to “USE DB” at the beginning of the scriptsLogin creation can’t be done via “sp_addlogin” (deprecated), instead use ‘create login”.User can’t be created via “sp_grantdbaccess” (deprecated), instead use ‘create user’.All table will need to have a clustered index (via defining primary key in most cases).
• #10: This slide describes four common customer scenarios that SADB supportsDepartmental ApplicationsSimple application built by individual or departmentNeed simple deployment, self-management, IT: “Empowerment and Governance”Web applicationsSmall business or startup that uses the cloud as their ITSimple deployment, self-management, scale on demandISVISV hosting software on behalf of customerMulti-tenant support for billing and isolationData hub (shortly after V1)Sharing and aggregating of data across tiers and across enterprisesCentralized place for data, high scale, sync with existing data sourcesDepartmental workgroup applicationsBuilt with SQL Express or AccessSmall in size, 5 GB or lessLess than 10,000 rowsSmall number of concurrent users (tens)Owned by a department, not central IT.Often grows out an excel spreadsheet or Access databaseTypically one of the following types:Tracking app (purchase orders changes)Simple reporting app (CSS tool for tracking issues)Commonly pulls reference data from other systems.Simple security needs (a set of people all get read access, with a small number of people with Admin access)Do not have a dedicated DBA (usually managed by a department level IT helper or a technically savvy IW)Developer often a technically savvy IW. Especially for the Access apps.Web applicationsTypically built by a small development team with no little or administrative capabilitiesNeed to start small, but then be able to scale-up quickly and easily as required.Data HubsSecure data hubs enable you to consolidate existing data store investments and access them through a single cloud-based hub. The security features provided by the SADB platform ensure movement of, and access to your data is secure at all times. This enables you to develop or modify applications to provide geo-dispersed data access and enables the complete mobility of your workforce. You can be certain that if your employees have access to the internet they have access to their data!ISVs and SaaS ProvidersGrowing trend towards cloud-based LOB application offerings.Need global reach and scalability with the ability to quickly provision multiple tenants and manage billing
• #11: Familiar SQL Server relational modelUses existing APIs & toolsFriction free provisioning and reduced managementBuilt for the Cloud with availability and scaleFocus on combining the best features of SQL Server running at scale with low friction
• #23: Familiar SQL Server relational modelUses existing APIs & toolsFriction free provisioning and reduced managementBuilt for the Cloud with availability and scaleFocus on combining the best features of SQL Server running at scale with low friction
• #24: Most valuable things we did was to flesh out the system was to take on an internal partner. EHA is that partner EHA is that partnerEHA is a high scale archiving system. They take email from on premise Exchange servers and store in their system. This is useful for companies that need to adhere to strict compliance laws (like Sarbanes Oxley). It results in very large data sets, tens of terabytes for the larger customers.EHA had built their first version using standard scale up pattern. Each customer got their own database on a single machine. The data for the larger customers was stored in a SAN. This architecture had two issues. One was that they hit a limit on the amount data they could process. This limited them from taking on customers that exceeded that limit. The second is a problem inherent in the archival pattern itself. In the archival pattern you mostly do lots of inserts in the steady state. This requires a lot of I/O capacity but not as much processing. Then you occasionally have to do a massive query across the data set. The processing for the queries is high because of the amount of data but you only need for a short period of time. That means you need to have enough hardware for the queries but it doesn’t get used for much of the time.The solution was to build on SADB using a scale out pattern where a given customer’s data is spread out over multiple nodes. Then when a query comes in it can be distributed across all the nodes where that customer data lives. Because most customers don’t query that often each query gets to harness the full computing power of the box for that query achieving better utilitization and therefore lower cost. In addition, it turns out this pattern is more performant than the pattern they had before and had a order of magnitude increase in query perf.Working with EHA has been a win win for both us and them. It helped them improve the scale and cost efficiency of their app. And it was tremoundously valuable for us to help us prove out our design and tune our system to handle a real production workload from real paying customers.