Planear plataformas de aplicações modernas

  • Artigo

A Metodologia de plano do Cloud Adoption Framework ajuda a criar um plano geral de adoção da cloud para orientar os programas e equipas envolvidos na sua transformação digital baseada na cloud. Esta documentação de orientação fornece modelos para criar o registo de tarefas pendentes e planos para criar as competências necessárias nas suas equipas, tudo com base no que está a tentar fazer na cloud.

A aplicação da metodologia de Plano centra-se nos cinco Rs da racionalização do seu património digital. O caminho mais comum para a cloud centra-se na velocidade, eficiência e repetibilidade dos processos de migração e modernização. A partir dos cinco Rs, o planeamento geralmente dá prioridade às opções de realojamento com suporte paralelo limitado para opções de rearquiteção e reconstrução.

Património digital

Ao planear o seu património digital, vai querer recolher dados de inventário e racionalizar o seu património. Num plano de adoção de contentores, todos os recursos, por exemplo VMs, dados e aplicações, são agrupados pela carga de trabalho que suportam. Assim que o agrupamento e a racionalização básica estiverem concluídos, pode avaliar estas cargas de trabalho para determinar as opções de pacote e realojamento ou rearquiteção.

O modelo de plano de adoção da cloud padrão representa os tipos de trabalho necessários num esforço típico de adoção da cloud. Mas terá de adicionar tarefas ao seu plano para empacotar a carga de trabalho em contentores e orquestração do aprovisionamento de contentores.

Atenção

Este artigo pressupõe que o leitor já está a seguir as melhores práticas descritas na série de artigos sobre a criação de um plano de adoção da cloud no Azure DevOps. Se estiver a controlar o seu plano de adoção da cloud na folha de cálculo ou noutras ferramentas de controlo de projetos, as secções seguintes continuam a ser aplicáveis, mas os passos acionáveis para adicionar dados ao seu plano terão de ser ajustados.

Aviso

Incorporar uma estratégia moderna da plataforma de aplicações em processos de migração padrão (ou numa fábrica de migração) exigirá a implementação madura de tarefas associadas à conceção de arquiteturas de cargas de trabalho antes da migração. Continuar com esta estratégia sem essas tarefas atrasará o esforço de migração e poderá levar a más decisões de arquitetura para os anfitriões de contentores implementados e cargas de trabalho de suporte.

Identificar cargas de trabalho candidatas

No cenário moderno da plataforma de aplicações, os retornos a longo prazo, que requerem um maior investimento inicial, são priorizados em relação a processos de migração mais eficientes. Os investimentos a longo prazo são representados em partes específicas do plano como um maior foco na ativação da inovação e na simplificação das operações para grupos específicos de cargas de trabalho.

Para começar a alinhar a estratégia e o plano, identifique quaisquer cargas de trabalho que possam ser afetadas pela adição de plataformas de aplicações modernas na sua estratégia de adoção da cloud. Esses pressupostos serão validados antes de implementar quaisquer alterações técnicas. Para ajudar na identificação de potenciais candidatos, procure os seguintes critérios no seu portefólio de cargas de trabalho:

  • Desenvolvimento ativo ou investimentos de DevOps: Uma percentagem das cargas de trabalho de produção estará em desenvolvimento ativo. Alguns podem até ser geridos através de práticas de DevOps em curso.
  • Portabilidade da carga de trabalho: Algumas cargas de trabalho são afetadas pela conformidade, proteção de dados ou restrições operacionais que podem exigir portabilidade em vários fornecedores de cloud pública, edge ou mesmo em nuvem privada.
  • Consolidação da carga de trabalho: Muitas cargas de trabalho (especialmente cargas de trabalho de baixa utilização) podem ser candidatas à consolidação em anfitriões de contentores, o que resulta em poucos servidores/VMs e custos operacionais reduzidos.
  • Cargas de trabalho legadas: As cargas de trabalho legadas podem bloquear atualizações para sistemas operativos e até mesmo impedir a migração para a cloud. As cargas de trabalho legadas que não são compatíveis com as funcionalidades do Azure podem ser candidatas à migração num anfitrião de contentores.

Documentar cargas de trabalho candidatas

Nota

A seguinte lista de considerações só deve ser documentada para candidatos de migração identificados pelos critérios acima.

Ao criar um plano de adoção da cloud, cada carga de trabalho é documentada ao seguir as orientações em Definir e atribuir prioridades a cargas de trabalho. Qualquer carga de trabalho que seja candidata ao cenário moderno da plataforma de aplicações exigirá informações adicionais para orientar a execução do plano. Este artigo realça a importância de documentar entradas empresariais e técnicas para definir a carga de trabalho. Para candidatos à plataforma de aplicações modernas, os seguintes pontos de dados devem ser adicionados à definição da carga de trabalho.

Entradas empresariais

