I was reading an interesting article in DBTA (April/May 2018, “The Headaches of Microsoft SQL Server Sprawl“) and it was clear that so many of us are facing some pretty significant challenges when it comes to managing SQL Server instances. Particularly true if you consider “SQL Server instances” to include your Azure instances and/or managed instances on Azure and AWS.
One of the things we’ve been seeing more and more with consulting customers is a bit of a runaway of instance counts on the cloud, particularly when you have mixed environments – on-premises and in the cloud. I’m not sure what is leading to it – but I suspect the different means of paying for the actual functionality is leading the way.
On-premise, you pay for the license, the hardware, the setup, the physical process of getting things going… it’s pretty clear that there are processes and costs associated and sometimes they can be substantial (license and systems and then requisitioning the people to get it done…)
Cloud-based, you click an option and your new instance is running, you’re only “paying for what you use” and you don’t really have solid visibility into the effort to bring that online. This makes it downright inexpensive, at least initially, as you bring the new server online.
The sprawl we’re seeing at accounts though comes from the fact that it really is so easy to set up the instance – so much so that the consolidation and management of instances (to make sure they’re utilized and not sitting idle, for example) that might normally happen on-premise, just doesn’t happen in the cloud. Indeed, some cloud options are more difficult to implement a solution that may house more than one database. If the system is more of a managed SQL Server, many times the effort to bring it online is completed by someone unaware (or not invested in…) other projects that would be candidates for sharing the resources. All of a sudden you have a whole load of SQL Server instances that are running at extraordinarily minor utilization levels.
One of the suggestions that is pretty common now is to make sure you have a fairly consistent audit process. Go back and review instances, look at what databases live there, what the utilization is, find out about new servers and new instances, etc. You can do a great deal to accomplish some controls by working closely with those that have the permissions to create new instances, but you may find that, even with those discussions, you have people creating new accounts or instances that are simply not needed and could easily be supported in an existing instance, perhaps even on-site.
The challenge is quite similar to the days of SQL Server express and Access instances all over companies. It’s so easy to set up a new instance, and yet people become dependent on it and expect it to be managed… at best. At worst, they’re throwing away money, time and resources for something that could easily be supported on existing licenses, existing instances.
Education of your stakeholders will help, but an ability to audit to make sure they’re getting the service they’ll need, along with the cost savings and management the company needs, are key. While you don’t want to strong-arm your way into their applications and such, you do want to make sure things are as optimally used as possible, and that they’re supported and known entities to the company.
