Microsoft Azure

Plataforma Windows Azure

O Microsoft Azure é uma plataforma de computação em nuvem de classificação empresarial aberta e flexível.

Utilizar esta plataforma de maneira adequada pode trazer uma série de vantagens competitivas para as empresas, dentre elas uma maior agilidade de implantação e uma redução drástica nos custos de hospedagem.

Por este motivo, a MSTech está empregando esforços para adaptar nossas aplicações para esta plataforma. Mas, antes de começarmos a ver quais são estes esforços e o que isto poderá modificar em nossos processos de desenvolvimento, vamos entender melhor a plataforma.

Modelos de Computação em Nuvem

Modelos de Computação em Nuvem

A computação em nuvem está capacitando desenvolvedores e departamentos de TI para que eles possam se dedicar ao que realmente é importante, evitando trabalhos semelhantes como aquisição, manutenção e planejamento de capacidade. Com o crescimento da popularidade da computação em nuvem, vários modelos e estratégias de implantação diferentes surgiram para atender a essas necessidades específicas de usuários distintos. Cada tipo de serviço em nuvem e método de implantação disponibiliza diferentes níveis de controle, flexibilidade e gerenciamento. A compreensão das diferenças entre infraestrutura como um serviço, plataforma como um serviço e software como um serviço, assim como as estratégias de implantação que você pode utilizar, pode ajudá-lo a decidir qual conjunto de serviços é o ideal para as suas necessidades. A seguir, uma breve explanação sobre os modelos citados:

Infrastructure as a Service (IaaS - Infraestrutura como um serviço)

Neste modelo você contrata capacidade de Hardware, que é disponibilizada através de virtualização. Você possui controle total sobre as VMs (máquinas virtuais), sistema operacional, armazenamento, aplicativos instalados, etc. Todo o custo de gerenciamento e o aumento ou diminuição da capacidade estão sob sua responsabilidade. Este modelo é o mais parecido com a infraestrutura "on premise" (dentro das dependências da própria empresa), uma vez que o gerenciamento da infra de TI é de sua responsabilidade. A diferença fica por conta da responsabilidade e gerenciamento da infraestrutura predial (fornecimento de energia, instalações, controle de temperatura, segurança, etc), já que na IaaS este encargo é do fornecedor.

Apesar do Azure oferecer algum nível de automação para ajustar a capacidade à demanda (como ligar e desligar automaticamente VMs de acordo com o nível de processamento), este ajuste não funciona para situações que exigem rápida resposta, além de depender de uma série de configurações manuais. Isto permite que ocorram constantemente 2 situações indesejadas: gargalos de desempenho (quando a capacidade é menor que a demanda), ou, de forma oposta, ociosidade, gerando custos desnecessários.

Por exemplo, digamos que um aplicativo precisa suportar o acesso de 1000 usuários simultâneos. Para evitar gargalos, temos que provisionar recursos (quantidade de servidores, processamento, memória, armazenamento, etc) para suportar essa quantidade. No entanto, na maior parte do tempo, apenas 100 usuários simultâneos acessam o aplicativo, gerando um enorme desperdício de recursos. Também pode acontecer de, inesperadamente, 2000 usuários simultâneos acessarem o aplicativo. Como sua infraestrutura está preparada para 1000 usuários, o resultado será queda de desempenho e consequente descontentamento dos usuários.

Este modelo serve apenas para hospedagem de aplicações que não são compatíveis com os modelos mais modernos, descritos a seguir.

Platform as a Service (PaaS - Plataforma como um serviço)

Modelo que oferece uma plataforma completa para o desenvolvimento de aplicativos na nuvem, no qual toda a infraestrutura, armazenamento e comunicação para os aplicativos são de responsabilidade do fornecedor. O desenvolvedor pode se preocupar exclusivamente com o desenvolvimento do aplicativo enquanto o seu fornecedor trata do gerenciamento, atualização e a manutenção da infraestrutura disponibilizada para o aplicativo.

Diferentemente do modelo IaaS, o modelo PaaS não enfrenta problemas de gargalo ou de ociosidade, uma vez que disponibiliza mais ou menos recursos de acordo com o que o aplicativo necessita. Desta forma, os custos e os riscos de gargalos são reduzidos drasticamente.

Apesar das vantagens, este modelo exige um cuidado maior na construção dos aplicativos. Uma vez que os custos estão diretamente relacionados aos recursos utilizados, o desenvolvedor precisa se preocupar em otimizar suas aplicações para utilizar o menor número de recursos possível. Bugs que façam o aplicativo consumir recursos de forma exagerada, podem fazer este modelo custar mais caro do que o modelo IaaS.

Além disso, este modelo traz uma série de diretrizes que precisam ser seguidas desde o início do projeto para que o aplicativo seja compatível.

Software as a Service (SaaS - Software como um serviço)

O modelo SaaS é o modelo de cloud computing mais difundido hoje em dia, você pode não saber mas quando acessa um sistema de e-mail como Gmail, Hotmail, Office 365, ou entra em uma rede social como Facebook ou Twitter, você esta na verdade acessando um serviço disponibilizado como SaaS.

A diferença entre SaaS e PaaS é pequena, no PaaS é fornecido uma plataforma para você desenvolver suas próprias aplicações e disponibiliza-las na nuvem, enquanto o SaaS trata do fornecimento de aplicações na nuvem. Em outras palavras, a MSTech pode contratar o modelo PaaS para desenvolver e hospedar suas aplicações e pode oferecer estas mesmas aplicações no modelo SaaS para seus clientes.

Opções de Hospedagem disponíveis no Azure

Comparativo dos principais Serviços do Azure

O Azure oferece os modelos de computação que acabamos de ver na forma de serviços. Os cinco componentes para fornecer aplicativos à partir do Azure são:

• App Service and App Service Environment;
• Azure Cloud Services;
• Azure Virtual Machines;
• Azure Service Fabric; e
• Azure Container Service.

Na imagem ao lado (Principais Serviços) é possível visualizar, de forma sucinta, os principais pontos de cada um dos principais serviços. A seguir, uma breve descrição de todos os modelos disponíveis:

App Service and App Service Environment

Você pode usar o App Service para provisionar e criar aplicativos web rapidamente no Azure. O App Service é uma solução PaaS, portanto, as soluções do App Service são executadas em um ambiente de máquina virtual. Portanto, a infraestrutura e os detalhes do sistema operacional e de gerenciamento são virtualizados e transparentes para o aplicativo hospedado pelo Azure.

Você pode criar soluções para o App Service usando as seguintes linguagens:

• Microsoft ASP.NET;
• PHP;
• Node.js; e
• Python.

Os aplicativos da que usam o App Service também podem se integrar a outros serviços do Azure, incluindo banco de dados SQL, Service Bus ou armazenamento BLOB. Ao usar várias cópias de um aplicativo em máquinas virtuais separadas, você pode rapidamente provisionar e dimensionar aplicativos que usam o App Service.

Você também pode usar o Azure App Service Environment para criar um ambiente dedicado no qual você pode executar aplicativos Azure, como Web apps, Mobile apps e Logic apps. Estes aplicativos podem conectar-se através de uma rede virtual definida pelo escopo de rede do App Service.

Azure Cloud Services

Com o Azure Cloud Services, você pode estender a funcionalidade de sua solução baseada em nuvem, pois suporta escalabilidade para aplicativos e maior controle sobre o ambiente de hospedagem, sendo mais adequado para:

• Aplicações Web de várias camadas;
• Aplicações Web que exigem um ambiente altamente escalável e de alto desempenho; e
• Aplicações Web que possuem requisitos adicionais relativamente simples, como aplicativos secundários ou alterações menores de ambiente.

Azure Virtual Machines

O Azure Virtual Machines, e fornece a maior flexibilidade e controle das opções de computação disponíveis, tal como uma solução IaaS. Desta forma, você tem controle completo sobre a máquina virtual no nível do sistema operacional, o que implica também em manter a máquina virtual no nível do sistema operacional, incluindo a manutenção da continuidade do negócio e a instalação de atualizações. Esta modalidade é mais adequada para:

• Aplicativos altamente personalizados que exigem componentes de infra-estrutura complexos; e
• Hospedar servidores de aplicativos e infraestrutura do Windows Server ou Linux, como controladores de domínio, servidores DNS ou servidores de banco de dados.

Azure Service Fabric

O Service Fabric fornece uma tecnologia confiável e flexível que pode-se usar para criar ambos os tipos de aplicativos: stateful e stateless. Os aplicativos de Service Fabric são compostos de microservices executados em um pool compartilhado de computadores, denominado Cluster Service Fabric, sendo usado principalmente para criar aplicativos em nuvem complexos.

Azure Container Service

Com o Azure Container Serviceé possível criar clusters para suportar aplicativos, permitindo que as empresas criem aplicativos em cluster escaláveis rapidamente, como aplicativos baseados em Docker.

Em qual modelo a Mstech se encaixa atualmente?

Atualmente as aplicações desenvolvidas pela MSTech se enquadram no modelo Azure Virtual Machines. Como já vimos, este modelo não traz nenhuma vantagem para a empresa. Por isso, nossos esforços para tornar nossas aplicações compatíveis com o Azure App Services.

Migrando Aplicações para o Azure App Services

Devido a grande mudança de paradigma entre o desenvolvimento voltado à infraestrutura e o desenvolvimento voltado a nuvem, reunimos aqui uma coleção de informações que podem ajudar no desenvolvimento do dia a dia. Uma das maneiras mais simples para você fazer isso agora (e de graça) é se inscrever em uma conta de avaliação do Windows Azure, nos seguintes endereços:

• Crie sua conta gratuita no Azure .
• Aprenda a implantar um aplicativo ASP.NET no Azure App Service, usando o Visual Studio .

A seguir listamos as principais restrições que o serviço em nuvem do Azure apresenta com relação ao serviço on-primese (baseado em infraestrutura):

Microsoft SQL Server

Quando optamos por utilizar o banco de dados SQL como serviço disponibilizado pelo Azure nos deparamos com os seguintes recursos para os quais não há suporte (atenção aos itens em vermelho):

• Agrupamento de objetos do sistema;
• Administrador de recursos;
• Auditoria do SQL Server (em vez disso, use a auditoria do Banco de Dados SQL);
• Coletor de dados;
• Conexão relacionado: instruções de ponto de extremidade, ORIGINAL_DB_NAME. O Banco de dados SQL não dá suporte à autenticação do Windows, mas dá suporte à autenticação do Azure Active Directory semelhante. Alguns tipos de autenticação exigem a versão mais recente do SSMS (SQL Server Managment Studio);
• Configurações do servidor relacionadas ao hardware: memória, threads de trabalho, afinidade da CPU, sinalizadores de rastreamento etc. Em vez disso, use níveis de serviço;
• Consultas cruzadas de banco de dados usando nomes de três ou quatro partes;
• Credenciais do servidor. Em vez disso, use credenciais no escopo do banco de dados;
• Criptografia: gerenciamento extensível de chaves;
• DATABASEPROPERTY (em vez disso, use DATABASEPROPERTYEX);
• Depuração de Transact-SQL;
• Diagramas de banco de dados;
• Disparadores: no escopo do servidor ou gatilhos de logon;
• Encadeamento de propriedades de bancos de dados, configuração TRUSTWORTHY;
• Eventos: eventos, notificações de eventos, notificações de consulta;
• FILESTREAM;
• Funções: fn_get_sql, fn_virtualfilestats e fn_virtualservernodes;
• HAS_DBACCESS;
• Integração do CLR com o SQL Server do .NET framework;
• Itens no nível de servidor: funções de servidor, IS_SRVROLEMEMBER, sys.login_token. Permissões de nível de servidor não estão disponíveis, embora algumas delas sejam substituídas por permissões de nível de banco de dados. Algumas DMVs (exibições de gerenciamento dinâmico) de nível de servidor não estão disponíveis, embora algumas delas sejam substituídas por DMVs de nível de banco de dados;
• KILL STATS JOB;
• Logons de EXECUTE AS;
• Pesquisa semântica;
• Rastreamento do SQL Server;
• Recursos que dependem do leitor de log em execução no Banco de Dados SQL: replicação push, Change Data Capture;
• Recursos que dependem do SQL Server Agent ou do banco de dados MSDB: trabalhos, alertas, operadores, gerenciamento baseado em políticas, database mail, servidores de gerenciamento central;
• Recursos relacionados à alta disponibilidade, que é gerenciada por meio de sua conta do Microsoft Azure: backup, restauração, AlwaysOn, espelhamento de banco de dados, envio de logs e modos de recuperação;
• Recursos relacionados à localização de arquivos de banco de dados, o tamanho e os arquivos de banco de dados que são gerenciados automaticamente pelo Microsoft Azure;
• Serverless express: localdb, instâncias de usuário;
• Service broker;
• Servidores mestre/de destino;
• Servidores vinculados, OPENQUERY, OPENROWSET, OPENDATASOURCE, BULK INSERT e nomes de quatro partes;
• SET REMOTE_PROC_TRANSACTIONS;
• SHUTDOWN;
• Sinalizadores de rastreamento. Alguns itens do sinalizador de rastreamento foram movidos para os modos de compatibilidade;
• sp_addmessage;
• sp_helpuser;
• sp_migrate_user_to_contained;
• SQL Server Profiler; e
• Tabelas temporárias globais.

