Afinal, eu preciso de Kubernetes?

Como toda tecnologia, Kubernetes (e orquestradores em geral) vêm para resolver problemas em aberto. Mas será que você realmente tem esses problemas? Aprenda a diferenciar a necessidade do oba-oba no mundo dos contêineres!

Se você acompanha o universo do DevOps, já deve ter ouvido falar de Kubernetes, o orquestrador de contêineres Docker (e rkt) que nasceu na Google e ganha cada vez mais tração. Se está por fora, dê uma lida em o que são orquestradores.

Além de trabalhar como Site Reliability Engineer na In Loco, focado em automação, eu também sou (e amo ser) desenvolvedor front-end. Por isso, vindo do universo do JavaScript, precisei aprender a diferenciar hype de utilidade (no começo não foi fácil). Trazendo essa habilidade para as terras de DevOps, quero te ajudar a entender se Kubernetes resolve os problemas que você tem ou se só vai ser mais um problema para adicionar na pilha.

(O texto continua logo abaixo da foto obrigatória de contêineres de navio para manter a analogia de sempre.)

Fonte: Wikimedia Commons (Domínio Público)

Kubernetes te ajuda a gerenciar contêineres em produção

Isso é meio óbvio, mas não custa lembrar: para usar um orquestrador como o Kubernetes, suas aplicações precisam rodar em contêineres, como Docker. Existem vários benefícios para usar contêineres, como a paridade entre ambientes de desenvolvimento, teste, homologação e produção, portabilidade de código e redução na configuração da máquina hospedeira da aplicação.

Porém, se você tem um simples projeto em PHP, rodando em uma hospedagem compartilhada, e isto atende suas necessidades, migrar para contêineres talvez te dê mais trabalho do que retorno, pois você vai ter que lidar com a efemeridade dos contêineres e armazenamento. Além disso, claro, você terá que migrar para uma hospedagem em que você tem o controle do servidor, coisa que nem sempre vale à pena se você não tem uma equipe dedicada com expertise para isso.

Se você precisa de contêineres, talvez precise de Kubernetes! Se não precisa, deixe para lá.

Kubernetes abstrai a sua infraestrutura física (ou virtual), para você só pensar em contêineres

Uma das grandes vantagens de usar um orquestrador é poder lançar, remover e escalar contêineres nas suas máquinas sem precisar literalmente executar os comandos do Docker nelas (especialmente se você tem dezenas ou centenas de máquinas e contêineres). Porém isso assume que você tem uma infraestrutura para ser abstraida.

Hoje em dia, vários PaaS (Platform as a Service) têm suporte nativo a contêineres Docker, como o Heroku. Nesses casos, você constrói seus contêineres e envia para que sejam executados por você. Por que então nos damos o trabalho de provisionar máquinas e instalar e gerenciar o Kubernetes nós mesmos? Principalmente, preço e flexibilidade.

Geralmente, esses PaaS são mais caros do que a infraestrutura equivalente seria, se contratada diretamente. Isso faz sentido, afinal o Heroku (PaaS) roda na Amazon Web Services (IaaS). A depender da sua escala, contratar infraestrutura de nuvem e manter equipes para gerenciá-la vai sair mais barato e, com as ferramentas certas (como Kubernetes), proporcionar o mesmo nível de facilidade para sua equipe de desenvolvimento.

Outro quesito é a flexibilidade. Ao contratar infraestrutura, você tem a liberdade de provisionar recursos que sirvam perfeitamente para seus casos de uso, como instâncias com diferentes tipo de poder de processamento, memória, rede, armazenamento, além de balanceadores de carga e diversos outros serviços. Frequentemente, provedores de PaaS têm variedades limitadas no tipo de recursos que você pode usar. É como quando você compra uma camisa simples, que tem tamanhos P, M ou G, comparado com uma camisa de marca, que tem tamanhos numerados, com diferentes combinações entre comprimento e largura da gola, por exemplo. (A diferença, nesse caso, é que a camisa simples aqui é mais cara, pois a camisa de marca vem só o tecido, linha e agulha para você costurar! Hahaha)

Se você precisa e pode gerenciar sua infraestrutura, talvez precise de Kubernetes! Se não, procure outras opções (ou ainda, um Kubernetes-as-a-Service).

Kubernetes facilita escalonamento automático, otimização de recursos e automações em geral

Uma das melhores razões para usar um orquestrador é a facilidade de automatizar coisas como escalonamento, deploy e recuperação de problemas. Afinal, o Kubernetes provê uma API que pode em tempo real monitorar e agir sobre os seus contêineres. Ele também ajuda a otimizar recursos: máquinas podem rodar vários contêineres, potencialmente de diversas aplicações que você tenha. Assim, se você tem uma aplicação que usa 80% de uma instância, os 20% restantes podem ser usados pelo servidor web de outra aplicação sua, sem você ter de se preocupar em fazer a matemática.

Ao meu ver, o ~pulo do gato~ do Kubernetes está aí. Se você tem uma ou várias equipes desenvolvendo software que evolui muito rápido (potencialmente gerando mais e mais outros softwares), Kubernetes pode ser bem útil! A facilidade de sair do zero para uma aplicação com replicação, servidor web, load balancer, auto-scaling, monitoramento e recuperação automática de erros e muito mais (e manter essa aplicação saudável) é sensacional!

Claro, tudo isso vem com um custo: você precisa criar, configurar e manter a saúde do seu cluster do Kubernetes e dos sistemas auxiliares que ele utiliza. Novamente, se isso parece demais para você, potencialmente você ainda não precisa de um orquestrador. Mas se você está disposto a fazer isso para ganhar toda essa facilidade, e se isso faz sentido para o crescimento do seu software e da sua equipe, parabéns! Você tem um bom caso de uso para o Kubernetes!

Ou seja?

Opinião pessoal: Kubernetes é massa. Todo mundo precisa parar agora para aprender e colocar em uso em qualquer sistema que desenvolve? Não.

Para sua empresa: valide se você precisa das facilidades que o Kubernetes te traz e se os custos (de tempo, esforço e dinheiro) envolvidos valem à pena. Pesquise casos de sucesso e insucesso e veja como o seu negócio se compara! Se sim, use, é massa! Mas não adote só pelo hype.

Para você, interessado em DevOps e SRE: estude Docker e orquestradores como Kubernetes. Das duas uma: você vai entrar numa empresa cuja escala justifica o uso, e vai precisar saber para se virar, ou você vai entrar numa (ou criar uma) empresa que vai chegar nesse momento, eventualmente, e você vai ser responsável por implementar não só o software, mas as boas práticas e a cultura.


Recadinho: a In Loco está contratando!

Se você tem interesse por DevOps, automação, confiabilidade e engenharia de software, a In Loco está contratando pessoas para nossas áreas de Site Reliability Engineering (SRE)! Dá uma olhada na página de vagas.


Notou que não existe muito conteúdo sobre este assunto em português? Vamos mudar isso! Se gostou, compartilhe e recomende esse artigo (batendo palmas ali embaixo 👏). Se estiver inspirado, manda um comentário ou ainda escreva sobre o assunto!