Avaliação de candidaturas

  • Artigo

A racionalização da nuvem é o processo de avaliação de aplicativos para determinar a melhor maneira de migrá-los ou modernizá-los para a nuvem.

Os métodos de racionalização incluem:

  • Rehospedar. Também conhecida como migração lift and shift , o rehost move um aplicativo atual para a nuvem com o mínimo de alterações.
  • Refatorar. Refatoração ligeira de um aplicativo para se adequar às opções baseadas em plataforma como serviço (PaaS) pode reduzir os custos operacionais.
  • Rearquitecto. Rearquitete aplicativos antigos que não são compatíveis com componentes de nuvem ou aplicativos compatíveis com a nuvem que obteriam eficiência operacional e de custo rearquitetando em uma solução nativa da nuvem.
  • Recriar. Se as alterações ou os custos para levar um aplicativo adiante forem muito grandes, considere a criação de uma nova base de código nativa da nuvem. A reconstrução é especialmente apropriada para aplicativos que anteriormente atendiam às necessidades de negócios, mas agora não têm suporte ou estão desalinhados com os processos de negócios atuais.

Antes de decidir sobre uma estratégia apropriada, analise o aplicativo atual para determinar o risco e a complexidade de cada método. Considere o ciclo de vida do aplicativo, a tecnologia, a infraestrutura, o desempenho, as operações e o monitoramento. Para arquiteturas multicamadas, avalie a camada de apresentação, a camada de serviço, a camada de integrações e a camada de dados.

As listas de verificação a seguir avaliam um aplicativo para determinar a complexidade e o risco de rearquitetar ou reconstruir.

Complexidade e risco

Cada um dos seguintes fatores aumenta a complexidade, o risco ou ambos.

Arquitetura

Defina a arquitetura de alto nível, como aplicativo Web, serviços Web, armazenamento de dados ou cache.

Fator Complexidade Risco
Os componentes do aplicativo não são traduzidos diretamente para o Azure. ✔ ✔
O aplicativo precisa de alterações de código para ser executado no Azure. ✔ ✔
O aplicativo precisa de alterações de código importantes e complexas para ser executado no Azure. ✔ ✔

Impulsionadores de negócios

Aplicativos mais antigos podem exigir alterações extensas para chegar à nuvem.

Fator Complexidade Risco
Esta aplicação existe há mais de três anos. ✔
Esta aplicação é crítica para os negócios. ✔
Existem bloqueadores de tecnologia para migração. ✔
Existem bloqueadores de negócios para a migração. ✔
Esta aplicação tem requisitos de conformidade. ✔
A aplicação está sujeita a requisitos de dados específicos do país/região. ✔
O aplicativo é acessível publicamente. ✔ ✔

Tecnologia

Fator Complexidade Risco
Este não é um aplicativo baseado na Web e não está hospedado em um servidor web. ✔
O aplicativo não está hospedado no Windows IIS ✔
O aplicativo não está hospedado no Linux ✔
O aplicativo é hospedado em uma web farm e requer vários servidores para hospedar os componentes Web. ✔ ✔
O aplicativo requer que software de terceiros seja instalado nos servidores. ✔ ✔
O aplicativo é hospedado em um único datacenter e as operações são executadas em um único local. ✔
O aplicativo acessa o registro do servidor. ✔
O aplicativo envia e-mails e precisa de acesso a um servidor SMTP. ✔
Este não é um aplicativo .NET. ✔
O aplicativo usa o SQL Server como seu armazenamento de dados. ✔
O aplicativo armazena dados em discos locais e precisa acessar os discos para funcionar corretamente. ✔
O aplicativo usa os Serviços do Windows para processar operações assíncronas ou precisa de serviços externos para processar dados ou operações. ✔

Implementação

Ao avaliar os requisitos de implantação, considere:

  • Número de utilizadores diários
  • Número médio de usuários simultâneos
  • Tráfego esperado
  • Largura de banda em Gbps
  • Pedidos por segundo
  • Quantidade de memória necessária

Você pode reduzir o risco de implantação armazenando o código sob controle do código-fonte em um sistema de controle de versão, como Git, Azure DevOps Server ou SVN.

Fator Complexidade Risco
Usar código e dados existentes é uma prioridade #1. ✔ ✔
O código do aplicativo não está sob controle do código-fonte. ✔
Não há nenhum processo de compilação automatizado como o Azure DevOps Server ou o Jenkins. ✔
Não há nenhum processo de liberação automatizado para implantar o aplicativo. ✔ ✔
O aplicativo tem um Acordo de Nível de Serviço (SLA) que determina a quantidade de tempo de inatividade esperado. ✔
O aplicativo experimenta tempos de uso ou cargas de pico ou variáveis. ✔
O aplicativo Web salva seu estado de sessão em processo, em vez de um armazenamento de dados externo. ✔

Operações

Fator Complexidade Risco
O aplicativo não tem uma estratégia de instrumentação bem estabelecida ou uma estrutura de instrumentação padrão. ✔
O aplicativo não usa ferramentas de monitoramento e a equipe de operações não monitora o desempenho do aplicativo. ✔
O aplicativo mediu o SLA em vigor e a equipe de operações monitora o desempenho do aplicativo. ✔
O aplicativo grava em um armazenamento de log, log de eventos, arquivo de log, banco de dados de log ou Application Insights. ✔
O aplicativo não grava em um armazenamento de log, log de eventos, arquivo de log, banco de dados de log ou Application Insights. ✔
O aplicativo não faz parte do plano de recuperação de desastres da organização. ✔

