Artigo
10/09/2015

Outubro de 2015

Volume 30 - Número 10

Microsoft Azure: Microsoft Azure – visão global

Por Tony Meleg | Outubro de 2015

Todos os meses, essa revista mergulha nos detalhes de algum serviço novo ou interessante no Microsoft Azure. Há um fluxo infinito de coisas que os desenvolvedores aparentemente precisam saber, mas, ao mesmo tempo, uma confusão sobre todas as diferentes maneiras de realizar a mesma coisa. Não é fácil montar esse quebra-cabeça para apreciar uma "visão global". Por outro lado, com a velocidade das inovações que vivenciamos em nosso setor, o grande desafio para empresas e profissionais de TI é não ignorar a visão global. Bem, esse artigo é para ajudar você a compreender o Azure sem focar um serviço específico, o contrário do que fazemos normalmente.

Você há de concordar que desenvolvedores nem sempre conseguem simplificar coisas muito complexas. Ao contrário, normalmente partimos de um problema simples e implementamos uma solução muito complexa. Precisamos compreender como as coisas funcionam, especialmente o que não fomos nós que criamos. Em parte, é uma questão de confiança, mas também é para compreender como alterar e ajustar um componente ou um software inteiro para que atenda às nossas necessidades específicas. Então também uma questão de controle.

A grande aposta da Microsoft

Se as minhas afirmações sobre desenvolvedores estão fazendo sentido para você, não vai gostar nem um pouco do que vou dizer agora. O Acure é uma coleção de blocos para construção de aplicativos, ou "serviços", e cada um fornece uma função diferente que você pode precisar em algum momento em um aplicativo que deseja compilar. A Microsoft acredita que esses blocos devem ser intrinsecamente resistentes, altamente escalonáveis e auto-gerenciáveis. Você pode provisionar qualquer serviço, de qualquer lugar do mundo, pagando apenas pelo que consumir e, mais importante, podendo alterar seu consumo a qualquer momento ou de qualquer lugar. A parte que você não vai gostar é essa: Esses serviços simplesmente funcionam. Eles abstraem você de toda a complexidade; você não possui muito controle sobre eles; não é possível enxergar dentro deles. Em outras palavras, é preciso simplesmente confiar neles. Não parece algo muito atraente, não é, por que você quer ter o controle, não "confia" e adora complexidade?

A grosso modo, é possível segmentar o Azure em três camadas: a estrutura de datacenter, serviços de infraestrutura e serviços de plataforma, como na Figura 1.

Figura 1 Visão conceitual do Microsoft Azure

Pense nessas três camadas empilhadas uma sobre a outra, com cada camada uma abstração da camada abaixo. Assim, Infraestrutura como serviço (IaaS) é uma abstração ampla dos servidores físicos, armazenamento e rede subjacentes. Plataforma como serviço (PaaS) é uma abstração da infraestrutura de software do aplicativo que você normalmente instalaria em servidores e usaria ao criar aplicativos, como infraestrutura de servidores Web, bancos de dados, sistemas de mensagens e identidade. A função do serviço não é fornecer esse software para você, mas prestar um serviço integral em execução, resistente e sempre disponível (e trabalhar nos bastidores para monitorar e corrigir quaisquer problemas com transparência, sem seu aplicativo soluçar).

Estes serviços não estão disponíveis apenas na nuvem pública do Azure, mas em qualquer lugar. Pode ser seu datacenter, um host ou terceirizado. Recentemente, a Microsoft anunciou o Azure Stack para que isso seja possível: imagine empacotar a fórmula secreta e os serviços do Azure para implantar em seu próprio hardware. Afinal, esse software é criado sobre as estruturas fudamentais do Windows Server e Hyper-V. Mas nesse novo mundo você não precisa se preocupar, porque o foco está nos serviços que precisa, como arquitetar a solução adequadamente e como programar com os serviços.

Os blocos de construção da plataforma

Então vamos dar uma olhada geral por todo o Azure. A Figura 2 ilustra todos os serviços em um conjunto de grupos, com funcionalidades divididas entre serviços de infraestrutura e serviços de plataforma. Você deve pensar em serviços de infraestrutura como as funções que permitem que você crie a infraestrutura de baixo nível para seus aplicativos existentes. Você precisa de computadores que tenham discos; precisa que eles estejam em rede; precisa de discos compartilhados; e precisa conectá-los a outros sistemas e redes em outros lugares, e assim por diante.

