Mesmo um projeto simples como foi mostrado no post anterior pode requerer a criação de várias instâncias se for muito acessado, de modo que a aplicação continue atendendo à todas as requisições. Para entender como essas instâncias são criadas, primeiro é preciso entender do que o Azure é composto e como a sua infra funciona.

Load Balancer

Olhando a figura acima, repare que a área de web roles (onde fica a aplicação web) não recebe as requisições diretamente, todos os acessos devem passar pelo Load Balancer. Ele fornece 4 serviços importantes:

• Canal de entrada único: Reduz as possibilidades de ataques, aumentando a segurança;
• Distribuição de carga: Distribui de forma adequada as requisições recebidas, visando não sobrecarregar nenhuma instância;
• Tolerância à falhas: Direciona o tráfego para outras instâncias se houver algum problema;
• Manutenção: Direciona o tráfego para outras instâncias enquanto alguma instância estiver sendo atualizada.

Resumindo, o Load Balancer é quem recebe as requisições e as distribui entre as múltiplas instâncias de web roles e work roles (que em resumo, são como serviços do WIndows rodando na nuvem).

Falando sobre as múltiplas instâncias, o Azure precisa de algo que gerencie o que está rodando e obtenha novos recursos quando necessário. Em um sistema operacional padrão quem faz esse trabalho é o Kernel. No Azure, o Kernel é o Fabric Controller.

Fabric Controller

O Azure contém uma enorme quantidade de servidores, de forma que seria muito difícil gerenciá-los de forma individual, então abstrair a forma de lidar com eles para uma nuvem cabe muito bem para resolver esse problema, pois isso permite gerenciá-la como um todo. Esse monte de servidores é chamado de fabric e é aí que a nossa aplicação roda quando fazemos deploy no cloud.

Fabric é o paradigma de cloud computing que o Azure segue, o qual é basicamente uma forma de descrever o data center como uma série de elementos conectados logicamente, formando um sistema de alto desempenho. Cada parte do hardware, do server ao cabo para conexão, cada VM, todos em conjunto formam a fabric.

O software responsável por gerenciar a fabric é chamado de Fabric Controller. É trabalho dele instalar nossa aplicação nas máquinas da nuvem, além de monitorar sua saúde e tomar as ações necessárias para mantê-la saudável. Porém, há coisas que o Fabric Controller não faz, como I/O por exemplo. No Azure, esse trabalho é feito pelo Storage Service.

Salvando dados na Nuvem com Azure

Aplicativos tem que guardar dados em algum lugar. No Azure não podemos contar com a forma usual de guardar informações, já que nossa app pode estar rodando em N máquinas diferentes e pode ser movida de uma máquina para outra a qualquer momento.

Tal qual as aplicações, os dados não podem ficar reféns do servidor físico. O Azure fornece um serviço de storage escalável que pode ser acessado de dentro e de fora do data center (o que quer dizer que você pode armazenar dados nele e acessaá-los com uma app que não roda no Azure). O serviço é escalável porque não é preciso se preocupar com o espaço disponível, ele “nunca acaba” (deixe que a Microsoft se preocupe com isso). O serviço de storage é acessado através de uma API REST, usando tokens de autenticação para garantir a segurança.

Esse serviço permite salvar informações de três formas:

Blob

É possível armazenar arquivos binários (binary files ou Blobs) no Azure, em uma área chamada Blob Storage. É semelhante a um sistema de arquivos e pastas comum.

Mensageria

É um serviço de mensageria padrão. Uma web role ou algum serviço externo coloca uma mensagem na fila para processamento e instâncias de worker role desocupadas tiram as mensagens da fila e as processam. Apesar de não ter necessariamente relação com armazenamento de dados, esse serviço faz parte do Azure Storage porque as mensagens precisam ser armazenadas enquanto esperam para ser processadas.

Tabelas

O serviço de Table Storage permite guardar entidades serializadas em uma “grande tabela”, assim elas podem ser particionadas entre múltiplos servers. Esse serviço não é uma base relacional, caso seja necessário usar uma, você vai precisar de um serviço um pouco diferente, o Azure SQL Database, o qual não faz parte do Storage.

Azure SQL Database

O SQL Database fornece as principais funcionalidades do SQL Server na nuvem. A comunicação é feita via TDS (Tabular Data Stream), o mesmo protocolo do SQL Server “tradicional”, então você pode se conectar em uma base na nuvem como se ela fosse local. Se a sua aplicação não utiliza recursos avançados do SQL Server, você pode colocá-la na nuvem com poucas, ou talvez nenhuma alteração.

O que foi descrito sobre os serviços do Azure até agora são apenas uma introdução, haverá posts específicos sobre cada um deles nessa série. No próximo post vou falar sobre como o ambiente de desenvolvimento do Azure funciona no seu computador, como a sua aplicação roda localmente e as diferenças para rodá-la na nuvem.

Juliano Alves

Juliano Alves é formado em Ciência da Computação e Especializado em Engenharia de Software pela PUC-SP e considera desenvolvimento de software uma arte. Trabalha com desenvolvimento a 6 anos, focado em métodos ágeis, possuindo experiência com Java, Scala, Ruby e Python, falando sobre elas no twitter @vonjuliano de vez em quando. Contribuinte do framework opensource Mirror, criado para simplificar o uso de reflection e commiter do VidaGeek Games, uma plataforma que mistura prática deliberada e Gamefication para ensino. Hoje trabalha na Lambda3, empresa envolvida no meio ágil desde que foi criada.