Para as empresas, a capacidade de migrar milhares de aplicativos é uma parte inevitável da competitividade. Descobrir como obter uma migração bem-sucedida é assustador, então vamos nos aprofundar nas armadilhas a serem evitadas. O COVID-19 criou uma escassez de talentos técnicos combinada com um aumento na demanda por cronogramas técnicos acelerados. Muitas empresas estão começando a enfrentar um efeito “ ”, onde as empresas estão tendo que redefinir como e onde estão competindo no mercado para garantir que permaneçam relevantes. Hoje, as empresas que permanecem complacentes são recompensadas com uma desvantagem mordaz e um ciclo perpétuo de recuperação. As migrações de tecnologias existentes para soluções mais responsivas e econômicas são uma parte significativa da metamorfose de qualquer empresa; no entanto, pode ser repleto de armadilhas para os despreparados. Rainha Vermelha De acordo com um estudo do Boston Consulting Group em 2020, que incluiu 825 executivos seniores em 70 empresas envolvendo 895 transformações digitais, apenas 30% das transformações atingiram suas metas de transformação. Esses não são números para inspirar confiança. Felizmente, empresas como a Stark & Wayne trabalharam para permitir várias migrações corporativas para que outras pessoas possam evitá-las. A Stark & Wayne é especialista em migração de infraestruturas de escala empresarial. Projetos anteriores incluíram implantações do que gerenciam 45.000 instâncias de aplicativos. Cloud Foundry Foundation Documente uma linha de base de desempenho É um mandato! Toda empresa exige melhor desempenho, mas muitas carecem de métricas básicas de desempenho ou formas de medir o que significa melhor desempenho. O desempenho está relacionado à experiência do usuário final? O desempenho é baseado na expansão e redução das cargas de trabalho para reduzir o consumo? O desempenho é medido em tempo reduzido para implantação ou atualização? Depois de estabelecer como medirá o desempenho, você poderá vinculá-lo aos seus aplicativos, clientes e negócios. Isso permitirá que você avalie se os aplicativos estão com baixo desempenho durante e após a migração. Também ajuda a gerenciar as percepções durante uma mudança significativa e ajuda a quantificar o sucesso. Você precisará comparar suas plataformas pré e pós-migração com cargas de trabalho semelhantes. O que você mede depende dos requisitos de negócios, mas algumas medidas genéricas são: Tempos de execução do componente Tempos de resposta do aplicativo Tempos gerais de execução do aplicativo Aplicativos de teste para validar a conectividade de componentes e acessibilidade de serviços API Metrics (carga de página, utilização de memória, CPU, desempenho do servidor) Carga de saída de log Carregamento de relatórios de incidência ao longo do tempo Automação (e trate a automação como um cidadão de primeira classe, porque melhorará o desempenho geral) Alterações no custo operacional devido à migração e automação de tarefas Teste com tipos de aplicativos que modelam seu ambiente. Bons painéis: você não pode migrar o que não pode encontrar A maioria das organizações sabe ao que está dando suporte agora, mas precisa identificar o que deseja oferecer suporte após a migração. Saber o número de instâncias do aplicativo é fácil, pois seu fornecedor provavelmente está cobrando de você com base nessa métrica. Ainda assim, você também precisará saber o número de aplicativos, quais equipes oferecem suporte aos aplicativos, quais aplicativos têm interdependências e quais tipos de serviços cada aplicativo está consumindo. A identificação dessas variáveis ajudará a determinar como você pode migrar e oferecer suporte ao novo ambiente. Ao mapear os proprietários de cada aplicativo, é essencial identificar quais deles possuem scripts de teste automatizados para validar o funcionamento do aplicativo. O ideal é que cada aplicativo tenha scripts de teste automatizados, mas, no mínimo, você precisa ter um mapeamento dos proprietários do aplicativo. Além disso, você precisará procurar por aplicativos não utilizados e sem manutenção. A última coisa que você deseja fazer é migrar um aplicativo não funcional (já vimos isso acontecer) quando o aplicativo precisar ser removido ou corrigido antes da migração. Um número surpreendente de vezes, você descobrirá que não existe um mapeamento mestre de proprietários de aplicativos, levantando problemas durante e após a migração. Portanto, o foco é “inventário, inventário, inventário”, já que muitas empresas não têm um local central que catalogue quem é o proprietário de cada aplicativo, o que cada aplicativo tem ou faz e qual é o impacto comercial do aplicativo. A capacidade de consultar rapidamente e encontrar informações relevantes é vital para operações, eficiência e tomada de decisões de negócios. Onde começar? Primeiro, responda às perguntas mais amplas: Em quais regiões você está rodando e por quê? Quais aplicativos estão sendo executados em cada região? Quais serviços cada aplicativo está usando em cada região? Qual versão do Linux está em uso? Quais aplicativos se comunicam com outros aplicativos em uma região? Quais aplicativos são voltados para o cliente versus internos? A coleta desses pontos de dados iniciais não responderá a todas as incógnitas, mas começará a fornecer os insights de que você precisa. Audite o que puder: e aceite o incognoscível Não importa o quão bem você audite ou documente cada detalhe, haverá variáveis desconhecidas que afetam o tempo de inatividade, clientes, colegas de trabalho, despesas e cronograma. Essas incógnitas só podem ser encontradas quando a equipe técnica colocar a mão na massa com o processo de migração. Veja como você pode apoiá-los: Adicione uma linha do tempo para incógnitas Tenha mais recursos disponíveis para ajudar quando um item desconhecido criar um problema Seja flexível com as políticas da empresa, reuniões internas e lançamentos de novos recursos Tenha planos de backup em vigor, como reversões, se os testes falharem Concentre-se primeiro nas pequenas vitórias para ganhar impulso enquanto planeja as grandes. Lembre-se, vitórias rápidas tangíveis podem ajudar o moral, desde que não causem mais sobrecarga operacional. O método preferido é realizar uma auditoria completa e documentar as estruturas e relacionamentos organizacionais e usá-los como referência ao longo do trabalho. Uma vez iniciado o projeto, esta documentação se tornará seu mapa e ajudará a evitar a despriorização ou a suspensão de itens. Você pode achar que a escalação para a gerência superior pode ser necessária para priorizar as ações que você precisa realizar. Ainda assim, a preferência deve ser entender como as equipes individuais trabalham e estabelecer uma boa comunicação com elas, em vez de passar por cima de suas cabeças. Segurança: leve a equipe SecOps para almoçar Não queremos dizer isso no estilo Tony Soprano “Leve-os para um passeio”; nós realmente queremos dizer levar a equipe de segurança para almoçar para estabelecer um relacionamento cara a cara. A equipe de segurança é vital para o processo de migração restringir, afrouxar ou fornecer soluções alternativas para os bloqueadores que surgirem. Você também precisa da revisão rápida de qualquer novo software necessário para tornar sua migração um sucesso. Uma equipe de segurança que for negligenciada será um bloqueador. Vamos enfrentá-lo com outra terrível analogia de filme, a segurança nunca quer ser o Cavaleiro Negro de Monty Python gritando: “Nenhum passará!” mas eles realmente querem cumprir o papel vital de manter tudo seguro. No final, a segurança quer capacitar todos dentro da organização, desde que haja diretrizes adequadas. Se você envolvê-los cedo, evitará dores de cabeça quando a segurança for acionada no último minuto. Resistir ao aumento do escopo: essa é uma ótima ideia… para o próximo ano O aumento do escopo precisa ser gerenciado com cuidado. Todas as organizações querem resolver seus problemas simultaneamente, mas você deve se concentrar em resolver um problema muito específico. Tomando como exemplo a mudança do Pivotal Cloud para o Cloud Foundry de software livre, os principais pontos fortes do Cloud Foundry são os muitos recursos que podem ser adicionados e o potencial de personalização. Por exemplo, melhorar a postura de recuperação de desastres e backups pode ser tentador, mas criar um escopo adicional cria pontos problemáticos adicionais. O aumento do escopo também cria um problema em que algo pode quebrar e você não pode ter certeza se a quebra foi causada pelo objetivo geral do projeto ou pelo escopo adicional. Espelhamento: correspondendo ao mundo que você quer deixar para trás Depois de estabelecer os parâmetros do seu projeto e os resultados desejados, você deve garantir que tenha espelhado todos os ambientes que serão migrados. Isso inclui seu ambiente de operações ou “playground”, onde você testará tudo antes, passando para a não produção e, finalmente, a produção. Ao construir o ambiente de playground, você vai querer garantir que a tecnologia atual, em nosso exemplo Pivotal, seja igual ao seu ambiente de não produção. Isso permitirá que você tenha mais confiança de que terá menos problemas. Questões de gestão: faça amigos em cargos importantes Você precisará do apoio da gerência, portanto, não pinte uma imagem totalmente cor de rosa. As migrações têm um longo caminho pela frente. Mover a plataforma é uma coisa, mas você também precisa lidar com todos os serviços. A gerência precisa conhecer sua abordagem para a migração e seu plano para mitigar o risco comercial. A gerência ficará nervosa, pois as migrações podem afetar os resultados, então você precisa discutir todas as suas medidas para evitar isso. Falhando bem: tornando-o um sucesso O fracasso é bom, o fracasso é ótimo e o fracasso deve ser esperado, desde que você implemente as lições aprendidas na próxima vez. Você não pode explicar tudo, e as falhas percebidas acontecem quando o desconhecido se torna um bloqueador. Espera-se que deixar a gerência saber que haverá falhas evitará as conotações negativas e melhorará o moral geral. Na verdade, você precisa comemorar os aprendizados com o fracasso porque está progredindo. Para vender que a falha é aceitável, você precisa de um plano alternativo claro. Tenha isso como parte de seu planejamento diário de migração com pontos de decisão ir/não ir para reverter. As taxas de licenciamento e os riscos são os principais motivadores da migração para o Open Source Cloud Foundry ou Kubernetes. Para grandes organizações que executam milhares de aplicativos, os riscos são de missão crítica. Com a crescente demanda por escala e escassez de desenvolvedores, as migrações parecem arriscadas. A principal preocupação é evitar o impacto nas equipes de aplicativos e evitar o tempo de inatividade. A boa notícia é que a Stark & Wayne realizou muitas migrações em escala empresarial bem-sucedidas que aderiram ao impacto mínimo do desenvolvedor e tempos de inatividade limitados a janelas de controle de alterações. Ao fatorar esses erros comuns que encontramos, é menos provável que seu próximo projeto se torne parte dos 70% que o Boston Consulting Group sugere que não obtêm o que esperam. Publicado também . aqui

fees

Read My Stories

Este áudio é produzido no idioma original da história!

Muito longo; Para ler

Developers: Build Less. Deliver More. [Learn how]	

Erros comuns a evitar ao migrar

Muito longo; Para ler

Company Mentioned

Norm Abramovitz

About Author

Rótulos

Languages

ESTE ARTIGO FOI APRESENTADO EM...

Erros comuns a evitar ao migrar

Muito longo; Para ler

Company Mentioned

Norm Abramovitz

About Author

Rótulos

Languages

ESTE ARTIGO FOI APRESENTADO EM...

HISTÓRIAS RELACIONADAS