Хабрахабр

«Kubernetes во все поля!» – интервью с программным комитетом конференции DevOops

Раньше докер был крутым, молодежным, вещью в себе. А потом как-то докер перестал быть интересен: он просто есть, он у всех и во всем. На нем все микросервисы, Kubernetes, девопс — всё, что угодно. Вместе с тем, люди тащат контейнеры себе в рот откуда ни попадя. Они часто даже не знают, что там лежит внутри.

Команда супергероев — программный комитет конференции DevOops — попалась в дьявольскую ловушку в Hangouts и целый час отвечала на вопросы. Что же теперь интересно DevOps-инженерам? (Кто все эти люди — подробно написано по ссылке).

У каждого эксперта — свой цвет: Под катом — интервью, раскрашенное цветными мелками.

Барух, как ты думаешь, что интересного произошло в мире с прошлого  DevOops?

Мне кажется, самое интересное, из очевидного — это взлет Kubernetes во все поля, а из неочевидного — менее заметно, но не менее важно, консюмеризация докера.

То есть раньше докер был не для всех?

Раньше докер был крутым, молодежным, вещью в себе. Нет. Но сам по себе докер как технология вдруг как-то раз и больше никого не интересует. А потом как-то докер перестал быть интересен, то есть он есть, он у всех и во всем, на нем все микросервисы, Kubernetes, девопс, все, что угодно. Меня это очень завораживает.
Не запускать же голую джаву на серверах, понятно, что контейнеры.

В докере не осталось проблем и были ли они там?
Люди обычно обсуждают то, с чем у них или проблемы, или прямые задачи связаны.

Кроме того, мы перестали использовать те части докера, которые были болезненны. В докере было много проблем, и они действительно решились. А есть те, которые плохо.
У докера были вещи, которые он умеет делать очень хорошо.

Приведи пример.

Это действительно очень круто работает. Например, джейлы в unix-процессах — там все очень хорошо и умно. А вот например, связность между микросервисами, которые бегут в контейнерах, кластеры, деплойменты, это всё был ад и кошмар.

Ты имеешь в виду Swarm, которым они пытались угнаться за Kubernetes?

И мы решили не пользоваться этим, а пользоваться только тем, что хорошо работает, что понятно и бесплатно. Да, я имею в виду Compose, вот это все было кошмар и ад. Докер и докер — ну и хорошо.
И докер стал очень крут с одной стороны, а с другой стороны перестал быть интересен.

Желательно от производителя этой софтины. Сейчас, когда присматриваешься к новому софтину, в первую очередь смотришь, есть ли готовый контейнер. Докер доставил нам сложные сервисы на потыкать на рабочую машину. Потом смотришь, как ее развернуть и потыкать в нее палочкой. Тот же Sentry состоит из 5-6 компонент, которые по отдельности задолбаешься запускать. Сейчас не так уж важно, макось у тебя или линукс. Сейчас это займет 15 минут — запустил, у себя развернул, причем кусок будет на Ruby, кусок на Java, не дай бог, какой-нибудь Elasticsearch — который умрет с этим же докером.
А если у тебя задача просто посмотреть, как это добро выглядит, послать сигнал и наблюдать, как оно там разложится.

Самое главное, он потом умрет.

Раньше можно было себе в систему нагадить так, что в /usr/local что только не было. Да, это отдельная прелесть. И у тебя система пухнет, обрастает всем ненужным. И оно ж еще встанет — у кого в /opt, у кого в /usr/local, у кого еще куда-то. И так как мы все это запускаем теперь в докерах, то и безопасность здесь, и чистота, и не таскаешь с собой гадости всякие.
Это одно, а второе — чем больше у тебя ненужного, чем больше вектор атаки на тебя, из-за чего тебя можно обидеть.

Слушайте, дамы и господа, вы же конференции по девопсу делаете, и там если докер стал скучным и неинтересным, что теперь, докера не будет?

То, что он стал скучным и неинтересным, не значит, что его перестанут использовать. Во-первых, докер будет везде. То есть он везде есть. Наоборот, это значит, что мы теперь его используем и не обращаем внимание.
Он не тема отдельного разговора на конференциях.

Если я сейчас зайду в программу и напишу слово докер, не найдется ничего?
А он в докладах-то есть?

Давай проведем этот прекрасный эксперимент.
Напиши.

Написал, и там написано: Practical steps for securing your container deployment

