Este artigo foi traduzido por máquina.

Integração do Windows Azure

Plataforma Windows Azure para empresas

Hanu Kommalapati

Computação já comprovou valioso de atenção de empresas estabelecidas e novas empresas semelhantes em nuvem. A maioria das empresas está vendo com mais de apenas ociosa curiosidade de computação em nuvem. Como da redação deste artigo, pesquisa de mercado de TI sugere que a maioria TI da empresa gerentes tem recursos suficientes para adotar a nuvem de computação em combinação com o recursos de TI em instalações.

Obviamente, há pessoas que estão dúvidas da nuvem de computação da capacidade de fornecer as promessas. Essa solução emergente é quase parecida com a criação da ARPANET (precursora para Internet); muitas instituições de pesquisa dúvidas não desejem se associar à rede inicial para o medo de perder seus dados particulares. Depois de cientistas viram os benefícios da rede de dados e a colaboração que ele ativado, não havia nenhuma interrupção-los e o resto é história. Grandes empresas hoje, como skeptics ARPANET, estão no processo de obtenção já se conhecem com a mudança de paradigma que está ocorrendo como computação recursos são obtidos e operados.

Atendimento ao cliente e as tendências do setor de detecção exigem, a Microsoft fez uma aposta enorme no, liberando a plataforma Windows Azure e os serviços de suporte necessários para a criação e a execução de serviços de nível industrial na nuvem de computação em nuvem. Neste artigo, eu discutir a plataforma Windows Azure no nível da arquitetura e formam uma interseção com as necessidades de soluções corporativas.

Computação de nuvem

Tenho certeza de que há várias definições de computação em nuvem, mas a um como o máximo é: computação entregue como um utilitário através de protocolos e padrões da Internet. Essa definição abre as possibilidades de “ nuvem pública ” e conceitos de “ particular nuvem ”. Nuvens públicas, como o nome indica, estão disponíveis para qualquer pessoa que wields um cartão de crédito. Nuvens particulares servem para uso exclusivo de uma empresa ou um consórcio de empresas como identificado pelo declaração de missão da nuvem particular.

A plataforma Windows Azure, Amazon Web Services, Google App Engine e Force.com são alguns exemplos de nuvens públicas. Qualquer data center particular executada por uma grande empresa pode ser chamado uma nuvem particular se tira proveito do modelo unificados de recursos habilitado pela virtualização mais abrangente que trata de computação, armazenamento e rede como um pool de recursos homogêneo e tira proveito dos processos altamente automatizados para o sistema operacional.

Computação utilitário tem sido um sonho dos visionários no espaço de automação do computador para, desde que eu possa se lembrar. Tentativas de iniciativas semelhantes de outros fornecedores feitas em negrito e DSI (Dynamic Systems Initiative) da Microsoft ajudar a operadores de data center fornecer características utilitário: altamente automatizados, autogerenciados, auto-otimizados e monitorados de armazenamento, rede e computação ciclos. Enquanto a visão estava louvável, ele viu sucesso misto. O surgimento da virtualização feitas utilitário computação uma realidade. A virtualização ajudou desacoplar o sistema operacional e aplicativos de hardware físico. Ele trata como dados, para que os processos automatizados podem ser desenvolvidos para fluxo contínuo sob demanda do sistema operacional e outros recursos dependentes para o hardware de destino.

Para preparar o terreno para uma discussão de plataforma Windows Azure, brevemente examinarei a terminologia do setor na nuvem de computação espaço e o mapa a plataforma Windows Azure para esses termos para que nós pode prontamente compreender. Figura 1 mostra o diagrama sanduíche da terminologia do setor e o mapeamento da plataforma Windows Azure. Examinarei diversos tipos de serviço em nuvem e suas diferenças relativas em detalhes nas seções a seguir.

Figura 1 Windows Platform Azure É uma oferta de PaaS

Software como um serviço

O software como um serviço (SaaS) é um modelo de negócios entrega do software no qual uma festa ou provedor hospeda um aplicativo e o torna disponível para clientes em cada assinatura. Os clientes SaaS usar o software em execução na infra-estrutura do provedor em uma base flexível. Não há compromissos não antecipados, para que o cliente é dispensado quaisquer contratos de longo prazo.

Com base nos termos contratuais, os clientes podem optar por sair usando o software a qualquer momento. A infra-estrutura subjacente e a configuração de software são invisíveis aos usuários e, portanto, os clientes que liquidar para a funcionalidade que é fornecida fora da caixa. SaaS usa uma arquitetura altamente diversos clientes, e contextos de usuário são separados uns dos outros logicamente no tempo de execução e o restante.

Este multilocação pode ser censurável para algumas empresas devido à natureza de seus negócios para que provedores podem oferecer uma infra-estrutura fisicamente isolada para esses clientes e cobrá-los os custos extras associados à manutenção de software e o hardware. Microsoft Business Productivity Online Suite (BPOS) e CRM online são bons exemplos de SaaS. A Microsoft também oferece hospedando dedicado para esses serviços para custos adicionais.

Aplicativos de colaboração que resolvem o mesmo problema em muitas empresas têm sido muito bem-sucedidos no espaço de SaaS. Como a configuração de hardware e software é transparente para os usuários finais, há mínima se algum precisar para IT pro envolvimento. Alguns aplicativos SaaS podem ser personalizados por usuários finais por meio da configuração; no entanto, a maioria não permitir personalização. Como resultado, o espaço da equipe de desenvolvimento no contexto do aplicativo SaaS também é minimizado.

SaaS pode melhorar o aspecto do tempo de entrega de aplicativos e no processo de corrigir os problemas de reclamar sobre freqüentemente alinhamento de TI de negócios. Durante os estágios iniciais de adoção de SaaS da empresa para o pesadelo dos arquitetos corporativos, “ sombra IT ” (uma pequena equipe de programadores com alto conhecimento planilha associada a unidades de negócios, por exemplo) podem distrair iniciativas em toda a empresa. Isso ocorre porque o SaaS capacita unidades de negócios para ignorar os processos de aquisição de TI. As equipes de arquitetura empresarial precisam perceber isso e educar as unidades de negócios sobre a importância de controle. Eles também devem desenvolver novos processos de controle ou modificar as existentes para acomodar SaaS.