Figura 2 Serviços do Microsoft Azure

No nível de serviços de infraestrutura, as abstrações são mais familiares porque representam o datacenter físico subjacente, como um computador na forma de uma máquina virtual (VM) e discos virtuais que você anexe à máquina. Isso permite que você execute sistemas que já possui, e faça as coisas na mesma maneira que já faz hoje, porque a única abstração é o computador, e não o software aplicativo que você usaria. Ainda é sua responsabilidade instalar, gerenciar, corrigir, reparar e criar software que seja resistente para executar em um conjunto de VMs conectados à rede, como faz hoje em seu próprio datacenter.

Mas nos serviços de plataforma, ao contrário, as funcionalidades envolvidas distanciam você dos níveis mais baixos de computadores, armazenamento e/ou redes que o serviço utiliza; tudo isso é abstraído de você. Como regra geral, se você não puder tocar ou se conectar à VM subjacente em um determinado serviço, o serviço é PaaS. Você também não pode escolher o software que fornece o serviço, nem ajustar ou controlar o software. O papel do serviço é simplesmente funcionar, corrigindo a si mesmo e monitorando todas as partes do serviço necessárias em todos os datacenters do Azure. Você pode simplesmente se concentrar em utilizá-lo, o que, de qualquer maneira, sempre foi o seu papel.

Um aparte: a infraestrutura de datacenter do Azure

Como temos corações geeks, você deve estar interessado na complexa infraestrutura de computação e datacenter que sustenta o Azure. Talvez você queira compreender as especificações físicas dos servidores, quais comutadores utilizamos, como os racks são construídos. Ou talvez queira conhecer a complexa topologia de rede, que fornece uma velocidade insanamente rápida e consistente para todos os serviços e para a rede global que conecta e une as regiões de datacenter do Azure. Ou ainda pode ser que tenha curiosidade sobre as 24 regiões de datacenter espalhadas pelo mundo onde o Azure já existe (ou existirá em breve, quando as cinco novas regiões no Canadá e na Índia forem ativadas), como mostramos na Figura 3.

Figura 3 Localização global dos datacenters do Microsoft Azure

Esse é o seu primeiro teste como desenvolvedor nesse novo mundo: você precisa parar de se preocupar com isso, pelo menos no Azure. Se quisesse construir seu próprio "Azure" em seu datacenter como o Azure Stack, você (ou alguém em sua organização) ainda teria que se preocupar com essas questões físicas. No passado, era preciso se preocupar muito com tudo isso, e mesmo com a infraestrutura necessária para um aplicativo específico, devido ao altíssimo custo em cometer um erro. Você nunca sabia o número e o tamanho dos servidores necessários; assim, previa o pior cenário possível e adicionava um pouco mais, por segurança. No Azure, esses problemas não existem porque, se você precisar mais de alguma coisa, basta provisionar mais. Se precisar de um computador maior, consegue; se for demais, basta alterar. No Azure você só precisa descobrir onde estão os usuários do seu aplicativo e os melhores datacenters para utilizar na entrega da solução. Geralmente, o mais próximo.

Serviços de infraestrutura: mais controle, mais trabalho

Quando você se depara com os cerca de 60 serviços na Figura 2, é uma lista assombrosa. Mas a maioria dos aplicativos que você já construiu, na maior parte do tempo, contém apenas algumas funcionalidades. Geralmente, já um servidor Web e um banco de dados relacional central, e mais várias peças para identidade, relatórios e alguns processos em lote. Por hora, vamos nos concentrar na infraestrutura Web e no banco de dados.

Imediatamente, há uma escolha a fazer: Você trabalha no nível de infraestrutura ou de plataforma da abstração? Você aciona algumas VMs, instala seu servidor Web e seu banco de dados e segue adiante? Lembre-se, essa abstração envolve principalmente servidores físicos, armazenamento (discos) e redes, mas não o software necessário para execução nesses servidores. Parece fácil e soa familiar, e, veja só, é mesmo. É exatamente o que você já faz e vem fazendo por toda a sua carreira. Observe a Figura 4. Uma VM possui discos virtuais que podem ser compartilhados por VMs ou anexado a um computador específico. As VMs podem ser inseridas em redes virtuais para que possam se comunicar e para que redes possam ser conectadas ao seu próprio datacenter, e por regiões do Azure. Tudo isso é feito através dessa abstração de software, o que significa que você terá um computador com um ou mais discos, parado em uma rede e conectado a outros computadores.

