Do servidor Windows para o cluster
Migração da hospedagem de um parque corporativo: de servidores Windows com IIS para containers em Kubernetes. É um trabalho de time, do qual eu participo migrando as aplicações sob minha responsabilidade.
O que já existia, e não mudou
Vale começar por aqui, porque é a parte que costuma ser contada errado. O parque já tinha entrega automatizada antes da migração:
- Pipeline no GitLab CI fazendo build, teste e publicação, sem ninguém copiar arquivo para servidor
- Código versionado, com ambientes separados de homologação e produção
- Rollback funcionando: voltar versão é reexecutar a pipeline anterior, que sobrescreve os arquivos com o conteúdo antigo
Nada disso mudou com a migração. O que era legado não era o processo de entrega, era onde a aplicação roda.
O problema
O modelo antigo tinha as APIs em servidores Windows com IIS e os robôs e workers num servidor separado, agendados por Windows Schedule. Isso trazia quatro custos:
Ambiente não reproduzível. Servidor compartilhado acumula estado: configuração que alguém editou direto na máquina, dependência de caminho no disco, versão de runtime que vale para todas as aplicações daquele servidor. O que roda em produção não é exatamente o que foi testado.
Escala presa ao servidor. Crescer significa crescer a máquina inteira, com todas as aplicações que moram nela junto.
Agendamento acoplado. A periodicidade do worker vivia dentro da aplicação ou do agendador do Windows, então mudar horário mexia em código ou dependia de acesso ao servidor, e a aplicação precisava estar de pé para o relógio funcionar.
Visibilidade zero do lado do time. Saber se a aplicação estava no ar, ou por que estava lenta, dependia inteiramente da infraestrutura. Toda pergunta virava chamado.
E há o problema de escala da própria migração: o difícil não é o primeiro serviço, é o centésimo. Cada aplicação tem uma particularidade — versão antiga de framework, dependência de caminho, algo configurado à mão anos atrás — e parar tudo para migrar em bloco não é opção quando os sistemas faturam.
O que muda de fato
- Container em vez de servidor. APIs e workers passam a rodar como containers de homologação e produção no cluster, com a mesma imagem promovida entre ambientes
- CronJob em vez de Windows Schedule. A periodicidade é declarada no pipeline e vira tarefa agendada do cluster. Escala independente do serviço web, e mudar horário deixa de exigir deploy
- Monitoramento com acesso do time. O dono continua sendo o DevOps, mas o time passa a conseguir olhar o estado da própria aplicação sem intermediário
- IDP para nascimento de aplicação. Um portal cria a aplicação a partir do template e já abre os tickets de DNS e banco de dados, o que tira do caminho a parte burocrática que atrasava projeto novo
O ganho real é ambiente reproduzível e autonomia operacional. Não é automação de deploy, que já estava resolvida.
O meu papel
Sou consumidor competente da plataforma. Migro as aplicações sob minha responsabilidade e participo das decisões de como as aplicações usam o modelo novo. Não montei o cluster, não escrevi os charts base, não construí a esteira de GitOps e não sou dono do IDP — isso é do time de DevOps.
O que eu defendo no desenho
Template, não cópia. A alternativa comum é cada repositório ter seu pipeline copiado do vizinho. Funciona no décimo e é impossível no centésimo, porque corrigir um problema de build passa a exigir cem alterações. O template centraliza a mecânica e mantém a variação onde ela é legítima. É o mesmo princípio de biblioteca compartilhada, aplicado a entrega.
Convivência longa, não corte. Cento e noventa e quatro aplicações continuam no modelo antigo, e o desenho precisa suportar os dois mundos por anos. Quem projeta assumindo migração rápida cria pressão que quebra sistema em produção.
Onde está hoje
Das 319 aplicações do parque, 33 estão no cluster e 194 seguem em servidor Windows. As 92 restantes ainda não foram classificadas. Entre as migradas estão 12 repositórios meus.
Limite
A migração está no começo, e a parte que eu não controlo é a maior: o ritmo depende do time de plataforma e da fila de cada área. Também não tenho experiência de operar o cluster em incidente real — quando algo quebra em nível de infraestrutura, quem resolve não sou eu.
Stack
GitLab CI · Docker · registry privado · Helm · ArgoCD · Kubernetes