Ambientes de TI atuais podem impedem as empresas de pequenas e médio porte da necessidade de recursos necessários para realizar seus negócios ideal de devido a carga de investimentos em TI enormes. SaaS pode fornecer todas as empresas do mesmo tipo de recursos de TI que agora estão acessíveis somente por grandes empresas. Como SaaS não requer investimentos em TI pesado, ele pode nível o campo de jogo para empresas de pequeno, colocando corporativo recursos de TI dentro de seu entendimento.

Da perspectiva do provedor de serviço, qualquer empresa de pequeno porte pode tornar-se um provedor de SaaS e competir com grandes software casas. Agora, dessas empresas podem concentrar em seus principais recursos de domínio em vez da outlaying capital escasso para a aquisição e gerenciamento de infra-estrutura de hardware e software.

Plataforma como um serviço

SaaS parece para que seja o que é certo fazer para todos os softwares precisam de uma empresa. No entanto, cada empresa é exclusiva em sua personalidade IT, resultante da tecnologia legada assim como de seu domínio comercial em particular. Localizando uma SaaS serviço para cada necessidade de linha de negócios é muitas vezes impossível, então as empresas precisam continuar a criação de aplicativos. Plataforma como um serviço (PaaS) preenche as necessidades de quem deseja compilar e executar aplicativos personalizados como serviços. ISVs, provedores de serviços de valor agregado de TI da empresa podem ser lojas e qualquer pessoa que precisa de aplicativos personalizados. PaaS oferece servidores de aplicativo hospedado com escalabilidade quase infinita resultantes de pools de recursos grandes dependem. PaaS também oferece serviços de suporte necessários como armazenamento, segurança, ferramentas de desenvolvimento e infra-estrutura de integração de uma plataforma completa.

Um provedor de serviços oferece um ambiente de servidor de aplicativo pré-configurados, virtualizados aos quais aplicativos podem ser implantados pela equipe de desenvolvimento. Desde que os provedores de serviços de gerenciar o hardware (patches, upgrades e assim por diante), bem como o tempo de atividade do servidor de aplicativo, o envolvimento de profissionais de TI será minimizado. Os desenvolvedores criem aplicativos e anotar os aplicativos com descritores de recursos. Após a implantação, o mecanismo de provisionamento vincula os recursos de infra-estrutura necessária declarados em descritores para o aplicativo. Os recursos podem incluir pontos de extremidade de rede, balanceadores de carga, núcleos de CPU, as dependências de software e memória. Escalabilidade por demanda combinada com o gerenciamento de servidor de hardware e aplicativo libera os desenvolvedores de questões de infra-estrutura e permite que a concentração em criação de aplicativos. PaaS é geralmente adequado para aplicativos totalmente novos, como aplicativos legados geralmente exigem a refatoração extensa em conformidade com regras de proteção de segurança.

Infra-estrutura como um serviço

A infra-estrutura como um serviço (IaaS) é semelhante a hospedagem tradicional, onde uma empresa usará o ambiente de host como uma extensão lógica do datacenter em suas instalações. Os servidores (físicos e virtuais) são alugados como a necessidade e os profissionais de TI que gerenciam a infra-estrutura têm controle total sobre a configuração de software. Alguns provedores ainda podem permitir flexibilidade na configuração de hardware, que faz com que o serviço mais caros em comparação com uma oferta PaaS equivalente.

A composição de software pode incluir sistemas operacionais, plataformas de aplicativos, middleware, servidores de banco de dados, barramentos de serviços corporativos, os componentes de terceiros e estruturas e gerenciamento e software de monitoramento. Com a liberdade de escolher o servidor de aplicativos vem flexibilidade na escolha também as ferramentas de desenvolvimento. Esse tipo de flexibilidade aumenta a complexidade do ambiente de TI, como cliente da necessidade de profissionais de IT para manter os servidores como se estivessem em suas instalações. As atividades de manutenção podem incluir patches e atualizações do sistema operacional e o servidor de aplicativos, balanceamento de carga, failover de clusters de servidores de banco de dados, backup e restauração e outras atividades que reduzem os riscos de falhas de hardware e software.

A equipe de desenvolvimento irá criar, testar e implantar aplicativos com reconhecimento total da configuração do hardware e software dos servidores. Muitas vezes desastres recuperação e continuidade de negócios são as responsabilidades do cliente. Um benefício importante IaaS é que ele pode permitir a migração de aplicativos legados para a nuvem. Uma vez que a flexibilidade de IaaS permite a construção de qualquer configuração, é difícil a portabilidade de um aplicativo entre os provedores de nuvem. Migração de aplicativos herdados é o nicho para IaaS, pois permite imitando a infra-estrutura corporativa na nuvem. A flexibilidade de IaaS também permite que novos aplicativos que requerem controle significativa de configuração do software. Por exemplo, alguns aplicativos podem exigir a instalação de serviços e bibliotecas de terceiros e IaaS permite tal instalação com sem restrições.

A plataforma Windows Azure tem todos os benefícios do PaaS, enquanto que, ao mesmo tempo prometendo seja tão flexível quanto IaaS, conforme ilustrado no Figura 1. A plataforma Windows Azure combina grandes conjuntos de computação (servidores commodity), redes e recursos de armazenamento em um ambiente de computação do utilitário do qual os clientes podem desenhar recursos sob demanda e pagar somente o uso. Típico de nuvem ambientes, a plataforma Windows Azure ajuda os clientes a evitar outlays capital inicial e permite o crescimento dos recursos de TI em conforme a necessidade.

Plataforma Azure do Windows

A plataforma Windows Azure fornece um servidor de aplicativo hospedado e a infra-estrutura necessária de armazenamento, redes e integração para a criação e a execução de aplicativos do Windows. A plataforma Windows Azure se baseia em grandes conjuntos de hardware commodity na criação do ambiente de computação do utilitário. Figura 2 mostra o modelo de recursos de plataforma Windows Azure onde armazenamento virtualizado, rede e recursos implantados sob demanda por políticas provisionamento definidas em tempo de implantação de computação. O controlador de malha é o cérebro do ecossistema inteiro, com um conjunto de recursos dedicados que não fazem parte do pool de recursos do aplicativo. Desde que o controlador de malha já não pode falhar, ele fornece um ambiente de hardware e software altamente redundante.

