Li recentemente um bom artigo pela equipe de engenharia da Intuit, onde eles mencionaram um tópico interessante — bolha dupla. Em termos de nuvens, é um estado durante migração para nuvem ou transformação digital quando você paga por ambas as nuvens, sites de origem e de destino. Vamos discutir o quão comum isso é.
Um projeto padrão de migração para a nuvem consiste em um conjunto definido de etapas:
1. Justificativa de TI e comprovação de uma necessidade comercial. A justificativa pode ser evitar o bloqueio de fornecedor, ciclo de renovação de licença de hardware ou software de arrendamento de datacenter, velocidade de dimensionamento, TCO ou desconto de nuvem pública etc. Normalmente, quando há uma justificativa clara, não é um problema comprovar a necessidade comercial.
2. Definição do escopo do projeto. Nesta etapa, uma pessoa responsável (gerente de projeto) e aplicações/recursos específicos são definidos.
3. Fase de migração para a nuvem.
4. Post-mortem.
Falaremos apenas sobre p. 2 e 3 por enquanto. É normal que durante o processo de migração haja momentos em que você tenha recursos em execução em ambas as nuvens, de origem e de destino. Alguns dos recursos podem já ter sido migrados, alguns ainda podem estar em uma fila ou mesmo não definidos para migração e ainda em execução em uma nuvem de origem. Mas há um caso interessante quando você migra alguns recursos (em alguns casos, centenas ou milhares de máquinas) e precisa pagar por eles duas vezes.
Alcançar a eficácia gestão de custos é tudo sobre otimização e rastreamento. Com um conjunto de políticas, princípios e processos em vigor, as empresas podem apaziguar as partes interessadas e garantir que seus gastos com a nuvem permaneçam sob controle. Se sua conta de gastos com a nuvem for uma surpresa toda vez que você a receber, você simplesmente não está aproveitando todas as ferramentas de governança de custos disponíveis.
Quando as empresas definem o que mover para uma nuvem, geralmente pensam em categorias de aplicativos, departamentos ou recursos inteiros. Consultores ou fornecedores experientes em migração sempre aconselharão dividir os recursos em blocos de 30 a 50 VMs e migrar por fases. De um lado, isso reduz o risco, do outro lado, ajuda exatamente a estourar a bolha. O ideal é que um único aplicativo esteja em um bloco. Nesse caso, você pode migrar e testar toda a parte granular do seu sistema e evitar problemas de localidade de dados. Lembre-se de que o tráfego de nuvem entre regiões e de saída não é gratuito e é muito caro. É melhor pensar nisso antes de receber sua primeira fatura de nuvem 🙂
A causa raiz da bolha está em 'replicação -> teste' -> escopo de cutover. Quando você migra algum pedaço, leva algum tempo para replicar dados, definir como você vai pegar incrementos (melhor de forma automatizada), como testar o pedaço em uma nuvem de destino e agendar uma janela de manutenção para executar o cutover. E essas 3 fases formam a bolha. Você armazena os dados em dispositivos de bloco ou um armazenamento de objetos, executa VMs em uma nuvem de destino e paga pela computação. Na maioria dos casos, as migrações de teste podem ser executadas por 1 a 3 semanas (pode ser até mais) até que uma equipe que possui o aplicativo migrado valide que está tudo bem com ele em uma nuvem de destino e não há degradação de desempenho ou outros problemas. E se você migrar vários pedaços em paralelo, a bolha aumentará.
Então, como evitar a bolha…
1. Primeiro de tudo, identifique seu ritmo de migração. Seja muito franco consigo mesmo, é exatamente assim que se aprende uma nova habilidade — muito lento no começo e muito melhor depois de algumas iterações.
2. Defina uma fila de aplicações/pedaços. Coloque-a no calendário do seu projeto de migração.
3. Descubra uma maneira de replicar VMs sem tempo de inatividade e sem replicá-las novamente o tempo todo. Há dezenas de ferramentas fazendo isso e isso economiza seu tempo e dinheiro, pois você paga menos pelo armazenamento.
4. Comunique-se com as equipes que possuem os chunks ou aplicativos. Defina os critérios de aceitação e o processo de transição com eles, quanto mais cedo eles começarem a pensar sobre isso, mais preparados estarão quando chegar a hora. Defina os intervalos de tempo em que eles precisam testar a migração. Este é o passo mais importante, pois o teste estoura a bolha e, geralmente, as equipes não têm ideia de como testar os aplicativos, quais são os componentes e quem é o dono das máquinas individuais.
5. Defina o período de espera — quanto tempo você espera até remover as VMs migradas do ambiente de origem. Não se esqueça de que, por um lado, você precisa de algum plano de backup se algo der errado com as VMs e aplicativos em uma nuvem de destino e, por outro lado, você ainda paga (direta ou indiretamente) pelas máquinas em um lado de origem.
6. Encerre os testes assim que perceber que a equipe não está preparada ou que não é a prioridade deles, certo. Se eles não estiverem motivados, eles apenas perderão tempo (equivalente a dinheiro em nuvens públicas) ou, pior ainda, tomarão uma decisão (aceitar ou rejeitar) com base em algum critério estranho e, ou prosseguirão para usar as máquinas em uma nuvem de origem ou descobrirão que houve problemas quando as VMs de origem já teriam sido removidas. Reitere com seu gerente ou alta gerência para ajustar as prioridades de ambas as equipes.
7. Se os testes forem aprovados, prossiga com o cutover. Remova todos os snapshots e teste as migrações para os aplicativos migrados. Não se esqueça de iniciar o relógio de tempo de espera para eles.
8. Revise suas estimativas de ritmo e ajuste sua programação.
Você terá algum tipo de bolha dupla em qualquer projeto de migração, mas pode controlar o quão grande ela será por meio de planejamento e comunicação adequados com os proprietários de aplicativos e VMs. Somente pessoas corajosas migram toda a infraestrutura em uma única execução, pessoas inteligentes planejam e fazem isso em pedaços e fases.
