Uma plataforma interna é um sistema de colaboração, não apenas infraestrutura. Foi essa a tese central da palestra Building Cloud Native Culture in a Bank, apresentada por Marcy Paramonova e Stéphane Cusin na KubeCon & CloudNativeCon Europe. A dupla detalhou como um banco redesenhou suas estruturas para que times de plataforma e de aplicação trabalhassem de forma independente, com padrões abertos e operações self-service via GitOps.
Por que uma plataforma é um sistema de colaboração?
Segundo Paramonova, desenvolvedores e times de produto dependem do time de plataforma, e o time de plataforma depende dos times de aplicação. Para avançarem juntos, precisam de padrões compartilhados. "Uma plataforma não é um pedaço de infraestrutura; é um sistema de colaboração por onde passa muita comunicação", explicaram os dois na sessão.
A transição para cloud native foi apresentada como uma mudança cultural, não só técnica. Paramonova argumentou que a jornada de transformação do banco exigiu também uma virada de comportamento entre equipes acostumadas ao modelo de tickets.
Leia também
Kubernetes promove kyaml como formato mais seguro e consistente para manifestos
Genius Bar duas vezes por semana
Uma das estruturas criadas foi o chamado Genius Bar: sessões de duas horas, duas vezes por semana, onde qualquer desenvolvedor pode aparecer com dúvidas sobre a plataforma, sem ticket e sem esperar agenda. Paramonova contou que a iniciativa atraiu times de infraestrutura, cibersegurança, rede, identidade e cloud, que passaram a resolver problemas em conjunto.
Além do Genius Bar têm, o time organiza sessões de user insights, com prioridades definidas junto aos usuários, e demos periódicas mostrando o que foi entregue, o que está no roadmap e como usar a plataforma no dia a dia. Internamente, o time de plataforma mantém sessões próprias de planejamento para decisões deliberadas em vez de trabalho reativo.
Super user awards e feedback doloroso
O banco criou eventos para reconhecer a adoção da plataforma, incluindo prêmios de super usuário para desenvolvedores que contribuíam ativamente com melhorias. "O feedback deles, às vezes difícil de ouvir e um pouco doloroso, nos ajudou de fato a criar algo mais bonito e melhor", admitiu Paramonova.
Como o GitOps eliminou a cultura da dependência?
Um princípio definido desde o primeiro dia, segundo Cusin, foi que nenhuma capacidade da plataforma poderia depender de intervenção manual. Ativar um recurso passou a ser uma mudança simples de configuração no Git, aplicada automaticamente pelo processo de GitOps.
O resultado é uma experiência self-service com rastreabilidade total. O time consegue ver quais capacidades estão sendo adotadas, quais caíram em desuso e quais usuários são afetados por uma mudança, o que permitiu desativar recursos não usados e migrar times para versões novas da plataforma com segurança.
Dica: se o seu time de plataforma vive reclamando de interrupções, a pergunta certa não é "por que nos atrapalham?", e sim "definimos uma estrutura clara para as pessoas nos procurarem?", como aponta Cusin.
Info: as decisões da plataforma são entregues como artefatos versionados, padrões de implantação reutilizáveis e interfaces documentadas, em vez de acordos individuais entre times.
Cultura segue estrutura: o que o caso do banco ensina
Cada recurso da plataforma passou a ter um ciclo de vida explícito: quem usa, como usa e se ainda gera valor. Essa visibilidade permite evoluir a plataforma de forma intencional, em vez de acumular complexidade ao longo do tempo.
Os princípios embarcados na própria plataforma resumem a cultura desejada: self-service em vez de operações por ticket, padronização em vez de customização, transparência em vez de conhecimento tribal e propriedade compartilhada em vez de dependência de poucos especialistas. Quando esses princípios estão embutidos no sistema, a cultura certa se torna o caminho mais fácil de trabalhar.
Atenção: se toda ação exige ticket, intervenção manual ou suporte direto de um engenheiro de plataforma, você está criando uma cultura de dependência sem perceber, alertou Cusin. Os times passam a esperar em vez de aprender e operar de forma autônoma.
Mindset de engenharia vale mais que o domínio atual
Paramonova defendeu que o mindset de engenharia é o fator mais importante: não o que você sabe hoje, mas sua capacidade de aprender, executar e operar novas tecnologias. "Ser engenheiro é resolver problemas, ter paixão por isso e compartilhar essa paixão", resumiu.
O uso de open source com padrões abertos também torna as habilidades transferíveis: o profissional não reaprende tudo do zero, mas constrói sobre uma base compartilhada entre tecnologias abertas. Para quem acompanha o mercado, o caso mostra como Kubernetes segue como base de novas camadas de abstração, inclusive em cenários regulados como o bancário, e dialoga com iniciativas como o OpenRL, API do Google para fine-tuning de LLMs no Kubernetes.
Cultura segue estrutura: você não pode esperar que a cultura surja sozinha; precisa desenhar sistemas que criem a cultura desejada, explicou Cusin.
"Kubernetes transformou mais do que a nossa plataforma. Transformou como a nossa organização constrói software", concluiu Cusin. Na avaliação do Mercado de TI, o caso é um roteiro reproduzível para empresas brasileiras com times de plataforma: os rituais descritos não exigem orçamento novo, apenas desenho intencional de interações. Para líderes de engenharia, o próximo passo é auditar onde o modelo de tickets ainda cria dependência e substituí-lo por configuração declarativa e rituais de colaboração.
Fonte: Infoq