Figura 2 Exibir conceitual da infra-estrutura de computação (Windows Azure instalação pode ser diferente)

O pool de recursos de computação abrange recursos de mercadoria feitas tolerantes a falhas pelo controlador de malha. O controlador de malha é projetado para detecção antecipada de falhas do aplicativo e gera instâncias adicionais para atender aos contratos de nível de serviço contratuais. Como o ambiente Windows Azure é uma plataforma completa de hospedagem de aplicativos, ele garante sistemático qualidades do aplicativo, oferecendo recursos praticamente ilimitados por meio de provisionamento por demanda. Recursos não utilizados são retornados ao pool, aumentando a utilização. Os recursos incluem ciclos de computação, armazenamento virtualizado para persistência e recursos de redes virtualizados para reconfiguração dinâmica de rotas de rede privada e pública. As configurações físicas desses recursos são por design, invisível para desenvolvedores e arquitetos de aplicativos.

Então, como os proprietários dos aplicativos provisionar esses recursos? Usar o telefone e chamando um profissional que fazemos em instalações tradicionais ambientes de TI está fora da pergunta, como os datacenters de plataforma Windows Azure maciços são gerenciados por algumas poucas profissionais que dependem muito de automação. As operações diárias normais do datacenter requerem intervenção humana. A plataforma Windows Azure permite que os proprietários de aplicativos provisionar os recursos necessários por meio de modelos legível por máquina que compõem os descritores de recursos. Na plataforma Windows Azure, esses descritores de recursos são chamados modelos de serviço. Esses modelos de serviço especificam os recursos de aplicativo e suas dependências suficientes para provisionar a infra-estrutura de tempo de execução concluída sem envolvimento humano. Por essa automação, o tempo de provisionamento de infra-estrutura de aplicativos é geralmente menos de cinco minutos. Se você comparar isso com a abordagem procure e provisionamento de ambientes de instalações típica, segure o poder da nuvem de computação.

Calcular

A parte de computação da plataforma Windows Azure é responsável por fornecer ciclos de CPU para a execução de aplicativos. Aplicativos são hospedados em ambientes virtualizados para impedir quaisquer dependências físicas no hardware e sistema operacional subjacente. Menos rigidez dos aplicativos é obtido por meio de recursos virtualizados, que incluem arquivos locais, o armazenamento persistente (estruturados e não-estruturados) e os recursos de diagnóstico e instrumentação. O ambiente de hospedagem é implementado como uma máquina virtual, assim, quaisquer falhas de aplicativo não afetam outros aplicativos em execução no mesmo hardware físico.

Os aplicativos são implantados na plataforma Windows Azure como pacotes de funções e código executável associado e recursos. Uma função Azure descreve as características do ambiente de hospedagem declarativamente. Quando um aplicativo implantado é ativado, o ambiente de provisionamento Azure analisa o modelo de serviço, seleciona uma imagem pré-configurada do virtual machine (VM) com base no tipo de função, copia os bits de aplicativo para a máquina virtual, inicializa o computador e inicia os serviços de aplicativo necessário. A definição de serviço mostrada na Figura 3 representa um aplicativo de lista de compras, usado como referência no decorrer deste artigo.

Figura 3 Modelo de serviço para Web e funções de trabalho

Definição de ShoppingListService

<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="ShoppingList">
<WebRole name="ShoppingList_WebRole">
<LocalResources>
<LocalStorage name="ShoppoingList_ImageCache" sizeInMB="100" 
cleanOnRoleRecycle="false"/>
</LocalResources>
<InputEndpoints>
<InputEndpoint name="HttpIn" protocol="http" port="80" />
<InputEndpoint name="HttpsIn" protocol="https" port="443" />
</InputEndpoints>
<ConfigurationSettings>
<Setting name="DiagnosticsConnectionString" />
<Setting name="DataConnectionString" />
<Setting name="ShoppinglistOut"/>
</ConfigurationSettings>
</ WebRole>
< WorkerRole name="ShoppingList_WorkerRole">
<Instances count="2" />
<ConfigurationSettings>
<Setting name="DiagnosticsConnectionString" />
<Setting name="DataConnectionString" />
<Setting name="ShoppinglistIn"/>
</ConfigurationSettings>
< WorkerRole />
</ServiceDefinition>

Configuração ShoppingListService

<?xml version="1.0"?>
<ServiceConfiguration serviceName="ShoppingList">
</Role>
<Role name="ShoppingList_WebRole">
<Instances count="3" />
<ConfigurationSettings>
<Setting name="DiagnosticsConnectionString" value=
              "UseDevelopmentStorage=true" />
<!-- flip the commenting of the following two lines for application 
storage needs on  local dev fabric -->
<!--<Setting name="DataConnectionString" value=
                  "UseDevelopmentStorage=true" />-->
<Setting name="DataConnectionString" 
value="DefaultEndpointsProtocol=http;
AccountName=<<account name>>;AccountKey=<<account key>>" />
<Setting name="ShoppinglistOut" value="shoppinglistq"/>
</ConfigurationSettings>
</Role>
<Role name="ShoppingList_WorkerRole">
<Instances count="2" />
<ConfigurationSettings>
<Setting name="DiagnosticsConnectionString" value=
              "UseDevelopmentStorage=true" />
<!-- flip the commenting of the followign two lines for local dev fabric -->
<!--<Setting name="DataConnectionString" value=
                  "UseDevelopmentStorage=true" />-->
<Setting name="DataConnectionString" 
value="DefaultEndpointsProtocol=http;
AccountName=<<account name>>;AccountKey=<<account key>>" />
<Setting name="ShoppinglistIn" value="shoppinglistq"/>
</ConfigurationSettings>
</Role></ServiceConfiguration>

O aplicativo de lista de compras descrito em Figura 3 solicita três instâncias da função da Web e duas instâncias da função de trabalho. O tráfego da Web de várias instâncias de uma função de Web é automaticamente com balanceamento de carga e as três ocorrências serão ser provisionadas com SSL, bem como os pontos de extremidade HTTP por descrição do modelo de serviço. Para evitar a falha total do aplicativo, o controlador de malha distribui as alocações entre vários domínios de falha. A organização de domínio falha é muito mais complexo do que o modo de exibição simplificado mostrado no Figura 2. Para fins de simplicidade, você pode considerar cada rack do servidor com a rede associada switch e a fonte de alimentação como falha de um domínio.

