#189 Kubernetes: a ferramenta para orquestrar e escalar performances

Fernandinha: Tá começando mais um Entre Chaves, o seu podcast de desenvolvimento de software. Hoje vamos falar sobre Kubernetes, um assunto muito legal com pessoas bastante ativas na comunidade DevOps. Inclusive, ambos palestraram no último DevOps Day que aconteceu em Juiz de Fora e vieram aqui conversar conosco sobre isso. Mas antes de apresentar os convidados, Champs está aqui comigo. Champs, como é que você tá?

Champs: Oi, Fernandinha! Oi, convidados. Eu que não palestrei no DevOps Day, mas estou aqui para bater papo, que é o que a gente sabe fazer, né? Estamos celebrando os 10 anos do Kubernetes. Apesar dos 10 anos, é um tema super atual, totalmente utilizado. Acho que todo mundo tem curiosidade de saber mais, então vai ser um prazer ter essa conversa aqui hoje.

Fernandinha: É isso aí. Então, para falar sobre esse assunto conosco, temos aqui o Felipe. Felipe, como é que você tá? Se apresenta, por favor.

Felipe: Olá, boa tarde, bom dia, boa noite, sei lá. Obrigado pelo convite, primeiramente. Meu nome é Felipe, sou Lead DevOps, atuo como Lead DevOps há algum tempo e já tive outras posições também. Hoje, além disso, trabalho com Engenharia de Inteligência Artificial, principalmente com modelos grandes de linguagem, os famosos LLMs. E sim, tento ser um participante ativo da comunidade. Inclusive, eu e a Natalia nos conhecemos em um desses eventos no ano passado, no qual eu estava palestrando. Este ano, ela palestrou também, não foi isso?

Natalia: Bom dia, Boa tarde, boa noite. Sou a Natalia, muito bom estar aqui. Um dos princípios do DevOps, que acredito muito, é compartilhar conhecimento de qualquer forma. Hoje, vamos tentar ajudar o pessoal a se aprofundar um pouco mais em containers e Kubernetes. Sou DevOps e trabalho com foco em observabilidade. Tento contribuir com a comunidade e este ano comecei a contribuir com a tradução da documentação do Kubernetes do inglês para o português, além de outros projetos open source da CNCF.

Fernandinha: Muito legal. Antes de entrarmos no tema, falem um pouquinho sobre o evento DevOps Day.

Felipe: Acho que o principal ponto do evento é a formação de indivíduos pelos próprios indivíduos que contribuem e que têm a sua vida profissional de ativa, né, dentro desse tema. Não é restrito ao tema de DevOps, apesar de tudo DevOps não é um cargo, né, é uma ideia por trás de como atuar numa profissão e etc. Existe um ferramental associado a essa ideia e aí é onde a gente acaba arrumando o nosso cargo nisso e tal, mas é mais essa defesa dessa ideia e uma das coisas que surgiram de forma emergente, né, a partir desse movimento, do estabelecimento dessa ideia, foi esse evento que acontece de maneira global e ele é organizado pelas comunidades locais, não é restrito, na verdade, qualquer comunidade ativa pode criar esse evento e ele tem alguns fundamentos, o primeiro deles é esse, né, não tem nenhum tipo de associação ou influência de empresas no desenvolvimento do evento e por influência eu quero dizer, tipo, palestra de uma pessoa, o patrocínio ele acontece, mas como um apoio. Então não existe nenhum tipo de venda, esse tipo de coisa, o que torna as palestras mais puristas no ponto de vista de tecnologia, então é o ponto de vista do profissional sobre uma determinada tecnologia ou assunto, e explanando ali para os demais colegas, né, que estão participando do evento sobre aquele tema, né, então acho que é o ponto de colaboração, né, entre os profissionais e tal, que é um dos princípios de DevOps.

Natalia: Não, e eu assim, eu recomendo fortemente a quem está nos ouvindo, caso tenha uma oportunidade que participe de DevOps Days, a gente vai ter uma edição aqui em Belo Horizonte, também pode ser um ponto a pé para você que nunca teve nenhum contato com nenhuma comunidade, conhecer. É um evento que nos possibilita também saber de cases, aprender ferramentas novas, né, porque aí dentro desse mundo, Cloud Native, são muitas coisas. Então é um lugar assim para fazer networking, para aprender, ou você aí que está querendo entrar ou migrar diária também, é se entender um pouco, então é uma oportunidade muito bacana e 14 de setembro tem DevOps Days Belo Horizonte.

Fernandinha: Bom, então entrando mais um pouco no nosso tema, né, vamos começar falando mais sobre o Kubernetes, né, como que surgiu o histórico, o que que é o Kubernetes, então gostaria de só que a gente desse uma primeira contextualizada aí na galera, do que que é e o histórico, um breve histórico aí dessa ferramenta.

