Sharding is a technique used to horizontally partition data across physical servers. It is used to achieve high levels of scalability. Each database in this architecture is referred to as a shard.
Microsoft has recently published a whitepaper to explain how sharding can be accomplished on SQL Azure today. The application will need to implement the sharding logic and route calls to individual databases as necessary. The whitepaper can be found here: http://social.technet.microsoft.com/wiki/contents/articles/sharding-with-sql-azure.aspx
The final section of the paper explains how an upcoming feature of SQL Azure known as SQL Azure Federations will make sharding much simpler and in the long run possibly totally transparent. Clients will continue to route to one database, known as the root database. That database will contain definitions for one or more Federations. Each Federation will include the sharding details (known as Federation Scheme) – included is the Federation key(s) which describes how the data is partitioned. Each Federation consists of one or more Federation Members which then map to physical databases.
A T-SQL command will be available to split a Federation unit into two, resulting in two physical databases with the data spread across the two. The really cool bit is that SQL Azure will let you do this “online” by ensuring that the view of the federation unit is consistent until the split is complete! And a T-SQL ‘merge’ is also planned which does the reverse.
I’d also like to refer you to Steve Yi’s post which explains this at a high level: http://blogs.msdn.com/b/sqlazure/archive/2010/12/23/10108670.aspx. Steve is one of the reviewers of the whitepaper.