The Other Jobs

There’s a meme of sorts going around Twitter. It asks for your non-tech jobs, and I’ve seen some good ones from Grant, Kendra, Erin Stellato, and more. There are some interesting ones, and a few that I’m glad I never had to try. My list is here:

  1. Ice bag packer/delivery
  2. Waiter/bartender
  3. Lawn service supervisor
  4. Lay water/sewer pipe
  5. Volleyball coach (current)

In my youth, I had a few more (newspaper delivery, painter), but I’ve had paying computer jobs since I was about 16, off and on, and I had a lot of restaurant jobs. I’ve actually been a cook, busboy, delivery person, waiter, bartender, and manager. I always enjoyed restaurant work and even had some part time jobs even as I was starting my career in tech. These days I certainly have ranch jobs, usually assigned by my wife, and I do coach competitive youth volleyball over the winter.

I know most of us have more in our lives than tech, and some of us might even have second jobs now, whether by necessity or for fun. This week I’m curious what other jobs you’ve held and which ones you enjoyed. Perhaps there were some you hated. Let us know how rounded your work history is.

As I get older, I think about other jobs. Not that I want to leave Redgate or SQLServerCentral, but I’d like to retire at some point and still have something that occupies some time. Volunteering somewhere, with a commitment as a real job, is something I hope to do at some point. Volleyball is great, but one thing I’m looking to try is holding babies at the local hospital. Many of them need companionship when they are born premature or ill and parents need a break. Seems like a good gig to me.

What interesting job would you try in retirement?

BTW, I know some of you worry about these as a security question, but I’ve never seen this listed as one of my choices. If you have, then please don’t answer.

Steve Jones

Listen to the podcast at Libsyn

Posted in Editorial | Tagged | Leave a comment

SQL in the City in Melbourne on June 14

As a part of our down under tour, SQL in the City comes to Melbourne on June 14. It’s a day before SQL Saturday #865 – Melbourne. If you’re anywhere close, and I know there’s not a lot of cities close by, but come take two days and get lots of Database DevOps and SQL Server training for a very low cost. I’m hoping for a good turnout and the chance to come back again next year.

Register today for a full day of training, including a catered lunch, and listen to talks about DevOps and Redgate products on Friday, then come back to SQL Saturday 24 hours later.

I’m excited for the event. We completed our London Summit a few weeks ago and it went very well. I’m taking over the keynote from Kendra and also doing a Monitoring session as well as covering privacy and the panel.

It’s going to be an exciting day, so if you want to improve your Database DevOps process, in a Compliant way, sign up and come on June 14.

Posted in Blog | Tagged , , | Leave a comment

Serverless Databases

I wrote about serverless applications recently. Not a lot of people are using serverless technology for their code, but a few have had a lot of success. It seems like a move that makes sense, though there are some challenges in managing the code when you deploy functions or snippets instead of an entire codebase. I worry a bit about tracking billing, usage, versions, and deployment pipelines with serverless, but I know things will get better over time.

Now Microsoft Azure has included a new option for databases: Azure SQL DB Serverless. This is a SQL Server database that bills you for the compute cycles used by the second. This works by essentially pausing your use of the database processing when clients are not accessing the system. You are still billed for storage all of the time, which makes sense, but storage is cheap. The system also has quite a few automatic scaling features, many of which aren’t as simple to understand as I might hope.

How many times have you purchased a server (or rented one) and found it is barely used, trundling along at 10-20% CPU? I’ve done that quite a few times, especially when I had no idea of the workload early on. Later, it’s often not been worth my time to try and consolidate the database on another machine. Often this is often a fear based response where the cost of the machine is already gone, and I don’t want to take the chance that a burst in workload will overload another system.

For sporadic use applications, serverless databases might be a good fit. I can avoid paying for compute during low periods, such as overnight. I’m essentially renting a machine at specific times and not at others, but the compute layer gets provisioned as I need it. That seems like the ideal situation for a lots of apps, assuming I can run them in the cloud. There are some restrictions in preview, such as the inability to pause the system unless there are 6+ hours of no activity, but I’m hoping that changes. Six hours seems like a long time.

The one thing I think about this database service is that it will require longer timeouts and more resilient applications that can handle a warm-up period if the computer layer has been shut down. I also worry a bit about cache and the buffer pool. If you’ve ever dealt with servers that regularly restart, there is a bit of a slow period as the buffer pool fills and code is compiled. Perhaps Microsoft has ways of saving off some of these states, perhaps capturing plans in the Query Store that can avoid excessive compilations on restart, but I do worry that slow starts will increase user complaints and tickets filed. Those costs might not be worth the savings from shutting down your database resources.

Steve Jones

Listen to the podcast at Libsyn

Posted in Editorial | Tagged | Leave a comment

Moving to Serverless for Azure SQL DB

After the announcement of Serveless Azure SQL Datbase at //build/, I decided to give it a try. I have some Basic databases, so what would Serverless mean for me? I was wondering as the Basic dbs are cheap and moving to Serverless means moving to Gen 5, larger machines.

Let’s try this.

Reconfigure an Existing Database

I’ll pick one of the basic test databases I have and look for the sizing. It’s under Configure, which is where my mouse it in the image below.

2019-05-06 16_07_02-SQLPatches - Microsoft Azure

Here’s my database config and cost. For my little dev/test environment, this makes perfect sense. I’m paying $4.99 a month in virtual cost. Since I get $150/month as part of my subscription as an MVP, I can afford to put up 5 or 6 of these test databases for different things without worry.

2019-05-06 16_07_36-Configure - Microsoft Azure

After I click the vCore pricing, I get new options. I can see Serverless in here.

2019-05-06 16_07_49-Configure - Microsoft Azure

For dev/test (for me), that’s a lot. I don’t want this kind of bill every month.

2019-05-06 16_07_58-Configure - Microsoft Azure

Let’s change to serverless.

2019-05-06 16_08_14-Configure - Microsoft Azure

That cost changes

2019-05-06 16_08_19-Configure - Microsoft Azure

That’s more affordable. I think that’s worth trying.

The last thing to set is the Auto-pause delay. This is the amount of inactive time that we set before the db shuts down. We don’t want this shutting down after a few seconds of inactivity, presumably because there is overhead to shutting down and restarting. I’d expect that most people would want tens of minutes or hours before stopping.

I hope so, because when you scroll down, you see this:

2019-05-06 16_11_49-Configure - Microsoft Azure

However, that’s the minimum you can set.

2019-05-06 16_02_12-Configure - Microsoft Azure

Six hours seems crazy, but still, it’s better than nothing. I hope this changes after the preview period to something more like 1 hour. Perhaps this is to gather additional telemetry during preview, but we’ll see.

I click “Apply” and see this:

2019-05-06 16_15_53-Configure - Microsoft Azure

If I go back to the overview, I see one of the cool things about Azure.

2019-05-06 16_16_37-SQLPatches - Microsoft Azure

I can still use the system as I’m making changes. That’s not normally what happens with IaaS or my own systems.

Is It Worth it?

We’ll see. I’ll check the bill next month, while making it a point to access this database and do some work. I’m guessing my bill will go down, which is good, but I’d also expect that this database will perform better than my previous one because it’s much larger.

This is an interesting idea, but we’ll see how it goes.

Posted in Blog | Tagged , | 1 Comment