Inventariando as Suas Atuais Cargas de Trabalho e Arquitetura

Recomendamos que você crie uma matriz de atributos organicamente. Comece pequeno e repita. Se possível, limite inicialmente o escopo dos aplicativos que estão sendo considerados.

Este é o processo geral a ser seguido:

1. Crie uma matriz de aplicativos com base nos principais atributos desses aplicativos. Se os aplicativos fizerem parte da mesma suíte de arquitetura, você poderá avaliá-los como grupo. Em seguida, identifique uma lista finita de valores para cada atributo.

2. Repita a matriz de aplicativos, atributos e valores de atributo.

   Ao repetir, você pode identificar novos atributos, combiná-los ou modificar os valores de um atributo. Você também pode ajustar a lista de aplicativos ou a forma de agrupá-los. Por exemplo, você pode definir inicialmente um atributo de latência como tendo um valor de alta latência, latência média ou baixa latência. Após uma avaliação mais detalhada, você decide que seus requisitos de latência sejam mais bem definidos como colocalizados versus tolerante a remoto.

   Sua matriz deve ser descritiva o suficiente para fornecer suporte significativo para que você tome decisões de arquitetura e migração, mas pequena o suficiente para se encaixar no espaço de decisão cognitiva. Se o escopo de sua avaliação for todo o portfólio de TI de sua organização, considere a criação de uma matriz consolidada de nível mais alto.

3. Defina o escopo inicial dos aplicativos a serem avaliados.

   Você terá de avaliar todas as cargas de trabalho que planeja migrar. No entanto, para as primeiras repetições, priorize um subconjunto de cargas de trabalho a serem avaliadas. O ideal é que suas metas comerciais identifiquem aplicativos específicos ou objetivos direcionados que possam ajudar você a decidir quais aplicativos priorizar.

4. Examine o conjunto completo de aplicativos.

   Reavalie os atributos existentes no contexto do conjunto completo de aplicativos que você planeja migrar. Se você identificar informações importantes que exijam consideração adicional, adicione-as à matriz. Por exemplo, você pode encontrar uma dependência de dados por causa de detalhes de latência ou integração que não faz parte do escopo inicial. Como outro exemplo, você pode identificar uma tecnologia-chave legada que exige um esforço dedicado para planejamento de retirada ou migração ; portanto, exige uma avaliação mais profunda.

Use os atributos desta seção como ponto de partida para avaliar suas cargas de trabalho e arquitetura de plataforma existentes.

Dependendo das metas de negócios e dos aplicativos que você planeja migrar, alguns atributos podem ser mais relevantes do que outros. Recomendamos que você adapte a terminologia aos termos preferidos em sua própria organização. Muitas de suas restrições e metas de negócios existentes serão refletidas nesses atributos.

Avalie a função estratégica:

• Por exemplo, aplique uma versão do modelo de contexto/núcleo de Geoffrey Moore ao seu portfólio de TI. Identifique recursos como de missão crítica e não de missão crítica. Aplique um segundo label para identificar recursos como diferenciais ou operacionais.

  • Se seus objetivos de negócios enfatizarem a inovação, sua arquitetura inicial deverá se concentrar em aplicativos diferenciais, mas não críticos ainda.

  • Se seus objetivos de negócios enfatizarem a eficiência operacional, sua arquitetura deverá focar em aplicativos operacionais de missão crítica.

Entenda o roteiro para aplicativos de terceiros:

• Você entende o roteiro de fornecedores de cada tecnologia de terceiros em sua pilha atual, incluindo rede, computação e armazenamento?

• Um aplicativo de terceiros está no fim da vida útil?

• Um aplicativo de terceiros pode continuar com um upgrade?

• Sem se aprofundar em arquiteturas futuras, o Oracle Cloud Infrastructure oferece uma versão de nuvem? O fornecedor de terceiros oferece uma versão de nuvem do Oracle Cloud Marketplace?

Identifique quaisquer recursos exclusivos relacionados a tecnologia, implantação e operações nas principais dimensões não funcionais:

• Segurança. Por exemplo, há recursos de mascaramento de dados internos?

• Conformidade. Por exemplo, há suporte integrado para requisitos do PCI (setor de cartões de pagamento)?

• Resiliência. Por exemplo:

  • A camada de aplicativos pode ser clusterizada?

  • O armazenamento é automaticamente redundante?

  • Você confia na migração ao vivo para dar suporte à continuidade dos negócios?

• Governança e operações. Por exemplo, há integração direta com ferramentas de SDLC (ciclo de vida de desenvolvimento do software) ou controles de monitoramento externos?

