Pull to refresh

Comments 19

Редко пишу комментарии, но такого замеса тёплого с мягким не видел уже давно. Микросервисы перепутаны с микрофронтендом в половине текста, DevOps вообще хз кто, называем так всех, кого можем и т.д., и т.п.


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

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

На наш взгляд микросервисы (на бэке) и микрофронты имеют в себе много общего и разделять их в рамках вертикальной разработки, только по тому что это фронт и бэк? Ведь разработка идет full stack.

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

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

В нашей команде DevOps — это инженер, занимающийся разработкой фичи начиная с разработки фронта, бэка, тестов(dev) и заканчивая сопровождением ее на протяжении всего времени жизни(ops). Деплоит в прод, устанавливает индикаторы стабильности и производительности и следит за ними. Обеспечивает вывод их эксплуатации ненужных сервисов… И т.д. Об этом опять же я напишу в следующих статьях.
Да, в терминологии есть небольшая путаница. Дело в том, что в нашей команде мы работаем по схеме high performance employee. В частности т. к. все настроены прежде всего на то, чтобы выдавать результат, и все занимаются всем, то и четких границ ролей нет. Каждый из нас занимается в том числе devops активностями по части построения и автоматизации релизных процессов. Конкретно для своей фичи. Часто для краткости мы друг друга назваем devops, хотя на самом деле мы что то типа devops++…
Ну вот честно, какое каноническое определение у термина DevOps?

Development + operations, что не так? Или DevOps это админ только для микросервисов?

Тут такая тема, зачастую происходит путаница и определениях.

Есть процесс DevOps и есть человек DevOps.

Как говорит википедия процесс DevOps это процесс тесного взаимодействия между Development и Operations. Это определение переносят и на людей, которые, строят этот процесс. В крупных конторах, где есть применяться разделение по цехам девопы строят Ci/Cd процесс общий для всех. С мониторингом, автоматизацией и так далее. Разработчики пытаются в рамках ограничений, которые им ставят девопы решить задачу. И так человек устроен, что зачастую не разобравшись до конца в технологии разработчики раз за разом наступают на одни и те же грабли. Но это общая проблема цехового производственного процесса.

В случае, когда компания проявляет гибкость в орг структуре и не цементирует зоны ответственности возникает человек-DevOps.

Канонический ;) То есть разработчик, который выполняет и operations. То есть он и написал, он и задеплоил, он и отвечает за работоспособность и мониторинг своего сервиса.

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

Микрофронты так же как и микросервисы помогают людям DevOps-ам релизить свои фичи от и до. Начиная от разработки — и заканичивая мониторингом и всем остальным.

Мы этим занимаемся уже 3 года. И крайне успешно ;)
И тут все это работает только при одном условии. Наличии облака. Не важно какого. В компании должен быть отдел — продуктом которого является облако, либо облако должно быть куплено у провайдера PaaS. Это может быть Cloud Foundry или Kubernetes не важно. Современные облака позволяют настолько автоматизировать operations что разработчик легко превращается в DevOps-а. Построить тогда CiCd процесс для созданного тобой микросервиса — проще простого.
то мы получим двойную загрузку необходимых библиотек, и соответственно, ухудшение метрик производительности.

Подскажите, а блок 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.

Я бы еще добавил, что микро фронты — не замедляют разработку, ни на одном этапе. Главное не позволяйте им превратиться в монстра, которого невозможно переписать за неделю…

Пока только минусы:


  1. Можно было разделить сборки через, например dllPlugin. Но оставить одну версию переиспользуемых либ. Зависимости через монорепу было бы удобно обновлять в данном кейсе. Вы пошли путём не масштабируемым собирая везде отдельный бандл и решили использовать какие-то легко весные либы, которые надо изучать. Т.е по вашим словам же, научить инженера сложнее чему-то новому чем писать на известном
  2. Для единого стиля вам нужна какая-то дизайн система. Разработать под зоопарк фреймворков сложнее чем под один
  3. Для бизнеса ещё бывает момент, когда он хочет перераспределить ресурсы на более важные части. Например из одной команды привлечь разработчиков в другую для ускорения. Но тут у вас будет большая сложность. И инструменты другие и подходы и линтеры

В итоге как ни крути, связанность есть, так как проект один. Связанности могут быть не обязательно в коде. А в стилях, подходах, переспользуемость ускоряет, а не написание 10 раз с нуля в каждом блоке на странице.

Давайте попробуем отдельными топиками разобрать, то, что мы используем, и о чем говорим.


Т.е по вашим словам же, научить инженера сложнее чему-то новому чем писать на известном

Жаль, что я не нашел с первого раза правильную формулировку. Давайте попробуем по другому.


Предположим у нас есть некий уже готовый фремворк (например Материал или Альфа Банк ui kit) с другой стороны компоненты, пусть даже и пере используемые в рамках монолитного фронта.


В первом случае целью было создать удобный и пере используемый фремворк для создания унивесальных приложений. и поэтому:


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

Второй вариант.


  1. Дешевый вариант, т. к. в продуктовой разработке важен больше бизнес результат, который трудно вывести из общей библиотеки.
  2. Документация это обычно страничка на конфлюенсе, которая была написана на этапе защиты проекта, которая безнадежно устарела. Либо плохо структурированный, трудно понимаемый мануал, который писал сам разработчик. Да и вообще — "код лучше всякой документации", и "если что: подойди — спроси"
  3. Обычно создавался для встраивания в конкретное место, имеет крайне мало степеней свободы в использовании и требует доработки для встраивания в другие места.

И вот это моя основная мысль:


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

Как организуются команды и осуществляется процесс разработки когда нужно собрать несколько продуктов в "бандл" (и управлять продуктом как "бандлом" а не отдельными наборами продуктов)?
И еще вопрос как вы привлекаете и удерживаете HPE, как работаете с культурой внутри фирмы?

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

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

Тема такая: компонент должен откинуть отчетную информацию в удобном формате, главное что бы там была информация, а дальше аналитики(bigdata) постараются намайнить из нее все, что необходимо для понимания где проект находится в текущий момент и куда можно развиваться.

Это про управление. Если интересно как технически совмещать разработку единого фронта из многих компонентов — то я готовлю статью на эту тему…

По культуре если есть время — советую посмотреть выступление на митапе, в котором мы участвовали совместно с БКС. Дмитрий Камалдынов — директор нашего бизнес-юнита — там по этому поводу выступал. Ссылка с таймингом youtu.be/qL4zfaDLi9c?t=2578
Only those users with full accounts are able to leave comments. Log in, please.

Information

Founded
Location
Россия
Website
www.cian.ru
Employees
201–500 employees
Registered