5

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"?

|improve this question
  • One significant disadvantage of this practise is the time it takes to start. Ensuring the topics/subscriptions exist can add several seconds to the startup time of an application – Tom Squires Mar 25 '13 at 10:32
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.

|improve this answer
  • In the case of Service Bus constructs and databases, the code to administrate is very simple; the provided APIs make it reasonable to write that code. – Paul Turner Mar 25 '13 at 12:29
  • @Tragedian Agreed, however, each single piece of extra code is just more code to maintain and to have to train new developers around. – Ed James Mar 26 '13 at 12:03
  • What I mean is: I don't think there's a simpler alternative for Service Bus - you have to write the code. It's only a question of where you put it. – Paul Turner Mar 26 '13 at 13:10
  • @Tragedian If you're referring to the service bus initialisation code (i.e. NamespaceManager.TopicExists etc.), I'd say that's closer to the old file-system access patterns, as opposed to self-configuration. Think about reading from a file using a FileReader: first you check the file exists, then you read if it does. When you said self-configuration I assumed you were referring to creating a service bus namespace using the Azure API. – Ed James Mar 26 '13 at 14:17
  • So, do you believe this code should exist separate from the operational application, or existing in a separate "setup" application? – Paul Turner Mar 26 '13 at 15:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.