Este habrapost é uma entrevista com Anton Weiss, co-proprietário da consultoria de tecnologia Otomato Software, proprietário de mais de 15 anos de experiência no campo da alta tecnologia. Ele é especialista em ensino técnico, iniciador e co-autor do primeiro curso de certificação de Israel para DevOps. Anton participa de conferências internacionais e é conhecido como um orador legal.
Falaremos sobre os seguintes tópicos:
A diferença entre Rússia e Israel
Oleg: Por favor, me diga quem você é e o que faz.Anton: Eu sou Anton, nasci em São Petersburgo, mas me mudei para Israel aos 15 anos e moro lá desde então. Nos últimos vinte anos em Israel, participei de TI em suas várias formas. Desses vinte anos, os últimos dez se especializaram em tudo relacionado à entrega de software: integração, o que antes era chamado de gerenciamento de configuração e o que agora é chamado de DevOps. Trabalhei em grandes empresas - em empresas internacionais como AT&T, BMC. Ele trabalhou em startups. Nos últimos quatro anos, tive minha própria empresa de consultoria, chamada Otomato Software, onde estamos comprometidos em ajudar as organizações a otimizar os processos de entrega e dominar novas ferramentas: ou seja, fazemos a parte técnica e tudo o mais.
Oleg: Existe alguma diferença entre a Rússia e Israel em termos de trabalho?Anton: Eu quase não trabalhei com clientes russos. O fato de os últimos três anos me conectarem com a Rússia são conferências. E em várias empresas russas, realizamos algo como uma auditoria: chegamos, examinamos, resolvemos, emitimos algumas recomendações e saímos. Ou seja, não havia especificamente esse trabalho diário, por isso é difícil dizer exatamente como isso difere. Eu acho que há todo tipo de coisas diferentes. Ou seja, no mesmo Israel, temos organizações corporativas tão pesadas nas quais as pessoas trabalham há 15 anos e tudo está mudando muito. E não importa como eles tentem fazer algum tipo de transformação, melhorar processos: eles conversam, conversam, mas ... Temos um cliente com quem fizemos tudo há dois anos e tomamos todas as decisões, desenvolvemos todos os programas e nos quais então, no momento em que tudo parou, saímos de lá. Apenas alguns dias atrás, conheci a partir daí os chefes com quem trabalhamos, eu digo:
- como?
- Bem então. Dizem que é difícil, estamos fazendo, agora algo está começando a acontecer.
Dois anos depois. Há política, há zonas de influência. Existem pessoas que não querem liberar essas zonas de influência, respectivamente, quando tal situação, é muito difícil mudar alguma coisa. Bem, o próprio kit de ferramentas está de alguma forma avançando. Por outro lado, em Israel, existem startups nas quais tudo muda muito rapidamente, é fácil criar um novo tuling, e todos são nativos da nuvem e estão completamente sentados na nuvem. A propósito, essa pode ser uma dessas diferenças tangíveis entre a Rússia e Israel. Em Israel, com uma nuvem pública é muito mais fácil. Pelo que vi. Na Rússia, por exemplo, parece que é muito difícil para todos, exceto as iniciantes, entrar na nuvem pública, mas em Israel ainda é mais fácil. Hoje, mesmo bancos e companhias de seguros já entendem que pelo menos parte de suas coisas pode ser lançada na nuvem pública. E aqui, contratos com Google e Amazon não assustam ninguém. Pelo que ouvi nas conferências na Rússia, ainda é ainda mais complicado, bem, mesmo do ponto de vista das sanções, não das sanções e de algumas questões legais.
A diferença entre startups e gigantes
Oleg: Entendi . A propósito, onde é mais interessante e agradável para você trabalhar: em startups ou em grandes organizações?Anton: É mais agradável, é claro, nas startups, porque grandes organizações ... bem, realmente apenas o material se move muito. Existem vantagens, é claro. Se você olhar para grandes organizações, elas, por exemplo, têm muito mais do que aquilo que se chama diversidade. As grandes empresas simplesmente porque precisam de muitas pessoas ou porque é algum tipo de cultura organizacional que se desenvolveu ao longo dos anos, estão prontas para contratar pessoas diferentes. Especificamente, em Israel, por exemplo, em startups você quase não encontrará, por exemplo, árabes, eles estão quase ausentes. Nas grandes organizações, isso é muito mais fácil. Mas as startups já estão crescendo com algum tipo de contexto cultural em que a maioria dos participantes é basicamente o mesmo homem branco. Existe uma cultura do que precisa ser rasgado adequadamente, e é aconselhável trabalhar 10 a 12 horas por dia, e isso também não é suficiente. Parece que Moscou (ou seja, Tel Aviv) está atrás de nós, não há para onde recuar e, portanto, deve sangrar aqui e agora.
Oleg: E a diferença de abordagem do DevOps em pequenas e grandes empresas? Ou seja, se você, por exemplo, trabalha para duas pessoas, não pode configurar seu próprio CI / CD, mas copiar artefatos do SCP.Anton: Por um lado. Por outro lado, configurar o CI / CD hoje não significa que você realmente realiza entregas contínuas. Mas configurar algum tipo de pipeline, se você é uma empresa de duas pessoas, é muito, muito simples. Se antes você tinha que ficar confuso de alguma forma, hoje você tem muitos serviços em nuvem. Escreveu YAML - e para frente, vamos lá. Isto é mais fácil. De fato, o desafio são as startups de inicialização. Aqueles que foram além de 20 pessoas, e aqui começam a sofrer com descamação, porque não há processos. Tudo costumava funcionar de alguma forma, mas então toda essa bagunça começa, e não está claro como podemos manter esse antigo dinamismo e, ao mesmo tempo, conduzir processos, e decidir quem mais fará tudo isso.
E então tudo começa, como "teremos uma equipe de DevOps que será responsável por DevOps", sabemos o que isso leva na maioria dos casos. Um gargalo aparece e, gradualmente, eles crescem para onde as grandes empresas estão agora. As grandes empresas têm um infortúnio completamente diferente, elas nem sequer têm um gargalo, mas simplesmente um gateway poderoso que abre uma vez por dia e, durante todo o tempo, uma enorme quantidade de lixo é acumulada lá. E assim eles pensam: “Como podemos fazer agora muitos pequenos gateways desse gateway que podem ser abertos muito mais facilmente?” Ou seja, problemas completamente diferentes. As startups têm um problema com o fato de que “estamos sendo sugados para o funil, como podemos nadar?”. E para as grandes empresas - elas já estão no funil, já estão no submundo, agora estão pensando em nadar de volta para cima.
A tendência está aumentando a complexidade e o que fazer sobre isso
Oleg: Bem, além da parte técnica: quando você tem poucas pessoas, tecnologias simples, precisa conhecer um pouco de Linux básico, e é isso. E com a menor escala, você precisa aprender alguns Kubernetes, e esse parece ser o problema.Anton: E isso é sem dúvida um problema. Tivemos uma conferência há apenas dois dias, e foi notável que quase todo mundo que disse algo mencionou uma palavra: “complexidade” (complexidade). Isso se tornou um tipo de palavra definidora para todo o discurso do DevOps hoje.
Oleg: Isso foi há um ano?Anton: Na tentativa de fazer tudo de forma rápida e dinâmica, para alcançar a notória flexibilidade, nos envolvemos com tanta complexidade. De fato, existem muitos pequenos dutos que funcionam maravilhosamente separadamente, e então tentamos coletar alguma imagem do mundo disso tudo, e aqui a complexidade surge repentinamente. Porque agora estamos construindo um processo em todos esses pequenos pipelines para que toda a empresa funcione como um ser humano.
Oleg: E qual é a resposta? Como gerenciar essa complexidade?Anton: Bem, não há respostas, elas nascem no processo. Meu relatório foi sobre uma dessas soluções. Em geral, tudo isso vai acontecer? Uma vez eu fui infectado com o pensamento sistêmico, muito é mencionado sobre isso no DevOps. Interessei-me, li os livros de Peter Senge, Russell Ackoff, Donella Meadows - pessoas que começaram a pensar de algum modo sistêmico e, em geral, expuseram seus principais postulados. Um dos principais prismas pelos quais o pensamento sistêmico olha o mundo são os ciclos de feedback. Com essa complexidade, esses loops de feedback agora surgem, ou seja, a complexidade se torna muito, muito alta, começamos a procurar ferramentas para, de alguma forma, levar em consideração essa complexidade. Não estou dizendo reduzir - tomar uma rédea para não rolar.
As soluções centralizadas aparecem; em geral, até o Kubernetes é algo assim. Você tem um plano de controle centralizado, que no momento o controla, controlará a complexidade dos serviços que são executados. A peneira de serviço, a mesma malha de serviço, é o mesmo tipo de solução. Dizemos: "Temos vários serviços, é necessário que eles possam conversar de alguma forma, porque eles não entendem onde estão sentados e não está claro se eles responderão ou não, e eles não vão lidar. Então, vamos fazer agora, no meio, inseriremos uma mente universal que dirá a eles, com quem você pode conversar, com quem não pode falar e os protegerá se eles repentinamente disserem algo rude em resposta ". E há muitas perguntas. Por um lado, isso é um tipo de necessidade, porque as organizações não conseguem lidar. Nos últimos anos, ajudamos várias organizações a migrar para o novo mundo arrojado do Cloud Native, especialmente quando se trata de crescimento, dimensionamento e crescimento de empresas, e as pessoas simplesmente se perdem. No meio de tudo isso, há uma pequena equipe dos chamados DevOps, que precisam escrever milhares de linhas YAML para lidar com tudo isso, e tudo simplesmente explode.
Nuvem nativa
Oleg: Você pode explicar um pouco o que é o Cloud Native? Como se tornou algum tipo de palavra da moda, agora todos escrevem em todas as paredes. Como você vê isso?Anton: De modo geral, tudo começou com o surgimento da abordagem de “plataforma como serviço”, isto é, quando precisávamos executar muito mais software e muito mais serviços da Web do que antes. Percebemos que não é mais possível implementar cada serviço separadamente como animal de estimação favorito, que conhecemos pelo nome e cuidamos dele por toda a vida, precisamos lidar com eles como uma espécie de rebanho. Para fazer isso, precisamos de algum tipo de plataforma homogênea na qual possamos descartar esse código, e a plataforma será inteligente o suficiente para servi-lo. Bebedor de carro, em suma, um bebedor-alimentador de carro para serviço.
Os pioneiros dessa abordagem foram Heroku. Eles disseram que, para que esses serviços usem nossas infra-estruturas, eles também devem ser vacas. Ou seja, eles devem ter certas qualidades. Portanto, havia uma aplicação de 12 fatores, que deveria ter o menor estado estável possível. Esse aplicativo é necessariamente montado por um determinado pipeline no qual sua compatibilidade com a plataforma é verificada. Ele deve ser capaz de ser resiliente (estável) - saber que, se algo der errado, não caia imediatamente. Por outro lado, de certa forma, conte com a plataforma. Em geral, esse híbrido. Entenda que você não está por conta própria, que existe uma plataforma e deve respeitar suas limitações. De um modo geral, tudo começou a partir daí.
Mas, por alguma razão, essa abordagem de “plataforma como serviço” não se justificou e o boom prometido não aconteceu. Ou seja, sim, era Heroku, e imediatamente depois deles todos os grandões também criaram seus análogos: Google App Engine, Amazon - Elastic Beanstalk. Eu tive que trabalhar muito com empresas que começaram com isso. Mas, no momento em que você está fazendo algo que ultrapassa ligeiramente os limites permitidos pela plataforma, isso se transforma em uma terrível dor de cabeça. Porque você começa a se deparar com paredes que estão por toda parte. E como as pessoas tendem a, quando tropeçam nas paredes, começam a procurar uma maneira de atravessar a parede.
O moderno Cloud Native cresceu a partir daí: como fazê-lo funcionar ainda na nuvem, usar alguns serviços de plataforma, mas também fornecer uma incrível flexibilidade para tudo o que acontece. Equilibramos constantemente entre flexibilidade e simplicidade. A flexibilidade causa complexidade, enquanto simplificar e criar uma plataforma clara sempre causa limitações. Aparentemente, o Cloud Native está encontrando algum tipo de equilíbrio entre as limitações da plataforma em nuvem e a flexibilidade que a nuvem permite com seu dimensionamento automático, e tudo isso tem um preço.
Oleg: Provavelmente, a própria organização deve de alguma forma aprender a viver processualmente com todas essas coisas.Anton: Naturalmente, naturalmente! Tudo isso deixa sua marca. Os microsserviços também pertencem a isso. Em geral, essa é a idéia de que temos pequenos serviços, pequenos aplicativos espalhados pela nuvem e podem estar em qualquer lugar a qualquer momento, e pode haver 10 réplicas agora e amanhã - 1.500, isso também faz parte da nuvem Nativo A ideia de que não estamos limitados pelos limites físicos do data center. Em geral, o mundo inteiro é minha nuvem, é uma visão absolutamente maravilhosa, uma busca maravilhosa, mas tem um preço, e esse preço é complexidade, o preço é que, em geral, ninguém na cabeça pode se encaixar no que acontecerá, quando nosso aplicativo cresce repentinamente de 10 instâncias para 1500. Ninguém pode imaginar isso, e todos os artefatos de dimensionamento começam a aparecer. Como seres humanos, como operadores, não podemos fazer nada com isso, exceto para responder ao caos que está acontecendo. E então começamos a pensar: “Mas como podemos construir nosso aplicativo e nossa infraestrutura para que, quando esses artefatos surgirem, primeiro eles possam ser previstos e, em segundo lugar, de alguma forma, possamos lidar com esses artefatos e continuar funcionar? "
Combinando habilidades técnicas e não técnicas
Oleg: Você tem relatórios sobre assuntos técnicos, por exemplo, sobre uma peneira de serviço e há relatórios sobre liderança, sobre gerenciamento, tudo isso. Você é mais uma pessoa técnica, é gerente ou seu trabalho é de alguma forma diferente?Anton: Eu comecei a escrever em algum momento sobre este post, ainda não o terminei. De certa forma, estou dividida puramente pessoalmente entre essas duas coisas, porque, por um lado, gosto de entender como as coisas funcionam, gosto de lidar com elas. Quando é possível resolver um problema técnico, apenas dá uma sensação incrível das habilidades de alguém, o que é chamado de gratificação instantânea, recompensa imediata, enchimento de dopamina: "Oh, legal, eu posso, eu decidi." E é difícil recusar, é difícil sair. E como é, continuo fazendo coisas técnicas. Novas tecnologias me excitam: é legal escolher algo, entender algo. Por causa disso, acontece que, como existe esse conhecimento, as pessoas querem comprá-lo e eu continuo vendendo.
Por outro lado, entendo que esse é apenas um pequeno pedaço do cenário geral, trabalho na indústria há muito tempo e não posso deixar de ver que a tecnologia é apenas um canto de um sistema grande, apenas um dos componentes. Gerenciei as equipes e entendo como é importante considerar a interação de tecnologias e ferramentas com as pessoas que as utilizam. No final, a tecnologia da informação, de fato, qualquer tecnologia, existe para as pessoas a usarem. E criar tecnologias sem pensar em quem as usa é completamente inútil. A tecnologia em si não é de todo interessante, a menos que você pense sobre sua aplicação, e a aplicação está sempre associada a pessoas que de alguma forma se beneficiam dela. E, portanto, tudo em torno da tecnologia também está muito interessado em mim. Eu sinto que é necessário falar sobre isso, eu entendo que sem isso, tudo realmente não faz sentido. Na medida em que às vezes fico chapado para sentar, algo para cheirar lá por dois a três dias, às vezes semanas. Posso me deixar levar por algum tipo de problema que não consigo resolver, posso resolver, obter uma paróquia incrível com isso. Mas então levanto a cabeça do teclado, olho em volta e entendo que algo está acontecendo ao redor que não posso ignorar. E então o código e a seleção no Linux se tornam completamente desinteressantes para mim, sem importância, e eu quero começar a resolver problemas em um nível diferente, em um nível humano.
Como descobrir rapidamente DevOps
Oleg: Escute, você pode aconselhar algo para as pessoas que agora estão envolvidas em engenharia e estudando as práticas de DevOps ao mesmo tempo? Como enfiar tudo dentro e em que ordem? Relativamente falando, como planejar, talvez, sua carreira para se tornar mais bem-sucedida em pouco tempo?Anton: Eh ... Bem, não há dicas universais, novamente, da minha própria experiência. Durante muito tempo, provavelmente nos primeiros 10 anos da minha carreira, fiquei descontente com o meu lugar. Eu estava procurando o que não gostava, estava focando nisso, estava procurando o que seria mais interessante para mim fazer. Mas, em geral, ele não fez nada sobre isso. O conselho principal é ... Em que momento acho que minha carreira foi subida? No momento em que comecei a falar sobre coisas que eram interessantes para mim. O campo do conhecimento técnico, mesmo não apenas técnico, em geral, o campo da tecnologia da informação é muito amplo, ou seja, você pode ser um técnico: um desenvolvedor, um testador, um integrador e um administrador de sistemas - essas são coisas diferentes, todos podem encontrar seu próprio nicho lá. Você não quer ser um técnico completamente, está interessado em assuntos técnicos e, ao mesmo tempo, comerciais? Envolver-se em um produto, um projeto. O nicho está cheio, encontre o seu nicho que lhe interessa.
Agora se fala muito de profissionais na forma de "T". Você precisa entender onde está o seu pé T, escolher uma coisa, começar a cavar neste lugar. Profundidades tremendas serão encontradas no momento da escavação. Mas você pode cavar em qualquer lugar. E eu estou bem ciente de que há muitas áreas que eu não cavei profundamente, porque tentei olhar e percebi que não era minha. E aqui, onde você está interessado em cavar - continue cavando, e aqui é muito importante falar sobre isso. Ou seja, novamente, eu entendo que isso não é para todos. : -, , , — , Gist' GitHub. - — .
. DevOps — . , , . , , , , - , - , , - . , . , , , , , , , . , . . ? — , , . , , . , . Algo assim. .
: , , DevOps', , . , , . , -, , … , . - , ? . , , : « ». , ?: -, , , : « ». - , , , , . , , : « ».
: ?: , , , , , . , — . , , «, , », - . , - , . - , - . , Agile: , , , , , .
, . . , — , - — , , — , , , , , . : « — , . , , . , . , , , -, , , ». , , , .
, - , , continuous integration … , , , . , , . , 10 : , , - , , , , , , , , . — . : , , , , . E - , , .
: . , - , , - , , , , DevOps -. ?: , , , , . , , , , ? , , . . - , , .
, , . , , .
DevOps
: , : Google, Netflix, . , ?: , , ( ) , — , , , . , , lean management — value stream mapping. . , , , - : , , , , , , , , . , , , .
: ? - — - , , — . , , , , . , , , Java, , , . , :
— , .
— , ? ?
— , , .
, , , , — , . — , .
, :
— .
:
— , , . .
, , :
— .
:
— . ?
:
— , .
, — , , . . . , CI/CD — . , . , , . , , .
: , ? , CI/CD . ?: -, , . - , , , , . Kubernetes: , — Kubernetes. VMware , Kubernetes . , Google . , , .
: Google ?: , , Swarm Kubernetes, Docker. Docker , . , Microsoft, Amazon — « Docker». Docker! Docker . , , , , Google, Microsoft, Amazon? , . , , , . , . E assim aconteceu.
Então aqui. . — . — « Kubernetes , ». . Kubernetes . Kubernetes — - API, , . API . — , , , , : « API, , Kubernetes, Kubernetes , ».
— , Continuous Delivery Foundation, - , , Google, CloudBees, GitLab. Tekton, — API continuous delivery-. , continuous integration / continuous delivery- Kubernetes, , , . ,
. Microsoft , , SMI Spec. , , - .
Kubernetes . , , - , , Kubernetes — .
Oleg: Em quais relatórios você estuda, o que acha interessante?Anton: Primeiro de tudo, se houver algum novo recurso tecnológico, um desvio que ainda não tenho tempo de ver por mim mesmo, e houver um orador que possa falar sobre isso de maneira inteligente, então acho que essa é uma vantagem selvagem, porque, em vez disso, para ler e desenterrar agora, e talvez com dificuldade em entender, você pode vir ouvir em meia hora como uma pessoa vai lhe mostrar, lhe dizer. Novamente, para isso, você precisa de uma certa habilidade e desejo de poder falar sobre tecnologia. E eu entendo que isso também não vem de lugar nenhum, precisamos trabalhar nisso. Levei muito tempo também. A propósito, o fato de eu estar envolvido no ensino técnico me ajudou muito nisso. Quando você tem uma aula à sua frente, precisa explicar algo para as pessoas e entende que, não importa como explique, elas são estúpidas - você percebe que, aparentemente, o problema é como você explica, e não que as pessoas são estúpidas .
Oleg: E que tipo de ensino técnico? O que voce esta fazendoAnton: Eu ensino disciplinas puramente técnicas há cerca de 7-8 anos. Tudo começou com o fato de eu ter ensinado coisas como Maven e scripts de shell por um ano. Como eu estava muito ocupado com Jenkins e o conhecia profundamente, ensinei as pessoas a trabalhar com a administração de Jenkins. Nos últimos anos, tudo relacionado ao nativo da nuvem: Kubernetes, contêineres e tudo ao seu redor. Vou para Londres em breve, darei uma aula de mestrado no Istio. Esta não é a parte principal da minha atividade, mas em um mês ou dois eu conduzo aulas de mestrado.
Oleg: Você vai principalmente a um relatório, a um tópico ou a uma pessoa?Anton: Se eu sei que o orador é bom, vou a uma pessoa simplesmente porque ainda é muito importante para mim aprender com outras pessoas como saber bem. Aprender é sempre importante. Se houver um tópico, mas eu não conheço o orador, então irei ver, mas como de costume, como ir para o stand-up: olhei os primeiros 10 a 15 minutos, não entrei - saí. Ou há palestrantes que eu realmente irei de qualquer maneira, porque eles sempre dizem de maneira interessante, mesmo as coisas que você sabe que podem mostrar do seu ângulo, é apenas para você e transforma toda a questão de uma nova perspectiva. Daqueles que eu gosto ultimamente ... Primeiro, há Simon Wardley - um consultor, ele tem seu próprio chip com cartões de desenho, ele explica com a ajuda de cartões como as empresas podem construir sua estratégia corretamente, ele já foi então CTO, CEO de startups, ele fala muito sobre isso, sobre tecnologia. A propósito, ele se afoga constantemente para sem servidor e diz que aqueles que não o fazem hoje em dia têm grandes problemas.
Oleg: É este o camarada que tem o livro Medium ? Ele fez isso na forma de posts. Formato incomum.Anton: Ele realmente fala muito legal. Suas palestras nos últimos 2-3 anos me lembro mais. Bem, John Willis, que veio para o DevOops no ano passado - simplesmente porque ele
realmente sabe como contar . Há algum problema com ele, porque ele fala muito sobre a realidade americana, coisas que às vezes simplesmente não se aplicam à realidade russa ou israelense. Agora eles têm algum tipo de guerra agora com alguns conselhos de aprovação de mudanças, sobre os quais falam constantemente. Aparentemente, isso é algo que existe nas empresas americanas; existe um processo para conduzir e aprovar mudanças em TI; alguns tipos de compromissos precisam ser cumpridos.
Oleg: Mas nós não temos isso - eu nem entendo do que você está falando agora.Anton: Então, eu também não entendo, também não existe isso em Israel. E lá eles falam sobre isso. Se você ouvir todos esses camaradas, como o DORA, que
fazem o relatório State of DevOps , eles escrevem muito sobre isso também. Em geral, quero dizer que as pessoas estão falando sobre algum tipo de problema que somente eles têm, e você não está nem um pouco interessado.
Oleg: Você esteve no último DevOops, para quais relatórios vale a pena analisar e revisar as gravações?Anton: Veja
todo mundo . Um pouco interessado no tópico - vá.
Oleg: Há algum Anton Weiss, na minha opinião. Provavelmente vale a pena dar uma olhada.Anton: Não, não faça isso, algumas coisas chatas :-)
Oleg: Bem, muito obrigado. Isso foi demais! Vejo que você já enviou um relatório para a próxima conferência, então - até o próximo DevOops!A conferência DevOops 2020 em Moscou será realizada de 29 a 30 de abril, desta vez em Moscou. Descrevemos a essência da conferência sobre Habré no anúncio "Os engenheiros de DevOps não existem" . O programa está sendo formado ativamente (ainda há muitos meses antes da conferência), mas os primeiros palestrantes já podem ser vistos no site . Você pode comprar ingressos lá .