Compartilhar via

Planejar-se para plataformas de aplicativos modernos

  • Artigo

A metodologia Planejar da Cloud Adoption Framework ajuda a criar um plano geral de adoção da nuvem para orientar os programas e as equipes envolvidas em sua transformação digital baseada em nuvem. Essas diretrizes fornecem modelos para a criação da sua lista de pendências e seus planos, visando à construção das habilidades necessárias nas suas equipes, tudo com base nas suas pretensões na nuvem.

A aplicação da metodologia de Planejamento se concentra nos cinco Rs da racionalização do seu acervo digital. O caminho mais comum para a nuvem tem como foco a velocidade, a eficiência e a repetibilidade dos processos de migração e modernização. Dos cinco Rs, o planejamento geralmente prioriza as opções de hospedar novamente com suporte paralelo limitado para opções de rearquitetura e recompilação.

Propriedade digital

Ao planejar seu acervo digital, é aconselhável coletar dados de inventário e racionalizar seu acervo. Em um plano de adoção de contêiner, é vital que todos os ativos, por exemplo, VMs, dados e aplicativos, sejam agrupados pela carga de trabalho que suportam. Após concluir o agrupamento e a racionalização básica, você pode avaliar essas cargas de trabalho para determinar as opções de pacote e hospedar novamente ou recriar a arquitetura.

O modelo de plano de adoção da nuvem padrão é responsável pelos tipos de trabalho necessários em um esforço típico de adoção da nuvem. Mas você precisará adicionar tarefas ao seu plano para empacotar a carga de trabalho em contêineres e orquestrar o provisionamento de contêineres.

Cuidado

Este artigo presume que o leitor já adote as práticas recomendadas descritas na série de artigos sobre como criar um plano de adoção da nuvem no Azure DevOps. Mesmo que você acompanhe seu plano de adoção da nuvem usando planilha ou outras ferramentas de acompanhamento de projeto, as seções a seguir serão aplicáveis, mas as etapas de ação da adição de dados ao seu plano precisarão ser ajustadas.

Aviso

Incorporar uma estratégia de plataforma de aplicativo moderna em processos de migração padrão (ou em uma fábrica de migração) exigirá uma implementação madura de tarefas associadas à criação de arquiteturas de carga de trabalho anterior à migração. Seguir com essa estratégia sem essas tarefas atrasará o esforço de migração e poderá levar a decisões de arquitetura incorretas para os hosts de contêiner implantados e as cargas de trabalho de suporte.

Identificar cargas de trabalho candidatas

No cenário da plataforma de aplicativo moderna, os retornos de longo prazo, que exigem maior investimento inicial, são priorizados em relação a processos de migração mais eficientes. Os investimentos de longo prazo são representados em partes específicas do plano pelo maior foco na habilitação da inovação e da otimização de operações para grupos específicos de cargas de trabalho.

Para começar a alinhar a estratégia e o plano, identifique todas as cargas de trabalho provavelmente afetadas pela adição de plataformas de aplicativo modernas em sua estratégia de adoção da nuvem. Essas hipóteses serão validadas antes da implementação de qualquer alteração técnica. Para ajudar a identificar possíveis candidatas, procure os seguintes critérios no seu portfólio de cargas de trabalho:

  • Desenvolvimento ativo ou investimentos em DevOps: um percentual de cargas de trabalho de produção estará em desenvolvimento ativo. Algumas podem até mesmo ser gerenciadas por meio de práticas de DevOps contínuas.
  • Portabilidade da carga de trabalho: algumas cargas de trabalho são afetadas por questões de conformidade, proteção de dados ou restrições operacionais que podem exigir portabilidade em nuvem privada, borda ou até mesmo vários provedores de nuvem pública.
  • Consolidação de carga de trabalho: muitas cargas de trabalho (especialmente aquelas de baixa utilização) podem ser candidatas à consolidação em hosts de contêiner, resultando em poucos servidores/VMs e custos operacionais reduzidos.
  • Cargas de trabalho herdadas: cargas de trabalho herdadas podem bloquear atualizações para sistemas operacionais e até mesmo impedir a migração para a nuvem. Cargas de trabalho herdadas não compatíveis com os recursos do Azure podem ser candidatas à migração em um host de contêiner.

Documentar cargas de trabalho candidatas

Observação

A lista de considerações a seguir só deve ser documentada para candidatas à migração identificadas pelos critérios acima.

Na criação de um plano de adoção da nuvem, cada carga de trabalho é documentada segundo as diretrizes descritas em Definir e priorizar cargas de trabalho. Qualquer carga de trabalho candidata no cenário moderno de plataforma de aplicativo exigirá informações adicionais para orientar a execução do plano. Este artigo destaca a importância de documentar informações comerciais e técnicas para definir a carga de trabalho. No caso de candidatas de plataforma de aplicativo moderna, os pontos de dados a seguir devem ser adicionados à definição da carga de trabalho.

Informações de negócios

