Quando usar o Azure?

Existem dois tipos de respostas aqui: uma que visa o diferencial do aplicativo do ponto de vista Controle X Custo, já abordado em https://msdn.microsoft.com/pt-br/azure/dd638038.aspx; outra que visa a adequação tecnológica no uso do Azure . Hoje vou tratar da segunda.

Em minha opinião, nem todo tipo de arquitetura de aplicativo é susceptível de ir para o Azure, seja por impossibilidade técnica atual, seja por custo.

Para ficar mais claro qual tipo de arquitetura eu creio ser viável no Azure, criei o seguinte quadro:

Para tornar mais claro, vamos tratar de cada caso:

1) Web 2.0 (Privado/Público): imagine cenários que precisam compartilhar um volume muito grande de dados não transacionais, podendo ter que escalar eventualmente para milhares ou mesmo milhões de usuários. Pense em Facebook, Youtube, sites de blogs, sites de notícias, etc. Neste caso você vai poder usar o Azure em todo seu potencial, utilizando a elasticidade de processamento e storage (Azure Tables), armazenando tudo num volume virtualmente infinito de recursos. Estes é um dos cenários mais favoráveis para o Azure!

2) SaaS (Privado/Público): imagine fazer um aplicativo para ser vendido para milhares ou mesmo milhões de clientes, cada um utilizando seus dados de forma exclusiva, tendo um máximo de 10G de banco SQL (limitação atual do SQL Azure), mas podendo guardar em Blobs e Tables do Azure um volume virtualmente infinito de documentos, fotos, vídeos, etc – o que diminui consideravelmente a limitação de volume máximo do banco. Imagine poder crescer/decrescer o número de clientes de acordo com a sazonalidade sem custo de compras ou ociosidade de recursos. Este é também um cenário para o Azure.

3) High Performance Computing: imagine um aplicativo que precise de um alto grau de processamento paralelo, para criar animações de filmes, analisar proteínas, construir plataformas de petróleo, etc, utilisando algoritmos como MapReduce. Se não houver impeditivo na carga/descarga de dados a serem trabalhados (devido à latência ou volume), o Azure pode ser utilizado para a infraestrutura deste aplicativo, com a vantagem de você só alocar os servidores quando realmente necessitar rodar o processamento. Por que só bom? Ainda não existe framework MapReduce pronto, você terá que fazer o seu. Outra questão é o eventual volume de dados para ser carregado para uma análise.

4) Small/Medium Transaction Processing: se você tem um aplicativo para empresas pequenas e/ou médias, ou mesmo aplicativos departamentais, provavelmente você poderá usar o SQL Azure de 1G ou 10G, migrando o seu aplicativo para o Azure. Lembre-se que fotos, documentos e outros podem migrar do Banco para Tables e Blobs, pois isto diminui o risco do limite do SQL ser atingido. Por que só bom? O limite atual de 10 Gb pode ser um impeditivo.

5) Remote SQL: você pode utilizar o SQL remotamente, ganhando latência (o que é ruim), mas conseguindo tanto um custo pequeno quanto a possibilidade de compartilhar os dados com outras empresas, sites, etc. Porque não deixar a lista de produtos e preços da sua empresa disponível para terceiros? (leitura somente, é claro!). Por que só bom? A latência da Internet pode ser um impeditivo.

6) Internet Service Bus: se você precisa da comunicação com aplicativos externos à sua rede, eventualmente de terceiros, o Internet Service Bus é uma infraestrutura interessante. Ele permite a troca de mensagens com autenticação federada, diminuindo o custo de infraestrutura e gerenciamento de um EDI. Por que só bom? Latência, de novo.

7) Mistos: imagine uma loja online, onde pedidos são feitos pelo site no Azure (com lista de produtos no SQL Azure e fotos dos produtos nos blobs) e em que toda a infraestrutura de pagamento e entrega está na sua empresa, ou na empresa de terceiros. Neste caso, você poderá complementar sua loja online, que habita no Azure, com os demais sistemas de logística, meios de pagamentos, etc, utilizando o Internet Service Bus como mecanismo de troca de mensagens confiável. Este e muitos outros cenários podem utilizar o melhor de cada tipo de ambiente (nuvem, dispositivos, sistemas internos ou de terceiros), realizando uma verdadeira arquitetura Software+Serviços. Por que só bom? Latência e limite de SQL Azure…

Por fim, dois cenários, ao meu ver, não parecem ser convenientes para o Azure atualmente:

1) eXtreme Transaction Processing: que necessitam de Base de Dados muito grandes e que não pode ser resolvido com particionamento (vide post).

2) Sites HTMLs puros: neste caso, você até pode colocar o site no Azure, mas como você não estará compartilhando o IIS com outros usuários, o custo, potencialmente, será desvantajoso com o que praticado por hosters do mercado.

Esta é a minha análise dentro da situação atual. Você concorda?

Abraços