One of the things you learn early on in programming is that you ought to reuse code whenever possible. This often means refactoring code into functions or methods. This ensures that the code is more easily maintained and that the knowledge and work of solving the problem is reused in many places.

In database code we don't do this too often. We certainly can reuse some code by encapsulating it in a view, but this often brings performance penalties. We often don't want to reuse code in stored procedures and functions as embedding this into queries can cause lots of issues. In fact, it seems that much of the way databases optimize query performance isn't that amenable to reusing code.

That being said, I ran into an interesting case recently when thinking about maintenance in the cloud. Someone was asking about SQL Agent and the lack of support for it in many PaaS database systems. I understand that, and while there are some ways to do this, they feel complex compared to using a SQL Agent on a local instance, which is usually easy to set up and readily available. One of the speakers taking questions mentioned that they user shouldn't forget about Azure Data Factory as an automation agent.

That caught my attention as I hadn't thought about it before. This week, there was a blog on that very topic and I read through it to see what I thought. While this isn't as easy as SQL Agent, it does seem to be easier than Azure Automation, and likely more familiar than elastic jobs.  That's if you already have ADF running in pipelines. In many ways, this feels like using the maintenance plans in SQL Server, though just the call a stored procedure task. Since many people use a solution like Ola's, this is very easy to implement.

I like that this pattern reuses skills and a system that you may already be using, transferring the skills from one area (ETL) to another (administration). This might not seem like much, but limiting the tools and technology, reduces complexity and means that each person needs to know less to support your environment. I'm a fan of code re-use, outside of T-SQL), and I think reusing other technology systems, where appropriate, is a good idea.