2019-11-29: Highload - очередной шаг Web-Scale IT for Enterprise
В начале ноября был на Highload-2019 и свое основное впечатление с конференции я сформулировал по горячим следам в этом посте на FB: Web-Scale IT for Enterprise сделал очередной такт развития. Напомним, шесть лет назад, в 2013, Gartner анонсировал на 2014 год новый тренд Web-Scale IT for Enterprise - применение технологий, наработанном в публичном Web для разработки "серьезных" enterprise-приложений. В 2015-2016 годах этот тренд пробовали учесть на конференциях #SECR и #RITfest, но тогда это было про будущее. А эта конференция показывает, что этот тренд за прошедшие годы развернулся в очень широко. Для банков, которые активно переходили в интернет-пространство, этот тренд развернулся естественным образом уже давно. Тинькофф, Сбербанк, Альфа, Райффайзен активно представлены на IT-конференциях. А сейчас эти технологии активно осваивает Retail, в том числе тот, который производит товары, а не просто их продает. На конференции стояли стенды Lamoda, Леруа, Спортмастера и других. Был целый трек, на котором они рассказывали о своих проектах, о переходе с традиционных технологий на современные и технологический стек там вполне современный - ClickHouse, Elastic, Kafka, Go и многое другое. И используются эти технологии на хорошем уровне, характерном для высоконагруженных приложений публичного Web. На прошлом Highload это было гораздо менее выражено: стенды стояли, но меньше, а доклады если и были, то больше про технические аспекты, а не про решение бизнес-задач. Так что очередной такт развития цифровизации бизнеса пройден, ждем следующих.
А еще на Highload второй год вручается премия за вклад в развитие IT. Номинанты 2019 - интереснейшие люди, я всем рекомендую зайти на страницу и почитать. Было две системы голосования: экспертный совет и публичное, и один из номинантов получил сразу обе премии. Всех лауреатов я не записал, а на сайте список еще не опубликован. Но помню, что среди них точно был Алексей Натёкин, организатор бесплатных DataFest, собиращих тысячи участников, Кирилл Мокевнин, Сергей Федоров из jug.ru и другие. Кстати, вручение проходило интересно: показывали ролик с кандидатом, где лицо было скрыто, но шли комментарии, а дальше аудитории предлагалось угадать :) Надеюсь, ролики тоже выложат, вместе со списком лауреатов. А лауреатов прошлого года можно увидеть на странице премии.
Ну а теперь я перехожу к обзору докладов. Как всегда на таких конференциях он будет не репрезентативен, потому что на конференции 15 треков, и ты в каждый момент только на одном. К тому же я был только один день из двух, второй пересекся с конференцией 40 лет ОДИ. Но я услышал много интересного и очень благодарен организаторам и спикерам за интересные доклады и всем - за активное общение. Общение тоже было много, хотя с некоторыми из знакомых я так и не смог встретиться на конференции, мы это выяснили уже потом..
Итак, доклады, которые я услышал.
Пост на FB Первый доклад Олег Филиппов Распределенная система, которая работает везде и на всём. Про технологии, на которых работает современный fasion retail, кейс SELA. С требованиями устойчивой работы на любом оборудовании, которое стоит у франчайзеров в разных небольших точках (поэтому без JVM на клиенте), offline или через очень слабый интернет, работа с внешним оборудованием (поэтому не Web), 400+ узлов базы данных. Мне это очень знакомо, потому что в Спортмастере мы такую систему строили с начала нулевых, с аналогичными требованиями, и задачи-то - не изменились. Сейчас построение продолжается, но, как обычно, в технологиях влияет история, поэтому узнать о решениях на новых технологиях было интересно.
Что я для себя вынес? 1C на фронте - основной вариант, потому что работает на всем железе, отслеживает изменения законодательства, и ее все кассиры знают, не надо обучать.
Основная БД - PostreSQL и MS SQL с репликациями из центра в периферию с фильтрацией и обратным сбором данных. И на слабом оборудовании локальная БД всегда будет ломаться и теряться, поэтому не заморачиваются с бэкапами, а вместо этого всегда можно переключиться на работу с центральной БДб запустив параллельно восстановление локальной и занимает 20 минут. Для, для отключения и восстановления нужен интернет, и если одновременно упала локальная БД и интернета нет, то печалька, но считаем, что что-то одно есть. А при этом для данных бонусной системы - CouchDB, она позволяет распределенную сетевую репликацию с резервными узлами, легко конфингурируется, есть легкий вариант PouchDB для развертывания на клиентах. Система сбора бизнес-логов ClickHouse, а не Elastic+ELK, потому что Elastic дорог, стоимость логов получается как продакшн. При этом там для бизнес-задач структурированных данных хватает, текстовый поиск не нужен. А вот технологические логи, сбор потока сознания в журналах 1С - на Elastic, потому что там проблемы без поиска по regexp не найдешь. И все выведено на Grafana
Самописная система распространения обновлений - потому что в условиях неустойчивого интернета надо их вытягивать, когда он появился, надо взаимодействовать с клиентом, чтобы не запустить обновление когда касса выбивает чеки - промышленные системы этого не умеют. При этом для службы поддержки - DokuWiki, и все действия посажены на кнопки. Это тоже интересно - нет сейчас готового решения.
Пост на FB Денис Карасик из Badoo. Кафка. Описание одной борьбы. Заглянул внутрь конфигурирования Кафки для обеспечения скорости и надежности. Люблю такие доклады, потому что через них понимаешь внутреннюю логику работы системы. И это реально полезно. Спасибо.
Пост на FB Алексей Скоробогатый из Lamoda. Starship Enterprise Evolution: архитектура e-commerce-платформы. Очень интересный и содержательный доклад про эволюцию от традиционной архитектуры обработки данных, включающей huge-монолиты, мелкие сервисы с SOA и cron-driven reporting, и передачу всего в DWH, где обработка данных, в общем случае, идет в суточном ритме к event-driven архитектуре обработки потоков событий, позволяющих получать результат почти-real-time, за несколько секунд. Для этого исторически сложившиеся монолиты, например, содержащие данные о заказах, выдают события по созданию заказа и изменению состояния, которые попадают в Кафку, обрабатываются сервисами на Go и возвращают свои события, на которые подписываются потребители, и хранение состояния сервиса в собственной Postgres-базе. При этом монолит разгружается от многочисленных обращений потребителей данных по заказам, а сервисы сами хранят необходимые данные. Существующие сервисы частично переиспользованы, но вместо request-responce сделан прием событий и выдача событий-результатов. И уже над ними, где надо, надстроено API, которое может дождаться ответа для синхронного вызова.
Отмечу, что зал был переполнен, и зона рядом с залом - тоже, я немного задержался и в результате слушал доклад сидя на полу - чтобы конспектировать. Но он того стоил, спасибо Алексею!
Пост на FB Артем Цурков, Связной. 5 лет в А.Д.у - Расчет цепочки поставок - ДДД Эванса на практике. Несколько сумбурный, но очень интересный доклад о том, как за счет применения DDD меняли структуру обработки запросов на доступные маршруты доставки заказа при заказе на сайте. При том, что на входе был черный ящик, который последовательно дорабатывали с многочисленными наслоениями по преобразованию данных, в результате, например, даты заказа и информация по оплате была дублирована многократно. И Артем показывал, как за счет модели предметной области эта логика прояснялась и менялась: цикл расчета маршрута был разбит на три участка - узлы сборки, узлы выдачи, варианты маршрута, для маршрутов появилась абстракция билета и так далее. Но при этом начиналось все с выстраивания логов и мониторинга метрик, и профилирования, потому что далеко не всегда структурная оптимизация дает выигрыш сама по себе. Например, описанная выше разноска на три этапа расчета сначала дала деградацию, потому что каждая нода начала обращаться за остатками, но после того, как это обращение вынесли на прокси, который маршрутизировал начальный запрос, и начали добавлять к запросу - скорость выросла. И было еще несколько примеров. Интересно!
Пост на FB Игорь Цупко. Потерянные знания: что делать с непонятным легаси. Митап KnowledgeConf неожиданно собрал громадное число слушателей, что переместились из маленькой комнаты в Сингапур и он почти заполнен. Но Сингапур был свободен только один слот, на второй - переместились в фойе и фото - оттуда.
Рассказ о болях начался с философского вопроса: если ваш руководитель направил нас на легаси-проект, то надо бежать или принять испытание судьбы?
Дальше - заметки в вольном стиле.
Как появляется легаси? А очень просто: быстро запилили фичу и забыли. И через год-два у вас жуткое количество фич, и никто не знает, что они делают.
Запросы посмотреть чужой позитивный опыт:
- У нас монолит, мы пытаемся покрыть тестами, а уже потом реинжинирить. Кто-нибудь прошел этот путь?
- Что перспективнее: Постепенно выносить монолит в небольшие модули, или собрать технический долг, и перестроить монолит внутри?
Жизненный цикл легаси Ctrl-Alt-Del: взять под контроль, заменить, удалить...
Требования в легаси: абсурдные, непонятные и исторически сложившиеся. Люди привыкли и пользуются... Сделано решение, потому что не придумали по-другому, или это тот гвоздь на котором все держится?
А еще микросервисы могут превратиться в распределенный монолит,, может надо научиться монолиты готовить...
Про требования. Очень важно: что решили, почему решили и какие варианты рассматривали - последний пункт тоже очень важен.
Если трамвайчик разгоняется, и мы не можем объяснить, что надо приостановиться и сделать рефакторинг, и руководство не понимает - стоит ли пробовать уговорить, или лучше сразу идти на headhunter?
Мой рецепт, как приостановить трамвайчик докручивания новых фич... Можно объяснять, что эти новые фичи внутри сделать дорого и тяжело, поэтому надо сделать рядом - и так постепенно сначала окружить трамвайчик новым набором машинок, а потом и заменить его.
Паттерн, когда новичка бросают на легаси-участок, а потом дают другие проекты. Жестко, но есть разумное зерно: если бизнес построен над легаси, то надо проверить совместимость человека.
Рефакторинг легаси - это путь самурая. Даже если эффективность обоснована, все равно остается риск того, что после рефакторинга вылезут большие проблемы. И или ты веришь, что команда сможет с этим справится, или ты не веришь. При этом проблемы в легаси - они не твои, ты их унаследовал и можешь жаловаться. А в новом все проблемы будут твоими.
Еще вопрос легаси имеет две стороны. Есть позиция, что легаси надо квалифицировать с точки зрения бизнеса: когда жесткость системы не успевает за требованиями по доработкам, когда высокая стоимость доработок или эксплуатации. И есть позиция разработчиков: легаси - это то, что на устаревших технологиях, что противно дорабатывать и сопровождать. Бизнес-позиция эту скрытую позицию легко пережимает, но победа часто кажущаяся, потому что разработчики голосуют ногами, увольняясь или применяют манипулятивные приемы. Нормальный диалог, учитывающий обе позиции, складывается редко.
[ Хронологический вид ]Комментарии
Войдите, чтобы комментировать.