Чуть больше года назад, в апреле 2024 года, Гугл опубликовал Список из 101 реального примера использования ИИ от ведущих мировых организаций. Прошел год и в апреле 2025 года этот список насчитывает уже 601 пример из различных областей. Поскольку меня интересует ритейл, то вот выжимка. Больше деталей по ссылке.

Клиенты:
▶️ AI Sommelier от Carrefour Taiwan, голосовой ИИ, интегрированный в приложение, помогает клиентам выбирать вина на основе их предпочтений
▶️ Home Depot создала Magic Apron — ИИ, который круглосуточно предлагает экспертные рекомендации чтобы облегчить обустройство дома
▶️ Lowe's улучшает поиск товаров с помощью Vertex AI Search, позволяющий генерировать динамические рекомендации по товарам и отвечать на сложные поисковые запросы клиентов

Сотрудники:
▶️ Arpalus разработал приложение, которое может мгновенно анализировать физическую полку и уведомлять сотрудников о действиях, которые необходимо предпринять для ее улучшения
▶️ Best Buy создает резюме разговоров в реальном времени с помощью ИИ контакт-центра, позволяя живым сотрудникам переключить свое внимание на поддержку клиентов
▶️ Home Depot разработала приложение Sidekick, которое помогает сотрудникам магазина управлять запасами и поддерживать полки заполненными
▶️ Woolworths использует Gemini для создания акций нового поколения и для быстрого обобщения всех предыдущих взаимодействий с клиентами в режиме реального времени

Креатив:
✔️ Carrefour использовала Vertex AI для создания Carrefour Marketing Studio - решения для оптимизации создания динамических кампаний в различных социальных сетях
✔️ L'Oreal Groupe использует Veo 2 и Imagen 3 в качестве творческого партнера, позволяющего создавать разнообразные кинематографические кадры за меньшее время в 20 странах и на 20 языках
✔️ Puma использует Imagen для настройки изображений продуктов на своем веб-сайте, что экономит время и обеспечивает их локальную релевантность на всех рынках

Разработка:
✔️ Leroy Merlin разработал свой анализатор pull реквестов с использованием Vertex AI показывающее суммарное изменение кода, помогая разработчикам быстрее понимать проекты и повышать эффективность проверки кода

Данные:
✅ Shopify полностью преобразовала свою инфраструктуру данных, объединив все свои данные и подключив их к технологиям обработки данных на базе ИИ для предоставления мощной бизнес-аналитики
✅ Unilever оцифровал процессы дистрибуции с помощью BigQuery и теперь может обрабатывать 75 000 заказов ежедневно

Безопасность:
🟡Dunelm интегрировал Google Security Operations с Acora для создания комплексного профиля рисков, и обеспечил адаптивную, гибкую и высокоавтоматизированную защиту даже от самых сложных угроз
🟡Grupo Boticário (лидер рынка косметики и парфюмерии в Бразилии) использует модели безопасности в режиме реального времени для предотвращения мошенничества, а также для выявления и реагирования на проблемы

Понятно, что это только выжимка и только про ритейл. В исходной статье гораздо больше информации по разным рынкам и по разным применениям.
#новости #AI #ChatGPT #чтотампроchatgpt #data #данные

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

"Бирюзе" как массовому явлению немногим больше 10 лет. Все началось с Фредерика Лалу и его книги - Открывая организации будущего. Идея создать компанию без иерархии, самоорганизующуюся, с ответственными людьми, выбирающими что делать и куда развиваться, быстро проникла в умы и сподвигла на эксперименты. Вдумаемся: мало контроля и много доверия, работа ради смысла, а не KPI = описание работы мечты.

Но не сработало. Точнее сработало, но не для всех. Уже лет 5 назад на разных конференциях и во время круглых столов шли дискуссии о том, что пределом "бирюзовости" является организация в 50 человек. Что же пошло не так, почему сложно масштабироваться на бОльший объем?

