In a lot of examples for the Azure platform I’m seeing a lot of self-administration happening: an application will test for the presence of an external system such as a queue or database and create the necessary structures it needs to function.
This behaviour seems contrary to a more traditional application’s environment being configured by an administrator or a separate setup application acting on behalf of the administrator.
So far, the biggest drawback I can observe to this is that the application would need to have some level of administrative rights over the services it is configuring and that could lead to increased vulnerability.
However, the Code-First approach in Entity Framework would also seem to suggest a practise of allowing an application to work at an administrator-level on the resources it needs to function.
Is this a paradigm I should be expecting to see more of, and are there compelling reasons to consider it as “good practice”?
1
Whether this is “good practice” or not probably depends on how your organisation and application are structured as much as any “accepted standards”.
As Azure isn’t very dynamic in terms of infrastructure (i.e. it’s long-winded to add new stuff while other stuff is running), I’d say it’s appropriate for you to have pre-deploy setup tasks for your database or queue, since you’re unlikely to be working with arbitrary numbers of databases or queues, or adding more infrastructure during runtime.
However, if your organisation relies on the ability to quickly (and automatically) deploy a new version of your app at short notice then you may be well placed to have your application ensure the state of its own database. I’d say this is quite a rare scenario, and if you’re in that position perhaps the Azure platform (with its huge spool-up times) isn’t the ideal choice for you anyway. To be honest, I’d say the big downside of the self-configuring approach is not so much the security risk (this can be managed) as the amount of extra time you’ll need to implement it.
For most Azure applications, I’d suggest simply looking into some form of SQL version control (Red Gate make an excellent solution), and perhaps an automated script you can run after deployment to configure your other infrastructure. This will allow for deployment agility without going over the top making an all-singing self-configuring application when you may be better off spending that time implementing some cool features.
6