Os serviços destacados em vermelho são utilizados atualmente pelas aplicações desenvolvidas pela MSTech:

• Consultas cruzadas de banco de dados usando nomes de três ou quatro partes:
  • Neste item estão os sinônimos e JOIN's entre bancos de dados. Este é um dos recursos mais utilizados pelas aplicações da MSTech.
• Diagramas de banco de dados:
  • Utilizados por algumas equipes para a modelagem do Banco de Dados.
• Integração do CLR com o SQL Server do .NET framework:
  • Na maior parte é utilizada para operações de strings, já foi realizada análise sobre este item e é possível mudar o código para remover esta integração.
• Logons de EXECUTE AS:
  • Em alguns clientes da MSTech foi utilizada esta clausula devido as restrições de permissões impostas. Em sua grande maioria está relacionada com o start de Jobs
• Recursos que dependem do SQL Server Agent ou do banco de dados MSDB: trabalhos, alertas, operadores, gerenciamento baseado em políticas, database mail, servidores de gerenciamento central:
  • As aplicações utilizam-se de jobs para processos de longa duração.
• Servidores vinculados, OPENQUERY, OPENROWSET, OPENDATASOURCE, BULK INSERT e nomes de quatro partes:
  • Também conhecido como Linked Server.
• Tabelas temporárias globais:
  • Sabemos que algumas aplicações usam este tipo de recurso.

Vale ressaltar que, além dos recursos apresentados acima, o SQL Azure não possui o serviço de Reporting Services, amplamente utilizado pelas aplicações desenvolvidas pela MSTech. Durante um tempo houve o serviço Windows Azure SQL Reporting, contudo, o mesmo foi descontinuado . A solução apresentada pela Microsoft para o Reporting Services após a remoção do serviço Windows Azure SQL Reporting foi a criação de uma máquina virtual com o serviço de Reporting Services nativo instalado. Contudo, a ideia de se utilizar uma máquina virtual para executar o Reporting Services não atende ao modelo de nuvem proposto pela MSTech para a migração de suas aplicações. A solução mais plausível seria construir no FrontEnd uma página em C# que renderize o relatório com um framework mais leve, como Angular por exemplo. A questão de exportações, seria necessário a utilização de bibliotecas de terceiros, como o EvoPDF (no caso de exportação para PDF).

Microsoft IIS (Internet Information Services)

A Microsoft disponibiliza um Assistente de Migração de Aplicativos WEB que irá analisar a sua aplicação no servidor de IIS, identificar quais sites podem ser migrados para a nuvem, realçar quaisquer elementos que não possam ser migrados ou aos quais a plataforma não dá suporte. A seguir, alguns dos principais itens aos quais você deve se atentar e que são verificados durante a análise de compatibilidade:

• Associações de porta – aplicativos Web somente dão suporte à porta 80 para HTTP e à porta 443 para tráfego HTTPS. Configurações de porta diferentes serão ignoradas e o tráfego será roteado para 80 ou 443.
• Autenticação – os aplicativos Web dão suporte à Autenticação Anônima por padrão e à Autenticação de Formulários onde especificado por um aplicativo. A autenticação do Windows pode ser usada somente com a integração com o Active Directory do Azure e o ADFS. Não há suporte no momento para nenhuma outra forma de autenticação - por exemplo, Autenticação Básica.
• Cache de Assembly Global (GAC) – os aplicativos Web não dão suporte ao GAC. Se seu aplicativo faz referência a conjuntos que você normalmente implanta no GAC, você precisará implantar na pasta bin do aplicativo em aplicativos Web.
• Modo de compatibilidade IIS5 – não há suporte para esse modo nos aplicativos Web.
• Pools de aplicativos – em aplicativos Web, cada site e seus aplicativos filho são executados no mesmo pool de aplicativos. Se o site tiver vários aplicativos filho utilizando vários pools de aplicativos, consolide-os em um único pool de aplicativos com as mesmas configurações ou migre cada aplicativo em um aplicativo Web separado.
• Componentes COM – aplicativos Web não permitem o registro de componentes COM na plataforma. Se seus sites ou aplicativos utilizarem componentes COM, você deve reescrevê-los em código gerenciado e implantá-los em seu site ou aplicativo.
• Filtros ISAPI – os aplicativos Web podem dar suporte ao uso de filtros ISAPI. Você precisa fazer o seguinte:
  • Implantar as DLLs com seu aplicativo Web
  • Registrar as DLLs usando Web.config
  • Coloque um arquivo applicationHost.xdt na raiz do site com o conteúdo seguinte:

   <?xml version="1.0"?>
   Para obter mais exemplos de como usar transformações de documentos XML com o seu site, consulte Transformar seu Site do Microsoft Azure .

