Learning to build on Azure: One ISV's Experience

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

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