Figura 4 Abstração de máquina virtual de servidores, discos e redes

Tudo o que você precisar dentro do conjunto de VMs, pode controlar e ajustar e abrir e alterar. De fato, é ainda melhor do que em seu universo local, devido à abstração. Você não se terá que preocupar com o computador físico, o sistema operacional do host, o hipervisor. Não terá que se preocupar com a resistência da infraestrutura subjacente de armazenamento para seus discos virtuais. Há um conjunto impressionante de opções para tamanhos de VMs (combinações diferentes entre CPU e RAM, com diferentes tamanhos de discos, velocidades e larguras de banda de redes).

Melhor ainda, tudo funciona em autoatendimento, e tudo pode ser automatizado, sendo incrivelmente fácil definir a infraestrutura que você precisa e acionar centenas de instâncias com um único script.

Digamos que seu aplicativo necessite de um nível considerável de escala e resistência. É fácil criar um Web farm de VMs e servidores Web, criando um cluster de banco de dados. Você sabe (ou seu melhor amigo profissional de TI sabe) como fazer tudo isso; não é fácil, mas é possível. E você pode fazer isso a qualquer momento, dia ou noite; pode provisionar em qualquer lugar do mundo; pagar apenas o que usar e, no momento em que mudar de ideia, destruir tudo sem pagar absolutamente nada. Não é muito sensacional? Mas... parece bom demais para ser verdade, onde está a pegadinha?

A pegadinha, no nível da infraestrutura, é que você ainda terá que realizar muito trabalho para implantar e executar tudo. E depois que tudo estiver em execução, ainda mais trabalho de manutenção. Mas há ajuda, especialmente para a parte "colocar em execução", longe do universo local em que há muito mais problemas para implantar um conjunto complexo de VMs inter-relacionados, incluindo funções no Azure como Gerenciador de Recursos do Azure e automação pelo Windows PowerShell, assim como muitas outras soluções de terceiros. Quando tudo estiver em execução, você ainda precisará corrigir os softwares que estiver usando dentro das VMs, incluindo o sistema operacional, independentemente de qual seja. E terá que gerenciar a integridade de todos os softwares do aplicativo, o que não é muito difícil para o servidor Web e o banco de dados, mas muito mais difícil em escala ou adicionando cinco outras funcionalidades.

É uma troca de controle por trabalho ou esforço. Se deseja controle, terá que despender um esforço maior para construir o que precisa e manter tudo em funcionamento.

Serviços de plataforma: menos controle, menos trabalho

Você deve lembrar do ditado "Todos os problemas da ciência da computação podem ser resolvidos por outro nível de indireção (abstração)". Bem, há uma outra frase que geralmente vem depois, mais ou menos "... mas isso geralmente cria outro problema".

É verdade, e os serviços de plataforma são um excelente exemplo. A imagem dos Serviços do Azure na Figura 2 demonstra as duas abstrações de serviço para os dois blocos de construção necessários no exemplo (um servidor Web e um banco de dados). No Azure, essas abstrações são Aplicativos Web (na seção Web e Mobile) e Banco de Dados SQL (na seção Dados). O provisionamento desses serviços no Azure ocorre da mesma maneira que qualquer serviço, indo ao Portal de Gerenciamento do Azure, selecionando o serviço que deseja e inserindo os detalhes necessários: nome do serviço, localização do datacenter, nível inicial de desempenho/preços, e assim por diante.

É aqui que entra aquele "menos controle, menos trabalho". Peguemos o banco de dados como exemplo. Eu provisiono um banco de dados no datacenter do norte da Europa. Em menos de um minuto, tenho um banco de dados totalmente operacional, e meu trabalho é implantar meu esquema e meus dados no banco de dados, conectando meu aplicativo Web. Nenhum software precisa ser instalado: eu tenho o que está disponível, um banco de dados SQL. Na verdade, não tenho apenas um banco de dados, mas três, todos em operação conjunta em um cluster de alta disponibilidade, com níveis incríveis de resistência. Posso aumentar ou diminuir o desempenho dos três banco de dados simplesmente selecionando um outro nível de desempenho (o que alterará o preço). Não é possível optar por não ter esse banco de dados clusterizado de três vias; receberá assim porque o serviço precisa se certificar de entregar um banco de dados em operação, e essa é a melhor maneira para isso.