Felipe: Não, legal, acho que nesse aspecto eu posso contribuir um pouco, acho que uma das primeiras coisas que eu fiz quando eu comecei a aprender sobre containerização foi olhar o que tinha no ecossistema de containers, isso foi em 2020, já faz um tempo, eu senti, e aí dentro do ecossistema apareceu o Kubernetes como um dos orquestradores que tinha disponível na época, né, ele na vez também tinha Mezos ainda, ainda existe na real, mas ele não é tão expressivo, o Dock Swarm, entre outros, que também foram meio que não deixado de lado, mas assim foram sendo substituídos por conta da expressividade que o Kubernetes tem de fato, né, e pelo tanto de outros features que ele cobre além da orquestração de containers. E uma coisa que eu acho super interessante é que é um projeto que a Google desenvolveu durante dez anos, né, ele inicialmente o Borg ou Omega, eu nunca lembro quem veio primeiro, mas ele era um orquestrador bet, né, de tarefas, bet rodando em containers que durante esses dez anos se viu ao Google pra diversas funcionalidades, especificamente nessa parte de orquestração de containers e em algum momento ele resolve abrir esse projeto para a comunidade, na época quando foi aberto era o Borg propriamente dito e esse projeto rapidamente foi incorporado pela comunidade por conta da sua expressividade, né, ele resolve alguns problemas que eu acho muito sensacionais na parte de orquestração de container que o Dock Swarm, na minha opinião, não resolve tão bem, que é a parte de redes e comunicação entre, mas acho que essa solução, né, da parte de usar na Liuvelay V2 com o Service Resolver por ele mesmo e tal, isso já foi um belo de um ganho, acho que o maior ponta pé inicial ali para a comunidade realmente abraçar e se começar a desenvolver outras soluções em cima disso. Hoje o Kubernetes já é um monstro, um ecossistema completamente diferente desse inicial, usa isso ainda de base, mas existem um milhão de outras soluções em cima disso.

Champs: E ele domina a orquestração de containers completamente.

Natalia: E por que que, aí eu vou trucar, porque que o Kubernetes é o que ele é hoje, né, assim, primeiro que a Google colocou aí no finado Borg, mais de 15 anos de de expertise, né, e se a gente for pensar, né, que containers não é um conceito assim tão recente ou que surge com o Kubernetes, né, você vai ter lá no Linux, ser groups, outras formas de você fazer isolamentos de processos, mas o Kubernetes ele imprime um padrão de como desenvolver a sua aplicação, como fazer integrações e como você gerenciar isso, né, porque se a gente for colocar qualquer workload aí no Kubernetes, é de forma declarativa, se eu estou dizendo que eu tenho, eu quero uma réplica pra, sei lá, ChatGPT ou o Evolve, ele vai garantir que eu tenha uma réplica dessa, dessa aplicação, né, no seu funcionamento ali embaixo. Então ele imprime esse padrão que vai tornar integração entre times, definição de negócio, né, muito mais prático, mais simples do que outras soluções de orquestração que a gente teve.

Champs: Eu queria colocar uma perguntinha aí, né, porque a gente citou vários conceitos aí durante a aplicação e eu acho que até pra quem já tá familiarizado, às vezes, com o conceito de container e tudo mais, com essas diferentes possibilidades de Kubernetes, às vezes esses conceitos ainda ficam um pouco confusos pros desenvolvedores. Então minha pergunta é mais no sentido de dessa diferenciação do que que é um pod, o que que é uma imagem, o que que é um container, enfim, eu acho que se a gente pudesse contextualizar um pouquinho disso, acho que vai facilitar ainda para o pessoal entender do que que a gente tá falando e por que que o Kubernetes tem sido tão relevante.

Natalia: Bom, o Kubernetes ele imprime um padrão, né, de como, desde o desenvolvimento ao deploy e o monitoramento de uma aplicação, né. Então, o que que é a internalização, né, é o isolamento de processos dessa aplicação em uma infraestrutura, né. Então você desenvolveu um software, né, você vai precisar ali das dependências desse código, né, você é normalmente você precisa definir, né. Ah, essa é uma aplicação serverless, vai rodar uma OVM, onde que você vai hospedar isso, né. E tradicionalmente, né, aí há uns 15 anos, né, ou não, você subia essa aplicação numa máquina virtual, por exemplo. Só que ao longo do tempo era muito comum você ter problemas de compatibilidade ou atualização de alguma dependência, de algum Lib, que quebrava a sua aplicação, por exemplo, né. Então, com a containerização, você consegue construir, né, a partir aí do dockerfile, uma imagem, né, o que vai se tornar uma imagem de container que vai poder ser executada, uma máquina com Docker ou no próprio Kubernetes, e você vai conseguir isolar um exemplo, construir algo em Python, né. Eu tenho ali uma dependência da versão 1.0.1 e não sei por que cargas d’água essa aplicação só consegue ser executada nessa versão, né. Pode ser que algum dia você executou um pipe upgrade e essa dependência mudou de versão, quebrou a sua aplicação. Então, no container você consegue garantir aquele garantir que essa dependência, por exemplo, não mude, né. Então, eu vou isolar a minha rede, eu vou isolar a CPU, eu vou isolar a memória e você vai garantir que essa aplicação não se misture, né, com outras coisas que estão ali na sua infraestrutura.