✔️ Самоорганизация ≠ порядок - если в небольших командах еще можно отследить "серые" зоны и вовремя их закрывать, то в больших организациях можно легко упустить критически важные процессы из вида и никто их не закроет
✔️ Время = деньги - синхронизация кучи автономных команд требует бесконечного количества времени, т. к. у каждой команды свое видение "прекрасного"
✔️ Зрелость – редкий товар. Бирюзовость требует сознательных, мотивированных и ответственных сотрудников. Искать на рынке или выращивать внутри - долго и трудозатратно, а только на мотивированных и сознательных лидерах эту историю не вывезти
✔️ Децентрализация = отсутствие общего фокуса, а это означает отсутствие стратегии. Цели размываются, идеи конфликтуют, бизнес - стагнирует
✔️ Процесс превыше всего - еще одна проблема бирюзы. Фасилитации, ретроспективы, митапы, согласования это все важно, но забывается, что во главе коммерческих компаний стоит его величество P&L
✔️ Коллегиальность = коллективная безответственность. Сложные решения не принимаются, а если принимаются, то ответственность за них никто не несет

В общем сама идея - классная, но сложно реализуемая на практике. Если смотреть успешные кейсы, то все их объединяет одно - они эволюционны. Т.е. сама компания в своем развитии доходит до всех принципов бирюзовости и начинает их исповедовать, а не принципы бирюзовости появляются в ответ на желание руководства срезать затраты на менеджеров и иметь более продуктивных сотрудников.
#впоискахсеребрянойпули #цифроваятранформация #управление

О роли доставки в екоме вообще и на маркетплейсах в частности. Заказал на Озоне фильтр воды на дачу. Так получилось, что заказал с доставкой домой, не в ПВЗ. Ну бывает, соскочила рука. Фильтр должен был приехать 11 июня. Но что-то пошло не так и 11 числа заказ перенесли на 12. А 12 — это праздник, поэтому заказ я перенес на 15 июня. Ну и расслабился. А зря. Потому, что 15 утром заказ перенесли на 16. Ну камон. Учитывая, что окна доставки у Озона целый день, с 12 до 23 часов, сидеть дома и ждать, когда привезут фильтр было уже не але. Работать надо 🥲

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

Мысль, которую хочу подсветить - какая бы классная у вас ни была площадка, каким бы классным ни был бы ассортимент, но если вы не можете организовать внятную доставку, то результат будет печальным. Понятно, что для Озона этот кейс - атом в бесконечности. Но определенные выводы я сделал. С Озоном - только ПВЗ и только заказы, которые не критичны к сроку доставки. Если критично - буду искать в другом месте.
#еком #CJM #клиентскийопыт #логистика #доставка

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

Очень соблазнительно построить универсальную систему, которая сможет подстраиваться под любые изменения, которые могут или гипотетически могут возникнуть в будущем. Но нередко это желание приводит к тупику, известному как гиперуниверсальность (Misapplied Genericity) — ситуация, когда система становится чрезмерно абстрактной и обобщённой. Бывает, что гиперуниверсальность порождается желанием предусмотреть все и страхом, что требования изменятся или желанием сделать сервис "на века".

Например, вместо сервиса расчета бонусов, пишется:
🔜 сервис правил
🔜 конструктор акций
🔜 интерпретатор конфигураций
🔜 язык программирования для описания бизнес-логики (DSL - domain specific language)

Почему это плохо:
📌 Обобщенная архитектура это излишнее усложнение. Усложнение = время и деньги. Если это не нужно сейчас, то вы инвестируете в тех.долг (парадоксальненько, однако, но факт)
📌 Гиперуниверсальность это всегда конфигурация. А в конфигурации сложнее разобраться, чем в коде. Порог входа для новичков - выше
📌 Гибкие системы хуже поддаются изменениям, чем специализированные. Для изменения требуется понимать все уровни абстракции, что требует больше навыка и времени, чтобы разобраться
📌 Сомнительная бизнес-ценность. Бизнесу нужен функционал, а не потенциальная возможность расширения

