I am old enough to remember when many large corporations implemented chargebacks. Essentially, each internal department was charged for their usage of IT systems, similar to how we are charged in the cloud. It was a mess, and individual departments had to answer for excessive charges. I don’t know that any department ever lost service, but their shared of the IT budget was certainly discussed in management meetings.
These days more and more of us are going to move systems to the cloud, and some of those systems moved will be databases. We may not move all our systems, but we will move some, and the ongoing cost of those systems is something that we will periodically be asked to justify. In the past, we rarely dealt with billing, usually just when specifying and procuring new hardware or requesting a VM.
Moving forward, I can see us spending time every quarter, or likely every year, analyzing the resources we are paying for and then determining if we are overspending.
Or, if you’re proactive, perhaps you’ll start looking at costs and performance, as Brent did, and try to write better code to reduce your outlay every month by more efficiently using resources. Have you built in-efficient designs? Are you pulling back too much data with SELECT * from a table or view? Are you building code that recreates the N+1 problem?
We’ve known for years that writing good code to interact with databases can prevent scale problems and overloaded hardware, even with large workloads. Many case studies over the years show SQL Server backing extremely large databases and busy workloads. Multi-TB databases with thousands of concurrent clients are common these days, and often we find that workloads at clients would easily be run on existing hardware with some better code.
For some of us, the refocus on the cost of systems may give us some help in pushing developers to write better code from the beginning, learn to use efficient patterns and avoid anti-patterns, and perhaps even get more time to tune systems. However, those are skills that many of us need to improve, learning how to find code that can be improved, and what techniques to use to do so. We have lots of articles that help, as to Brent Ozar, Erik Darling, sqlSkills and others. There are lots of ways to improve your skills, and they can help improve your bottom line. If you work on them.
Steve Jones
Listen to the podcast at Libsyn, Stitcher or iTunes.
Voice of the DBA 