Per Figura 2, o controlador de malha inicialmente alocado Web uma função de cada falha domain–racks número 1, 3 e # n. Examinarei a confiabilidade de toda a camada de computação de Windows Azure da perspectiva de alguns dos eventos hipotéticos. Durante evento # 1, Web função # 1 e função de operador # 1 param de responder como resultado de falha de energia do rack. O controlador de malha inicia o processo de provisionamento de função Web # 1 e função de operador # 1 na racks–rack disponível # 2 e rack 3. Mais tarde, o evento nº 2 acontece, durante o qual a função Web realocada # 1 falha a verificação de integridade devido a uma falha de aplicativo. Agora o controlador de malha inicia alocando função Web # 1 a um dos outros racks disponíveis.

Durante o curso desses eventos, a disponibilidade dos aplicativos não é afetada. As solicitações de página da Web continuam a ser atendidas pelo menos duas funções da Web, enquanto continua trabalho pelo menos uma função para extrair transacionais itens nas filas e gravar para o Windows Azure Storage. O controlador de malha se esforça para alcançar o equilíbrio de três instâncias de função Web saudáveis e duas instâncias de funções de trabalho em qualquer determinada instância de tempo. Na realidade, os racks podem ser equipados com fontes de alimentação redundantes e switches de rede, assim a reciclagem de papel e da realocação podem ocorrem freqüentemente devido a problemas de aplicativos ou dimensionamento até atender aos objetivos de escalabilidade.

O modelo de lista de compras de serviços solicitado duas funções de trabalho para evitar um ponto único de falha. Mesmo que a camada Web e a camada de lote são dissociados através do Windows Azure filas, ainda é uma boa prática para solicitar pelo menos duas funções de operador para hospedagem de serviços sensíveis ao tempo de missão crítica em lotes. Você pode apenas obter imediatamente com uma função de trabalho se o serviço hospedado não sensíveis ao tempo.

Figura 1 indica que a plataforma Windows Azure está se esforçando para oferecer as vantagens do PaaS, mas ao mesmo tempo é capaz de atingir a flexibilidade de IaaS. Isso é ativado pelo modelo de implantação baseada em diretiva manifestado Web funções, funções de trabalho, funções CGI e várias outras funções por vir no futuro. A lista de funções suportadas continuará a crescer para atender às necessidades de implantação de aplicativos e diversas de clientes.

Custo-Oriented Architecture para a nuvem

Decisões de arquitetura podem causar impactos profundos na economia das operações para pequenas e grandes empresas. Embora em nuvem é sobre IT agilidade de computação, considerações sobre despesas operacionais das empresas precisará ser levado em consideração durante o planejamento da solução. A arquitetura de um aplicativo de nuvem precisa oferecer funcionalidade e sistemático qualidades (escalabilidade, disponibilidade, confiabilidade e desempenho) e, ao mesmo tempo ao mesmo tempo otimizando as despesas operacionais. Em situações nas suas instalações, arquitetos de aplicativos raramente preste atenção ao custo de armazenamento, a largura de banda da rede ou o custo de ciclos de computação, já que esses são capital despesas incorridas no nível da organização.

Por exemplo, a otimização do armazenamento de aplicativos geralmente não na parte superior de tarefas do arquiteto, como parte de gastos operacionais não são os custos de manutenção do armazenamento. A principal prioridade para os sistemas no local é oferecer importantes qualidades sistemático dentro do orçamento alocado. Arquitetura de sistemas para despesas operacionais ideal se torna um elemento importante do processo de desenvolvimento de software no contexto da nuvem de computação.

Examinarei o modelo de custo da plataforma Windows Azure da perspectiva do aplicativo lista de compras como mostrado no Figura 4. O diagrama mostra o modo de exibição de arquitetura lógica da lista de compras com setas indicando a movimentação de dados. As setas tracejadas indicam consumo de largura de banda intra datacenter, enquanto as linhas sólidas mostram a movimentação de dados dentro e fora do data center em nuvem.

Figura 4 Modelo Azure plataforma de carga de aplicativo do Windows

A plataforma Windows Azure considera apenas encargos de entrada e saída para transferência de dados, ignorando as transferências de dados local dentro de um data center. Todos os dados gravados para Windows Azure filas não incorrer em qualquer largura de banda ou encargos de armazenamento, como o consumo de armazenamento por filas é altamente transitório. No entanto, as filas incorrerá em taxas por transação. Inspecionar, leitura ou gravação de um item da fila é considerada uma transação.

Windows Azure plataforma de servidor uso encargos baseiam-se no número de funções e a quantidade de tempo de que um aplicativo é implantado. Isso significa que, mesmo que o aplicativo não tenha nenhuma solicitação de usuários finais, o sistema de cobrança de plataforma Windows Azure irá cobrar por hora de ocorrência para a função estados “ suspensos ” e “ iniciado ”.  Portanto, tem recomendável para proativamente aparar verticalmente o número de funções ativos com base nas demandas dos aplicativos. No momento, esse é um processo manual; no entanto, você pode ser capaz de escala automática o aplicativo com base em padrões de escalabilidade de aplicativos usando dados de diagnóstico e o gerenciamento de serviço API. Uso de Windows Azure tabelas, filas e BLOBs incorrerão em custos de armazenamento manutenção, cobrados mensalmente, por cada GB no registro. Consulte o Figura 5 para Windows Azure preços que foi lançado no momento da redação deste artigo.

Figura 5 Windows Azure preços

Preços de plataforma Windows Azure são simples com uma exceção do armazenamento usado por BLOBs e tabelas. Uso do Windows Azure Storage da conta é medido por dia durante um ciclo de cobrança e uma média diária é calculada. O encargo será ser calculado multiplicando essa média diária por US$ 0,15/GB. Por exemplo se você armazenar 20 GB no primeiro dia, adicionar 10 GB no dia dois, adicionar 5 GB no dia três e excluir 5 GB no dia quatro sem nenhuma atividade durante o restante do ciclo de cobrança, o preço ser computado como mostrado abaixo:

((20 +10 + 5 – 5)/30) * 0.15 = $0.15

Isso pressupõe um ciclo de tarifação de 30 dias. Amostragem diária de armazenamento irá se certificar de que aplicativos com armazenamento altamente transitório precisam ainda pagará seu uso do armazenamento, ao contrário de um sistema que mede apenas no final do ciclo de cobrança.

Como mencionado anteriormente, arquitetura é um fator importante na mensal do custo de um aplicativo operacional. Por exemplo, se um aplicativo gera muitos dados e apenas os dados mais recentes — dizer as duas últimas semanas — é necessária para a funcionalidade do aplicativo, ajustada a arquitetura para excluir os dados desnecessários ou periodicamente para transferi-lo aos sistemas nas suas instalações. Talvez seja melhor pagando um custo de largura de banda única que incorrer em custos de armazenamento permanente. O mesmo pode ser verdadeiro com os dados de referência que não faz parte do conjunto de dados ativo. Essa abordagem pode funcionar bem para empresas já investiram em capacidade de arquivamento de dados.

O cenário do aplicativo

Examinarei diversos aspectos da plataforma Windows Azure no contexto de um cenário de nível industrial e-commerce: o aplicativo de lista de compras. Me concentrarei na criação de uma lista de compras e salvá-lo para uso posterior ao mesmo tempo, fazer compras na loja. A interface do usuário da Web compõe a lista de compras e usa serviços da Web para salvá-lo para o Windows Azure Storage. Para escalabilidade, a camada Web grava listas de compras em uma fila de Azure Windows; periodicamente, um processo em lotes monitora as listas de filas e os salvará em Windows Azure tabelas. Vou usar a autenticação com base em Windows Azure e segurança baseada em função para demonstram aspectos da solução do mundo real.

Figura 6 Comprar lista de aplicativos no Windows Platform Azure

No contexto da arquitetura orientada a custo discutido anteriormente, várias decisões terá impacto sobre as despesas operacionais mensais. Aqui estão alguns aspectos de um sistema que devem ser considerados antes de prosseguir com a arquitetura:

1. Taxa de crescimento de dados de referência
2. Taxa de crescimento de dados transacionais
3. Capturar a taxa de dados de criação de perfil comportamentais
4. Taxa de crescimento de dados de eventos de negócios
5. Taxa de dados de eventos do sistema de captura
6. Conteúdo de mídia relacionado a produtos
7. Usando filas vs. interação direta com o armazenamento persistente

Meu cenário de lista de compras não incluiu muito conteúdo de mídia, portanto, isso não fosse um grande fator na equação de custo, mas pode ser muito importante a considerar para sites de conteúdo que oferecem fluxos de áudio, imagens e vídeos. Figura 7 mostra para um aplicativo típico do custo operacional mensal na plataforma Windows Azure. A planilha não inclui os custos de pessoal de desenvolvimento, suporte operacional e suporte do usuário final.

Figura 7 Windows Azure operacional Calculadora de despesas para um aplicativo de E-Commerce

Um ambiente de computação em nuvem reduzirá o número da equipe de suporte operacional, portanto, isso deve ser fatorado ao comparar o ROI entre na empresa e a nuvem. Além disso, é importante incluir energia e depreciado despesas de capital por aplicativo na equação de ROI. Atuais no-premissas modelos de aplicativo custo geralmente Don incluem essas despesas, é muito difícil dividir a energia consumida por aplicativo. O mesmo é verdadeiro para refrigeração e espaço físico. Calculadoras ROI podem usar suposições informadas na ausência de divisões de objetivos de custo.

A Calculadora de custo simples mostrada na Figura 7 estima a despesa operacional de aplicativos hospedados na plataforma Windows Azure. Essa ferramenta com base no Excel do Microsoft permite que vários parâmetros de entrada de um aplicativo de comércio eletrônico típico e ele calcula o custo operacional mensal usando a plataforma Windows Azure preços de tabela mostrada na Figura 5. Lembre-se de que os parâmetros padrão usados na ferramenta são fictícios; você precisa levar seu sistema em consideração antes de tomar decisões com base na saída da ferramenta. A Calculadora de custo é orientada pelo número de visitantes por mês e presume certos número de visitas à página e transacional e criação de dados de eventos. A equipe de plataforma Windows Azure criou uma ferramenta mais abrangente que calcula o custo mensal de um aplicativo e também compara o TCO dos aplicativos no local com a do Windows Azure. A ferramenta Windows Azure TCO pode ser acessada em Microsoft.com/windowsazure/TCO.

Como mostra a Figura 7, nosso aplicativo fictício gera 9000GB dos dados em um determinado mês custa aproximadamente US$ 1,350 por mês se fôssemos armazenar isso dentro do Windows Azure tabelas. Tenha em mente que Figura 7 mostra apenas o armazenamento de point-in-time e taxas de dados de eventos podem se acumulam quando o aplicativo continua a operar. Tais custos podem ser otimizados ajustando a quantidade de dados de evento capturados como um aplicativo amadurece operacionalmente. A Calculadora de custo é orientada pelo número de visitantes por mês e usa um número hipotético das funções de operador 3 e 10 funções da Web. A cobrança mensal total é $ 3,571.

Como alternativa, o aplicativo pode ser projetado para canal os dados do evento pagando os custos de largura de banda única (US$ 0,10/GB transferida externamente) a um sistema de armazenamento já depreciado no local, se ele existir. Estratégias semelhantes podem ser aplicadas a transações e comportamentais dados para evitar tarifas de armazenamento cumulativo de criação de perfil.

Calcule encargos não são de natureza cumulativos e, portanto, causam um impacto menor na despesa operacional geral do aplicativo. No entanto, há oportunidade para ajustar o número de instâncias de função em lotes com base no perfil observado escalabilidade do aplicativo, para obter o alívio marginal em despesas operacionais e da Web ativa. Entre os encargos de armazenamento e de informática, calcule uso pode ser controlado, a qualquer momento, enquanto custo de armazenamento depende de decisões de arquiteturais que não podem ser desfeitas facilmente depois que o aplicativo é criado. Assim, minha sugestão é obter sua arquitetura de persistência certa na primeira vez.