• Outros componentes, como SharePoint, extensões de servidor do FrontPage (FPSE), FTP, certificados SSL não serão migrados.

Outro ponto importante a ser frisado é que o Banco de Dados da aplicação pode ser migrado em conjunto com a mesma, desde que a sua string de conexão esteja no web.config da aplicação, caso contrário a migração automática do Banco de Dados não é realizada.

Dos pontos acima mencionados chamamos a atenção para o item Pools de aplicativos. Nossas aplicações, devido a quantidade de sistemas geralmente são construídas em torno de apenas uma URL padrão (geralmente a do CoreSSO), enquanto todos os demais módulos e sistemas são aninhados como filhos da aplicação, também conhecidos como Application. Para cada Application criada temos por padrão criar um Pool de aplicativos próprio para separar a execução das aplicações. Este modelo trás algumas implicações técnicas na hora de efetuar a migração para o Azure pois, ou todos utilizam o mesmo pool ou devem ser criados sites individuais para cada aplicação, e é aqui onde as implicações técnicas começam.

No Azure, não existe o conceito que utilizamos de infraestrutura compartilhada, onde temos um servidor IIS com diversos sites utilizando os recursos disponíveis do servidor. Quando criamos um site na nuvem do Azure este é hospedado individualmente em uma instância individual de IIS, que possui sua configuração própria de hardware. Sim, para cada site publicado individualmente ele está atrelado a um tipo de máquina para realizar a sua execução, em outras palavras, se temos hoje um site com 15 applications e vamos migrá-lo para websites individuais é como que se no final tivéssemos nada mais nada menos que 15 servidores sustentando essa aplicação. O problema aqui é o custo elevado para manter a aplicação, visto que mesmo sem uso, essas 15 instâncias estariam ativas e consumindo créditos da empresa.

Desenvolvendo Aplicações para o Azure

Como visto anteriormente, o Azure possui o Azure App Service especializado na hospedagem de aplicativos Web, aplicativos para dispositivos móveis e Aplicativos de Interface de Programação (API) sem a necessidade de configurar uma máquina virtual e o software da plataforma associada. Para tanto, é possível fazer o upload de um aplicativo da Web personalizado do Microsoft Visual Studio ou de outra ferramenta de desenvolvedor da Web.

Introdução ao App Service

Há uma crescente demanda pelas organizações para entregar aplicativos móveis e web que envolvam e conectem com seus clientes. Além disso, esses aplicativos têm que trabalhar em qualquer dispositivo e devem ser capazes de consumir e integrar com dados de qualquer lugar. O App Service fornece uma plataforma poderosa que integra tudo o que as empresas precisam para criar aplicações web e móveis que podem funcionar em qualquer dispositivo. Esses aplicativos podem se integrar facilmente a outros aplicativos de Software como Serviço (SaaS), como Microsoft Office 365, Microsoft OneDrive for Business, Facebook e muito mais, ou conectar-se a aplicativos corporativos locais, como SAP, Oracle e outros.

Panorâmica do App Service

Plataforma Azure App Service

O App Service fornece uma plataforma abrangente para a criação de aplicativos baseados em nuvem que os usuários podem consumir em qualquer dispositivo, além de fornecer um serviço hospedado que os desenvolvedores podem usar para criar aplicativos para celular e web. Além disso, os desenvolvedores podem usar esse serviço para desenvolver API's e usá-las para integrar aplicativos SaaS usando aplicativos lógicos, para que eles possam combinar a lógica de negócios para obter diferentes funcionalidades em seus aplicativos. O App Service é um novo serviço Azure que substituiu os seguintes serviços Azure: Azure Websites, Azure Mobile Services e Azure BizTalk Services. O App Service agora é um serviço integrado único e possui recursos mais avançados do que seus predecessores, a saber:

• Web Apps: Fornece uma plataforma comum para desenvolver, construir, hospedar e gerenciar aplicativos da web;

• Mobile Apps: Fornece uma plataforma para a construção e suporte de aplicativos móveis que os usuários podem consumir em quase qualquer dispositivo;

• API Apps: Fornece uma plataforma de serviço hospedada que pode ajudar os desenvolvedores a criar, hospedar e consumir facilmente APIs que são desenvolvidas usando plataformas conhecidas, como ASP.NET, PHP e Python; e

• Logic Apps: Permite links rápidos entre aplicativos baseados em nuvem, para que você possa criar soluções conectadas.

Web Apps

Plataforma Azure Web Apps

O recurso Web Apps é uma plataforma de tecnologias que permitem a criação de aplicativos Web no Azure sem configurar e manter suas próprias máquinas virtuais. No Azure, você pode executar aplicativos Web que são desenvolvidos usando os frameworks ASP.NET, PHP, Node.js e Python. O recurso Web Apps permite que os desenvolvedores usem o mesmo conjunto de ferramentas e frameworks para criar aplicativos Web, fornecer versões de aplicativos, atualizar os aplicativos com novas funcionalidades e ter uma funcionalidade de monitoramento completa por meio do ciclo de vida dos aplicativos Web. Os principais recursos do Web Apps são:

• Gallery applications: Pode-se usar o Azure Marketplace para escolher entre soluções predefinidas para configurações populares, como sites de blogs, frameworks, aplicativos de inicialização ASP.NET e outros. Pode-se encontrar a seleção completa de soluções na seção de Aplicativos Web do Marketplace;

• Auto scaling: Pode-se implementar várias instâncias de cada aplicativo Web para aumentar a capacidade e garantir a resiliência. O balanceador de carga do Azure distribui automaticamente as solicitações de entrada entre essas instâncias. Pode-se também pode configurar a funcionalidade de crescimento automático para lidar com cargas recebidas dinamicamente;

