Recent Update: the program is at full capacity and nomination survey is now closed. Thank you for the great number of nominations. For questions about the program details, you can contact us at SAPESupport@Microsoft.Com.
Microsoft SQL Azure Federations Product Evaluation Program nomination survey is now open. To nominate an application and get access to the preview of this technology, please fill out this survey.
Let me take a second to explain the program details: the preview program is a great fit for folks who would like to get experience with the federations programmability model. As part of the preview, you get access to very early bits on scale-minimized versions of SQL Azure. This minimized version does not provide high availability or high performance and scale just yet as it runs under a different configuration. Those properties will come when we deploy to the public cluster. However you can exercise the programmability model and develop a full fledged application. There may still be minor changes to the surface but will be incremental small changes at this point. Participants will also get a chance to provide the development team with detailed feedback on the federations technology before it appears in SQL Azure. The preview program is available to only a limited set of customers. Customer who are selected for the program, will receive communication once the program is kicked off in the months of May and June 2011.
Looking forward to all the nominations! Thanks
Cihan Biyikoglu – SQL Azure – Program Manager
Will there be tools for federations at the data access layer that abstract away the changes needed for Federation?
I am thinking a new derived SqlConnection and SqlCommand object that could be used with EF where the federation key is passed in the constructor and then from that point on you treat it as if it is a standard SqlConnection, with the filtering going on behind the scenes for multi tenancy. So this might be something like a FederatedFilteringSqlConnection.
With regards the EntityFramework, I am unsure if the ObjectContext etc would need to be 'federation-aware'?
I guess I am wondering how much re-engineering will we be faced with for multi tenancy versus how much will be provided for in the framework?
Currently we use dependency injection to provide a connection per customer, and I hope for only having to change our connection injection :).
Are you able to shed any light on plans in this area?
Hi Simon, There won't be a transparent layer to hide the federation related details built into the server side. However you can create a data access layer that can hide the complexities. EF Team is looking into the ways one can incorporate federations into the existing EF framework and looking into new abilities around federations but nothing that we can share at the moment.
Multi-tenancy is an interesting question; it is easy to forget that you need to give up isolation when multiple tenants are in a single db. There is some help the system will give you for moving into a multi-tenant model (refer to my post on developing multi-tenant solutions with federations) but the work required for moving into multi-tenancy is proportional to the amount of isolation you will need to build between tenants.