Em antecipação Vitaly Khabarov entrevistado Dmitri Stolyarov (), diretor técnico e cofundador da empresa Flant. Vitaly perguntou a Dmitry sobre o que Flant faz, sobre Kubernetes, desenvolvimento de ecossistemas, suporte. Discutimos por que o Kubernetes é necessário e se ele é realmente necessário. E também sobre microsserviços, Amazon AWS, a abordagem “Terei sorte” para DevOps, o futuro do próprio Kubernetes, por que, quando e como ele dominará o mundo, as perspectivas do DevOps e o que os engenheiros devem se preparar no futuro brilhante e próximo com simplificação e redes neurais.
ouça um podcast sobre DevOps Deflop - um podcast em russo sobre DevOps, e abaixo está a versão em texto.
Aqui e abaixo ele faz perguntas engenheiro da Express42.
Sobre "Flant"
- Olá Dima. Você é o diretor técnico "" e também seu fundador. Por favor, diga-nos o que a empresa faz e o que você faz nela?
Dmitry: Do lado de fora, parece que somos nós que instalamos o Kubernetes para todos e fazemos algo com ele. Mas isso não é verdade. Começamos como uma empresa que lida com Linux, mas há muito tempo nossa principal atividade tem sido atender projetos turnkey de produção e alta carga. Normalmente construímos toda a infraestrutura do zero e depois somos responsáveis por ela por muito, muito tempo. Portanto, o principal trabalho que “Flant” faz, pelo qual recebe dinheiro, é assumindo a responsabilidade e implementando a produção turnkey.
Eu, como diretor técnico e um dos fundadores da empresa, passo dia e noite tentando descobrir como aumentar a acessibilidade da produção, simplificar seu funcionamento, facilitar a vida dos administradores e a vida dos desenvolvedores mais agradável .
Sobre o Kubernetes
— Ultimamente tenho visto muitos relatos de Flant e sobre Kubernetes. Como você chegou a isso?
Dmitry: Já falei sobre isso muitas vezes, mas não me importo de repetir. Acho correto repetir este tópico porque há confusão entre causa e efeito.
Nós realmente precisávamos de uma ferramenta. Enfrentamos muitos problemas, lutamos, superamos com diversas muletas e sentimos necessidade de uma ferramenta. Passamos por muitas opções diferentes, construímos nossas próprias bicicletas e ganhamos experiência. Gradualmente chegamos ao ponto em que começamos a usar o Docker quase assim que ele apareceu – por volta de 2013. Na época de seu surgimento, já tínhamos muita experiência com containers, já havíamos escrito um análogo do “Docker” - algumas de nossas próprias muletas em Python. Com o advento do Docker, tornou-se possível abandonar as muletas e usar uma solução confiável e apoiada pela comunidade.
Com o Kubernetes a história é semelhante. No momento em que começou a ganhar impulso - para nós esta é a versão 1.2 - já tínhamos um monte de muletas no Shell e no Chef, que de alguma forma tentamos orquestrar com o Docker. Estávamos olhando seriamente para o Rancher e várias outras soluções, mas então apareceu o Kubernetes, em que tudo é implementado exatamente como teríamos feito ou até melhor. Não há nada do que reclamar.
Sim, há algum tipo de imperfeição aqui, há algum tipo de imperfeição ali - há muitas imperfeições e 1.2 geralmente é terrível, mas... Kubernetes é como um prédio em construção - você olha para o projeto e entende que vai ser legal. Se o prédio agora tem alicerce e dois andares, então você entende que é melhor não se mudar ainda, mas não há problemas com o software - você já pode usá-lo.
Não tivemos um momento em que pensamos em usar ou não o Kubernetes. Estávamos esperando por isso muito antes de aparecer e tentamos criar nós mesmos análogos.
Sobre o Kubernetes
— Você está diretamente envolvido no desenvolvimento do próprio Kubernetes?
Dmitry: Medíocre. Em vez disso, participamos no desenvolvimento do ecossistema. Enviamos um certo número de solicitações pull: para o Prometheus, para vários operadores, para o Helm - para o ecossistema. Infelizmente, não sou capaz de acompanhar tudo o que fazemos e posso estar errado, mas não há um único pool nosso no núcleo.
— Ao mesmo tempo, você desenvolve muitas de suas ferramentas em torno do Kubernetes?
Dmitry: A estratégia é esta: vamos e puxamos solicitações para tudo que já existe. Se pull requests não forem aceitos lá, nós simplesmente os bifurcaremos e viveremos até que sejam aceitos em nossas compilações. Então, quando chegar ao upstream, voltamos para a versão upstream.
Por exemplo, temos um operador Prometheus, com o qual já alternamos para o upstream de nossa montagem provavelmente 5 vezes. Precisamos de algum tipo de recurso, enviamos uma solicitação pull, precisamos lançá-lo amanhã, mas não queremos esperar que seja lançado no upstream. Conseqüentemente, montamos para nós mesmos, implementamos nossa montagem com nosso recurso, que precisamos por algum motivo, para todos os nossos clusters. Aí, por exemplo, eles nos entregam no upstream com as palavras: “Gente, vamos fazer isso para um caso mais geral”, nós, ou outra pessoa, terminamos e com o tempo ele se funde novamente.
Tentamos desenvolver tudo o que existe. Muitos elementos que ainda não existem, ainda não foram inventados, ou foram inventados, mas não tiveram tempo de serem implementados - estamos fazendo isso. E não porque gostemos do processo ou da construção de bicicletas como indústria, mas simplesmente porque precisamos desta ferramenta. Muitas vezes se pergunta: por que fizemos isso ou aquilo? A resposta é simples - sim, porque tínhamos que ir mais longe, resolver algum problema prático, e resolvemos com esta tula.
O caminho é sempre assim: pesquisamos com muito cuidado e, se não encontrarmos nenhuma solução de como fazer um trólebus com um pão, então fazemos o nosso próprio pão e o nosso próprio trólebus.
Ferramentas Flanta
— Eu sei que Flant agora tem operadores addon, operadores shell e ferramentas dapp/werf. Pelo que entendi, este é o mesmo instrumento em diferentes encarnações. Também entendo que existem muitas outras ferramentas diferentes no Flaunt. Isto é verdade?
Dmitry: Temos muito mais no GitHub. Pelo que me lembro agora, temos um mapa de status - um painel para Grafana que todos já encontraram. É mencionado em quase todos os artigos sobre monitoramento do Kubernetes no Medium. É impossível explicar brevemente o que é um mapa de status - ele precisa de um artigo separado, mas é 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 LogHouse - algo baseado em ClickHouse e magia negra para coletar logs no Kubernetes.
Muitas utilidades! E haverá ainda mais, porque este ano serão lançadas diversas soluções internas. Dos muito grandes baseados no operador addon, há um monte de addons para Kubernetes, ala como instalar corretamente o sert manager - uma ferramenta para gerenciar certificados, como instalar corretamente o Prometheus com um monte de acessórios - são cerca de vinte diferentes binários que exportam dados e coletam algo, para isso o Prometheus possui os gráficos e alertas mais incríveis. Tudo isso são apenas um monte de addons para o Kubernetes, que são instalados em um cluster, e passa de simples a bacana, sofisticado, automático, no qual muitos problemas já foram resolvidos. Sim, fazemos muito.
Desenvolvimento do ecossistema
“Parece-me que esta é uma contribuição muito grande para o desenvolvimento deste instrumento e dos seus métodos de utilização.” Você pode estimar aproximadamente quem mais daria a mesma contribuição para o desenvolvimento do ecossistema?
Dmitry: Na Rússia, das empresas que atuam em nosso mercado, ninguém chega nem perto. Claro, esta é uma afirmação alta, porque existem grandes players como Mail e Yandex - eles também estão fazendo algo com o Kubernetes, mas mesmo eles não chegam perto da contribuição de empresas em todo o mundo que fazem muito mais do que nós. É difícil comparar a Flant, que tem uma equipe de 80 pessoas, e a Red Hat, que tem 300 engenheiros só por Kubernetes, se não me engano. É difícil comparar. Temos 6 pessoas no departamento de P&D, inclusive eu, que cortam todas as nossas ferramentas. 6 pessoas contra 300 engenheiros da Red Hat - é difícil comparar.
- Porém, quando mesmo essas 6 pessoas conseguem fazer algo realmente útil e alienante, quando se deparam com um problema prático e dão a solução para a comunidade - um caso interessante. Entendo que em grandes empresas de tecnologia, onde possuem equipe própria de desenvolvimento e suporte de Kubernetes, a princípio, as mesmas ferramentas podem ser desenvolvidas. Este é um exemplo para eles do que pode ser desenvolvido e dado à comunidade, dando impulso a toda a comunidade que utiliza Kubernetes.
Dmitry: Esta é provavelmente uma característica do integrador, sua peculiaridade. Temos muitos projetos e vemos muitas situações diferentes. Para nós, a principal forma de criar valor acrescentado é analisar estes casos, encontrar pontos em comum e torná-los o mais baratos possível para nós. Estamos trabalhando ativamente nisso. É difícil para mim falar sobre a Rússia e o mundo, mas temos cerca de 40 engenheiros DevOps na empresa que trabalham no Kubernetes. Não creio que existam muitas empresas na Rússia com um número comparável de especialistas que entendam de Kubernetes, se é que existem.
Eu entendo tudo sobre o cargo de engenheiro DevOps, todo mundo entende tudo e está acostumado a chamar engenheiros DevOps de engenheiros DevOps, não vamos discutir isso. Todos esses 40 incríveis engenheiros de DevOps enfrentam e resolvem problemas todos os dias, apenas analisamos essa experiência e tentamos generalizar. Entendemos que se ficar dentro de nós, daqui a um ou dois anos a ferramenta será inútil, porque em algum lugar da comunidade aparecerá uma Tula pronta. Não faz sentido acumular essa experiência internamente - é simplesmente drenar energia e tempo para dev/null. E não sentimos pena disso. Publicamos tudo com muito prazer e entendemos que precisa ser publicado, desenvolvido, divulgado, promovido, para que as pessoas utilizem e agreguem sua experiência - assim tudo cresce e vive. Depois de dois anos o instrumento não vai para o lixo. Não é uma pena continuar investindo força, porque é claro que alguém está usando sua ferramenta, e depois de dois anos todos estão usando.
Isso faz parte da nossa grande estratégia com dapp/werf. Não me lembro quando começamos a fazer isso, parece que foi há 3 anos. Inicialmente, geralmente estava na casca. Foi uma super prova de conceito, resolvemos alguns dos nossos problemas particulares - funcionou! Mas há problemas com o shell, é impossível expandi-lo ainda mais, programar no shell é outra tarefa. Tínhamos o hábito de escrever em Ruby, portanto, refizemos algo em Ruby, desenvolvemos, desenvolvemos, desenvolvemos, e nos deparamos com o fato de que a comunidade, a galera que não fala “queremos ou não queremos, ”Torce o nariz para Ruby, Como isso não é engraçado? Percebemos que deveríamos escrever tudo isso em Go apenas para atender ao primeiro ponto da lista de verificação: A ferramenta DevOps deve ser um binário estático. Ser Go ou não não é tão importante, mas um binário estático escrito em Go é melhor.
Gastamos nossa energia, reescrevemos o dapp em Go e o chamamos de werf. O Dapp não é mais suportado, não é desenvolvido, está sendo executado em alguma versão mais recente, mas existe um caminho de atualização absoluto para o topo e você pode segui-lo.
Por que o dapp foi criado?
— Você pode nos contar resumidamente por que o dapp foi criado, quais problemas ele resolve?
Dmitry: O primeiro motivo está na montagem. Inicialmente, tivemos sérios problemas com a construção quando o Docker não tinha recursos de vários estágios, então criamos vários estágios por conta própria. Então tivemos mais problemas com a limpeza da imagem. Todo mundo que faz CI/CD, mais cedo ou mais tarde, se depara com o problema de que há um monte de imagens coletadas, você precisa de alguma forma limpar o que não é necessário e deixar o que é necessário.
A segunda razão é a implantação. Sim, existe o Helm, mas ele resolve apenas alguns dos problemas. Curiosamente, está escrito que “Helm é o gerenciador de pacotes do Kubernetes”. Exatamente o que “o”. Há também 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: “O pacote foi entregue”.
É interessante que digamos: “Helm, instale o pacote”, e quando ele responde que instalou, acontece que acabou de iniciar a instalação - indicou o Kubernetes: “Lança essa coisa!”, e se começou ou não , funcione ou não, o Helm não resolve esse problema de forma alguma.
Acontece que o Helm é apenas um pré-processador de texto que carrega dados no Kubernetes.
Mas como parte de qualquer implantação, queremos saber se o aplicativo foi liberado para produção ou não. Lançado para prod significa que o aplicativo foi movido para lá, a nova versão foi implantada e pelo menos não trava lá e responde corretamente. Helm não resolve esse problema de forma alguma. Para resolvê-lo, você precisa despender muito esforço, porque precisa dar ao Kubernetes o comando para implementar e monitorar o que está acontecendo lá - seja ele implantado ou implementado. E também há muitas tarefas relacionadas à implantação, limpeza e montagem.
Planos
Este ano iniciaremos o desenvolvimento local. Queremos alcançar o que acontecia anteriormente no Vagrant - digitamos “vagrant up” e implantamos máquinas virtuais. Queremos chegar ao ponto onde existe um projeto no Git, escrevemos “werf up” ali, e ele traz uma cópia local deste projeto, implantada em um mini-Kub local, com todos os diretórios convenientes para o desenvolvimento conectados . Dependendo da linguagem de desenvolvimento, isso é feito de forma diferente, mas mesmo assim, para que o desenvolvimento local possa ser realizado convenientemente em arquivos montados.
O próximo passo para nós é invista em conveniência para desenvolvedores. Para implantar rapidamente um projeto localmente com uma ferramenta, desenvolvê-lo, colocá-lo no Git e ele também será implementado em estágio ou testes, dependendo dos pipelines, e então usará a mesma ferramenta para ir para produção. Essa unidade, unificação, reprodutibilidade da infraestrutura desde o ambiente local até as vendas é um ponto muito importante para nós. Mas isso ainda não está em vigor - estamos apenas planejando fazê-lo.
Mas o caminho para o dapp/werf sempre foi o mesmo do Kubernetes no início. Encontramos problemas, resolvemos-os com soluções alternativas - encontramos algumas soluções para nós mesmos no shell, em qualquer coisa. Então eles tentaram de alguma forma endireitar essas soluções alternativas, generalizá-las e consolidá-las em binários, neste caso, que simplesmente compartilhamos.
Existe outra maneira de ver toda essa história, com analogias.
Kubernetes é uma estrutura de carro com motor. Não há portas, vidros, rádio, árvore de Natal - absolutamente nada. Apenas o quadro e o motor. E lá está Helm - este é o volante. Legal - existe um volante, mas você também precisa de um pino de direção, cremalheira de direção, caixa de câmbio e rodas, e não pode ficar sem eles.
No caso do werf, este é outro componente do Kubernetes. Somente agora na versão alfa do werf, por exemplo, o Helm é compilado dentro do werf, porque estamos cansados de fazer isso sozinhos. Há muitas razões para fazer isso, contarei em detalhes por que compilamos todo o leme junto com o leme dentro do werf .
Agora o werf é um componente mais integrado. Conseguimos um volante pronto, um pino de direção - não sei muito sobre carros, mas este é um bloco grande que já resolve uma gama bastante ampla de problemas. Não precisamos percorrer o catálogo sozinhos, selecionar uma peça para outra, pensar em como parafusá-las. Obtemos uma colheitadeira pronta que resolve um grande número de problemas de uma só vez. Mas por dentro ele é construído a partir dos mesmos componentes de código aberto, ainda usa Docker para montagem, Helm para algumas funcionalidades e existem várias outras bibliotecas. Esta é uma ferramenta integrada para tirar CI/CD da caixa de forma rápida e conveniente.
O Kubernetes é difícil de manter?
— Você fala sobre a experiência que começou usando Kubernetes, isso é uma estrutura para você, um motor, e que você pode pendurar muitas coisas diferentes nele: uma carroceria, um volante, pedais aparafusados, assentos. Surge a pergunta: quão difícil é o suporte do Kubernetes para você? Você tem muita experiência. Quanto tempo e recursos você gasta no suporte ao Kubernetes isoladamente de todo o resto?
Dmitry: Essa é uma pergunta muito difícil e para responder precisamos entender o que é suporte e o que queremos do Kubernetes. Talvez você possa revelar?
— Pelo que eu sei e vejo, agora muitas equipes querem experimentar o Kubernetes. Todo mundo se atrela a isso, coloca de joelhos. Tenho a sensação de que as pessoas nem sempre entendem a complexidade deste sistema.
Dmitry: É assim.
— Quão difícil é pegar e instalar o Kubernetes do zero para que esteja pronto para produção?
Dmitry: Quão difícil você acha que é transplantar um coração? Entendo que esta é uma questão comprometedora. Usar bisturi e não cometer erros não é tão difícil. Se lhe disserem onde cortar e onde costurar, o procedimento em si não será complicado. É difícil garantir sempre que tudo vai dar certo.
Instalar o Kubernetes e fazê-lo funcionar é fácil: garota! – instalado, existem vários métodos de instalação. Mas o que acontece quando surgem problemas?
Sempre surgem perguntas - o que ainda não levamos em consideração? O que ainda não fizemos? Quais parâmetros do kernel Linux foram especificados incorretamente? Senhor, nós ao menos os mencionamos?! Quais componentes do Kubernetes entregamos e quais não? Surgem milhares de perguntas e, para respondê-las, você precisa passar de 15 a 20 anos neste setor.
Tenho um exemplo recente sobre este tópico que pode revelar o significado do problema “O Kubernetes é difícil de manter?” Há algum tempo, consideramos seriamente se deveríamos tentar implementar o Cilium como uma rede no Kubernetes.
Deixe-me explicar o que é Cílio. O Kubernetes tem muitas implementações diferentes do subsistema de rede, e uma delas é muito legal - Cilium. Qual é o seu significado? No kernel, há algum tempo, tornou-se possível escrever ganchos para o kernel, que de uma forma ou de outra invadem o subsistema de rede e vários outros subsistemas, e permitem ignorar grandes pedaços do kernel.
O kernel Linux historicamente tem uma rota IP, um filtro excessivo, pontes e muitos componentes antigos diferentes com 15, 20, 30 anos. Em geral funcionam, está tudo ótimo, mas agora estão empilhados contêineres, e parece uma torre de 15 tijolos uns em cima dos outros, e você fica em cima dela apoiado em uma perna só - uma sensação estranha. Este sistema desenvolveu-se historicamente com muitas nuances, como o apêndice no corpo. Em algumas situações há problemas de desempenho, por exemplo.
Existe um BPF maravilhoso e a capacidade de escrever ganchos para o kernel - os caras escreveram seus próprios ganchos para o kernel. O pacote entra no kernel do Linux, eles o retiram logo na entrada, processam eles mesmos como deveriam, sem pontes, sem TCP, sem pilha de IP - em suma, ignorando tudo o que está escrito no kernel do Linux e depois cuspindo para dentro do recipiente.
O que aconteceu? Desempenho muito legal, recursos interessantes - simplesmente legal! Mas olhamos para isso e vemos que em cada máquina existe um programa que se conecta à API Kubernetes e, com base nos dados que recebe desta API, gera código C e compila binários que carrega no kernel para que esses ganchos funcionem no espaço do kernel.
O que acontece se algo der errado? Nós não sabemos. Para entender isso, você precisa ler todo esse código, entender toda a lógica, e é incrível como isso é difícil. Mas, por outro lado, existem essas pontes, filtros de rede, ip rout - não li o código-fonte deles, nem os 40 engenheiros que trabalham em nossa empresa. Talvez apenas alguns entendam algumas partes.
E qual é a diferença? Acontece que existe o ip rout, o kernel do Linux, e existe uma nova ferramenta - que diferença faz, não entendemos um ou outro. Mas temos medo de usar algo novo – por quê? Porque se a ferramenta tem 30 anos, então em 30 anos todos os bugs foram encontrados, todos os erros foram corrigidos e você não precisa saber de tudo - funciona como uma caixa preta e sempre funciona. Todo mundo sabe qual chave de fenda de diagnóstico colocar em qual lugar, qual tcpdump executar em que momento. Todo mundo conhece bem os utilitários de diagnóstico e entende como esse conjunto de componentes funciona no kernel Linux - não como funciona, mas como usá-lo.
E o incrivelmente legal Cilium não tem 30 anos, ainda não envelheceu. Kubernetes tem o mesmo problema, copie. Que o Cilium está instalado perfeitamente, que o Kubernetes está instalado perfeitamente, mas quando algo dá errado na produção, você consegue entender rapidamente em uma situação crítica o que deu errado?
Quando dizemos que é difícil manter o Kubernetes - não, é muito fácil e, sim, é incrivelmente difícil. O Kubernetes funciona muito bem sozinho, mas com um bilhão de nuances.
Sobre a abordagem “Terei sorte”
— Existem empresas onde é quase garantido que essas nuances apareçam? Suponha que o Yandex transfira repentinamente todos os serviços para o Kubernetes, haverá uma carga enorme lá.
Dmitry: Não, esta não é uma conversa sobre carga, mas sobre as coisas mais simples. Por exemplo, temos o Kubernetes, implantamos o aplicativo lá. Como você sabe que está funcionando? Simplesmente não existe uma ferramenta pronta para entender que o aplicativo não está travando. Não existe um sistema pronto que envie alertas, é preciso configurar esses alertas e cada agendamento. E estamos atualizando o Kubernetes.
Eu tenho Ubuntu 16.04. Você pode dizer que esta é uma versão antiga, mas ainda estamos nela porque é LTS. Existe o systemd, cuja nuance é que ele não limpa grupos C. O Kubernetes inicia pods, cria grupos C, depois exclui pods e, de alguma forma, acontece - não me lembro dos detalhes, desculpe - que as fatias do systemd permanecem. Isso leva ao fato de que, com o tempo, qualquer carro começa a desacelerar fortemente. Esta nem é uma questão sobre alta carga. Se pods permanentes forem iniciados, por exemplo, se houver um Cron Job que gera pods constantemente, a máquina com Ubuntu 16.04 começará a ficar lenta após uma semana. Haverá uma média de carga constantemente alta devido ao fato de que vários grupos C foram criados. Este é o problema que qualquer pessoa que simplesmente instalar o Ubuntu 16 e o Kubernetes enfrentará.
Digamos que ele de alguma forma atualize o systemd ou algo mais, mas no kernel Linux até 4.16 é ainda mais engraçado - quando você exclui grupos C, eles vazam no kernel e não são realmente excluídos. Portanto, depois de um mês trabalhando nesta máquina, será impossível consultar as estatísticas de memória das lareiras. Retiramos um arquivo, rolamos no programa e um arquivo rola por 15 segundos, porque o kernel leva muito tempo para contar um milhão de grupos C dentro de si, que parecem ter sido excluídos, mas não - eles estão vazando .
Ainda há muitas dessas pequenas coisas aqui e ali. Este não é um problema que as empresas gigantes possam por vezes enfrentar sob cargas muito pesadas - não, é uma questão de coisas do quotidiano. As pessoas podem viver assim por meses - instalaram o Kubernetes, implantaram o aplicativo - parece funcionar. Para muitas pessoas isso é normal. Eles nem saberão que este aplicativo irá travar por algum motivo, não receberão um alerta, mas para eles isso é a norma. Antes vivíamos em máquinas virtuais sem monitoramento, agora mudamos para Kubernetes, também sem monitoramento - qual a diferença?
A questão é que quando caminhamos sobre o gelo, nunca sabemos a sua espessura, a menos que a medimos antecipadamente. Muitas pessoas caminham e não se preocupam, porque já caminharam antes.
Do meu ponto de vista, a nuance e a complexidade da operação de qualquer sistema consiste em garantir que a espessura do gelo seja exactamente suficiente para resolver os nossos problemas. É disso que estamos falando.
Em TI, parece-me, existem muitas abordagens do tipo “terei sorte”. Muitas pessoas instalam software e usam bibliotecas de software na esperança de ter sorte. Em geral, muitas pessoas têm sorte. Provavelmente é por isso que funciona.
— Pela minha avaliação pessimista, é assim: quando os riscos são altos e o aplicativo precisa funcionar, então é necessário o suporte do Flaunt, talvez da Red Hat, ou você precisa de sua própria equipe interna dedicada especificamente ao Kubernetes, que está pronta para retirá-lo.
Dmitry: Objetivamente, é assim. Entrar sozinho na história do Kubernetes para uma pequena equipe envolve vários riscos.
Precisamos de contêineres?
— Você pode nos dizer o quão difundido o Kubernetes está na Rússia?
Dmitry: não tenho esses dados e não tenho certeza se mais alguém os possui. Dizemos: “Kubernetes, Kubernetes”, mas há outra maneira de encarar esta questão. Também não sei o quão difundidos são os contêineres, mas conheço um número de relatórios na Internet de que 70% dos contêineres são orquestrados pelo Kubernetes. Foi uma fonte confiável para uma amostra bastante grande em todo o mundo.
Depois, outra pergunta: precisamos de contêineres? Meu sentimento pessoal e a posição geral da empresa Flant é que o Kubernetes é um padrão de fato.
Não haverá nada além do Kubernetes.
Isto é uma mudança absoluta no campo da gestão de infra-estruturas. Simplesmente absoluto - é isso, chega de Ansible, Chef, máquinas virtuais, Terraform. Não estou falando dos antigos métodos de fazenda coletiva. Kubernetes é uma mudança absoluta, e agora será só assim.
É claro que para alguns são necessários alguns anos, e para outros, algumas décadas, para perceberem isso. Não tenho dúvidas de que não haverá nada além do Kubernetes e esse novo visual: não danificamos mais o sistema operacional, mas usamos infraestrutura como código, só que não com código, mas com yml - uma infraestrutura descrita declarativamente. Tenho a sensação de que sempre será assim.
— Ou seja, aquelas empresas que ainda não migraram para o Kubernetes certamente mudarão para ele ou permanecerão no esquecimento. Eu entendi você corretamente?
Dmitry: Isso também não é totalmente verdade. Por exemplo, se tivermos a tarefa de rodar um servidor DNS, então ele pode ser rodado no FreeBSD 4.10 e pode funcionar perfeitamente por 20 anos. Basta trabalhar e pronto. Talvez em 20 anos algo precise ser atualizado uma vez. Se estamos falando de software no formato que lançamos e ele realmente funciona por muitos anos sem nenhuma atualização, sem fazer alterações, então, é claro, não haverá Kubernetes. Ele não é necessário lá.
Tudo relacionado a CI/CD - onde quer que a Entrega Contínua seja necessária, onde você precise atualizar versões, fazer alterações ativas, onde quer que você precise criar tolerância a falhas - apenas Kubernetes.
Sobre microsserviços
- Aqui tenho uma ligeira dissonância. Para trabalhar com Kubernetes, você precisa de suporte externo ou interno – este é o primeiro ponto. Em segundo lugar, quando estamos apenas começando o desenvolvimento, somos uma pequena startup, ainda não temos nada, o desenvolvimento para Kubernetes ou arquitetura de microsserviços em geral pode ser complexo e nem sempre justificado economicamente. Estou interessado na sua opinião: as startups precisam começar imediatamente a escrever para o Kubernetes do zero ou ainda podem escrever um monólito e só depois vir para o Kubernetes?
Dmitry: Pergunta legal. Tenho uma palestra sobre microsserviços Muitas vezes encontrei pessoas tentando martelar pregos com um microscópio. A abordagem em si está correta; nós mesmos projetamos nosso software interno dessa maneira. Mas ao fazer isso, você precisa entender claramente o que está fazendo. A palavra que mais odeio em microsserviços é “micro”. Historicamente, essa palavra se originou aí, e por algum motivo as pessoas pensam que micro é muito pequeno, menos de um milímetro, como um micrômetro. Isto está errado.
Por exemplo, existe um monólito que foi escrito por 300 pessoas, e todos que participaram do desenvolvimento entendem que há problemas ali, e ele deveria ser dividido em micropedaços - cerca de 10 peças, cada uma delas escrita por 30 pessoas em uma versão mínima. Isso é importante, necessário e legal. Mas quando uma startup chega até nós, onde 3 caras muito legais e talentosos escreveram 60 microsserviços de joelhos, toda vez procuro o Corvalol.
Parece-me que isso já foi falado milhares de vezes - obtivemos um monólito distribuído de uma forma ou de outra. Isso não se justifica economicamente, é muito difícil em geral em tudo. Já vi isso tantas vezes que realmente me dói, então continuo falando sobre isso.
Para a pergunta inicial, há um conflito entre o fato de que, por um lado, o Kubernetes é assustador de usar, porque não está claro o que pode quebrar ali ou não funcionar, por outro lado, é claro que tudo vai lá e nada além do Kubernetes existirá. Responder - pese a quantidade de benefício que vem, a quantidade de tarefas que você pode resolver. Isso está em um lado da escala. Por outro lado, existem riscos associados ao tempo de inatividade ou à diminuição do tempo de resposta, nível de disponibilidade - com diminuição dos indicadores de desempenho.
Aqui está: ou avançamos rapidamente e o Kubernetes nos permite fazer muitas coisas de maneira muito mais rápida e melhor, ou usamos soluções confiáveis e testadas pelo tempo, mas avançamos muito mais lentamente. Esta é uma escolha que toda empresa deve fazer. Você pode pensar nisso como um caminho na selva - quando você anda pela primeira vez, você pode encontrar uma cobra, um tigre ou um texugo louco, e quando você andou 10 vezes, você percorreu o caminho, removeu os galhos e andar com mais facilidade. Cada vez que o caminho fica mais amplo. Depois é uma estrada de asfalto e depois uma linda avenida.
O Kubernetes não fica parado. Pergunta novamente: Kubernetes, por um lado, é de 4 a 5 binários, por outro lado, é todo o ecossistema. Este é o sistema operacional que temos em nossas máquinas. O que é isso? Ubuntu ou curiosidades? Este é o kernel do Linux, um monte de componentes adicionais. Todas essas coisas aqui, uma cobra venenosa foi jogada para fora da estrada, uma cerca foi erguida ali. O Kubernetes está se desenvolvendo de forma muito rápida e dinâmica, e o volume de riscos, o volume do desconhecido está diminuindo a cada mês e, consequentemente, essas escalas estão se reequilibrando.
Respondendo à pergunta sobre o que uma startup deve fazer, eu diria - venha para Flaunt, pague 150 mil rublos e obtenha um serviço fácil de DevOps pronto para uso. Se você é uma pequena startup com alguns desenvolvedores, isso funciona. Em vez de contratar seu próprio DevOps, que precisará aprender como resolver seus problemas e pagar um salário neste momento, você terá uma solução pronta para uso para todos os problemas. Sim, existem algumas desvantagens. Nós, como terceirizados, não podemos estar tão envolvidos e responder rapidamente às mudanças. Mas temos muita experiência e práticas prontas. Garantimos que em qualquer situação iremos descobrir rapidamente e ressuscitar qualquer Kubernetes dos mortos.
Recomendo fortemente a terceirização para startups e negócios estabelecidos até um tamanho onde você possa dedicar uma equipe de 10 pessoas às operações, porque senão não adianta. Definitivamente faz sentido terceirizar isso.
Sobre Amazon e Google
— Um host de uma solução da Amazon ou do Google pode ser considerado terceirizado?
Dmitry: Sim, claro, isso resolve vários problemas. Mas, novamente, existem nuances. Você ainda precisa entender como usá-lo. Por exemplo, existem mil pequenas coisas no trabalho do Amazon AWS: o Load Balancer precisa ser aquecido ou uma solicitação deve ser feita com antecedência: “pessoal, vamos receber tráfego, aqueça o Load Balancer para nós!” Você precisa conhecer essas nuances.
Quando você recorre a pessoas especializadas nisso, você fecha quase todas as coisas típicas. Temos agora 40 engenheiros, e até o final do ano provavelmente serão 60 – definitivamente encontramos todas essas coisas. Mesmo que encontremos esse problema novamente em algum projeto, rapidamente perguntamos uns aos outros e sabemos como resolvê-lo.
Provavelmente a resposta é: claro, uma história hospedada torna parte mais fácil. A questão é se você está pronto para confiar nesses hosters e se eles resolverão seus problemas. Amazon e Google se saíram bem. Para todos os nossos casos - exatamente. Não temos mais experiências positivas. Todas as outras nuvens com as quais tentamos trabalhar criam muitos problemas - Ager, e tudo o que existe na Rússia, e todos os tipos de OpenStack em diferentes implementações: Headster, Overage - o que você quiser. Todos eles criam problemas que você não quer resolver.
Portanto, a resposta é sim, mas, na verdade, não existem muitas soluções hospedadas maduras.
Quem precisa do Kubernetes?
— E ainda assim, quem precisa do Kubernetes? Quem já deveria mudar para o Kubernetes, quem é o típico cliente Flaunt que vem especificamente para o Kubernetes?
Dmitry: Essa é uma pergunta interessante, pois neste momento, na esteira do Kubernetes, muita gente vem até nós: “Gente, sabemos que vocês estão fazendo Kubernetes, façam isso por nós!” Nós respondemos: “Senhores, não fazemos Kubernetes, fazemos prod e tudo relacionado a ele”. Porque atualmente é simplesmente impossível fazer um produto sem fazer todo o CI/CD e toda essa história. Todos se afastaram da divisão de que temos desenvolvimento por desenvolvimento e depois exploração por exploração.
Nossos clientes esperam coisas diferentes, mas todos estão esperando por algum bom milagre de terem certos problemas, e agora - pule! — Kubernetes irá resolvê-los. As pessoas acreditam em milagres. Em suas mentes eles entendem que não haverá milagre, mas em suas almas eles esperam - e se esse Kubernetes agora resolver tudo para nós, eles falam tanto sobre isso! De repente ele agora - espirra! - e uma bala de prata, espirre! — e temos 100% de tempo de atividade, todos os desenvolvedores podem lançar o que quer que entre em produção 50 vezes e não trava. Em geral, um milagre!
Quando essas pessoas vêm até nós, dizemos: “Desculpe, mas milagre não existe”. Para ser saudável, você precisa se alimentar bem e fazer exercícios. Para ter um produto confiável, ele precisa ser fabricado de maneira confiável. Para ter um CI/CD conveniente, você precisa torná-lo assim. É muito trabalho que precisa ser feito.
Respondendo à pergunta de quem precisa do Kubernetes - ninguém precisa do Kubernetes.
Algumas pessoas têm a ideia errada de que precisam do Kubernetes. As pessoas precisam, têm uma necessidade profunda de parar de pensar, de estudar e de se interessar por todos os problemas de infraestrutura e de execução de suas aplicações. Eles querem que os aplicativos simplesmente funcionem e sejam implementados. Para eles, o Kubernetes é a esperança de que parem de ouvir a história de que “estávamos ali deitados” ou “não podemos implementar” ou qualquer outra coisa.
O diretor técnico costuma vir até nós. Pedem-lhe duas coisas: por um lado, dê-nos características, por outro, estabilidade. Sugerimos que você assuma a responsabilidade e faça isso. A solução mágica, ou melhor, banhada a prata, é que você deixará de pensar nesses problemas e de perder tempo. Você terá pessoas especiais que irão encerrar esta edição.
A expressão que nós ou qualquer outra pessoa precisamos do Kubernetes está incorreta.
Os administradores realmente precisam do Kubernetes, porque é um brinquedo muito interessante com o qual você pode brincar e mexer. Sejamos honestos: todo mundo adora brinquedos. Somos todos crianças em algum lugar e quando vemos um novo, queremos brincar com ele. Para alguns isso tem sido desencorajado, por exemplo, na administração, porque já jogaram bastante e já estão cansados a ponto de simplesmente não quererem. Mas isso não está completamente perdido para ninguém. Por exemplo, se já estou cansado de brinquedos na área de administração de sistemas e DevOps há muito tempo, ainda adoro os brinquedos, ainda compro alguns novos. Todas as pessoas, de uma forma ou de outra, ainda querem algum tipo de brinquedo.
Não há necessidade de brincar com a produção. Tudo o que eu recomendo categoricamente não fazer e o que vejo agora em massa: “Oh, um brinquedo novo!” — correram para comprar, compraram e: “Vamos levar agora para a escola e mostrar para todos os nossos amigos”. Não faça isso. Peço desculpas, meus filhos estão apenas crescendo, constantemente vejo algo nas crianças, percebo isso em mim mesmo e depois generalizo para os outros.
A resposta final é: você não precisa do Kubernetes. Você precisa resolver seus problemas.
O que você pode conseguir é:
- o bastão não cai;
- mesmo que ele tente cair, sabemos com antecedência e podemos colocar algo nele;
- podemos alterá-lo na velocidade que nosso negócio exige, e podemos fazê-lo convenientemente; isso não nos causa nenhum problema.
Existem duas necessidades reais: fiabilidade e dinamismo/flexibilidade de implementação. Todos que estão atualmente realizando algum tipo de projeto de TI, não importa em que tipo de negócio - soft para facilitar o mundo, e que entendem isso, precisam resolver essas necessidades. Kubernetes com a abordagem certa, com o entendimento certo e com experiência suficiente permite resolvê-los.
Sobre sem servidor
— Se você olhar um pouco mais para o futuro, então tentando resolver o problema da ausência de dores de cabeça com infraestrutura, com a velocidade de rollout e a velocidade de mudanças nas aplicações, surgem novas soluções, por exemplo, serverless. Você sente algum potencial nessa direção e, digamos, um perigo para o Kubernetes e soluções similares?
Dmitry: Aqui precisamos novamente comentar que não sou um vidente que olha para frente e diz - será assim! Embora eu tenha feito a mesma coisa. Olho para os meus pés e vejo vários problemas ali, por exemplo, como funcionam os transistores em um computador. É engraçado, certo? Estamos encontrando alguns bugs na CPU.
Torne o serverless bastante confiável, barato, eficiente e conveniente, resolvendo todos os problemas do ecossistema. Aqui concordo com Elon Musk que é necessário um segundo planeta para criar tolerância a falhas para a humanidade. Embora eu não saiba o que ele está dizendo, entendo que não estou pronto para voar para Marte e isso não acontecerá amanhã.
Com o serverless, fica claramente claro que isso é algo ideologicamente correto, como a tolerância a falhas para a humanidade - ter dois planetas é melhor do que um. Mas como fazer isso agora? Enviar uma expedição não é um problema se você concentrar seus esforços nisso. Enviar várias expedições e instalar vários milhares de pessoas lá, creio eu, também é realista. Mas torná-lo completamente tolerante a falhas, para que metade da humanidade viva lá, parece-me agora impossível, não sendo considerado.
Com serverless one on one: a coisa é legal, mas está longe dos problemas de 2019. Mais perto de 2030 - vamos viver para ver isso. Não tenho dúvidas de que viveremos, com certeza viveremos (repita antes de dormir), mas agora precisamos resolver outros problemas. É como acreditar no pônei do conto de fadas Rainbow. Sim, alguns por cento dos casos são resolvidos e são resolvidos perfeitamente, mas subjetivamente, serverless é um arco-íris... Para mim, esse tópico é muito distante e incompreensível. Não estou pronto para conversar. Em 2019, você não pode escrever um único aplicativo sem servidor.
Como o Kubernetes evoluirá
— À medida que avançamos em direção a esse futuro distante potencialmente maravilhoso, como você acha que o Kubernetes e o ecossistema ao seu redor se desenvolverão?
Dmitry: Pensei muito sobre isso e tenho uma resposta clara. O primeiro é statefull - afinal, stateless é mais fácil de fazer. O Kubernetes inicialmente investiu mais nisso, tudo começou com isso. Stateless funciona quase perfeitamente no Kubernetes, não há nada do que reclamar. Ainda existem muitos problemas, ou melhor, nuances. Tudo lá já funciona muito bem para nós, mas somos nós. Levará pelo menos mais alguns anos para que isso funcione para todos. Este não é um indicador calculado, mas o que sinto na minha cabeça.
Em suma, statefull deve - e irá - desenvolver-se fortemente, porque todas as nossas aplicações armazenam status; não existem aplicações stateless. Isso é uma ilusão; você sempre precisa de algum tipo de banco de dados e algo mais. Statefull é endireitar tudo o que for possível, consertar todos os bugs, melhorar todos os problemas que estão sendo enfrentados atualmente - vamos chamar isso de adoção.
O nível do desconhecido, o nível dos problemas não resolvidos, o nível de probabilidade de encontrar algo cairão significativamente. Esta é uma história importante. E operadores - tudo relacionado à codificação da lógica de administração, lógica de controle para obter um serviço fácil: serviço fácil MySQL, serviço fácil RabbitMQ, serviço fácil Memcache - em geral, todos esses componentes que precisamos ter a garantia de funcionar a Caixa. Isso apenas resolve o problema de querermos um banco de dados, mas não queremos administrá-lo, ou queremos Kubernetes, mas não queremos administrá-lo.
Esta história de desenvolvimento de operadores, de uma forma ou de outra, será importante nos próximos anos.
Acho que a facilidade de uso deve aumentar muito - a caixa ficará cada vez mais preta, cada vez mais confiável, com botões cada vez mais simples.
Certa vez, ouvi uma antiga entrevista com Isaac Asimov dos anos 80 no YouTube no Saturday Night Live - um programa como Urgant, só que interessante. Eles perguntaram a ele sobre o futuro dos computadores. Ele disse que o futuro está na simplicidade, assim como o rádio. O receptor de rádio era originalmente uma coisa complexa. Para pegar uma onda, era preciso girar os botões por 15 minutos, girar os espetos e saber de maneira geral como tudo funciona, entender a física da transmissão das ondas de rádio. Como resultado, sobrou apenas um botão no rádio.
Agora em 2019 que rádio? No carro, o receptor de rádio encontra todas as ondas e os nomes das estações. A física do processo não mudou em 100 anos, mas a facilidade de uso sim. Agora, e não só agora, já em 1980, quando houve uma entrevista com Azimov, todos usavam o rádio e ninguém pensava em como funcionava. Sempre funcionou - isso é um dado adquirido.
Azimov disse então que aconteceria o mesmo com os computadores - a facilidade de uso aumentará. Embora em 1980 você tivesse que ser treinado para pressionar botões em um computador, esse não será o caso no futuro.
Tenho a sensação de que com o Kubernetes e com a infraestrutura também haverá um grande aumento na facilidade de uso. Isso, na minha opinião, é óbvio - está na superfície.
O que fazer com engenheiros?
— O que acontecerá então com os engenheiros e administradores de sistemas que oferecem suporte ao Kubernetes?
Dmitry: O que aconteceu com o contador após o advento do 1C? Aproximadamente o mesmo. Antes contavam com o papel – agora no programa. A produtividade do trabalho aumentou em ordens de grandeza, mas o trabalho em si não desapareceu. Se antes eram necessários 10 engenheiros para aparafusar uma lâmpada, agora um será suficiente.
Parece-me que a quantidade de software e o número de tarefas estão agora a crescer a um ritmo mais rápido do que o aparecimento de novos DevOps e a eficiência está a aumentar. Há uma escassez específica no mercado neste momento e ela vai durar muito tempo. Mais tarde, tudo voltará a uma espécie de normalidade, em que a eficiência do trabalho aumentará, haverá cada vez mais serverless, um neurônio será anexado ao Kubernetes, que selecionará todos os recursos exatamente conforme necessário, e em geral irá faça tudo sozinho, como deveria - a pessoa apenas se afasta e não interfere.
Mas alguém ainda precisará tomar decisões. É claro que o nível de qualificação e especialização desta pessoa é superior. Hoje em dia, no departamento de contabilidade, não são necessários 10 funcionários fazendo livros para que as mãos não se cansem. Simplesmente não é necessário. Muitos documentos são digitalizados e reconhecidos automaticamente pelo sistema de gerenciamento eletrônico de documentos. Basta um contador-chefe inteligente, já com habilidades muito maiores, com bom entendimento.
Em geral, este é o caminho a seguir em todos os setores. Com os carros é a mesma coisa: antes vinha um carro com mecânico e três motoristas. Hoje em dia, conduzir um automóvel é um processo simples do qual todos participamos todos os dias. Ninguém pensa que carro é algo complicado.
O DevOps ou a engenharia de sistemas não irão desaparecer – o trabalho de alto nível e a eficiência aumentarão.
— Também ouvi uma ideia interessante de que o trabalho vai mesmo aumentar.
Dmitry: Claro, cem por cento! Porque a quantidade de software que escrevemos está em constante crescimento. O número de problemas que resolvemos com software está em constante crescimento. A quantidade de trabalho está crescendo. Agora o mercado DevOps está terrivelmente superaquecido. Isso pode ser visto nas expectativas salariais. No bom sentido, sem entrar em detalhes, deveria haver juniores que querem X, intermediários que querem 1,5X e seniores que querem 2X. E agora, se você olhar para o mercado salarial DevOps de Moscou, um júnior quer de X a 3X e um sênior quer de X a 3X.
Ninguém sabe quanto custa. O nível salarial é medido pela sua confiança - um hospício completo, para ser sincero, um mercado terrivelmente superaquecido.
É claro que esta situação mudará muito em breve - deverá ocorrer alguma saturação. Este não é o caso do desenvolvimento de software - apesar de todos precisarem de desenvolvedores, e todos precisarem de bons desenvolvedores, o mercado entende quem vale o quê - a indústria se acalmou. Esse não é o caso do DevOps atualmente.
— Pelo que ouvi, concluí que o atual administrador de sistema não deve se preocupar muito, mas é hora de atualizar suas habilidades e se preparar para o fato de que amanhã haverá mais trabalho, mas será mais qualificado.
Dmitry: Cem por cento. Em geral vivemos em 2019 e a regra de vida é esta: aprendizagem ao longo da vida - aprendemos ao longo da vida. Parece-me que agora todo mundo já sabe e sente isso, mas não basta saber - é preciso fazer. Todos os dias devemos mudar. Se não fizermos isso, mais cedo ou mais tarde ficaremos à margem da profissão.
Esteja preparado para curvas fechadas de 180 graus. Não excluo uma situação em que algo mude radicalmente, algo novo seja inventado – isso acontece. Saltar! - e agora agimos de forma diferente. É importante estar preparado para isso e não se preocupar. Pode acontecer que amanhã tudo o que eu faça seja desnecessário - nada, estudei a vida toda e estou pronto para aprender outra coisa. Isso não é um problema. Não há necessidade de ter medo da segurança no emprego, mas você precisa estar preparado para aprender constantemente algo novo.
Desejos e um minuto de publicidade
- Você tem algum desejo?
Dmitry: Sim, tenho vários desejos.
Primeiro e mercantil - inscreva-se . Caros leitores, acessem o YouTube e inscrevam-se em nosso canal. Em cerca de um mês iniciaremos a expansão ativa do serviço de vídeo. Teremos muito conteúdo educacional sobre Kubernetes, aberto e variado: desde coisas práticas, até laboratórios, até coisas teóricas fundamentais e profundas e como usar o Kubernetes no nível de princípios e padrões.
O segundo desejo mercantil - vá para e colocar estrelas porque nos alimentamos delas. Se você não nos der estrelas, não teremos o que comer. É como mana em um jogo de computador. Fazemos alguma coisa, fazemos, tentamos, alguém diz que são bicicletas horríveis, alguém que está tudo completamente errado, mas continuamos e agimos com absoluta honestidade. Vemos um problema, resolvemos e compartilhamos nossa experiência. Portanto, dê-nos uma estrela, ela não irá embora de você, mas chegará até nós, porque dela nos alimentamos.
Terceiro desejo importante e não mais mercantil - pare de acreditar em contos de fadas. Vocês são profissionais. DevOps é uma profissão muito séria e responsável. Pare de brincar no local de trabalho. Deixe clicar para você e você entenderá. Imagine que você chega ao hospital e lá o médico está fazendo experiências com você. Entendo que isso possa ser ofensivo para alguém, mas provavelmente não se trata de você, mas de outra pessoa. Diga aos outros para pararem também. Isso realmente arruína a vida de todos nós - muitos começam a tratar operações, administradores e DevOps como caras que quebraram algo novamente. Isso foi “quebrado” na maioria das vezes pelo fato de irmos brincar e não olharmos com a fria consciência de que é assim e é assim.
Isso não significa que você não deva experimentar. Precisamos experimentar, nós mesmos fazemos isso. Para ser honesto, às vezes nós mesmos jogamos - isso, claro, é muito ruim, mas nada de humano nos é estranho. Vamos declarar 2019 um ano de experimentos sérios e bem pensados, e não de jogos em produção. Provavelmente sim.
- Muito obrigado!
Dmitry: Obrigado, Vitaly, tanto pelo tempo quanto pela entrevista. Caros leitores, muito obrigado se de repente vocês chegaram a este ponto. Espero que tenhamos trazido a você pelo menos algumas reflexões.
Na entrevista, Dmitry abordou a questão do werf. Agora, este é um canivete suíço universal que resolve quase todos os problemas. Mas nem sempre foi assim. Sobre no festival Dmitry Stolyarov falará detalhadamente sobre essa ferramenta. no relatório haverá de 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, criaremos as ferramentas perfeitas.
Fonte: habr.com