company_banner

DevOops 2019 глазами разработчика

    image

    29-30 октября в Санкт-Петербурге прошла конференция DevOops. В этой статье я поделюсь впечатлениями и инсайтами, а также краткими заметками о прослушанных докладах. Небольшой disclaimer: поскольку я разработчик, то некоторые мысли и комментарии могут быть с уклоном в Dev, нежели в Ops, но я постараюсь быть как можно объективнее.

    DevOops входит в число мероприятий, которые проводит JUG Ru Group. И нужно признать, организация и уровень докладов были на уровне. Конференция длилась два дня, в три потока. Помимо этого, были дискуссионные зоны для общения со спикерами, мастер-классы, а также lightning talks — более лёгкие и короткие доклады, в том числе для тех, кто ранее не выступал и хочет попробовать себя в качестве спикера.

    Тематическая канва DevOops 2019 — cloud native. Бо́льшая часть докладов была прямо или косвенно посвящена облакам. Тема давно уже не новая, однако есть множество неочевидных сложностей, которые возникают в процессе использования облачных технологий. И многие пришли специально, чтобы найти ответы. Это было особенно заметно на QA-сессиях после докладов. Спикерам задавали практические вопросы, которые действительно волнуют людей. Почти на каждый вопрос следовали реплики других участников «У нас такая же проблема!» и начиналась оживлённая дискуссия.

    День первый

    Characters, community, and culture: Important factors for prosperity (Timothy Lister, The Atlantic Systems Guild Inc.)


    image

    Конференцию открыл Тимоти Листер, который ещё в 1987 (!) году написал книгу про DevOps-практики. Тим много говорил о том, что отличает сильную, успешную команду со здоровой и приятной атмосферой внутри от посредственной и токсичной команды. Особенно запомнилась мысль:
    «Хорошая компания полна людей, которые говорят “я не знаю”».

    Это про открытость и доверие внутри команды. Атмосфера открытости просто необходима, если у вас есть амбициозная цель. Для этого нужно, чтобы каждый в команде чувствовал себя комфортно и свободно. Это не означает, что в случае появления проблемы участник команды сразу же эскалирует её на всех. Важна атмосфера открытости и возможность в любой момент обратиться к кому-то конкретному (вне зависимости от должности) или ко всей команде и озвучить явно, что требуется улучшить или поменять. Подобная культура формирует спокойный фон для работы, когда каждый знает, что в случае появления вопросов его выслушают.

    По моему опыту, для продуктивной и стабильной работы этот фактор имеет большое значение. Ведь вопросы, трения и смена направлений будут всегда. А атмосфера открытости — это универсальный инструмент, который позволяет справляться с личными и командными вызовами.

    Ещё одна мысль, которая мне мне кажется правильной: не существует единственной верной формулы для построения культуры в компании.
    «Ни одну культуру нельзя назвать идеальной. И ни одну культуру нельзя назвать полным провалом».

    Тенденция последнего времени: всё больше конференций включают в программу доклады про управление, коммуникацию, построение команды и культуры. DevOops не стал исключением. Я считаю что это позитивный тренд, ведь эти факторы оказывают на конечный результат даже большее влияние, чем технологические сложности.
    «Руководитель не управляет командой, а растит её».

    Do it in code (not YAML)! Unlock power of Kotlin DSL for Kubernetes (Виктор Гамов, Confluent, и Фёдор Коротков, Cirrus Labs)


    image

    Полустёбный доклад, но он в полной степени выражает боль от написания бесконечных YAML-файлов, их поддержки и (о ужас!) дебага в случае ошибки или опечатки. Это даже привело к появлению отдельных позиций YAML Engineer.

    Как всё начиналось? Когда-то были скрипты. Потом их стало больше. И ещё больше. Появилась необходимость унифицировать, упрощать и масштабировать решения. Так в DevOps-мире появился формат YAML и стал стандартом во многих инструментах.

    Авторы доклада подумали и сказали: «что-то в консерватории не так».
    • Непонятно, как тестировать YAML-файлы.
    • Легко допустить ошибку. Причём некоторые ошибки почти невозможно отловить и очень больно исправлять. Например, можно легко указать версию зависимости как число, вместо строки. И потом долго выяснять, почему используется не та версия, которая указана в конфиге. А всё дело в приведении типов и округлении.
    • Если ошибка синтаксическая, то она будет выявлена достаточно быстро, на CI. Но это не точно.

    Фишкой доклада стала заливка в Kubernetes невалидного конфига, на что он невозмутимо ответил: Too many errors.

    Виктор и Фёдор предлагают писать конфигурации на Kotlin DSL, что помогает справиться со всеми этими проблемами. Да, решение интересное и удобное, однако не является универсальным и работает только для k8s. Помимо этого, в случае обновления API нужно также обновить библиотеку.

    Pipelines & pods: DevOps with Kubernetes (Burr Sutter, Red Hat)


    image

    Лёгкий доклад про общую концепцию и основные компоненты Kubernetes, а также другие модные Ops-инструменты и Ops-практики. Для новичка в теме — то что надо. Он отлично вписался бы в программу конференции для разработчиков, но было странно прослушать доклад такого уровня на специализированной конференции по DevOps. Тем не менее, обзор получился хороший, простой и понятный.

    А вот формировать из Java-кода JSON, используя StringBuilder, — как-то слишком. Даже учитывая то, что это demo-проект.

    Паттерны и антипаттерны непрерывных обновлений в практике DevOps (Барух Садогурский, JFrog)


    image

    В докладе Баруха сложно выделить какую-то одну идею или направленность. Скорее это сборник личного опыта, историй из жизни, примеров «как делать хорошо, а как плохо», баек, прочих хиханек да «факапчиков».

    Особенно из этого доклада запомнилась история, когда из-за ошибки в процессе деплоя Knight Capital Group потеряла $440 000 000 за 45 минут и обанкротилась.

    Под конец Барух рассказал историю про баг в ПО Airbus A350. Из-за этого бага авиакомпании были вынуждены перезагружать самолёт каждые 149 часов, а для этого его нужно было посадить на землю. А если кто-то забудет это сделать — самолёт зависнет. Такой вот неприятный баг. Проблема простая — в коде происходит overflow. Фикс тоже простой. Но предположим, что перезагрузить самолёт всё-таки забыли, он вылетел рейсом Лос-Анджелес → Лондон и за 3 часа до приземления пилоты осознали, что через час самолёт зависнет. «Хьюстон, у нас проблема». «Сейчас пофиксим!» — ответили диспетчеры, собрали программистов AirBus, пофиксили, всё работает. А что делать дальше? Деплоить новую версию на самолёт по воздуху? Или не рисковать? Барух был настроен решительно: «Деплоить. Хуже уже не будет».

    День второй

    CDK and infrastructure as a code (Сергей Курсон, AWS)


    image

    Сергей рассказывал о AWS CDK (Cloud Development Kit). Это набор библиотек, который позволяет управлять инфраструктурой кодом. Решение спорное, поскольку управление инфраструктурой в императивном стиле — это некий откат назад. Все современные средства автоматизации позволяют описывать инфраструктуру в декларативном стиле (т.е. состояние, которое должно получиться в результате). Тем не менее, у такого подхода есть и преимущества. Например, сильно упрощается процесс тестирования развёрнутой инфраструктуры, а процесс деплоя и принятия решения о том, что и как деплоить, становится намного более гибким. Помимо этого, открываются большие возможности для динамического и крайне гибкого управления инфраструктурой по событиям, признакам или метрикам.

    Зачем нам сервисное сито? (Антон Вайс, Otomato Software)


    image

    Пожалуй, один из самых лучших и глубоких докладов этой конференции. Под «сервисным ситом» спикер подразумевает Service mesh — отдельный слой облачной инфраструктуры, управляющий общением сервисов между собой. Паттерн Service mesh делегирует множество задач с уровня сервиса (т.е. с прикладного разработчика) на собственно уровень сервисного сита (на DevOps):
    • управление безопасностью;
    • мониторинг трафика;
    • управление трафиком.

    Хотя Service mesh как технологии уже несколько лет, автор сделал про неё глубокий доклад и проанализировал историю возникновения, как она эволюционировала и как будет развиваться в ближайшие годы.

    Доклад особенно полезен разработчикам, поскольку задачи, которые решает Service mesh, сейчас зачастую решаются на уровне сервисов. А это отнимает у разработчиков дополнительное время и мешает сконцентрироваться на решении бизнес-задач.

    Ускоряем интернет-запросы и спим спокойно (Сергей Фёдоров, Netflix)


    image

    Сергей работает в Netflix над тем, чтобы для конечных пользователей сервис работал максимально быстро. Все запросы в нём делятся на две большие группы:
    • запросы к облаку (динамика);
    • запросы к CDN (статика).

    Во многих случаях необходимо сделать одновременно запросы и к динамической, и к статической части инфраструктуры. Но в такой схеме есть накладные расходы: нужно установить минимум два соединения, два раза провести TLS Handshake и т.д.

    Появилась идея, что если делать запрос только к статической инфраструктуре, установить на неё умный proxy и доверить ей от своего имени делать динамические запросы в облако, то это ускорит клиентские запросы. Команда Netflix реализовала такую схему, провела тестирование на реальных пользователях. Однако стало понятно, что она работает не всегда и не для всех, некоторые запросы начинают обрабатываться хуже.

    Поэтому команда решила пойти другим путём. Они придумали схему, которая позволяет для каждого клиента индивидуально принимать решение, как выгоднее выполнять динамические запросы: напрямую с клиента или доверить проксирование этого запроса статической части инфраструктуры.

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

    Почему IT-индустрия переживает темные времена, как в этом виноват DevOps, и почему «Капитал» может помочь (Роман Шапошник, ZEDEDA Inc.)


    image

    Самый «визионерский» доклад этой конференции. В нём Роман много говорил о том, как связаны (и неразделимы) между собой технологии и капитал. Думаю, этот тезис очень важен для инженеров и понимания, что технологии создаются, чтобы решать конкретные проблемы людей и бизнеса. С таким мышлением становится проще приоритизировать задачи и понимать, что важно, а что нет. Также Роман рассказывал, почему политика закрытости и корпорации, всё больше увеличивающие своё влияние, могут привести к глобальному кризису в IT-индустрии. А также в целом об истории и философии сферы информационных технологий.

    DevOops — это про развитие


    Несколько спикеров спрашивали у зала, кто занимается эксплуатацией и инфраструктурой, а кто разработкой. Результаты меня удивили: распределение примерно 50 на 50. Очень здорово, что всё больше разработчиков хотят понимать, что происходит с их кодом после написания, как приложения разворачиваются и общаются друг с другом. С таким пониманием при написании кода сразу думаешь о том, как он будет работать в живых условиях и где можно подстелить соломки.
    • +30
    • 4,4k
    • 5
    FunCorp
    318,76
    Разработка развлекательных сервисов
    Поделиться публикацией

    Комментарии 5

      0
      Очень информативная статья, хорошо то, что в наши дни DevOps пользуется огромным спросом, вот недавняя вакансия в GoodCore Software Ltd, им нужен инженер DevOps для создания и / или перепроектирования масштабируемых программных решений, и ответственность за разработку и разработку DevOps Engineer возлагается на инженера DevOps. создать облачную инфраструктуру и автоматизацию развертывания с командами разработчиков программного обеспечения. Поэтому я считаю, что масштабы этой карьеры суждено и дальше увеличиваться.
        +2

        Это машинно-переведённый спам такой?)

          +1
          Бизнесу нужны DevOps, а то наберут этих админов и программистов, а они в ответ это не моя задача не в моей ответственности. (сарказм)
          Я вот работаю веб-программистов(на каком говне только не пишу), но также администрирую веб-сервера и реализую полную CI интеграцию для проектов. Что я теперь DevOps? Нет я так не считаю, считаю, что я просто могу провести веб проект от начала до конца.
          0
          А видео нет???
            +1
            Есть на youtube трансляция первого дня. Всё остальное при покупке билета для online-просмотра. К следующей конфе может появиться остальное видео

          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

          Самое читаемое