Fernandinha: E aí, essa vantagem que você está contando para nós, Natalia, é a vantagem de usar containers, né. De ter containers, de utilizar containers para fazer a publicação da minha aplicação, certo?

Natalia: Exatamente. E aí, onde que entra o Kubernetes no jogo? Primeiro que Kubernetes não é uma bala de prata, né. Ele não vai resolver todos os problemas da nossa vida, né. Depende muito se você tem um ambiente, se você tem um ambiente pequeno, por exemplo, será que Kubernetes é a melhor solução, né. O Kubernetes vem para resolver o problema de você gerenciar o que você precisa ser um maestro muito eficiente para conseguir gerenciar altas cargas de trabalho, né. E dependendo do período do ano, por exemplo, essa semana a gente está tendo uma promoção aí bem boa num marketplace famoso e você tem, por exemplo, um aumento, né, no número de requisições, né, de determinadas operações ali. Se fosse no modelo tradicional, como que você escalaria e atenderia a essa demanda, né, garantiria alta disponibilidade? Então, o Kubernetes vai entrar aí, né, e aí você tem essa imagem de container, ela pode ser só um POD, sem um controlador por trás, e aí se você deletar esse workload, morreu a aplicação, né, ou você pode colocar isso em forma de deployment, né, que vai gerenciar esse POD, que é a menor unidade dentro do Kubernetes, e a partir disso, a gente consegue escalar essa aplicação, por exemplo, se tiver um aumento de CPU, de consumo de CPU e de consumo de memória RAM, eu subo o número de réplicas, por exemplo, para dar conta desse serviço e, por exemplo, eu não sofri com lentidão, latência e etc. Então, o Kubernetes resolve, por exemplo, um dos problemas de alta disponibilidade, que se ele fosse utilizado só ali no Docker, no AVM, a gente não teria essa possibilidade, exatamente, né.

Felipe: Você perguntou de uma coisa específica sobre POD, né, o que é um POD e tal, acho que o granado já diz algumas coisas, mas é interessante falar que o POD, apesar dele ser a menor unidade, né, que o Kubernetes consegue orquestrar, então, quando ele avalia se aquele POD cabe dentro daquela AVM ou não, né, ele vai olhar o total de memória, o total de CPU e avaliar se existe recurso físico naquele servidor para poder alocar aquele POD ou não. Mas dentro daquele POD, a gente pode ter mais de uma aplicação rodando, né, inclusive. E assim, não é usual, porque quando você está falando de escalabilidade, por exemplo, você tem um back e um front, por exemplo, se você colocar os dois dentro do mesmo POD, talvez o seu front esteja sofrendo em uma carga de trabalho que vai exigir que ele escale para uma nova unidade, igual a Granato mesmo já tinha colocado, mas o back está suave, assim, ele nem precisa responder, ele está lá nos 40% de memória ainda, estão no 20% de requisição e tal, e é isso. Mas como o Kubernetes não entende o container, ele entende o pod, se os dois estiverem no mesmo container, então ele vai escalar ambos, né, e aí você vai ter o que a gente antigamente tinha com o AVM, que é o desperdício, né. Acho que o Kubernetes ele endereça mais uma coisa interessante, que é evitar o desperdício de recurso, é super usar o seu recurso disponível. Então, quando você está falando de escalabilidade e tal, que ele consegue olhar quanto de memória e quanto de CPU, aquele POD ou aquela aplicação que você está tentando deployar precisa e aí ele vai conseguir encontrar um servidor que consegue alocar aquele recurso, nós estamos falando que eu posso usar aquele recurso até 100% com um nível de conforto ali de que e a minha aplicação está rodando tranquilo. E um ponto a se observar nisso é que isso gera uma economia, né, isso gera economia de serviços do tipo cloud, aonde você está pagando, você está alugando a VM de alguém para rodar suas coisas, é sempre importante falar que a cloud não é algo abstrato que mora no céu, é um servidor físico, exatamente.

Fernandinha: Existe um servidor físico em algum lugar.