Com o modelo de custo do aplicativo, as grandes empresas irão preste muita atenção à segurança de aplicativo, que explorarei agora.

Segurança de computadores

As empresas estão detalhadas sobre a segurança de aplicativos e dados na nuvem. Enquanto a segurança do datacenter, infra-estrutura e o sistema operacional são manipulados pela Microsoft, a segurança de aplicativos ainda é responsabilidade dos proprietários dos aplicativos. Examinarei a segurança de aplicativos da perspectiva do meu aplicativo Web de lista de compras. Proteger um aplicativo da plataforma Windows Azure é semelhante à sua contraparte em suas instalações. A plataforma Windows Azure fornece vários componentes do sistema para ajudar os desenvolvedores a integrar a segurança em aplicativos. Esses componentes de sistema permitem autenticação básica e independente e autorização a cenários federados adequado para grandes empresas.

Identidade básica

Um modelo de identidade básicas, como o nome sugere, implementa uma arquitetura de identidade independente para atender às necessidades de aplicativos ou um grupo co-localizado de aplicativos que compartilham o mesmo conjunto de usuários e está intimamente ligado ao mesmo sistema de identidade a nível de implementação. As Exemplos de plataforma Windows Azure contêm um conjunto de provedores ASP.NET (associação, funções, perfil e sessão) que podem ser usados para implementar uma solução básica de identidade. Provedores Windows Azure ASP.NET são implementados no Windows Azure Storage, que inclui Windows Azure tabelas e BLOBs. Esses provedores implementam os contratos de provedor ASP.NET e aproveitam APIs StorageClient que fazem parte da plataforma Windows Azure SDK. A esquema dos provedores é mostrada no Figura 8.

Figura 8 Windows Azure ASP.NET Providers

Para os aplicativos usar provedores Windows Azure ASP.NET, o arquivo Web.config precisa ser modificado para remover os provedores padrão e incluir os novos. As alterações na configuração mostradas na Figura 9 são semelhantes às alterações que devem ser feitas para provedores ASP.NET personalizados em situações nas instalações.

Figura 9 Alterações no Web.config para Windows Azure ASP.NET Providers

<system.web>
  ... ... ... ...
<authentication mode="Forms" />
<!-- Membership Provider Configuration -->
<membership defaultProvider="TableStorageMembershipProvider"
userIsOnlineTimeWindow="20">
<providers>
<clear/>
<add name="TableStorageMembershipProvider"
type="Microsoft...AspProviders.TableStorageMembershipProvider"
description="Membership provider using Azure storage"
applicationName="ShoppingList"
... ... ... ... ...
minRequiredNonalphanumericCharacters="0"
requiresUniqueEmail="true"
passwordFormat="Hashed"/>
</providers>
</membership>
<sessionState mode="Custom"
customProvider="TableStorageSessionStateProvider">
<providers>
<clear />
<add name="TableStorageSessionStateProvider"
type="Microsoft...AspProviders.TableStorageSessionStateProvider"
applicationName="ShoppingList"/>
</providers>
</sessionState>
<roleManager enabled="true"
defaultProvider="TableStorageRoleProvider"
cacheRolesInCookie="true"
cookieName=".ASPXROLES"
cookieTimeout="30"
... ... ... ... ...
cookieProtection="All">
<providers>
<clear/>
<add name="TableStorageRoleProvider"
type="Microsoft....AspProviders.TableStorageRoleProvider"
description="Role provider using table storage"
applicationName="ShoppingList" />
</providers>
</roleManager>
... ... ... ...
</system.web>

Depois que os provedores ASP.NET são configurados, perfis de usuário de autenticação, autorização e podem ser implementados da mesma forma tradicionais aplicativos ASP.NET. Observe que a configuração em Figura 9 contém um provedor de sessão baseada em armazenamento Azure do Windows, que permite que o armazenamento de estados de sessão em uma mídia durável. Como balanceadores de carga do Windows Azure Don suportam sessões de auto-adesivas, armazenamento dados da sessão no Windows Azure armazenamento oferece uma melhor experiência ao usuário por meio da personalização baseada em sessão. O modelo de identidade básicos é adequado para aplicativos que possuem ciclos de usuário identidade vida (criação de contas de usuário, uso e fechamento) que começam e terminam no mesmo aplicativo. Implementação básica de identidade pode ser escolhida por diversos motivos, incluindo o seguinte:

• Um aplicativo deseja manter os registros de identidade do usuário cuja propriedade completa
• A falta de infra-estrutura para implementar o armazenamento de identidade federada e serviços de suporte
• Aplicativos com um tempo de vida curto (por exemplo, marketing Concursos e promoções) que exigem registro de usuário

Provedores Windows Azure ASP.NET também podem ser usados para autenticar os usuários do AJAX, bem como aplicativos do Silverlight. As AJAX podem ser chamadas AuthenticationService ProfileService classes e RoleService, localizadas dentro de System.Web.Extensions.dll, podem ser publicadas como pontos de extremidade .svc por meio da função Windows Azure na Web. Tenha em mente que esses serviços exigem compatibilidade com ASP.NET para acessar dados específicos de contexto HTTP. O artigo intitulado “ construir aplicativos empresariais de linha de negócios com o Silverlight, parte 2 ” (MSDN.Microsoft.com/magazine/dd434653), fornece informações detalhadas sobre como configurar serviços acima para ser chamado a partir do Silverlight ou do AJAX.

Modelo de identidade federada

Identidade federada é necessária para aplicativos que incluem a cadeia de fornecimento, a cadeia de valores, colaboração e redes sociais, bem como aplicativos que integram os armazenamentos de identidade popular na Internet. A pilha do Windows Azure ASP.NET pode ser combinada com o Windows Identity Foundation (WIF) para integrar com um ou mais provedores de serviço de token de segurança. WIF funciona em conjunto com as relações de confiança pre-established ativadas pelo WS-Trust e WS-Federation. Figura 10 mostra uma exibição conceitual do aplicativo lista de compras trabalhando com dois provedores de token — um em premissas e o outro é um parceiro de atendimento.

Figura 10 Vários serviços de token podem ser registrados com o Windows Azure Applications