A seguir estão pontos de dados relacionados aos negócios que podem influenciar a decisão de incluir uma carga de trabalho na estratégia de plataforma de aplicativos moderna.

  • Motivos de conformidade: quais critérios de conformidade específicos estão motivando considerações sobre a hospedagem dessa carga de trabalho em uma nuvem privada?
  • Motivos de proteção de dados: quais medidas de proteção de dados estão motivando considerações sobre a hospedagem dessa carga de trabalho em uma nuvem privada?
  • Restrições operacionais: quais restrições operacionais estão motivando considerações sobre a hospedagem dessa carga de trabalho em uma nuvem privada?
  • Resultados da plataforma de aplicativos moderna: qual das seguintes motivações está por trás da avaliação dessa carga de trabalho como candidata a um contêiner? DevOps, portabilidade, consolidação, carga herdada ou vários desses motivos.
  • Modelo operacional: essa carga de trabalho será gerenciada de forma centralizada (por IT/CCoE central), descentralizada (pela equipe de carga de trabalho) ou com operações corporativas (suporte central e operações específicas de carga de trabalho)?

Informações técnicas

A seguir estão pontos de dados das equipes de tecnologia que podem influenciar a decisão de incluir uma carga de trabalho na estratégia de plataforma de aplicativo moderna.

Considerações sobre localização:

Considerações relacionadas ao local em que a carga de trabalho será hospedada.

  • Requisito de hospedagem na nuvem pública: há restrições técnicas específicas associadas ao requisito de nuvem pública?
  • Requisito de hospedagem na nuvem privada: há restrições técnicas específicas associadas ao requisito de nuvem privada?
  • Requisito de hospedagem na borda: há restrições técnicas específicas associadas ao requisito de borda?
  • Requisito de portabilidade: há restrições técnicas específicas associadas ao requisito de portabilidade em nuvem?

Considerações sobre operações:

Considerações relacionadas às operações de plataforma, hosts e cargas de trabalho.

  • Plataforma de nuvem primária: as organizações devem definir uma plataforma de nuvem primária para fornecer ferramentas de gerenciamento de operações. Algumas podem ter mais de uma plataforma de nuvem principal para gerenciar vários tipos de operações. Qual é a plataforma de nuvem primária para operar essa carga de trabalho?
  • Plataformas de operações adicionais: essa carga de trabalho também será gerenciada por plataformas de operações adicionais?
  • Requisitos de hospedagem em nuvem: essa carga de trabalho requer uma estratégia específica de hospedagem em nuvem? Nuvem pública, nuvem privada ou portabilidade em nuvem
  • Plataforma de orquestração padronizada: se a empresa tiver uma solução padrão para orquestração de contêineres, inclua o nome da plataforma padronizada a ser considerada. Exemplos: AKS (Serviço de Kubernetes do Azure), mecanismo do AKS ou Kubernetes.
  • Considerações sobre orquestração personalizada: há alguma exigência de uso de plataforma de orquestração de contêiner não padrão? Se houver, explique-a.
  • Operações de host padronizadas: supõe-se que as cargas de trabalho não sejam hostis e possam ser hospedadas em contêineres compartilhados com suporte por operações de host padronizadas. Essa carga de trabalho é compatível com tal abordagem?
  • Considerações sobre operações de host personalizadas: se a carga de trabalho não for compatível com operações padronizadas, quais requisitos específicos devem ser considerados ao estabelecer práticas de operações de host para essa carga de trabalho?

Considerações sobre o aplicativo:

Considerações específicas sobre como o aplicativo é desenvolvido hoje e será no futuro.

  • Tempo de execução de PaaS (plataforma como serviço) : provedores de nuvem pública produzem tempos de execução de aplicativo consistentes, geralmente chamados de ofertas de PaaS (plataforma como serviço). No Azure, são os tempos de execução de PaaS fornecidos pelo Serviço de Aplicativo do Azure. Esse aplicativo pode operar em um tempo de execução de PaaS? Qual tempo de execução é mais compatível?
  • Tempo de execução padronizado: se o aplicativo não for compatível com um tempo de execução de PaaS, há um tempo de execução padronizado fornecido pela organização? Em qual tempo de execução essa carga de trabalho será criada?
  • Considerações sobre tempo de execução personalizado: quais considerações específicas exigiriam um tempo de execução personalizado para essa carga de trabalho?
  • Restrições de tempo de execução: há alguma restrição imposta ao aplicativo pelo tempo de execução escolhido?
  • Dependências do aplicativo: essa carga de trabalho depende de sistemas existentes que residam em um local específico (como público ou privado)? Um exemplo é um sistema ERP, como o SAP, executado em uma solução específica.
  • Gravidade de dados: essa carga de trabalho depende de uma fonte de dados que resida em um local específico (como público ou privado)? Um exemplo é a dependência dos dados no SAP ou em outras fontes de dados centralizadas.
  • Considerações sobre listas aprovadas: as considerações sobre operações personalizadas são aprovadas para uso na sua plataforma de nuvem? Quais serviços aprovados devem ser incluídos na implantação?

Considerações para contêineres iniciais

O empacotamento de suas cargas de trabalho em contêineres é o primeiro conjunto do trabalho a ser agendado e trabalhado. O segundo é planejar a hospedagem desses contêineres.