Seguem-se pontos de dados relacionados com a empresa que podem influenciar a decisão de incluir uma carga de trabalho na estratégia moderna da plataforma de aplicações.

  • Controladores de conformidade: Que critérios de conformidade específicos são as considerações de orientação para alojar esta carga de trabalho numa nuvem privada?
  • Controladores de proteção de dados: Que medidas de proteção de dados estão a impulsionar as considerações para alojar esta carga de trabalho numa nuvem privada?
  • Restrições operacionais: Que restrições operacionais estão a impulsionar as considerações para alojar esta carga de trabalho numa nuvem privada?
  • Resultados modernos da plataforma de aplicações: Qual das seguintes opções é o fator subjacente à avaliação desta carga de trabalho como um candidato a contentor? DevOps, portabilidade, consolidação, legado ou vários destes controladores.
  • Modelo operacional: Esta carga de trabalho será gerida centralmente (por TI/CCoE central), des centralmente (por equipa de carga de trabalho) ou com operações empresariais (operações específicas de suporte central e carga de trabalho)?

Entradas técnicas

Seguem-se pontos de dados das equipas tecnológicas que podem influenciar a decisão de incluir uma carga de trabalho na estratégia moderna da plataforma de aplicações.

Considerações de localização:

Considerações relacionadas com o local onde a carga de trabalho será alojada.

  • Requisito de alojamento na cloud pública: Existe alguma restrição técnica específica associada ao requisito de cloud pública?
  • Requisito de alojamento na nuvem privada: Existe alguma restrição técnica específica associada ao requisito de nuvem privada?
  • Requisito de alojamento do Edge: Existe alguma restrição técnica específica associada ao requisito de limite?
  • Requisito de portabilidade: Existe alguma restrição técnica específica associada ao requisito de portabilidade da cloud?

Considerações sobre operações:

Considerações relacionadas com as operações da plataforma, anfitriões e cargas de trabalho.

  • Plataforma de cloud primária: As organizações devem definir uma plataforma de cloud primária para fornecer ferramentas de gestão de operações. Algumas organizações podem ter mais do que uma plataforma de cloud primária para gerir vários tipos de operações. Qual é a plataforma de cloud principal para operar esta carga de trabalho?
  • Plataformas de operações adicionais: Esta carga de trabalho também será gerida por plataformas de operações adicionais?
  • Requisitos de alojamento na cloud: Esta carga de trabalho requer uma estratégia de alojamento na cloud específica? Cloud pública, cloud privada ou portabilidade da cloud
  • Plataforma de orquestração padronizada: Se a empresa tiver uma solução padrão para orquestração de contentores, inclua o nome da plataforma padronizada a considerar. Exemplos: Azure Kubernetes Service (AKS), motor AKS ou Kubernetes.
  • Considerações de orquestração personalizadas: Existe um requisito para uma plataforma de orquestração de contentores não padrão? Se for o caso, explique esse requisito.
  • Operações de anfitrião padronizadas: Presume-se que as cargas de trabalho não são hostis e podem ser alojadas em contentores partilhados suportados por operações de anfitrião padronizadas. Esta carga de trabalho é compatível com esta abordagem?
  • Considerações sobre operações de anfitrião personalizadas: Se a carga de trabalho não for compatível com operações padronizadas, que requisitos específicos devem ser considerados ao estabelecer práticas de operações de anfitrião para esta carga de trabalho?

Considerações sobre a aplicação:

Considerações específicas sobre como a aplicação é desenvolvida e será desenvolvida daqui para a frente.

  • Runtime de plataforma como serviço (PaaS): Os fornecedores de cloud pública produzem runtimes de aplicações consistentes, muitas vezes referidos como ofertas de plataforma como serviço (PaaS). No Azure, os runtimes PaaS fornecidos pelo Serviço de Aplicações do Azure. Esta aplicação pode funcionar num runtime PaaS? Que runtime é mais compatível?
  • Runtime padronizado: Se a aplicação não for compatível com um runtime PaaS, existe um runtime padronizado fornecido pela organização? Em que tempo de execução esta carga de trabalho será criada?
  • Considerações sobre o runtime personalizado: Que considerações específicas exigiriam um runtime personalizado para esta carga de trabalho?
  • Restrições de tempo de execução: Existem restrições impostas à aplicação pelo runtime escolhido?
  • Dependências da aplicação: Esta carga de trabalho depende de quaisquer sistemas existentes que residam numa localização específica (como pública ou privada)? Os exemplos incluem um sistema ERP como o SAP em execução numa solução específica.
  • Gravidade dos dados: Esta carga de trabalho depende de uma origem de dados que reside numa localização específica (como pública ou privada)? Os exemplos podem incluir uma dependência dos dados no SAP ou noutras origens de dados centralizadas.
  • Considerações sobre a lista aprovada: As considerações sobre operações personalizadas estão aprovadas para utilização na sua plataforma na cloud? Que serviços aprovados têm de ser incluídos na implementação?

Considerações para contentores iniciais

Empacotar as cargas de trabalho em contentores é o primeiro corpo de trabalho que tem de ser agendado e trabalhado. A segunda é planear o alojamento desses contentores.

Soluções paaS para runtimes, orquestração e operações padronizadas

