Este é o quinto artigo da série sobre Windows Azure. Comecei a escrever esta série há algumas semanas com o objetivo de apresentar as principais características da plataforma de cloud da Microsoft, principalmente por existir pouco material explicativo em língua portuguesa. Se você está chegando nesta série agora, antes de prosseguir com a leitura deste texto, recomendo realizar a leitura dos textos anteriores seguindo. Eles podem ser encontrados seguindo este link.
Windows Azure foi criado para ser uma plataforma completa, que fosse suficientemente capaz de oferecer grandes vantagens tanto para empresas (permitindo que seus custos de gerenciamento de infraestrutura fossem minimizados em grande escala) quanto para desenvolvedores, que poderiam usufruir de uma plataforma de execução robusta sem se preocuparem com aspectos de administração de infraestrutura. Neste sentido, o time do Windows Azure pensou em uma plataforma modular, composto basicamente de 4 grandes elementos:
- Computação (vimos este conceito no segundo artigo desta série)
- Bancos de dados relacionais (vimos o SQL Azure no quarto artigo desta série)
- Armazenamento (vimos este conceito em detalhes no terceiro artigo da série)
- Recursos adicionais
O quarto e último módulo (que aqui estamos chamando de “recursos adicionais”) será o alvo de nosso estudo neste texto.
Windows Azure App Fabric
O Windows Azure App Fabric (ou simplesmente App Fabric) é o nome dado pelo time de Windows Azure para um set de recursos que completam a plataforma Azure. Este conjunto de recursos é extremamente útil para que desenvolvedores possam endereçar aspectos de design de aplicações e até mesmo demandas operacionais. A Figura 1 apresenta uma visão geral do App Fabric.
Figura 1. Visão geral do Windows Azure App Fabric
Na sequência deste texto, apresentaremos em maiores detalhes cada um dos componentes do Windows Azure App Fabric bem como sua importância junto ao processo de desenvolvimento de aplicações.
Caching (Windows Azure Cache)
Conforme você pôde constatar nos textos anteriores desta série, Windows Azure disponibiliza um modelo de computação stateless. Isto siginifica que, de tempo em tempos, as instânsias de máquinas virtuais são destruídas e recriadas. Este modelo gera aguns efeitos colaterais. Para que esta ideia fique mais clara, imagine o exemplo de uma aplicação web que trabalha com variáveis de seção. Pode ser que, ao gravar a seção na memória de determinada instância, a mesma não se encontre mais disponível em um instante seguinte quando precisar ser consumida pela aplicação. Isso naturalmente ocorre em função do modelo stateless.
A solução proposta pelo Windows Azure para solucionar este e outros tipos de problemas semelhantes, é o Azure Cache.
O Windows Azure Cache é uma solução de caching distribuído. Isto quer dizer que os elementos adicionados ao cache podem estar distribuídos ao longo de múltiplas instâncias dentro do mesmo datacenter (de forma horizontal). Como é natural ao modelo PaaS, todos os aspectos de configuração e implementação da infraestrutura necessária para o funcionamento do recurso, são encapsulados pela plataforma. A Figura 2 apresenta o modelo de cache.
Figura 2. O modelo de computação do Windows Azure App Caching
Azure Cache (como tudo na plataforma Azure) é disponibilizado para desenvolvedores e suas aplicações na forma de serviço via HTTP (REST).
Uma característica importante do Windows Azure Cache reside no fato de que por padrão, não há um tempo definido para que os dados armazenados temporariamente sejam retirados da memória. Entretanto, para que não haja “estouro de memória”, a plataforma implementa um regra chamada “eviction” (em pt-br, “despejo”). O que acontece é que quando a capacidade da memória cache é atingida, para liberar espaço para novos conteúdos, o Windows Azure automaticamente remove os conteúdos mais antigos. Existe entretanto, a possibilidade de se definir um tempo para expiração do conteúdo de forma manual ao realizar o acesso via PUT ou ADD.
A capacidade de armazenamento do das memórias cache varia de 128 MB até 4 GB. Evidentemente que, quanto maior a capacidade contratada, maior o valor da cobrança, que é realizada de forma mensal. Você pode visualizar os preços para contratação do Windows Azure Cache seguindo este link.
Service Bus (Windows Azure Service Bus)
Windows Azure Service Bus (como o própio nome sugere) é um ambiente que disponibiliza infraestrutura necessária (no formato de barramento) para conectar aplicações através de web services. Se você já é acostumado com o conceito de ESB (Enterprise Service Bus), você estará super confortável então com o Windows Azure Service Bus, pois a ideia é exatamente a mesma.
Com o service bus oferecido pelo Windows Azure, você poderá conectar diferentes aplicações utilizando diferentes tipos de modelos de comunicação (SOAP, REST, etc.).
A ideia é que exista uma camada intermediária que sirva de barramento para que as aplicações on-premisses ou na nuvem, possam conectar-se e trocar informações com outras aplicações utilizando os mais diversos protocolos de comunicação, conforme apresentado pela Figura 3.
Figura 3. O modelo proposto pelo Windows Azure Service Bus
O modelo de cobrança do service bus é baseado no número de mensagens trocadas através do barramento ao longo do mês. Você pode visualizar o modelo de cobrança do Windows Azure Service Bus em detalhes seguindo este link.
Access Control Service (ACS)
O Access Control Service ou pela nomenclatura mais atual, Windows Azure Active Directory, é um container que identificação. Com ele, suas aplicações poderão realizar autenticações de forma unificada, seja via Active Directory, Facebook, Twitter, Live ID, Google Account, etc.
A ideia é que a aplicação através de um processo único, consiga realizar a autenticação utilizando os principais modelos disponíveis para este fim (todos encontram-se encapsulados dentro do ACS). Novamente, seguindo o modelo disponibilizado pelo ambiente PaaS, toda complexidade relacionada ao ambiente de autenticação (criptografia, implementação de mecanismos de segurança, etc.) são encapsulados pela plataforma Azure. A Figura 4 apresenta o modelo de autenticação disponibilizado pelo ACS.
Figura 4. O modelo de autenticação proposto pelo ACS
O modelo de cobrança do ACS é conforme a utilização, entretanto, é possível que os valores de cobrança no momento em que este artigo foi escrito seja diferente em relação a data de leitura, portanto, recomendo seguir este link para obter os detalhes do modelo de cobrança.
Composite App
Outro elemento de fundamental importância disponibilizado dentro da plataforma Azure e que também é orquestrado pelo App Fabric é o “App Composite”. O App Composite possui a função de gerenciar os diferentes módulos de uma aplicação estruturada no Windows Azure, facilitando assim o processo de deploy, monitoramento e configuração.
Este recurso a princípio pode soar como irrelevante, entretanto, ao se trabalhar com aplicações em ambiente de maior escala, com muitas integrações e hibridismo, salta a vista sua relevância. A Figura 5 apresenta o modelo disponibilizado pelo composite app.
Figura 5. Windows Azure Composite App
Conclusões
Existe muita confusão em relação ao Windows Azure App Fabric internet a fora. O que deve ficar claro para você neste momento é: o App Fabric é um orquestrador de recursos complementares dentro da plataforma Azure. Internamente ao App Fabric, existem recursos específicos para realizarem tarefas específicas (cache, identificação, barramento de serviços, etc.).
Os recursos orquestrados pelo App Fabric são de fundamental importância no processo de implementação de aplicações mais robustas e corretamente distribuídas, principalmente pensando em ambientes híbridos (on-premisses e cloud).
Por hoje é só. Até o próximo post.
Facebook
Twitter
Instagram
LinkedIn
RSS