29-30 октября в Санкт-Петербурге состоится DevOops 2019 — конференция, посвященная инженерным DevOps-решениям. Основные темы — это облака вообще и Cloud Native в частности, observability, мониторинг и аудит, CI/CD, безопасность и так далее — в общем, всё, что вы можете ожидать от конференции, посвященной именно девопсу. Этот хабрапост — обзор программы DevOops, который мы написали вместе с программным комитетом конференции. Если вкратце: Программа большая, в сумме 30 докладов. Кейноуты ведут: Тим Листер (соавтор «Peopleware»), Hadi Hariri (руководитель Developer Advocacy в JetBrains) и Роман Шапошник (член совета директоров Apache Software Foundation и Linux Foundation LF Edge). Под катом мы поговорим о том, что вообще происходит в мире девопса, разобьём события по группам и посмотрим, как это всё ложится на программу из 30 докладов. Первая группа докладов — это «Case Study». За последнее время ситуация в мире стремительно развивается, например, продолжается война GitLab со всеми: у GitLab появилось всё, и они собираются продавать это как единый продукт (о чём сказал в скандальной статье журналу The Register CEO Sid Sijbrandij). При этом далеко не всё так радужно, и Никита Соболев как раз хочет рассказать, как они перелезли с GitLab на GitHub и почему. Вкратце, у GitHub тоже появилось всё, пусть и в preview, но те же Actions работают, Package Registry работает, Security тоже работает и так далее. С другой стороны, Actions всё так же продолжают выкачивать весь репозиторий, вне зависимости от того, pull request в какую ветку ты тестируешь. Да, в конце-концов ты перелезешь на Jenkins, потому что жизнь тяжела и полна ужасов, но по крайней мере docker image ты собрать уже можешь, и большинству для начала хватит. Это был один пример из категории «Case Study», а вообще докладов там несколько: NB: Барух Садогурский продолжает делать доклады на каждом новом DevOops. Попадёт ли он опять в топ? Делаем ставки. В докладах категории «Service Mesh» мы исследуем способы решения проблемы возрастающей сложности. Мы молодцы, мы придумали дробить монолиты на микросервисы, но вместо окончательного решения проблемы мы столкнулись с невероятной сложностью микросеврисного мира. Меши придумывались, чтобы сложности стало меньше, а в итоге… что получилось, то получилось. Что-то подсказывает, что и с мешами проще не стало, но это тема для отдельного большого разговора. Сейчас можно встретить всё больше и больше статей и докладов на тему: а давайте перестанем микро-хардкодить и вернёмся к привычным монолитам. По сути, как только стало понятно, что микросервисы уменьшают сложность в архитектуре, но повышают нагрузку на админов, пришёл народ и сказал: «Ой, а может, это не всегда надо»? Этот тезис никуда не делся, надо не всегда. Например, если твоя система должна быть интегрирована с чем-то большим и внешним, с какой-то толстой базой данных, то количество решаемых микросервисами проблем меньше, чем проблем создаваемых — весь стейт будет проходить через эту базу, а микросервисы уже и не микро, ибо друг без друга жить не могут. В программе у нас даже есть такие любители монолитов — например, Alex Thissen с докладом «Flagging your features» рассказывает о том, что можно взять одно монолитное приложение, покрыть его feature-флагами и потом катить всегда из мастера. Но кто же будет бороться с сервис-мешами? Спросите наших докладчиков! Старичок Jenkins можно запускать без Jenkins! Можно запускать в Travis, где угодно, как тебе такое, Илон Маск? (Это сейчас вполне серьёзно). В целом, поскольку сейчас везде Kubernetes, все наши инструменты CI/CD подстраиваются под этот факт, Kubernetes надо поддерживать. Поэтому у нас появился JenkinsX, поэтому в TeamCity появляются новые фишки, поэтому GitHub-ы и GitLab-ы разворачивают свои CI — всем нужен Kubernetes. Появление Kubernetes поменяло подходы к CD. Поскольку делать CD стало проще, начали появляться новые вариации того, как можно веселее раскатывать canary deployments, blue-green deployments, итп — куча готовых абстракций, которые можно использовать и радоваться жизни. Пример CI/CD, построенного на принципах Cloud Native — Tekton. У нас про Tekton ничего ещё нет (разве что, он упоминается в докладах Олега Ненашева и Burr Sutter), но весной постараемся сделать. JenkinsX — абсолютно та же фишка, создан на основе Cloud Native проектов для Cloud Native. Если кому интересно, что такое этот самый Cloud Native, стоит прочитать про 12-факторные приложения, это оно и есть. Как там недавно шутил Келси: Serverless, because cloud native EJBs doesn't sound cool. Доклады категории CI/CD: В мире мониторинга все куда менее бурно, но есть фундаментальные вопросы. Например, часто говорят, что никто так и не научился мониторить монолиты. Кажется, проблема не в том — ведь там нечему особо учиться. Проблема в том, что большинство монолитов — это легаси, и прикручивать мониторинг к существующим приложениям — это боль. Если тебе сейчас скажут: напиши монолит так, чтобы его удобно было мониторить, это раз плюнуть: ты берешь всё, что мы любим, начиная от логов и метрик и заканчивая трейсингом, всё красиво туда вписываешь и получаешь полный observability. Проблема в том, что мы сегодня говорим о прикручивании мониторинга к существующим большим монолитам, и вот это довольно нетривиально. И когда всё получится, с получившимся франкенштейном придётся как-то жить. Поэтому у нас есть доклад Дмитрия Столярова про культуру on-call, он не очень технический, но помните, девопс — не только об инструментах! Philipp Krenn расскажет, что при масштабировании мы начинаем терять ивенты, и, в общем-то, это нормально, но тут к нам приходят аудиторы и говорят — мы хотим смотреть отдельные ивенты! Как поженить масштабирование и аудит — неясно, неприятная проблема. В целом, мы ещё не научились к монолитам прикручивать мониторинг, а микросервисы ещё сверху работы навалили. Микросервисы и Cloud Native заставили нас совершенно по-другому взглянуть на observability, потому что мы понимаем, что старые методы вроде тупого логирования, по которому мы дальше делаем cat, перестают работать. Недавно где-то в твиттере проскакивала шутка: «Если ты вставляешь ID в пять разных тулов, и дальше ищешь в них по этому ID, значит ты сам — observability tool». В микросервисных архитектурах, двигающихся в сторону реактивной модели, observability строится на тех ивентах, которыми они перебрасываются внутри. А если это оркестрация, тогда ивентов нет, и приходится по-другому логи разбирать. Мир стал в несколько раз сложнее для наблюдения, и далеко не все научились его наблюдать. Доклады секции Monitoring: Клауды — самая большая и объемная тема. Когда-то считалось, что публичные облака — «наше всё». Потом выяснилось, что не всё. Потом оказалось, что ещё и не наше! Появилось много любителей приватных облаков, возникли гибридные облака. Это началось не в этом году, а сильно раньше. Сейчас один из основных вопросов в том, как объединять это всё. Например, как сочетаются VMWare с AWS, ведь VMWare пришёл и в Azure, и в AWS тоже пришёл, и вот это уже в масштабах года довольно большие новости. Конечно же, везде, в большинстве докладов (не только секции «Cloud») так или иначе упоминается Kubernetes. Он проник повсюду, и кто-то даже начинает ждать — когда появится убийца Kubernetes? Пока такового не видно. Ещё пару лет назад основным вопросом было — как жить с этой сложной непонятной штукой, но сейчас все уже привыкли к злому соседу и научились договариваться. Операторы? Knative? Kotlin DSL? Этот смелый новый мир настолько большой и разнообразный, что не имеет смысла тут всё перечислять, просто взгляните на этот список докладов: Ещё у нас есть три кейноута. Они занимают самый большой имеющийся зал, с ними в параллели не идёт других докладов, и они рассчитаны на широкую аудиторию, ведут их самые известные спикеры. Конференцию открывает Тимоти Листер — соавтор книг «Peopleware», «Вальсируя с Медведями», «Adrenaline junkies and template zombies». Все эти книги являются классикой в своей области и написаны вместе с коллегами по Atlantic Systems Guild. В докладе «Characters, community, and culture: Important factors for prosperity» Тим расскажет о best practices для организаций, о рабочей культуре, полезных и вредных аспектах работы в компании. В общем, о том, о чём он и так рассказывает в течение десятилетий, но обновлённое до реалий 2019 года. Если интересны подробности, совсем недавно мы сделали с ним большое интервью для Хабра. Пишут ли они новую книгу — да, пишут, читайте интервью. Первый день завершает Hadi Hariri, легендарный руководитель команды Developer Advocacy в JetBrains, open source-разработчик и спикер на протяжении уже 15 лет. В докладе «Removing the barriers» он предлагает задуматься над вопросом: что если все обычные барьеры и проблемы исчезли, что дальше? Действительно ли это приведёт к росту продуктивности и гарантированному решению задач? Оказывается, не всё так просто, и отсутствие барьеров — сама по себе достойная тема для обсуждения. Ну и наконец, конференцию завершает Роман Шапошник, член совета директоров Apache Software Foundation и Linux Foundation LF Edge, лично приложивший руку к ядру Linux, Hadoop, ffmpeg и другим популярным проектам. Его кейноут «Почему IT-индустрия переживает темные времена, как в этом виноват DevOps, и почему "Капитал" может помочь» постарается ответить на несколько философских вопросов про восхождение мультимедиа-облачных платформ, платформ с открытым кодом (Kubernetes и Cloud Foundry), Edge Computing и так далее. Полная программа конференции опубликована на сайте, везде есть развёрнутые описания, везде имеются комментарии программного комитета, а тэги вроде #kubernetes позволяют ориентироваться в содержимом не переходя в карточку доклада. Напоминаем, что DevOops 2019 состоится 29-30 октября в Санкт-Петербурге, билеты можно приобрести на официальном сайте конференции. О всех значительных новостях можно узнать либо из нашего блога на Хабре, либо подписавшись на почтовую рассылку на главной странице. Деврел Axiom JDK, продюсер в Failover Bar