LONDRES — O papel do CTO da Fortune 500 pode ser o de bater a cabeça contra a parede. Não necessariamente nas empresas nativas de tecnologia que ocupam muitos dos primeiros lugares, mas para as 71% das empresas ainda usam mainframes, a frustração, a rotatividade e os orçamentos para a migração fracassada para a nuvem são altos. Estas empresas gigantescas demoram a competir e a inaudibilidade dos seus sistemas tornou-se um enorme risco de segurança. Mas avançar demasiado depressa poderá ter um efeito catastrófico nos fluxos de receitas.
A modernização de sistemas legados é uma indústria de bilhões de dólares com pouco fim à vista. O que impede as equipes de aproveitar os benefícios de DevOps, código aberto e nuvem? Como pode engenharia de plataforma e IA generativa ativar esse primeiro caso de uso e acelerar a partir daí?
Esquecer levantar e mudar e vá incremental Rob Mee, CEO da Mechanical Orchard, disse ao The New Stack. Continue lendo para começar a entender as falhas das tentativas de migração anteriores e como você pode tornar sua próxima migração corporativa para a nuvem a última.
O CTO médio da Fortune 500 está na casa dos cinquenta. Seu papel atual pode muito bem ser o último. Isso os deixa divididos entre querer ter aquela última sensação de realização e não querer balançar o barco. E com milhões de clientes, evitar interrupções é fundamental. Eles provavelmente já percorreram esse caminho de transformação digital antes – mais de uma vez. O seu ceticismo e frustração são completamente válidos.
No entanto, “se não está quebrado, não conserte” não é mais suficiente. A mudança é muito lenta, tornando difícil inovar na mesma velocidade das empresas nativas da nuvem. O tempo real é inacessível.
“Precisamos fazer isso porque esse negócio precisa evoluir”, disse Mee, falando de organizações com monólitos de 30, 40 ou 50 anos, com 10 milhões de linhas de código de mainframe e bilhões de entradas de banco de dados, onde é difícil recrutar alguém quem é treinado na tecnologia e o conhecimento legado já existe há muito tempo. Adicione a isso, Lei de Conway está de fato, o que significa que, durante décadas, a organização e sua comunicação cresceram na forma dessa complexa e gigantesca pilha de tecnologia.
Com uma média de 15 anos de experiência técnica, a empresa de modernização legada, nativa da IA generativa, Mechanical Orchard, sabe no que está se metendo quando entra no escritório do CTO ou do CIO.
“Eu me meti em problemas porque disse: ‘Aposto que sei por que você falhou’”, disse Mee, refletindo sobre uma conversa anterior com seu primeiro cliente, um varejista da Fortune 500, que agrupava dados em lote todas as noites, incapaz de desbloquear cliques. e coletar atualizações de inventário em tempo real. “Eles disseram: ‘Bem, já fizemos isso três vezes, então por que você não nos esclarece?’
Eles estavam certos em ficar frustrados. Raramente há um único ponto de falha quando uma grande consultoria não consegue migrar uma empresa para a nuvem. Mas Mee descobriu três maneiras comuns de falhar:
Cada um desses modos de falha tende a se prolongar por alguns anos antes que você possa realmente testar se está funcionando.
“Então é essa sensação de bater em uma parede – ou em várias paredes diferentes. Você pode ir em diferentes direções e tentar sair do labirinto. Há uma sensação de exaustão, mas ainda assim de alta pressão e alto risco”, disse Mee. “E neste momento o sentido de urgência passou de alto a agudo porque eles estão olhando para a IA generativa e percebendo que estão perdendo.”
Essas organizações também não conseguiram tirar proveito do código aberto, que, continuou ele, “acho que é a verdadeira evolução da produtividade do desenvolvimento neste século” e “no mundo da nuvem, você usaria código aberto para tudo. ”
Além de tudo isso, estão ficando sem gente que consiga manter o sistema, então tudo se torna frágil e urgente.
“Você tem uma organização que moldou a si mesma e vice-versa os sistemas durante décadas. Se você não consegue fundi-los ou fazê-lo em etapas, isso normalmente fica muito grande”, disse Mee. “Também há movimentação de dados. Normalmente, as pessoas fazem toda uma estratégia de migração de dados para esse tipo de coisa. Isso também se torna extraordinariamente complexo. E você está tentando apoiar a paridade nesta transformação. Os projetos acabam enfrentando uma série de complexidades em cascata que vão ficando maiores e elas (as migrações) acabam caindo em alguns anos.”
A maioria dessas organizações mais tradicionais migrou pouco ou nada porque sentem que precisam fazer tudo de uma só vez – um Big Bang lift and shift. Na melhor das hipóteses, eles encontraram uma maneira de criar novas unidades de negócios nativas da nuvem, mantendo os antigos mainframes para o trabalho original. Deixar tudo de alguma forma rodando em cima de algum tipo de software proprietário que não é mais suportado ou corrigido.
Outras organizações investem em ferramentas de tradução em larga escala.
“Você pode usar um compilador para arquivar um milhão de linhas de COBOL em um milhão de linhas de Java muito rapidamente, mas pode levar alguns anos para colocá-lo em produção e realmente funcionar”, disse Mee, refletindo sobre um cliente na área da cadeia de suprimentos que tentou isso. “Eles gastaram dois anos e meio e dezenas de milhões de dólares. E eles o ativaram e testaram a aceitação do usuário, e ele funcionou a cerca de um décimo da velocidade.”
“A coisa mais difícil para nós é superar o medo que o risco gera nas pessoas que olham para sistemas que processam muitas receitas. Isso está congelado há muito tempo. Eles têm medo de tocá-lo. Eles têm medo de que os fornecedores toquem nele. Eles podem ter falhado várias vezes.” – Rob Mee, Pomar Mecânico
Esta organização já tinha um número muito limitado de pessoas com experiência contextual com esse código. Mas depois que mudou de COBAL para Java gerado por máquina, ninguém o fez.
“Então essa arquitetura será muito parecida com uma arquitetura de mainframe em Java”, disse Mee. “Como mostra este exemplo, você o liga e pensa ‘Oh, droga, não funciona’, porque se você tivesse escrito nativo da nuvem, não o teria escrito dessa forma. Então acaba que você gasta dois anos para fazer funcionar. Então você provavelmente passará mais alguns anos ajustando-o e refatorando-o até o ponto em que as pessoas que precisam mantê-lo possam entendê-lo.”
Acrescente a isso, em sua experiência, várias organizações realmente grandes com as quais ele se encontrou perderam o código-fonte de pelo menos alguns de seus sistemas.
“Imagine ter um sistema que está literalmente congelado há 10 anos”, disse Mee. “O cliente diz: ‘Bem, falhamos. Os fornecedores falharam. O sistema é realmente intratável e é por isso que temos um congelamento de código.”
Mas, seguindo a rota do Big Bang, o risco é mitigado até o final do projeto. Mas, assim como o gerenciamento do projeto Waterfall que o construiu, esse é um risco cumulativo muito maior que pode explodir.
Hoje em dia, quando Mee se reúne com clientes em potencial, ele não brinca de adivinhar o seu fracasso. Em vez disso, ele pede que falem sobre seus cinco ou dez principais problemas tecnológicos. Em seguida, a equipe da Mechanical Orchard começa a analisar o comportamento do sistema legado com base na interceptação de entradas e saídas, a fim de reproduzir o sistema a partir daí de forma nativa da nuvem e de código aberto. Isso não significa que eles não usam o código-fonte quando disponível – esse não é o ponto de partida.
“O código-fonte é muito útil, mas o importante é que consideremos o sistema em execução e seus fluxos de dados como realmente a fonte da verdade”, explicou Mee. “Com isso, podemos deixar para trás o código deles com relativa facilidade”, porque, nesses sistemas de gerações antigas, há muito código que não é mais usado ou que nunca foi executado.
Diferente da última empresa que ele fundou, a Pivotal, que se concentrava em fornecer serviços de qualificação de clientes, a equipe da Mechanical Orchard está na verdade construindo e executando esses sistemas empresariais. Ele disse: “Estamos nos modernizando gradativamente e nunca fazendo um Big Bang. Estamos pegando fatias e indo até a produção.”
Em vez desse levantamento e mudança, eles começam com um piloto, na tentativa de mostrar o progresso com antecedência e frequência. Eles pegam sua primeira fatia do monólito – o grande ponto problemático que é mais facilmente isolado em comparação com aquele que talvez tenha centenas de integrações. Eles reproduzem essa peça em um ambiente de teste em área restrita e, em seguida, observam o que ela faz, aproveitando a IA generativa para interrogar e como os dados fluem através dela. Em seguida, eles fazem engenharia reversa dessa peça para construí-la com as mesmas entradas e saídas, mas de maneira nativa da nuvem.
As organizações mais antigas são naturalmente avessas ao risco. Em vez de quebrar diretamente os pedaços para migrar para a nuvem, a equipe de Mee inicialmente evita completamente a produção, aproveitando um ambiente de teste para eliminar variáveis e a necessidade de orquestrar entre os dois sistemas. A única coisa que permanece igual são os dados da organização. Cabe à equipe de Mee verificar se eles podem produzir os mesmos resultados com o novo código nativo da nuvem.
“Vamos mostrar o formato moderno, demonstrar que ele faz a mesma coisa que o sistema existente, e faz isso de maneira muito eficaz e eficiente”, disse Mee.
A próxima etapa é enviar essa nova peça nativa da nuvem para produção. Somente retirando-o da sandbox e colocando-o em produção é que eles serão capazes de enfrentar os riscos reais do ambiente empresarial. “Temos que lidar com segurança. Temos que lidar com redes. Temos que lidar com todos os DBAs. Temos que superar todos os obstáculos organizacionais.”
Este não é um caminho mais rápido para a nuvem – muita tecnologia precisa ser construída – mas é um caminho com resultados mais rápidos, geralmente dentro de um trimestre. Depois de levarem a primeira peça para produção, sua contraparte legada pode ser encomendada. Mas, novamente, não pode ser uma mudança. Enquanto a Mechanical Orchard controla o CloudOps, o resto envolve muita coordenação com o cliente DevOps equipe. Envolve muito trabalho de orquestração, disse Mee, “mas se você pretende implantar de forma incremental e abordar os riscos antecipadamente, você tem que fazer isso, trabalhar para que a orquestração realmente aconteça”.
Na verdade, até agora eles descobriram que as organizações querem executar o que construíram em paralelo por muito mais tempo do que o necessário, garantindo que os usuários finais não percebam nenhuma mudança e que a mudança não atrapalhe sistemas a jusante.
Eles ainda não concluíram a migração para a nuvem, mas hoje têm vários componentes em produção.
Mee disse que este plano de migração peça por peça “nos permite enfrentar os riscos antecipadamente e então começar a avançar cada vez mais rápido”.
YOUTUBE.COM/THENEWSTACK
A tecnologia avança rápido, não perca um episódio. Inscreva-se em nosso canal no YouTube para transmitir todos os nossos podcasts, entrevistas, demonstrações e muito mais.
SE INSCREVER
