Blog

Enquanto conferências celebram microsserviços e Kubernetes, boa parte da receita de bancos, governo e indústria ainda roda em Oracle WebLogic, JBoss / WildFly, IBM WebSphere ou pilhas equivalentes, com servidores web na frente (Apache, IIS, HTTP Server embutido) e integrações que foram escritas há quinze ou vinte anos.

O problema humano

Recrutar quem domina deployment descriptors, filas JMS, datasources XA e o ciclo de vida de EJB não é só caro — é raríssimo. Muitos desenvolvedores associam “legado” a carreira estagnada; gestores temem parar features para “só manter o que funciona”. O resultado é concentração de conhecimento em poucas pessoas e risco operacional alto.

Problemas técnicos recorrentes

Versões de Java e do servidor de aplicação fora de suporte, patches de segurança acumulados, heap e GC mal dimensionados, thread pools esgotados sob pico, e integrações com mainframe ou SAP que ninguém mapeou por completo. Em WebLogic, clusters mal configurados geram sessão inconsistente; em JBoss, módulos e classloader ainda confundem quem veio só do Spring Boot.

Caminhos realistas

Documentar o mínimo viável (fluxos críticos, dependências, janelas de deploy), estabilizar com correções pequenas e mensuráveis, e alinhar um plano de estrangulamento do monólito (anti-corruption layer, extração de serviços por domínio) sem “big bang”. Alocação de perfis híbridos — quem conhece legado e quem traz práticas modernas — costuma ser o meio-termo que sustenta o negócio até a próxima geração de sistema.

O cluster Kubernetes é frequentemente vendido como destino final de modernização. Na operação, ele é um sistema distribuído que exige patching, capacidade planejada e continuidade de conhecimento no time — sob pena de incidentes em horários inconvenientes.

On‑premises

Upgrades de control plane coordenados com janela de manutenção, validação de CNI e CSI, e compatibilidade com SO dos nós. etcd como ponto sensível: backup e restauração testados de verdade, não só job agendado “verde”. Hardware heterogêneo e firmware desatualizado geram falhas difíceis de correlacionar com métricas de aplicação.

Na nuvem gerenciada

Menos peso em control plane, mas node groups, add‑ons, quotas e IAM continuam sob responsabilidade do cliente. Versões deprecadas de API extensions/v1beta1 ainda aparecem em manifests antigos e quebram upgrades silenciosamente até o próximo deploy.

Investimento em plataforma

Runbooks, simulacros de disaster recovery, ownership claro de cluster per team vs plataforma central, e FinOps para workloads que poderiam ser autoscaled ou movidos para modelo mais barato. Manutenção não é overhead — é parte do produto interno de plataforma.

Adotar IA em engenharia é decisão de produto e de risco, não só de licença de software. Líderes precisam comunicar trade‑offs em linguagem que diretoria e segurança entendam.

Vantagens comuns

Aceleração em código repetitivo, sugestões de teste, exploração de APIs desconhecidas, documentação inicial e tradução de requisitos em esboços técnicos. Para times maduros, isso libera ciclos para design e hardening.

Desvantagens e custos ocultos

Revisão mais exigente quando o diff é grande. Dependência de fornecedor e variação de qualidade entre modelos. Custo recorrente de tokens versus salário já pago. Risco de vazamento se políticas forem fracas. Homogeneização de soluções “óbvias” que competidores também geram.

Conclusão prática

Tratar IA como ferramenta em um toolchain governado: onde entra, quem valida, quais dados tocam o modelo, e como medir resultado em lead time e defeitos — não só “satisfação no Slack”. A LASS ajuda a montar esse framework alinhado a DevOps e compliance.

Ferramentas públicas de IA tornaram trivial colar dados confidenciais em busca de resposta rápida. O problema não é só malícia — é hábito, pressão de prazo e ausência de alternativa corporativa aprovada.

Cenários reais

Customer success enviando conversa com PII para resumir. Desenvolvedor colando stack trace com token embutido. Analista subindo CSV de vendas para “gerar insight”. Em todos os casos, o fornecedor pode reter trechos para treino ou suporte, dependendo dos termos — e o controle da empresa sobre o dado se perde.

Resposta pragmática

Oferecer ferramentas com contrato B2B adequado (ou modelo local), DLP em endpoints onde possível, treinamento curto e recorrente, e cultura de “não colar dado de cliente em ferramenta não aprovada”. Transparência com o comitê de privacidade evita projeto de IA parado no “não podemos”.

Ferramentas como copilotos e agentes prometem multiplicar velocidade. Em projetos reais, o ganho depende de tarefa repetitiva bem delimitada, qualidade do contexto enviado ao modelo e do tempo que o time ainda gasta validando, corrigindo alucinações e integrando código gerado ao padrão do repositório.