Fernandinha: Exatamente, e na verdade você só está alugando o computador de alguém, alguém compra um computador muito parrudo que vale a pena, você alugar ele, entendeu, e você não quer comprar ele também porque custa caro, principalmente agora, né, mas enfim. E aí, voltando lá nos PODs, existem padrões de aplicações que necessitam que tenham mais um container dentro do mesmo POD. Por exemplo, se você tem um log collector que está fazendo ali a varredura dos seus logs que estão saindo no STD Out de um POD, por exemplo, ou que estão sendo armazenados num sistema de arquivos do POD, é muito interessante que esse cara esteja no mesmo contexto, porque ele escala junto com a aplicação e ele consegue associar o ID daquele POD ao que ele está coletando de informação. E aí, na questão de observabilidade, isso só ajuda bastante, porque aí na hora que você está fazendo a avaliação dos logs de outro lado, ou das métricas e etc., isso fica muito mais claro sobre qual é o problema da sua aplicação ou não, ou como ela está performando. Do ponto de vista, vamos falar de sidecars, que a gente fala que é um padrão hoje muito utilizado para aplicações que vão precisar, por exemplo, de uma abstração da parte de redes além da que o Kubernetes consegue te oferecer. E aí, quando a gente está falando do além do que o Kubernetes consegue te oferecer, é porque a camada de service dele já vai fazer um registro no KubeProxy, por exemplo, que é um dos componentes que o Kubernetes deploy em todos os servidores. Da parte de registro do POD, do OP do Pod para torná-lo disponível na comunicação. Então, quando o KubeProxy recebe uma requisição, ele enxerga se aquela comunicação está sendo para um determinado serviço e faz o redirecionamento disso para o POD específico que está sendo chamado, mas ele não consegue fazer um controle, por exemplo, se aquele POD deveria receber aquela requisição. Porque esse KubeProxy, no final das contas, é uma comunicação de load balancer tipo 4, que vai na camada 4 OS, que é só transporte e tal. E a camada de transporte não entende nada do pacote ou do protocolo. Se ele não entende nem do pacote, nem do protocolo, nem da aplicação, o que ele pode fazer é só fazer um redirecionamento baseado no IP, endereço de quem está mandando para quem está enviando. Quando você vai na camada de aplicação, ou na camada de segurança, ou em outras camadas de protocolo, ele vai conseguir entender se aquele pacote ou aquele método poderia ser executado contra aquele outro POD. E aí você precisa de uma aplicação que está no seu POD, que recebe esse pacote e consegue entender. O KubeProxy roteia tudo, porque ele não entende nada da aplicação do protocolo, mas o sidecar vai conseguir abrir aquele pacote e chegar na camada de aplicação e falar “você deveria estar mandando alguma requisição para esse POD ou não?”. E aí ele vai redirecionar ou não redirecionar. E aí tem outras N aplicações, ao qual isso se aplica, por exemplo, o Multotree LES, que vai poder conseguir encryptar a comunicação end-to-end. Então, só no contexto do POD, que aquilo vai ser descryptografado, então tudo aquilo que é visível dentro, se você usar um IdeaShark, ou um TCP estando lá, você conseguiria ver todos os pacotes, mas eles estariam encryptados, você não conseguiria ler nada. Acho que eu fui muito além do que a pergunta inicial, mas a gente entende o porquê o POD a menor unidade e o que que ele permite você fazer de abstração, além do que o kubernetes oferece por default, digamos assim.

Natalia: Um exemplo, eu preciso de um apache, um POD, tem um POD ali, aí eu tenho um apache e a aplicação, por exemplo, eles podem estar no mesmo POD, aí você vai ter, vão se comunicar muito facilmente, porque vão estar dentro do mesmo workload, ou uma paixão que precisa, sei lá, esses dois containers precisam ter acesso ao mesmo sistema de arquivos, então, estando no mesmo POD, isso é resolvido também, ou sei lá, por algum motivo, eu quero colocar junto com a minha aplicação, eu não recomendo isso, mas é só um exemplo, sei lá, um gerenciador de segredos, eu posso meter isso no mesmo…

Felipe: Na real,ele faz isso, ele tem um padrão que faz a injeção dos segredos direto, ele faz a carry no servidor principal e injeta como segredo na aplicação direto, por variável de ambiente.

Natalia: Exatamente, e eu acho que o principal case, falando de boas práticas, espero que vocês se preocupem com isso, eu posso construir um container que ele vai coletar métricas da minha aplicação de forma customizada, então eu consigo desenvolver uma aplicação que vai coletar, tratar logs, métricas, traces, etc. E, por exemplo, exportar essas métricas para alguma solução centralizada, então você consegue colocar esse carinha para trabalhar ali lado a lado do meu container de aplicação. Por exemplo, tudo isso, o POD pode servir para a gente.