A relação de confiança descreve os pontos de extremidade do STS (serviço de token seguro) e o necessário certificados X 509 para assinar o token de solicitações e respostas. Figura 11 mostra a relação de confiança de esquema, a representação XML do qual será incluída na configuração do aplicativo lista de compras no momento da implantação. Os usuários obtém autenticados em seus respectivos sistemas e o token SAML (Security Assertion Markup Language) resultante é encaminhado para o aplicativo solicitante.

Figura 11 Descritor de confiança federada

Como mostra a Figura 10, quando um usuário acessa o conteúdo da Web seguro no aplicativo Windows Azure hospedado na plataforma de lista de compras, WIF encaminha a solicitação para um shopping lista STS URL presentes na configuração de confiança. O STS de lista de compras reúne as credenciais, autentica usuários em relação ao Active Directory, constrói um token SAML com a Ajuda do Active Directory Federation Services (ADFS, anteriormente conhecido como “ servidor Geneva ”) e encaminha para o aplicativo de lista de compras via navegador da Web. WIF em execução dentro do site da lista de compras no Windows Azure irá extrair declarações SAML e executar verificações de autorização.

Quando vários STSes estão envolvidos, um site terá que implementar a lógica de conversão de token para converter tokens diversos em um formato canônico. Para minimizar o impacto de introduzir um STS de novo no sistema, a lógica de conversão de símbolo pode ser exteriorizada ou encapsulada em um componente que pode ser modificado sem causar impacto nos aplicativos que consomem-los. Figura 12 mostra o esquemático de conversão de token que funciona junto com WIF.

Figura 12 Identidade federada System com provedores de token de vários

Cenários, como serão habilitados pelo modelo de identidade federada:

• Armazenamento de identidade registra suas instalações para conformidade normativa
• Aproveitar o existente o infra-estrutura de segurança de aplicativos em instalações
• Integração com parceiros da cadeia de valores e cadeias de fornecimento
• Sign-on único entre o local e o aplicativo de plataforma Windows Azure

Com freqüência, grandes empresas já implementaram serviços de autenticação e servidores de diretório que precisa ser aproveitado para proteção de aplicativos. A plataforma Windows Azure permite aproveitar da nuvem rápida implantação de aplicativos enquanto ao mesmo tempo que aproveita a infra-estrutura existente de segurança. Além disso, a plataforma Windows Azure por design permite o uso de uma identidade federada, que permite que vários cenários de integração entre parceiros comerciais e cadeias de valor.

Windows Storage Azure

Aplicativos e serviços implantados na plataforma Windows Azure podem usar o Windows Azure armazenamento de persistência de conteúdo não-estruturado e semi-estruturado. Windows Azure Storage compreende três recursos fundamentais necessários para criar serviços e aplicativos de nível industrial: Tabelas, BLOBs e filas. Windows Azure Storage é amplamente dimensionável e mecanismo de persistência altamente confiável que também esteja acessível para os aplicativos hospedados no local por meio de interface de serviços da Web padrão do setor como REST. Privacidade durante a transmissão, Windows Azure Storage oferece suporte ao acesso baseado em SSL HTTPS juntamente com o protocolo HTTP padrão. Escalabilidade e outras qualidades sistemático são obtidas por meio de um farm de armazenamento grande que consiste em hardware e disco arrays mercadoria servidor, que é gerenciado pelo Windows Azure Storage software. O acesso de armazenamento é com carga balanceada automaticamente em um conjunto de nós de escalabilidade e disponibilidade. Cada nó é responsável por uma quantidade finita de armazenamento físico. Acesso ao armazenamento fora de escopo do nó é realizado através de uma interface ponto-a-ponto. A confiabilidade é obtida por meio de redundância das entidades armazenadas (como ShoppingList) em vários nós. O software de armazenamento faz várias réplicas (três no momento da elaboração deste documento) dos dados automaticamente quando ocorre uma gravação. Armazenamento suporta gravações transações atômicas e a transação será concluída somente após todas as réplicas são gravadas em unidades. Figura 13 mostra uma coleção de mercadoria formando o serviço de armazenamento Windows Azure de nós de armazenamento.

Figura 13 Serviço de armazenamento

Enquanto sendo usado, pode falhar em qualquer lugar qualquer unidade de armazenamento a possibilidade de que é mostrada pela “ X ” vermelho em números de nó 4 e 11. Depois que o serviço de armazenamento identifica uma unidade com falha, ele replica os dados de uma unidade está funcionando para um novo nó. O serviço de armazenamento está sempre em conformidade com as diretivas de réplicas em qualquer ponto no tempo. Mencionado anteriormente, o tráfego de solicitação de aplicativos será balanceamento de carga entre vários nós.

Esse tipo de arquitetura ajudará as escalas maciças exigidas pelo nuvem pública PaaS ofertas, como a plataforma Windows Azure. Como mostra a Figura 13, vamos supor que nós, 4, 11 e 14 ter três réplicas iniciais de uma folha de dados. No caso de falha de nós, 4 e 11, nó 14 continuará atendendo as solicitações diretamente, bem como re-replicating rapidamente os dados a pelo menos dois nós adicional (nó 2 e 8) para manter os dados em um número de bom funcionamento de réplicas.

Segurança de armazenamento

Windows Azure Storage baseia-se em baseado em Hash Message Authentication Code (HMAC) para autenticar as solicitações da Web REST. A chave secreta e compartilhada associada ao projeto Windows Azure Storage é combinada com a solicitação HTTP na computação um hash de 256 bytes obtém incorporado como um cabeçalho de autorização de “ ” para a solicitação da Web. O mesmo processo é repetido no servidor para verificar a autenticidade da solicitação. Tabela Azure do Windows, fila e BLOBs seguem o mesmo processo de autenticação, enquanto a carga e o destino URLs são diferente para cada um dos tipos de armazenamento. A seguir estão as URLs para acessar os recursos de armazenamento três acima sob o projeto, digamos, “ hkshoppinglist ”:

• HTTP (s): / / hkshoppinglist.blob.core.windows. NET /
• HTTP (s): / / hkshoppinglist.queue.core.windows. NET /
• HTTP (s): / / hkshoppinglist.table.core.windows. NET /

