locked
Development for SQL Azure Before Subscribing RRS feed

  • Question

  • I am almost certain, but not completely so, that I will deploy a website, including the code behind and the supporting SQL server database, to Windows Azure and SQL Azure.  SQL Server 2008 R2 apparently has the ability to develop for SQL Azure (see the Template Explorer in Management Studio).

    Were I to develop using this option, I assume I will be building a database that can be ported to SQL Azure without any compatibility issues.  Will I also be developing a database (1) that can remain on premises if I decide not to go to Azure, and (2) that can be used during development of a Silverlight/VS 2010 web project before porting to Azure?

    Which is the better strategy:  develop for Azure or for on premises, if Azure deployment is not for sure?

    Thanks.


    Jack
    Friday, March 11, 2011 3:40 PM

Answers

  • Jack,

    In general, your strategy seems sound.  However, you should think hard about architectural choices for your applications.  For example, with an on-premises SQL Server, you have options for scaling up the horsepower and storage capacity of your SQL Server in a way not possible with SQL Azure.  In addition to the SQL Azure limits on the maximum size of a database, you can hit a SQL Azure database hard enough to get throttled. The appropriate SQL Azure strategy is to scale out--sharding and using multiple SQL Azure instances. Designing for scale out requires some additional/different considerations in application design.

    And don't dismiss too quickly some of the advantages of using services like Azure Storage, ACS, etc.  These might tie you to a Windows Azure Platform model, however, the benefits of moving to the platform might also help make the eventual platform decision easier.

    Jeff


    Jeff G. Young @jeffcodes http://jeffcodes.net
    • Marked as answer by Jack Herr Saturday, March 12, 2011 6:52 AM
    Friday, March 11, 2011 11:24 PM

All replies

  • Hi Jack,

    Let's step back for one second and not think about what you're working on.

    This is a simple exercise that is all about application and product planning. You obviously see a need for your application to be in the cloud at some point or you wouldn't be here asking. What you need to consider is when do you see your project being deployed to the cloud? If you project anything less than 6 months, I would say build for the cloud now, and save yourself the data migration headaches in a timeframe where you'll be tuning the application for cloud deployment.

    SQL Azure isn't quite at parity with the on premise SQL but it really depends on what features you'd like to leverage. I'd say that Microsoft has put a compelling product into the cloud, I would look at what you need to leverage for your application and refer to this Guidelines and Limitations of SQL Azure article on MSDN to see if what you're planning already fits nicely into the current offering. 

    Just my two cents,

    ~Cory()


    Cory Fowler Windows Azure MVP http://blog.syntaxc4.net
    Friday, March 11, 2011 4:22 PM
    Answerer
  • Hi Jack,

    Consider SQL Azure as a subset of SQL Server. So if you develop for SQL Azure it will work in SQL Server (as of now); however if you develop for SQL Server, it may or may not work for SQL Azure. Do not assume that if you are using SSMS 2008 R2 you get a compatible SQL Azure database automatically; the burden is on you to only use the features supported by SQL Azure. 

    Silverlight is supported.  I have developed ASP.NET websites before that I was able to easily port in Azure. However I was using all the built-in capabilities of .NET; no external components. If you use third-party tools you may want to verify they support Windows Azure.

    Finally, Azure offers new storage models (Blobs, Azure tables) and a new type of queue (Azure Queue). You also have worker roles in Azure, which allow you to run tasks in the cloud. While SQL Azure is a subset of SQL Server, Windows Azure and the App Fabric offer capabilities not available on premise.

    So if you really don't know where your development is going to run, you are probably limited to two options:  only use the set of features that will work in both environments (which can be challenging) or wait until you know for sure which route you will go so you take full advantage of on-premise capabilities or Azure capabilities.

     


    Herve Roggero, Blue Syntax MVP SQL Azure Co-Author: Pro SQL Azure
    Friday, March 11, 2011 4:23 PM
  • Thank you (both) for responding.  I believe in simplicity of design, wherever possible.  Based on the capabilities of a SQL Azure database, I see no reason why I should not be able to develop a robust database completely tuned to the needs of my web project using SQL Azure.  So I am currently disposed to develop a SQL Azure database and use it for development in VS 2010.  I am building an ambitious web based product that will take about 9 months, and I am doing it on spec (meaning that I will look for funding only when I have a working product), so I can't afford the Azure licensing fees right now, even with the current MS promotions.  So I want to keep it all on my development machine for now.

    Thanks again.

    If anyone would caution that this is a bad strategy, for some reason, please let me know.


    Jack
    Friday, March 11, 2011 4:34 PM
  • Jack,

    In general, your strategy seems sound.  However, you should think hard about architectural choices for your applications.  For example, with an on-premises SQL Server, you have options for scaling up the horsepower and storage capacity of your SQL Server in a way not possible with SQL Azure.  In addition to the SQL Azure limits on the maximum size of a database, you can hit a SQL Azure database hard enough to get throttled. The appropriate SQL Azure strategy is to scale out--sharding and using multiple SQL Azure instances. Designing for scale out requires some additional/different considerations in application design.

    And don't dismiss too quickly some of the advantages of using services like Azure Storage, ACS, etc.  These might tie you to a Windows Azure Platform model, however, the benefits of moving to the platform might also help make the eventual platform decision easier.

    Jeff


    Jeff G. Young @jeffcodes http://jeffcodes.net
    • Marked as answer by Jack Herr Saturday, March 12, 2011 6:52 AM
    Friday, March 11, 2011 11:24 PM