• Continuous integration: Pode-se implantar o código de aplicativos à partir de sistemas de controle de versão na nuvem (como o Visual Studio Online e o GitHub), sistemas de controle de versão on-premise (como o Team Foundation Server e o Git), e de ferramentas de implantação (como Visual Studio, clientes FTP, WebMatrix e MSBuild). Pode-se também usar ferramentas de integração contínua para automatizar a compilação, testes e testes de integração;

• Deployment slots: Ao usar o plano padrão para o App Service é possível criar dois ou mais slots para cada aplicativo Web. Por exemplo, pode-se criar um slot para o o ambiente de produção e, em seguida, implantar o código testado e aceito. Em seguida, pode-se criar um segundo slot para o ambiente de teste e implantar o novo código para executar testes de aceitação (o slot de teste terá uma URL diferente)

• Testing in production: Quando uma nova versão do seu aplicativo Web instalado no slot de teste passar todos os testes, você pode implantá-lo com segurança no ambiente de produção trocando os slots. Isso também fornece um caminho de reversão simples. Se a nova versão causar problemas inesperados, você pode trocar os slots novamente para reverter para o site de produção antigo;

• Azure WebJobs: O recurso WebJobs executa processos em segundo plano para aplicativos Web, descarregando assim a maior parte das tarefas demoradas e com uso intensivo de CPU dos aplicativos Web. Pode-se executar tarefas comuns, como atualizar um banco de dados ou mover arquivos de log facilmente usando WebJobs; e

• Hybrid connections: Pode-se implementar conexões híbridas de aplicativos Web e móveis no Azure para acessar recursos locais, como bancos de dados SQL ou outros recursos publicados. Ao usar o Gerenciador de conexões híbridas é possível compartilhar a conexão em vários aplicativos Web ou aplicativos para dispositivos móveis, além de limitar as portas TCP necessárias para acessar sua rede. No serviço Premium é possível usar o App Service Environment para integrar-se a uma rede virtual do Azure. Um cenário comum no qual as conexões híbridas são utilizadas é quando o aplicativo Web precisa acessar um banco de dados ou um serviço da Web que está sendo executado em uma máquina virtual hospedada em uma rede virtual do Azure.

Os aplicativos Web geralmente requerem dois serviços de suporte: armazenamento de dados e armazenamento de arquivos. Os dados brutos que o código do lado do servidor formata em uma página da Web e envia para o usuário muitas vezes está em um banco de dados. No Azure, você pode usar um banco de dados SQL para hospedar esse banco de dados. Como alternativa, você pode provisionar um banco de dados em uma máquina virtual ou usar o armazenamento de tabela Azure. Os aplicativos da Web geralmente incluem arquivos de mídia, como: imagens, vídeos e arquivos de som. O desempenho normalmente é melhorado se você não armazenar esses arquivos de mídia em um banco de dados. No Azure, você pode usar uma conta de armazenamento para esses arquivos.

Mobile Apps

Plataforma Azure Mobile Apps

O recurso Mobile Apps é uma parte do App Service e fornece uma plataforma para criação e suporte de aplicativos móveis, resolvendo problemas comuns para os desenvolvedores. Os requisitos comuns de aplicativos para dispositivos móveis incluem que eles precisam de:

• Armazenar e acessar dados estruturados;

• Receber notificações quando eventos acontecem na nuvem;

• Autenticar e autorizar usuários com base no Facebook, Twitter, Microsoft ou outras identidades; e

• Definir a lógica de negócios.

O recurso Mobile Apps permite que desenvolvedores criem aplicativos multiplataforma que podem ser executados no Windows, iOS ou Android. Esses aplicativos podem ser executados apenas na nuvem ou conectar-se à infraestrutura local para fins de autenticação e autorização. Os desenvolvedores podem usar mais de 40 conectores API SaaS para integração com uma variedade de aplicativos em nuvem, além de beneficiar-se do mecanismo de notificação build-push que pode enviar um grande número de notificações push personalizadas para quase qualquer dispositivo móvel que esteja usando o iOS, o Android ou o Windows.

O Mobile Apps suporta back-end' escrito em Java e PHP back-end e já vem preparado com crescimento automático (auto-scale) e balanceamento de carga. Além disso, suporta vários slots de implantação para produção e testes, fornecendo também alertas e arquivos de log para monitoramento e solução de problemas, contando ainda com a integração com o New Relic fornece uma visão profunda do desempenho e da confiabilidade dos aplicativos para dispositivos móveis desenvolvidos.

É possível aproveitar todos os novos recursos migrando as soluções existentes de uma de duas maneiras:

• Migração: Este processo só altera o ambiente subjacente sem reescrever qualquer código. Após a migração todos os novos recursos, como WebJobs, nomes de domínio personalizados, slots de teste, crescimento automático e balanceamento de carga estarão disponíveis; e

• Atualização: Este processo é mais complexo porque requer alterações de código. Normalmente, é necessário criar uma segunda instância do aplicativo, atualizar o projeto para usar os novos kits de desenvolvimento de software para servidor (SDKs) e, em seguida, liberar o novo aplicativo.

Logic Apps

Plataforma Azure Logic Apps

Logic Apps automatizam um processo de negócios, permitindo links rápidos entre aplicativos baseados em nuvem como: Office365, Google Services, Salesforce e muitos outros, utilizando para tanto um editor visual para pode combinar conectores do Azure Marketplace para diferentes cenários de integração.

Os Logic Apps usam um mecanismo de fluxo de trabalho para projetar processos de negócios graficamente e, em seguida, interliga-los através de conectores para que os usuários possam acessar os dados e serviços necessários. A funcionalidade dos conectores é baseada nas APIs que podem acionar novas instâncias do fluxo de trabalho com base em um evento específico, onde cada etapa do fluxo de trabalho é uma ação que acessa dados ou serviços através do conector. Cenários de integração mais avançados podem usar regras, transformações, validações e recursos que fazem parte dos Serviços BizTalk.

Algumas das principais APIs mais comuns incluem:

• Conector do Office 365: API para criar uma ação que possa enviar e receber e-mails além de gerenciar calendários e contatos para uma conta do Office 365;

