Mudanças entre as edições de "Microsoft Azure"

Edição das 17h59min de 21 de fevereiro de 2017

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

Os principais tipos de serviços de nuvem oferecidos pelo Azure são:

• Software as a Service (SaaS - Software como um serviço);
• Platform as a Service (PaaS - Plataforma como um serviço); e
• Infrastructure as a Service (IaaS - Infraestrutura como um serviço).

A MSTech adotou como estratégia técnica o início de desenvolvimento voltado para aplicações que trabalhem no modelo de PaaS. Com o PaaS, é possível criar aplicativos personalizados altamente escaláveis sem a necessidade de provisionar e manter o hardware e os recursos do sistema operacional.

Opções de Hospedagem disponíveis

Principais Serviços

O Azure provê diversas opções de serviços para aplicativos e serviços computacionais baseados na nuvem. 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. Atualmente as aplicações desenvolvidas pela MSTech se enquadram no modelo Azure Virtual Machines onde o cliente tem maior controle sobre o hardware e suporte a aplicativos legados, contudo, a manutenção e agilidade para criação destes ambientes é muito morosa e custosa para a empresa. Isto posto, a MSTech entendeu a necessidade de atualizar as tecnologias que utiliza no seu desenvolvimento de software afim de conseguir migrar seus aplicativos para o modelo App Service, onde o controle sobre o ambiente é pouco e o suporte à aplicativos legados é mínimo, porém, a agilidade e manutenção desse novo modelo é simplificado, sendo assim uma vantagem competitiva para a empresa no mercado de desenvolvimento de software ágil.

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 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.

Migrando Aplicações para o Azure

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 ^[1].
• Aprenda a implantar um aplicativo ASP.NET no Azure App Service, usando o Visual Studio ^[2].

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 ^[3]. 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^[4] 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 ^[5] 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 [6].

• 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

Referências

1. ↑ Microsoft. Create your free Azure account today, Acesso em 21 de fevereiro de 2017.
2. ↑ Burstein, G., et al. Deploy an ASP.NET web app to Azure App Service, using Visual Studio. Publicado em 16 de dezembro de 2016. Acesso em 21 de fevereiro de 2017.
3. ↑ Microsoft. Relatórios SQL. Publicado em fevereiro de 2015. Acesso em 20 de fevereiro de 2017.
4. ↑ Saxton, Adam. Use o PowerShell para criar uma VM do Azure com um servidor de relatório em modo nativo. Publicado em 11 de janeiro de 2017. Acesso em 20 de fevereiro de 2017.
5. ↑ Microsoft. Azure App Service Migration Assistant. Acesso em: 20 de fevereiro de 2017.
6. ↑ Wei, Zhao. Transform your Microsoft Azure Web Site. Publicado em 17 de junho de 2014. Acesso em 21 de fevereiro de 2017.