Here’s a neat little NuGet package. The Transient Fault Handling Application Block for Windows Azure. What it does is help you write code which connects to Windows Azure SQL Database, which is of course on the internet and therefore a bit more prone to connection issues. When these connection errors do occur, the application block will retry intelligently. Retry logic is a best practice for Windows Azure, and the application block makes it easier
Tag Archives: Windows Azure
DAC deployment and Windows Azure.
So here’s a nifty little feature. Visual Studio has a project type for SQL Server database projects. You write some scripts to create your database;
CREATE TABLE [dbo].[Customers]
(
[Id] INT NOT NULL PRIMARY KEY,
[Name] NCHAR(255) NOT NULL
)
Now that’s fine and dandy. You design your database and label it version 1.0.0. You build the project and it creates a ‘.dacbac’ file — a package which can be installed to Windows Azure to create your database. All is good, and your cloud app works happily on top of your database.
But let’s say the next version of your software requires some datbase changes. You update your creation script in SQL Server and label the version 1.1.0, a .1 incremental release.
CREATE TABLE [dbo].[Customers]
(
[Id] INT NOT NULL PRIMARY KEY,
[Name] NCHAR(255) NOT NULL,
[Expired] BIT NOT NULL DEFAULT FALSE
)
Now you go ahead and build again. You get a new .dacbac file. When you try to upload the new definition, The Windows Azure service scans the SQL script, notices the columns, compares it to the existing database, and generates a change script which will upgrade from 1.0 to 1.1.
Now that’s really snazzy. Previously, developers would exect to write ‘patching’ scripts; something starting
-- 1.0 to 1.1 upgrade script
ALTER TABLE [dbo].[Customers]
...
but notice that no such ALTER statements are being made. It’s just two CREATE statements, being intelligently compared. I asked Nino Filipe, and he confirmed that the service itself is actually parsing the file, figuring out the effect, comparing it to the current state, and generating a new script with the ALTER statements itself, so you don’t have to.
Cloud-first features from Microsoft
In his talk, Nuno Filipe mentioned in passing something I found interesting, so I present it here for you to find just as interesting. He said
“Microsoft are promising to deliver features first on the cloud, then later on-premises”
That’s a paraphrase. One clue is that everyone uses the Jargon on-prem for ‘on premises,’ or ‘software I installed on a machine’. Use it — you’ll sound like you know what you’re talking about.
But the sentiment is not just an empty threat. A really useful feature on Azure is SQL Federation, a feature that doesn’t exist yet in release versions of SQL 2012, but which is available right now on Azure. It’s a feature which helps you scale out your database to many different servers, and gives you the ability to split your database up by certain criteria. An example would be to create one ‘sub-database’ per customer, or one ‘sub-database’ per geographic region, or some other split. Then you can do things like this pseudocode;
-- switch to using the sub-database for europe
USE FEDERATION geo (location='europe') WITH FILTERING=ON -- get all the european projects
SELECT * FROM Projects -- now switch back to the master database
USE FEDERATION geo RESET -- now get all projects across the world
SELECT * FROM Projects
So the plan, clearly, is to tease people onto Azure with the latest and greatest features. I’m guessing they’ll do the same with other features. I bet IIS 9 will roll out first on Azure, and Exchange 2015…
Creating a SQL Server database on Windows Azure
(Just to address a point of confusion. In the old days, Microsoft called their cloud-based SQL Server cloud service ‘Windows Azure’. Then they made their cloud service do virtual machines and apps and whatnot, and they renamed the SQL Server bit ‘Windows Azure Sql Database’ or something. This post is about the SQL Server thing, whatever it’s called. On with the show, anyway.)
“Just give me a connection to a SQL instance”. That’s the promise of Windows Azure Sql Database. Out there somewhere in the cloud, Microsoft will give you a SQL server instance, into which you can create databases, and it’s supposed to function exactly like a SQL Server instance you’ve installed on a local machine. Or you can use it as the back-end store for an app running on Azure, of course, but for now, let’s just consider the use of it as a raw SQL Server instance.
The story is pretty complete. You create your instance through the Azure control panel, tell it some admin credentials, and then you’ve got an instance. You can open up Management Studio now if you want, and connect to your instance by typing in something like
w2490825.database.windows.net
and you now have Management Studio; you can now CREATE DATABASE or whatever you want to do. (Technically, you get a thing called a `TDS endpoint`. Google it.)
So databases created on Azure are replicated twice — you have a master copy and two slaves, and writes have to hit the master and at least one slave. That adds a little bit of latency, so the suggestion is that you write chunky, unchatty commands. Seems reasonable, I guess. But you get replication for free.
Now, don’t go confusing that with backups. If you `TRUNCATE TABLE PROJECTS` on your master you can’t switch to a slave to restore to an earlier state — you just truncated all three copies. This is just for redundancy in case a meteor strike hits the rack with your master DB on it. You still need to do regular backups.
And I say backups, but you don’t get those the same way. Actually, technically, you can’t do backup or restore. Not with `.bak` files. Instead, there is an import/export service that you can use. The .bak files contain transaction logs, and those would contain sensitive data from other users of the datacentre, so you can’t get ’em.
Steve-Driven Development 