De 29 a 30 de outubro, São Petersburgo sediará o DevOops 2019 - uma conferência dedicada às soluções de engenharia do DevOps. Os principais tópicos são nuvens em geral e Cloud Native em particular, observabilidade, monitoramento e auditoria, CI / CD, segurança e assim por diante - em geral, tudo o que você pode esperar de uma conferência dedicada especificamente aos devops.
Este ponto central é uma revisão do programa DevOops, que escrevemos em conjunto com o comitê do programa da conferência.
Em resumo:
- Anton Weiss falará sobre malhas de serviço;
- Burr Sutter e Oleg Nenashev - sobre CI / CD;
- Dmitry Stolyarov e Sergey Fedorov - sobre monitoramento;
- Há uma seção enorme sobre nuvens e Kubernetes: Mete Atamel, Jessica Deen, Victor Gamov, Ivan Glushkov ...
O programa é grande, com um total de 30 relatórios.
As palestras são lideradas por Tim Lister (co-autor da Peopleware), Hadi Hariri (chefe de Advocacy para Desenvolvedores da JetBrains) e Roman Shaposhnik (membro do conselho de administração da Apache Software Foundation e Linux Foundation LF Edge ).
Abaixo, vamos falar sobre o que está acontecendo no mundo dos devops, dividiremos os eventos em grupos e veremos como tudo se encaixa em um programa de 30 relatórios.
Estudo de caso
O primeiro grupo de relatórios é o Estudo de Caso. Recentemente, a situação no mundo está se desenvolvendo rapidamente, por exemplo, a guerra do GitLab continua com todos: o GitLab tem tudo, e eles o venderão como um único produto (conforme declarado em um artigo escandaloso do CEO do The Register, Sid Sijbrandij).
No entanto, nem tudo é tão otimista, e Nikita Sobolev só quer dizer como eles se mudaram do GitLab para o GitHub e por quê. Em resumo, o GitHub também tinha tudo, embora em pré-visualização, mas as mesmas ações funcionam, o Registro de Pacotes funciona, a Segurança também funciona e assim por diante. Por outro lado, as Ações ainda continuam distribuindo todo o repositório, independentemente de qual solicitação pull você está testando em qual ramificação. Sim, no final, você escalará Jenkins, porque a vida é dura e cheia de horrores, mas pelo menos você já pode montar a imagem do docker, e a maioria deles será suficiente para começar. Este foi um exemplo da categoria Estudo de Caso, mas houve vários relatórios em geral:
Nota: Baruch Sadogursky continua a fazer apresentações em cada novo DevOops. Ele vai chegar ao topo de novo? Nós fazemos apostas.
Malha de serviço
Nos relatórios da categoria Malha de Serviço, exploramos maneiras de resolver o problema de aumentar a complexidade. Somos ótimos, pensamos em dividir monólitos em microsserviços, mas, em vez de finalmente resolver o problema, fomos confrontados com a incrível complexidade do mundo dos microsserviços. As malhas foram inventadas para diminuir a complexidade, mas no final ... o que aconteceu, o que aconteceu. Algo me diz que não ficou mais fácil com malhas, mas esse é um tópico para uma grande conversa separada.
Agora você pode encontrar mais e mais artigos e relatórios sobre o tópico: mas vamos parar a codificação micro-rígida e retornar aos monólitos comuns. De fato, assim que ficou claro que os microsserviços reduzem a complexidade da arquitetura, mas aumentam a carga dos administradores, as pessoas vieram e disseram: “Ah, talvez isso nem sempre seja necessário”? Esta tese não desapareceu, nem sempre é necessária. Por exemplo, se seu sistema precisar ser integrado a algo grande e externo, com algum tipo de banco de dados espesso, o número de problemas resolvidos por microsserviços será menor que os problemas criados - todo o estado passará por esse banco de dados e os microsserviços não serão mais micro, pois eles não podem viver sem o outro. Temos até amantes de monólitos no programa - por exemplo, Alex Thissen, com o relatório "Sinalizando seus recursos", fala sobre o fato de que você pode pegar um aplicativo monolítico, cobri-lo com sinalizadores de recursos e sempre sair do assistente.
Mas quem lutará com malhas de serviço? Pergunte aos nossos palestrantes!
- Erik Veld - Adaptando sua infraestrutura para se tornar multi- *
- Anton Weiss - Por que precisamos de uma peneira de serviço?
- Alexander Lukyanchenko - Malha de serviço para a construção de um sistema multi-cluster
CI / CD
O velho Jenkins pode ser executado sem Jenkins! Você pode correr em Travis, em qualquer lugar, como você gosta disso, Elon Musk? (Isso é muito sério agora). Em geral, como o Kubernetes agora está em todo lugar, todas as nossas ferramentas de CI / CD se adaptam a esse fato, o Kubernetes precisa de suporte. É por isso que adquirimos o JenkinsX, para que novos chips apareçam no TeamCity, é por isso que o GitHubs e o GitLabs implantam seus ICs - todos precisam do Kubernetes.
O surgimento do Kubernetes mudou a abordagem do CD. Como facilitar o uso de CDs, começaram a surgir novas variações sobre como é divertido implementar implantações de canários, implantações verde-azuladas etc. - um monte de abstrações prontas que você pode usar e aproveitar a vida. Um exemplo de um IC / CD construído com base nos princípios do Cloud Native é o Tekton . Ainda não temos nada sobre Tekton (exceto que é mencionado nos relatórios de Oleg Nenashev e Burr Sutter ), mas na primavera tentaremos fazê-lo. JenkinsX é exatamente o mesmo chip, criado com base em projetos Cloud Native para Cloud Native. Se alguém estiver interessado no que é esse Cloud Native, vale a pena ler sobre aplicativos de 12 fatores , é isso. Como Kelsey brincou recentemente:
Relatórios de categoria CI / CD:
Monitoramento
No mundo do monitoramento, tudo é muito menos tempestuoso, mas há questões fundamentais. Por exemplo, costuma-se dizer que ninguém aprendeu a monitorar monólitos. Parece que o problema não é esse - afinal, não há muito o que aprender. O problema é que a maioria dos monólitos é legada, e atrapalhar o monitoramento de aplicativos existentes é uma dor. Se eles lhe disserem agora: escreva um monólito de forma que seja conveniente monitorá-lo, é hora de cuspir: você pega tudo o que amamos, começando de logs e métricas e terminando com rastreamento, você escreve tudo lindamente e obtém total observabilidade.
O problema é que hoje estamos falando de parafusar o monitoramento em grandes monólitos existentes, e isso não é trivial. E quando tudo der certo, você terá que viver de alguma forma com o Frankenstein resultante. Portanto, temos um relatório de Dmitry Stolyarov sobre a cultura de plantão , não é muito técnico, mas lembre-se, os devops não são apenas ferramentas! Philipp Krenn lhe dirá que, quando escalamos, começamos a perder eventos e, em geral, isso é normal, mas aqui os auditores vêm até nós e dizem - queremos assistir a eventos individuais! Como se casar com escala e auditoria não é claro, um problema desagradável.
Em geral, ainda não aprendemos a fixar o monitoramento em monólitos, e os microsserviços empilharam o trabalho. Os microsserviços e o Cloud Native nos fizeram dar uma olhada completamente diferente na observabilidade, porque entendemos que métodos antigos, como o registro burro, no qual continuamos praticando gato, param de funcionar. Recentemente, uma piada apareceu em algum lugar no Twitter: "Se você colar o ID em cinco ferramentas diferentes e depois procurá-los usando esse ID, você será uma ferramenta de observabilidade". Nas arquiteturas de microsserviço que estão se movendo em direção a um modelo reativo, a observabilidade é construída nos eventos com os quais são transferidos internamente. E se for uma orquestração, não haverá eventos e você precisará desmontar os logs de uma maneira diferente. O mundo tornou-se várias vezes mais difícil de observar, e nem todos aprenderam a observá-lo.
Relatórios da seção de monitoramento:
Cloud
Nuvem é o tópico maior e mais volumoso. Acreditava-se que as nuvens públicas são "nosso tudo". Então acabou que nem tudo. Depois, descobriu-se que também não era nosso! Muitos amantes das nuvens privadas apareceram, surgiram nuvens híbridas. Não começou este ano, mas muito antes. Agora, uma das principais perguntas é como combinar tudo isso. Por exemplo, como o VMWare se combina com a AWS, porque o VMWare chegou ao Azure e também à AWS , e isso já é uma grande novidade ao longo do ano.
É claro que em todos os lugares, na maioria dos relatórios (não apenas na seção Nuvem), o Kubernetes é mencionado de uma maneira ou de outra. Ele se infiltrou em todos os lugares e alguém até começou a esperar - quando o assassino dos Kubernetes aparecerá? Até agora, isso não é visível. Há alguns anos, a principal questão era - como viver com essa coisa incompreensível complexa, mas agora todos já estão acostumados com um vizinho mau e aprenderam a negociar. Operadores? Knative? DSL Kotlin?
Esse mundo novo e ousado é tão grande e diversificado que não faz sentido listar tudo aqui, basta dar uma olhada nesta lista de relatórios:
Keynotes
Também temos três palestras. Eles ocupam a maior sala disponível, não há outros relatórios paralelos e são projetados para uma ampla audiência, são liderados por seus oradores mais famosos.
A conferência começa com Timothy Lister, co-autor de Peopleware, Waltzing with the Bears, viciados em adrenalina e zumbis-modelo. Todos esses livros são clássicos em seu campo e são escritos com colegas da Atlantic Systems Guild . No relatório “Personagens, comunidade e cultura: fatores importantes para a prosperidade”, Tim falará sobre as melhores práticas para as organizações, cultura de trabalho, aspectos úteis e prejudiciais ao trabalhar em uma empresa. Em geral, sobre o que ele fala há décadas, mas atualizado para as realidades de 2019. Se os detalhes são interessantes, recentemente fizemos uma ótima entrevista com ele para Habr . Eles escrevem um novo livro - sim, eles lêem a entrevista.
O primeiro dia termina com Hadi Hariri, o lendário líder da equipe de Advocacy para desenvolvedores da JetBrains, desenvolvedor de código aberto e palestrante há mais de 15 anos. Em seu relatório Removendo as Barreiras, ele sugere refletir sobre a questão: e se todas as barreiras e problemas comuns desaparecerem, o que vem a seguir? Isso realmente leva ao aumento da produtividade e à solução garantida dos problemas? Acontece que nem tudo é tão simples, e a falta de barreiras é, por si só, um tópico digno de discussão.
E finalmente, a conferência termina com Roman Shaposhnik, membro do conselho de administração da Apache Software Foundation e Linux Foundation LF Edge , que pessoalmente participou do kernel Linux, Hadoop, ffmpeg e outros projetos populares. Sua palestra “Por que o setor de TI está passando por momentos sombrios, como é a culpa do DevOps e por que a Capital pode ajudar” tentará responder a várias perguntas filosóficas sobre o surgimento de plataformas em nuvem multimídia, plataformas de código aberto (Kubernetes e Cloud Foundry), Edge Computação e assim por diante.
O que vem a seguir?
O programa completo da conferência é publicado no site , há descrições detalhadas em todos os lugares, comentários do comitê do programa em todos os lugares e tags como #kubernetes permitem navegar pelo conteúdo sem acessar o boletim.
Lembramos que o DevOops 2019 será realizado de 29 a 30 de outubro em São Petersburgo. Os ingressos podem ser adquiridos no site oficial da conferência . Você pode aprender sobre todas as notícias importantes no nosso blog em Habré ou assinando a lista de discussão na página principal .