Changes in Azure MI Policies - Are we affected?

By Rob Litjens

One of my friends created a post on changes in the Azure Managed Instance (later: MI) policies today. Reading his post covered some drawbacks why he was not that happy with them. Even me, when reading his post. And only reading that post it made sense to me as well.

It was a reason for me to open a discussion in the LinkedIn. My first opinion was that he was right and I still think his explanation fits.

In the mean time I looked into what Microsoft wrote about the changes. They have written it down here. It is written there quite well, despite I probably would have reworded it a bit more uhh… commercial. But that later.

Soon after that one of my Microsoft asked me for a small meeting. I accepted the meeting and we spoke about the things and some examples where I would use the Managed Instance and Managed Instance Link. Both Microsoft employees listened to why and how.

I prepared some questions:

  1. What polices does Managed Instance have?
  2. Why did Microsoft implement the ‘Always-up-to-date update policy’ Policy?
  3. Why is it named Policy?
  4. Do we need to update our Azure scripts to implement it (immediately)?
  5. Is there impact on offerings like Managed Instance Link

What Policies do we have?

Currently Manage Instance does have two policies:

  • SQL Server 2022 update policy
  • Always-up-to-date update policy

As you can see, two completely different names, having different purposes.

The SQL Server 2022 Update policy focusses on compatibility with, I think you guessed it, SQL2022 The Always-up-to-date Update polic focuses on delivering the latest features to you as a customer, not focussing on backwards compatibility.

Why did Microsoft Implement the ‘Always-up-to-date update policy’ Policy?

For this, I have to go back a few years. It was November 2022, when Bob Ward and his Microsoft friends announced SQL2022. Part of that announcement was that Microsoft will offer 5 years compatibility with MI. Looking at this, that would end on January 1st, 2028.

Microsoft keeps their promisses under any circumstance. They still offer the compatibility of 5 years. If they would not add this policy, it would mean that they need to follow on-prem update policies. These are very thoroughly tested. It would mean for example that a set of fixes (read: they finally fixed the IQP engine) from march wll be in the next CU. Only after a certain amount of time (months before everyone has implemented the fix) it would be possible to get this in Managed Instance. But that would mean that they also create technical debt in such a way that they cannot innovate. That is not where all of us are waiting for.

Microsoft should start building on SQL 2025….and use trusted binaries from the cloud.

Why is it named Policy?

I have no clue. It is not a bad name, but you could also see it as a feature set. However, I think I know why they did not put a version in the name. That might be because of the upcomming version. That would have a ‘SQL Server 2025 Update policy’ which means that the ‘Always-up-to-date update policy’ can be applied anytime.

Do we need to update our Azure scripts to implement it (immediately)?

Happily enough not. The ‘SQL Server 2022 Update Policy’ (the old one) is the default. But if you want to make it explicit, Microsoft encourage you to do. If you need the new feature set, you must explicitly mention this. For examples on how to do, please visit Microsoft Learn

This page also shows that you can migrate from the SQL2022 policy to the Always-up-to-date policy

I wish I could say no, but there is. But only if you apply the Always up to date policy: Examples:

  • Restore a database backup taken by the Always Up to date Policy to the SQL2022 policy (also on-prem!) is not possible.
  • Managed Instance link is (thus) only possible when the SQL2022 policy is applied when you use the MI Link for DR and only when there is a requirement to go back to the on-prem situation.
  • Failover groups are only possible when using the same policy

Note: When you use the MI Link to support cloud based Reporting and you do not fail back to on-prem then you could still use the benefits of the new policy.

My thoughts

First of all I think that the name Policy is not the best name. Maybe Feature Set or Compatibility Set matches better. Also the name of Always-Up-To-Date calls in memories… It refers to ideas that when ‘SQL2022 Update policy’is selected that your environment is not maintained anymore. That is not the case. Regardless of the update policy chosen, you continue to benefit from Azure SQL platform innovation

Improvements and new features not related to the SQL engine such as zone redundancy, instance stop/start capability, networking and connectivity improvements, business continuity, new hardware generations will be continued to be delivered to your Azure SQL Managed Instance.

The Always-Up-to-date policy enables a lot of new features which we probably will see in later versions of SQL server or in a later CU. It will bring you the latest and greatest on Managed Instance.

Most of the features in the Always-up-to-date policy will end up in the standard policy. Sooner or later…

Conclusion

I think Microsoft did the right things, only the lack of some commercial thoughts on writing the learn page would have brough more clarity. Also the naming could be looked at, but knowing that Policies is a common sense thing, naming of the policies would bring the improvement.

Also, looking at the learn page, i would add a clear overview of What is the new policy.