É uma boa prática para os aplicativos do Azure se autoadministrarem?

5

Em muitos exemplos da plataforma do Azure, vejo muitas ocorrências autogerenciadas: um aplicativo testará a presença de um sistema externo, como uma fila ou banco de dados, e criará as estruturas necessárias necessárias para funcionar .

Esse comportamento parece contrário ao ambiente de um aplicativo mais tradicional que está sendo configurado por um administrador ou por um aplicativo de configuração separado agindo em nome do administrador.

Até agora, a maior desvantagem que posso observar é que o aplicativo precisaria ter algum nível de direitos administrativos sobre os serviços que está configurando e que poderia levar a um aumento da vulnerabilidade.

No entanto, a abordagem Code-First no Entity Framework também parece sugerir uma prática de permitir que um aplicativo funcione em nível de administrador com os recursos necessários para funcionar.

Este é um paradigma que eu deveria esperar ver mais, e existem razões convincentes para considerá-lo como "boa prática"?

    
por Paul Turner 25.03.2013 / 11:05
fonte

1 resposta

1

Se isso é "boa prática" ou não depende, provavelmente, de como sua organização e aplicativo são estruturados, assim como qualquer "padrão aceito".

Como o Azure não é muito dinâmico em termos de infraestrutura (ou seja, é longo demais adicionar novas coisas enquanto outras coisas estão em execução), eu diria que é apropriado que você tenha tarefas de configuração pré-implantação para seu banco de dados ou fila, já que é improvável que você esteja trabalhando com números arbitrários de bancos de dados ou filas, ou adicionando mais infra-estrutura durante o tempo de execução.

No entanto, se a sua organização confiar na capacidade de implantar de maneira rápida (e automática) uma nova versão do seu aplicativo com pouca antecedência, você poderá estar bem posicionado para que seu aplicativo garanta o estado de seu próprio banco de dados. Eu diria que este é um cenário bastante raro, e se você está nessa posição, talvez a plataforma do Azure (com seus enormes tempos de carregamento) não seja a escolha ideal para você de qualquer maneira. Para ser honesto, eu diria que a grande desvantagem da abordagem de autoconfiguração não é tanto o risco de segurança (isso pode ser gerenciado) quanto a quantidade de tempo extra que você precisará para implementá-lo.

Para a maioria dos aplicativos do Azure, sugiro simplesmente examinar alguma forma de controle de versão do SQL (o Red Gate cria um excelente solução ), e talvez um script automatizado que você possa executar após a implantação para configurar sua outra infraestrutura. Isso permitirá a agilidade de implantação sem passar do início, criando um aplicativo de autoconfiguração que cante tudo, quando você pode aproveitar melhor o tempo gasto na implementação de alguns recursos interessantes.

    
por 25.03.2013 / 12:03
fonte

Tags