• Eficiência. Por exemplo:

  • As plataformas de virtualização, como VMware, estão em sua pilha?

  • Você tem outro compartilhamento de computação, armazenamento ou banco de dados em vigor? Se você tiver servidores de banco de dados compartilhados executando vários aplicativos, um valor de atributo será implantação de banco de dados compartilhado.

• Automação. Por exemplo:

  • Qual é o nível de automatização do seu modelo de criação/implantação/operação?

  • Quais ferramentas são usadas?

Identifique áreas funcionais compartilhadas, dados compartilhados e outros componentes comuns e entenda como seus aplicativos suportam a integração:

• Um aplicativo suporta várias linhas de negócios, funções de usuário ou processos de negócios?

• Quais origens de dados são compartilhadas? Alguma infraestrutura é compartilhada? Por exemplo:

  • Seus aplicativos são executados em um host compartilhado por motivos que não sejam eficiência operacional ou pacote de bin?

  • Como seus componentes de rede são compartilhados? Por exemplo, se os segmentos de rede se ajustarem à continuidade dos negócios entre sites, os detalhes da rede poderão ser um atributo relevante.

  • Qual sistema você usa para gerenciamento de identidades? Se sua organização usar vários sistemas ou origens de gerenciamento de identidades, o sistema de identidades poderá ser um atributo relevante.

• Como funções, dados e componentes compartilhados se integram entre si? Por exemplo:

  • Integração síncrona versus integração assíncrona.

  • Alto volume versus baixo volume.

  • Qual é o método de integração? Por exemplo, links de entrada e links de saída, componentes de middleware.

Avalie outras características de arquitetura ou design não funcionais. Considere áreas em que as opções de implantação e arquitetura ofereçam componentes em vez de recursos técnicos ou de plataforma.

• Volume de alteração de dados e simultaneidade. Por exemplo:

  • Novos dados líquidos versus atualizações em dados existentes poderão ser relevantes se um sistema executar, na maioria das vezes, uma operação ou outra. Por exemplo, um data lake pode ter um alto volume de novos dados sendo adicionados, enquanto um cache de locais do GPS atuais pode ter um alto volume de dados sendo atualizados.

  • Simultaneidade de aplicativos e número de clientes.

  • Dependendo de seus aplicativos, considere dados transacionais, dados de referência e dados analíticos.

• Dimensionamento. Por exemplo:

  • Sua arquitetura atual aumenta e diminui com base em um ciclo de demanda recorrente ou picos inesperados de demanda?

  • Qual é o mecanismo de dimensionamento?

• Confidencialidade de dados ou preocupações especiais com a conformidade. Por exemplo:

  • As cargas de trabalho incluem dados que estão sujeitos a regulamentos de PCI ou HIPAA (Health Insurance Portability and Accountability Act)?

  • Os dados armazenados ou processados estão sujeitos aos requisitos de residência de dados, como o GDPR (Regulamento Geral de Proteção de Dados)?

• Práticas operacionais resilientes. Por exemplo:

  • Algumas cargas de trabalho são transferidas por failover para outro local em resposta a incidentes específicos, enquanto outras simplesmente entram em um estado "inativo"? Algumas camadas de aplicativos ou bancos de dados usam clusters de failover. Alguns aplicativos que não possuem failover automatizado podem ter automação total de reconstrução. Para outros aplicativos, o processo de recuperação pode ser totalmente manual.

  • Identifique um número limitado de padrões em relação aos modos de falha específicos de seus aplicativos.

• Custos operacionais. As camadas de custo podem ser aproximadas e não exatas. Exemplo de áreas a serem consideradas:

  • É necessário algum appliance exclusivo?

  • Qual o custo de mão de obra? A mão de obra é geralmente alocada; assim, pode ser difícil capturar números exatos, mas considere estimativas para uma matriz agregada ou resumida.

  • Sua pilha de tecnologia inclui licenças ou suporte premium de terceiros? Em caso afirmativo, as licenças de terceiros ou o suporte são portáteis?

  • Existem eficiências compartilhadas que são importantes destacar? Por exemplo, considere a tecnologia de virtualização, como VMware ou aplicativos baseados em contêiner que compartilham servidores.

Você pode identificar atributos adicionais a serem considerados. Recomendamos que você gerencie o escopo de sua análise para evitar ficar sobrecarregado.

À medida que repetir, ajuste sua matriz de aplicativos, atributos e valores de atributo atuais com base no entendimento de seu cenário de tecnologia existente, suas metas de negócios e seus planos de adoção da nuvem, incluindo o mapeamento da arquitetura atual para a arquitetura planejada.

Defina os atributos de sua arquitetura de nuvem planejada e das cargas de trabalho.