 |
| Bellacosa Mainframe e o pc veloz mas o Windows virou ruindows |
☕ Um Café no Bellacosa Mainframe
💻 O PC ficou 100.000 vezes mais poderoso. Por que ainda estamos esperando?
Temos processadores multicore, dezenas de gigabytes de RAM e SSDs que transferem gigabytes por segundo. Mesmo assim, esperamos o Explorer abrir. Talvez o problema nunca tenha sido falta de hardware.
Outro dia eu estava fazendo uma coisa absolutamente revolucionária no YouTube Studio.
Não estava renderizando um filme em 8K.
Não estava treinando uma inteligência artificial.
Não estava simulando a colisão de duas galáxias.
Eu queria alterar:
título, descrição, tags e thumbnail.
Só isso.
Então resolvi olhar quanto aquela aparentemente simples página estava consumindo no Chrome.
Quase 500 MB de memória.
Parei.
Olhei novamente.
Quinhentos megabytes.
Para quem passou boa parte da vida profissional dentro do mundo mainframe, existe uma reação quase automática:
“O que exatamente vocês estão fazendo com toda essa memória?”
E então percebi que o problema não estava apenas no navegador.
Olhei para minhas duas máquinas.
Uma roda Windows 10.
A outra, Windows 11.
Uso as duas regularmente e existe uma diferença que nenhum benchmark de processador consegue esconder:
a experiência cotidiana parece mais pesada.
Abrir o Explorer.
Copiar arquivos.
Abrir uma pasta.
Trabalhar no Word.
Editar uma planilha no Excel.
Operações que computadores fazem há décadas continuam conseguindo produzir aquela pequena pausa que faz o cérebro perguntar:
“Por que ainda não aconteceu?”
Foi então que surgiu a pergunta:
Se o computador ficou milhares de vezes mais poderoso, por que ainda estamos esperando?
🖥️ CAPÍTULO 1 — Quando 640 KB pareciam muito
Quem começou a trabalhar com computadores algumas décadas atrás viveu em um universo completamente diferente.
Memória era preciosa.
Disco era precioso.
CPU era preciosa.
I/O era precioso.
Cada byte tinha consequência.
Programadores discutiam estruturas de dados porque alguns kilobytes adicionais realmente importavam.
Um programa precisava caber dentro da máquina.
Hoje frequentemente fazemos o contrário.
Esperamos que a máquina seja grande o suficiente para caber dentro do programa.
Temos PCs domésticos com:
16 GB, 32 GB ou 64 GB de RAM.
Processadores com muitos núcleos.
SSDs NVMe capazes de movimentar gigabytes por segundo.
GPUs com poder computacional que teria parecido ficção científica algumas décadas atrás.
E usamos tudo isso para...
abrir uma pasta.
🚀 CAPÍTULO 2 — O hardware venceu. O software respondeu crescendo
Existe um fenômeno recorrente na história da computação.
Quando o hardware fica mais poderoso, inicialmente tudo fica rápido.
Depois o software percebe que existe capacidade disponível.
Surgem novas bibliotecas.
Novos frameworks.
Novas camadas.
Novos serviços.
Novos processos.
Novas integrações.
Novos recursos funcionando em segundo plano.
Até que, algum tempo depois, estamos novamente esperando.
É uma espécie de inflação computacional.
O computador ficou mais poderoso.
Mas o software aumentou sua ambição até consumir boa parte dessa vantagem.
Não necessariamente porque os desenvolvedores ficaram piores.
O software moderno também faz muito mais.
Segurança, criptografia, sincronização, colaboração, acessibilidade, internacionalização, recuperação, telemetria, nuvem e inúmeras outras funcionalidades possuem custos reais.
O problema aparece quando todas essas possibilidades entram no caminho daquilo que estou tentando fazer agora.
🗂️ CAPÍTULO 3 — Eu só queria abrir o Explorer
Vamos imaginar uma operação aparentemente trivial.
Você clica no Explorer.
Sua intenção é extremamente simples:
MOSTRE MEUS ARQUIVOSMas um sistema operacional moderno não enxerga necessariamente apenas uma pasta.
Existem thumbnails.
Arquivos recentes.
Indexação.
Pesquisa.
Integração com serviços de nuvem.
Extensões do shell.
Verificações de segurança.
Metadados.
Dispositivos externos.
Compartilhamentos de rede.
Caches.
Serviços auxiliares.
Sincronizações.
Cada componente pode individualmente possuir uma justificativa perfeitamente razoável.
O problema é a soma.
Você pediu:
DIRA arquitetura respondeu:
AGUARDE ENQUANTO CONSULTAMOS
O ECOSSISTEMA.
🧠 CAPÍTULO 4 — No mainframe isso produziria uma reunião
Agora imagine uma aplicação corporativa cuja documentação dissesse:
FUNÇÃO:
Editar quatro campos.
MEMÓRIA NECESSÁRIA:
500 MBEm muitos ambientes mainframe tradicionais alguém provavelmente perguntaria:
“Por quê?”
E essa pequena palavra muda completamente uma cultura de engenharia.
No mainframe existe uma longa tradição de observar:
CPU.
Storage.
I/O.
Throughput.
Response time.
Workload.
Prioridade.
Capacidade.
Consumo não é apenas algo que aparece no Task Manager.
Consumo faz parte da arquitetura.
Porque durante décadas cada recurso computacional teve custo suficientemente visível para obrigar organizações a prestar atenção nele.
⚙️ CAPÍTULO 5 — WLM: nem todo trabalho merece a mesma prioridade
Existe outra ideia extremamente interessante no mundo z/OS.
Workload Management.
O sistema não precisa simplesmente perguntar:
“Existe CPU disponível?”
Ele precisa entender que diferentes workloads possuem diferentes objetivos.
Uma transação crítica esperando resposta de um cliente não possui necessariamente a mesma importância operacional que uma atividade batch que pode esperar.
Agora imagine aplicar mentalmente essa filosofia ao desktop.
Estou usando o Explorer.
Então poderíamos imaginar:
SERVICE CLASS: INTERACTIVE
IMPORTANCE: 1Enquanto coisas como:
INDEXAÇÃO
SINCRONIZAÇÃO
UPDATE
CACHE
TELEMETRIA
PRELOADpoderiam conceitualmente pertencer a:
SERVICE CLASS: BACKGROUND
IMPORTANCE: 5A regra seria maravilhosa:
Primeiro responda ao ser humano. Depois faça manutenção da máquina.
Sistemas desktop possuem mecanismos de prioridade e gerenciamento de recursos, evidentemente.
Mas do ponto de vista da experiência do usuário, nem sempre parece que essa é a regra dominante.
⏱️ CAPÍTULO 6 — O benchmark que realmente importa
Existe uma métrica extremamente importante que raramente aparece na caixa do computador.
Paciência humana.
Considere:
100 ms → instantâneo
300 ms → praticamente instantâneo
700 ms → percebi uma pausa
1 segundo → estou esperando
3 segundos → alguma coisa está errada?Para um benchmark computacional, algumas centenas de milissegundos podem parecer insignificantes.
Para alguém trabalhando oito horas por dia, são fundamentais.
Porque o problema não é esperar 700 milissegundos uma vez.
É repetir pequenas esperas:
centenas de vezes durante o dia.
Abrir.
Esperar.
Salvar.
Esperar.
Trocar janela.
Esperar.
Abrir pasta.
Esperar.
A máquina continua tecnicamente rápida.
Mas o usuário começa a considerá-la lenta.
📄 CAPÍTULO 7 — Meu Office antigo continua trabalhando
Existe um experimento curioso na minha própria rotina.
Continuo utilizando uma versão antiga do Microsoft Office para determinadas tarefas.
Por quê?
Porque ela faz aquilo que preciso.
No Word quero:
escrever, formatar, inserir imagens, salvar e imprimir.
No Excel quero:
células, fórmulas, tabelas, gráficos e arquivos.
As versões modernas oferecem muito mais.
Colaboração.
Cloud.
Autosave.
Contas.
Templates conectados.
Serviços online.
Integrações.
Add-ins.
Assistentes.
IA.
Tudo isso pode ser extremamente útil para quem utiliza essas funcionalidades.
Mas existe uma pergunta arquitetural importante:
Se eu não estou usando determinada funcionalidade, por que ela precisa participar do caminho crítico daquilo que estou fazendo?
Esse talvez seja o verdadeiro problema.
Não é possuir funcionalidades.
É pagar continuamente pelo custo das funcionalidades que não estamos utilizando.
🌐 CAPÍTULO 8 — O navegador virou sistema operacional
Também precisamos reconhecer outra transformação.
O navegador deixou de ser simplesmente um programa para mostrar documentos HTML.
Ele virou uma plataforma computacional.
Uma aplicação web moderna pode possuir:
player de vídeo,
banco de dados local,
cache,
workers,
GPU acceleration,
criptografia,
comunicação permanente com servidores,
frameworks JavaScript,
árvores enormes de objetos,
notificações,
sincronização,
telemetria,
analytics.
Quando abrimos uma página moderna, muitas vezes estamos inicializando algo muito mais próximo de uma aplicação completa do que de um documento.
Isso explica parte dos 500 MB.
Mas explicar não significa necessariamente justificar cada megabyte.
🏗️ CAPÍTULO 9 — Construímos catedrais para vender cachorro-quente
Existe uma tentação permanente na engenharia de software.
Resolver o problema que talvez tenhamos amanhã em vez daquele que temos hoje.
Então uma pequena aplicação recebe:
framework,
container,
API gateway,
microservices,
observability,
event bus,
cache distribuído,
telemetria,
autenticação federada,
cinco bibliotecas JavaScript.
E finalmente...
um formulário com quatro campos.
A arquitetura é impressionante.
Mas o usuário queria editar o título de um vídeo.
É como construir uma catedral porque precisávamos de uma barraca para vender cachorro-quente.
A catedral pode ser maravilhosa.
Só existe uma pergunta inconveniente:
era necessária?
💾 CAPÍTULO 10 — Memória livre também serve para alguma coisa
Existe uma ressalva técnica importante.
Ver 10 GB ocupados no computador não significa automaticamente que 10 GB estejam sendo desperdiçados.
Sistemas operacionais modernos utilizam memória disponível como cache.
Isso é inteligente.
RAM vazia não produz trabalho.
Se o sistema puder guardar dados que provavelmente serão utilizados novamente, poderá melhorar bastante o desempenho.
Portanto:
MEMÓRIA UTILIZADAnão é igual a:
MEMÓRIA DESPERDIÇADAMas existe outra métrica.
Quanto recurso é realmente necessário para executar a função solicitada?
Essa pergunta continua válida.
🔥 CAPÍTULO 11 — CPU baixa também pode esconder um computador lento
Outro erro comum é olhar:
CPU: 7%e concluir:
“O computador está praticamente parado.”
Talvez.
Mas experiência interativa não depende apenas da média de CPU.
Imagine dezenas de processos acordando continuamente.
Um faz I/O.
Outro verifica alguma coisa.
Outro consulta a rede.
Outro atualiza um cache.
Outro analisa um arquivo.
Outro cria uma thread.
Outro executa garbage collection.
Nenhum deles individualmente utiliza muita CPU.
Mas todos disputam pequenas parcelas de atenção do sistema.
A utilização média continua baixa.
A latência percebida pelo usuário aumenta.
É possível ter CPU sobrando e ainda possuir uma experiência ruim.
📦 CAPÍTULO 12 — SSDs esconderam muitos pecados
Quando utilizávamos discos mecânicos, acessar arquivos desnecessariamente era caro.
Seek time doía.
I/O aleatório doía.
Inicializações pesadas doíam.
Depois chegaram os SSDs.
E muita arquitetura ruim ficou subitamente rápida.
Excelente.
Então adicionamos mais coisas.
Mais bibliotecas.
Mais serviços.
Mais arquivos.
Mais dependências.
Mais abstrações.
Vieram os NVMe.
Novamente ganhamos uma quantidade enorme de desempenho.
E novamente começamos a consumi-la.
Até que chegamos à situação quase cômica:
um dispositivo capaz de transferir vários gigabytes por segundo pode apresentar hesitação para abrir uma pasta.
🦖 CAPÍTULO 13 — Talvez o mainframe tenha algo a ensinar ao desktop
Não estou dizendo que devemos transformar Windows em z/OS.
São plataformas diferentes resolvendo problemas diferentes.
Mas algumas ideias atravessam arquiteturas.
Recursos possuem custo.
Mesmo quando parecem baratos.
Workloads possuem prioridades diferentes.
O que está diante do usuário merece tratamento especial.
Capacity planning continua importante.
Ter capacidade não significa que devemos desperdiçá-la.
Response time importa.
Throughput excelente não consola alguém esperando uma janela abrir.
Observabilidade precisa responder “quem consumiu?”
Não simplesmente “quanto foi consumido”.
E talvez principalmente:
Complexidade precisa justificar sua existência.
🖥️ CAPÍTULO 14 — Windows 10 de um lado. Windows 11 do outro.
Tenho duas máquinas ligadas.
Uma com Windows 10.
Outra com Windows 11.
Não preciso consultar uma apresentação de marketing para perceber determinadas diferenças.
Estou trabalhando nelas.
Abro Explorer.
Copio arquivos.
Uso navegador.
Abro Word.
Trabalho no Excel.
São justamente as tarefas banais que constroem nossa percepção sobre um sistema operacional.
Uma interface pode ser mais bonita.
Pode possuir animações melhores.
Pode integrar dezenas de serviços.
Mas existe uma métrica brutalmente simples:
Quando cliquei, respondeu?
Porque a interface gráfica possui uma função fundamental.
Transformar intenção humana em ação computacional.
Quanto menor a distância perceptível entre as duas, melhor parece a máquina.
👴 CAPÍTULO 15 — O computador velho que parece rápido
Existe uma experiência divertida.
Pegue um computador antigo funcionando com software da própria época.
Às vezes ele parece surpreendentemente responsivo.
Obviamente não é mais poderoso.
Um smartphone atual pode possuir ordens de magnitude mais capacidade computacional.
Mas aquele sistema antigo frequentemente possui:
menos processos,
menos camadas,
menos serviços,
menos abstrações,
menos dependências.
Você clica.
Ele executa.
Isso não significa que devamos voltar ao DOS.
Significa apenas que existe algo valioso naquela relação direta entre:
INTENÇÃO
↓
AÇÃOCada camada adicionada entre as duas deveria conseguir responder:
“Qual benefício estou entregando?”
🚨 CAPÍTULO 16 — O verdadeiro desperdício não é RAM
Talvez este seja o ponto mais importante.
500 MB de RAM custam pouco atualmente.
Alguns ciclos adicionais de CPU custam pouco.
Um SSD NVMe consegue absorver enormes volumes de I/O.
Mas existe um recurso que continua extremamente caro.
Tempo humano.
Se uma pessoa perde apenas dois segundos repetidamente durante centenas de operações diárias, estamos consumindo justamente o recurso que não conseguimos ampliar instalando outro DIMM.
Não existe upgrade de:
HUMAN TIMENão podemos instalar:
+32 GB DE VIDAÉ por isso que performance continua sendo experiência do usuário.
☕ CAPÍTULO 17 — O Mainframe Café propõe uma nova métrica
Talvez precisemos de uma nova unidade.
Vou chamá-la de:
Wasted Human Milliseconds — WHM
😂
Em vez de perguntar apenas:
CPU?
MEMÓRIA?
IOPS?
THROUGHPUT?perguntaríamos:
QUANTOS MILISSEGUNDOS
O USUÁRIO ESPEROU
SEM NECESSIDADE?Multiplique isso por:
mil operações,
mil usuários,
mil dias.
Subitamente aqueles insignificantes 500 milissegundos deixam de parecer insignificantes.
🧙 CAPÍTULO 18 — A regra Jedi do Capacity Planning
Depois de décadas trabalhando com sistemas críticos, eu resumiria a questão assim:
Capacidade disponível não é licença para desperdiçar latência.
Ter 64 GB de RAM não significa que cada aplicação ganhou autorização para consumir gigabytes.
Ter 16 núcleos não significa que dezenas de processos devam acordá-los continuamente.
Ter um NVMe de vários GB/s não significa que podemos ignorar I/O desnecessário.
E possuir uma máquina extraordinariamente poderosa não significa que o usuário deva aceitar esperar para abrir uma pasta.
Hardware abundante deveria proporcionar uma coisa maravilhosa:
simplicidade extremamente rápida.
☕ EPÍLOGO — Cliquei. Abra.
Talvez estejamos complicando demais.
Não quero que meu computador seja menos poderoso.
Não quero abandonar segurança.
Não quero abandonar cloud.
Não quero abandonar IA.
Não quero voltar para 1995.
Quero algo muito mais simples.
Quando eu clicar no Explorer:
abra.
Quando mandar copiar:
copie.
Quando abrir Word:
deixe-me escrever.
Quando abrir Excel:
mostre minha planilha.
Quando entrar no YouTube Studio para trocar título, descrição, tags e thumbnail:
deixe-me fazer exatamente isso.
Se eu quiser Analytics, carregue Analytics.
Se quiser comentários, carregue comentários.
Se quiser IA, carregue IA.
Se quiser edição de vídeo, carregue o editor.
Até lá:
IF FUNCTION_REQUESTED = FALSE
DO NOT WASTE MY RESOURCES
END-IFTalvez essa seja uma filosofia antiga.
Mas depois de observar uma página consumir centenas de megabytes para permitir que eu altere algumas linhas de texto, começo a suspeitar que algumas ideias antigas continuam bastante modernas.
Porque depois de toda a evolução dos processadores, memórias, discos, GPUs e sistemas operacionais, a melhor experiência de usuário ainda pode ser resumida em três palavras:
Cliquei. Responda. Agora.
☕ Um Café no Bellacosa Mainframe
Onde até o Windows aprende que recurso computacional também merece Capacity Planning.