Fernandinha: Vocês falaram assim, várias boas práticas de como utilizar o POD, quando, quais aplicações que deveriam estar dentro de um mesmo POD, como fazer essa utilização da melhor forma, mas eu fiquei com uma dúvida até anterior a isso ainda, que assim, a Natalia até eu vou falar um pouco sobre isso, que são alguns cenários em que a gente não precisa utilizar Kubernetes e às vezes não precisamos nem containerizar a minha aplicação. Existem esses cenários. Exato, vou fazer um API super padrão aqui, que eu não preciso ficar me preocupando muito com escalabilidade, com esse tipo de coisa, às vezes eu não preciso, às vezes eu vou estanciar um S service dentre da minha azure lá e já está tudo bem, eu não preciso containerizar. E aí eu queria saber com vocês, como vocês veem isso, em quais situações que eu realmente não preciso nem de containerizar, o que que eu preciso e quando eu preciso de fato usar um Kubernetes mesmo, porque eu estou precisando distrair o melhor potencial da ferramenta?

Felipe: Legal, acho que a essa pergunta eu daria um comentário de contribuição aqui, que é a primeira coisa que você precisa avaliar é caso de uso. O que que o Kubernetes resolve? O Kubernetes resolve complexidade de rede, complexidade de orquestração, escalonamento, escalabilidade, resiliência, ah beleza, aí você “vou sempre no Kubernetes”. Não, não é isso o caso. É porque tem outros orquestradores que fazem partes dessas funcionalidades, mas não entregam, por exemplo, uma versão completa de solução de rede. Então, de um service discovery, por default. E, por exemplo, o ECS da AWS ou a outra solução de containers que eu não conheço, eu só conheço a AWS, mas enfim. E esse ECS, por exemplo, 90% de todas as implementações que eu fiz até hoje em containers e que já resolve tipo assim, assustadoramente, boa parte das aplicações. Quando foi o ponto de corte? O ponto de corte foi: a partir do momento em que eu precisei resolver endereços de aplicações que foram sendo escaladas de forma dinâmica, o ECS começa a ficar truncado nisso, porque você vai precisar usar ou o load balancer ou uma solução custom de service mesh. E aí, na hora que você faz isso, começa a introduzir uma complexidade que o Kubernetes te entregue de graça. E aí você fica assim, cara, por que que eu vou gastar minha cabeça com isso se eu tenha outra solução que já atende a isso? E vai te entregar até muito além do que você está tentando resolver. Eu falaria que até container tem casos de uso. E aí, na minha bem humilde opinião, você precisa avaliar se o overhead de um container, apesar de estar entregando esse isolamento da aplicação, etc., faz sentido quando a aplicação é extremamente demandante. E aí o que eu estou falando? Vamos supor aplicações de inteligência artificial. O meu container vai ter um driver que suporta rodar em cima daquele sistema operacional, fazer as conversões necessárias, as chamadas de kernel, etc., e ainda entregar em alto desempenho para a minha aplicação fazer o processamento daquilo? Então nós estamos fazendo uma aplicação entre o sistema operacional e o hardware. O container tem, ele é uma abstração de sistema operacional. Se ele é uma abstração de sistema operacional, ele tem um layer no meio do caminho que está fazendo chamada para o sistema operacional base e o sistema operacional base fazendo uma chamada para o kernel propriamente dito. É claro que tem funções otimizadas para isso, o container vem entregando isso cada vez mais otimizado, mas ainda assim tem uma perda de desempenho e aí se a sua aplicação é extremamente demandante e nós estamos falando de uma aplicação que vai rodar em alta performance o tempo inteiro, às vezes você está falando comigo “ah, são milisegundos que estou perdendo”, cara, mas no tempo, em larga escala, com uma quantidade absurda de chamadas sendo executadas, etc., isso vai chegar no montante que justifica esse nível de otimização.Tem aquele dizer da engenharia do software que é a otimização precoce, você não faz nenhum tipo de otimização precoce, porque geralmente você está matando formiga com canhão. Mas enfim, é uma coisa a ser avaliada e se você é um bom entendedor na hora do levantamento do requisito, você encontra requisitos não funcionais que restringem aquele tipo de aplicação, você tem que ingressar o caso de uso certo. Então acho que foram esses dois maiores casos de restrição que eu já encontrei hoje para o uso dessas tecnologias, tanto o container quanto a orquestração. Por default, usa container, pelo menos o container.

