DevOops 2019 através dos olhos do desenvolvedor

29-30 de outubro em São Petersburgo sediou a conferência DevOops . Neste artigo, compartilharei minhas impressões e idéias, além de breves notas sobre os relatórios que ouvi. Um pequeno aviso: como sou desenvolvedor, alguns pensamentos e comentários podem ser tendenciosos no Dev do que no Ops, mas tentarei ser o mais objetivo possível.

O DevOops é um dos eventos organizados pelo Grupo JUG Ru . E devo admitir que a organização e o nível dos relatórios estavam no nível. A conferência durou dois dias, em três correntes. Além disso, havia áreas de discussão para comunicação com palestrantes, oficinas e palestras relâmpago - apresentações mais fáceis e curtas, inclusive para aqueles que ainda não se apresentaram e que desejam se apresentar como oradores.

Tela temática DevOops 2019 - nativo da nuvem. A maioria dos relatórios foi direta ou indiretamente dedicada às nuvens. O tópico não é novo há muito tempo, mas há muitas dificuldades não óbvias que surgem no processo de uso de tecnologias em nuvem. E muitos vieram de propósito para encontrar respostas. Isso foi especialmente notável nas sessões de controle de qualidade após as apresentações. Os palestrantes receberam perguntas práticas que realmente emocionam as pessoas. Quase todas as perguntas foram seguidas pelas observações de outros participantes: "Temos o mesmo problema!" E uma discussão animada começou.

Primeiro dia

Personagens, comunidade e cultura: fatores importantes para a prosperidade (Timothy Lister, The Atlantic Systems Guild Inc.)

A conferência foi aberta por Timothy Lister, que em 1987 (!) Escreveu um livro sobre as práticas de DevOps. Tim falou muito sobre o que distingue uma equipe forte e bem-sucedida com uma atmosfera saudável e agradável de uma equipe medíocre e tóxica. Lembrei-me especialmente do pensamento:

"Uma boa empresa está cheia de pessoas que dizem" eu não sei ".

Trata-se de abertura e confiança dentro da equipe. Uma atmosfera de abertura é essencial se você tiver um objetivo ambicioso. Para fazer isso, todos na equipe devem se sentir confortáveis ​​e livres. Isso não significa que, no caso de um problema, um membro da equipe o encaminhe imediatamente para todos. Uma atmosfera de abertura é importante e a capacidade, a qualquer momento, de recorrer a alguém específico (independentemente da posição) ou a toda a equipe e indicar claramente o que precisa ser aprimorado ou alterado. Essa cultura forma um fundo calmo para o trabalho, quando todos sabem que, se surgirem perguntas, serão ouvidos.

Na minha experiência, para uma operação produtiva e estável, esse fator é de grande importância. Afinal, sempre haverá perguntas, atritos e uma mudança de direção. E a atmosfera de abertura é uma ferramenta universal que permite lidar com os desafios pessoais e da equipe.

Outro pensamento que me parece correto: não existe uma fórmula verdadeira para construir uma cultura em uma empresa.

“Nenhuma cultura pode ser chamada de ideal. E nem uma única cultura pode ser chamada de falha completa. ”

Tendência recente: mais e mais conferências incluem relatórios sobre gestão, comunicação, formação de equipes e cultura. O DevOops não foi exceção. Acredito que essa é uma tendência positiva, porque esses fatores têm um impacto ainda maior no resultado final do que as dificuldades tecnológicas.

"O líder não gerencia a equipe, mas cresce."

Faça isso no código (não no YAML)! Desbloqueie o poder do Kotlin DSL para o Kubernetes (Victor Gamow, Confluent e Fedor Korotkov, Cirrus Labs)

Relatório semi-funerário, mas expressa completamente a dor de escrever infinitos arquivos YAML, seu suporte e (ah, horror!) Depuração em caso de erro ou erro de digitação. Isso até levou ao surgimento de posições separadas do engenheiro da YAML.