Segurança

Fator Complexidade Risco
O aplicativo usa o Ative Directory para autenticar usuários. ✔ ✔
A organização ainda não configurou o Microsoft Entra ID ou não configurou o Microsoft Entra Connect para sincronizar o AD local com o Microsoft Entra ID. ✔
O aplicativo requer acesso a recursos locais, o que exigirá conectividade VPN do Azure. ✔
A organização ainda não configurou uma conexão VPN entre o Azure e seu ambiente local. ✔ ✔
O aplicativo requer um certificado SSL para ser executado. ✔ ✔

Resultados

Usando as tabelas acima, determine se cada fator se aplica ao seu aplicativo. Conte o número de marcas de verificação de Complexidade e Risco para os fatores que se aplicam ao seu aplicativo.

  • O nível de complexidade esperado para migrar ou modernizar o aplicativo para o Azure é: Fatores de complexidade correspondentes/Fatores de complexidade possíveis totais.
  • O risco esperado envolvido é: Fatores de Risco Correspondentes/Total de Possíveis Fatores de Risco.

Total de Fatores de Complexidade Possíveis = 28, Total de Fatores de Risco Possíveis = 23

Tanto para complexidade quanto para risco, uma pontuação obtida a partir do cálculo acima de <0,3 = baixo, 0,7 = médio, 0,7 <>= alto. Essas pontuações fornecem uma escala relativa de complexidade e risco.

Refatorar, rearquitetar ou reconstruir

Para racionalizar se deve rehospedar, refatorar, rearquitetar ou reconstruir seu aplicativo, considere os seguintes pontos. Muitos destes fatores também contribuem para a complexidade e o risco.

Determine se os componentes do aplicativo podem ser traduzidos diretamente para o Azure. Nesse caso, você não precisa de alterações de código para mover o aplicativo para o Azure e pode usar estratégias de rehost ou refator. Se não, você precisa reescrever o código, então você precisa rearquitetar ou reconstruir.

Se o aplicativo precisar de alterações de código, determine a complexidade e a extensão das alterações necessárias. Pequenas alterações podem permitir a rearquitetura, enquanto grandes alterações podem exigir reconstrução.

Rehospedar ou refatorar

  • Se o uso de código e dados existentes for uma prioridade máxima, considere uma estratégia de refatoramento em vez de rearquitetar ou reconstruir.

  • Se você tiver cronogramas urgentes, como desligamento do datacenter ou expiração de contrato, licenciamento de fim de vida útil ou fusões ou aquisições, a maneira mais rápida de obter o aplicativo para o Azure pode ser rehospedar, seguida de refatoração para aproveitar os recursos de nuvem.

Rearquitetar ou reconstruir

  • Se houver aplicativos que atendam a necessidades semelhantes em seu portfólio, essa pode ser uma oportunidade para rearquitetar ou reconstruir toda a solução.

  • Se você quiser implementar a arquitetura de várias camadas ou microsserviços para um aplicativo monolítico, deverá rearquitetar ou reconstruir o aplicativo. Se você não se importa de manter a estrutura monolítica, você pode ser capaz de rehospedar ou refatorar.

  • Rearquitete ou reconstrua o aplicativo para aproveitar os recursos de nuvem se você planeja atualizar o aplicativo com mais frequência do que anualmente, se o aplicativo tiver horários de pico ou de uso variáveis ou se você espera que o aplicativo lide com tráfego alto.

Para decidir entre rearquitetar ou reconstruir, avalie os seguintes fatores. O maior resultado de pontuação indica a sua melhor estratégia.

Fator Rearquitetar Reconstruir
Existem outras aplicações que servem necessidades semelhantes no seu portfólio. ✔ ✔
O aplicativo precisa de pequenas alterações de código para ser executado no Azure. ✔
O aplicativo precisa de alterações de código importantes e complexas para ser executado no Azure. ✔
É importante usar o código existente. ✔
Você deseja mover um aplicativo monolítico para a arquitetura de várias camadas. ✔
Você deseja mover um aplicativo monolítico para uma arquitetura de microsserviços. ✔ ✔
Você espera que este aplicativo adicione recursos inovadores, como IA, IoT ou bots. ✔
Entre funcionalidade, custo, infraestrutura e processos, a funcionalidade é o aspeto menos eficiente deste aplicativo. ✔
O aplicativo requer software de terceiros instalado nos servidores. ✔
O aplicativo acessa o registro do servidor. ✔
O aplicativo envia e-mails e precisa de acesso a um servidor SMTP. ✔
O aplicativo usa o SQL Server como seu armazenamento de dados. ✔
O aplicativo armazena dados em discos locais e precisa acessar os discos para ser executado corretamente. ✔
O aplicativo usa serviços do Windows para processar operações assíncronas ou precisa de serviços externos para processar dados ou operações. ✔
Um aplicativo Web salva seu estado de sessão em processo, em vez de em um armazenamento de dados externo. ✔
O aplicativo tem tempos de uso e cargas variáveis e de pico. ✔ ✔
Você espera que o aplicativo lide com alto tráfego. ✔ ✔

Próximos passos