Decidi criar uma alternativa ao Kubernetes. Sim, estou ciente de que sou louco.
Amor porque, antes dele, fazer deploy em produção era algo sombrio. Vários softwares tentaram resolver esse problema — Mesos, Fleet, Nomad — mas somente o Kubernetes resolveu minimamente a orquestração de containers em escala. Não é sem mérito que hoje mais de 96% das organizações que usam containers usam Kubernetes, segundo o relatório CNCF de 2023.
Mas como nada é perfeito, um software criado por engenheiros do Google pecou muito na questão do design — não de UI, mas de como as coisas funcionam. Engenheiros pensam como engenheiros: funciona, mas a complexidade do Kubernetes é algo que você provavelmente vai precisar de um curso para entender a fundo. De um lado criou carreiras inteiras — a certificação CKA virou commodity no mercado — do outro, empresas pequenas que não podem se dar ao luxo de ter um DevOps certificado se veem numa encruzilhada: sentem a necessidade do Kubernetes mas não conseguem geri-lo.
O problema concreto: um cluster Kubernetes mínimo exige compreensão de pelo menos 15 abstrações diferentes — Pods, Deployments, Services, Ingress, ConfigMaps, Secrets, RBAC, PVCs, StorageClasses, NetworkPolicies, e por aí vai. E por incrível que pareça, a cada release esse número cresce. O Kubernetes 1.29 introduziu mais de 60 mudanças de API. Em 2024 foram depreciadas mais de 10 APIs que projetos dependiam.
Vários projetos tentaram resolver um pouco dessa complexidade. O Rancher adicionou uma boa camada de UI em cima do Kubernetes. O Dokploy, que não usa Kubernetes mas sim o Docker Swarm, conseguiu algo notável: na primeira vez que usei, coloquei um projeto online em poucos minutos, sem nenhum curso, sem grandes preocupações. A UX deles é genuinamente boa.
Mas tenho um problema com o Dokploy: ele usa o Docker Swarm. E embora o Swarm ainda seja tecnicamente mantido pela Docker Inc., o desenvolvimento desacelerou drasticamente em favor de soluções Kubernetes, o ecossistema parou de investir nele e a adoção encolheu. É um projeto funcionalmente estagnado — o que para infraestrutura crítica é um risco real.
O Nomad da Hashicorp tentou um caminho diferente — mais simples que o Kubernetes, binário único, sem a cerimônia toda. Mas em minha opinião pecou por estar muito acoplado ao ecossistema Hashicorp: Consul para service discovery, Vault para secrets, Terraform para infraestrutura. Funciona muito bem se você adota tudo. Se não, é limitado. E agora, depois que a Hashicorp foi adquirida pela IBM em 2024 e mudou a licença de MPL para BSL, essa dependência ficou ainda mais arriscada para quem constrói sobre essa base.
Algo sobre mim que você precisa saber: eu amo estudar qualquer coisa relacionada a IT. Além de ser minha profissão, é um hobby. E gosto de dar algum sentido ao meu estudo.
Dito isso, recentemente comecei um projeto pessoal. Tenho três VPS's, comecei a analisar o que precisaria e percebi que não precisava de toda a complexidade da stack Kubernetes. Fui para o Dokploy, que funciona bem para um MVP — mas fica a pergunta: e quando crescer?
Então num belo dia, enquanto tomava banho e refletia sobre tudo isso, pensei: posso usar o Dokploy enquanto é MVP, posso fazer um curso de Kubernetes e torcer para a IA configurar tudo certo, ou posso criar uma alternativa real. Fui pela opção mais óbvia: criar a alternativa.
Você pode me achar louco. Mas o Kubernetes nasceu de engenheiros do Google que acharam que podiam fazer melhor que o Borg. O Docker nasceu de alguém que achou que LXC podia ser mais simples. Projetos reais surgem quando pessoas resolvem pensar diferente sobre problemas conhecidos.
Meu objetivo não é fama nem dinheiro. O projeto vai ser 100% open source, licença Apache 2, sem versões pagas. O que quero é resolver um problema real: a complexidade desnecessária na orquestração de containers. Não prometo conseguir — mas é algo que vale tentar.
Estou trabalhando nisso há algumas semanas. O repositório ainda está privado, mas em breve, quando tiver uma versão mais estável, vou torná-lo público. Nos próximos posts vou detalhar as decisões de arquitetura e os motivos por trás delas — incluindo por que construí um orquestrador próprio em vez de colocar uma camada sobre o Kubernetes.
Se você também sente que a complexidade do Kubernetes está fora de proporção com o problema que ele resolve, acompanhe. Provavelmente vou errar muito — mas vou documentar tudo.