Decodificação:
Azat Khadiev: Olá. Meu nome é Azat Khadiev. Sou desenvolvedor de PaaS na Mail.ru Cloud Solutions. Comigo está Pavel Selivanov, da Southbridge. Estamos na conferência DevOpsDays. Ele fará uma palestra sobre como você pode construir DevOps com Kubernetes, mas provavelmente fracassará. Por que um tema tão sombrio?
Pavel Selivanov: Não é bem um cenário sombrio. Trata-se do fato de estarmos tentando resolver muitos problemas em nossa comunidade com tecnologia. E estamos tentando resolvê-los de uma forma bastante unilateral. O Kubernetes, por exemplo, é a mesma coisa — é algo pelo qual a equipe de Operações é responsável, digamos assim. Mas temos esse conceito maravilhoso de engenheiro DevOps. Um engenheiro DevOps é responsável pelo Kubernetes. E, no entanto... É como se você criasse o Kubernetes, e os desenvolvedores nem sequer soubessem de tudo isso, não soubessem o que ele permite fazer — e tudo funciona exatamente da mesma forma para eles. E isso apesar de o Kubernetes conter soluções prontas, ferramentas prontas para usar essa tecnologia e estender a abordagem DevOps, a comunicação entre Desenvolvimento e Operações. Aproveitamos muito pouco essa oportunidade. Ao migrarmos até mesmo nossas estruturas atuais para todas essas ferramentas DevOps — Docker, Kubernetes, nuvens e assim por diante — estamos piorando ainda mais a situação. E estamos começando a usar as ferramentas de maneiras para as quais elas não foram projetadas. E todas essas tecnologias estão sendo construídas em torno de algumas muletas verdadeiramente terríveis.
Azat Khadiev: Entendo. Parece um tema amplo. Qual você acha que é o problema mais comum que as empresas enfrentam atualmente? Com o Kubernetes.
Pavel Selivanov: O problema mais comum com o Kubernetes é a falta de conhecimento especializado. Este é um problema comum na área de TI. Há sempre escassez de especialistas. Há sempre escassez de conhecimento especializado. E agora, com o Kubernetes, há uma escassez de habilidades. Enquanto isso, francamente, existem poucas soluções prontas no mercado que permitam que alguém comece a usar o Kubernetes sem ter o conhecimento especializado necessário. E as que existem, todas levantam algumas questões. Com o Kubernetes, estamos constantemente procurando pessoas que entendam isso. Estamos tentando aprimorar nosso desenvolvimento para atender a essa demanda.
Azat Khadiyev: E considerando a atual escassez de talentos na área de TI, que sempre existiu e ainda existe, como você acha que podemos viver nessas condições? Quais são algumas dicas para lidar com isso?
Pavel Selivanov: Dicas práticas. Primeiramente, da perspectiva da nuvem, uma dica prática seria algo como: nos dê algumas de suas competências. E nós as assumiremos. E cuidaremos de tudo internamente. E isso é ótimo. Exceto que é importante que quem usa isso entenda... Na verdade, é um ponto excelente... Mas é importante entender que, ao delegar algumas de nossas competências a uma nuvem ou provedor, recebemos em troca uma solução de propósito geral. Grosso modo, temos um banco de dados que realiza tarefas muito específicas e foi configurado de forma muito específica. Ao transferir esse banco de dados para a nuvem, podemos, claro, demitir o administrador que gerenciava os clusters de banco de dados — a Amazon ou o Google farão isso por nós. Mas, ao mesmo tempo, a Amazon ou o Google não nos permitirão configurar nosso banco de dados com precisão. Grandes projetos, grandes empresas — inevitavelmente acabam usando soluções em nuvem em algum momento de suas vidas e, inevitavelmente, voltam a internalizar essas competências porque habilidades mais específicas são necessárias.
Azat Khadiev: As soluções universais são ruins ou podem ser usadas para construir mais soluções?
Pavel Selivanov: Não, soluções universais definitivamente não são ruins. Soluções universais são boas. A questão é que soluções universais... são universais. É importante entender isso. É como pegar um roteiro genérico... Se você puder construir toda a lógica operacional da empresa em torno desse roteiro genérico, dessa aplicação genérica, ótimo. Mas se a lógica operacional for diferente, e você pegar essa solução universal, esse roteiro universal, e começar a tentar encaixar tudo em uma única esfera, isso é ruim. E não há nada de errado com o universalismo em si.
Azat Khadiev: Se esse administrador já trabalha para você, não se trata de demiti-lo. Ele simplesmente poderá fazer mais.
Pavel Selivanov: Sim, eliminar a rotina e delegar a tarefa a outra pessoa para que seja feita em outro lugar. Essa é certamente uma boa abordagem. O importante aqui é saber se essa solução padrão é adequada para um caso específico.
Azat Khadiev: Com base na minha experiência, vejo que muitas empresas estão fazendo a mesma coisa. Elas configuram um cluster Kubernetes e pensam em como escalá-lo. E todas essas operações são muito repetitivas.
Pavel Selivanov: Sim, com certeza. Principalmente porque, se considerarmos o Kubernetes especificamente, há uma verdadeira escassez de conhecimento profundo e de qualidade sobre Kubernetes no mercado atualmente. O Kubernetes é um pacote de software tão gigantesco que, se você optar por adotá-lo, prepare-se para contratar um engenheiro em tempo integral para trabalhar nele. E isso é caro. E encontrar um engenheiro assim é difícil. Falando por mim, não sou muito fã de soluções baseadas em nuvem porque tenho um conhecimento bastante bom e profundo de como o Kubernetes funciona. E frequentemente percebo que as soluções em nuvem não possuem a funcionalidade que eu preciso, e me dizem: "Não, não é possível". Bem, nesse caso, sinto muito, mas posso fazer melhor do que as soluções em nuvem. Mas, ao mesmo tempo, se você não tem um engenheiro em tempo integral e não quer pagar um para lidar com o Kubernetes, e está constantemente pagando muito dinheiro apenas para experimentação, então a nuvem é uma ótima solução. Porque pelo menos as pessoas que trabalham lá já foram contratadas pelo fornecedor. E sabem o que estão fazendo. E as coisas básicas de que você precisa diariamente estão disponíveis.
Azat Khadiev: O que você acha do estado atual do Kubernetes? Como ele estará daqui a cinco ou dez anos?
Павел Селиванов: Хороший вопрос. Я просто знаю, что у нас происходит в комьюнити по этому поводу. Некоторые люди верят, что кроме Кубернетеса ничего не останется. Та ситуация, которая давно произошла с линуксами. То есть вне Linux есть люди, которые живут на BSD, скорее всего у них очень специфичные задачи. Есть люди, которые работают под Windows — windows-сервера — скорее всего, у них тоже есть специфичные задачи, или есть просто компетенция в этом деле и они не готовы оттуда уезжать. В любом случае, стандарт в нашей сфере — это Linux. Вот есть мнение, что Kubernetes станет таким же стандартом де-факто, и кроме Кубернетеса ничего не будет. Кубернетес будет управлять не только приложениями, их разворачиванием, деплоем, масштабированием. Вообще всем управлять. Сейчас уже спрашивают: «А можно ли в Kubernetes запихнуть базу данных». Я обычно говорю о том, что тут вопрос не в Кубернетесе, а в Docker. Если вы готовы, что ваша база данных будет работать в контейнерах, как она будет работать. Мне отвечают: «Не-не-не, подождите. В контейнеры не нужно. Нужно в Кубернетес. Мы её привьём к ноде. То есть всё будет, как у нас есть сейчас, только всем этим будет управлять Кубернетес.» И это хорошая идея на самом деле. То есть Кубернетес — это такая штука, когда можно прийти в компанию, если в компании есть Кубернетес и на нём построенные процессы, то человеку, который в этом разбирается — ему достаточно посмотреть пару дней, чтобы сказать: «Я готов вас поддерживать. Полностью. Целиком. Я понял, как у вас что работает». В отличие от подходов без Кубернетеса — тут одни костыли запихали, тут другие костыли. Тут Ansible, тут Terraform. Кем-то всё это написано, и надо полгода, чтобы разобраться. Вот. Так что станет ли Кубернетес стандартом де-факто, я не знаю. На текущий день он выглядит гораздо амбициозней и уверенней, чем решения, которые вокруг него есть.
Азат Хадиев: Ну, сравнение с Linux достаточно смелое. Он-то работает на одной машине — и всё. А Кубернетес работает на многих машинах. Сразу же возникает миллион вариаций, причин. Да, это смело. Просто если учитываться, что есть конкуренты у этой парадигмы. Например, Serverless. КУбернетес в опасности при таких конкурентах?
Pavel Selivanov: De Serverless... (risos) Serverless - ainda entendemos isso servidor Afinal, existem sim. Recentemente, ouvi uma reportagem sobre isso. O cara de lá disse que existem servidores, afinal — e isso é a nuvem. Mas devemos sempre entender que a nuvem também tem servidores. Existem servidores de hardware reais, um rack, e eles estão instalados em algum lugar. Isso é a nuvem. Além disso, existe o Serverless, onde servidores "Não." Então a questão é: o Serverless vai superar o Kubernetes? Eu acredito que o Serverless migrará para o Kubernetes. Para provedores que oferecem Serverless, o Kubernetes é uma plataforma muito conveniente. Sim, talvez em algum momento deixemos de falar sobre o Kubernetes como uma ferramenta padrão para desenvolvimento de aplicações empresariais. Mas, em algum lugar no fundo, provedores e engenheiros ainda terão o Kubernetes implementado, onde tudo isso estará disponível.
Azat Khadiev: Mudando um pouco de assunto. Existe esse conceito de engenheiro full-stack. O que você acha deles? Eles sequer existem?
Pavel Selivanov: Hum... Um engenheiro full-stack... Bem, acho que vale a pena distinguir entre essas coisas... Sabe, existe o perfil de profissional em formato de T. Essas pessoas são necessárias na indústria atual? Sim, definitivamente são. Precisamos de pessoas que tenham uma perspectiva ampla, mas que também sejam especialistas em uma área específica. E um engenheiro full-stack é exatamente isso — alguém que faz de tudo. Do desenvolvimento front-end aos testes, do back-end aos servidores e tudo mais. Não acredito que, em uma grande empresa, uma pessoa consiga fazer tudo isso sem ter especializações específicas em cada área. Mas, ao mesmo tempo, ter apenas uma especialização específica, como "Não sei nada sobre o que está acontecendo aqui", também não funciona no mundo moderno. Então, eu diria... Eu descartaria a palavra "full-stack". Precisamos mesmo de engenheiros. Precisamos de DevOps. Tenho a impressão de que em breve vamos reconsiderar esse ponto. E eles não serão mais necessários.
Azat Khadiev: Você pode revelar?
Pavel Selivanov: Acho que chegaremos a um ponto na indústria em que essas funções de DevOps e Ops se tornarão obsoletas em breve. Se precisarmos de especialistas e estivermos procurando... Precisamos deste tipo de desenvolvedor, precisamos daquele tipo de administrador, precisamos de engenheiros DevOps — nós os temos agora, e em breve também teremos engenheiros de produção e engenheiros de SRE. Embora, na realidade, o que precisamos são engenheiros que queremos contratar. A formação acadêmica é praticamente irrelevante. Porque... Por exemplo, os SREs dizem que os problemas de infraestrutura são sempre relacionados a software. Então... Vamos contratar desenvolvedores — considerando que um desenvolvedor é um engenheiro — e colocá-los no departamento de suporte, e eles resolverão esses problemas da mesma forma que resolvem problemas de negócios com código, com engenharia propriamente dita.
Azat Khadiev: E, desse ponto de vista... Como entrevistar esses engenheiros?
Павел Селиванов: Ох, хороший вопрос. Он, наверное, находится уже за гранью того, что я понимаю в этой жизни. Но я просто пример бы привёл. Он к собеседованию отношения не имеет. Это про нашу систему образования в России. В IT мы знаем, что наша система образования в России для IT-мира очень сильно устарела, она не такая, как должна быть. Я говорю в среднем про Россию необъятную — и что там происходит. Выпускаются люди, которые абсолютно неготовы пойти завтра же после выпуска пойти в веб-разработку, в технологическую компанию. И типа это плохо. Мы обучаем их каким-то странным вещам, хотя вроде бы должны учить разрабатывать их под Android, под iOS, как пользоваться Git и всем этим вещам. На самом деле как будто бы нет. Институт — это такое время, когда за тебя по большей части платят родители. За всю твою жизнь. И ты можешь посвятить пять лет своей жизни, чтобы углублённо учиться. И изучать весь этот T-shaped. Когда ты можешь в институте изучать, что такое система контроля версий, какие бывают паттерны разработки, как это всё дело тестировать, какие бывают базы данных, балансировщики. А когда ты уже идёшь работать, ты начинаешь углубляться в какой-то конкретной области. И таким образом мы получаем инженеров. И вот наша система образования в России гораздо ближе к этой правде, чем нам кажется. Нам дают хорошую математическую подготовку, дают хорошую алгоритмическую подготовку, нам дают какое-то представление о языках программирования. И про собеседование мне кажется что-то близкое этому. Инженеров нам надо собеседовать. Нам нужна верхняя часть буквы T у T-shaped. Потому что вертикальную черту буквы Т он приобретёт.
Azat Khadiev: Sim, é interessante. Durante cinco anos após a faculdade, achei minha formação estranha e inadequada. Mas depois, conforme meu trabalho progredia, quando as tarefas se tornaram mais complexas e os projetos maiores, percebi que, na verdade, eu havia aprendido coisas muito importantes. Pavel, obrigado. Foi muito interessante ouvir suas respostas. Vamos ouvir seu relatório.
Pavel Selivano: Obrigado.
Fonte: habr.com