• Conector Microsoft OneDrive: API para criar uma ação que possa se conectar ao seu Microsoft OneDrive pessoal e carregar, excluir ou listar arquivos;

• Conector Microsoft Yammer: API para se conectar à sua assinatura do Yammer para postar ou obter novas mensagens;

• Conector do Facebook: API para se conectar à sua conta do Facebook para publicar mensagens, fotos, receber comentários e executar outras ações; e

• Conector HTTP: API para abrir um HTTP listener para ouvir uma solicitação HTTP recebida em um endereço específico.

Os conectores de integração empresarial podem estender os serviços de aplicativos e fornecer integração e conectividade aos sistemas SAP, Oracle, DB2, Informix dentre outros.

Ao desenvolver uma solução é possível usar conectores com gatilhos para poll ou push. Um cenário comum de gatilhos poll é integrar o aplicativo quando novos dados estiverem disponíveis em um local de arquivo, no armazenamento Azure ou em um banco de dados SQL. Em seguida, pode-se usar o gatilho de pesquisa para obter esses dados e usá-los no aplicativo. Geralmente, os gatilhos push são utilizados para iniciar uma nova instância de uma aplicação lógica quando ocorre um evento específico.

Além disso, Logic Apps podem incluir conectores que iniciam uma ação, por exemplo, conectores podem ser usados para gravar, atualizar ou excluir dados de uma conta de armazenamento ou de algum outro aplicativo vinculado.

API Apps

Plataforma Azure API Apps

Uma API é um conjunto de rotinas, protocolos e ferramentas que especificam como os componentes de software devem interagir, criando blocos de construção para o desenvolvimento de aplicativos. Sendo frequentemente usada devido a facilidade da sua reutilização em projetos.

API Apps é uma plataforma de serviço hospedada que pode ajudar os desenvolvedores a construir, hospedar e usar facilmente APIs desenvolvidas usando plataformas conhecidas como: ASP.NET, PHP, Python dentre outras. É possível criar um aplicativo de API usando a interface simples no portal do Azure e, em seguida, integrá-lo com o Visual Studio para desenvolvimento, depuração e gerenciamento.

Ao criar uma nova API, o Azure gera o código que permite que diferentes aplicativos SaaS (como o Office 365) usem a API, além de ter suporte integrado para os metadados Swagger API os quais descrevem as capacidades da API e geram o código do cliente para acessar a API usando diferentes idiomas como C#, Java e JavaScript. Também é possível para as APIs se beneficiar da ativação do cross-origin resource sharing (CORS), isso permite que o JavaScript faça chamadas de API para domínios diferentes do domínio original do código JavaScript.

Você pode criar um aplicativo de API que pode acionar um processo de fluxo de trabalho com base em determinados eventos ou condições. Por exemplo, você pode configurar o aplicativo para procurar uma seqüência específica em um aplicativo em nuvem, como o Yammer, e depois desenvolver um método que inicie automaticamente uma ação ou resposta. É possível também criar uma API que pode acionar um processo de fluxo de trabalho com base em determinados eventos ou condições.

App Service Environment

Plataforma Azure App Service Environment

Aplicativos críticos para negócios geralmente exigem ambientes isolados e dedicados. O App Service Environment, que é parte do plano de serviço premium, habilita no Azure recursos isolados e dedicados para esse tipo de aplicativo. É possível usar o App Service Environment para hospedar aplicativos Web, aplicativos para dispositivos móveis e API's que exigem recursos de computação altamente escaláveis, isolamento e acesso à rede.

O site Introduction to App Service Environment possui uma ótima introdução sobre as principais funcionalidades que são disponibilizadas no neste modelo de negócio. Também é possível verificar a documentação detalhada do ambiente através do endereço App Service Environment Documentation .

Storage: Planejamento e Implementação

Os serviços de armazenamento do Microsoft Azure oferecem uma variedade de opções para armazenar e acessar dados. Os principais serviços consistem em quatro tipos de armazenamento: blobs, tables, queues e files. O Azure Content Delivery Network (CDN) é outro serviço relacionado ao armazenamento cujo objetivo principal é melhorar o desempenho de aplicativos e serviços web hospedando dados em locais próximos aos consumidores.

Storage como um componente do Azure

O Azure Storage faz parte dos serviços de gerenciamento de dados do Azure, além dos recursos de backup e recuperação. Vários serviços Azure utilizam o Azure Storage, incluindo máquinas virtuais IaaS, App Service e serviços de nuvem de plataforma como serviço (PaaS).

A escolha do armazenamento também tem outras implicações de uso, principalmente relacionado à diferença entre a estrutura V1 e V2 do Azure.

O Azure também disponibiliza o serviço de CND, no qual App Service, serviços em nuvem PaaS e aplicativos Web hospedados em máquinas virtuais IaaS podem se beneficiar de seu uso, pois este recurso fornece armazenamento distribuído globalmente para seu conteúdo estático, que pode incluir arquivos de texto, bibliotecas de scripts, software para download e mídia (como arquivos de áudio e vídeo). O armazenamento distribuído permite a melhora da experiência do usuário ao acessar esses serviços de locais remotos, pois o conteúdo é replicado para um grande número de servidores que residem em vários locais ao redor do mundo e, quando um usuário solicita qualquer conteúdo que está residente em um CDN, tal solicitação é encaminhada para um servidor CDN que está mais próximo do local do usuário.

Panorâmica sobre o Azure Storage

Em geral, o Azure Storage oferece quatro tipos de serviços de armazenamento, dependendo do tipo de dados que eles são projetados para armazenar:

• Blobs: Geralmente eles representam arquivos não estruturados, tais como: conteúdo de mídia, discos de máquinas virtuais, backups ou logs. Os blobs facilitam o mecanismo de locking, assegurando o acesso exclusivo aos arquivos que as máquinas virtuais IaaS necessitam. Existem três tipos de blobs, a saber:
  • O primeiro, conhecido como block blob, é otimizado para acesso sequencial, o que é ideal para conteúdo de mídia;
  • O segundo, conhecido como page blob, oferece capacidades de acesso aleatório superior, o que é mais adequado para discos de máquinas virtuais; e
  • O terceiro, conhecido como append blob, aplica-se a operações de anexação de dados, sem a necessidade de modificar o conteúdo existente, como por exemplo em arquivos de log onde apenas adiciona-se conteúdo ao fim do arquivo;

• Tables: Este tipo hospeda conteúdo não-relacionais e parcialmente estruturado, que consiste em várias linhas de dados com diferentes conjuntos de propriedades. No contexto do armazenamento Azure Table, estas linhas são referidas como entidades. Geralmente este modelo é implementado como o armazenamento de dados de backend para o App Service ou serviços em nuvem PaaS;

• Queues: Este é um armazenamento temporário para mensagens que os serviços Azure comumente usam para se comunicar de forma assíncrona entre si. Em particular, em aplicativos distribuídos, um componente de origem envia uma mensagem colocando-o em uma fila, e o componente de destino consome as mensagens na fila uma de cada vez;

• Files: Semelhante ao blob, eles fornecem armazenamento para arquivos não estruturados, mas oferecem suporte para compartilhamento de arquivos da mesma maneira que os compartilhamentos de arquivos tradicionais do Windows.

Blob storage

Azure blob storage

O serviço de blob storage do Azure armazena grandes quantidades de dados não estruturados sob a forma de arquivos, que normalmente residem em contêineres. Os contêineres são semelhantes às pastas de arquivo, ajudando a organizar os blocos logicamente em uma conta de armazenamento e fornecendo segurança extra, contudo, suportam apenas hierarquia de nível único. Cada blob pode ter centenas de gigabytes de tamanho e os usuários podem acessá-los por meio de uma URL exclusiva.

Ao criar um blob, é necessário informar o seu tipo. Geralmente, isso acontece implicitamente com base na finalidade pretendida. Por exemplo, ao criar uma máquina virtual (IaaS) automaticamente é criado o "contêiner" .vhd na conta de armazenamento de destino e um page blob contendo os arquivos de disco da máquina virtual. Os três tipos de blobs são:

• Block blobs: São otimizados para downloads e uploads. Para realizar essa otimização, o Azure divide os dados em blocos menores de até 4 megabytes (MB) de tamanho, que posteriormente são carregados ou baixados em paralelo. Block blobs individuais podem ter até 200 GB de tamanho;

• Page blobs: São otimizados para operações aleatórias de leitura e gravação. os blobs são acessados ​​como páginas, cada uma com até 512 bytes de tamanho. Quando um page blob é criado especifica-se o tamanho máximo para o qual pode crescer, até o limite de 1 TB. Cada page blob oferece throughput de até 60MB por segundo ou 500 (8 KB em tamanho) operações de I/O por segundo (IOPS); e

• Append blobs: São estritamente para operações de append, porque não suportam modificações ao seu conteúdo existente. A adição (append) ocorre em blocos de até 4 MB (o mesmo tamanho que os blocos individuais de block blobs) com até 50.000 blocos por blob de anexos, o que se traduz em aproximadamente 195GB de tamanho. É geralmente usado em operações de log.

Table storage

Azure table storage

O serviço de armazenamento Azure Table pode ser utilizado para armazenar dados parcialmente estruturados em tabelas sem as restrições dos bancos de dados relacionais tradicionais (por trás é um NoSQL). Dentro de cada conta de armazenamento é possível criar várias tabelas e cada tabela pode conter várias entidades. Como o table storage não exige um schema, as entidades em uma única tabela não precisam ter o mesmo conjunto de propriedades. Por exemplo, uma entidade do "Produto" pode ter uma propriedade "Tamanho", enquanto outra entidade do "Produto" na mesma tabela pode não ter nenhuma propriedade "Tamanho". Cada propriedade consiste em um nome e um valor. Por exemplo, a propriedade Tamanho pode ter o valor 50 para um produto específico.

Semelhante aos blobs, os aplicativos podem acessar cada tabela por meio de um URL. Por exemplo, para acessar uma tabela denominada "mytable" em uma conta de armazenamento chamada "myaccount" as aplicações usariam a seguinte URL: http://myaccount.table.core.windows.net/mytable

O número de tabelas em uma conta de armazenamento é limitado apenas pelo tamanho máximo da conta de armazenamento. Da mesma forma, não há restrições sobre o número máximo de entidades em uma tabela. Cada entidade pode ter até 1 MB de tamanho e possuir até 252 propriedades personalizadas. Cada entidade também tem três propriedades designadas: uma chave de partição (partitio key), uma chave de linha (row key) e um timestamp. O valor do timestamp é gerado automaticamente, mas a escolha da chave de partição e da chave de linha depende do designer da tabela. Para maiores informações acesse o site.

É importante escolher essas duas propriedades cuidadosamente porque Azure usa sua combinação para criar um índice agrupado para a tabela. O índice agrupado, por sua vez, melhora consideravelmente a velocidade das pesquisas, o que de outra forma resultaria em uma varredura da tabela completa. É possível usar a chave de partição para agrupar entidades semelhantes com base em sua característica comum, mas com valores de chave de linha exclusivos.

Queue storage

Azure queue storage

O serviço Azure Queue Storage fornece armazenamento temporário de mensagens. Frequentemente usa-se o queue storage para facilitar o intercâmbio confiável de mensagens entre componentes individuais de sistemas multitarefa ou distribuídos. Esses componentes adicionam e removem mensagens de uma fila, emitindo comandos sobre os protocolos HTTP ou HTTPS.

Semelhante a outros tipos de serviço de armazenamento do Azure, cada fila é acessível a partir de uma URL exclusiva. Por exemplo, para acessar uma fila chamada "myqueue" em uma conta de armazenamento chamada "myaccount" as aplicações usariam a seguinte URL: http://myaccount.queue.core.windows.net/myqueue.

Pode-se criar qualquer número de filas em uma conta de armazenamento e qualquer número de mensagens em cada fila, até o limite de 500TB para todos os dados na conta de armazenamento. Contudo, cada mensagem pode ter até 64 kilobytes (KB) em tamanho.