Избежать этого антипаттерна легко - нужно строить сервисы на основании реальных, а не гипотетических кейсов. Если в дальнейшем будет сходные задачи, то можно сделать обоснованное изменение, обобщить новые кейсы. Но не наоборот.
Ну и классика - архитектура должна быть понятной. Особенно для тех, кто будет ее сопровождать….
#разработка #впоискахсеребрянойпули #цифроваятранформация #архитектура #антипаттерны

И снова про рынок труда. Помогает нам в этом опять ежемесячный отчет HH - Краткий рынок труда за май 2025.
Основное:
📌 hh индекс остался без изменений по сравнению с апрелем, все те-же 5.6 (соотношение количества активных резюме к количеству активных вакансий)
📌 Среднее число активных вакансий упало на 25% к уровню предыдущего года, а среднее число активных резюме выросло на 34%
📌 Среднее число активных вакансий и резюме снизилось на 5% по сравнению с апрелем

Если пройтись по ключевым для меня направлениям - ритейл и ИТ, то в сухом остатке имеем:
📌 В ритейле сохраняется острый дефицит кадров (hh индекс упал еще на одну десятую - 4.3)
📌 В ИТ дефицит вакансий вырос еще на 1 пункт (hh индекс 12.8 против 11.7 в прошлом месяце)
📌 Число вакансий в ИТ уменьшилось на 29% по сравнению с маем прошлого года
📌 Число соискателей увеличилось на 26% за тот же период
📌 Если в апреле число соискателей в ИТ оставалось на уровне марта, а число вакансий уменьшилось на 4%, то в мае число соискателей в ИТ уменьшилось на 3%, а число вакансий уменьшилось уже на 11%.

Резюме - нестабильность на рынке труда продолжается. Сохраняется дефицит вакансий в ИТ сфере и дефицит работников во многих других. ИТ-шное эльдорадо завершается.
От себя хочу добавить - скиловые спецы по-прежнему в цене. А вот те, кто рванул в ИТ за "длинным рублем" в условиях рынка кандидата, находятся под угрозой.
#подбор #разработка #development #управление #HR #development #рыноктруда #войтивит

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

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

Абстрактные примеры:
✔️ Ритейл. Известны компании, которые начали цифровую трансформацию с внедрения еком сайта, но не пересмотрели логистику, управление ассортиментом, клиентский сервис. Как результат - плохой клиентский путь, низкая удовлетворенность, потеря лояльности
✔️ Порталы цифровых услуг. Это не столько "оцифровка" документов, сколько выстраивание межведомственного взаимодействия, построение сквозных процессов и изменение точки зрения на получателя услуги, как на клиента
✔️ Промышленность. Датчики и устройства IoT это круто, но без адаптации производственных процессов и выстраивания системы принятия решений они не дают значимого прироста в эффективности

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

Что нужно для успешной трансформации:
🟢 KYC - поиск и определение клиента
🟢 Перестройка процессов под клиента
🟢 Обучение и вовлечение сотрудников
🟢 Готовность к изменениям на всех уровнях
🟢 Культура постоянного улучшения
🟢 И только после всего этого - выбор ИТ-инструментов.

Зафиналю - Цифровая трансформация это не "про цифру", а про способность меняться. А технологии это то, что помогает быстро и эффективно реализовывать изменения.
#разработка #цифроваятранформация #agile #development #продуктоваяразработка

Я часто пишу про эффективность команд. Давайте вспомним еще одного человека - Дж. Ричарда Хэкмана - который в 2002 году сформулировал модель Эффективной команды.
В результате своих исследований он вывел, при каких условиях команда работает максимально эффективно. Можно даже встретить информацию, что он за это получил Нобелевскую премию по экономике, но это не так - премию получил почти тезка - Джеймс Хекман и немного за другое.

Хэкман разработал модель пяти условий, которые определяют эффективность команды не только в плане достигнутого результата, но и по степени роста и удовлетворенности самих участников.
1️⃣ Четкая и убедительная цель. И тут почти по SMART - цель должна быть: ясной, значимой и вдохновляющей
2️⃣ Правильный состав команды - необходимые навыки и знания, готовность к совместной работе и эмоциональная зрелость, оптимально - 5-9 человек
3️⃣ Структура с четкими зонами ответственности и нормами взаимодействия, простые и эффективные рабочие процессы
4️⃣ Поддерживающая культура - компания должна помогать командам работать. Включает в себя доступ к необходимым ресурсам компании, поддержку руководства и систему поощрения
5️⃣ Развитие через обучение и наставничество. Обратная связь и рефлексия, обучение командной работе, помощь коучей, наставников и фасилитаторов

Начал он разрабатывать свою модель в 1975 году, совместно с коллегами исследуя связь между групповыми задачами, процессами и результатом. В 1983 году представил "критерии работающих команд" и далее больше 15 лет проводил исследования, которые легли в основу его книги, выпущенной в 2002 году.

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

Сегодня поразмышляем на тему рынка AI решений. После ухода иностранных вендоров российский рынок AI достаточно парадоксален - с одной стороны это технологические монстры рынка со своими "коробочными" решениями, а с другой - много мелких компаний с компетенциями и технологиями, но без законченных продуктов, только узкоспециализированными функциями.

Что произойдет в случае возвращения западных компаний на российский рынок? Смогут ли отечественные решения полноценно конкурировать или будут вытеснены? Может ли быть у российских AI решений своя "фишка", которая станет конкурентным преимуществом?

Я думаю да, если фокус в создании локальных AI решений будет в решении конкретных проблем на нашем рынке. Не европейских, не средних по Африке и Америке, а наших. Решения, заточенные под специфику языка, менталитета, отраслевых требований и законодательства будут выигрывать. У меня есть пример, не из мира AI, когда прекрасное решение для маркетплейсов Miracle, не могло составить конкуренцию российским "малышам" из-за своей ориентированности на европейский рынок (начиная с SaaS и хостеров и заканчивая коннекторами с логистическими компаниями).

Что пока тормозит развитие локальных AI решений:
🔵 Большинство решений остаются в статусе "полуфабрикатов" - технология есть, а полноценных продуктов с понятной бизнес-ценностью почти нет
🔵 Недостаток специалистов в области AI - не хватает подготовленных кадров
🔵 Все еще AI воспринимается как эксперимент, мало кейсов с четкой окупаемостью, поэтому бизнес не всегда готов инвестировать в технологию
🔵 Да и в целом - очень мало компаний, кто инвестирует в ИТ - как правило ИТ бюджет-это расходы, а не инвестиции

В итоге российский рынок AI сегодня находится на перепутье: есть хорошие наработки и понимание потребностей рынка, но для устойчивого роста необходимо превратить технологии в полноценные, масштабируемые продукты с доказанной экономической выгодой. Только это позволит отечественным решениям не просто удержаться, но и стать конкурентоспособными на фоне потенциальных конкурентов, используя свое главное преимущество - глубокую адаптацию под наши реалии.
#AI #ChatGPT #чтотампроchatgpt #data #данные #мнения

Недавняя шок-новость - В России разработан стандарт качества цифровой трансформации. На самом деле Минцифры, Цифровая Экономика и Роскачество начали его разработку давно. Сам стандарт датирован 2024 годом.

Документ призван унифицировать основные принципы и понятия, а также определить подходы и ожидаемые результаты компаний при реализации цифровой трансформации

В принципе правильно, а то цифровой трансформацией сейчас называется всё и вся. Порадовал факт, что в пункте 4.2 зафиксировано, что подход построен на цикле Деминга-Шухарта - PDCA. Всего стандарт выделяет шесть основных этапов цифровой трансформации:
1️⃣ оценка и анализ текущего состояния
2️⃣ стратегическое планирование
3️⃣ определение ключевых ресурсов
4️⃣ реализация запланированных мер
5️⃣ оценка полученных результатов
6️⃣ улучшение.

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

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

Ну и на сладкое - также выпущена Методика самооценки, где каждая организация может ответить на вопросы и понять свой уровень цифровизациии, что на мой взгляд очень полезно. Ну хотя бы чтоб не страдать иллюзиями. Но даже если вы не собираетесь в цифровую трансформацию или не собираетесь себя оценивать, то рекомендую прочитать список вопросов - там есть о чем подумать:
📌 В организации определены ключевые процессы, их интеграция между подразделениями и выявлены потребности в их оптимизации
📌 Организация адаптирует процессы в ответ на новые клиентские запросы или регуляторные изменения
📌 В организации внедрены методы управления качеством процессов
📌 Предпринимаются меры для поддержания мотивации и вовлеченности сотрудников в оптимизацию процессов
📌 ИТ-архитектура организации, ее цели и задачи соответствуют Стратегии цифровой трансформации
📌 Разработан план управления рисками, связанными с цифровыми технологиями
📌 Организован процесс управления изменениями, включая адаптацию бизнес-процессов к новым условиям и интеграцию новых решений с существующими системами

Понятно - вопросов там сильно больше, и все они даже не про цифровую трансформацию, а про современный бизнес, который уже немыслим без цифры. Как говорится - "…пойдете вы туда или нет, но он там будет…"
#разработка #цифроваятранформация #agile #development #продуктоваяразработка

Назрела необходимость завести новую рубрику - "Услышано в кулуарах". Недавно на одном из архитектурных комитетов услышал от оппонента фразу:

Вы сделали (отдельный) сервис потому, что не стали влезать в ядро системы

Если что, то для меня это прозвучало как похвала. Но я задумался, а все ли понимают, почему не надо лезть в ядро? Все ли осознают риски и принимают последствия? (*Дисклеймер - под системой здесь мы понимаем энтерпрайз систему, монолит, покупное решение)

Все банально. Ядро - фундамент, на котором всё держится. Любые изменения в ядре - это потенциальный каскад рисков:
📌 непредсказуемые побочные эффекты
📌 нарушение стабильности и быстродействия
📌 сложности при тестировании
📌 проблемы с безопасностью
📌 невозможность обновить версию системы без новых существенных доработок

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

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

Ох, обожаю я появление новых терминов. Особенно так любимых всеми ИТшниками аббревиатур из трех букв. В одном из каналов нашел ссылку на статью - "MVP vs MLP: почему минимально жизнеспособного продукта уже недостаточно в 2025 году" и очень хочу поразгонять на эту тему.

В мире стартапов назревает сдвиг: классический подход Minimum Viable Product (MVP) больше не гарантирует успеха... … на сцену выходит концепция Minimum Lovable Product (MLP): стратегия запуска, ориентированная на создание любимого продукта с первого дня.

Ну и дальше по списку - MVP уже не работает, потому что в 2025 году мало сделать просто рабочий прототип, нужно чтобы пользователи "влюбились в продукт с первого касания", поэтому MLP. Вспомнили про Эрика Риса и The Lean Startup (2011) и определили, что через 14 лет все это не работает потому, что:
✖️ Высочайшие требования к UX
✖️ Конкуренция во всех нишах
✖️ Технологии упростили создание
✖️ Первое впечатление - решающее

В общем складывается впечатление, что автор поста плохо читал или плохо понял Эрика Риса и все перепутал. По Lean Startup - MVP это про поиск. Поиск Problem - Solution Fit (соответствие решения проблеме) или Product - Market Fit (соответствие продукта рынку). А если надо сразу нарисовать почти идеальный CJM, то где во всей этой истории поиск? Такое ощущение, что стартапер должен уметь сразу безошибочно заполнить все поля на канвасе, чтобы сразу продукт получился.

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

Складывается ощущение, что автор попутал терминологию и назвал POC - MVP, а MVP - MLP. Ну или продажи MVP пошли вниз, поэтому надо срочно придумать новое название для старого термина, чтобы поднять продажи.
#гибкиеметодики #продуктоваяразработка #leanstartup #впоискахсеребрянойпули

