Comments 22
Больше всего замедляет разработку вакханалия наращивания функционала, практически не нужного. Тут в соседней статье утверждали про 15000 серверов на Авито. Сразу вопрос: зачем.
Представьте себе приложение Яндекс.Еда, в котором восемьсот магазинов и служб доставки. Как сделать так, чтобы это работало как единое целое?» — продолжает Сахаров. «Я просто не могу представить, как пятьсот команд должны работать в распределенном режиме с такой нагрузкой, которую испытывают большие банки, Яндекс, Ozon и другие крупные компании. Как это решить в монолите с тестированием обратной совместимости, с тестированием всего регрессионного функционала, с отсутствием конфликтов между командами, с единым интерфейсом, с единым пользовательским опытом и еще с отсутствием падений при обновлении какого-то маленького кусочка?
Ну давайте вместе подумаем.
Утверждающий не умеет в нормальный, правильный монолит.
Яндекс.Еда — это не 800 независимых сервисов, а скорее модульная система с четким разделением ответственности. На практике там:
1. API Gateway для партнёров (рестораны/доставка) — стандартизированный протокол, не 800 разных
2. Core-домены (заказы, платежи, логистика) — их немного, они стабильны
3. Адаптеры для интеграций — изолированы от ядра
В Сбере сотни команд работают над единой платформой через:
- Контракты между модулями (не микросервисами!)
- Feature toggles для постепенного выката
- Библиотеки shared-компонентов для UI консистентности
- Blue-green деплой целиком, а не по кускам
Реальная проблема не "монолит vs микросервисы", а организация команд. Amazon решает это через "two-pizza teams" с четкими API между ними — неважно, монолит это или сервисы.
Модульный монолит (на Java, c#) с хорошими границами проще масштабировать организационно (до определенного предела, которого я на практике не встречал), чем распределённую систему с неявными зависимостями. См. про "модулиты".
ИТ руководители Авито, Озон задрали планку сложности выше нужного чтобы показать свою значимость и дуют в уши бизнесу о своей незаменимости
Практика копирования опыта у старших товарищей типа Гугл приводит к усложнению и карго культу. Хотя, без опыта, наверное, страшно идти, создавать своё. Проще копировать, сохраняя ненужную сложность
Проблема в том, что видят решение, а не путь к нему. Amazon пришёл к микросервисам после 10 лет монолита, когда уперлись в конкретные проблемы. А не "начали сразу правильно".
Вот и Авито создал свой Амазон, такой же сложный, только без его денег
ну и разумеется если просто поднять флаг мы типа тут все делаем на MSA и значит нас ждет успех - это прямой путь в никуда. MSA требовательна гораздо серьезнее чем монолит. Мы это хлебнули в полный рост и именно поэтому сделали платформу и кучу архетипов и типовых библиотек для решения огромного количества рутинных задач для того чтобы не утонуть в океане создаваемых микросервисов
Тут сложно не согласиться. Конечно же ситуация гораздо более сложная, чем просто монолит или микросервис. Разумеется много слоев всего и правильная организация команд и правильный devops и правильный sdlc в целом. Разумеется грамотные люди могут организовать эффективную работу в любой архитектуре
Критерий выбора предельно прост и прагматичен.
«Если очень нужен микросервис на Node.js, тогда мы его используем. Это как последняя опция. Это когда мы все остальное перепробовали, и у нас получается, что микросервис — это все еще лучшее решение из возможных. Вот тогда мы его делаем», — говорит он. «Когда все остальное хуже, тогда делаем микросервис», — резюмирует Евсеев.
Вот интересно а что это все остальное что перепробовали? 15 вариантов монолитов построили? Монолиты так быстро строятся? Так критерий-то в чем? Что было хуже и чем, из того что попробовали? Как оценить что хуже, а что лучше?
По моему это просто критерий выбора названия того что получилось при разработке. Типа: "Как назовем эту заплатку? Какие у нас варианты: микросервис ..долгая пауза.. а все остальное хуже! Ну точно, пусть называется микросервис!"
Для примера, вот что можно делать вместо микросервисов:
Подключить готовую библиотеку
Написать свою библиотеку
Написать свой фреймворк -- тоже библиотека, но особенная
Решить проблему на стороне фронтенда
Уже на старте разработки монолита декомпозировать его на подсистемы
Реализовать фичу на стороне другого продукта
Вариантов не так уж и мало. Есть из чего выбирать.
ну наш ответ простой - если люди просто говорят "микросервис", то они скорее всего не понимают , что говорят. MSA тянет за собой и devops и инфобез и производительность и оркестрацию и кучу еще всего, что должно решаться на базе какой-то платформы
По данным на 2024 год, среднесписочная численность сотрудников ООО «Диасофт» — 1735 человек
Если вычесть непроизводственный персонал (HR, бухгалтерия, продажи, админы) - остаётся ~1200-1300 в разработке, человек 800 разработчиков, остальные девопс, аналитики, тестировщики. При 200 командах получается 4 человека на команду.
Возможные объяснения:
"Команда" = проект для конкретного банка. Тогда одни и те же люди в нескольких "командах"
Считают подкоманды (backend, frontend, QA отдельно)
Two-pizza teams по Безосу - намеренно дробят для автономности
И независимых продуктов, видимо, несколько. 4-5 монолитов или продуктов с числом отдельных доменов до 20 на продукт.
Вывод:
Вы опять создаёте себе трудности на ровном месте
мы всего лишь делимся опытом и практикой и обсуждаем ее с коллегами. Разговоры показывают что "трудности на ровном месте" возникают у всех и имеет смысл их обсуждать совместно, чтобы не наступать на грабли. у нас 2500 человек и примерно 6-7 человек на команду, команды полнофункциональные работают в методологии Fusion teams от Gartner на основе концепции "цельной упакованной бизнес функциональности" (PBC). Переход на работу в этом режиме позволило нам в несколько раз повысить эффективность работы по сравнению с тем режимом когда мы работали в монолите. Навреное можно было бы этого добиться и в монолите, но опыт крупных компаний показывает, что на практике это мало у кого получается, потому что такие крупные заказчики как Альфа, ВТБ, Сбер, ПСБ, ТБанк, Уралсиб и другие перешли на эти же подходы
6-7 человек на команду
Это только разработчики или включая аналитиков, тестировщиков? В любом случае, команды небольшие или совсем небольшие.
Как меряли повышение эффективности? Стало меньше разработчиков, но больше девопсов это не повышение эффективности
Подождите, а стек то какой?
Если PHP/Go то понятно. Языкам с коротким жизненным циклом нужен внешний супервайзер и микросервисы как решение именно этого, а вовсе не вопросов масштабирования или организационной сложности.
Lifecycle-Driven Architecture:
Не чиним баги. Быстрее умираем
Не управляем ресурсами (почти). Ограничиваем память. Рестартуем по расписанию
PHP: Умру через 30ms, память почищу
// 1 сервис = 1 endpoint = 1 файл
Go: Умру через 100MB RAM, можно не параноить за ресурсами и дедлоками
// 1 сервис = 3-5 endpoints = 1 redeploy unit
Зачем искать дедлоки если можно просто умереть и рестартить зависшее быстрее, чем пользователь заметит?
Грамотные люди, объясните как называется архитектура САПа в системе координат монолит-микросервис?
Модульный монолит с элементами SOA.
Ключевые признаки:
- Общая БД (всё в одной Oracle/HANA)
- Модули (FI, CO, MM, SD) деплоятся вместе
- Транзакционная целостность через общее ядро
- Но модули относительно изолированы через ABAP interfaces
они не вместе деплоятся. то есть с дистрибутива вместе разворачиваются, но в принципе можно любую кнопочку деплоить независимо. Можно одну букву в коде поменять, завернуть в перенос и деплоить независимо. Фактически каждый функциональный модуль - это отдельный наносервис, который можно развернуть независимо. При этом да, все работают на одной БД.
Примерный список по РФ, где масштаб/организация обычно оправдывают микросервисы (по публичным докладам, вакансиям, кейсам):
Экосистемы/мультипродукт: Яндекс, VK, Сбер
Маркетплейсы/ритейл (сомнительно): Ozon, Wildberries, X5 Tech (Пятёрочка/Перекрёсток), Магнит Tech
Банки/платежи: Тинькофф, Альфа-Банк, ВТБ, НСПК (МИР/СБП), другие банки топ-10
Телеком/инфраструктура: МТС, Мегафон, Билайн, Теле2, Ростелеком (в т.ч. РТ Лабс/Госуслуги)
Классифайды/HR (сомнительно): Авито, HeadHunter (hh.ru)
Карты/навигация: 2ГИС
Облака/платформы: Selectel, Cloud.ru (экс SberCloud)
Медиа/стриминг: Okko
(?)Газпром/Газпром нефть:
Платформы сбора телеметрии с месторождений, предиктивная аналитика оборудования, цифровые двойники
(?)РЖД:
Пассажирские сервисы: билеты, личный кабинет, мобильные приложения, уведомления, лояльность
Вы нашлись в этом списке?
Везде и всегда надо работать головой и исходить из практической целесообразности.
Начинать проект надо с монолита, но правильно написанного. максимально изолированные слабосвязанные модули, которые общаются между собой событийно, асинхронно и так далее. Тесты, документация - все должно быть правильно.
А вот когда размер превысит определенный порог, то у вас начнется органическое деление на микросервисы. но 90% проектов до этого просто не дойдут - хватит монолита за глаза для решения задач бизнеса.
это действительно так. Но на практике бывают ситуации, когда на самых ранних стадиях нет достаточно грамотных людей в команде, поскольку все грамотные предпочитают работать на стабильных позициях в крупных компаниях, а в стартапы и новые направления идут молодые и смелые, за что им почет и уважение!=)
Микросервисы vs Монолиты: что на самом деле ускоряет разработку