Como tudo começou? Era uma vez scripts. Então havia mais deles. E mais Era necessário unificar, simplificar e dimensionar soluções. Portanto, no mundo do DevOps, o formato YAML apareceu e se tornou o padrão em muitas ferramentas.

Os autores do relatório pensaram e disseram: "algo no conservatório está errado".

• Não está claro como testar arquivos YAML.
• É fácil cometer um erro. Além disso, alguns erros são quase impossíveis de detectar e muito dolorosos para corrigir. Por exemplo, você pode especificar facilmente a versão de uma dependência como um número, em vez de uma sequência. E depois descubra por um longo tempo por que a versão errada é usada, o que é indicado na configuração. E é tudo sobre fundição e arredondamento de tipos.
• Se o erro for sintático, ele será detectado com bastante rapidez, no IC. Mas isso não é exato.

O destaque do relatório foi o upload de uma configuração inválida para o Kubernetes, à qual ele respondeu com calma: Muitos erros .

Victor e Fedor se oferecem para escrever configurações no DSL Kotlin, o que ajuda a lidar com todos esses problemas. Sim, a solução é interessante e conveniente, mas não é universal e funciona apenas para os k8s. Além disso, no caso de atualizar a API, você também deve atualizar a biblioteca.

Pipelines e pods: DevOps com Kubernetes (Burr Sutter, Red Hat)

Um relatório leve sobre o conceito geral e os principais componentes do Kubernetes, bem como outras ferramentas e práticas de Ops da moda. Para um iniciante no assunto - o que é necessário. Isso se encaixaria perfeitamente no programa da conferência para desenvolvedores, mas era estranho ouvir um relatório desse nível em uma conferência especializada em DevOps. No entanto, a revisão acabou sendo boa, simples e clara.

Mas formar JSON a partir do código Java usando o StringBuilder é de alguma forma demais. Mesmo considerando que este é um projeto de demonstração.

Padrões e antipadrões de atualizações contínuas na prática do DevOps (Baruch Sadogursky, JFrog)

No relatório de Baruch, é difícil destacar qualquer ideia ou direção. Pelo contrário, é uma coleção de experiências pessoais, histórias de vida, exemplos de "como fazer o bem e o quão ruim", contos, outros hi-hacks e "fakapchikov".

Especialmente neste relatório, lembrei-me da história em que, devido a um erro no processo de implantação, o Knight Capital Group perdeu US $ 440.000.000 em 45 minutos e faliu.

No final, Baruch contou uma história sobre um bug no software Airbus A350. Por causa desse bug, as companhias aéreas foram forçadas a reiniciar a aeronave a cada 149 horas e, para isso, tiveram que ser plantadas no chão. E se alguém se esquecer de fazer isso, o avião irá congelar. Um bug tão desagradável. O problema é simples - o estouro ocorre no código. A correção também é simples. Mas suponha que eles ainda se esquecessem de reiniciar o avião, ele decolou em um vôo de Los Angeles → Londres e três horas antes do pouso, os pilotos perceberam que em uma hora o avião congelaria. "Houston, nós temos um problema." “Agora vamos consertar!” Os despachantes responderam, montaram programadores AirBus, consertaram, tudo funciona. O que fazer depois? Implantar uma nova versão em um avião por via aérea? Ou não correr riscos? Baruch estava determinado: “Implante. Não vai ser pior.

Segundo dia

CDK e infraestrutura como um código (Sergey Kurson, AWS)

Sergey falou sobre o AWS CDK (Cloud Development Kit). Este é um conjunto de bibliotecas que permite gerenciar sua infraestrutura de código. A decisão é controversa, pois o gerenciamento da infraestrutura em um estilo imperativo é uma espécie de reversão. Todas as ferramentas modernas de automação permitem descrever a infraestrutura em um estilo declarativo (ou seja, o estado que deve resultar). No entanto, existem vantagens para essa abordagem. Por exemplo, o processo de teste da infraestrutura implantada é bastante simplificado, e o processo de implantação e decisão do que e como implantar se torna muito mais flexível. Além disso, existem grandes oportunidades para gerenciamento de infraestrutura dinâmico e extremamente flexível por eventos, atributos ou métricas.