Como pode ver na Figura 5, há um modelo parecido quando você provisiona a infraestrutura Web para seu aplicativo usando Aplicativos Web do Azure. Você pode selecionar o número de instâncias que deseja usando um controle deslizante simples. Você aumenta ou diminui a contagem de instâncias, e o serviço realiza o restante. Você pode até mesmo programar o sistema para fazer isso por você, com base em carga ou agendamento. E o mais importante, é o papel do serviço fornecer a contagem de instâncias que você especificou, e monitorar e corrigir instâncias interrompidas. Seu papel é simplesmente escrever os trechos de código do seu aplicativo Web e entregar para o serviço, para que ele verifique se todos estão onde precisam, em todas as suas instâncias.

Figura 5 Alterar a contagem de instâncias do aplicativo Web

Assim, a abstração para serviços de plataforma geralmente fornece um serviço que lida com o provisionamento, a resistência e o gerenciamento do serviço para você. O "problema adicional" criado com a abstração é você perder um pouco do controle. Você não pode escolher o software, nem "entrar na caixa" e ajustar ou alterar o software usado pelo sistema operacional até o alto da pilha; pra você, é como uma caixa preta. O outro controle que você perde é ficar preso às funcionalidades daquele serviço, e também à API do mesmo; ou seja, como seu código de aplicativo interage com o serviço. Por exemplo, talvez você precise de algo específico no banco de dados, mas o serviço não fornece. Isso pode ser um tipo de dados específico, ou uma funcionalidade inteira, como pesquisa de texto inteiro. Ou talvez você esteja movendo um aplicativo existente para a nuvem e as funcionalidades usadas em seu aplicativo não coincidem com as do serviço no Azure. O que fazer?

A imagem dos blocos de construção do Azure na Figura 2 classificaram todos os serviços em IaaS ou PaaS, mas não pense que não é possível cruzar essa fronteira e usá-los "juntos", porque é sim. Não há motivos, por exemplo, para você deixar de usar o serviço de Aplicativo Web PaaS com, digamos, uma VM em que você tenha instalado Oracle em execução em Linux, ou SQL Server em execução no Windows. Agora, você tem um equilíbrio entre controle e esforço. De fato, você pode avançar ainda mais com isso. Como esses blocos de construção estão lá esperando para serem usados, você pode, é claro, usá-los de qualquer lugar. Tudo o que você precisa é de uma API simples ou de algum protocolo que você já use para conversar com esses serviços. Você pode usar qualquer um desses blocos com os seus sistemas existentes em seu próprio datacenter. E pode ainda usar esses blocos com outros blocos de terceiros, e até mesmo de outros provedores de nuvem. Tudo isso, é claro, desde que o aplicativo possa tolerar os desafios de latência que podem ser introduzidos, mas é possível.

Os ouros serviços

Mas então por que você precisa de todas essas funcionalidades no Azure? Bem, se você olhar em volta em seu próprio departamento de TI, em todos os aplicativos em execução em produção hoje encontrará uma grande coleção de softwares de aplicativos alimentando esses aplicativos: sistemas de mensagens, funções de análise de dados, infraestrutura de identidade, camadas de segurança, sistemas de backup, armazenamento de dados e sistemas de gerenciamento, e assim por diante. Coletivamente, em todo o seu portfólio de TI, todas essas "coisas" são necessárias. Eu gosto de imaginar o Azure como uma coleção de "Legos de TI". Você não precisa de todos os tipos de tijolinhos o tempo inteiro enquanto você monta sua próxima grande obra, mas precisa de todos em sua caixa de ferramentas.

