Комментарии 16
Недешёвый инструмент управления сложностью и чуть чуть масштабируемостью
Мой опыт разработки в "кровавом энтерпрайзе" показывает, что чуть ли не единственное реальное удобство использования микросервисов не технологическое, а организационное - с ними проще "отвязывать" релизные циклы команд друг от друга. Остальные декларируемые удобства за свои 25 лет разработки не встречал почти никогда:
1) Разный техстэк? Возможно, но крупной организации логично его унифицировать во избежание бардака.
2) Независимое масштабирование и изоляция нагрузки? Хороший аргумент, но на практике стараются закладывать ресурсы с запасом и ставить ограничители частоты запросов на всё что можно ради выполнения SLA, подписанного кровью перед бизнесом.
Если очень надо разделять части функциональности, можно сделать несколько "систем", а не "микросервисов". Технически разница небольшая, хотя могут быть нюансы с точки зрения производственного процесса компании (например, системы могут требовать специального учёта и согласования, а микросервисы нет). Но опять же, это не про технологию, а про управление процессом разработки.
Разный стек это когда монолит легаси на PHP и нового туда не пишут, только старое. А микросервисы на Go.
Лично я видел распределенную архитектуру только в географически распределенных системах, да и там это была архитектурная ошибка.
организационное - с ними проще "отвязывать" релизные циклы команд друг от друга
В разных языках по разному. C# например позволяет быструю инкрементальную сборку, быструю проверку стат анализаторами только изменившегося модуля (DLL) и даже внутренние долгоживущие сервисы. И нафиг ещё микросервисы надо. А PHP никаких гарантий изоляции не даёт, фреймворки и настройки вмешиваются во всю программу
Однажды столкнулись с проблемой узкого канала у заказчика при использовании распределенной системы при переносе данных из одного репозитория документов в другой.
Консультанты не выяснили что канал между серверами старого и нового репозитория узкий, около мегабайта в секунду, использовался для небольшого трафика. А тут мы по нему погнали сотни млн документов.
Повезло что приложение можно было резать на части (kafka streaming api) с заглушками в файловой системе ( дерево папок с метаданными и контентом).
Второе хорошо что небольшое расстояние, километров 20 - возили хард как Амазон дата трак с дисками....
Хорошая статья, спасибо за перевод.
И ни слова про ИИ. Лично для моих проектов выбор в пользу микросервисов был обусловлен контекстным окном нейронки. Как ни странно нейронки вполне себе успешно переваривают весь микросервис и умудряются писать самостоятельно простой функционал.
Плюс очень просто стало искать исполнителей на фрилансе. Не нужно вводить исполнителя в курс дела проекта. Даётся тз на несколько простых функций без необходимости вводить исполнителя в контекст проекта.
"Самое большое преимущество монолитов в простоте их развёртывания." удивительно как эта байка о простоте развёртывания монолита гуляет так долго. Наверное это для приложений: фронт->бэк->база без связей с другими системами. Если ваш монолит это база на несколько терабайт обвешанная сервисами разной степени мутности как новогодняя ёлка с кучей интеграций, то развёртывание этого монолита станёт весёлым и затейливым квестом.
Был у меня в соседней группе монолит - всем монолитам монолит... Конфиг XML на сотни строк, с кросс ссылками, коннекторами в репозитории, вьюверы и тд. Само приложение тоже неудобное - часть модулей мавен отключено в дефолтном профайле, по коду ничего не найти если не знаешь где. "Метастаза" было бы хорошим названием этому приложению.
Я упирался руками и ногами чтоб не делать что либо в этом проекте - проблема не в коде сделать фикс а проверить билд...
Ни слова о k8s, только докер упомянут. А между прочим, микросервисы без k8s теряют смысл.
И ещё плюс микросервисов, не упомянутый никак: в случае ошибки в коде монолита, можно получить нерабочий весь монолит (например, логинится юзер и видит белый лист из-за 500 ошибки в коде функции которая данные из таблички выгребает), в то время как в микросервисной архитектуре ляжет лишь конкретный микросервис (и условно вместо белого листа у юзера будет почти весь интерфейс и белый прямоугольник там где функция должна была вернуть данные для отрисовки графика)
Наконец, пример из жизни: ребята не могут вылить в деплоймент код api сервера, потому что в имеющейся админке монолита который api реализует есть уязвимые сторонние библиотеки, хотя они не используются в работе api и нужен секс по обновлению зависимостей для успокоения анализатора уязвимостей. В случае архитектуры микросервисов, api был бы независим от админки, что упростило бы выкладку.
Полстатьи про то, что важна скорость разработки на машине конкретного разраба. А в этом случае docker-compose рулит, а k8s вот совсем не рулит
Нет, я работал в разных местах, в том числе и там где рабочий энв был уже в облаке (разными способами) и всё делалось на сервере
Но проще compose
Если проект - одиночный небольшой сервис вокруг базы данных, то да, а если это проект в котором десяток различных составляющих, неочевидным для данного программиста образом взаимодействующих, он кукухой тронется, пытаясь поднять локально функционирующую копию всего сервиса в докере.
Иными словами, микросервисная архитектура хороша там, где у проекта много составляющих, которые делают разные люди. Каждый из них знает свою часть и может её прогнать на своём локальном компе в примитивной установке (банально curl'ом руками попинать), не пытаясь запустить весь комбайн.
Монолит практически невозможно распараллелить, то есть пилить его в два-три-четыре рыла в одном и том же куске проекта, монолит может пилить один, максимум два человека. Например, один фронтэндщик и один бэкендщик.
Так статья называется "Издержки микросервисов, которые ваш стартап может не потянуть"
Обычно это небольшой проект и там немного народу.
Да и модульный монолит вполне можно пилить человек в 5 только бэков, например, если в разных углах пилить.
Да и модульный монолит вполне можно пилить человек в 5 только бэков, например, если в разных углах пилить.
Ага, но вскоре начинаются проблемы совместимости разных третьесторонних модулей, потому что Вася использует приблуду завязанную через зависимости на некий плагин энной ветки, а Петя ветки эн плюс эм, и в зависимости от версии, впиленной в монолит, не работает либо Петин код, либо Васин :)
Или другой вариант - скажем, код Пети работает на nodejs v.18 и ниже, а код Васи не может работать ниже чем на nodejs v.20, и либо Пете надо переписывать почти весь свой код, либо Васе нужно придумывать костыли...
Тоже хотел сказать, что оркестрацией почти все проблемы из таблички решаются просто запретом ручного деплоя и как следствие - использованием чего то типа k8s и прочих терраформеров.
Кстати никто ге мешает сделать вариант композа удобного для локальной разработки и конфигов для энтерпрайзы, особенно если деплой идет через ci всегда.
Если бы создатели StackOverflow считали микросервисы “правильным путем”, у нас бы не было StackOverflow. Как один из примеров, что у всех на виду.
Издержки микросервисов, которые ваш стартап может не потянуть