Outro serviço do Azure frequentemente usado, e que oferece funcionalidade de armazenamento de mensagens similar ao queue storage, é o Service Bus. No entanto, os aspectos e funcionalidades de ambos os serviços diferem entre si. Maiores informações sobre o Azure storage queue e o service bus podem ser encontradas aqui .

File storage

O serviço File Storage permite o compartilhamentos de arquivos SMB (Server Message Block) no Azure exatamente como um servidor de arquivos local faria. Dentro de cada compartilhamento de arquivos é possível criar vários níveis de pastas para categorizar o conteúdo, e cada diretório pode conter vários arquivos e pastas. Os arquivos podem ter até 1 TB de tamanho e o tamanho máximo de um compartilhamento é de 5 TB.

Precificação Padrão dos Serviços de Armazenamento do Azure

Os custos da conta de armazenamento padrão do Azure são calculados com base em sua utilização. Em geral, quatro componentes contribuem para encargos relacionados com o armazenamento, são eles:

• Volume regional de tráfego de saída: As transferências de dados de entrada para o Azure são gratuitas, contudo, as transferências de dados de saída dos datacenters do Azure são gratuitas apenas para os primeiros 5GB por mês. Efetivamente, quando os serviços ou aplicativos estão localizados na mesma região que o seu armazenamento o Azure não impõe taxas pelo uso da largura de banda entre os recursos de computação e de armazenamento;

• Transações: Uma transação representa uma operação de leitura ou gravação para ou a partir de uma conta de armazenamento. O preço é fornecido para cada 100.000 transações;

• Capacidade: A capacidade representa a quantidade de espaço de armazenamento usado. As taxas baseiam-se em GB utilizados. No caso de page blobs, por exemplo, isso significa que se criarmos um novo arquivo de disco rígido virtual de 100 GB, mas usarmos apenas 10 GB de seu volume total, iremos pagar apenas esse valor, independentemente de quanto espaço foi alocado; e

• Esquema de replicação: As contas de armazenamento LRS são mais baratas do que as contas ZRS, que por sua vez, são mais baratas do que as contas do GRS. As contas de armazenamento geograficamente redundantes de leitura-acesso são as mais caras.

Melhores Práticas de Desenvolvimento

Azure App Service

Nesta seção estão resumidas algumas das boas práticas para o desenvolvimento utilizando o Azure App Service.

Colocation

Quando os recursos do Azure que compõem uma solução, tais como um aplicativo Web e um banco de dados, estão localizados em regiões diferentes os seguintes problemas podem ocorrer:

• Maior latência na comunicação entre os recursos; e

• Encargos monetários para a transferência de dados de saída entre regiões, conforme observado na página de preços do Azure.

Colocation em uma mesma região é melhor para os recursos Azure que compõem uma solução, tais como um aplicativo web, um banco de dados ou uma conta de armazenamento usada para armazenar conteúdo ou dados. Ao criar os recursos, é necessário certificar-se de que eles estão na mesma região do Azure, a menos que o escopo do negócios ou o design da aplicação não permita tal cenário. Caso os recursos tenham sido criados em regiões diferentes é possível mover um aplicativo do App Service para a mesma região onde está o banco de dados, através do recurso de clonagem do App Service (atualmente disponível apenas para aplicativos Premium App Service Plan).

Quando os aplicativos consomem mais memória do que o esperado

Quando um aplicativo consome mais memória do que o esperado, conforme indicado por meio de recomendações de monitoramento ou de serviços, recomenda-se utilizar o recurso Auto-Healing do App Service. Uma das opções do recurso Auto-Healing é o de tomar ações personalizadas com base em um limite de memória. As ações vão desde notificações por e-mail à investigação por meio de despejo de memória até a reciclagem do processo de trabalho.

O Auto-Healing pode ser configurado via web.config ou através de uma interface de usuário amigável (conforme descrito no blog App Service Support Site Extension).

Quando os aplicativos consomem mais CPU do que o esperado

Quando um aplicativo consome mais CPU do que o esperado ou experimenta repetidos picos de CPU, conforme indicado por recomendações de monitoramento ou serviço, é prudente considerar a possibilidade de escalonar vertical ou horizontal o plano do App Service. Se a sua aplicação é statefull o escalonamento vertical é a única opção, enquanto para os aplicativos stateless o escalonamento horizontal trará mais flexibilidade e maior potencial de escala.

Para obter mais informações sobre aplicativos statefull e stateless assista a este vídeo: Planejando um aplicativo Multicamada End-to-End escalável no Microsoft Azure Web App.

Para obter mais informações sobre as opções de escala de serviço de aplicativo e opções de escala automática, leia: Dimensione um aplicativo Web no Azure App Service.

Quando os recursos do socket estão esgotados

Uma razão comum para esgotar as conexões TCP de saída é o uso de bibliotecas de terceiros que não são implementadas para reutilizar as conexões TCP ou, no caso de um protocolo de nível superior como HTTP - Keep-Alive, não sendo aproveitadas. É necessário revisar a documentação de cada uma das bibliotecas referenciadas pelos aplicativos no seu App Service Plan para garantir que eles estejam configurados, ou sendo acessados, de forma eficiente na reutilização de conexões de saída. É importante também seguir as diretrizes da documentação da biblioteca para criação, liberação adequada e limpeza das conexões para evitar vazamento das mesmas.

Quando novos aplicativos Node.js são implantados no Azure App Service

A configuração padrão do Azure App Service para aplicativos Node.js destina-se a atender melhor às necessidades dos aplicativos mais comuns. Se a configuração do aplicativo Node.js desenvolvido se beneficiar de ajustes personalizados para melhorar o desempenho ou otimizar o uso de recursos de CPU/memória/rede será necessário revisar as práticas recomendadas e etapas de solução de problemas. O artigo a seguir descreve as melhores práticas, vários cenários ou problemas que o aplicativo pode enfrentar e como corrigir tais dificuldades: Best practices and troubleshooting guide for Node applications on Azure App Service.