Natalia: Mas indo além, eu acho que tem três coisinhas que para mim, Natália, pesaria na minha tomada de decisão, em qual ambiente, que aí a gente volta lá atrás na regra de negócio. Eu diria, putz, essa minha solução aqui, ela é crítica, crítica, crítica. O que escolher? Porque no final das contas, o Kubernetes vai, por exemplo, te garantir uma melhor tolerância a falhas. Porque a sua própria arquitetura, quando a gente sobe uma aplicação no Kubernetes, ele vai escolher o melhor nó para subir essa aplicação, mas você consegue também replicar essa aplicação em vários nós. Tem um componente do Kubernetes, que é o cluster autoscale. Então a gente pode achar que, meu Deus, eu subi minha aplicação para a nuvem, está tudo resolvido. Mas a gente sabe que os provedores de nuvem têm zonas de disponibilidade, de várias coisas, etc., para garantir que isso não aconteça. Mas se cai um nó, por exemplo, do Kubernetes, se a minha aplicação estava rodando ali, o Kubernetes com cluster autoscale vai tratar de repor esse nó de forma dinâmica. E ele também vai estar olhando para as métricas e recursos do cluster, para, por exemplo, decidir subir outro nó. E isso garante com que a minha aplicação seja tolerante a falhas. E um outro ponto que pode pesar no porquê escolher o Kubernetes é o fato de, como a gente tem um padrão de como você definir as aplicações, o time de desenvolvimento, em tese, não vai precisar, por exemplo, se preocupar se essa aplicação está containerizada, em, por exemplo, em qual cloud, se um dia a gente tiver um cenário que eu tenho que fazer uma migração, vou migrar de provedor, eu vou voltar para as VMs, vou voltar para a BNMETO, etc., então a portabilidade que o Kubernetes oferece garante com que as empresas não fiquem presas, ou atreladas a uma solução de um provedor específico. Porque a minha aplicação containerizada, eu levo ela para um manifesto do Kubernetes, eu consigo levar ela somente para um container docker, eu consigo levar ela para um docker compose, então a facilidade de você migrar, portar essa aplicação é muito grande com Kubernetes. E o fato dela estar definida para Kubernetes faz com que também o time de desenvolvimento, por exemplo, consiga fazer rollback, fazer redeploy de uma aplicação de uma forma muito mais ágil, ou fazer testes, etc., de uma forma muito mais ágil dentro do Kubernetes, seria aí pontos que eu levaria em consideração as facilidades. Claro que o primeiro contato com Kubernetes pode ser um pouco assustador, uma empresa que adote Kubernetes. Obvio que você vai ter uma dívida técnica a ser paga, mas o fato de ser um software open source, que você consegue sim utilizar soluções gerenciadas da cloud, etc., podem oferecer algum serviço específico à base do Kubernetes é a mesma. Não importa se você está rodando aí o Kubernetes num container na sua máquina ou num provedor específico de cloud. A definição da aplicação para Kubernetes é a mesma, então isso inclusive faz com que a gente tenha um avanço do desenvolvimento de soluções e aplicações muito mais rápido do que outras soluções.

Fernandinha: Foi legal você falar Natalia em relação à migração de nuvens ou de provedores. Eu estava lendo recentemente uma vantagem falando sobre o fato de que algumas empresas estão saindo, voltando da cloud para on-premise. Isso é um tema que com certeza a gente vai explorar no episódio futuro, mas é uma coisa que eu estava lendo inclusive recentemente, que algumas empresas estão retornando para on-premise. Mas aí, depois de todas essas vantagens que vocês falaram e quando utilizar e quando não, eu fiquei agora curiosa em relação a custo, porque isso, claro, quanto mais facilidade a gente tem, mais custo a gente tem também. E aí, queria conversar um pouquinho sobre esse tema do custo do Kubernetes.

Champs: Só complementando também, só pelo que foi dito, a gente já tem uma interpretação de que tem um custo mais subjetivo relacionado ao Kubernetes, que pode estar relacionado justamente à diminuição do esforço do meu time, em conseguir desenvolver ele mais rápido, ter menos esforço na hora de fazer os deploy, ter menos trabalho na hora de pelo fato de não ter que lidar com o bug em produção lá por causa do gerenciamento do recurso, porque os bugs vão deixar de acontecer se isso for bem gerenciado. Então tem uma série de fatores aí falando de custo, mas de uma maneira mais subjetiva, em termos de tempo de trabalho, de esforço de time, que o Kubernetes, pelo que já foi dito, já é um ponto para ele. Aí eu não sei se ele se paga, é o que eu acho que a gente tem que levar em consideração.

Fernandinha: E aí eu queria colocar mais um ponto na pergunta também, que é a complexidade da ferramenta. Pelo que vocês falaram, é uma ferramenta que tem uma complexidade inerente e que talvez vai tirar um esforço do time de dev, mas vai colocar um esforço num outro time, talvez ali de devops. Então acho que tudo isso pode ser considerado como custo. Então vamos lá.