O exemplo de código no Figura 14 mostra a criação de várias tabelas de Azure Windows como parte da preparação de armazenamento para implantação do aplicativo.

Figura 14 Pseudo-Code mostra a criação do Windows autenticada Azure tabelas e dados

[DataServiceKey("TableName")]
Public class StorageTable
{
  Private string _tableName;
  Public string TableName
{
  get { return this._tableName; }
  set { this._tableName = value; }
}
}

Public class Customer: TableServiceEntity
{
  Public string Name { get; set; }
  Public string CustomerID { get; set; }
  public Customer()
{
  PartitionKey = "enterprise";
  RowKey = string.Format("{0:10}_{1}", DateTime.MaxValue.Ticks –
  DateTime.Now.Ticks, Guid.NewGuid());
}
}
CloudStorageAccount _storageAccount = CloudStorageAccount.FromConfigurationSetting("DataConnectionString");

Public void CreateMultipleCustomers(List<Customer> customers)
{
  TableServiceContext tsc = new
  TableServiceContext(_storageAccount.TableEndpoint.AbsoluteUri, 
  _storageAccount.Credentials);
  foreach (Customer cust in customers)
{
  tsc.AddObject("customers", cust);
}
try
{
  DataServiceResponse resp =  tsc.SaveChanges(SaveChangesOptions.Batch);
  foreach (ChangeOperationResponse cor in resp)
{
  if (cor.Error != null)
{
//cor.Headers["Location"] can be parsed to find out the failed 
//requests which can be retried after correcting the error condition
}
}
}
catch (Exception ex){ //do something with the exception }
}

protectedvoid linkCreateTables_Click(object sender, EventArgs e)
{
  labelStatus.Text = string.Empty;
try
{
  CreateTable("customers");
  CreateTable("products");
}
catch (DataServiceRequestException ex)
{
  labelStatus.ForeColor = System.Drawing.Color.Red;
  labelStatus.Text = "Error: Table creation error : " + ex.Message;
}
}
//Use ADO.NET services directly to create an Windows Azure Table
Public void CreateTableUsingContext(AzureStorageTable storageTable)
{
  TableServiceContext tsc = new
  TableServiceContext(_storageAccount.TableEndpoint.AbsoluteUri, 
  _storageAccount.Credentials); tsc.AddObject("Tables", storageTable);
try
{
  DataServiceResponse resp = tsc.SaveChanges(SaveChangesOptions.None);
//handle errors
}
catch (Exception ex){//do something here}
}
//much simpler way of creating an Windows Azure Table
  publicvoid CreateTable(string tableName)
{
CloudTableClient ctc = _storageAccount.CreateCloudTableClient();
try
{
  ctc.CreateTable(tableName);
}
catch(Exception e) { //handle exception }
}

Usando o Windows Azure tabelas como um exemplo, mostrarei algumas maneiras simples de preparar o Windows Azure Storage para preenchimento transacional de dados. As Exemplos de código mostram a criação de tabelas de “ produtos ” usando TableServiceContext, bem como CloudTableClient para ilustrar a flexibilidade da interação baseada em REST e “ clientes ”. Na verdade, você também pode elaborar uma carga bruta, anexar HMAC a solicitação da Web e fazer um HTTP POST para a URL da tabela, mas requer muitos códigos e só deve ser feito como um exercício acadêmico. A abordagem recomendada é usar StorageClient, que faz parte do SDK do Windows Azure.

A função CreateTableUsingContext usa a classe AzureStorageTable para gerar a carga de criação de tabela com a Ajuda dos serviços de dados ADO.NET. TableServiceContext automaticamente gera HMAC e anexa a solicitação usando a chave contida na propriedade CloudStorageAccount.Credentials.

Armazenamento de tabela Azure do Windows permite que transações de lote, como mostra a função CreateMultipleCustomers em Figura 14. O lote não deve ultrapassar 100 operações em um conjunto de alterações de determinada e um único lote não deve exceder 4 MB de tamanho. Para obter mais detalhes, consulte a documentação do Windows Azure Storage. Somente são permitidas transações em lote com as entidades que pertencem à mesma partição.

Credenciais necessárias para a geração de HMAC são especificadas na configuração do serviço da função Windows Azure respectiva. Este é o formato da seqüência de conexão para o armazenamento local e a nuvem:

Armazenamento local:

<Setting name="DataConnectionString"
value="UseDevelopmentStorage=true"/>

Armazenamento em nuvem:

<Setting name="DataConnectionString"
value="DefaultEndpointsProtocol=
http;AccountName=
<your account>;AccountKey=<your account key"/>

Não há nenhuma noção de segurança baseada em Windows Azure Storage; assim, uma solicitação autenticada terá total acesso ao armazenamento no contexto do projeto de armazenamento. Uma exceção a isso é o recipiente de blob, que pode ser público (anônimo) ou particular. Autorização é responsabilidade do aplicativo que consome os serviços de armazenamento.

Resumo

Neste artigo eu apenas uma pequena amostra da plataforma Windows Azure. Tenho certeza de que haja muita cobertura no futuro sobre Microsoft SQL Azure, AppFabric, várias funções de servidor e outros cenários de segurança não abordados aqui. A plataforma Windows Azure é uma plataforma de computação em nuvem que foi projetada para ativar o utilitário de varredura de computação para desenvolver e hospedar aplicativos e serviços.

Grandes pools de hardware commodity são feitos altamente confiáveis por software através de um alto grau de automação. As vantagens econômicas de escalas maciças são passadas para os consumidores uma taxa de assinatura de baixo. Os assinantes serão cobrados com a utilização da largura de banda, ciclo de ciclos de computação e armazenamento em uma cobrança mensal. A plataforma Windows Azure vem com os componentes da plataforma necessários para a criação de aplicativos corporativos e serviços com nenhum compromisso antecipado de contratos de capital ou de longo prazo.

Hanu Kommalapati é um consultor de estratégia de plataforma da Microsoft e nessa função ele aconselha os clientes corporativos na criação de aplicativos de linha de negócios escalonáveis nas plataformas Silverlight e Azure do Windows.

Graças aos seguintes especialistas técnicos para revisar este artigo: Vittorio Bertocci, Brad Calder, Ryan Dunn e Tim O’Brien