Refatorar zonas de destino

Uma zona de destino é um ambiente para hospedar suas cargas de trabalho, pré-provisionadas por meio de código. Como a infraestrutura da zona de destino é definida no código, ela pode ser refatorada igual a qualquer outra base de código. Refatoração é o processo de modificar ou reestruturar o código-fonte para otimizar a saída desse código sem alterar sua finalidade ou função principal.

A metodologia Pronta usa o conceito de refatoração para acelerar a migração e remover bloqueadores comuns. As etapas na visão geral pronta abordam um processo que começa com o modelo predefinido de zona de destino que se alinha melhor à sua função de hospedagem. Em seguida, refatore ou adicione ao código-fonte para expandir a capacidade das zonas de destino de entregar essa função por meio de segurança, operações ou governança aprimoradas. A imagem a seguir ilustra o conceito de refatoração.

Figura 1: refatoração da zona de destino.

Obstáculos comuns

Quando os clientes adotam a nuvem, as considerações da zona de destino são o único bloqueador mais comum à adoção e aos resultados de negócios relacionados à nuvem. Os clientes tendem a preferir um dos dois bloqueadores a seguir. Equipes variadas costumam preferir um desses dois bloqueadores, resultando em deadlocks culturais que dificultam a adoção.

Os dois bloqueadores primários têm base em uma crença, o ambiente de nuvem e os datacenters existentes devem ter, ou estar próximos de terem, a paridade de recursos em relação a operações, governança e segurança. Essa é uma meta de longo prazo inteligente. Mas a dificuldade vem do equilíbrio delicado entre o tempo para atingir essa meta e a velocidade necessária para fornecer resultados de negócios.

Bloqueador: agir cedo demais

Foram necessários anos e um esforço significativo para alcançar o estado atual de governança e operações de segurança no datacenter atual. Também houve a necessidade de fazer observações, obter aprendizado e personalização para atender às restrições exclusivas desse ambiente. Replicar esses mesmos procedimentos e configurações levará tempo. Atingir a paridade de recursos completa também pode resultar em um ambiente com desempenho abaixo do esperado na nuvem. Essa abordagem de paridade também costuma causar um gasto excessivo significativo e não planejado no ambiente de nuvem. Não tente aplicar os requisitos de estado atual a um ambiente de estado futuro como uma porta de estágio inicial. Essa abordagem raramente é lucrativa.

Figura 2: agir cedo demais é um bloqueador comum.

Na imagem acima, o cliente tem um objetivo de 100 cargas de trabalho em execução na nuvem. Para chegar lá, o cliente provavelmente implantará sua primeira carga de trabalho e, em seguida, suas dez primeiras cargas de trabalho antes de estar pronto para liberar uma delas para produção. Por fim, ele atingirá o objetivo do plano de adoção e terá um portfólio robusto na nuvem. Mas o X vermelho na imagem mostra onde os clientes geralmente ficam presos. Aguardar o alinhamento total pode atrasar a primeira carga de trabalho por semanas, meses ou até mesmo anos.

Bloqueador: agir tarde demais

Por outro lado, agir tarde demais pode ter consequências significativas em longo prazo sobre o sucesso da iniciativa de adoção da nuvem. Se a equipe aguardar até alcançar a paridade de recursos até a conclusão dos esforços de adoção, ela encontrará obstáculos desnecessários e precisará de vários escalonamentos para manter os esforços no caminho certo.

Figura 3: agir tarde demais é um bloqueador comum.

Assim como agir cedo demais, nessa imagem, o cliente aguarda muito tempo para alcançar a preparação empresarial entre zonas de destino. Ao aguardar muito tempo, o cliente ficará restrito com relação à quantidade de refatoração e expansão que pode fazer no ambiente. Essas restrições limitarão a capacidade de impulsionar o sucesso contínuo.

Como encontrar o equilíbrio

Para evitar esses bloqueadores comuns, sugerimos uma abordagem iterativa com base em um plano de adoção de nuvem bem-estruturado, que maximiza as oportunidades de aprendizado e minimiza o tempo até o sucesso dos negócios. A refatoração e os esforços paralelos são críticos para essa abordagem.

Aviso

Há muito pouca probabilidade de as equipes de adoção que têm um objetivo de médio prazo (dentro de 24 meses) de hospedar mais de mil ativos (aplicativos, infraestrutura ou ativos de dados) na nuvem alcançarem o sucesso usando uma abordagem de refatoração. A curva de aprendizado é muito alta e a linha do tempo é muito rígida para permitir abordagens orgânicas para a obtenção de habilidades. Um ponto de partida mais completo que exige menos personalização será um caminho melhor para atingir seus objetivos. Seus parceiros de implementação provavelmente poderão orientá-lo por uma abordagem melhor.

O restante deste artigo se concentrará em algumas restrições principais que podem capacitar uma abordagem de refatoração, minimizando o risco.

Teoria

O conceito de refatoração de uma zona de destino é simples, mas a execução requer um proteções adequadas. O conceito mostrado anteriormente descreve o fluxo básico:

• Quando você estiver pronto para criar sua primeira zona de destino, comece com uma zona de destino inicial definida por um modelo.
• Após a implantação dessa zona de destino, use as diretrizes nos artigos na seção Enhance da tabela de conteúdo para refatorar e adicionar à zona de destino inicial.
• Repita o processo de revisão e adição até que você tenha um ambiente pronto para a empresa que atenda aos requisitos aprimorados de suas equipes de segurança, operações e governança.

Abordagem de desenvolvimento

