 |
| Bellacosa Mainframe quando o sonho da nuvem virada pesadelo |
☕💸☁️ CLOUD BILL SHOCK — QUANDO A FATURA DA NUVEM CHEGA E O MAINFRAME COMEÇA A PARECER BARATO
Existe um momento muito curioso na vida de quase toda empresa que embarca na jornada da computação em nuvem.
No início tudo parece maravilhoso.
O desenvolvedor cria um servidor em poucos minutos.
O ambiente de testes nasce instantaneamente.
Os sistemas escalam sozinhos.
As equipes ganham agilidade.
Os executivos sorriem.
Os arquitetos comemoram.
Os fornecedores fazem apresentações cheias de gráficos coloridos.
E então chega a primeira fatura realmente grande.
Nesse momento nasce um fenômeno que ficou conhecido mundialmente como:
Cloud Bill Shock.
Ou, em português:
O Choque da Fatura da Nuvem.
Para muitos profissionais jovens, especialmente quem está começando carreira em COBOL e Mainframe, esse termo parece estranho.
Afinal, durante anos ouvimos que a nuvem era mais moderna, mais simples e mais barata.
Mas a realidade dos grandes ambientes corporativos mostrou uma verdade muito interessante.
Cloud pode ser fantástica.
Cloud pode ser revolucionária.
Cloud pode acelerar negócios.
Mas cloud nem sempre é barata.
E algumas empresas descobriram isso da forma mais dolorosa possível.
Ao abrir a fatura no final do mês.
O que uma Analista COBOL Júnior precisa entender
Vamos começar do início.
Imagine que você trabalha em um banco tradicional.
Existe um ambiente mainframe que processa:
contas correntes;
cartões;
PIX;
empréstimos;
aplicações financeiras.
Tudo funciona há décadas.
O sistema está pago.
A infraestrutura está instalada.
Os profissionais conhecem a plataforma.
Os processos são estáveis.
Então surge a pergunta:
"Por que não colocar tudo na nuvem?"
Parece uma pergunta simples.
Mas a resposta é extremamente complexa.
Porque existe uma enorme diferença entre:
custo inicial
e
custo operacional contínuo.
O encanto da nuvem
Imagine uma startup recém-criada.
Ela possui:
5 desenvolvedores;
1 produto;
100 clientes.
Comprar um datacenter próprio seria loucura.
A nuvem resolve o problema.
Você cria:
servidores;
bancos de dados;
armazenamento;
monitoramento.
Tudo com poucos cliques.
O modelo parece perfeito.
E realmente é.
Nesse estágio.
O problema da escala
Agora imagine que essa startup cresceu.
Não possui mais:
100 clientes.
Possui:
1 milhão.
Depois:
10 milhões.
Depois:
50 milhões.
Depois:
100 milhões.
Agora o cenário muda completamente.
Cada operação gera consumo.
Cada acesso gera consumo.
Cada consulta gera consumo.
Cada byte armazenado gera consumo.
Cada transferência de dados gera consumo.
Cada serviço adicional gera consumo.
A conta começa a crescer.
E cresce rapidamente.
O aluguel invisível
Uma forma simples de explicar cloud para um iniciante é esta:
Mainframe tradicional muitas vezes funciona como casa própria.
Cloud funciona como aluguel.
Imagine um apartamento alugado.
No começo parece excelente.
Pouco investimento inicial.
Entrada reduzida.
Flexibilidade.
Mas depois de vinte anos pagando aluguel...
Você percebe que gastou uma fortuna.
Cloud possui comportamento parecido.
Você paga continuamente por:
CPU;
memória;
armazenamento;
rede;
backup;
tráfego;
monitoramento;
segurança.
A conta nunca para.
O dia em que o financeiro descobre a AWS
Existe uma história que se repete em inúmeras empresas.
A área técnica está feliz.
A inovação está acelerada.
Os desenvolvedores estão satisfeitos.
Então o departamento financeiro recebe a fatura.
Primeiro mês:
US$ 5 mil.
Segundo mês:
US$ 20 mil.
Terceiro mês:
US$ 80 mil.
Sexto mês:
US$ 500 mil.
Um ano depois:
milhões de dólares.
Nesse momento alguém pergunta:
"Por que estamos gastando tudo isso?"
E nasce uma investigação corporativa.
O caso do armazenamento
Uma analista COBOL talvez pense:
"Mas armazenamento é barato."
Sim.
Individualmente.
Mas vamos fazer uma conta simples.
Imagine um banco com:
100 milhões de clientes;
documentos digitalizados;
extratos;
imagens;
logs;
backups;
auditoria.
Estamos falando de petabytes.
Talvez dezenas de petabytes.
Quando o volume cresce, cada centavo por gigabyte se transforma em milhões.
O inimigo chamado Data Transfer
Existe uma cobrança que assusta muitos arquitetos.
Transferência de dados.
Os provedores de nuvem adoram falar sobre armazenamento.
Sobre CPU.
Sobre inteligência artificial.
Mas existe um detalhe.
Mover dados também custa dinheiro.
Muito dinheiro.
Imagine:
aplicativos móveis;
APIs;
integrações;
analytics;
parceiros externos.
Bilhões de chamadas.
Bilhões de respostas.
Terabytes trafegando diariamente.
Cada pacote possui custo.
O pesadelo do ambiente esquecido
Todo analista experiente já viu isso.
Um desenvolvedor cria:
servidor de teste;
banco temporário;
ambiente experimental.
O projeto termina.
O ambiente fica ligado.
Dias passam.
Meses passam.
Anos passam.
Ninguém percebe.
Mas a cobrança continua.
Existem empresas pagando milhares de dólares por recursos esquecidos.
O efeito multiplicador dos microsserviços
Os microsserviços trouxeram inúmeras vantagens.
Mas também criaram novos desafios.
No mundo tradicional talvez existisse:
uma aplicação;
um banco de dados.
No mundo moderno podemos ter:
centenas;
milhares;
dezenas de milhares de serviços.
Cada um consumindo:
CPU;
memória;
armazenamento;
rede.
Separadamente parecem baratos.
Juntos tornam-se gigantescos.
Quando o Mainframe entra na conversa
É aqui que uma analista COBOL começa a entender o debate.
Um mainframe não é vendido como servidor barato.
Nunca foi.
Mas existe algo impressionante nele.
Consolidação.
Um único IBM Z moderno pode processar volumes absurdos de transações.
Em muitos casos substituindo centenas ou milhares de servidores distribuídos.
O resultado é que algumas cargas financeiras apresentam:
menor consumo energético;
menor ocupação física;
menor administração;
menor complexidade operacional.
Por isso o cálculo econômico não é tão simples quanto parece.
O choque das empresas famosas
Nos últimos anos surgiu um movimento chamado:
Cloud Repatriation
Traduzindo:
"Trazer sistemas de volta."
Empresas que migraram tudo para cloud começaram a revisar decisões.
Não porque a nuvem fosse ruim.
Mas porque certas cargas de trabalho ficaram caras demais.
Algumas descobriram economias milionárias ao mover parte dos ambientes para:
infraestrutura própria;
colocation;
plataformas especializadas.
O mercado percebeu que não existe solução mágica.
O erro mais comum dos iniciantes
Muitos profissionais novos acreditam que arquitetura é apenas tecnologia.
Mas arquitetura também é economia.
Um arquiteto precisa entender:
desempenho;
segurança;
disponibilidade;
custos.
A melhor solução técnica do mundo pode fracassar se custar dez vezes mais que o necessário.
O que os bancos aprenderam
Os grandes bancos possuem uma experiência valiosa.
Eles processam bilhões de transações há décadas.
Por isso normalmente adotam arquitetura híbrida.
Não colocam tudo na cloud.
Também não deixam tudo no mainframe.
Cada ambiente recebe a carga mais adequada.
Por exemplo:
Aplicativo móvel?
Cloud.
Machine Learning?
Cloud.
Analytics?
Cloud.
Core bancário?
Talvez mainframe.
Liquidação financeira?
Talvez mainframe.
Processamento crítico?
Talvez mainframe.
O paradoxo que ninguém conta
Aqui está a parte mais interessante.
O objetivo da cloud nunca foi ser sempre mais barata.
O objetivo principal era:
agilidade.
Você consegue lançar produtos rapidamente.
Experimentar ideias.
Criar novos serviços.
Escalar em minutos.
Essa velocidade possui valor.
Muitas vezes o ganho de negócio compensa o aumento de custo.
Por isso empresas continuam investindo bilhões em nuvem.
O que uma Analista COBOL deve aprender com isso
Talvez a maior lição seja esta.
Não existe guerra entre Mainframe e Cloud.
Essa guerra só existe em apresentações simplificadas.
No mundo real os dois convivem.
E convivem muito bem.
O profissional moderno precisa compreender:
COBOL;
APIs;
Cloud;
Mensageria;
Integração;
Arquitetura distribuída.
Porque o mercado não procura especialistas que conhecem apenas um lado.
Procura profissionais que entendem como tudo se conecta.
Conclusão: Quando a Fatura Vira Professor
Cloud Bill Shock é uma das lições mais importantes da tecnologia moderna.
Ele nos lembra que inovação possui custo.
Escalabilidade possui custo.
Conveniência possui custo.
Flexibilidade possui custo.
A nuvem transformou a indústria.
Permitiu o nascimento de empresas como Nubank, Mercado Pago e centenas de fintechs.
Mas também ensinou uma lição valiosa.
Quando os números chegam à casa dos milhões de clientes e bilhões de transações, a discussão deixa de ser tecnológica.
Passa a ser econômica.
E é justamente nesse momento que muitos executivos voltam a olhar para tecnologias que julgavam ultrapassadas.
Mainframe.
COBOL.
CICS.
DB2.
IBM Z.
Não porque sejam antigos.
Mas porque continuam resolvendo problemas extremamente difíceis com eficiência impressionante.
Por isso, da próxima vez que alguém disser que o futuro pertence apenas à nuvem, lembre-se de uma verdade que o mercado financeiro aprendeu ao longo das décadas:
A tecnologia mais moderna nem sempre é a mais barata.
A mais antiga nem sempre é a mais cara.
E a melhor arquitetura quase sempre é aquela que equilibra inovação, desempenho e custo.
É exatamente nesse ponto que nasce o verdadeiro arquiteto de sistemas.
E é exatamente aí que uma analista COBOL deixa de enxergar apenas código e começa a enxergar negócios.
