When it comes to the cloud, developers will often take the “easy” approach to fix performance problems. The “easy” approach is to simply scale the resource up to a larger size. While this will often fix the performance problem at hand, there’s a couple of downsides to taking this approach.
- Resources can only be scaled up so far. Resources have upper limits, and if the plan is to scale up to fix problems, then you have to be careful to not hit the upper limit of the resource. If you have scaled up and need to scale up again, but there’s no room to scale up anymore; than this approach isn’t going to work.
- Scaling up isn’t cheap. When cloud resources are scaled up, scaling those resources up cost real money. Depending on how large the resource is scaled up to the cost may be significant.
For example, if you have an Azure SQL DB database that you have running at 32 vCores and there’s a performance problem with the application, then your next scale option is 40 vCores. If 40 vCores doesn’t solve the problem, then your next scale option is 80 vCores. There is no option to scale up from that point. So, at this point, you’ll need to do traditional performance tuning instead of just scaling up.
As you scale the application up cost is going to be a major factor as well as you can see from the below chart.
|vCores||Business Critical Monthly Cost (US West)||Monthly Increase from 32 Cores|
As you can see from the table above, scaling from 32 vCores to 80 vCores becomes a very costly plan very quickly, even if only done for a month. Many performance problems aren’t going to be solved in a month, and several months will be needed in order to resolve the performance problem. Assuming that the problem can be solved in 3 months that performance problem could easily cost over $75,000.
This scaleing approach instead of fixing problems applies to more than just databases. We’ve seen this done in Web Apps, Virtual Machines, Cosmos DBs, as well as other Azure services. There are lots of places in the cloud (I’ve talked about Azure here but the same applies to AWS and GCP as well) where you can scale up instead of fixing performance issues.
Solving the performance problem via performance tuning is going to be much more cost-effective than scaling the resource up.
I bring this up as we’ve seen this exact situation with multiple clients recently. Due to their scaling the database (in this Azure SQL DB) they have spent large amounts on their cloud spend that they didn’t need to spend. If you are having performance problems, in the cloud or on-premises, DCAC can help performance tune your database systems.