Soluções de PaaS para tempos de execução, orquestração e operações padronizados

Algumas cargas de trabalho são altamente autossuficientes e não se beneficiam necessariamente dos controles avançados e dos requisitos de infraestrutura que acompanham uma plataforma grande, como o Kubernetes. O simples fato de sua carga de trabalho estar em contêineres não significa que ela deva ser implantada no Kubernetes. O Azure fornece várias soluções para execução de cargas de trabalho no seu portfólio que não exigem o nível de gerenciamento e infraestrutura imposto pelo AKS. As soluções a seguir seguem essa abordagem de planejamento:

Considere o uso de uma solução mais leve para seus contêineres com cargas de trabalho cuja complexidade você não espere aumentar e que se alinhem com as finalidades e os limites dessas soluções.

Orquestração padronizada com tempos de execução e operações personalizados na nuvem pública

Para essas cargas de trabalho que não podem ser executadas em uma plataforma PaaS totalmente gerenciada e devem retransmitir em controles de nível de infraestrutura, o desejo de usar recursos avançados de implantação, como aqueles oferecidos por orquestradores de contêineres ou de esperar aumento em termos de complexidade modular aponta para o AKS (Serviço de Kubernetes do Azure). O AKS resolve a hospedagem de contêiner e também fornece amplas opções de arquitetura, SRE, segurança, implantação, monitoramento e infraestrutura.

O conjunto de recursos da plataforma exige o aprendizado da plataforma, nos níveis do operador de cluster e da carga de trabalho. Inclua a educação das suas equipes de operações, arquitetura e engenharia de carga de trabalho nas linhas do tempo da migração. Além disso, como o AKS é uma plataforma, certifique-se de que as equipes de cargas de trabalho entendam a separação de responsabilidades nessa plataforma em relação à sua organização de hospedagem atual. Pode haver alguma semelhança, mas, provavelmente, haverá pontos novos.

Orquestração personalizada, tempos de execução e operações na nuvem pública

No caso de cargas de trabalho muito especializadas ou de requisitos organizacionais específicos, o Azure oferece duas outras plataformas principais no espaço de orquestração de contêineres.

  • Red Hat OpenShift no Azure
  • Azure Service Fabric

Se houver motivo para explorar alternativas, certifique-se de que haja tempo alocado para que todos entendam os custos e benefícios de todas as opções da plataforma. A solução padrão do Azure é o AKS e essa documentação presume que o AKS seja a tecnologia escolhida.

Padronizar operações em plataformas de nuvem

Frequentemente, os clientes implantarão diferentes orquestradores de contêiner em ambientes de nuvem privada, borda e nuvem pública. Para padronizar as operações nessas diferentes plataformas de nuvem, os clientes podem incorporar uma abordagem de operações unificadas estendendo suas ferramentas de operações de nuvem para várias plataformas de nuvem.

No Azure, as organizações podem padronizar operações entre vários orquestradores integrando diferentes hosts de contêiner ao Azure Arc para Kubernetes. Essa ferramenta garante monitoramento, operações e governança consistentes em cada host de contêiner.

Tempos de execução de aplicativo em ambientes de nuvem privada e de borda

Quando as cargas de trabalho devem ser executadas em ambiente de borda ou nuvem privada, mas há melhor suporte por parte de um tempo de execução de PaaS, algumas ferramentas permitem que os desenvolvedores criem com base em tempos de execução de PaaS consistentes usando o Serviço de Aplicativo do Azure:

  • Azure Stack HCI: permite hospedar o Serviço de Aplicativo do Azure no Azure Stack, gerenciado pelo operador do Azure Stack dados.
  • Azure Stack HCI para AKS: permite hospedar tempos de execução personalizados executados no AKS no Azure Stack, gerenciados por operadores do Azure Stack e do AKS para permitir a portabilidade para outras soluções do Kubernetes.
  • Serviço de Aplicativo do Azure no Kubernetes com Azure Arc: permite que qualquer host do Kubernetes forneça serviços de aplicativo no Azure. Todos os hosts se tornam uma pequena instância Serviço de Aplicativo do Azure. Como cada host também é integrado ao Azure Arc, eles também podem ser gerenciados por meio de operações de host consistentes baseadas em nuvem.

Plano de preparação da plataforma de aplicativos moderna

Além do plano de habilidades de adoção da nuvem, talvez as equipes de adoção da nuvem precisem desenvolver habilidades relacionadas ao contêiner e ao Kubernetes antes de executá-lo:

Certifique-se de que haja tempo alocado para que as equipes de carga de trabalho documentem e simulem planos de migração. Talvez o atual aplicativo ou sistema externo (dependências e sistemas que dependem dessa carga de trabalho) precise ser modificado e ganhar flexibilidade para oferecer suporte ao esforço de migração. Isso é verdadeiro para ambientes de produção e de pré-produção.

Próxima etapa: Examinar seu ambiente ou sua zona de destino do Azure

A lista de artigos a seguir fornecerá diretrizes sobre pontos específicos no percurso de adoção da nuvem para ajudar você a ter êxito nesse cenário.