Por que precisamos de uma peneira de serviço? (Anton Weiss, Otomato Software)

Talvez um dos melhores e mais profundos relatórios desta conferência. Por "peneira de serviço", um alto-falante significa uma malha de Serviço - uma camada separada de infraestrutura em nuvem que controla a comunicação de serviços entre si. O padrão de malha de serviço delega muitas tarefas do nível de serviço (ou seja, do desenvolvedor do aplicativo) para o próprio nível de peneira de serviço (no DevOps):

• gerenciamento de segurança;
• monitoramento de tráfego;
• gerenciamento de tráfego.

Embora a malha do serviço como tecnologia já exista há vários anos, o autor fez um relatório detalhado e analisou a história de sua origem, como evoluiu e como se desenvolverá nos próximos anos.

O relatório é especialmente útil para desenvolvedores, pois as tarefas que a malha do Serviço resolve agora são resolvidas com frequência no nível de serviço. E isso leva tempo adicional aos desenvolvedores e dificulta a concentração na solução de problemas de negócios.

Acelerando as solicitações da Internet e dormindo em paz (Sergey Fedorov, Netflix)

Sergey trabalha na Netflix para garantir que o serviço funcione para os usuários finais o mais rápido possível. Todos os pedidos são divididos em dois grandes grupos:

• solicitações de nuvem (dinâmica);
• Consultas CDN (estáticas).

Em muitos casos, é necessário fazer solicitações simultaneamente para as partes dinâmica e estática da infraestrutura. Mas esse esquema tem sobrecarga: você precisa estabelecer pelo menos duas conexões, realizar o TLS Handshake duas vezes, etc.

Havia uma ideia de que, se você fizer uma solicitação apenas para uma infraestrutura estática, instale um proxy inteligente e confie a ela solicitações dinâmicas à nuvem em seu nome, isso acelerará as solicitações do cliente. A equipe da Netflix implementou esse esquema, realizou testes em usuários reais. No entanto, ficou claro que nem sempre funciona e nem para todos, alguns pedidos começam a ser processados ​​pior.

Portanto, a equipe decidiu seguir o outro caminho. Eles criaram um esquema que permite que cada cliente decida individualmente como é mais lucrativo executar solicitações dinâmicas: diretamente do cliente ou confie o proxy dessa solicitação à parte estática da infraestrutura.

Este é um bom exemplo de não ter que se afastar dos desafios técnicos. Você precisa ser corajoso e escolher uma opção de compromisso se isso melhorar o produto e a vida dos usuários for mais fácil.

Por que o setor de TI está passando por momentos sombrios, como o DevOps é o culpado e por que o Capital pode ajudar (Roman Shaposhnik, ZEDEDA Inc.)

O relatório mais "visionário" desta conferência. Nele, Roman falou muito sobre como as tecnologias (e o capital) estão interconectadas (e inseparáveis). Penso que esta tese é muito importante para os engenheiros e entende que as tecnologias são criadas para resolver problemas específicos de pessoas e negócios. Com esse pensamento, fica mais fácil priorizar tarefas e entender o que é importante e o que não é. Roman também falou sobre por que políticas e corporações fechadas, que estão aumentando cada vez mais sua influência, podem levar a uma crise global no setor de TI. Bem como um todo sobre a história e a filosofia do campo da tecnologia da informação.

DevOops é sobre desenvolvimento

Vários oradores perguntaram ao público quem está envolvido na operação e infraestrutura e quem está desenvolvendo. Os resultados me surpreenderam: a distribuição é de cerca de 50 a 50. É ótimo que mais e mais desenvolvedores desejem entender o que acontece com seu código após a escrita, como os aplicativos são implantados e se comunicam. Com esse entendimento, ao escrever um código, você pensa imediatamente sobre como ele funcionará nas condições de vida e onde poderá colocar canudos.