News

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

MIX 09: Nigel Ellis on Azure SQL Data Services

Posted by Jean-Jacques Dubray on Mar 20, 2009

Sections: Operations & Infrastructure,; Architecture & Design,; Development
Topics: Ruby ,; SQL Server 2008 ,; Java ,; SQL Server ,; Azure ,; Dynamic Languages ,; ADO.NET ,; .NET ,; Languages ,; Relational Databases ,; Microsoft ,; PaaS ,; Companies ,; Programming ,; Architecture ,; Cloud Computing ,; SQL Data Services ,; Transactions ,; Database ,; Astoria

Nigel Ellis, Architect at Microsoft, presented today the new relational model of Azure SQL Data Service, which was announced a couple of weeks ago on the team's blog. As an introduction he explained that data platforms have grown very complex since the integration of durable media with computing. A data platform is basically composed of places, types and services. He argued:

Nowadays, data platforms can deal with a lot of types of data: in memory, multi-dimensional, XML, files. In addition to the original CRUD services, they offer: caching, analysis, protection, load, backup, mining, integration, sync, reporting, search... and data needs to be managed in a lot more places: mobile, desktop, server, mega server...

Nigel also noticed that a lot of the data management is policy-based and happens by expressing intent.

The key elements of Azure SQL Services include:

A database-as-a-Service
Some Services: Data Synchronization, Reference Data Management, Business Intelligence, and Reporting
A data hub integration with on-premise SQL Server 2008

The SDS team added recently a familiar SQL Server relational model which is based on existing SQL Server APIs and tools. However, SDS is specifically build for the cloud in terms of availability and scale. The key is that SDS is accessible from all platform, including PHP, Ruby and Java. Nigel demonstrated how the built a blog web site using a PHP WordPress implementation which invokes SDS via an ODBC driver.

This week, at MIX 09, the SDS team announced support for full trust and native code.

The SDS API which was previously based on REST and ACE has been entirely replaced by TDS and TSQL. You can still expose a REST interface by using Astoria in a Compute Cloud Resource connecting to SDS in the back-end. You may also use the ADO.NET+EF or new SQL Client library which connects to SDS. TDS for instance works well over high latency connections.

Nigel talked about the Service Provisioning Model: each account has a billing relationship, and owns one ore more virtual servers

Each server has one or mode database including a virtual master. Each database is limited in size, currently, the limit is 5-10 Gb. Each database has one or more logins (SQL users). The Authentication and Authorization mechanism is identical to the one of SQL Server 2008. As a matter of fact, Nigel stressed that you can start developing your application targeted at SDS today, simply by using SQL Server Express 2008.

The SDS infrastructure manages request routing, security and isolation. It also provides a scalable, highly available technology which include:

Automatic replication and failover
The "fabric" delivers the high availability -it would switch requests from one server to another one, should a server go down
Provisioning (db, accounts, roles,...), metering and billing
Load Balancing: if one specific server is really busy, we can take a replica and move one of the secondary replicas and make it primary, we can also clone a replica and more it to another server.

Nigel detailed the compatibility goals of SDS:

Support common application patterns
Logical/policy based administration
Patterns from Server to Cloud (and back)
Multi-tenancy considerations
Throttling and load balancing
Limits on Database size, transaction duration

He believes that the first version will address address the needs of 95% or more web and departmental applications.

In terms of SQL compatibility, SDS will support in v1:

tables, indexes and views
stored procedures
triggers
constraints
table variables session temp tables

However these features will be out of scope for v1:

Distributed Transactions
Distributed Query
CLR
Service Broker
Spatial capabilities
Physical server or catalog DDL and views

The security model is 100% compatible with on-premise model but is limited to standard SQL authentication and logins. In the future they will support AD federation, WLID, etc as alternate authentication protocols.

Nigel talked a little bit about the road map: