29-30 октября в Санкт-Петербурге состоится DevOops 2019 — конференция, посвященная инженерным DevOps-решениям. Основные темы — это облака вообще и Cloud Native в частности, observability, мониторинг и аудит, CI/CD, безопасность и так далее — в общем, всё, что вы можете ожидать от конференции, посвященной именно девопсу.

Этот хабрапост — обзор программы DevOops, который мы написали вместе с программным комитетом конференции.

Если вкратце:

• Антон Вайс расскажет про сервис-меши;
• Burr Sutter и Олег Ненашев — про CI/CD;
• Дмитрий Столяров и Сергей Фёдоров — про мониторинг;
• Про облака и Kubernetes есть огромная секция: Mete Atamel, Jessica Deen, Виктор Гамов, Иван Глушков…

Программа большая, в сумме 30 докладов.

Кейноуты ведут: Тим Листер (соавтор «Peopleware»), Hadi Hariri (руководитель Developer Advocacy в JetBrains) и Роман Шапошник (член совета директоров Apache Software Foundation и Linux Foundation LF Edge ^[1]).

Под катом мы поговорим о том, что вообще происходит в мире девопса, разобьём события по группам и посмотрим, как это всё ложится на программу из 30 докладов.

Case Study

Первая группа докладов — это «Case Study». За последнее время ситуация в мире стремительно развивается, например, продолжается война GitLab со всеми: у GitLab появилось всё, и они собираются продавать это как единый продукт (о чём сказал в скандальной статье ^[2] журналу The Register CEO Sid Sijbrandij).

При этом далеко не всё так радужно, и Никита Соболев как раз хочет рассказать, как они перелезли с GitLab на GitHub и почему. Вкратце, у GitHub тоже появилось всё, пусть и в preview, но те же Actions ^[3] работают, Package Registry ^[4] работает, Security ^[5] тоже работает ^[6] и так далее. С другой стороны, Actions всё так же продолжают выкачивать весь репозиторий, вне зависимости от того, pull request в какую ветку ты тестируешь. Да, в конце-концов ты перелезешь на Jenkins, потому что жизнь тяжела и полна ужасов, но по крайней мере docker image ты собрать уже можешь, и большинству для начала хватит. Это был один пример из категории «Case Study», а вообще докладов там несколько:

• Никита Соболев ^[7] — Автоматизируем все с Github Actions
• Григорий Кошелев ^[8] — Как готовить Кафку, чтобы не пригорало
• Алексей Кирпичников ^[9] — Проклятие инфраструктурной команды
• Барух Садогурский ^[10] — Паттерны и антипаттерны непрерывных обновлений в практике DevOps

NB: Барух Садогурский продолжает делать доклады на каждом новом DevOops. Попадёт ли он опять в топ? Делаем ставки.

Service Mesh

В докладах категории «Service Mesh» мы исследуем способы решения проблемы возрастающей сложности. Мы молодцы, мы придумали дробить монолиты на микросервисы, но вместо окончательного решения проблемы мы столкнулись с невероятной сложностью микросеврисного мира. Меши придумывались, чтобы сложности стало меньше, а в итоге… что получилось, то получилось. Что-то подсказывает, что и с мешами проще не стало, но это тема для отдельного большого разговора.

Сейчас можно встретить всё больше и больше статей и докладов на тему: а давайте перестанем микро-хардкодить и вернёмся к привычным монолитам. По сути, как только стало понятно, что микросервисы уменьшают сложность в архитектуре, но повышают нагрузку на админов, пришёл народ и сказал: «Ой, а может, это не всегда надо»? Этот тезис никуда не делся, надо не всегда. Например, если твоя система должна быть интегрирована с чем-то большим и внешним, с какой-то толстой базой данных, то количество решаемых микросервисами проблем меньше, чем проблем создаваемых — весь стейт будет проходить через эту базу, а микросервисы уже и не микро, ибо друг без друга жить не могут. В программе у нас даже есть такие любители монолитов — например, Alex Thissen с докладом «Flagging your features» ^[11] рассказывает о том, что можно взять одно монолитное приложение, покрыть его feature-флагами и потом катить всегда из мастера.

Но кто же будет бороться с сервис-мешами? Спросите наших докладчиков!

• Erik Veld ^[12] — Adapting your infrastructure to go multi-*
• Антон Вайс ^[13] — Зачем нам сервисное сито?
• Александр Лукьянченко ^[14] — Service mesh для построения мультикластерной системы

CI/CD

Старичок Jenkins можно запускать без Jenkins! Можно запускать в Travis, где угодно, как тебе такое, Илон Маск? (Это сейчас вполне серьёзно ^[15]). В целом, поскольку сейчас везде Kubernetes, все наши инструменты CI/CD подстраиваются под этот факт, Kubernetes надо поддерживать. Поэтому у нас появился JenkinsX, поэтому в TeamCity появляются новые фишки, поэтому GitHub-ы и GitLab-ы разворачивают свои CI — всем нужен Kubernetes.

Появление Kubernetes поменяло подходы к CD. Поскольку делать CD стало проще, начали появляться новые вариации того, как можно веселее раскатывать canary deployments, blue-green deployments, итп — куча готовых абстракций, которые можно использовать и радоваться жизни. Пример CI/CD, построенного на принципах Cloud Native — Tekton ^[16]. У нас про Tekton ничего ещё нет (разве что, он упоминается в докладах Олега Ненашева ^[17] и Burr Sutter ^[18]), но весной постараемся сделать. JenkinsX — абсолютно та же фишка, создан на основе Cloud Native проектов для Cloud Native. Если кому интересно, что такое этот самый Cloud Native, стоит прочитать про 12-факторные приложения ^[19], это оно и есть. Как там недавно шутил Келси:

Доклады категории CI/CD:

• Sebastian Daschner ^[21] — Delivering progressively with Jenkins X
• Антон Архипов ^[22] — CI больших проектов в JetBrains
• Burr Sutter ^[18] — Pipelines & Pods: DevOps with Kubernetes
• Владимир Иванов ^[23] — Мобильная разработка: DevOps или не DevOps
• Олег Ненашев ^[17] — Under the hood of serverless Jenkins: Jenkinsfile Runner
• Alex Thissen ^[24] — Flagging your features — a DevOps approach to continuous release — любитель монолитов

Monitoring

В мире мониторинга все куда менее бурно, но есть фундаментальные вопросы. Например, часто говорят, что никто так и не научился мониторить монолиты. Кажется, проблема не в том — ведь там нечему особо учиться. Проблема в том, что большинство монолитов — это легаси, и прикручивать мониторинг к существующим приложениям — это боль. Если тебе сейчас скажут: напиши монолит так, чтобы его удобно было мониторить, это раз плюнуть: ты берешь всё, что мы любим, начиная от логов и метрик и заканчивая трейсингом, всё красиво туда вписываешь и получаешь полный observability.

Проблема в том, что мы сегодня говорим о прикручивании мониторинга к существующим большим монолитам, и вот это довольно нетривиально. И когда всё получится, с получившимся франкенштейном придётся как-то жить. Поэтому у нас есть доклад Дмитрия Столярова про культуру on-call ^[25], он не очень технический, но помните, девопс — не только об инструментах! Philipp Krenn расскажет ^[26], что при масштабировании мы начинаем терять ивенты, и, в общем-то, это нормально, но тут к нам приходят аудиторы и говорят — мы хотим смотреть отдельные ивенты! Как поженить масштабирование и аудит — неясно, неприятная проблема.

В целом, мы ещё не научились к монолитам прикручивать мониторинг, а микросервисы ещё сверху работы навалили. Микросервисы и Cloud Native заставили нас совершенно по-другому взглянуть на observability, потому что мы понимаем, что старые методы вроде тупого логирования, по которому мы дальше делаем cat, перестают работать. Недавно где-то в твиттере проскакивала шутка: «Если ты вставляешь ID в пять разных тулов, и дальше ищешь в них по этому ID, значит ты сам — observability tool». В микросервисных архитектурах, двигающихся в сторону реактивной модели, observability строится на тех ивентах, которыми они перебрасываются внутри. А если это оркестрация, тогда ивентов нет, и приходится по-другому логи разбирать. Мир стал в несколько раз сложнее для наблюдения, и далеко не все научились его наблюдать.

Доклады секции Monitoring:

• Дмитрий Столяров ^[25] — 10 лет on-call. Чему мы научились?
• Philipp Krenn ^[26] — Scale Your Auditing Events
• Сергей Фёдоров ^[27] — Ускоряем Интернет-запросы, и спим спокойно

Cloud

Клауды — самая большая и объемная тема. Когда-то считалось, что публичные облака — «наше всё». Потом выяснилось, что не всё. Потом оказалось, что ещё и не наше! Появилось много любителей приватных облаков, возникли гибридные облака. Это началось не в этом году, а сильно раньше. Сейчас один из основных вопросов в том, как объединять это всё. Например, как сочетаются VMWare с AWS, ведь VMWare пришёл и в Azure ^[28], и в AWS тоже пришёл ^[29], и вот это уже в масштабах года довольно большие новости.

Конечно же, везде, в большинстве докладов (не только секции «Cloud») так или иначе упоминается Kubernetes. Он проник повсюду, и кто-то даже начинает ждать — когда появится убийца Kubernetes? Пока такового не видно. Ещё пару лет назад основным вопросом было — как жить с этой сложной непонятной штукой, но сейчас все уже привыкли к злому соседу и научились договариваться. Операторы? Knative? Kotlin DSL?

Этот смелый новый мир настолько большой и разнообразный, что не имеет смысла тут всё перечислять, просто взгляните на этот список докладов:

• Mete Atamel ^[30] — Serverless Containers with Knative and Cloud Run
• Сергей Курсон ^[31] — CDK and infrastructure as a code
• Jessica Deen ^[32] — From Zero to DevOps Superhero: The Container Edition
• Nikhil Barthwal ^[33] — Implementing Microservices Architecture as Cloud Run Application
• Николай Ихалайнен ^[34] — Как рулить пароходом MySQL
• Фёдор Чемашкин ^[35] — Заключительный рассказ про операторы
• Виктор Гамов, Фёдор Коротков ^[36] — Do it in code (not YAML)! Unlock power of Kotlin DSL for Kubernetes
• Иван Глушков ^[37] — Невыносимая легкость масштабирования подов в Kubernetes
• Дмитрий Губенко ^[38] — Terraform vs Helm: Битва за инфраструктуру

Кейноуты

Ещё у нас есть три кейноута. Они занимают самый большой имеющийся зал, с ними в параллели не идёт других докладов, и они рассчитаны на широкую аудиторию, ведут их самые известные спикеры.

Конференцию открывает Тимоти Листер — соавтор книг «Peopleware», «Вальсируя с Медведями», «Adrenaline junkies and template zombies». Все эти книги являются классикой в своей области и написаны вместе с коллегами по Atlantic Systems Guild ^[39]. В докладе «Characters, community, and culture: Important factors for prosperity» ^[40] Тим расскажет о best practices для организаций, о рабочей культуре, полезных и вредных аспектах работы в компании. В общем, о том, о чём он и так рассказывает в течение десятилетий, но обновлённое до реалий 2019 года. Если интересны подробности, совсем недавно мы сделали с ним большое интервью для Хабра ^[41]. Пишут ли они новую книгу — да, пишут, читайте интервью.

Первый день завершает Hadi Hariri, легендарный руководитель команды Developer Advocacy в JetBrains, open source-разработчик и спикер на протяжении уже 15 лет. В докладе «Removing the barriers» ^[42] он предлагает задуматься над вопросом: что если все обычные барьеры и проблемы исчезли, что дальше? Действительно ли это приведёт к росту продуктивности и гарантированному решению задач? Оказывается, не всё так просто, и отсутствие барьеров — сама по себе достойная тема для обсуждения.

Ну и наконец, конференцию завершает Роман Шапошник, член совета директоров Apache Software Foundation и Linux Foundation LF Edge ^[1], лично приложивший руку к ядру Linux, Hadoop, ffmpeg и другим популярным проектам. Его кейноут «Почему IT-индустрия переживает темные времена, как в этом виноват DevOps, и почему "Капитал" может помочь» ^[43] постарается ответить на несколько философских вопросов про восхождение мультимедиа-облачных платформ, платформ с открытым кодом (Kubernetes и Cloud Foundry), Edge Computing и так далее.

Что дальше?

Полная программа конференции опубликована на сайте ^[44], везде есть развёрнутые описания, везде имеются комментарии программного комитета, а тэги вроде #kubernetes позволяют ориентироваться в содержимом не переходя в карточку доклада.

Напоминаем, что DevOops 2019 состоится 29-30 октября в Санкт-Петербурге, билеты можно приобрести на официальном сайте конференции ^[45]. О всех значительных новостях можно узнать либо из нашего блога на Хабре, либо подписавшись на почтовую рассылку на главной странице ^[46].

Автор: Олег Чирухин

Источник ^[47]