Algumas cargas de trabalho são altamente autónomas e não beneficiam necessariamente dos controlos avançados e dos requisitos de infraestrutura incluídos numa grande plataforma como o Kubernetes. Só porque a carga de trabalho está em contentores não significa que tenha de ser implementada no Kubernetes. O Azure fornece uma variedade de soluções para executar cargas de trabalho no seu portefólio que não requerem o nível de gestão e infraestrutura de que o AKS necessita. Cada uma das seguintes soluções seguiria esta abordagem ao planeamento:

Considere utilizar uma solução mais simples para os seus contentores com cargas de trabalho que não espera que cresçam em complexidade e que se alinhem com os objetivos e limites destas soluções.

Orquestração padronizada com runtimes personalizados e operações na cloud pública

Para as cargas de trabalho que não podem ser executadas numa plataforma PaaS totalmente gerida e têm de reencaminhar controlos ao nível da infraestrutura, pretender utilizar funcionalidades de implementação avançadas, como as oferecidas por orquestradores de contentores, ou esperar crescer em complexidade modular, passar para Azure Kubernetes Service (AKS). O AKS resolve o alojamento de contentores, mas também fornece extensas opções de arquitetura, SRE, segurança, implementação, monitorização e infraestrutura.

O conjunto de funcionalidades da plataforma inclui um requisito para aprender a plataforma tanto ao nível do operador de cluster como ao nível da carga de trabalho. Factor the education of your operations teams, architecture teams, and workload engineering teams into migration timelines( Ter em conta a educação das suas equipas de operações, equipas de arquitetura e equipas de engenharia de cargas de trabalho) nas linhas cronológicas de migração. Além disso, uma vez que o AKS é uma plataforma, as equipas de cargas de trabalho compreendem a separação de responsabilidades nesta plataforma em comparação com a sua disposição de alojamento atual. Pode ser semelhante em alguns aspectos, mas provavelmente será romance em outros.

Orquestração personalizada, runtimes e operações na cloud pública

Para cargas de trabalho muito especializadas ou requisitos organizacionais específicos, o Azure oferece duas outras plataformas importantes no espaço de orquestração de contentores.

  • Azure Red Hat OpenShift
  • Azure Service Fabric

Se houver razões para explorar alternativas, certifique-se de que o tempo é atribuído para compreender os benefícios e desvantagens de todas as opções de plataforma. A solução predefinida do Azure é o AKS e esta documentação pressupõe que o AKS é a tecnologia escolhida.

Uniformizar operações em plataformas na cloud

Muitas vezes, os clientes implementarão diferentes orquestradores de contentores em ambientes de cloud privada, edge e cloud pública. Para uniformizar as operações nessas diferentes plataformas na cloud, os clientes podem incorporar uma abordagem de operações unificadas ao expandir as suas ferramentas de operações na cloud para várias plataformas na cloud.

No Azure, as organizações podem uniformizar operações em vários orquestradores ao integrar anfitriões de contentores diferentes no Azure Arc para Kubernetes. Esta ferramenta garante uma monitorização, operações e governação consistentes em cada anfitrião de contentor.

Runtimes de aplicações em ambientes de cloud privada e edge

Quando as cargas de trabalho têm de ser executadas num ambiente de cloud ou edge privado, mas a carga de trabalho é suportada melhor por um runtime PaaS, existem algumas ferramentas que podem permitir aos programadores criar em cima de runtimes PaaS consistentes com Serviço de Aplicações do Azure:

  • Azure Stack HCI: Permite alojar Serviço de Aplicações do Azure nativamente no Azure Stack, gerido pelo operador do Azure Stack.
  • Azure Stack HCI para AKS: Permite o alojamento de runtimes personalizados em execução no AKS no Azure Stack, geridos pelos operadores do Azure Stack e do AKS para permitir a portabilidade a outras soluções do Kubernetes.
  • Serviço de Aplicações do Azure no Kubernetes com o Azure Arc: permite que qualquer anfitrião do Kubernetes forneça serviços de aplicações no Azure. Todos os anfitriões tornam-se uma pequena instância de Serviço de Aplicações do Azure. Uma vez que cada anfitrião também está integrado no Azure Arc, esses anfitriões também podem ser geridos através de operações de anfitrião consistentes baseadas na cloud.

Plano de preparação da plataforma de aplicações moderna

Além do plano de competências de adoção da cloud, as equipas de adoção da cloud poderão ter de desenvolver competências relacionadas com o contentor e o Kubernetes antes de executar o seu plano:

Certifique-se de que o tempo é atribuído às equipas de cargas de trabalho para documentar e executar planos de migração a seco. A aplicação existente ou o sistema externo (tanto as dependências como os sistemas que dependem desta carga de trabalho) podem ter de ser modificados com flexibilidade adicional para suportar o esforço de migração. Isto aplica-se tanto aos ambientes de pré-produção como aos ambientes de produção.

Passo seguinte: Rever o ambiente ou a zona de destino do Azure

A seguinte lista de artigos irá levá-lo à documentação de orientação em pontos específicos do percurso de adoção da cloud para o ajudar a ter êxito no cenário de adoção da cloud.