There is significant abstraction from beginner to intermediate database administration responsibilities. In this way, I can focus on my business objectives, as opposed to heavy upfront cost of ownership when compared to on-premises or IaaS alternatives.
It provides faster turnaround time to getting solutions customer facing.
It could have closer parity to on-premises capabilities. Introduce a graph database engine component.
I have been using Azure since its inception.
Historically, SQL Azure has tended to choke at databases larger than 50GB, and in some cases, as small as 20GB. Granted, this starts becoming a function of database design.
Caveat: It's been a while since I last attempted to put larger sets of data into a single SQL Azure database. Now, if you don't use resilient connection tolerance practices (or technologies), then it may feel unstable. Here again, it becomes a function of design.
In other words, if you simply choose to use on-premises traditional designs and principles when interacting with SQL Azure, then there is a higher probability of it "feeling" unstable.
I've seen and experienced some amazing service and then I've endured appalling interactions, too.
This becomes a function of your SQL engine skill, the diligence and appropriateness of your design, the support tier you purchased, and some luck if you connected with a support engineer who not only spoke your language, but also carried an attitude of chasing down a solution.
The setup is super straightforward. I don't really find that question useful, or at least as useful as, "What is it like incrementally adjusting the design of the database?"
This is where Microsoft's eco-system further outshines the alternatives. Again, this is a much longer discussion, but it's folly to choose a platform, and even a technology, without considering the lifecycle of changes.
In an agile world, you have to ask how you are going to get that data tier to respond efficiently and within business requirements and tolerances.
It's an elastic service, at least in its simplest definition, and a proactive one with some reactive capability. Therefore, there is value in monitoring usage and adjusting proactively to gain optimal savings.
Alternatives tended to be IaaS offerings hammered or butchered to be PaaS. So, frankly, the answer is that I don't know of other PaaS alternatives.
SQL Azure is a good option for maintaining structured data, especially for smaller databases (0 - 25GB).
My solutions today leverage a plethora of structured and unstructured data. Therefore, having this service in close proximity to the resource groups I use for the other services is beneficial.
It does tend to constrain me to the Azure platform, as I've yet to find a vendor who can give me the RDBMS PaaS offering. Constrain makes it sound like “suck up some pain”. However, I have yet to find the Azure platform limiting.
Here is some context or insight. I was previously on the product team that heavily influenced the direction and feature set of SQL Server, both box (on-premises) and cloud. My focus and specialty is related to scaling the RDBMS tier to support high-demand applications.
To that end, SQL Azure was very useful for a certain set of business problems. At the time, I certainly would not have recommended anything larger than 50GB residing in a SQL Azure database.
I also felt strongly that a significant value proposition of cloud-based RDBMS solutions lay in the as yet untapped elastic-scale possibilities.
To that end, I developed a framework for customers to leverage, which found its way (in a crippled form) into what is today's SQL Azure elastic feature. What I'm trying to say is that true elastic-scale and distributed scale of SQL Azure is hobbled. That frustrates me.
The value proposition of using SQL Azure for mobile and web app solutions is also significant, and it remains as strong as ever. This is especially the case for solutions that enjoy the benefits of structured data.
The on-going improvements of SQL Azure reaching parity with an on-premises feature set is making SQL Azure a viable option for many applications that previously couldn't even begin to look at cloud-based, non-IaaS, therefore PaaS, offerings.
In my current role, I consider SQL Azure the leader for cloud-based RDBMS solutions, far ahead of any other cloud-based RBMS offering. Where I have structured data, SQL Azure is my de facto storage tier.