Кроме этого, он отражает еще одну вещь, которая может быть тоже изменилась за последнее время… Девопс стал больше. Это отражение того, что докер позволяет нашим современным системам быть более безопасными натуральным образом. И вместе с ними все больше стало разговоров на тему безопасности, которую может принести девопс или, наоборот — поломать оную безопасность. Скажем так, им стали все больше проникаться крупные компании.
Доклад Лиз как раз о том, как этот девопс правильно приготовить, чтобы ваши безопасники были довольны.

Кто такая Liz Rice?
Вы докладчиков лично-то знаете?

Она глава всех KubeCon-ов. Лиз — достаточно важная фигура в девопсном ландскейпе. Во-вторых, она работает в компании Aqua Security, которая занимается как раз безопасностью контейнеров. На самом деле Лиз, во-первых, очень хороший докладчик. Что интересно конкретно про доклады Лиз, я видел много ее докладов, — это то, что она пытается решить достаточно сложную проблему. Лучшего человека для рассказа про безопасность контейнеров, чем тот, кто этим специально занимается, мы не найдем. Соответственно защищаться от них становится сложнее, мы должны шифровать нашу информацию по REST, мы должны шифровать in-traffic, всякие TLS-ы, https-ы, сертификаты, протоколы… все это сложна. Проблема в том, что сегодня security, во-первых, сложный, и делается сложнее и сложнее, поскольку атаки становятся более sophisticated. Во-первых, сложно, а во-вторых — от этого никуда не деться, поскольку ты не можешь сейчас сказать: «Ой, я этого не знаю, давай я не буду делать https. С буквой А на конце. Поскольку тот же мерзкий Chrome немедленно накричит на всех твоих пользователей, что у тебя все не секьюрно. Ну какая разница, кому я нужен». С другой стороны, она лежит на нас, потому что мы не можем просто проигнорировать эти аспекты. И это сочетание сложности и необходимости, оно вымораживает, потому что это не наша забота, мы все не безопасники. Лиз в своих докладах пытается просто и понятно донести ключевые аспекты безопасности контейнеров до людей, которые от  безопасности далеки, и это очень круто.

Они же часто даже не знают, что там лежит внутри. Там есть еще одна проблема в том, что люди тащат контейнеры себе в рот откуда ни попадя. И другое дело — потащить это в продакшн. Одно дело, если ты хочешь потыкаться палочкой у себя на ноутбуке. То есть нужно что-то, что сложно собрать, они берут готовое и хорошо, если от производителя, который позаботился и взял нормальные базовые контейнеры. И, к сожалению, многие тащат что ни попадя. Например, мы можем в ближайшее время огрести новую волну одноименных контейнеров, как было с пип-модулями, с гет-модулями. И это же вектор для атаки. То есть это не новая проблема, это все та же старая. Как было с доменами, все то же самое. Кстати, из-за этого у нас про безопасность много докладов. И когда сервис становится commodity, когда он так распространяется — туда приходят люди, которые наказывают тех, кто не следит за безопасностью.

А что там еще есть?

Кстати, с ним же будет круглый стол по безопасности.
У нас еще есть про управление секретами от Сета Варго.

А Сет — это же человек из Google, который раньше в HashiCorp работал?

Он оставил след чуть ли не в каждом кукбуке. До этого он работал в Chef Software и там был звездой, когда Chef был на пике популярности. Потом он много наследил в HashiCorp. Его за эту активность даже некоторые не любили. У нас он будет рассказывать про продукт HashiCorp. И этот шлейф HashiCorp за ним до сих пор тянется. Но в тайтле у него будет Google, так что это добавляет вес.
Про Google он не будет рассказывать.

Кстати, а что с Chef случилось?

Кое-где Chef был убит теми самыми контейнерами.

Применения Chef там, где были написаны и работают — насколько понимаю, могут еще достаточно долго продолжать работать, потому что configuration management сам по себе не умер.

У нас то, что не в докере, то под Шефом. Ребят, я могу вам сказать на живом примере.
Потому что сервера-снежинки никуда не девались.

То, что не под докером, то под Шефом. Ты сейчас сказал, что случилось с Шефом. Но под Докером у нас почти все.

Вот они еще будут какое-то время с Chef жить, потому что в адище ручного управления возвращаться все, кто побывал в нормальном мире, не хотят. Все правильно, но все равно остаются долго живущие сервера, сервера с данными, которые никто не хочет пихать.