Como decidir quais blocos usar ao construir uma nova solução? Não é muito diferente do que sempre foi, você precisa compreender o que os blocos de construção fazem e usá-los de acordo com as necessidades específicas de seu aplicativo, fazendo escolhas. Há uma percepção de que a compilação de aplicativos na nuvem é diferente, e mais complexo. Não é nem um nem outro, mas há algumas coisas adicionais que você precisa fazer devido ao conceito fundamental de trabalhar em uma infraestrutura "compartilhada". Isso quer dizer que muitos serviços possuem restrições, e essas restrições variam de acordo com os muitos níveis funcionais e tipos de preços que você usa; é preciso saber o que são. Lembre-se, o ideal é que eles não sejam constantes, e sim variar conforme sua necessidade, com base na carga do aplicativo e na demanda. É preciso programar defensivamente devido a essas restrições, assim como disponibilidade do serviço e responsividade. Você pode usar as mesmas ferramentas, linguagens e estruturas para compilar soluções, e todos os serviços no nível mais baixo possuem APIs com base em REST e wrappers específicos da estrutura para usar. Por isso, você pode literalmente chegar nos blocos de construção a partir de qualquer coisa que possua uma simples pilha Web, como um sensor, motivo pelo qual a nuvem está impulsionando a explosão de soluções da Internet das Coisas.

O lado bom da nuvem é poder iterar rapidamente (devido à facilidade de acionar os serviços); poder experimentar alternativas; e poder falhar rapidamente e sem gastar muito, devido aos investimentos baixos. Veja a Figura 2 novamente. Será que falta alguma coisa? Pode ser que enxergue coisas que nunca precisará nessa imagem, mas aposto que terá dificuldades em pensar em alguma funcionalidade que você precisa, ou que já possua, e que não esteja representada nela. E há muitos guias por aí para te ajudar, dos mais abrangentes aos mais detalhados para implementação, serviço a serviço.

Aprender coisas novas está no DNA da maior parte dos desenvolvedores. Muito provavelmente você adora explorar tecnologias e experimentar novidades. Mesmo que a sua empresa nunca, jamais crie algo para uma nuvem pública, ela ainda é o melhor campo para desenvolvedores, e para que você aprenda e cresça.

Lidando com alterações

Antes de terminar, quero tocar em um último assunto, e é sobre as mudanças. Eu mesmo assumo, é muito difícil me manter atualizado com todas as inovações entregues no Azure nessa velocidade maluca, e olhe que essa é, tipo, a minha função. Antigamente, havia mapas de implantação de recursos e funcionalidades com três a cinco anos para a entrega, mas esses dias já se foram. Hoje em dia, você terá sorte se tiver seis meses. Durante o desenvolvimento de algo, você descobre novas funcionalidades, e até mesmo serviços inteiros novos, e é tentado a avaliar e refatorá-los em sua solução. Funcionalidades e serviços também podem ser removidos dentro do período de notificação de um ano, sem aquele ciclo de suporte de 10 anos tradicionalmente posicionado para softwares de servidores.

Agora também ocorre controle de versões, com novas funcionalidades sendo adicionadas a um serviço que podem interromper a implementação daquele serviço e os aplicativos compilados com ele. Assim, uma decisão precisa ser tomada sobre a versão, e a criação de uma implementação lado a lado. Isso foi feito recentemente no Azure com o Banco de Dados SQL do Azure. Veja o artigo sobre as novidades da versão 12 do Banco de Dados SQL do Azure em bit.ly/1Dcjpo4.

O ponto é que há um imposto a se pagar pela nuvem, e você precisa saber disso e fatorar o custo desse imposto. É preciso estar conectado aos processos de notificação de suporte e alterações da nuvem para poder planejar com antecedência e não ser pego de surpresa. Esse imposto, é claro, é a mudança, e o custo é mais alto e mais frequente do que no local. Mas não deixe isso desanimar, o lado bom compensa muito mais. A velocidade para a realização de coisas é muito maior, a qualidade é maior, e os riscos que você corre, muito menores.

Quer saber mais? No evento virtual AzureCon você pode receber informações diretamente de especialistas em Azure, assistir sessões de perguntas e respostas e descobrir mais sobre as inovações mais recentes para o Azure. Você pode assinar para acessar todo o conteúdo arquivado da conferência em bit.ly/1KRD76d.

Tony Melegé gerente técnico de produtos na equipe do Microsoft Azure. Seu tempo é dedicado a criar conteúdo técnico para vários públicos, realizar evangelização do Azure e transformar complexidade em conceitos simples.