Conferência DUMP | grep 'back-end \ | devops'

Na semana passada, fui à conferência DUMP IT (https://dump-ekb.ru/) em Ecaterimburgo e quero falar sobre o que foi discutido nas seções Back-end e Devops e se as conferências regionais de TI merecem atenção.


Nikolay Sverchkov de Evil Martians sobre Serverless

O que havia?

No total, a conferência teve 8 seções: back-end, front-end, dispositivos móveis, testes e controle de qualidade, Devops, design, ciência e gerenciamento.

Os maiores salões, aliás, são Ciência e Administração)) Com aproximadamente 350 pessoas cada. Backend e Frontend não são muito menos. Devops Hall era o menor, mas o mais ativo.

Ouvi os relatórios nas seções Devops e Backend e conversei um pouco com os palestrantes. Quero falar sobre os tópicos abordados e dar uma visão geral dessas seções na conferência.

Representantes do SKB-Kontur, DataArt, Evil Marcianos, estúdio de Flag of Yekaterinburg, Miro (RealTimeBoard) falaram nas seções Devops e Backend. Os tópicos relacionados ao CI / CD, trabalho com serviços de fila, registro em log, tópicos sem servidor e trabalho com o PostgreSQL no Go foram bem divulgados.

Também houve relatórios de Avito, Tinkoff, Yandex, Jetstyle, Megafon, Ak Bars Bank, mas não tive tempo de visitá-los fisicamente (gravações em vídeo e slides de relatórios ainda não estão disponíveis, eles prometem publicá-los no dump-ekb.ru dentro de duas semanas).

Seção Devops

O que surpreendeu - a seção foi realizada no menor salão, cerca de 50 lugares. As pessoas até ficaram nos corredores :) Vou falar sobre os relatórios que consegui ouvir.

Peso elástico em petabytes

A seção começou com um relatório de Vladimir Lil (SKB-Kontur) sobre a Elasticsearch em Kontur. Eles possuem um Elastic suficientemente grande e carregado (~ 800 TB de dados, ~ 1,3 petabytes, levando em consideração a redundância). O Elasticsearch para todos os serviços do circuito é único, consiste em 2 clusters (de 7 e 9 servidores) e é tão importante que existe um engenheiro especial do Elasticsearch no circuito (de fato, o próprio Vladimir).

Vladimir também compartilhou seus pensamentos sobre os benefícios do Elasticsearch e os problemas que ele traz.

Benefício:

• Todos os logs em um só lugar, acesso fácil a eles
• Armazenamento de log por um ano e sua fácil análise
• Alta velocidade com toras
• Visualização legal de dados "pronta para uso"

Os problemas:

• intermediário de mensagens - deve ter (Kafka desempenha o papel de Kontur)
• Recursos do trabalho com o Elasticsearch Curator (alta carga criada periodicamente a partir de tarefas regulares no Curator)
• sem autorização interna (apenas para dinheiro separado, razoavelmente grande, ou como plug-ins de código aberto com graus variados de prontidão para produção)

Sobre o Open Distro for Elasticsearch, as análises foram positivas :) O mesmo problema de autorização foi resolvido lá.

Recursos de desenvolvimento sem servidor

Relatório adicional de Ruslan Serkin da DataArt sobre Serverless.

Ruslan falou sobre o que é desenvolvimento com a abordagem sem servidor em geral e quais são seus recursos.

Sem servidor é uma abordagem de desenvolvimento em que os desenvolvedores não têm nada a ver com infraestrutura. Um exemplo é o AWS Lambda Serverless, o Kubeless.io (sem servidor no Kubernetes) e o Google Cloud Functions.

Um aplicativo sem servidor ideal é apenas um recurso que envia uma solicitação a um provedor sem servidor por meio de uma API de gateway dedicada. Um microsserviço ideal, enquanto no mesmo AWS Lambda é suportado um grande número de linguagens de programação modernas. O custo de suporte e implantação da infraestrutura se torna zero no caso de provedores de nuvem; o suporte a pequenos aplicativos também será muito barato (AWS Lambda - solicitações simples de US $ 0,2 / 1 milhão).

A escalabilidade de um sistema desse tipo é quase perfeita - o provedor de nuvem cuida disso sozinho, o Kubeless é escalado automaticamente dentro do cluster Kubernetes.

Existem desvantagens:

• o desenvolvimento de aplicativos grandes está ficando mais difícil
• há uma dificuldade com a criação de perfis de aplicativos (apenas logs estão disponíveis para você, mas não com a criação de perfil no sentido usual)
• sem versionamento

Sinceramente, ouvi falar do Serverless há alguns anos, mas durante todos esses anos não estava claro para mim como usá-lo corretamente. Após o relatório de Ruslan, o entendimento apareceu e, após o relatório de Nikolai Sverchkov (marcianos maus) da seção de back-end, ele consolidou. Não é de admirar que eu fui à conferência :)

CI para os pobres, ou vale a pena escrever seu próprio IC para o web studio

Mikhail Radionov, diretor do estúdio de web Flag, em Ecaterimburgo, falou sobre o CI / CD auto-escrito.

Seu estúdio passou de um “CI / CD manual” (conectado ao servidor via SSH, git pull, repetido 100 vezes por dia) para Jenkins e uma ferramenta auto-escrita que permite controlar o código e executar lançamentos chamados Pullkins.