Onde a performance patina

Latência e rate limits de APIs externas inserem espera no fluxo de IDE. Prompts vagos geram refatorações amplas que quebram testes. Falta de métricas: ninguém mede tempo “humano no loop” versus tempo economizado em boilerplate.

Uso sustentável

Definir casos de uso com ROI claro (testes, documentação, scaffolding), políticas de modelo e de dados sensíveis, e treino para revisar diff como em qualquer PR externo. IA é alavanca — não substitui governança de qualidade.

O primeiro deploy saiu em semanas; o décimo, com o mesmo repositório, já exige dias e medo de regressão. Não é só falta de teste — é fronteira de módulo inexistente, dependências circulares e configuração espalhada que ninguém mapeou.

Padrões que vemos

“Vamos quebrar em microserviços no próximo sprint” sem domínio estável: nascem sete deploys e um acoplamento pior que o monólito via chamadas síncronas. Pacotes compartilhados que viram lixeira global de DTOs e utils. Falta de convenções de nomenclatura e camadas, dificultando onboarding e revisões.

Caminho mais saudável

Modularizar dentro do monólito (bounded contexts), contratos claros entre módulos, pipelines de CI que falham cedo em acoplamento proibido, e decisão documentada de quando fatiar serviços — geralmente após estabilizar o modelo de domínio e observabilidade. A LASS apoia arquitetos e tech leads a desenhar esse degrau sem travar entrega.

A LGPD não é só política de privacidade na landing page: em engenharia, ela aparece em cada decisão de persistência, retenção e acesso. Times ágeis frequentemente tratam ambiente de desenvolvimento como “fora do escopo” até o DPO apontar cópias de produção em laptops ou PII em JSON de erro enviado ao Sentry.

Casos típicos

Logs com e‑mail, CPF ou token indexados em Elasticsearch sem política de TTL. Backups sem inventário de onde estão e quem pode restaurar. Testes E2E usando base real “só dessa vez”. Exportações para BI sem classificação de dados sensíveis.

Alinhamento técnico‑jurídico

Classificar dados tratados por sistema, definir bases legais documentadas, minimização (mascarar, hash, pseudonimização onde possível), retenção por tipo de dado e procedimento de resposta a incidentes e a pedidos dos titulares. Ferramentas ajudam; o que falta, em geral, é contrato explícito entre produto, segurança e jurídico — nós ajudamos a traduzir isso em backlog priorizado.

Automatizar entrega acelerou times, mas também multiplicou superfícies: runners efémeros, registries de imagens, repositórios de artefactos e integrações com SaaS. Erros de configuração expõem não só infraestrutura, mas dados de clientes embutidos em dumps de teste ou relatórios gerados no pipeline.

Onde dói

Variáveis mascaradas que ainda vazam em stack traces ou artefactos de build. Caches de dependências ou layers Docker com credenciais de registry corporativo. Permissões amplas em tokens de deploy que permitem leitura de buckets inteiros “para facilitar o script”.

Ambientes de staging com cópias parciais de produção sem anonimização são alvo frequente em auditorias e, pior, em incidentes reais quando URLs de homologação ficam expostas.

Práticas que reduzem exposição

OIDC em vez de chaves longas‑vida, rotação automática, escopo mínimo por job, revisão de Dockerfiles multi‑stage para não deixar segredos em layers intermediários, e política clara de dados em builds (synthetic data, subset anonimizado). Cultura de “pipeline como produto” com revisão de PR igual à de código de negócio.

Integrar on‑premises com nuvem parece um exercício de “abrir firewall e apontar rota”. Na prática, a maior parte dos incidentes vem de pressupostos errados sobre caminho de retorno, MTU, DNS privado e zonas que se sobrepõem entre ambientes.

Problemas que vimos em campo

Assimetria de rota: o pacote sai pela VPN e volta pela internet pública (ou vice‑versa), causando timeouts intermitentes que ferramentas de aplicação atribuem erroneamente a “lentidão do microserviço”. CIDR sobreposto entre VPC/VNet e rede corporativa exige NAT complexo ou redesenho — adiado até virar bloqueador de projeto.

DNS híbrido: aplicações em Kubernetes resolvem nomes via CoreDNS enquanto mainframes ou ERPs esperam sufixos internos; sem encaminhamento consistente, “funciona do meu laptop” e falha do pod. ExpressRoute/Direct Connect com BGP mal anunciado derruba redundância percebida como ativa‑ativa.

Como desenhar melhor

Diagrama de fluxos com origem/destino explícitos, testes de conectividade bidirecionais documentados, e decisão consciente entre hub‑and‑spoke, mesh ou rede única estendida. Segurança (segmentação, least privilege em security groups) deve nascer junto da topologia, não como retrabalho.