Spring cleaning

I don’t know about you, but sometimes I just create stuff in Azure and then don’t touch it again for ages, and then when I go back I can’t remember why I created stuff in the first place…

In these financially-constrained times (and also because when I looked at my resources in the Azure Portal and went ‘YIKES’), I thought that some housekeeping was long overdue. Turns out deleting stuff is both *extremely* satisfying and *slightly* annoying, but the pay-off is a tidy portal, and that has to be good, right ?

Anyway, so I deleted some stuff that I hadn’t used in ages and was costing me money. I was fairly ruthless about it as well: CosmosDB for Cassandra ? Gone. Same for MongoDB. Gone. Same for some Azure Table storage… I figured that if I need it again, I can just recreate it anyways.

I also thought that my Azure Synapse Workspace was also a little.. well, messy to be frank, so while I was in a cleansing mode, let’s bin that as well and start again fresh. I can just recreate it…

So I did, following my own advice here. (Side note: I’m soooo happy I wrote this down somewhere. The steps are the same even if the UI has changed a little)

After having considered my location and region, I went for a local Azure place – feels nice to be close to your data, right ? Making sure that all pre-reqs were in place, sufficiently unique and rememberable, I got to the part where it said ‘Create’.

Happy days. The portal went off and did the things it does so well in sumitting the required tasks and actioning them..

But… disaster ! Oh noes !! I haz a sad:

The storage accounts were created OK, but there was something wrong with my Synapse Workspace creation !! How can this be ?!? I filled in all the things like a good Data Engineer ? I’m sure I did !

Diving into this a little deeper by choosing the Operation Details link, the problem is clear:

Well, clearer. Let’s take a look in the new Resource Group’s activity log for some more info. Ah yes, here it is:

Switching to the JSON view of the failure, we get a *lot* of information, but also details of the actual error:

OK, so that’s suboptimal. Never mind, I can just delete the deployment and start again.

Also, suboptimal. OK, so I can move the new resources into another datacen… ?

Also, nope. I don’t know if it’s possible via some CLI majick, but on the face of it it looks like it’s a no-no.

Now, I *could* try and create the missing resources manually (probably), but rn I’m a little tired and disheartened, so I’m just going to delete the whole shebang and try again in a different region 😦

This time, success !

So, there’s a couple of things to unpick here.

First, although the error seems to say that my subscription isn’t allowed to create new workspaces any more, in reality is looks like a resource constraint in that region (so an Azure thing). That’s good news.

Secondly, I didn’t actually request any ‘Windows Azure SQL Database servers’ when setting up the workspace, and this one is actually quite interesting as it exposes a part of Serverless SQL Pools that people sometimes forget.

Serverless SQL Pools are *not* serverless, it’s just that you can’t control (or even see) the servers that your queries are running on. For any query to work, there *has* to be some compute allocated, even if you’re just using OPENROWSET() to query an external file. Conceptually, the Workspace SQL Query window is just an abstraction of a normal query environment in that it’s exposed *only* via the web UI – it still has to connect to a database engine *somewhere*.

I guess UK West is just a bit busy at the moment. Any why wouldn’t it be ? Who doesn’t love the South West of the UK ? We have some great beaches for surfing, some excellent restaurants, and breathtaking scenery 🙂

Back soon…