Learning to build on Azure: One ISV's Experience

Play Learning to build on Azure: One ISV's Experience
Sign in to queue


While at PDC back in October, Ryan Dunn and I had a chance to sit down with Shan McArthur from gold ISV partner ADXSTUDIO to discuss what he'd learned from his experiences with the Azure Services Platform

Shan is a serial early adopter and Ryan and I (and a few other Technical Evangelists) have been working with him and his team for some time to help them along the way.

In this video Shan discusses some of the things he's done that helped him get there faster.  Amazingly the team was able to get the ADXStudio Content Management System (CMS) ported to Windows Azure in a lightning fast 3 weeks.

He ported ADXSTUDIO CMS and their CRM Developer Toolkit so that they are now able to run in either on-premises, partner-hosted or Windows Azure.  He also took advantage of Microsoft SQL Data Services (which is Ryan's favorite technology Smiley ) to store the content for the CMS.

Shan had a lot so say about what he learned when build his cloud-capable and scalable app.  His app originally had a dependency on numerous Microsoft technologies including IIS, ASP.NET, SQL Server, Active Directory.

Windows Azure

He’s now betting of both worlds.  He knows many of his customers will continue to use traditional deployment methods but for many more Windows Azure will be a great fit. 

Some of his comments:

  • Hosting in Azure is different.  You can’t always do the things you expect from ASP.NET since you're now in a sandbox
  • The first thing to learn is code access security code since Windows Azure doesn't run apps in full trust
  • A great way to learn code access security is to move into medium trust immediately (even while on IIS) to see the exceptions right away
  • Get devs to Vista and IIS7 and use the integrated pipeline
  • He talks about how to build applications that will run in either IIS or Windows Azure. 
  • Shan’s team were able to get all of this cool stuff ported and working in just a few weeks.
  • Shan shows us a project built on the ADXSTUDIO CMS running on Windows Azure and in the Windows Azure dev fabric.

SQL Data Services

Shan’s team went with SQL Data Services (SDS) for data storage.  He notes that Windows Azure also has some storage capabilities.  Shan discusses why he made the choice he did to use SDS:

  • much richer query capability
  • easier to use for composition of multiple web sites
  • soon will have the additional security access control
  • will take on more and more relational capabilities

Since SDS is not full-fledged SQL Server there is a certain amount of re-architecting that Shan needed to do to ensure that his app was portable.  He made some design decisions very early on in development that made this easier:

  • used a provider model to separate the data from the logic in the application
  • moved away from deep dependency on SQL Server (e.g. stored procs)
  • used guids/ unique ids (as opposed to using auto-numbered ints) for unique keys

Shan goes quite deep into the code showing how he takes full advantage of the provider model.

He also spends some time talking about how he tackles identity.  Again because he uses the membership provider model he can switch identity based on the need of the application (Active Directory, Live Id, Forms Auth, etc).

Dynamics CRM

Shan’s team does a lot of work with Dynamics CRM as well.  Shan’s team put together a very cool conference self-service registration demo application that uses Azure on the front end with the site content stored in SDS and the dynamic content coming directly via web services from Dynamics CRM.  So, in the same way that Dynamics CRM can be used to build line-of-business apps that run on-premises, partner-hosted or in Microsoft data-centers with CRM Online, they can build customer facing self-service web sites that run in any of the 3 hosting models (on-prem, partner-hosted, Windows Azure).  For Shan’s code it’s just a change in a web.config file.

I even managed to get Ryan on film paying off Shan for all the kind words he has for the evangelists that have helped him out.  Gosh, I hope Legal doesn't see this.  Smiley  Seriously though, Shan has certainly done a great job of taking advantage of all the resources we provide to ISVs building on our platform.  Thanks for the kind words and great product, Shan.





Download this episode

The Discussion

  • User profile image
    I'm finding it hard to see why SDS exists. Microsoft has spent enough time telling us that SQL Server can scale up massively  and can be made totally reliable, etc. But now people promoting SDS are telling us that we're supposed to use this new API because "SQL Server doesn't scale up to the cloud" whatever that means. Go to the Azure site and it tells use that SDS uses SQL Server behind the scenes. Huh? To most devs it looks like an API purely for the sake of it. I can certainly see why you're not going to give Azure applications straight SQL Server accounts and connections because there's a bit of administrative overhead in doing that. Also SQL Server isn't really set up for the SaaS market (lacking Mainframe style accounting that could be used to bill customers), but that doesn't stop a lot of web hosts offering it. I think people want to know, why wasn't SQL Server improved instead of providing this new API.

    In fact the whole of Azure smacks of a new API just for the sake of locking in developers to Microsoft's hosting offerings. I can see it has value in terms of some people may need to provide a very scalable web application and don't have the expertise to write a high quality multi-server applications. But for people that do know how to do that, what does Azure offer? Even if I don't own enough servers I can rent them from many hosting providers. If I'm in a situation where I need a large capacity only some of the time (and this is a much smaller class of customers), I'd rather use an Amazon EC2 style service where I rent a standard Windows Server image on a per-hour-per-CPU basis because I know I can write the same code and run it on any server. Azure just ties me down and unless Microsoft offer to licence the technology to other hosting providers, that is going to rule it out for a majority of potential customers.
  • User profile image

    SQL Server Database is a relational database not a generic storage system.   In relational databases the emphasis is returning and manipulating direct relationships.  You can store Blobs or anything else in the intersect of the relational attributes but you cannot manage this as an indexed file system, for example.  In the case of SDS it is about moving large amounts of data quickly and efficiently in bulk between locations.  Simialr to the indexed file system where we could store random pictures, documents and other items together under some search criteris SDS uses a simplified attribute structure to move and retrieve this type of information.

    In the case of EC2 this works well for an individual program or when I need storage for a specific problem.  When managing many processes that are coordinating together coding this in Amazon's API is a more difficult process.  ASP, BPO, and SaaS ISV's have to manage this next layer of difficulty.  Distributing the results back to your customer is more than renting a box.  Azure attempts to solve some of these issues. 

    That being said the original Azure is targeted to MS data centers to provide services.  I do not think that Micorosoft is going to go through another round of anti-competitive lawsuits making that their only option.  They could make it more convenient to use their centers but still enable all the services to other providers.  We shall see how this is handled moving forward. 

    Microsoft has been the expert when it comes to this middle arena between applications and the infrastructure.  That is their core capability and one that Azure looks primed to take advantage of.  If I were to look into the next couple of years the idea of writing an interface between Azure and Amazon's hosting services would be right within this "sweet spot". 

Add Your 2 Cents