Na véspera Vitaly Khabarov fez uma entrevista com Dmitry Stolyarov (), diretor técnico e cofundador da empresa "Flant". Vitaly perguntou a Dmitry sobre o que a "Flant" faz, sobre Kubernetes, o desenvolvimento do ecossistema, suporte. Discutiram por que precisamos do Kubernetes e se ele é realmente necessário. Também falaram sobre microsserviços, Amazon AWS, a abordagem "Vou me sair bem" no DevOps, o futuro do Kubernetes, por que, quando e como ele dominará o mundo, as perspectivas do DevOps e o que os engenheiros devem se preparar para o futuro próximo com simplificações e redes neurais.
em forma de podcast pode ser ouvida no DevOps Deflope — o podcast em russo sobre DevOps, e abaixo está a versão escrita.
Aqui e adiante, as perguntas são feitas por um engenheiro da Express42.
Sobre a "Flant"
— Dima, olá. Você é o diretor técnico da "" e também seu fundador. Por favor, conte-nos o que a empresa faz e qual é o seu papel nela?
Dmitry: Do lado de fora, parece que somos aqueles caras que vão por aí instalando Kubernetes e fazendo algo com ele. Mas não é assim. Começamos como uma empresa que lida com Linux, mas já há muito tempo nossa principal atividade é a manutenção de projetos de produção e highload sob demanda. Normalmente, construímos toda a infraestrutura do zero e depois gerenciamos isso por um longo tempo. Portanto, o principal trabalho que "Flant" realiza, pelo qual é remunerada, é assumir a responsabilidade e implementar a produção sob demanda.
Eu, como diretor técnico e um dos cofundadores da empresa, estou constantemente pensando em como aumentar a disponibilidade da produção, simplificar sua operação, facilitar a vida dos administradores e tornar a vida dos desenvolvedores mais prazerosa.
Sobre o Kubernetes
— Ultimamente, tenho visto muitas palestras da "Flant" e sobre Kubernetes. Como vocês chegaram até ele?
Dmitry: Eu já falei sobre isso muitas vezes, mas não me importo em repetir. Acredito que é importante repetir esse tópico, pois há confusão entre causa e efeito.
Precisávamos muito de uma ferramenta. Enfrentamos uma série de problemas, lutamos, superamos eles de várias maneiras e sentimos a necessidade de uma ferramenta. Experimentamos muitas opções diferentes, inventamos nossas próprias soluções e acumulamos experiência. Gradualmente, chegamos ao ponto em que começamos a usar o Docker quase assim que ele surgiu - por volta de 2013. Quando ele apareceu, já tínhamos muita experiência com contêineres e já havíamos escrito um análogo ao "Docker" - algumas soluções improvisadas em Python. Com o surgimento do Docker, surgiu a possibilidade de descartar as improvisações e usar uma solução confiável e apoiada pela comunidade.
A história com o Kubernetes é semelhante. No momento em que começou a ganhar impulso - para nós, isso é a versão 1.2 - já tínhamos várias soluções improvisadas tanto em Shell como em Chef, que estávamos tentando orquestrar com o Docker. Olhamos seriamente para o Rancher e várias outras soluções, mas então apareceu o Kubernetes, que tinha tudo implementado exatamente como teríamos feito nós ou até melhor. Não há nada a reclamar.
Sim, há algumas falhas, algumas insuficiências — muitas insuficiências, e a versão 1.2 é uma verdadeira bagunça, mas... O Kubernetes é como um edifício em construção — você olha para o projeto e entende que vai ser incrível. Se o edifício agora tem um fundamento e dois andares, é melhor não se mudar ainda, mas com o software isso não é um problema — já se pode usar.
Não tivemos um momento em que pensamos se usaríamos o Kubernetes ou não. Estávamos à espera dele muito antes de ele aparecer, e estávamos tentando criar nossos próprios análogos.
Sobre o Kubernetes
— Você participa diretamente do desenvolvimento do próprio Kubernetes?
Dmitry: Moderadamente. Participamos mais do desenvolvimento do ecossistema. Enviamos uma quantidade de pull requests: para o Prometheus, para vários operadores, para o Helm — para o ecossistema. Infelizmente, não consigo acompanhar tudo o que fazemos e posso cometer erros, mas não temos nenhum pull request para o núcleo.
— Ao mesmo tempo, vocês desenvolvem muitas ferramentas em torno do Kubernetes?
Dmitry: A estratégia é a seguinte: vamos e fazemos pull requests em tudo o que já existe. Se os pull requests não são aceitos, apenas os forkeamos para nós mesmos e continuamos enquanto eles não forem aceitos com nossas versões. Depois, quando isso chega ao upstream, voltamos para a versão do upstream.
Por exemplo, temos o operador Prometheus, com o qual alternamos para a versão upstream da nossa construção cerca de 5 vezes, provavelmente. Precisamos de um recurso, enviamos um pull request, precisamos implementá-lo amanhã e não queremos esperar que ele seja lançado na versão upstream. Portanto, montamos nossa própria versão com o recurso que precisamos em todos os nossos clusters. Depois, isso é, por exemplo, incorporado ao upstream com as palavras: "Pessoal, vamos fazer isso para um caso mais geral", e nós, ou alguém, terminamos isso e, com o tempo, é novamente mesclado.
Tudo o que existe, tentamos desenvolver. Muitos elementos que ainda não existem, ainda não foram inventados ou foram, mas não conseguiram ser implementados — nós fazemos. E não porque gostamos do processo em si ou da construção de bicicletas como um setor, mas simplesmente porque precisamos dessa ferramenta. Frequentemente, nos perguntam por que fizemos isso ou aquilo? A resposta é simples — porque precisávamos avançar, resolver um problema prático, e resolvemos com essa ferramenta.
O caminho sempre é este: procuramos muito cuidadosamente e, se não encontramos nenhuma solução, como fazer um trólei a partir de um pão, então fazemos nosso próprio pão e nosso próprio trólei.
Ferramentas da Flant
— Sei que atualmente a Flant possui operadores addon, operadores shell, ferramentas dapp/werf. Como entendo, isso é a mesma ferramenta em diferentes encarnações. Também entendo que dentro da Flant há muitas outras ferramentas diferentes. É verdade?
Dmitry: Temos muitas outras coisas no GitHub. Desde o que consigo me lembrar agora, temos o statusmap — um painel para Grafana que todo mundo adora. Ele é mencionado praticamente em cada segundo artigo sobre monitoramento de Kubernetes no Medium. É impossível descrever brevemente o que é statusmap — precisa de um artigo separado, mas é uma coisa muito útil para monitorar o status ao longo do tempo, já que, no Kubernetes, muitas vezes precisamos mostrar o status ao longo do tempo. Também temos o LogHouse — uma solução baseada em ClickHouse e mágica negra para coletar logs no Kubernetes.
Muitas utilidades! E haverá ainda mais, pois algumas soluções internas serão lançadas este ano. Dentre as grandes, com base no operador addon, há uma série de addons para Kubernetes, como instalar corretamente o sert manager – uma ferramenta para gerenciar certificados, como instalar Prometheus com muitos complementos – são cerca de vinte binários diferentes que exportam dados e coletam informações, com Prometheus oferecendo gráficos incríveis e alertas. Todos esses são addons para Kubernetes que podem ser instalados no cluster, transformando-o de simples em avançado, automático, onde muitas questões já estão resolvidas. Sim, estamos fazendo muitas coisas.
Desenvolvimento do ecossistema
— Acredito que isso é uma contribuição muito grande para o desenvolvimento desta ferramenta e seus métodos de uso. Você pode estimar quem mais poderia fazer uma contribuição semelhante para o desenvolvimento do ecossistema?
Dmitry: Na Rússia, dentre as empresas que atuam no nosso mercado – ninguém chega nem perto.. Claro, é uma declaração ousada, pois há grandes players, como Mail e Yandex – eles também estão fazendo algo com Kubernetes, mas mesmo eles não se comparam à contribuição de empresas ao redor do mundo, que estão fazendo muito mais do que nós. É difícil comparar "Flant" com uma equipe de 80 pessoas e a Red Hat, que tem 300 engenheiros apenas para Kubernetes, se não me engano. É complicado comparar. Temos em nosso departamento de P&D 6 pessoas, incluindo eu, que desenvolvem todas as nossas ferramentas. 6 pessoas contra 300 engenheiros da Red Hat – é difícil fazer essa comparação.
— No entanto, quando mesmo essas 6 pessoas conseguem fazer algo realmente útil e transferível, ao se depararem com uma tarefa prática e entregarem a solução para a comunidade – é um caso interessante. Entendo que em grandes empresas de tecnologia, onde há desenvolvimento próprio e uma equipe de suporte para Kubernetes, ferramentas semelhantes podem ser desenvolvidas. Isso serve de exemplo para eles, de que é possível desenvolver e entregar à comunidade, impulsionando todo o ecossistema que utiliza Kubernetes.
Dmitry: Provavelmente, essa é uma característica do integrador, sua particularidade. Temos muitos projetos e vemos muitas situações diferentes. Para nós, a principal forma de gerar valor agregado é analisar esses casos, encontrar o que eles têm em comum e maximizar a redução de custos para nós. Estamos ativamente envolvidos nisso. É difícil falar sobre a Rússia e o mundo, mas temos cerca de 40 engenheiros DevOps na empresa que trabalham com Kubernetes. Não acredito que haja muitas empresas na Rússia com um número comparável de especialistas em Kubernetes, se é que existem.
Eu entendo tudo sobre o título de DevOps Engineer, todos entendem e se acostumaram a chamar os engenheiros DevOps de engenheiros DevOps, não vamos discutir isso. Todos esses 40 engenheiros DevOps incríveis enfrentam problemas diariamente e os resolvem, nós apenas analisamos essa experiência e tentamos generalizar. Sabemos que se isso permanecer conosco, em um ou dois anos a ferramenta se tornará inútil, porque algo aparecerá na comunidade. Não faz sentido acumular essa experiência internamente — é apenas um desperdício de esforço e tempo em dev/null. Assim, não nos importamos em compartilhar. Temos o prazer de publicar tudo e entendemos que isso deve ser divulgado, promovido, para que as pessoas possam usar e adicionar suas experiências — assim tudo cresce e vive. Então, em dois anos, a ferramenta não será jogada no lixo. Não hesitamos em continuar investindo esforço, porque é visível que alguém está usando sua ferramenta, e em dois anos, todos já a utilizam.
Essa é parte da nossa grande estratégia com dapp/werf.. Não lembro exatamente quando começamos a fazê-lo, parece que foi há uns 3 anos. Inicialmente, era tudo em shell. Foi um super proof of concept, resolvemos algumas de nossas questões particulares — deu certo! Mas com shell havia problemas, não era possível escalar, programar em shell é uma atividade complicada. Tínhamos o hábito de programar em Ruby, então, refizemos algumas coisas em Ruby, desenvolvemos, desenvolvemos, e nos deparamos com o fato de que a comunidade, as pessoas, que não dizem 'queremos ou não queremos', torcem o nariz para Ruby, por mais engraçado que pareça. Percebemos que deveríamos escrever tudo isso em Go, para simplesmente atender ao primeiro item da lista de verificação: A ferramenta DevOps deve ser um binário estático.Se vai ser Go ou não, isso não é tão importante, mas preferimos um binário estático escrito em Go.
Despendemos esforços para reescrever o dapp em Go e o chamamos de werf. O dapp não é mais suportado, não é mais desenvolvido, funciona em uma versão antiga, mas existe um caminho de upgrade absoluto que pode ser seguido.
Por que o dapp foi criado
— Você pode explicar brevemente por que o dapp foi criado e quais problemas ele resolve?
Dmitry: A primeira razão está na construção. Inicialmente, tivemos grandes problemas com a construção, quando o Docker não suportava multi-stage, e tivemos que implementar o multi-stage por conta própria. Em seguida, tivemos uma série de questões relacionadas à limpeza da imagem. Todos que fazem CI/CD enfrentam, mais cedo ou mais tarde, o problema de que há muitas imagens construídas, e é necessário limpar o que não é necessário, mantendo o que é.
A segunda razão está na implantação. Sim, existe o Helm, mas ele resolve apenas parte das questões. Por mais engraçado que pareça, está escrito que "Helm é o Gerenciador de Pacotes para Kubernetes". Exatamente isso, "o". Além disso, existem as palavras "Gerenciador de Pacotes" — qual é a expectativa usual de um Gerenciador de Pacotes? Dizemos: "Gerenciador de Pacotes — instale o pacote!" e esperamos que ele nos diga: "Pacote instalado".
É interessante que dizemos: "Helm, instale o pacote", mas quando ele responde que instalou, descobrimos que ele apenas iniciou a instalação — informou ao Kubernetes: "Inicie este item!", mas se começou ou não, se está funcionando ou não, o Helm não resolve essa questão.
Portanto, o Helm é apenas um pré-processador de texto que carrega dados no Kubernetes.
Mas dentro de qualquer implantação, queremos saber — o aplicativo foi implantado em produção ou não? Implantado em produção significa que o aplicativo foi lançado, uma nova versão foi implantada, e ela está lá, pelo menos não está falhando e responde corretamente. O Helm não resolve essa tarefa. Para resolver isso, é necessário despender muito esforço, pois é preciso dar uma ordem ao Kubernetes para implantar e acompanhar o que está acontecendo — se foi implantado ou não, se ocorreu a migração. Além disso, há várias tarefas relacionadas à implantação, limpeza e construção.
Planos
Ainda este ano vamos avançar com o desenvolvimento local. Queremos atingir o que antes era possível no Vagrant — digitar «vagrant up» e ter nossas máquinas virtuais prontas. Aspiramos chegar a um ponto onde, ao ter um projeto no Git, podemos escrever «werf up» e isso levanta uma cópia local do projeto, implantada em um mini-Kub local, com todos os diretórios conectados e prontos para desenvolvimento. Dependendo da linguagem de desenvolvimento, isso acontece de maneiras diferentes, mas, no entanto, a intenção é permitir um desenvolvimento local eficiente com arquivos montados.
O próximo passo para nós é investir fortemente na conveniência para os desenvolvedores.. Para que, com uma única ferramenta, possamos rapidamente levantar um projeto localmente, desenvolvê-lo, fazer push para o Git, e ele seja exatamente implantado no estágio ou nos testes, dependendo dos pipelines, e então, com a mesma ferramenta, ir para a produção. Esta unidade, unificação e reprodutibilidade da infraestrutura, do ambiente local até a produção, é um ponto muito importante para nós. Mas isso ainda não está disponível no werf — estamos apenas planejando.
Mas o caminho para o dapp/werf sempre foi o mesmo que no início com o Kubernetes. Enfrentamos problemas, encontramos soluções alternativas — inventamos algumas soluções usando shell, ou qualquer coisa. Depois, tentamos de alguma forma simplificar, generalizar e consolidar essas soluções em binários com os quais compartilhamos.
Há também outra perspectiva sobre toda essa história, com analogias.
Kubernetes é como um chassi de carro com motor. Não há portas, janelas, rádio, ou qualquer coisa — só a estrutura e o motor. E há o Helm — isso é o volante. Legal ter o volante, mas precisamos de um pino de direção, uma barra de direção, transmissão e rodas, sem os quais não dá.
No caso do werf — é mais um componente para o Kubernetes. Apenas agora temos na versão alfa do werf, por exemplo, o Helm é compilado internamente no werf, porque estamos cansados de fazer isso por conta própria. Há muitas razões para fazer isso e, em breve, vou explicar exatamente por que compilamos o Helm junto com o Tiller dentro do werf. .
Atualmente, o werf é um componente mais integrado. Recebemos um volante pronto, um pino de direção — eu não sou muito bom com carros, mas é um grande bloco que resolve um amplo espectro de tarefas. Não precisamos ficar procurando no catálogo, combinando uma peça com a outra, pensando em como fixá-las. Obtemos uma colheitadeira pronta, que resolve um grande conjunto de tarefas de imediato. Mas por dentro, é composto pelos mesmos componentes open-source, tudo ainda utiliza Docker para a construção, Helm para parte da funcionalidade, e há várias outras bibliotecas. É uma ferramenta integrada para obter rapidamente e convenientemente um ótimo CI/CD de forma prática.
É difícil manter o Kubernetes?
— Você menciona a experiência de que começaram a usar o Kubernetes, que para vocês é um quadro, um motor, e que é possível adicionar muitas coisas diferentes: um corpo, um volante, instalar pedais, assentos. Surge a questão — quão difícil é para vocês manter o Kubernetes? Vocês têm uma experiência rica, quanto tempo e recursos vocês precisam especificamente para a manutenção do Kubernetes em relação ao resto?
Dmitry: Esta é uma pergunta muito difícil e, para responder, é necessário entender o que significa manutenção e o que queremos do Kubernetes. Talvez você possa esclarecer?
— Pelo que sei e como vejo, muitas equipes agora querem experimentar o Kubernetes. Todos estão se envolvendo, instalando de maneira improvisada. Tenho a impressão de que as pessoas nem sempre entendem a complexidade desse sistema.
Dmitry: É verdade.
— Quão difícil é simplesmente pegar e instalar o Kubernetes do zero, para que ele esteja pronto para produção?
Dmitry: O que você acha, quão difícil é realizar uma cirurgia de coração? Entendo, a pergunta é embaraçosa. Utilizar um bisturi e não cometer erros — isso não é tão complicado. Se você sabe onde cortar e onde coser, a própria procedimento não é difícil. O complicado é garantir que tudo funcione a cada vez.
Instalar o Kubernetes e fazê-lo funcionar é simples: plim! — foi instalado, há muitas formas de instalação. Mas o que acontecerá quando surgirem problemas?
Sempre surgem questões — o que ainda não consideramos? O que ainda não fizemos? Quais parâmetros do núcleo do Linux especificamos incorretamente? Meu Deus, nós realmente os especificamos?! Quais componentes do Kubernetes instalamos e quais não? Surgem milhares de perguntas, e para respondê-las, é necessário ter 15-20 anos de experiência na indústria.
Eu tenho um exemplo recente sobre esse tema que pode esclarecer o problema "É difícil suportar o Kubernetes?". Faz algum tempo que consideramos seriamente a possibilidade de implementar o Cilium como rede no Kubernetes.
Deixe-me explicar o que é o Cilium. No Kubernetes, existem muitas implementações diferentes do subsistema de rede, e uma delas é muito interessante - o Cilium. Qual é a sua essência? No núcleo, surgiu a possibilidade de escrever hooks para o kernel, que de uma forma ou de outra interferem no subsistema de rede e em vários outros subsistemas, permitindo contornar grandes partes do kernel.
Historicamente, o kernel Linux possui ip rout, netfilter, bridges e muitos outros componentes antigos que têm 15, 20 ou 30 anos. Em geral, eles funcionam bem, tudo é ótimo, mas agora temos muitos containers e isso parece uma torre de 15 tijolos empilhados um sobre o outro, e você está em cima dela equilibrando-se em uma perna - uma sensação estranha. Este sistema se desenvolveu historicamente com muitas nuances, como um apêndice no organismo. Em algumas situações, há problemas de performance, por exemplo.
Há um BPF incrível e a possibilidade de escrever hooks para o kernel - os desenvolvedores escreveram seus próprios hooks para o kernel. O pacote chega ao kernel Linux, eles o retiram diretamente na entrada, processam como necessário sem bridges, sem TCP, sem stack IP - ou seja, contornando tudo que está escrito no kernel Linux e imediatamente o direcionam para o container.
Qual foi o resultado? Um desempenho incrível, recursos fantásticos - simplesmente maravilhoso! Mas olhamos para isso e vemos que em cada máquina há um programa que se conecta à API do Kubernetes e, com os dados que recebe dessa API, gera código C e compila binários que são carregados no kernel para que esses hooks funcionem no espaço do kernel.
O que acontecerá se algo der errado? Não sabemos. Para entender isso, é preciso ler todo esse código e compreender toda a lógica, e isso é extremamente complicado. Mas, por outro lado, existem essas bridges, netfilters, ip rout - eu não li seu código-fonte, e 40 engenheiros que trabalham em nossa empresa também não. Pode ser que apenas algumas pessoas entendam certas partes.
E qual é a diferença? Assim, existe o ip rout, o núcleo do Linux, e há uma nova ferramenta - qual é a diferença, não entendemos uma nem a outra. Mas temos medo de usar o novo - por quê? Porque se a ferramenta tem 30 anos, então ao longo de 30 anos todos os bugs foram descobertos, todos os erros foram cometidos e não é necessário saber sobre todos - funciona como uma caixa preta e sempre funciona. Todos sabem qual chave de fenda usar em qual lugar, qual tcpdump iniciar em qual momento. Todos conhecem bem as ferramentas de diagnóstico e entendem como esse conjunto de componentes funciona no núcleo do Linux - não como é organizado, mas como usá-lo.
Mas o incrível Cilium não tem 30 anos, ele ainda não foi testado. O mesmo problema com o Kubernetes, cópia. Tanto o Cilium é instalado perfeitamente, quanto o Kubernetes é instalado perfeitamente, mas, quando algo der errado na produção, você conseguirá entender rapidamente, em uma situação crítica, o que deu errado?
Quando falamos se é difícil manter o Kubernetes - não, é muito simples, e sim, é incrivelmente complicado. O Kubernetes funciona perfeitamente por si só, mas com bilhões de nuances.
Sobre a abordagem 'Vou ter sorte'
— Existem empresas onde essas nuances quase garantidamente aparecerão? Suponha que o Yandex de repente transfira todos os serviços para o Kubernetes, lá haverá uma carga enorme.
Dmitry: Não, essa conversa não é sobre carga, mas sobre coisas simples. Por exemplo, temos o Kubernetes, implantamos uma aplicação lá. Como sabemos se ela está funcionando? Não existe uma ferramenta pronta para entender se a aplicação não está falhando. Não há um sistema pronto que envia alertas - precisamos configurar esses alertas e cada gráfico. E nós estamos atualizando o Kubernetes.
Temos Ubuntu 16.04. Pode-se dizer que é uma versão antiga, mas ainda estamos nela porque é LTS. Ela possui systemd, cuja particularidade é que não limpa os C-groups. O Kubernetes inicia pods, cria C-groups, depois exclui os pods, e assim acaba acontecendo — não me lembro dos detalhes, desculpe — que restam fatias do systemd. Isso leva a que, com o tempo, qualquer máquina comece a apresentar lentidão significativa. Não é nem uma questão de highload. Se pods constantes forem iniciados, por exemplo, se houver um Cron Job que gera continuamente pods, a máquina com Ubuntu 16.04 começará a travar em uma semana. Haverá sempre uma alta carga média devido ao grande número de C-groups criados. Este é um problema que qualquer pessoa que simplesmente instalar Ubuntu 16 e rodar Kubernetes enfrentará.
Suponha que ele atualize de alguma forma o systemd ou outra coisa, mas no núcleo do Linux até a versão 4.16 a situação é ainda mais engraçada — ao remover C-groups, eles persistem no núcleo e, na verdade, não são removidos. Portanto, após um mês de uso desta máquina, não será possível olhar as estatísticas de memória dos pods. Nós pegamos um arquivo, fazemos processamento nele e um arquivo leva 15 segundos porque o núcleo demora muito para calcular internamente milhões de C-groups que supostamente foram excluídos, mas na verdade não — eles persistem.
Ainda há muitos desses pequenos detalhes por aqui e ali. Não é uma questão que empresas gigantes podem ocasionalmente enfrentar sob grandes cargas — não, é uma questão do dia a dia. As pessoas podem viver assim por meses — instalaram o Kubernetes, implementaram a aplicação — parece que funciona. Para muitos, isso está ok. Quanto ao fato de que em algum momento essa aplicação pode cair sem explicação, eles nem vão saber, nenhum alerta chegará, mas para eles isso é normal. Antes viviam em máquinas virtuais sem monitoramento, agora mudaram para o Kubernetes também sem monitoramento — qual é a diferença?
A questão é que quando andamos sobre o gelo, nunca sabemos a sua espessura, a menos que tenhamos medido antes. Muitos andam e não se preocupam, porque já andaram anteriormente.
Na minha visão, a nuance e a complexidade na operação de qualquer sistema está em garantir que a espessura do gelo seja suficiente para resolver nossas tarefas. É sobre isso.
Na tecnologia, parece que existem muitas abordagens do tipo "Vou ter sorte". Muitos instalam softwares e usam bibliotecas na esperança de que terão sorte. No geral, muitos têm sorte. Provavelmente é por isso que isso funciona.
— Na minha avaliação pessimista, parece que: quando os riscos são altos e o aplicativo precisa funcionar, é necessária uma assistência da "Flant", possivelmente da Red Hat, ou é necessário ter uma equipe interna dedicada especificamente ao Kubernetes que esteja pronta para mantê-lo.
Dmitry: Objetivamente, é assim. Envolver uma pequena equipe na jornada do Kubernetes envolve um certo nível de riscos.
Precisamos de containers?
— Você pode contar o quão difundido o Kubernetes é na Rússia?
Dmitry: Eu não tenho esses dados e não estou certo de que alguém os tenha de fato. Dizemos: "Kubernetes, Kubernetes", mas há outro ponto de vista sobre essa questão. Não sei o quão difundidos são os containers, mas conheço um número de relatórios na internet que indicam que 70% dos containers são orquestrados pelo Kubernetes. Essa foi uma fonte confiável com uma amostra bastante abrangente em todo o mundo.
A próxima pergunta é: precisamos de containers? Tenho a sensação pessoal e, de maneira geral, a posição da empresa "Flant" é que o Kubernetes é o padrão de fato.
Nada além do Kubernetes existirá.
É um verdadeiro divisor de águas na gestão de infraestrutura. Absolutamente — chega de Ansible, Chef, máquinas virtuais, Terraform. E não estou nem falando de métodos antigos e arcaicos. Kubernetes é um verdadeiro divisor de águas, e agora será somente assim.
É claro que algumas pessoas levarão alguns anos, enquanto outras levarão décadas para perceber isso. Não tenho dúvidas de que não haverá nada além do Kubernetes e dessa nova abordagem: não estaremos mais tocando o sistema operacional, mas usando infraestrutura como código, mas não com código, e sim com yml — infraestrutura descrita de forma declarativa. Tenho a sensação de que assim será para sempre.
— Ou seja, as empresas que ainda não migraram para o Kubernetes definitivamente estarão obrigadas a fazê-lo ou acabarão esquecidas. Estou entendendo corretamente?
Dmitry: Isso também não está totalmente correto. Por exemplo, se temos a tarefa de iniciar um servidor DNS, ele pode ser executado no FreeBSD 4.10 e pode funcionar perfeitamente por 20 anos. Apenas funcionar e pronto. Talvez ao longo de 20 anos, algo precise ser atualizado uma vez. Se estamos falando sobre software que foi iniciado e realmente funciona por muitos anos sem atualizações, sem alterações, então, claro, não haverá Kubernetes. Ele não é necessário.
Tudo que diz respeito a CI/CD - em todos os lugares onde é necessário Continuous Delivery, onde é preciso atualizar versões, fazer alterações ativas, em todos os lugares onde é necessário construir resiliência - apenas Kubernetes.
Sobre microsserviços
— Aqui eu tenho um pequeno dissonância. Para trabalhar com Kubernetes, é necessário suporte externo ou interno - esse é o primeiro ponto. O segundo - quando estamos apenas começando o desenvolvimento, somos uma pequena startup, não temos nada ainda, desenvolver para Kubernetes ou mesmo para uma arquitetura de microsserviços pode ser complicado e nem sempre justificado economicamente. Estou interessado na sua opinião - startups devem começar imediatamente a escrever para Kubernetes desde o início ou ainda é possível escrever um monolito e depois apenas migrar para Kubernetes?
Dmitry: Ótima pergunta. Eu tenho uma palestra sobre microsserviços Eu já me deparei várias vezes com pessoas tentando pregar pregos com um microscópio. O próprio approach é correto, nós mesmos projetamos nosso software interno exatamente dessa maneira. Mas quando você faz isso, é necessário entender claramente o que está fazendo. O que eu mais odeio em microsserviços é a palavra “micro”. Historicamente, surgiram com essa palavra, e por algum motivo as pessoas pensam que micro é muito pequeno, menor que um milímetro, como um micrômetro. Não é assim.
Por exemplo, há um monolito que está sendo escrito por 300 pessoas, e todos que participaram do desenvolvimento entendem que há problemas e que ele precisa ser quebrado em micro partes - cerca de 10, cada uma das quais é escrita por pelo menos 30 pessoas. Isso é importante, necessário e incrível. Mas quando uma startup nos apresenta 3 jovens muito legais e talentosos que escreveram 60 microsserviços de forma improvisada, eu sempre procuro por calmantes.
Parece que já falamos sobre isso milhares de vezes — acabamos por obter um monólito distribuído de alguma forma. Isso não é economicamente viável, é extremamente complicado. Eu já vi isso tantas vezes que chega a doer, por isso continuo falando sobre o assunto.
Voltando à pergunta inicial, há um conflito entre o fato de que, por um lado, usar Kubernetes é assustador, pois não está claro o que pode falhar ou não funcionar, e, por outro lado, é evidente que tudo está indo nessa direção e nada além do Kubernetes existirá. A resposta é: pesar o volume de benefícios que vem, a quantidade de tarefas que você pode resolver.. Esse é um lado da balança. Do outro lado estão os riscos associados ao tempo de inatividade ou à diminuição do tempo de resposta, do nível de disponibilidade — à diminuição dos indicadores de desempenho.
A situação é a seguinte — ou nos movemos rapidamente, e o Kubernetes permite realizar muitas coisas muito mais rápido e melhor, ou usamos soluções confiáveis, testadas pelo tempo, mas avançamos muito mais devagar. Essa escolha deve ser feita por cada empresa. Pode-se considerar isso como um caminho na selva — quando você vai pela primeira vez, pode encontrar uma cobra, um tigre ou um texugo feroz, mas quando você já foi 10 vezes — você abriu a trilha, retirou os galhos e fica mais fácil de passar. A cada vez, a trilha fica mais larga. Depois disso, já é uma estrada pavimentada, e mais tarde, um belo boulevard.
O Kubernetes não para no tempo. Novamente a questão: o Kubernetes, por um lado, são 4-5 binários, e por outro — é todo um ecossistema. É o sistema operacional que temos nas máquinas. O que é isso? Ubuntu ou Curios? É o núcleo do Linux, uma porção de componentes adicionais. Todas essas coisas aqui jogaram uma cobra venenosa para fora da estrada, e lá colocaram uma cerca. O Kubernetes está se desenvolvendo muito rapidamente e dinamicamente, e o volume de riscos, a quantidade de desconhecido diminui a cada mês e, consequentemente, essas balanças se reequilibram.
Respondendo à pergunta sobre o que fazer um startup, eu diria: venha para a "Flant", pague 150 mil rublos e obtenha um serviço fácil de DevOps chave na mão. Se você é um pequeno startup com alguns desenvolvedores, isso funciona. Em vez de contratar seu próprio DevOps, que precisaria aprender a resolver seus problemas e receber um salário durante esse tempo, você receberá a solução para todas as questões chave na mão. Sim, existem algumas desvantagens. Nós, como prestadores de serviços, não podemos estar tão envolvidos e reagir rapidamente às mudanças. Mas, por outro lado, temos uma enorme quantidade de expertise e práticas prontas. Garantimos que, em qualquer situação, vamos resolver tudo rapidamente e levantar qualquer Kubernetes do inferno.
Eu recomendo categoricamente a terceirização para startups e negócios já estabelecidos até o ponto em que você pode alocar uma equipe de 10 pessoas para operações, porque, caso contrário, não há sentido. Faz todo o sentido terceirizar.
Sobre a Amazon e o Google
— Pode-se considerar a hospedagem como uma terceirização pela solução da Amazon ou do Google?
Dmitry: Sim, com certeza, isso resolve algumas questões. Mas de novo, há nuances. Você ainda precisa entender como usar isso. Por exemplo, há mil detalhes no funcionamento da Amazon AWS: o Load Balancer precisa ser aquecido ou você precisa solicitar de antemão, dizendo: "pessoal, teremos tráfego, aqueçam nosso Load Balancer!" Essas nuances precisam ser conhecidas.
Quando você se dirige a pessoas que se especializam nisso, você obtém quase todas as coisas padrão atendidas. Temos atualmente 40 engenheiros, e até o final do ano, provavelmente teremos 60 — com certeza já enfrentamos todos esses problemas. Mesmo se em algum projeto voltarmos a nos deparar com esse problema, já perguntamos rapidamente uns aos outros e sabemos como resolver.
Provavelmente, a resposta é que, com certeza, uma solução hospedada facilita uma parte disso. A questão é se você está pronto para confiar nesses provedores de hospedagem e se eles resolverão seus problemas. Amazon e Google têm uma boa reputação. Para todos os nossos casos - com certeza. Não temos mais experiências positivas. Todos os outros clouds com os quais tentamos trabalhar criam muitos problemas - tanto Ager quanto tudo o que existe na Rússia, e várias implementações do OpenStack: Headster, Overage - tudo o que você quiser. Todos eles criam problemas que não queremos resolver.
Portanto, a resposta é sim, mas, na prática, existem poucos serviços hospedados maduros.
Quem precisa do Kubernetes?
— Mas afinal, quem precisa do Kubernetes? Quem deve realmente migrar para o Kubernetes, quem é o cliente típico da "Flante" que vem especificamente em busca do Kubernetes?
Dmitry: A questão é interessante, porque atualmente, com a onda do Kubernetes, muitos estão chegando até nós: "Pessoal, sabemos que vocês trabalham com Kubernetes, façam para nós!". Nós respondemos: "Senhores, não fazemos Kubernetes, nós gerenciamos produção e tudo que está relacionado a isso". Porque implementar produção sem configurar todo o CI/CD e toda essa história é simplesmente impossível no momento. Todos abandonaram o conceito de que temos desenvolvimento separado da operação.
Nossos clientes esperam coisas diferentes, mas todos aguardam por algum tipo de milagre, acreditando que têm certos problemas, e agora — voilà! — o Kubernetes os resolverá. As pessoas acreditam em milagres. Compreendem racionalmente que não haverá um milagre, mas esperam com o coração — e se o Kubernetes resolver tudo para nós, já que falam tanto sobre isso! E se ele agora fosse o toque mágico — e, puff! — tivéssemos 100% de uptime, todos os desenvolvedores poderiam fazer 50 lançamentos de qualquer coisa na produção e tudo funcionaria. Enfim, um milagre!
Quando essas pessoas vêm até nós, dizemos: "Desculpe, mas milagres não existem". Para ser saudável, você precisa se alimentar bem e praticar esportes. Para ter uma produção confiável, você deve construí-la de forma robusta. Para ter um CI/CD eficiente, ele deve ser elaborado corretamente. Isso requer muito trabalho.
Respondendo à pergunta de quem precisa do Kubernetes — o Kubernetes não é necessário para ninguém.
Algumas pessoas têm a ideia errônea de que precisam do Kubernetes. As pessoas querem profundamente parar de se preocupar, se envolver e se interessar por todos os problemas de infraestrutura e pelo lançamento de seus aplicativos. Elas desejam que os aplicativos simplesmente funcionem e sejam implantados sem complicações. Para elas, o Kubernetes é a esperança de que elas não ouvirão mais histórias como "estamos enfrentando dificuldades" ou "não conseguimos lançar", ou qualquer outra coisa.
Geralmente, um diretor técnico nos procura. Ele é questionado sobre duas coisas: de um lado, funcionalidades, e do outro, estabilidade. Nós oferecemos assumir isso e resolver. A verdadeira deixa mágica é que você deixará de se preocupar com esses problemas e perder tempo. Você terá pessoas especializadas que cuidarão dessa questão.
A formulação de que precisamos do Kubernetes ou de alguém é errada.
O Kubernetes é muito necessário para os administradores, porque é um brinquedo muito interessante, com o qual podemos brincar e explorar. Vamos ser honestos – todos amam brinquedos. Todos nós ainda somos crianças em algum lugar, e quando vemos um novo brinquedo, queremos brincar com ele. Alguns já perderam esse interesse, especialmente na administração, porque já brincaram o suficiente e estão cansados, a ponto de não querer mais. Mas ninguém perdeu completamente esse interesse. Por exemplo, se eu já estou cansado de brinquedos na área de administração de sistemas e DevOps, eu ainda amo brinquedos e continuo comprando algumas novidades. As pessoas, de uma forma ou de outra, ainda querem algum tipo de brinquedo.
Não brinque com produção. O que eu categoricamente não recomendo fazer e o que vejo atualmente em massa: "Ah, um novo brinquedo!" – todos correm para comprá-lo, compram e: "Vamos levá-lo para a escola agora e mostrar a todos os amigos". Não faça isso. Peço desculpas, meus filhos estão crescendo, estou constantemente vendo algo neles, percebendo isso em mim e depois generalizando isso em relação aos outros.
Resposta final: você não precisa do Kubernetes. Você precisa resolver seus problemas.
Você pode alcançar que:
- o produção não cai;
- mesmo que esteja tentando cair, sabemos disso com antecedência e podemos intervir;
- podemos mudá-lo na velocidade que precisamos para os negócios, e fazer isso de forma conveniente, o que não nos causa problemas.
As necessidades reais são duas: confiabilidade e dinamismo / flexibilidade na implementação. Todos que estão atualmente fazendo projetos de TI, não importa em qual negócio – software para facilitar o mundo, e aqueles que entendem isso, precisam resolver essas necessidades. O Kubernetes, com a abordagem correta, a compreensão adequada e experiência suficiente, permite resolver esses problemas.
Sobre serverless
– Se olharmos um pouco mais adiante, tentando resolver o problema da ausência de dor de cabeça com a infraestrutura, a velocidade de implementação e a velocidade de mudança de aplicativo, surgem novas soluções, como o serverless. Você vê algum potencial nesse sentido e, digamos, um risco para o Kubernetes e soluções semelhantes?
Dmitry: Aqui é necessário fazer novamente uma observação de que eu não sou um vidente que olha para a frente e diz - será assim! Embora eu tenha acabado de fazer a mesma coisa. Eu olho para baixo e vejo um monte de problemas, como os transistores funcionam em um computador. É ridículo, não é? Estamos enfrentando alguns bugs na CPU.
Fazer serverless de forma confiável, barata, eficiente e conveniente, resolvendo todas as questões de ecossistema. Aqui eu concordo com Elon Musk que precisamos de um segundo planeta para garantir a resiliência da humanidade. Embora eu não saiba o que ele está dizendo, entendo que não estou pronto para voar para Marte e que isso não acontecerá amanhã.
Com o serverless fica claro que é uma ideia ideologicamente correta, assim como a resiliência para a humanidade - ter dois planetas é melhor do que um. Mas como fazer isso agora? Enviar uma expedição não é um problema, se concentrarmos esforços nisso. Mandar várias expedições e colonizar lá várias milhares de pessoas, eu acho que também é realista. Mas criar uma resiliência total, de modo que metade da humanidade viva lá, me parece atualmente impossível e não viável.
Com serverless é a mesma coisa: é uma ideia incrível, mas está longe dos problemas de 2019. Mais perto de 2030 - vamos viver até lá. Não tenho dúvidas de que viveremos, com certeza viveremos (repitam antes de dormir), mas agora precisamos resolver outros problemas. É como acreditar em um pônei mágico chamado Arco-Íris. Sim, alguns casos são resolvidos, e são resolvidos muito bem, mas, subjetivamente, serverless é um arco-íris… Para mim, este tema está muito distante e é muito incompreensível. Não estou pronto para falar. Em 2019, não se pode escrever um aplicativo com serverless.
Como o Kubernetes se desenvolverá
— Enquanto caminhamos em direção a esse potencial futuro maravilhoso, como você acha que o Kubernetes e o ecossistema ao seu redor se desenvolverão?
Dmitry: Eu pensei muito sobre isso e tenho uma resposta clara. Primeiro — statefull — na verdade, é mais fácil fazer stateless. O Kubernetes inicialmente investiu mais nisso, foi de onde tudo começou. Stateless funciona praticamente perfeitamente no Kubernetes, simplesmente não há do que reclamar. Em relação a statefull, ainda há muitos problemas ou, melhor dizendo, nuances. Já funciona muito bem para nós, mas somos nós. Para que isso funcione para todos, levará no mínimo mais alguns anos. Essa não é uma métrica exata, mas é minha sensação.
Em resumo, statefull precisa se desenvolver muito — e vai — porque todas as nossas aplicações armazenam estado, não existem aplicações stateless. Isso é uma ilusão, sempre precisamos de algum banco de dados e algo mais. Statefull é o endireitamento de tudo o que é possível, a correção de todos os bugs e a melhoria de todos os problemas que estamos enfrentando — vamos chamar isso de adoção.
O nível do desconhecido, o nível dos problemas não resolvidos, o nível da probabilidade de encontrar algo, vai cair drasticamente. Essa é uma história importante. E os operadores — tudo que está relacionado à codificação da lógica de administração, da lógica de gerenciamento, para obter serviços fáceis: serviço fácil de MySQL, serviço fácil de RabbitMQ, serviço fácil de Memcache — todos esses componentes que precisamos para garantir que funcionem logo de cara. Isso resolve exatamente as dores de que queremos um banco de dados, mas não queremos administrá-lo, ou queremos Kubernetes, mas não queremos administrá-lo.
Essa questão do desenvolvimento de operadores de alguma maneira será importante nos próximos anos.
Acredito que a simplicidade de operação deve aumentar muito — a caixa vai se tornar cada vez mais e mais simples, cada vez mais e mais confiável, com controles cada vez mais simples.
Um dia, ouvi uma velha entrevista de Isaac Asimov dos anos 80 no YouTube no show Saturday Night Live — um programa tipo o de Urgant, mas interessante. Ele foi perguntado sobre o futuro dos computadores. Ele disse que o futuro está na simplicidade, como era com o rádio. O rádio era inicialmente uma coisa complicada. Para sintonizar uma frequência, era preciso girar os controles por 15 minutos, mexer aqui e ali e entender como tudo funcionava, compreendendo a física da transmissão das ondas de rádio. No final, ficou apenas um controle no rádio.
Qual rádio temos agora, em 2019? No carro, o rádio capta todas as ondas e nomes das estações. A física do processo não mudou em 100 anos, apenas a facilidade de uso. Agora, e não apenas agora, já em 1980, quando houve a entrevista com Asimov, todos usavam rádio e ninguém pensava em como ele funcionava. Ele sempre funcionou - isso é um fato.
Naquela época, Asimov disse que com os computadores seria semelhante - a facilidade de uso aumentará. Se em 1980 era necessário ter uma educação especial para apertar botões em um computador, no futuro isso não será mais o caso.
Eu sinto que com o Kubernetes e a infraestrutura a facilidade de uso também vai aumentar muito. Isso, para mim, é evidente - está na superfície.
O que fazer com os engenheiros?
— E o que acontecerá com os engenheiros, administradores de sistemas, que suportam o Kubernetes?
Dmitry: E o que aconteceu com os contadores após o surgimento do 1C? Mais ou menos a mesma coisa. Antes, contava-se no papel - agora é em um programa. A produtividade aumentou exponencialmente, mas o trabalho não desapareceu. Se antes eram necessários 10 engenheiros para trocar uma lâmpada, agora basta um.
A quantidade de software e o número de tarefas, me parece, estão crescendo mais rapidamente do que surgem novos DevOps e aumenta a eficiência. Atualmente, há uma escassez específica no mercado que durará muito tempo. Mais tarde, tudo voltará a uma certa normalidade, onde a eficiência do trabalho aumentará, haverá cada vez mais serverless, o Kubernetes será integrado a uma inteligência neural que ajustará todos os recursos exatamente como necessário e, de fato, fará tudo sozinha - o ser humano deve se afastar e não atrapalhar.
Mas as decisões ainda precisarão ser tomadas por alguém. É claro que o nível de qualificação e a especialização dessa pessoa são mais altos. Agora, no departamento de contabilidade, você não precisa de 10 funcionários que mantenham os livros contábeis para que suas mãos não se cansem. Isso simplesmente não é necessário. Muitos documentos são escaneados automaticamente, reconhecidos pelo sistema de gerenciamento de documentos eletrônicos. Basta um contador-chefe inteligente, já com habilidades muito maiores, com um bom entendimento.
De forma geral, esse é o caminho em todos os setores. Com os carros é o mesmo: antes, um carro vinha acompanhado de um mecânico e três motoristas. Hoje, dirigir um carro é um processo simples, no qual todos nós participamos todos os dias. Ninguém pensa que um carro é algo complexo.
DevOps ou engenharia de sistemas não vão a lugar nenhum – a alta complexidade e a eficiência do trabalho vão aumentar.
— Eu também ouvi uma ideia interessante de que, na verdade, o trabalho vai aumentar.
Dmitry: Claro, cem por cento! Porque a quantidade de software que escrevemos cresce constantemente. A quantidade de questões que resolvemos com o software cresce constantemente. O volume de trabalho está aumentando. Atualmente, o mercado de DevOps está muito aquecido. Isso é visível nas expectativas salariais. De forma ideal, sem entrar em detalhes, deveria haver juniores querendo X, intermediários querendo 1,5X e seniores querendo 2X. Mas agora, se olhar para o mercado de salários de DevOps em Moscovo, um júnior quer entre X e 3X e um sênior quer entre X e 3X.
Ninguém sabe quanto custa. O nível salarial é medido pela sua confiança – é uma completa loucura, para ser honesto, um mercado extremamente aquecido.
Claro, essa situação vai mudar muito em breve – deve haver algum tipo de saturação. No desenvolvimento de software não é assim – apesar de que os desenvolvedores são sempre necessários, e bons desenvolvedores são sempre necessários, o mercado entende quem vale quanto – a indústria se estabilizou. Com DevOps, atualmente, não é assim.
— Do que eu ouvi, cheguei à conclusão de que o atual administrador de sistemas não deve se preocupar muito, mas é hora de aprimorar as habilidades e se preparar para o fato de que amanhã haverá mais trabalho, mas será mais qualificado.
Dmitry: Com certeza. No geral, estamos vivendo em 2019 e a regra de vida é: aprendizado ao longo da vida – nós aprendemos a vida toda. Para mim, parece que agora isso já é algo que todos sabem e sentem, mas não basta saber – é preciso agir. Todos os dias devemos mudar. Se não fazemos isso, mais cedo ou mais tarde seremos deixados pelo caminho da profissão.
Esteja preparado para mudanças bruscas de 180 graus. Não descarto a possibilidade de que algo mude radicalmente, que criem algo novo — isso acontece. De repente! — e agora agimos de maneira diferente. É importante estar pronto para isso e não se preocupar. Pode acontecer que amanhã tudo o que eu faço se torne desnecessário — tudo bem, eu aprendi a vida inteira e estou pronto para aprender algo novo. Isso não é um problema. Não se deve temer a segurança no emprego, mas é necessário estar preparado para aprender constantemente algo novo.
Desejos e um momento de publicidade
— Você tem algum desejo?
Dmitry: Sim, eu tenho alguns desejos.
O primeiro e mais comercial — inscreva-se em . Caros leitores, acessem o YouTube e se inscrevam no nosso canal. Daqui a cerca de um mês, começaremos uma expansão ativa no serviço de vídeo, teremos uma tonelada de conteúdo educativo sobre Kubernetes, tanto aberto quanto variado: desde coisas práticas, até laboratórios, até conceitos teóricos profundos e como aplicar Kubernetes em nível de princípios e padrões.
O segundo desejo comercial — acessem e deixem estrelas, porque nós dependemos delas. Se vocês não nos derem estrelas, não teremos o que comer. É como o maná em um jogo de computador. Nós fazemos algo, fazemos, nos esforçamos, alguns dizem que são bicicletas horríveis, outros que tudo está completamente errado, mas continuamos e agimos de maneira completamente honesta. Vemos o problema, o resolvemos e compartilhamos a experiência. Portanto, deixem-nos uma estrela, não vai custar nada para vocês e nos ajudará, pois dependemos delas.
O terceiro, e já não comercial, desejo importante — parem de acreditar em contos de fadas. Vocês são profissionais. DevOps é uma profissão muito séria e responsável. Parem de brincar no trabalho. Que isso os faça refletir e perceberem isso. Imagine que você vai a um hospital e o médico está experimentando com você. Entendo que isso pode desagradá-lo, mas, provavelmente, não é sobre você, e sim sobre outra pessoa. Digam aos outros para também pararem. Isso realmente estraga a vida para todos nós — muitos começam a ver a operação, os administradores e os DevOps como pessoas que quebraram algo novamente. Esse "quebrar" muitas vezes se dá porque começamos a brincar ao invés de observar com a mente fria o que está aqui e o que está ali.
Isso não significa que não devemos experimentar. Devemos experimentar, é o que fazemos. Para ser honesto, às vezes nós mesmos brincamos — isso, claro, é muito ruim, mas nada humano nos é estranho. Vamos declarar 2019 o ano de experimentos sérios e bem pensados, e não de brincadeiras no ambiente de produção. Provavelmente, é isso.
— Muito obrigado!
Dmitry: Obrigado a você, Vitaly, pelo tempo e pela entrevista. Caros leitores, muito obrigado, se vocês chegaram até este ponto. Espero que tenhamos trazido pelo menos algumas reflexões para vocês.
Na entrevista, Dmitry abordou a questão do werf. Atualmente, é uma chave suíça universal que resolve quase todas as tarefas. Mas nem sempre foi assim. No festival, Dmitry Stolyarov irá falar sobre esta ferramenta em detalhes. Na palestra terá tudo: problemas e nuances ocultas do Kubernetes, opções para resolver essas dificuldades e a implementação atual do werf em detalhes. Junte-se a nós nos dias 27 e 28 de maio, estaremos criando ferramentas ideais.
Fonte: habr.com
