Por que Kubernetes é nosso COBOL moderno, diz especialista em tecnologia

22

A infraestrutura de hoje se torna o legado de amanhã, mas há maneiras de construir que evitem armadilhas.

Hoje temos um problema de COBOL, com muito (e muito) de código antigo andando por aí com menos (e menos) pessoas que sabem como lidar com isso. O COBOL já foi a infraestrutura “in”, executando os sistemas de backend de scads de instituições financeiras e governos. Agora seguimos em frente.

Da mesma forma, Mike Loukides, vice-presidente de estratégia de conteúdo da O’Reilly Media, sugeriu que o próximo “momento COBOL” da nossa indústria provavelmente envolverá Kubernetes. Com o tempo, ele observou, Kubernetes inevitavelmente será substituído por algo mais simples, deixando-nos responder à pergunta: “Quem manterá a infraestrutura que já depende dela?”

Infraestrutura como código

Esta “COBOLization” de código não é endêmica para todos os softwares. Por exemplo, Loukides usa o Fortran para desenhar uma distinção entre código que cria problemas de manutenção a longo prazo e código que não:

Fortran e COBOL são usados de formas fundamentalmente diferentes. Enquanto a Fortran foi usada para criar infraestrutura, o software escrito no Fortran não é a própria infraestrutura….Ninguém se importa mais com o código Fortran escrito nos anos 60, 70 e 80 para projetar novas pontes e carros. O Fortran ainda é muito usado na engenharia — mas esse antigo código se aposentou. Essas ferramentas mais antigas foram reformuladas e substituídas….[I]f todos os programadores fortran do mundo deveriam desaparecer magicamente, essas bibliotecas e aplicativos poderiam ser reconstruídos rapidamente em linguagens modernas — muitas das quais já têm excelentes bibliotecas para álgebra linear e aprendizado de máquina.

Publicações Relacionadas

O código de infraestrutura é diferente. Código COBOL escrito na década de 1960 ainda pode estar em uso – é a infraestrutura que construímos. O código fortran, como indicado por Loukides, não é tratado da mesma forma.

Então, qual é o nosso COBOL moderno? Para Loukides, a resposta é clara. É Kubernetes:

[C]ompanies estão movendo aplicações para a nuvem em massa. Além de simples elevação e mudança, eles estão refaatorizando aplicações monolíticas em sistemas de microsserviços, frequentemente orquestrados por Kubernetes….

[I]t é uma aposta segura de que muitos desses sistemas ainda estarão funcionando daqui a 20 ou 30 anos; eles são os “aplicativos legados” da próxima geração. A configuração de Kubernetes é complexa, uma especialidade distinta por si só. Se Kubernetes for substituído por algo mais simples (o que eu acho que é inevitável), quem manterá a infraestrutura que já depende dela? O que acontece ao aprender que Kubernetes não é o ingresso para o próximo trabalho ou promoção? Os arquivos YAML que configuram Kubernetes não são uma linguagem de programação completa como python; mas eles são código. O número de pessoas que entendem como trabalhar com esse código inevitavelmente diminuirá, e pode eventualmente se tornar uma “raça moribunda”. Quando isso acontecer, quem manterá a infraestrutura?

Isso não é motivo para alarme. A maioria das organizações está focada em modernizar seus sistemas existentes, em vez de olhar de 10 a 20 anos para o futuro, preocupando-se com a escassez de talentos que pode eventualmente alcançar suas decisões. E, sem dúvida, as empresas estão tomando uma decisão inteligente quando constroem com um padrão da indústria como Kubernetes. Sim, Kubernetes um dia será legado, com toda a escassez de talentos que vem com ele. Mas hoje, as organizações estão mais preocupadas com a escassez existente no talento de Kubernetes, à medida que buscam abraçar arquiteturas habilitadas para contêinerese microsserviços.

Que talvez seja a lição a tirar disso: construir o máximo de agilidade possível em sua infraestrutura atual, e deixar que o futuro cuide de si mesmo. O VP de tecnologia da Expedia, Subbu Allamaraju, colocou desta forma,falando de uma mentalidade semelhante que infecta aqueles que querem preservar a máxima liberdade de infraestrutura, cobrindo nuvem com investimentos de data center: “Para ter sucesso em escala em uma arquitetura híbrida e maximizar o valor do cliente, a eficiência de custos e a agilidade exige que você faça um grande número de decisões técnicas, pessoas e processos até anos antes necessário. Mesmo que você possa pagar por isso, você é [un]provável [para] obter estes direito.”

Ou ateou atenção ao advogado do analista da Duckbill Corey Quinn sobre este mesmo tema: “Ao construir um êxodo teórico, você paga pela opcionalidade com a velocidade do recurso e reduz suas chances de chegar a uma posição onde os custos de nuvem dependem até mesmo para o sucesso geral do seu negócio.”

Em suma, sim, o aglomerado kubernetes quente de hoje é provavelmente a infraestrutura herdeira cobol-esque de amanhã. Mas, para citar mal a Bíblia, “Não pense, portanto, para o amanhã: para o amanhã deve tomar o pensamento para as coisas de si mesmo. O suficiente até hoje é a infraestrutura herdadas.”

você pode gostar também