Tag: Cloud Computing

Last week we had a training session at Redgate Software on the Cloud. One of the first slides from John Q Martin asked the question, “what is the cloud?” The next slide had the answer: it’s just someone else’s computer.

I mean that’s true, but it’s not Grant’s computer. He’s got a creaky, 4 year old HP that I don’t want running my workload.

The cloud is many things, it’s hard to define, it does so much, and at the same time, can do so little for you. Except cost a lot. We certainly find no shortage of people spending a lot of money in the cloud and not necessarily happy about it.

John was trying to educate others on the IaaS v PaaS, the challenges of cloud migration, giving them a perspective on what the cloud changes, and how customers think about the cloud. Apart from the basic details of what the cloud entails, he said an interesting thing (I’m paraphrasing here): the cloud does things that 95% of organizations couldn’t do themselves.

It’s not just someone else’s computer. It’s a whole bunch of computers someone else owns and has put a lot of security, infrastructure, planning, tooling, and more to enable you to flexibly create systems at a pace you would struggle to match inside your organization.

For most people.

The cloud is amazing. It’s is someone else’s (large rack of) computers that you can rent. They will charge you for the flexibility, and they’re not doing all your work for you, but they give you the ability to configure things the way you want them. Or you can ask one of your buddies, Claude or Copilot, to set up the configuration for you.

The cloud is a set of Lego bricks, some pre-built Lego models, a surface on which to place them, and a few rules to keep you from going too crazy, but you still have to do some work.

The cloud is a great enabler for many things. Not all, and not always for those things, but it’s up to you to find where it works, where it doesn’t, and where it’s worth the money.

That’s the cloud.

Steve Jones

Listen to the podcast at Libsyn, Spotify, or iTunes.

Note, podcasts are only available for a limited time online.

Lots of people move to the cloud; it’s common. In fact, it’s very common to hear customers who are being asked to migrate their workloads to a cloud vendor for a variety of reasons. You might not agree, but often there is some reason to move to the cloud. Sometimes it’s even moving from one cloud to another, just because one of the big three (AWS, Azure, GCP) seems more attractive this year than the one from last year.

When you move, do you size your system for the peak? 80% of the peak? Perhaps there is another goal for which you design. Do you worry about ever being under-provisioned and letting customers have a slower system? Or do you ensure you never hit the peak, which increases costs?

Auto-scaling can help, but it doesn’t seem to have worked as well for database systems as it does for serverless functions or other types of workloads. Compute is much easier to scale than stateful database systems that need CPUs and RAM ready on a particular system instantly. In fact, the “serverless” Azure SQL database is attractive to me more for it’s ability to scale the CPUs and RAM more than the on/off capability.

I was in a discussion recently with a number of data professionals who tend to over-provision a bit, mostly because their companies are willing to. It saves them headaches and phone calls (more angry texts these days), but it also means developers aren’t incentivized to optimize any queries. Unless there is a way to determine that the aggregate of all queries could lower the size of the resource provisioned, no one wants to fix any poorly running code.

That was interesting to me, as I’d think we’d want to optimize code as we pay every month, but the reality is that we pay every month for a level of resources. Coming in under that level is all that’s important. If we use 99% of those resources or 25%, we pay the same amount. It’s like saying we want to watch a movie every night because we pay for Netflix/Apple TV/etc. We’ve spent the money, so whether we watch 1 a week or 5 a week, there’s no point in optimizing our time to get value out of the subscription.

In the PaaS world, that might change, but often we’re still purchasing a tier of resources, not paying for each query. Until we need to raise that tier, no one worries about efficiency. If we can’t prove a lower tier would work with better code, no one cares.

It’s a little sad, but perhaps some future version of monitoring that can spin up a digital twin, optimize some code, and model a lower tier will take hold among all the performance tuners and monitoring vendors. Maybe with a few Claude code tokens, one of you will solve that problem.

For now, I still think it’s worth trying to optimize code, especially if an AI can give you suggestions and prove things run quicker in a test environment. If the cost of code is getting lower, then why not extend those savings to SQL code?

Steve Jones

Listen to the podcast at Libsyn, Spotify, or iTunes.

Note, podcasts are only available for a limited time online.