Пришел к мысли, что надо продолжить писать свои Записки программиста, и вот что получилось:

Записки программиста. День 417.
Сегодня в ТЗ появилась новая строчка:

Приложение должно быть удобным.

Не быстрое. Не безопасное. Не стабильное. Просто, *ука, удобное.
Я почувствовал себя как в том анекдоте: "Доктор, у меня что-то болит где-то вот тут…"

Начал искать, что заказчик имел в виду.
Спросил: - А что значит "удобное"?
Ответ: - "Ну чтобы человеку приятно было... пользоваться".
Ну круто, теперь всё ясно. Надо вставить в код usePleasure() и autoUserSatisfaction(true).

Ладно, на фиг, решил перевести это на технический.
Применил поверхностные навыки глубинного интервью:
🟢Для кого удобно? (новичок, эксперт, бабушка?)
🟢На чём удобно? (телефон, планшет, холодильник?)
🟢В чём удобно? (скорость? структура? кнопки с душой?)

Ответ был неожиданный, ну как в том фильме про 7 перпендикулярных линий: "Ну вы же профи, вы же понимаете".
Понял. Пошёл ставить темную тему и анимации - беспроигрышный вариант, когда говорим про удобство.

В итоге написал требования сам:

Основные сценарии (регистрация, заказ, оплата) должны занимать не более 3 шагов и проходить без ошибок у 95% пользователей по данным аналитики

Отправил заказчику. Он одобрил - "Да, да, вот теперь прям удобно"
В общем теперь каждый раз, когда вижу "удобно", сразу думаю: удобно кому, когда, и почему это опять моя проблема. В общем - если в ТЗ написано "удобное приложение" - это не требование, это из области метафизики. Будьте осторожны, там рядом обычно бродит "интуитивно понятно" и "должно просто работать".
#антипаттерны #управление #разработка #никогдатакогонебыло #шуткаюмора

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

Поехали:
1️⃣ Монолитный образ мысли. Делаем микросервисы, как привыкли делать монолитные приложения - сильная связанность, взаимозависимости сервисов, ограниченная автономность. Забываем про нормальное масштабирование, отказоустойчивость и высокую нагрузку
2️⃣ Монолит данных. Много сервисов, а БД - одна. Возникает жёсткая связь по данным, получаем сложности с согласованностью и узкие места по производительности
3️⃣ Болтливые сервисы. Чрезмерный обмен сообщениями между сервисами приводит к перегрузке, высокой задержке и повышенному использованию ресурсов
4️⃣ Неверно определенные границы сервисов. Либо сервисов мало - мегасервисы, либо слишком много - излишняя декомпозиция и микросервисный ад. И в том, и в другом случае получаем хаос, идем решать сложности с разработкой, тестированием и выкаткой
5️⃣ Расползание сервисов. Много сервисов без четкого контроля и управления. Все бесконтрольно создают сервисы - забываем о том, чтобы хоть что-то понимать в нашей архитектуре и направлении нашего движения
6️⃣ Отсутствие agnostic подхода. Мы верим в K8S или в BareMetal или в Managed services от нашего облачного провайдера и сильно удивляемся, когда все наше решение оказывается прибито гвоздями к конкретной реализации
7️⃣ Игнорировать observability и удивляться, что система нестабильна, время восстановления растет, контроль - утрачивается

Что со всем этим делать? Если вы увидели что-то вам знакомое, значит скорее всего вам не показалось. Пока все не разъехалось в разные стороны надо остановиться, провести аудит того, что уже наделали, внедрить архитектурный надзор или контроль и уже идти дальше, стараясь не допускать нарушений. Микросервисы - классная технология, но ее надо уметь готовить и понимать, зачем именно вам она нужна? Какие ваши вопросы она решает? И все будет хорошо.
#архитектура #development #разработка #платформы #впоискахсеребрянойпули #антипаттерны