 |
| Bellacosa Mainframe e a tecnica de cloud repatriation |
☕🏠☁️ CLOUD REPATRIATION — QUANDO AS EMPRESAS DESCOBREM QUE NEM TUDO DEVERIA TER IDO PARA A NUVEM
Se você é uma Analista COBOL Júnior, provavelmente cresceu ouvindo uma frase que parecia uma verdade absoluta:
"O futuro está na nuvem."
Durante mais de uma década, empresas do mundo inteiro migraram aplicações, bancos de dados, sistemas corporativos e ambientes inteiros para AWS, Azure e Google Cloud.
As apresentações dos fornecedores mostravam um cenário quase perfeito.
Tudo seria:
mais rápido;
mais moderno;
mais simples;
mais seguro;
mais barato.
Executivos ficaram encantados.
Arquitetos embarcaram na jornada.
Consultorias venderam projetos bilionários.
E milhares de empresas iniciaram aquilo que ficou conhecido como:
Cloud Migration.
Mas alguns anos depois algo inesperado começou a acontecer.
Empresas gigantes passaram a fazer o caminho inverso.
Sim.
O movimento contrário.
Retirar sistemas da nuvem.
Trazer aplicações de volta para datacenters próprios.
Mover cargas para ambientes especializados.
Consolidar plataformas.
Esse fenômeno ganhou um nome que talvez você escute cada vez mais nos próximos anos:
Cloud Repatriation.
Ou simplesmente:
Repatriação da Nuvem.
E para quem trabalha com Mainframe, COBOL e sistemas corporativos, entender esse conceito é fundamental.
Porque ele está mudando a forma como as empresas enxergam tecnologia.
O sonho da nuvem
Vamos voltar alguns anos.
Imagine uma empresa tradicional.
Ela possui:
servidores físicos;
storage;
rede;
datacenter;
equipe de infraestrutura.
Tudo precisa ser comprado.
Tudo precisa ser instalado.
Tudo precisa ser mantido.
Quando a nuvem chegou, a promessa parecia revolucionária.
Ao invés de comprar:
você alugaria.
Ao invés de esperar semanas:
criaria recursos em minutos.
Ao invés de investir milhões:
pagaria apenas pelo uso.
Parecia perfeito.
E para muitas situações realmente era.
O nascimento do "Cloud First"
Entre 2015 e 2022 surgiu uma expressão muito popular.
Cloud First.
Ou seja:
"A nuvem primeiro."
Toda nova solução deveria nascer em cloud.
Muitas organizações foram além.
Não apenas criaram sistemas novos.
Também migraram sistemas antigos.
Tudo virou candidato à nuvem.
ERP.
CRM.
Banco de dados.
Analytics.
Arquivos.
Aplicações críticas.
Em muitos casos sem uma análise profunda de custo-benefício.
A pergunta que ninguém fazia
Durante a fase de entusiasmo existia uma pergunta que poucos executivos faziam:
"Quanto isso custará daqui a cinco anos?"
A maioria analisava apenas:
velocidade;
facilidade;
inovação.
Mas ignorava:
crescimento;
consumo;
escalabilidade financeira.
A conta parecia pequena no início.
Mas crescia silenciosamente.
A armadilha do sucesso
Imagine uma fintech.
Primeiro ano:
100 mil clientes.
Segundo ano:
1 milhão.
Terceiro ano:
10 milhões.
Quarto ano:
50 milhões.
Tudo parece ótimo.
Mas existe um detalhe.
Cada cliente gera:
armazenamento;
processamento;
logs;
backups;
monitoramento;
tráfego de rede.
Quanto mais sucesso a empresa tem, maior fica a fatura.
O paradoxo é interessante.
O crescimento do negócio aumenta também o custo operacional da nuvem.
Quando chega a conta
É nesse momento que começa a repatriação.
Os diretores financeiros começam a fazer perguntas.
Por exemplo:
Estamos usando tudo que pagamos?
Precisamos realmente dessa configuração?
Existe alternativa mais barata?
O custo por transação está aumentando?
O retorno continua justificando o investimento?
E muitas vezes a resposta é surpreendente.
Nem toda carga de trabalho se beneficia economicamente da nuvem.
A analogia da casa
Uma das formas mais simples de entender Cloud Repatriation é imaginar um imóvel.
No começo você mora de aluguel.
Faz sentido.
Você ainda está começando.
Precisa de flexibilidade.
Não quer investir muito.
Mas imagine que passaram vinte anos.
Você continua pagando aluguel.
Todo mês.
Sem parar.
Em algum momento surge a pergunta:
"Não seria melhor comprar?"
A repatriação nasce exatamente dessa reflexão.
O caso do Dropbox
Um dos exemplos mais famosos ocorreu com o Dropbox.
Durante anos a empresa utilizou cloud pública.
Mas conforme cresceu percebeu algo importante.
O volume de armazenamento era gigantesco.
A escala era enorme.
A previsibilidade era alta.
O resultado?
Passou a investir fortemente em infraestrutura própria.
A economia foi medida em centenas de milhões de dólares ao longo dos anos.
Isso chamou a atenção do mercado.
O caso da 37signals
Outro exemplo muito discutido foi a empresa por trás do Basecamp.
Após anos utilizando cloud pública, seus executivos anunciaram um movimento de retorno para infraestrutura própria.
O argumento principal?
Economia.
Segundo eles, a redução de custos seria enorme.
A notícia gerou debates em toda a indústria.
O que isso ensina para uma Analista COBOL?
Ensina algo extremamente importante.
Tecnologia não é religião.
Não existe:
Mainframe bom.
Cloud ruim.
Nem o contrário.
Existe apenas:
o ambiente correto para a carga correta.
Essa é uma das maiores lições da arquitetura moderna.
Nem toda carga é igual
Imagine duas aplicações.
Primeira aplicação:
Website promocional.
Acessos variáveis.
Crescimento imprevisível.
Cloud faz sentido.
Agora imagine:
processamento de contas bancárias;
liquidação financeira;
batch noturno;
milhões de transações previsíveis.
Talvez a análise econômica seja diferente.
Talvez uma plataforma especializada seja mais eficiente.
Talvez um mainframe seja mais competitivo.
Tudo depende do contexto.
O papel do Mainframe nessa história
É aqui que muitos jovens profissionais ficam surpresos.
Durante anos ouviram que o Mainframe estava desaparecendo.
Mas a realidade mostrou algo curioso.
Enquanto algumas empresas tentavam migrar tudo para cloud, outras perceberam que certas cargas continuavam extremamente eficientes no IBM Z.
Por quê?
Porque o Mainframe foi construído justamente para:
alta escala;
alta disponibilidade;
processamento transacional;
confiabilidade extrema.
Essas características continuam valiosas.
Muito valiosas.
O custo invisível da nuvem
Uma Analista COBOL costuma enxergar claramente os custos de CPU e disco em ambientes tradicionais.
Na cloud surgem custos menos óbvios.
Por exemplo:
transferência de dados;
snapshots;
logs;
replicação;
monitoramento;
APIs;
tráfego entre regiões.
Cada item parece pequeno.
Somados podem se tornar gigantescos.
É por isso que tantas empresas passaram a adotar práticas de FinOps.
O nascimento do FinOps
FinOps significa:
Financial Operations.
Ou seja:
Operações financeiras aplicadas à tecnologia.
Hoje muitas empresas possuem equipes inteiras dedicadas a responder perguntas como:
Quem está consumindo recursos?
Quanto custa cada aplicação?
Qual é o custo por cliente?
Qual é o custo por transação?
Isso praticamente não existia no início da corrida para a nuvem.
A verdade que ninguém gosta de ouvir
Existe uma verdade que incomoda muitos vendedores de tecnologia.
Nem toda inovação reduz custos.
Algumas aumentam custos.
Mas aumentam receita.
E isso pode ser perfeitamente aceitável.
Cloud frequentemente se encaixa nesse cenário.
A empresa paga mais.
Mas cresce mais rápido.
Lança produtos mais rapidamente.
Conquista clientes mais cedo.
Portanto o custo adicional pode valer a pena.
Então por que repatriar?
Porque chega um momento em que determinadas cargas se tornam:
previsíveis;
estáveis;
maduras.
Nesse ponto a elasticidade da cloud perde parte do valor.
E a eficiência operacional começa a ganhar importância.
A pergunta muda.
Deixa de ser:
"Como crescer?"
E passa a ser:
"Como operar com eficiência?"
O futuro é híbrido
Talvez essa seja a maior conclusão.
O futuro não parece ser:
tudo na cloud;
tudo no mainframe;
tudo on-premises.
O futuro parece híbrido.
Cada carga de trabalho executada no ambiente mais adequado.
É exatamente isso que vemos nos grandes bancos.
Itaú.
Bradesco.
Banco do Brasil.
Santander.
Caixa.
Todos operam ambientes mistos.
Cloud.
Linux.
Containers.
APIs.
Mainframe.
Tudo convivendo.
Tudo integrado.
O que você deve aprender como profissional
Se você está começando em COBOL, não caia na armadilha de pensar que sua carreira está presa ao passado.
Pelo contrário.
O mercado está procurando profissionais que entendam integração.
Profissionais que consigam conversar sobre:
COBOL;
APIs;
Cloud;
Mensageria;
Kubernetes;
IBM Z;
Arquitetura distribuída.
Porque a verdadeira transformação digital não consiste em destruir o legado.
Consiste em conectá-lo ao futuro.
Conclusão: O Retorno da Maturidade Tecnológica
Cloud Repatriation não significa fracasso da nuvem.
Também não significa vitória do Mainframe.
Significa algo muito mais interessante.
Significa maturidade.
O mercado finalmente começou a entender que tecnologia não deve ser escolhida por moda.
Nem por marketing.
Nem por tendências.
Ela deve ser escolhida por critérios objetivos:
custo;
desempenho;
segurança;
disponibilidade;
escalabilidade.
A nuvem continuará crescendo.
Os datacenters continuarão existindo.
Os mainframes continuarão processando bilhões de transações.
E as arquiteturas híbridas se tornarão cada vez mais comuns.
Para uma Analista COBOL Júnior, essa é uma excelente notícia.
Porque mostra que o conhecimento de sistemas corporativos continua extremamente relevante.
O profissional do futuro não será aquele que conhece apenas uma tecnologia.
Será aquele que entende quando usar cada uma delas.
E talvez essa seja a maior lição da Cloud Repatriation.
Às vezes a inovação não está em mover tudo para a nuvem.
Às vezes a inovação está em descobrir o que nunca deveria ter saído de casa.
