In a past couple months I’ve seen this happen in a couple of different customers, so I thought I’d write a short post about the topic. While it’s easy to think that running SQL Server workloads on cloud VM’s is the same as running them on VM’s in an on-premises environment, this is typically not the case. There is one huge difference to cloud based VMs.
And as you are well aware, what databases commonly are used for, it’s storing data. But that data doesn’t exist in a limbo (though sometimes the cloud makes me wonder…) but in an actual storage device somewhere. In the on-premises world, if you’re running any type of serious workloads, that storage is going to be an expensive SAN device. In the cloud your storage is also very like coming from a super-expensive, state-of-the-art storage device, but that’s not the experience you’re going to get. Instead of having bandwidth measured in GB’s, you’re getting something that is measured in MB’s.
I am a huge fan of managed database services, no matter which cloud platform they’re running on. The simple reason is that I am not a huge fan of managing the automation for the basic things like backups, patching and high availability myself anymore. There is a trade-off though when you’re using someone else’s automation to manage your environments, the price you pay is the limited visibility of what’s happening underneath the covers.
I was reminded about this the other day as I was attempting to restore a database from one Managed Instance to another, a pretty standard thing to do for certain, and was facing an issue with it. In the end the problem itself was easy to fix but difficult to figure out.
Lately I’ve been spending lot of time outside my natural habitat, Azure, and I’ve entered the AWS frontier. Because of this I decided to write down some of my experiences about how the SQL Server deployments between these two cloud platforms compare to each other. AWS has been around longer than Azure by few years and is the largest of all the public cloud platforms, and I believe, that even today it’s hosting greater number of Windows based VMs than Azure.
With Azure Microsoft had the opposite approach to hosting SQL Server databases, and rather than starting with VMs they first released Azure SQL Database and then later on Microsoft added support for SQL Servers in VMs to attract more of the existing workloads into Azure. Noting the different approaches, let’s then take a look at how they compare when it comes to SQL Server deployments.
While I work 100% with cloud based SQL Server deployments these days, my life is not all unicorns and PaaS services. Surprisingly (or not) enough, many of the environments in the cloud are still build on top of good, trusty virtual machines. Except that sometimes they’re not good or trusty. There are definitely some good reasons for deploying VM’s in the cloud, however some decisions on the architecture can prove to be a challenge in a long run.
In this post, I’ll share my experience from struggling with some of these decisions, and hopefully help some of you make better decisions out there. Let me share a woeful story about Storage Spaces Direct and Cluster Shared Volumes.
I have previously written quite a few post about how much I like the Platform-as-a-Service databases for SQL Server (and for databases in general), and I do like them quite a bit. But would I recommend them for all use cases and workloads? Heck no! At the moment there are some features and limitations in Azure SQL PaaS databases that, with some of hte SQL Server workloads I have seen, wouldn’t just work all that well.
Also when we look at Azure, there’s some really cool features available for VMs that you can start using today, which are making the good old VMs an interesting option.
The answer to this question is not 2, happy and unhappy users. This time we’re discussing security, not the end user experience of your perfectly tuned databases.
I was recently having a discussion around SQL Server security, more specifically about the logins and user. The question I was asked after going through couple examples was, that how many different types of users there actually are. While this seems like a trivial thing to answer, I have to admit that even after thinking about this for a little while, and still got the answer off by 2. As it turns out there’s bit more complexity to this than might be obvious at the first glance.
Without checking from anywhere, can you name all the different types of users? Read onward to find out.
Sometimes I run into things in cloud that really just blow my mind away. Not that long ago I learned how you can give everyone in Azure, no matter what subscription or region they are in, an access to your database. And it was super easy too. It’s just one click to allow whole (Azure) world to start accessing your data.
Is this something I wanted to do, or would I recommend anyone to do it? No, not really. Also the documentation around this particular setting was less than great, so I decided to share what I learned.