A vantagem de uma abordagem baseada em refatoração é a capacidade de criar caminhos de iteração paralela para o desenvolvimento. A imagem abaixo apresenta um exemplo de dois caminhos de iteração paralela: adoção de nuvem e plataforma de nuvem. Ambos progridem ao próprio ritmo, com risco mínimo de tornarem-se uma barreira aos esforços diários da equipe. O alinhamento no plano de adoção e proteções de refatoração pode levar a um acordo quanto aos marcos e a uma clareza das dependências do estado futuro.

Figura 4: Iteração paralela da zona de destino.

Nos caminhos de iteração de exemplo acima, a equipe de adoção de nuvem está migrando o portfólio de 100 cargas de trabalho para a nuvem. Em paralelo, a equipe da plataforma de nuvem concentra-se em permanecer à frente do plano de adoção de nuvem para garantir que o ambiente esteja preparado para essas cargas de trabalho.

Neste exemplo, as iterações planejadas são executadas da seguinte maneira:

• A equipe da plataforma de nuvem inicia os esforços de desenvolvimento implantando uma zona de destino inicial. Essa zona de destino permite que a equipe de adoção de nuvem implante e comece a testar sua primeira carga de trabalho.
• Para preparar-se para a próxima implantação da equipe de adoção de nuvem de 10 cargas de trabalho, a equipe da plataforma de nuvem trabalha antecipadamente para refatorar e adicionar um ambiente conectado, tratando a nuvem como uma rede de perímetro.
• Antes que a equipe de adoção possa liberar sua primeira carga de trabalho de produção, a equipe de segurança requer uma revisão de segurança. Embora a equipe de adoção implante suas 10 primeiras cargas de trabalho, a equipe da plataforma avança para definir e implementar requisitos de segurança.
• No momento em que a primeira carga de trabalho é liberada para a produção, ambas as equipes devem ter aprendizados suficientes para prepararem-se para um modelo de serviço compartilhado de prazo mais longo. A centralização das arquiteturas de serviço principais ajudará a alinhar a equipe de governança e de operações. A centralização dos serviços principais ajudará a preparar a equipe de adoção para dimensionar e lançar as próximas várias ondas de cargas de trabalho de produção.
• À medida que a equipe se aproxima da meta de migrar 100 cargas de trabalho, ela começa a se aproximar mais de um modelo de colaboração de centro de excelência de nuvem e da estrutura de equipe.

A configuração de um ambiente pronto para a empresa levará tempo. Essa abordagem não eliminará esse requisito. Em vez disso, essa abordagem foi projetada para remover as barreiras iniciais e criar oportunidades para que as equipes de plataforma e adoção aprendam juntas.

Proteções de refatoração da zona de destino

Todos os modelos de zona de destino inicial têm limitações. Proteções ou políticas durante a refatoração devem refletir essas limitações. Antes de iniciar um processo de refatoração da zona de destino, é importante entender os requisitos de longo prazo do plano de adoção de nuvem e a classificação das cargas de trabalho candidatas em comparação às limitações de modelo inicial.

Como exemplo de estabelecer proteções de refatoração, vamos comparar a abordagem de desenvolvimento no exemplo anterior e o blueprint da zona de destino de Migração da CAF.

• De acordo com as suposições do blueprint da zona de destino de Migração da CAF, essa zona de destino inicial não é projetada para dados confidenciais nem cargas de trabalho críticas. Esses recursos precisarão ser adicionados por meio de refatoração.
• Neste exemplo, vamos supor que o portfólio de 100 cargas de trabalho exigirá funcionalidades de hospedagem de dados críticos e confidenciais.

Para balancear esses dois requisitos concorrentes, a equipe de adoção e a equipe de plataforma vão chegar a um acordo e operar sob as seguintes condições:

• A equipe de adoção de nuvem priorizará as cargas de trabalho de produção que não têm acesso a dados confidenciais e não são consideradas críticas.
• Antes da versão de produção, a equipe de segurança e operações validará o alinhamento à política anterior.
• A equipe da plataforma de nuvem trabalhará com as equipes de segurança e governança para implementar uma linha de base de segurança. Depois que a segurança aprovar a implementação, a equipe de adoção será liberada para migrar as cargas de trabalho que têm acesso a alguns dados confidenciais.
• A equipe da plataforma de nuvem trabalhará com a equipe de operações para implementar uma linha de base de gerenciamento. Depois que a equipe de operações aprovar a implementação, a equipe de adoção será liberada para migrar cargas de trabalho com um nível maior de importância.

Neste exemplo, o conjunto de condições acordadas acima permitirá que a equipe de adoção comece a usar seu esforço de migração. Também ajuda a equipe de plataforma a moldar suas interações com outras equipes, pois elas são criadas para um ambiente pronto para a empresa de longo prazo.

Como cumprir os requisitos de longo prazo durante a refatoração

A seção da metodologia Pronta sobre o aprimoramento de sua zona de destino auxiliará na mudança para os requisitos de longo prazo. À medida que a equipe de adoção de nuvem progredir com seu plano de adoção, examine Expandir sua zona de destino para obter diretrizes para ajudar a tomar decisões e refatorar para cumprir os requisitos em evolução de várias equipes.

Figura 5: metodologias mais profundas que auxiliam uma iteração de zona de destino paralela.

Cada subseção de Expandir sua zona de destino é mapeada para uma das adições descritas na imagem acima. Além dessas expansões básicas, as metodologias mais aprofundadas (como de governo ou gerenciamento) dessa estrutura ajudarão a ir além das modificações básicas da zona de destino para implementar disciplinas de longo prazo.

Próximas etapas

Para começar a usar um processo de refatoração, comece usando as zonas de destino do Azure.

Zonas de destino do Azure