Por que Jenkins não funcionou? Por padrão, não oferecia flexibilidade suficiente e era muito complicado para personalização.

A “flag” está sendo desenvolvida no Laravel (framework PHP). Ao desenvolver o servidor de CI / CD, Michael e seus colegas usaram os mecanismos internos do Laravel chamados Telescope and Envoy. O resultado é um servidor php (preste atenção) que processa solicitações de webhook recebidas, capazes de montar o frontend, backend, implantar em diferentes servidores e reportar ao Slack.

Além disso, para a capacidade de executar a implantação azul / verde, para ter configurações uniformes em ambientes de estágio de desenvolvimento, eles mudaram para o Docker. As vantagens permaneceram as mesmas, foram adicionadas as possibilidades de homogeneizar o ambiente e a implantação sem interrupções, além da necessidade de aprender o Docker a funcionar corretamente com ele.

O projeto está no Github

Como reduzimos o número de reversões de liberações de servidores em 99%

O relatório mais recente na seção Devops foi de Victor Eremchenko, engenheiro líder de devops do Miro.com (anteriormente RealTimeBoard).

O RealTimeBoard, o principal produto da equipe Miro, é baseado em um aplicativo Java monolítico. Coletar, testar e implantar sem tempo de inatividade é uma tarefa difícil. Ao mesmo tempo, é importante implantar essa versão do código para que ele não precise ser revertido (um monólito pesado).

No caminho para a construção de um sistema que permita isso, o Miro percorreu um longo caminho, incluindo o trabalho na arquitetura, as ferramentas usadas (Bamboo Atlassian, Ansible, etc) e o trabalho na criação de equipes (agora eles têm um comando Devops dedicado + muitos comandos Scrum separados de desenvolvedores de perfis diferentes).

O caminho acabou sendo difícil e espinhoso, e Victor compartilhou suas decisões, a dor acumulada e o otimismo que não terminaram por aí.


Ganhou um livro para perguntas

Seção de back-end

Eu tinha dois relatórios - de Nikolai Sverchkov (Evil Martians), também sobre Serverless, e de Grigory Koshelev (empresa Kontur) sobre telemetria.

Sem servidor para meros mortais

Se Ruslan Sirkin falou sobre o que é o Serverless, Nikolai mostrou aplicativos simples usando o Serverless e falou sobre os detalhes que afetam o custo e a velocidade dos aplicativos no AWS Lambda.

Um detalhe interessante: o item mínimo pago é 128 Mb de memória e 100 ms CPU, custa $ 0.000000208. Além disso, 1 milhão desses pedidos por mês é gratuito.

Algumas das funções de Nikolai frequentemente excederam o limite de 100 ms (o aplicativo principal foi escrito em Ruby); portanto, reescrevê-las no Go proporcionou excelentes economias.

Vostok Hercules - torne a telemetria ótima novamente!

O último relatório da seção Back-end de Grigory Koshelev (empresa Kontur) sobre telemetria. Telemetria são logs, métricas, rastreamentos de aplicativos.

O Contour usa suas próprias ferramentas escritas postadas no Github para isso. A ferramenta de relatório, Hercules, github.com/vostok/hercules , é usada para fornecer dados de telemetria.

Um relatório de Vladimir Lila na seção Devops analisou o armazenamento e o processamento de logs no Elasticsearch, mas ainda há a tarefa de fornecer logs de muitos milhares de dispositivos e aplicativos, e ferramentas como Vostok Hercules os resolvem.

O circuito seguiu o caminho conhecido por muitos - de RabbitMQ a Apache Kafka, mas não tão simples)) Eles tiveram que adicionar Zookeeper, Cassandra e Graphite ao esquema. Não divulgarei totalmente as informações deste relatório (não o meu perfil); se estiver interessado, aguarde os slides e o vídeo no site da conferência.

Em comparação com outras conferências?

Não posso compará-lo com conferências em Moscou e São Petersburgo, posso compará-lo com outros eventos nos Urais e com o 404fest em Samara.

DUMP é realizado em 8 seções, este é um recorde para as conferências Urais. Seções muito grandes de Ciência e Gestão, isso também é incomum. O público em Ecaterimburgo é bastante estruturado - a cidade possui grandes departamentos de desenvolvimento Yandex, Kontur, Tinkoff, isso deixa sua marca nos relatórios.

Outro ponto interessante é que muitas empresas têm imediatamente de 3 a 4 palestrantes na conferência (esse foi o caso de Kontur, Evil Martians, Tinkoff). Muitos deles eram patrocinadores, mas os relatórios estão em pé de igualdade com os outros; não se trata de relatórios publicitários.

Ir ou não ir? Se você mora nos Urais ou nas proximidades, tem a oportunidade e tópicos interessantes - sim, é claro. Se você está pensando em uma longa viagem, analisaria os tópicos dos relatórios e dos vídeos de anos anteriores www.youtube.com/user/videoitpeople/videos e tomaria uma decisão.
Outra vantagem das conferências nas regiões, como regra, é fácil se comunicar com o orador após os relatórios, pois há menos candidatos a essa comunicação.



Obrigado a Dump e Yekaterinburg! )