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?
Pavel Selivanov: Boa pergunta. Eu sei o que está acontecendo na nossa comunidade em relação a isso. Algumas pessoas acreditam que o Kubernetes será a única opção viável. É a mesma situação que aconteceu com o Linux há muito tempo. Fora do Linux, existem pessoas que usam BSD, e elas provavelmente têm tarefas muito específicas. Também existem pessoas que trabalham com Windows — servidores Windows — e elas provavelmente têm tarefas específicas, ou simplesmente têm experiência nessa área e não estão prontas para mudar. De qualquer forma, o padrão na nossa indústria é o Linux. Existe a crença de que o Kubernetes se tornará o padrão de fato e que será a única opção viável. O Kubernetes gerenciará não apenas os aplicativos, mas também sua implantação, implantação e escalonamento. Ele gerenciará tudo. Agora as pessoas estão perguntando: "É possível colocar um banco de dados no Kubernetes?" Eu costumo dizer que a questão aqui não é o Kubernetes, mas o Docker. Se você está pronto para que seu banco de dados rode em contêineres, como isso funcionará? Eles me dizem: "Não, não, não, espere. Você não precisa de contêineres. Você precisa do Kubernetes. Vamos integrá-lo ao nó. Assim, tudo continuará como está, só que o Kubernetes gerenciará tudo." E essa é uma boa ideia, na verdade. O Kubernetes é o tipo de solução que permite que você chegue a uma empresa que já utiliza Kubernetes e possui processos baseados nele, e alguém que o entenda — basta observar por alguns dias e dizer: "Estou pronto para dar suporte completo. Completamente. Entendo como tudo funciona para vocês." Diferentemente das abordagens sem Kubernetes — que improvisam com gambiarras. Aqui é Ansible, ali é Terraform. Alguém escreveu tudo isso e leva seis meses para entender. Então, se o Kubernetes se tornará o padrão de fato, eu não sei. Hoje, ele parece muito mais ambicioso e confiante do que as soluções que o cercam.
Azat Khadiev: Bem, a comparação com o Linux é bastante ousada. Ele roda em uma única máquina, e só. Mas o Kubernetes roda em múltiplas máquinas. Um milhão de variações e razões surgem imediatamente. Sim, é ousado. Mas considere que esse paradigma tem concorrentes. Por exemplo, Serverless. O Kubernetes está em perigo com esses concorrentes?
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?
Pavel Selivanov: Ah, essa é uma boa pergunta. Provavelmente está além da minha compreensão deste mundo. Mas vou dar um exemplo. Não tem nada a ver com entrevistas. É sobre o nosso sistema educacional na Rússia. Na área de TI, sabemos que o nosso sistema educacional na Rússia está muito desatualizado para o mundo da TI; não é o que deveria ser. Estou falando da Rússia em geral, em média, e do que está acontecendo lá. Pessoas se formam que não estão absolutamente preparadas para entrar no desenvolvimento web ou trabalhar em uma empresa de tecnologia no dia seguinte à formatura. E eles acham isso ruim. Estamos ensinando coisas estranhas, mesmo que devêssemos ensiná-los a desenvolver para Android, iOS, como usar Git e tudo mais. Na realidade, parece que não é o caso. A faculdade é uma época em que seus pais pagam a maior parte dos seus estudos. Por toda a sua vida. E você pode dedicar cinco anos da sua vida a um estudo aprofundado. E a aprender toda essa coisa em formato de T. Na faculdade, você aprende sobre sistemas de controle de versão, padrões de desenvolvimento, como testá-los, bancos de dados e balanceadores de carga. E quando começa a trabalhar, você se aprofunda em uma área específica. É assim que formamos engenheiros. Nosso sistema educacional na Rússia está muito mais próximo dessa realidade do que imaginamos. Recebemos uma boa base matemática, uma boa base algorítmica e alguma compreensão de linguagens de programação. E acho que o processo de entrevista é semelhante. Precisamos entrevistar engenheiros. Precisamos da parte superior do T em um sistema em forma de T. Porque ela terá a linha vertical do T.
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
