Комментарии 19
Редко пишу комментарии, но такого замеса тёплого с мягким не видел уже давно. Микросервисы перепутаны с микрофронтендом в половине текста, DevOps вообще хз кто, называем так всех, кого можем и т.д., и т.п.
В итоге, из интересного отраслевого кейса, получилась полная каша. Понимаю, что блог корпоративный, но технарям надо давать вычитывать.
На наш взгляд микросервисы (на бэке) и микрофронты имеют в себе много общего и разделять их в рамках вертикальной разработки, только по тому что это фронт и бэк? Ведь разработка идет full stack.
Это первая, можно сказать, вводная статья. В следующих я расскажу в технических деталях, как, что и зачем мы делаем. Как строить масштабируемое микрофронтовое приложение. Как мы обеспечиваем независимы деплоймент, как добиваемся низкой связанности между микрофронтами.
Именно такой подход помогает нам, малыми, действительно малыми, ресурсами и в короткие сроки выводить многие фичи, делать большое количество экспериментов — в итоге находя то, что нужно пользователю.
В нашей команде DevOps — это инженер, занимающийся разработкой фичи начиная с разработки фронта, бэка, тестов(dev) и заканчивая сопровождением ее на протяжении всего времени жизни(ops). Деплоит в прод, устанавливает индикаторы стабильности и производительности и следит за ними. Обеспечивает вывод их эксплуатации ненужных сервисов… И т.д. Об этом опять же я напишу в следующих статьях.
Ну какой же это DevOps?
Development + operations, что не так? Или DevOps это админ только для микросервисов?
Есть процесс DevOps и есть человек DevOps.
Как говорит википедия процесс DevOps это процесс тесного взаимодействия между Development и Operations. Это определение переносят и на людей, которые, строят этот процесс. В крупных конторах, где есть применяться разделение по цехам девопы строят Ci/Cd процесс общий для всех. С мониторингом, автоматизацией и так далее. Разработчики пытаются в рамках ограничений, которые им ставят девопы решить задачу. И так человек устроен, что зачастую не разобравшись до конца в технологии разработчики раз за разом наступают на одни и те же грабли. Но это общая проблема цехового производственного процесса.
В случае, когда компания проявляет гибкость в орг структуре и не цементирует зоны ответственности возникает человек-DevOps.
Канонический ;) То есть разработчик, который выполняет и operations. То есть он и написал, он и задеплоил, он и отвечает за работоспособность и мониторинг своего сервиса.
Так уж сложилось что это можно сделать в рамках микро сервисной архитектуры. Ведь в монолите или в сильносвязанной системе operations отнимает очень много времени, и его не остается на разработку.
Микрофронты так же как и микросервисы помогают людям DevOps-ам релизить свои фичи от и до. Начиная от разработки — и заканичивая мониторингом и всем остальным.
Мы этим занимаемся уже 3 года. И крайне успешно ;)
то мы получим двойную загрузку необходимых библиотек, и соответственно, ухудшение метрик производительности.
Подскажите, а блок peerDependencies в package.json не решал эту проблему?
Например, у нас есть страница с информацией о квартире, она собирается при релизе и соответственно скачиваются зависимости. Которые затем упаковываются в bundle этой страницы. Который загружается через ссылку в теге <script src='...'>.
Теперь, допустим, наша команда, которая реализует фичу «ипотечный калькулятор» хочет добавить на эту страницу функциональность с расчетем ежемесячного платежа. Наша задача добиться того, что бы при изменениях в калькуляторе пересобирать основную страницу не пришлось.
Поэтому наш калькулятор мы реализуем отдельным проектом, с отдельным процессом сборки и соответсвенно своим bundle. Куда так же на этапе сборки упаковывается версия библиотеки.
Когда два bundle (основной страницы и калькулятора) будут загружены — они не смогут видеть библиотеки друг друга.
Поэтому в случае микро фронтов peerDependencies не поможет, т. к. процесс сборки двух «проектов» разделен на 100% и не зависит один от другого…
Ведь когда мы работаем с рынком, мы не знаем, что он примет, а что нет. Только большим количеством изменений мы можем нащупать «невидимую руку рынка», что крайне важно особенно на начальных этапах развития инновационного продукта.
И тут на первый план выходит стоимость изменения.
«Краткосрочные перспективы» это когда есть идея; ее реализовал — и все. Но я на опыте убедился, что если дать poduct owner-у возможность генерировать идеи по развитию, которые реализуются не за два, три месяца, а максимум в неделю — две, то идеи не закончатся… Работа будет всегда. Мы же не лампочки делаем. ;)
Везде нужен баланс. И просто взять и ускориться сейчас, написав как угодно и на чем угодно, в будущем этот зоопарк вас не слабо тормознёт
Тут же какая вещь. Зоопарк это когда много всего, друг на друга зависит, и ничего не выкинуть. В этом случае точно — затормозит.
Но фишка микро фронтенда(как и микро сервисов) в крайне низкой связанности компонентов и легковесных протоколах интеграции.
В этом случае, как и показал наш опыт, замедления не происходит. Потому как каждый новый компонент — он отдельный. И небольшой. Переписать его, сохраняя верхнеуровневые и интегарционные тесты очень просто. Поэтому зачастую при развитии микросервиса его проще(и дешевле) написать с нуля, на привычной для инженера технологии, чем этому инженеру изучать чужую технологию и пытаться натянуть сову на глобус.
Помните, как писал дядя Боб:
- The jury is in!
- The controversy is over.
- GOTO is harmful.
- And TDD works.
Я бы еще добавил, что микро фронты — не замедляют разработку, ни на одном этапе. Главное не позволяйте им превратиться в монстра, которого невозможно переписать за неделю…
Пока только минусы:
- Можно было разделить сборки через, например dllPlugin. Но оставить одну версию переиспользуемых либ. Зависимости через монорепу было бы удобно обновлять в данном кейсе. Вы пошли путём не масштабируемым собирая везде отдельный бандл и решили использовать какие-то легко весные либы, которые надо изучать. Т.е по вашим словам же, научить инженера сложнее чему-то новому чем писать на известном
- Для единого стиля вам нужна какая-то дизайн система. Разработать под зоопарк фреймворков сложнее чем под один
- Для бизнеса ещё бывает момент, когда он хочет перераспределить ресурсы на более важные части. Например из одной команды привлечь разработчиков в другую для ускорения. Но тут у вас будет большая сложность. И инструменты другие и подходы и линтеры
В итоге как ни крути, связанность есть, так как проект один. Связанности могут быть не обязательно в коде. А в стилях, подходах, переспользуемость ускоряет, а не написание 10 раз с нуля в каждом блоке на странице.
Давайте попробуем отдельными топиками разобрать, то, что мы используем, и о чем говорим.
Т.е по вашим словам же, научить инженера сложнее чему-то новому чем писать на известном
Жаль, что я не нашел с первого раза правильную формулировку. Давайте попробуем по другому.
Предположим у нас есть некий уже готовый фремворк (например Материал или Альфа Банк ui kit) с другой стороны компоненты, пусть даже и пере используемые в рамках монолитного фронта.
В первом случае целью было создать удобный и пере используемый фремворк для создания унивесальных приложений. и поэтому:
- В него вложены очень серьезные деньги и силы большой команды.
- Он отлично документирован, с описанием встраивания и возможных подводных камней.
- Он универсален, и имеет защиту от неправильного использования.
Второй вариант.
- Дешевый вариант, т. к. в продуктовой разработке важен больше бизнес результат, который трудно вывести из общей библиотеки.
- Документация это обычно страничка на конфлюенсе, которая была написана на этапе защиты проекта, которая безнадежно устарела. Либо плохо структурированный, трудно понимаемый мануал, который писал сам разработчик. Да и вообще — "код лучше всякой документации", и "если что: подойди — спроси"
- Обычно создавался для встраивания в конкретное место, имеет крайне мало степеней свободы в использовании и требует доработки для встраивания в другие места.
И вот это моя основная мысль:
Инженеру проще пользоваться для решения своей задачи первым вариантом, чем погружаться во второй. А для этого в рамках продукта необходимо обеспечить возможность стыковки компонентов, без зависимостей одной на другую.
Как организуются команды и осуществляется процесс разработки когда нужно собрать несколько продуктов в "бандл" (и управлять продуктом как "бандлом" а не отдельными наборами продуктов)?
И еще вопрос как вы привлекаете и удерживаете HPE, как работаете с культурой внутри фирмы?
Именно сквозная аналитика позволяет управлять продуктом в целом.
Аналитика — отдельная, также слабо связанная с сервисами система. Т. к. аналитика оперирует слабо структурированными данными и толлерантна к формату. То она не противоречит развитию отдельных фич.
Тема такая: компонент должен откинуть отчетную информацию в удобном формате, главное что бы там была информация, а дальше аналитики(bigdata) постараются намайнить из нее все, что необходимо для понимания где проект находится в текущий момент и куда можно развиваться.
Это про управление. Если интересно как технически совмещать разработку единого фронта из многих компонентов — то я готовлю статью на эту тему…
По культуре если есть время — советую посмотреть выступление на митапе, в котором мы участвовали совместно с БКС. Дмитрий Камалдынов — директор нашего бизнес-юнита — там по этому поводу выступал. Ссылка с таймингом youtu.be/qL4zfaDLi9c?t=2578
Micro-frontends. Асинхронный подход к мультикомандной разработке