Кстати, Ansible кто-нибудь из присутствующих использует?

Да, Ansible тоже есть.

Мы используем.

Почему Ansible?
И как?

Вот такое впечатление Ansible оставляет. Восхитительная способность превращаться в мусор с дикой скоростью. Такой сходимости к аду я еще не встречал в своей жизни.

Кажется, у нас есть про это доклад!

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

Вы говорите, что все под докером запускается, но сами сервера-то, чтобы на них гипервизор запустить, их же надо как-то сконфигурировать?

Да нет, в Амазоне берешь…

Понятно.
А, читер, в Амазоне.

Или Терраформой — где угодно.

И про это у нас тоже есть доклад.
Самые продвинутые.

Потом у тебя в Terraform какой-нибудь provisioner, тот же Chef, тот же Ansible. Terraform закрывает эту потребность, что есть куча провайдеров, у них по-разному запускаются виртуальные машины, и ты с помощью Terraform закрываешь слой, когда у тебя машина появляется. Профит. Какой-то provisioner наливает следующий слой, и потом на эту готовую минимально машину прилетает Docker.

А доклад ведет тот человек, который делал aws-modules для Terraform?

И еще этот человек интересен следующим: так как он долго пожил с Terraform, то в комьюнити, где он тусит все эти годы, сформировались некие best practices, и вокруг Terraform этих best practices как раз не хватает, потому что он местами настолько прост и настолько не дает тебе делать лишних движений, что иногда описание получается слишком сложным. Он очень много сделал для амазоновых модулей, но это community-часть. И мы надеемся, что Антон Бабенко, который как раз будет рассказывать про все это, поможет разложить по полочкам, как же все-таки жить с Terraform и не страдать от этого. У тебя будет либо портянка, либо наоборот, очень сложная взаимосвязанная структура. Как развивать свои модули для личных потребностей, чтобы они продолжали оставаться чистенькими, читабельными и, кстати, там, конечно же, тоже никто ничего не тестирует.

Никто не пробовал эти портянки терраформовские из более удобного метаязыка генерить?

И мы стараемся не делать так. Есть такие идеи. Представь, что у тебя в амазоне несколько vpc в разных регионах, тебе надо между ними пиринг, и вот тут у тебя начинаются приключения. Там на самом деле у Terraform есть структуры данных, которые позволяют все-таки обходиться без генерации, но сложно. То есть тебе надо разрулить в описании эти точки входа, описать каждый vpc и еще пиринг, связь между этими vpc в разных регионах. В каждом регионе API, точка входа разная, а Terraform ты будто бы говоришь про одну. У нас ребята это сделали своими модулями, и с этим хоть как-то стало можно жить. И все это надо как-то описать. Но если бы Terraform давал еще больше возможностей, если б там… Как это называется, когда переменная внутри переменной разыминовывается?
Вообще, тяжко, сложно.

Kotlin DSL.

<все адски смеются>

Переменная переменная, или интерполяция — смотря что ты имел в виду.

Он тебя заставляет писать максимально просто, в отличие от Котлин DSL, где у тебя полноценный Kotlin в руках.
В общем, это не полноценный язык, он очень усечен.

Ну как, со всеми ограничениями Kotlin DSL-а, которые сами понимаете, решаются чем?

Чем?

Решаются Groovy DSL, естественно!

Многие пользовались TeamCity из здесь присутствующих?

Груви DSL, Kotlin DSL, у нас же про это доклад!
Да, конечно.

И его конечно же делаешь ты?

У нас будет как раз TeamCity с Kotlin DSL и его сравнение с Groovy DSL в дженкинсе. Его делаю не я, нет!

Кто-то из JetBrains приехал?

В этом отдельная прелесть.
Нет.

У нас реальные пользователи, никакого маркетинга.

Все, сдаюсь, кто еще может сделать доклад про TeamCity?

Вот, в программе он есть. Небольшая компания, широко известная в России как Тинькофф, использует.

Да, и немножко рассказать, сравнить со всеми ненавидимым, но повсеместно используемым дженкинсом и его Groovy DSL.

Надо сходить, послушать и узнать, какую роль в выборе технологии сыграла харизма Баруха.

Я абстрагировался полностью от этого всего. Никакую.
Все будет честно, без мухлежа.

