I may be completely off base here, but I’ve noticed a correlation between folks who use Amazon Web Services and their understanding that once you scale up a service during a busy business period, you can always scale back down again once the busy period is over. Perhaps that understanding is missing from the Azure side — or there’s a misconception about how to allocate resources to begin with — that mirrors on-premises implementations and force of habit.
So, consider this a public service announcement that it’s OK to scale down a service if you’re not using the resources right now. In fact, Azure bills you by the second, so if you’re able to reduce your service tier, you absolutely should.
When you buy hardware for your on-premises environment you spend a lot of money and time in planning how long that hardware will last you and how best to assign resources. You try and make sure the workload doesn’t consume all resources because it doesn’t allow for growth. That makes perfect sense.
With cloud computing, you’re renting time on someone else’s hardware, so you don’t really want to spec a system that matches your on-premises environment. On the contrary, you need to figure out what your usage is during an average workday and find a service tier that matches that average. Then if it gets busy you can scale up for that particular period of time, knowing that you will be able to scale back down again when it gets less busy.
Remember, the promise of Azure SQL Database (and Managed Instance) is a fully managed service that takes a number of tasks off your hands (backups, maintenance, and a fair amount of tuning too).
Don’t feel like your CPU needs to run at 15% all day. If it’s at 80% or higher then you’ve picked the right service tier. Skate that edge and save yourself some money in the process.
Share your thoughts in the comments below.
Photo by Jessica Knowlden on Unsplash.
I work for MSFT and I think you are right. I have some theories. I’ve noticed Azure customers are “Ops First” companies and AWS customers are “Dev First” companies. What I mean is…Azure is usually implemented by IT folks with an eye toward security and enterprise-y features and thought processes around getting the subscriptions and RBACing perfect. These are centralized IT shops. With AWS it’s much easier to spin up what you need in a VPC without needing an enterprise subscription and everything that comes along with that. So companies that are “Dev First”, meaning they value solving business problems over IT concerns, tolerate skunkworks, and follow a “beg forgiveness vs ask permission” mentality tend to embrace AWS. Further, IT tends to be CapEx driven so they want to pre-allocate resources and get a steady run rate for chargeback and budgeting, vs the business might be paying for cloud resources with a credit card and are very concerned with OpEx. These are gross generalizations but I totally agree that most IT departments aren’t as amazed at the ability to scale down to save costs. I’ve yet to hear an IT Ops Guy say, “ooh, let’s use azure spot instances to save 40%”. Always surprising.
That’s an interesting take on AWS being a “dev first” environment. I tend to think how/if you use the scaling features of the cloud depends on your application,licensing, and your finance department.
My company fully migrated to AWS a couple of years ago and those three components play a large role in how resources are sized. As the manager over Database Services, I have go with the “size and hope you make it to next year” approach. The application side deals with their own scaling issues, and finance controls it all.
I was working an a project for a client I found in the Azure documentation that you can change the service tier with an alter database command. So I wrote a little stored procedure to scale up or down the service tier using that command. The wrinkle is there is no guarantee when the scaling will complete. I had planned to write a loop in ADF to watch the service tier until it did change, but it was easier/faster just to put in a wait for 10 minutes and hope. I did get burnt once on my ETL process starting before the scaling had finished, but that wasn’t a big deal for that project.
Comments are closed.