In small organisations, everything is managed by a small group of people. There is no infrastructure team, nor is there a release manager. If you expect a project management office, forget it and the support team can consist of just one person. Essentially everyone can do anything and as software gets more complex these sorts of teams cannot be blamed for looking for short cuts.

When it comes to Azure it is not realistic to expect everyone to know all the details about all the services. Microsoft realise this because they are sprinkling things like helpers and advisers all over it. The one that has got my attention recently is the Azure SQL Adviser.

I have been using Azure SQL for a while now and the on the whole it just works. It looks and feels like any other SQL Server database but it just so happens that it is a running in the Cloud and some of the stuff we used to worry about such as backups and patching are now Microsoft’s problem. Even so, running and tuning a database is still complex and is a specialised skill, so a small general purpose team is thankful of any assistance they can get.

So, when customers are complaining about performance and the Azure SQL adviser is effectively flashing a big green button labelled “make the performance problems go away” that button is going to get pressed.

But wait…

Teams that are moving to DevOps are control freaks. They are creating sophisticated build and release pipelines and are trying to automate everything. In order to reduce down time things like database schema changes are closely planned and controlled using techniques like migrations. Those migrations are run as part of the release process automatically.

What is the impact of applying Azure SQL advisor recommendations immediately?

Let’s say that the adviser has applied an index on a database column used in a critical join. That change is applied immediately and all is good. Performance is improved. Customers stop complaining. Sometime later the development team are building a new feature that will be removing that column. This all works fine during development and testing but when the team try to deploy to Live, their database migrations fail. They are dropping a column that is used in an Index – an index they did not know about so there is no chance that it exists in other environments.

This can be quite a problem. Over time a team with a reliable release pipeline start to expect releases to just work and now they have a problem deploying to Live. They don’t know what to do. There is no plan for backing out or fixing forward the deployment.

The solution is quite simple. The team should look at the advisor as another source of work alongside new features and live issues. The development team should view the changes and incorporate them into their database release pipeline so it can be delivered into Live in a controlled and repeatable way. In some cases, the recommendation may relate to a critical performance problem so it becomes the highest priority. The question that the team needs to answer is how quickly this change can get into Live and is the existing process fast enough.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s