Имею в виду, что в Тинькоффе взяли все эти хипстерские технологии не просто так, TeamCity — это не какой-то энтерпрайз двадцатилетней давности, как это принято в банках обычно.

Банк для хипстеров от хипстеров. Тинькофф —  это такой банк, который с самого начала так и сделал. Соответственно, технологии там свежие и правильные.

TeamCity DSL стало можно пользоваться. Ребят, я действительно пользуюсь TeamCity каждый день, и в последней версии он стал прекрасен. В предыдущей версии, если ты переходил на Kotlin DSL, у тебя не было варианта продолжать пользоваться интерфейсом. Смотрите, какая проблема была до последней версии.
Как только ты перешагнул черту, единственный способ дальше писать был только на Kotlin.

Все, ты ступил на Темную Сторону.

Поэтому мы попробовали и откатились сразу назад на XML-конфигурацию. Да, документации было минимум, и это был адок. Потом ты можешь спокойно продолжить писать на Kotlin, если ты уже где-то что-то освоил. В последней версии при переходе на Kotlin DSL ты продолжаешь использовать веб-интерфейс, а он там под капотом формирует патчики, патчит эти структуры прямо в репозитории. Это прекрасно, ребята!
Те, кто еще не посвящен, могут продолжать тыкаться в интерфейсе.

Это благотворное влияние Антона Архипова.

Есть ли у нас доклады какие-то, которые посвящены не тулингу, а каким-то процессам, культуре, человеческой стороне?
Кстати, тут упоминали про практики всякие.

Во-первых, у нас есть прекрасный закрывающий кейноут Саши Титова и Кирилла Толкачева, в котором они будут обсуждать, плохо всё в девопсе или надежда еще есть. Естественно.

Мне кажется важным сказать, что DevOops — это, наверное, на данный момент чуть ли не единственная профессиональная конференция, которую организует JUG.ru Group, в которой разрешено говорить про социальные вещи и про процессные, причем на официальном уровне.

Для этого нам пришлось плотно пообщаться с руководством JUG.ru Group, но результат на лицо.

Это про команду внутри компании, которая пишет сервисы для внутреннего использования. У нас, кроме этого прекрасного кейноута, есть еще доклад от Dell EMC, там тоже во многом про процессы. Соответственно, напиши сервис, а потом продай его внутри компании. Одно дело написать этот сервис, а другое — чтобы им начали пользоваться, потому что все люди заняты, им некогда осваивать хипстерские технологии. Мы ожидаем там тоже огонька. К тебе придут пользователи, у них начнут возникать всякие нестандартные потребности, и вот у тебя дилемма — развивать сервис, чтобы им могли многие пользоваться или удовлетворить вот эту конкретную команду.


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

Барух, ты тоже что-нибудь остросоциальное рассказываешь?

Естественно, у нас есть какие-то метрики, к которым мы приносим с собой из dev и которыми мы не пользуемся и никогда не пользовались. У нас с Лёней Игольником есть доклад про то, как правильно начать замерять вот это все безобразие, которое у нас в девопсе происходит. Возникает вопрос, что же такое метрики девопс? У нас есть метрики, к которым мы приносим с собой из ops, с которыми всегда было куда лучше. Это просто взять тех и взять других, или это что-то новое, какие-то новые метрики? Что это значит? Короче говоря, data-driven devops.

Барух, иногда читатели, посетители негодуют, что товарищи из программного комитета свои доклады читают, они считают это чем-то нечестным.

По крайней мере, мы очень стараемся привести как можно больше разнообразных докладчиков, которые не только из программного комитета. Мы действительно это все приняли ко вниманию. Например, Алена Прохорчик, Principal Engineer в Rancher Labs, которые, наверное, имеют наибольший опыт в мире с multicloud Kubernetes deployments. Но при этом некоторых участников ПК мы всё же хотим видеть как докладчиков. А мы как программный комитет наслаждаемся её экспертизой в оценке докладов. Думаю, что все хотят послушать про это, и ей есть что рассказать. Но если у нас есть хороший докладчик, который хочет помогать программному комитету, я, честно говоря, не понимаю, почему мы должны выбирать или одно, или другое.
Наверное, когда вся конференция состоит из докладчиков из программного комитета, и у каждого из них по пять докладов, это действительно нехорошо.

У тебя вообще жизнь-то есть? Барух, ты работаешь работу, плюс постоянно ездишь с докладами, плюс работаешь в программном комитете. Как ты умудряешься все делать?

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

Кто-нибудь хочет что-нибудь добавить к нашему с Барухом монологу?
Понятно.

Я часто говорю, что слышал доклады, которые никто никогда не услышит.

Конкурс был один к трем. Да, программный комитет слышит не только то, что потом попадает на конференцию. Часть из того, что мы отфильтровали, мы рекомендовали на другие конференции.
Можно сказать, что так получилось, поскольку среди заявок было много достаточно интересных.

Kubernetes, например. Были ли какие-то темы, которые вам приходилось фильтровать по количеству? Есть что-нибудь еще?

У нас была битва за мониторинг.
Мониторинг.

Все любят мониторить.
Куча докладов.

Кто выиграл в этом Царе Горы?

Алексей Кирпичников, доклад «Чему мы научились, пока делали собственную систему уведомлений о нештатных ситуациях».

А есть что-то такое, что хотелось бы в программу, но нет экспертов?

Есть обратная сторона медали, наш любимый serverless, который вроде бы под хайпом, но никого, кто хорошо соображает и практически применил все это, не появилось. Ты с языка снял. Но в целом, в компаниях промышленного опыта пока мало. Надеюсь, хоть одного мы вытащим. Их тоже нет? Барух, а что с экспертами-евангелистами? Или просто к нам никто не пришел?

На визах, к сожалению, все и заглохло.
Вся эта история с визами нам очень здорово испортила ситуацию во многом, в том числе и с developer advocates, которые хотели приехать и рассказать про serverless, конкретно из Amazon, про лямбды.

Или какие-то прорывные вещи, которые запомнились?
А были такие доклады, в которых вы реально что-то новое для себя узнали, чего раньше не было?

Но не всегда!
Я, как один из самых нетехнических людей в программном комитете, постоянно узнаю кучу новых вещей, которые потом приношу инженерам своим, а они говорят, да это же 101, что ты мне принес.

Татьяна, ты ничего не говорила, расскажи, что нового ты узнала в процессе ПК?

Иногда меньше, иногда больше. Наверное, почти из каждого доклада много интересного нашла, чего не слышала. Особенно тот, который связан с Ansible, который уже упоминали. Из некоторых докладов мы что-то себе хорошее забрали. Интересно послушать доклад Оксаны, потому что я работаю в отделе, который занимается чем-то похожим. У нас тоже есть Ansible, и мы тоже начинали его неправильно готовить. Наш отдел, наоборот, пытается обработать всех, кто есть в компании.
Но у нас немного разная ориентация: насколько поняла, отдел Оксаны занимается теми, кто сам к ним пришел, и теми, кого бизнес требует.

Мы официально большое подразделение, которому поручено раздавать эти сервисы, в том числе местами насильно. На самом деле нет, я в том же отделе работаю, он у нас стоит на тех же позициях. Об этом мы поговорим на конференции.

Обязательно.

А Бородина обсуждали?

Владимир Бородин рассказывает про базы данных в облаках. Нет еще. Кстати, по облачным технологиям, наверное, это единственный доклад у нас.

Доклад по stateful в облаке, и это такая дичь-дичь, которую никто не умеет делать.

И поэтому появление такого managed PostgreSQL в России… В условиях, что многие сервисы просто обязаны были какое-то время назад перебраться в Россию, чтобы им позволили работать дальше — появление такого сервиса закрывает последний элемент пазла. Это никто не хочет делать, потому что потенциально потерять данные не хочет никто. Если облаков в России было много, то надежные хранилища, которым можно доверять, назвать непросто.

Расскажи, что тебя больше всего поразило?
Барух, ты постоянно что-то слушаешь, рассказываешь.

Мне очень интересно шагание Kubernetes по планете, мне очень интересна консьюмеризация докера, это очень прикольные штуки. Мы же с этого начали. И, конечно, я как тоже один из менее технически подкованных и менее хардкорно-ориентированных представителей программного комитета действительно старался, чтобы мы не обошли тему культуры и правильного построения процессов.

Можете ли вы что-то пожелать тем, кто сейчас это читает? Стремительно приближается к концу выделенное на встречу время, и настала пора подводить итоги. Какие-нибудь финальные мысли, какие-нибудь доклады, которые стоит посмотреть в первую очередь?

