Entrevista com Alexander Titov, um dos membros do comitê de programa da nossa
conferência HighLoad ++ de junho, cuja seção separada será dedicada ao DevOps.
Sob o corte sobre qual direção o "vento" do DevOps sopra, e quais exatamente os aspectos desse conceito serão discutidos no fórum.
Alexander é bastante familiar à nossa comunidade, ele é o organizador do DevOps Moscow e da conferência DevOpsDays Moscow, ele discursa em nossos eventos há vários anos e ajuda na formação de seus programas. Atualmente, ele é sócio-gerente da Express 42, que desenvolve DevOps em empresas de tecnologia. Anteriormente, de 2010 a 2012, Alexander passou por um fascinante caminho de aquisição com a Qik, desde a operação de uma startup em rápido crescimento até a operação em uma grande empresa internacional Microsoft. Antes disso, em 2009-2010, ele foi diretor técnico da primeira hospedagem em nuvem na Rússia, Skalaxi.- Vamos começar de longe: a cultura do DevOps está evoluindo? Que mudanças foram observadas nessa área nos últimos anos? E como é o DevOps na Rússia?É claro que, em um mundo em que a tecnologia muda a cada três anos, tudo muda constantemente. Inicialmente, o problema básico era a produção e operação do próprio software na era digital. Em torno desse problema, o movimento DevOps se reuniu. Agora, o problema básico foi dividido em muitas subcategorias - gerenciamento de infraestrutura, monitoramento, integração contínua, entrega contínua, trabalho com pessoas (em particular, o problema de esgotamento de pessoas envolvidas na exploração e desenvolvimento), algumas coisas tecnológicas (por exemplo, a aparência do Kubernetes, como padrão de fato para toda a plataforma de infraestrutura nas empresas). Ou seja, em muitos aspectos, surgiram detalhes específicos: passamos pelo estágio de entender o que precisa ser feito de maneira diferente como antes, tentamos muitas novas abordagens e chegamos à formação de alguns processos padronizados para resolver problemas comuns (típicos). Mas, ao mesmo tempo, as ferramentas e processos em muitas empresas em todo o mundo ainda permanecem com baixa qualidade ou muito mal formalizados.
No contexto russo, um problema adicional é que não entendemos por que tudo isso é necessário. Isso desorienta muitos. Temos desenvolvimento, teste e operação separadamente e, em seguida, alguns Kubernetes entram para resolver alguns problemas, mas tentam implementá-lo sem alterar os processos, abordagens e competências das pessoas. Tudo quebra. E por que essas novas tecnologias não são claras.
- E qual é o motivo de uma transformação tão radical?Como eu já mencionei, começamos a resolver outro problema. Inicialmente, a TI clássica resolveu o problema de automatizar processos de negócios dentro de uma corporação. Toda a infraestrutura foi ajustada para isso - bancos de dados, ônibus etc. Desde 2000, após a crise das pontocom, a TI mudou para a criação de produtos digitais que podem fornecer massivamente serviços personalizados, agregando algum valor. Se antes a empresa produziu um determinado modelo de carro, agora mudou para a personalização de cada cliente. Esta é uma solução para outro problema, para o qual são necessárias abordagens e tecnologias fundamentalmente diferentes - um processo de produção de software diferente. Aqui não é mais possível desenvolver, testar e operar sequencialmente. Agora esses processos começam simultaneamente.
A propósito, apesar disso, há um equívoco de que o DevOps seja sobre operação. Os administradores de sistemas clássicos que executam trabalhos operacionais são simplesmente renomeados engenheiros de DevOps, desacreditando o termo em princípio. De fato, o conceito é muito mais amplo. Esse é um conjunto separado de práticas, uma estrutura separada que permite resolver problemas específicos em determinadas condições e com pessoas de uma determinada competência - nem mais nem menos. Apenas poucas pessoas entendem por que isso é necessário. E este é um dos problemas que estamos tentando resolver por meio de conferências.
-
Quais relatórios estão planejados para focar em seções dentro do Siberian HighLoad?Se anteriormente havia principalmente relatórios operacionais, este ano queremos adicionar mais informações sobre a conexão com o desenvolvimento, por exemplo, sobre processos de entrega contínua, integração contínua, testes. Um exemplo interessante é um relatório de Maxim Lapshin no RIT ++ (como parte do RootConf 2018) sobre como usar o DevOps no desenvolvimento de caixas. Essa empresa basicamente não tem exploração - faz uma caixa que vende para um cliente. Ao mesmo tempo, ela tem DevOps dentro. Essa abordagem quebra o padrão, mas ao mesmo tempo ajuda a desmascarar o mito mencionado de que o DevOps é apenas uma operação. Este é o nosso primeiro foco básico.
O segundo foco são as novas tecnologias. Agora está na moda falar sobre Kubernetes, Prometheus e outros. E procuramos pessoas que pudessem sentir essas tecnologias na prática. Ou seja, não apenas configurado e feito para funcionar, mas também incluído isso em seu processo de desenvolvimento. Em geral, tentamos considerar todas as tecnologias sob o prisma de como elas são incluídas no processo de produção de software - que problema elas resolvem, que objetivos são definidas etc. Se você não fala sobre isso, as pessoas começam a trabalhar com a tecnologia como um culto à carga: "Vamos colocar o Kubernetes e podemos criar o Google". Não vai funcionar dessa maneira.
- O conceito de integração contínua já é bem aceito pelo mercado. Além de ferramentas específicas, há algo para se falar?Claro. O conceito básico, pode-se até dizer, crucial é que, no contexto do DevOps, os produtos não sejam testados quanto à qualidade dentro do processo de integração contínua. Ou seja, não importa a maturidade funcional do produto. É importante verificar o quão bem ele inicia e se está pronto para integrar-se com outros componentes.
Essa é uma mudança importante, porque há uma integração contínua no desenvolvimento, operação e teste consistentes. Porém, nesse nível, a qualidade do produto é verificada de acordo com os requisitos do usuário e, dentro da estrutura do DevOps, as qualidades funcionais são verificadas. É esse estágio que permite a integração mais rápida possível de serviços individuais na estrutura da infraestrutura de microsserviço (e o DevOps como um todo não existe sem uma arquitetura de microsserviço).
- Quais ferramentas estão em foco este ano?Primeiro de tudo, os Kubernetes já mencionados. Apareceu há algum tempo, mas apenas recentemente chegou ao estágio em que pode ser usado. Agora ele pode ser usado por qualquer empresa que desenvolva um serviço digital atualizado, por exemplo, fornecendo serviços através de sites ou aplicativos móveis.
Geralmente chamado de Prometheus - um sistema de monitoramento, GitLab - como um sistema de integração contínua. E também toda a pilha HashiCorp - Vault, Terraform (ambos desenvolvidos pela HashiCorp). Bem, é claro, Docker - como um formato de entrega.
- Há mudanças recentes na estrutura do conceito de "tudo como um código"?A prática de "tudo como um código" em si é obviamente útil. Esse é um dos princípios fundamentais nos quais o processo do DevOps se baseia. Kubernetes está apenas continuando essa ideologia.
No DevOps, a história principal é "infraestrutura como código". E esse não é apenas um conceito, mas também um processo no qual todos os componentes são apresentados na forma de código que permite que "partes" individuais da infraestrutura interajam. Não há mudanças drásticas aqui, mas, como prática, agora está se desenvolvendo dentro do Kubernetes. Por exemplo, são desenvolvidas ferramentas de gerenciamento de dependências, como Helm, ferramentas para criar módulos separados, descrições de infraestrutura, por exemplo, operadores (e aparecem estruturas para escrever instruções no Kubernetes), etc. Em outras palavras, há um desenvolvimento saudável do instrumento e a penetração da prática nele.
- Vale a pena falar sobre a prática de “tudo como um código” separado do instrumento?Ainda não formamos completamente um programa, por isso não posso dizer se abordaremos esses tópicos especificamente no HighLoad ++. Mas isso por si só é possível.
Existem muitas abordagens para organizar a infraestrutura, gerenciar a dependência no código da infraestrutura e testá-la. Obviamente, falaremos sobre conceitos para trabalhar com a prática - por exemplo, que o código de infraestrutura deve ser dividido em módulos. Parece-me que refinado, isoladamente da prática, esses tópicos não se encaixam muito bem. Mas, talvez, escolheremos um relatório em que todas as abordagens possíveis serão coletadas dentro da estrutura de uma única descrição do sistema. No entanto, é muito mais valioso quando as pessoas contam e mostram como esses conceitos teóricos são realizados na realidade. Sobre a teoria subjacente às práticas, você pode conversar com as mesmas pessoas à margem.
- Há uma opinião de que a popularidade da arquitetura orientada a eventos está crescendo ao longo do tempo. Você concorda com esta afirmação?A infraestrutura orientada a eventos sempre fez parte da abordagem dos chatops - por evento, tomamos uma decisão no bate-papo sobre o que deve acontecer com uma parte da infraestrutura. Essa história é muito necessária para grandes empresas de grande porte, mas para o restante do público ainda não está madura. Para tomar decisões sobre o que deve acontecer (o que devemos fazer), é necessário desenvolver alguma estrutura para as regras dentro das equipes sobre como tomamos essas decisões, para que todos façam mais ou menos da mesma maneira - olhe de um lado. E com isso, tudo é complicado. O formato para o desenvolvimento dessa estrutura é o que todos estão falando agora: como ela pode ser automatizada, levada a uma ferramenta, como deve ser feita no nível de criação de equipes e como coordenar com diferentes equipes.
- Isso de alguma forma se reflete nos relatórios da conferência?Não, o HighLoad ++ é mais sobre sistemas e ferramentas altamente carregados; portanto, aqui podemos falar sobre ferramentas, mas não sobre o desenvolvimento dessa estrutura. Mas no outono, teremos uma conferência RootConf separada, que será realizada de 1 a 2 de outubro. Até 2011, era dedicado a problemas operacionais (ou seja, apenas um componente de todo o processo "operação de teste de desenvolvimento"). Em 2015, reencarnamos no contexto de todo o DevOps - então expandimos o tópico gradualmente. No RootConf, discutimos como garantir a interação de desenvolvedores e engenheiros de manutenção, falamos sobre novos processos e tecnologias, sobre plataformas de infraestrutura e gerenciamento de infraestrutura, que no paradigma DevOps não estão envolvidos apenas na operação, mas também no desenvolvimento (eles apenas executam tarefas diferentes).
- Houve tecnologias interessantes para melhorar a resiliência dos projetos nos últimos dois anos? Eles serão discutidos na conferência?Hoje nos deparamos com um paradoxo relacionado ao fato de que “tolerância a falhas” não significa “confiabilidade”. A tolerância a falhas agora é suplantada pela confiabilidade.
Tolerância a falhas é um conceito do paradigma de sistemas monolíticos, onde o problema de confiabilidade foi resolvido através da duplicação, aumento de recursos, etc. Agora, essas abordagens não funcionam mais. A confiabilidade é baseada em abordagens fundamentalmente diferentes - implica a "anti-fragilidade" do sistema. Ou seja, o sistema se torna "suave": se agirmos sobre ele, ele muda, não entra em colapso. Em outras palavras, se você deseja criar algum tipo de novo serviço, deve fornecer variantes desse comportamento em que, se o usuário ou o ambiente em que ele trabalha tenta destruí-lo, o serviço simplesmente altera suas propriedades, enquanto o serviço ainda é fornecido , algum resultado é dado.
Um bom marcador dessa tendência é o surgimento da engenharia de confiabilidade do local como prática e especialistas individuais - engenheiro de confiabilidade do local (SRE) como substituto da competência anterior do administrador do sistema. Como ilustração desse processo, mencionarei que o Google lançou sua prática de implementação do DevOps na forma de um livro sobre engenharia de confiabilidade do site e está promovendo ativamente essa idéia para as massas.
Também falaremos sobre isso no RootConf. Agora, este tópico está no hype no Ocidente, e nós (pela comunidade DevOps de Moscou) estamos tentando trazê-lo gradualmente para nós.