Felipe: Legal, acho que um bom ponto para adicionar nisso aí, é que a carga cognitiva que você põe em cima do time, ela existe. E a partir do momento que você colocou o Kubernetes na sua solução, você tem duas opções. Ou você torna o time alheio a ela, e aí ele não sabe o que está acontecendo por trás, ele só sabe deployar. Clica no botãozinho, pipeline roda, e é isso, aí ele bate no endpoint e vê funcionar. Ou você torna o seu time ciente dessa complexidade. E aí eu acho que tem pontos positivos e pontos negativos dos dois lados. Num ponto positivo da primeira abordagem, é você extrair toda a complexidade do meu time. Eu tenho aplicações altamente resilientes, altamente escaláveis, etc. E aí eu pus todo o overload dessa complexidade em cima do meu time de devops, por exemplo, que eu tive que contratar, que talvez num sistema com VMs lá, o FTP, que tinha antigamente, e aí a galera conseguia auto-gerenciar o seu próprio deploy, mas que era extremamente susceptível a erros, falhas, etc. Mas quando você contrata esse time de devops para poder tratar essa complexidade, você tirou da mão do seu time algumas especificidades de implementação que às vezes seriam interessantes de eles conhecerem para entregar aplicações eficientes. Alguns problemas que podem ser criados por essas abstrações, porque quando eu estava comentando, por exemplo, sobre o Kubeproxy, que é um load balancer ali no meio do caminho do tipo 4, se o meu dev não sabe que tem aquele load balancer no meio do caminho, ele sabe que tem mais um hop ali. E aí eu estou precisando entregar minha aplicação em um mili-segundo. Tem um hard requirement lá de 100 mili-segundos, a resposta tem que acontecer. Se eu tiver o load balancer da cloud, mais um load balancer interno, mais um ingress no meio do caminho para tomar decisão, será que com esse tanto de componente eu consigo bater esse hard requirement? E aí às vezes o cara vai ficar ali escovando o bit e não vai. Porque tem uma quantidade de componentes no meio do caminho que impossibilitam. Não estou falando que é o caso, estou só conjecturando. Tem aplicações que rodam o Kubernetes e são extremamente performáticos, não é isso, não me entendo mal.

Fernandinha: Mas eu entendi seu ponto, que é basicamente assim, se o time não conhece, que está por baixo do que ele está fazendo, às vezes ele nunca vai conseguir otimizar a aplicação dele, a ponto de atingir requisitos não funcionais.

Felipe: Exatamente. E aí a gente vai entrar em um assunto até meio controverso, que é do tipo, o dev precisar conhecer o sistema operacional ou não?

Fernandinha: É, a gente sempre fala que no entre chaves sobre camadas de abstração que a gente adiciona, né? Enfim, desde sempre a gente adiciona camadas de abstração e cada vez menos o dev vai precisando de saber menos.

Felipe: Ou ele fica mais especializado, né? Vamos pensar dessa outra forma também. E aí você deixa o trabalho generalista para outros profissionais. As duas coisas são válidas, eu acho. Mas é só importante a gente reconhecer que quando a gente toma decisão para um lado ou para o outro, isso vai acontecer e isso pode impactar no tipo de aplicação que você está entregando para seu cliente final. Aí vai… Vamos lá, né? A Granato tinha comentado que o kubernetes está altamente associado com a galera de negócio, por uma série de questões. Isso é uma das questões, né? Se você tem um nível de… uma necessidade de uma entrega tão detalhada, então seu time vai precisar estar altamente apto a debugar, inclusive o que está executando a aplicação dele. Se ele não tem essa necessidade, se esses fatores já não são tão relevantes, cara, então abstrai mesmo, porque aí você vai ter entregas que são o core velue do seu produto muito mais rápido, porque você consegue encontrar devs mais facilmente no mercado porque eles estão mais especializados apenas nos frameworks de programação ao qual eles estão desenvolvendo. E aí a sua cadeia de valor acontece muito mais rápido, né? Então, acho que só essa ponderação, que era importante de ser feita, entre complexidade e facilidades, mas falando um pouco sobre essa parte de abstração de Cloud, que eu acho sensacional que o Kubernetes entrega, é uma camada comum, é uma plataforma para governar a todos. Se alguém entendeu a referência (risos). Enfim, essa camada é única, ela permite você ser multicloud, ela permite você ser híbrido, que é entre Cloud e on-prem. Aí esse tipo de movimento de volta para on-prem ou não, ela se torna uma decisão, o meu custo está maior do que eu esperava ou não? Ah, vamos supor que uma das Clouds determinou que o preço dela subiu 20% e aquilo tornou o retorno por request da sua aplicação inviável. Às vezes, aquele 20% era o seu lucro. E aí cada request passou a não se pagar mais. Então, você está dando software gratuito. E de verdade, nós estamos em um ramo onde o capitalismo reina, não adianta. Então, se você tem essa necessidade de entender qual é o retorno que você está tendo por request, esse detalhamento da sua aplicação, para você é relevante saber se você vai para Cloud A ou Cloud B ou ficar em casa. E aí, se você tem Kubernetes em todos os lugares, você pode botar um terceiro abstração, que é um cara que vai ficar olhando o preço dos três e falando, cara, vou escalonar aqui, porque aqui eu vou escalar, e aí o preço por request está bombando, economia de escala. Ou então, eu vou ficar em casa, porque é do tipo, a conta de luz aqui já está difícil de pagar. Então, fica quietinho aqui de personagem, entendeu?