Естественно, годнота будет не только в первом зале, соответственно, имеет смысл посмотреть и другие доклады тоже. Очень простой способ приобщиться к великому — это зависнуть на прямой трансляции первого зала. JUG.ru Group славится активностями, которые происходят на площадке вне самой комнаты, где происходит доклад. Но мне кажется, главное отличие просмотра докладов (в том числе трансляции — неважно, бесплатной или платной) от похода на конференцию — это все, что творится между ними. Там у нас очень много всего интересного. Это и общение со спикерами в дискуссионных зонах, и всякая мякотка, которую мы приготовили после закрытия конференции. О таких больных темах, например, чем девопс отличается от SRE. У нас будут и круглые столы, дискуссионные бофы (BOF). Кроме того, всякий фан, например, будет караоке-баттл, в котором все могут поучаствовать, вечеринка гиковская — как и положено, все будут стоять по углам, пить и молчать 🙂
Есть технические доклады про security, но есть гораздо более глобальная проблема — что нам с этим делать, потому что, как я сказал, никто из нас не специалисты, а делать это приходится всем нам.

Всех  присутствующих здесь можно будет встретить или кто-то не поедет?

Скорее всего, меня точно не будет.

«Скорее всего, точно, с большой вероятностью» — это прекрасно, я считаю.

Все же видели эту картинку?

Все так. Да, все эти слова, меняются в зависимости от культуры страны, в которой это все произносится.

Тут, скорее всего, бофы будут бофами, в которых каждый может поучаствовать и что-то сказать.
Интересно, что когда речь идет о, допустим, каких-то кишках Java Virtual Machine, то BOF превращается в еще один доклад.

Мы, как программный комитет, сделаем все возможное, чтобы этого не случилось.
Дело не в кишках JVM, а в том, что некоторые докладчики абьюзают формат бофа, чтобы сделать из этого доклад.

Мне кажется, это надо прямо акцентировать.
Идея в том, что девопс — это процессы, и это как раз то, что нужно перетирать в кулуарах.

Для конференции DevOops общение в кулуарах еще более важно, чем для всех остальных конференций. Все правильно, отличное замечание. Как раз потому, что вот это people + processes, на доклады ложится гораздо хуже, чем на дискуссионные зоны, бофы и все остальное.
Я с тобой полностью согласен здесь.


Наверное, имеет смысл это подчеркнуть, потому что я смотрел на того же Артема Каличкина на TechTrain, и дискуссионная зона была сопоставима по насыщенности с самим докладом.

Там после доклада, может быть, даже интереснее было, чем то, что он вещал на аудиторию. Согласен, я тоже был в этой дискуссионной зоне. Надо понимать, что аудитория TechTrain была совсем другая. Но то, что он рассказывал на TechTrain, здесь нам не сильно бы зашло. Там было очень много всего смешанного, там было очень круто. Это новый формат для JUG.ru Group, это не конференция — это фестиваль. Там были доклады, но многие из них были лайтовые, на молодежную аудиторию, чтобы заинтересовать и вызвать дискуссию.
Я оба дня там был, и все было очень интересно и хорошо.


Там бы смысл в том, что дискуссия может начаться с короткого доклада, а потом все пространство Экспофорума — это твоя «дискуссионная зона» (если говорить в терминах наших конференций).

Там же были еще доклады-лайтнинги, в зонах рядом со стендами буквально на двадцать минут, после которых тоже я случайно оказался свидетелем доклада про то, как человек писал хоралы Баха. Да, так и было. Мы с ним полчаса обсуждали еще — ему просто не повезло, что я мимо проходил.

Пригласи его на DevOops в следующий раз!

А человек, между прочим, из чудесной компании Леруа Мерлен — исключительно айтишная компания.
Его, скорее, на Joker надо приглашать, потому что он на Java писал.

Вы же знаете, every company is a software company, и наверняка они там делают что-то интересное. Они много всего делают, они выступают на многих конференциях и, наверное, на следующий DevOops оттуда можно будет кого-то интересного позвать.

Мы с вами еще неоднократно пересечемся при подготовке статей, а вот с нашими читателями с Хабра мы встретимся только на DevOops. Спасибо всем за интервью! Всего хорошего, и до новых встреч!

Если вдруг вам понравилась программа, которую мы тут обсуждали, то обязательно приходите. Конференция DevOops состоится 14 октября 2018 года в Санкт-Петербурге. Билеты есть по ссылке.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть