Our first Azure DevForce “application” debuted today.
Sure it’s just Northwind customers in an un-styled, read-only Silverlight DataGrid. Kind of like putting a monkey in orbit. But it’s an important step for IdeaBlade and DevForce … and I’m feeling a wee bit proud.
Behind that simple (simplistic?) exterior are DevForce 2010, SQL Azure, Windows Azure, Silverlight 4, Entity Framework v.4, and .NET 4. That really is EF 4 running in the cloud, not on the client as it is in most Azure demonstrations. That really is the DevForce middle tier “BOS” in the cloud and a DevForce Silverlight client executing in your browser.
We’ll probably have taken this sample down by the time you read this post. But who knows; if you’re quick, you may still be able to catch it at http://dftest003.cloudapp.net/
Kudos to Kim Johnson, our ace senior architect / developer who made it happen. Thanks to Microsoft’s Developer Evangelist Bruno Terkaly who first showed us EF 4 in Azure when there were no other published examples.
I’ll be talking about DevForce and Azure much more as our “DevForce in the Cloud” initiative evolves. It’s clearly past the “pipe dream” phase and I anticipate acceleration in the weeks ahead.
Those of you who’ve been wondering if we’d get there (Hi Phil!) or whether to "play it safe" and build your own datacenter (really?) … wonder no more!
3 comments:
I'm very interested in seeing where you and IdeaBlade go with this. I'm particularly hoping to hear that you're support Entities based on SQL Azure tables and Entities based on Windows Azure tables, in the same Entity Manager of course.
Loads very fast!
@Ben - Isn’t that amazing? They must not have a lot of traffic on that server yet ;-)
We’re going to try to launch something a little more substantial today. Keep your fingers crossed.
@Dan - Would you elaborate please? Right now our demo (and focus) is on entities backed by SQL Azure.
We have POCO support too which means it should be a short hop to working with entities backed by Azure Tables.
Of course these POCOs don't benefit from code generation and persistence framework as our EF-backed entities do. That means you have to code your CRUD methods to support your POCOs ... and that such coding would be specific to the Azure Table technology as I think you would expect.
Consequently, you have to do some work to do what EF+DF gives you for free.
I believe there are some great scenarios for Azure Tables in a business app and I look forward to exploring them. But, given the extra effort involved, I'd make sure that Azure Tables were doing something special for me (perhaps in lower cost) that made such effort worth while.
Post a Comment