Natalia: De toda forma, adotando o Kubernetes, você vai ter uma dívida técnica no início. Até você conseguir colocar o time na mesma página de conseguir padronizar como você desenvolve e deploya essas aplicações e como você administra também um cluster Kubernetes, você vai ter uma dificuldade inicial, mas que é superável. E claro, o Kubernetes, a gente está falando muito de custo. Hoje, por padrão, ele também oferece opções para você conseguir reduzir custos. Então, ali na definição do Kubernetes, se vocês estão fazendo tudo certo, observando a sua aplicação, pelo menos o básico, CPU, memória, etc., exatamente. Filipe falou tudo. Eu consigo, porque dentro do Kubernetes você pode ter alguns problemas. O primeiro, você pode ter problemas se você não definir limites, porque a sua aplicação pode consumir indefinidamente, e aí você está desperdiçando recurso que está te gerando custo. Você tem um problema de definir, de forma equivocada, esses limites de CPU e RAM, por exemplo, que pode fazer a sua aplicação entrar em um crash, etc. Então, o ideal, pegando tudo isso, custo, comportamento de aplicação, etc., é que você tenha uma stack mínima de observabilidade, que você defina um período de tempo que você vai observar o comportamento da sua aplicação, e definir quests e limites de acordo com isso. Porque aí você está olhando não só para a aplicação, mas para o ambiente. Você consegue remover nó, inserir nó, trocar máquinas, de uma forma muito tranquila dentro do Kubernetes. Mas é isso, voltando atrás. O Kubernetes não é uma bala de prata, de qual é o desenvolvimento, da administração, das boas práticas, porque ele não vai resolver tudo por si só.

Champs: Sim, só comentando em cima disso também. Assim como toda ferramenta, ela tem que ser bem utilizada e ela abre margem para você cometer esse tipo de erro.
Acredito que não só usando Kubernetes, mas usando outros tipos de gerenciamento dos seus recursos. Você consegue também cometer erros que vão te comprometer no uso de recursos e vão te comprometer financeiramente. Eu acho legal na discussão do Kubernetes como que a gente acaba sempre falando em custo. A gente sempre que no podcast que a gente vai falar sobre uma ferramenta, a gente cai na discussão do custo, que o usar ou não está sempre muito atrelado a isso. E o Kubernetes me parece ser um aliado em diferentes aspectos, como um potencial para otimizar o nosso uso dos nossos recursos e otimizar os custos consequentemente. É claro que tem todas essas questões que a gente falou de complexidade, de time, mas pela minha experiência acho que vocês vão concordar e não por acaso, é uma ferramenta que domina o mercado hoje. Ela é muito bem sucedida em otimizar esses custos nos cenários em que é aplicável. Ela é muito bem sucedida para ajudar a gente a otimizar esse recurso.

Felipe: Eu acho que o importante é só ressaltar que ele tem um salto inicial de custo, porque ele tem componentes próprios que precisam ser executados. Os nossos mestres, se eles estiverem sendo executados da forma de alta disponibilidade, com alta resiliência e sempre coisa, eles vão estar apartados dos workers. Tem os nós que são o control plane e tem o datoplane. E aí o datoplane é onde estão os workers que vão de fato executar os boards, etc. Então você tem o custo dessas máquinas sendo só o cérebro da sua aplicação, o que você não tem em outros orquestrados de contêiner. Então, você está entendendo que eu estou falando, às vezes, isso para uma startup é um custo que ela não paga, porque vai representar ali mil dólares para ela por mês das máquinas sendo executadas que ela não pode pagar. Então, tem esse degrau que é o que a Natalia soltou lá atrás. Tem otimizações, mas a gente tem que pensar que, da mesma forma que o CloudNatives interessa aplicações em escala, o Kubernetes também é em escala. Se você estiver falando de meia dúzia de pods sendo executados, esquece que o Kubernetes é caro demais para você. Em complexidade e gestão, em tudo, só vai se pagar no longo prazo, só isso.

Fernandinha: Achei o episódio muito bom, a gente falou bastante sobre Kubernetes, sobre o fato dele ser um orquestrado de contêiner e, principalmente, o que você falou, Felipe, de que a vantagem dele está totalmente na escala, da gente conseguir gerenciar melhor as nossas aplicações, e é isso. Muito obrigada a vocês. Até a próxima, gente. Tchau, tchau.

Champs: Valeu pessoal, até mais.

Natalia: Tchau, galera!