Так я не фантазирую. Я вам описываю реальную ситуацию.
Она реальна только для вас и только в вашей предметной области она может иметь более 80-90% наличия (возможно из-за специфичного оборудования и тд). Сейчас основные микросервисёры/распределёнщики - это веб и saas, там, где неконтролируемая сетевая нагрузка! А я имею ввиду именно эту область.
Ну так что делать если в теории практически 99% кода могут словить такую зависимость? Что куда выносить? Как организовать архитектура чтобы в каждом новом проекте можно было переиспользовать как можно больше базового кода?
маргинальные/форточные/и всякие остальные "тех.стеки" - в отдельные окружения с интерфейсами и докером (удобство, тормознутость) либо microvm (скорость/безопасность). Свои - в библиотеки. Всё просто!
Не проще тогда построить инфраструктуру на микросервисах, написать "стандартные" сервисы для всего что надо и потом только по необходимости менять отдельные сервисы на проприетарные решения в отдельных проектах?
Боюсь нет. Не вгоняйте компанию в долги, если имеете чуточку ответственности перед работадателем. Лучше почитайте правильную лит-ру а не хабр.
> В-третих - только нагрузки - объективная причина появления таких архитектур.
Это вы сейчас сами придумали?
Нет, не сам. Просто всё остальное действительно можно решить без микросервисов! А вот нагрузку уровня Вайлдберриз - вряд-ли.
Во-первых - не фантазируйте! Такие зависимости появляются крайне редко.
Во-вторых - такие зависимости как-раз таки можно вынести в отдельные окружения, заставить общаться по апи и жить с этим.
В-третих - только нагрузки - объективная причина появления таких архитектур. Веб и Нетфликс всему виной! Все остальные вопросы можно так или иначе решить без распределения.
Из-за сторонних зависимостей приходится использовать абсолютно разные тех-стеки.
Работать разные части кода должны на разном железе. Причём так что одна часть на винде, другая на соседней машине на линуксе, третья интегрируется в какой-нибудь TestStand, а четвёртая запускается в эмбеддед-окружении на каких-нибудь датчиках или производственном железе.
То, что должно работать в таком окружении - пусть в нем и работает. В остальном - монолит)
Работать разные части кода должны на разном железе. Причём так что одна часть на винде, другая на соседней машине на линуксе, третья интегрируется в какой-нибудь TestStand, а четвёртая запускается в эмбеддед-окружении на каких-нибудь датчиках или производственном железе.
Так похоже вы сами себе и сделали подобный винегрет) а потом за уши притягиваете микросервисы/распределенные архитектуры. Так и живите с ним "счастливо". Я говорю о среднестатистическом веб-приложении, ибо в "коробке" о микросервисах даже и говорить не приходится)
Часть функционала пишется не нами, а самими клиентами или нашими партнёрами или даже просто отдаётся на аутсорс.
Библиотеки не пробовали? :D Так написан весь линукс) Остальное - частные случаи, которые редко встречаются в разработке и в данном контексте просто не применимы.
Еще раз - микросервисы дороже математически - не спорьте!!!
Это не значит что во всех остальных случаях они не нужны.
Перечислите.
Раздельный деплой? Деплойте весь монолит - это возможно.
Работа с репой нескольких команд? Организуйте исходники, используя DDD, домены и ограниченные контексты - и вы будете пересекаться именно в тех случаях, когда зависимости необходимы - это сигнал для "события предметной области". И да - монорепа - это благо.
Вам нужно масштабировать нагрузки? В правильном монолите это решается поднятием уровня изоляции с потока/корутины до процесса/контенера.
Вот и все плюсы микросервисов решены в монолите.
Монолит вам создаёт кучу проблем, потому что вы не умеете всё вышеперечисленное.
Тут где то написали - если у вас бизнес масштаба Вайлдберриз - то микросервисы необходимы. Но в 95% случаев - это не так. Предположу, что у вас это тоже не так (хотя могу ошибаться) и все ваши сервисы только лишь приносят боль. Не вам - компании!
А для меня это очень зависит от ситуации. И в некоторых ситуациях микросервисы даже дешевле будут.
Это математически невозможно. Вы простой вызов метода заменяете сетевым взаимодействием.
Возьмите не квалифицированную и не добросовестную команду и попробуйте написать и поддерживать монолит на миллион строк кода.
Для монолита нужны просто программисты. Для микросервисов нужна гораздо более квалифицированная команда, для меня это очевидно. И кол-во строк кода будет в микросервисах гораздо больше, нежели в монолите. Вам нужно будет всё это сетевое взаимодействие выразить в коде.
Вы про моки ничего не слышали?
Еще как слышал, про моки и стабы, котрые нужно писать - это деньги. И в случае юнитов вы тестируете только код, но не то кол-во логики, которое вынесено на уровень инфраструктуры.
Вообще смешной аргумент. Ну не используйте докер если видите в этом проблему.
Я сказал "если" - а их, как правило и используют, не понимая, что это несет для компании. Прочитайте внимательно, что я написал.
Это и в монолите надо делать.
Только в случае внешних взаимодействий. Всё.
Я вам так скажу: микросервисы существуют гораздо дольше. Только их далеко не всегда называли микросервисами :)
Так я об этом и написал! И это всегда была боль ради распределения нагрузки.
Для меня порядки цены разработки очевидны - это минимум x3. Более того у меня огромный опыт работы и с тем, и с тем. Когда вы вместо простого вызова функции/метода начинаете городить всё вышеописанное в статье, то вам:
Нужна очень квалифицированная и добросовестная команда; скорее всего их несколько, ибо гонять сообщения/вызовы api самим себе по пять раз за запрос вот вообще смысла нет;
Удорожается отладка - вам нужно делать тестовые стеки из набора связанных микросервисов, потому что их десятки и они связаны; тестировать один сервис отдельно вы можете в самом начале его разработки, ибо потом он обрастает зависимостями и вам нужен будет стек и да, юнит-тесты уже не канают или это моковые монстры; в монолите - запустили инстанс, прогнали функциональные/интеграционные тесты - всё!
Не дай бог вы в качестве дефолтной изоляции для микросервисов используете докер - тут вообще всё плохо ибо это все еще теперь надо билдить и пайплайны будут идти часами. Цена ошибки и внедрения новой фичи в таких случаях очень велика, как и кол-во ресурсов на инфру (оно огромно) ну и конечно эмоции разработчиков! Не забудьте, что билдить надо будет так же и для того, что бы просто запустить интегр. тесты на стеке - а это то время, когда вы не можете работать с исходниками
Если вы не хотите репутационных проблем - вам ОБЯЗАТЕЛЬНО нужно будет делать всё, что описано в этой статье, а это далеко не для новичков;
Все апишки, контракты взаимодействия между сервисами нужно будет описывать и держать их в актуальном состоянии; мультиверсионность - та еще боль! ... я могу продолжать дальше, но работа ждёт)
Я вам так скажу. Раньше, где-то до появления докера (до середины 10ых), такие продукты были только у компаний с огромными нагрузками, изоляциями типо jail (FreeBSD, первая) и LXC (linux, позднее) и инфы про такие системы было мало, ибо это были их конкурентные преимущества, а в отрасли было чёткое понимание того, что когда ты выходиш из общего адресного пространства, да и ещё имеешь нагрузки выше среднего, ты получаешь возможность масштабировать и терминировать эту нагрузку, но тебе нужно будет обеспечивать целостность разделяемых ресурсов между разными окружениями, а это как в многопоточном приложении - самые трудноуловимые ошибки и даже сложнее - в многопоточке у тебя общее адресное пространство и там ты можешь использовать ipc примитивы а в микросервисной - всё гораздо жёсче. Так что как-то так, коллега)
Вы просто пройдитесь по плюсам микросервисов и вам будет всё понятно. Это Архитектурная преждевременная оптимизация по Кнуту.
Любую концепцию, прежде чем использовать, надо понять. ООП сложнее в изучении, чем процедурный подход, но профит от его использования на масштабных проектах - очевиден.
Ну успехов распараллелить раст на 100К [грин]тредов. Или в кластер из 50 машин. Мы же все еще про энтерпрайз?
Энтерпрайз так решил, потому что деньги! А все ваши приведенные вопросы - мало имеют отношения к предмету и местячковы по масштабам планеты.
У гугла энтерпрайз? Что ж они голанг-то тогда втаскивают всеми силами?
Гугл сделали молоток с рюшечками что-бы джуниорам было просто код писать - они об этом прямо говорят, а не от того, что он процедурный. Почему программисты с опытом клюют на это - для меня лично непонятно, но маркетинг у них хороший, да. Про себя скажу, что для таких задач я выбираю rust и радуюсь.
А еще раньше весь энтерпрайз был на коболе, причем даже тогда, когда уже существовали ООП языки. С этим как быть?
Все так. И все вот эти неодушевленные предметы - это обычные value object, обычно не имеющие поведения и прекрасно ложащиеся на концепт ООП+DDD ) а то, что у вас функции сбоку, так это добавляет сложности, так как у вас теперь методы "обезличены" (или всё-таки нет?) и во-первых вам нужно их куда то осмысленно класть в исходниках, во-вторых в этих функциях теперь вам нужно понимать, какой объект у вас на входе. И, не забывайте, в ООП тоже есть функции вообще-то. И никто не запрещал их использовать)
Да, именно об этом и речь. Делать большие проекты с кучей абстракций, предметных областей и прочее будет гораздо сложнее с функциональным образом мышления, ибо сама реализация подобного функционала будет все равно подталкивать вас к ООП парадигме, потому что мозг не обманешь - ему так проще) и не успеете оглянуться, как начнете реализовывать "интерфейсы, фабрики и представления"
И мне странно, что «наполнить чаем» в случае кружки — это почему-то метод кружки. Так-то насыпать заварку и залить кипяток можно и в банку, бутылку, бочку, рот.
И вообще, у вас довольно странное абстрактное мышление) С чего вы вообще взяли, что метод наполнения кружки должен лежать в классе кружка? Если вам по бизнес ложике важен процесс наливания чая, то вообще этот процесс инициирует не кружка, а вторая абстракция, которая собственно это делает. Всё как в жизни, не так ли?
Вот вообще не хочу погружаться в "мир техдолгов"! Я там уже был)
Кажется, что Домке слишком воодушевился или преследует свои интересы. Тут вот METR исследования провел и пишет, что замедляет работу https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/ . Предполагаю, что из-за того, что проверять за ним нужно, корректировать код.
Она реальна только для вас и только в вашей предметной области она может иметь более 80-90% наличия (возможно из-за специфичного оборудования и тд). Сейчас основные микросервисёры/распределёнщики - это веб и saas, там, где неконтролируемая сетевая нагрузка! А я имею ввиду именно эту область.
маргинальные/форточные/и всякие остальные "тех.стеки" - в отдельные окружения с интерфейсами и докером (удобство, тормознутость) либо microvm (скорость/безопасность). Свои - в библиотеки. Всё просто!
Боюсь нет. Не вгоняйте компанию в долги, если имеете чуточку ответственности перед работадателем. Лучше почитайте правильную лит-ру а не хабр.
Нет, не сам. Просто всё остальное действительно можно решить без микросервисов! А вот нагрузку уровня Вайлдберриз - вряд-ли.
Во-первых - не фантазируйте! Такие зависимости появляются крайне редко.
Во-вторых - такие зависимости как-раз таки можно вынести в отдельные окружения, заставить общаться по апи и жить с этим.
В-третих - только нагрузки - объективная причина появления таких архитектур. Веб и Нетфликс всему виной! Все остальные вопросы можно так или иначе решить без распределения.
На этом заканчиваю. Спасибо!
То, что должно работать в таком окружении - пусть в нем и работает. В остальном - монолит)
Представьте себе, в большинстве случаев - да!
Так вы микросервисы на производственных линиях используете? Без каких либо нагрузок? :big beautiful facepalm:
Так похоже вы сами себе и сделали подобный винегрет) а потом за уши притягиваете микросервисы/распределенные архитектуры. Так и живите с ним "счастливо". Я говорю о среднестатистическом веб-приложении, ибо в "коробке" о микросервисах даже и говорить не приходится)
Библиотеки не пробовали? :D Так написан весь линукс)
Остальное - частные случаи, которые редко встречаются в разработке и в данном контексте просто не применимы.
Еще раз - микросервисы дороже математически - не спорьте!!!
Перечислите.
Раздельный деплой? Деплойте весь монолит - это возможно.
Работа с репой нескольких команд? Организуйте исходники, используя DDD, домены и ограниченные контексты - и вы будете пересекаться именно в тех случаях, когда зависимости необходимы - это сигнал для "события предметной области". И да - монорепа - это благо.
Вам нужно масштабировать нагрузки? В правильном монолите это решается поднятием уровня изоляции с потока/корутины до процесса/контенера.
Вот и все плюсы микросервисов решены в монолите.
Монолит вам создаёт кучу проблем, потому что вы не умеете всё вышеперечисленное.
Тут где то написали - если у вас бизнес масштаба Вайлдберриз - то микросервисы необходимы. Но в 95% случаев - это не так. Предположу, что у вас это тоже не так (хотя могу ошибаться) и все ваши сервисы только лишь приносят боль. Не вам - компании!
Это ваши фантазии.
Это математически невозможно. Вы простой вызов метода заменяете сетевым взаимодействием.
Для монолита нужны просто программисты. Для микросервисов нужна гораздо более квалифицированная команда, для меня это очевидно. И кол-во строк кода будет в микросервисах гораздо больше, нежели в монолите. Вам нужно будет всё это сетевое взаимодействие выразить в коде.
Еще как слышал, про моки и стабы, котрые нужно писать - это деньги. И в случае юнитов вы тестируете только код, но не то кол-во логики, которое вынесено на уровень инфраструктуры.
Я сказал "если" - а их, как правило и используют, не понимая, что это несет для компании. Прочитайте внимательно, что я написал.
Только в случае внешних взаимодействий. Всё.
Так я об этом и написал! И это всегда была боль ради распределения нагрузки.
Для меня порядки цены разработки очевидны - это минимум x3. Более того у меня огромный опыт работы и с тем, и с тем. Когда вы вместо простого вызова функции/метода начинаете городить всё вышеописанное в статье, то вам:
Нужна очень квалифицированная и добросовестная команда; скорее всего их несколько, ибо гонять сообщения/вызовы api самим себе по пять раз за запрос вот вообще смысла нет;
Удорожается отладка - вам нужно делать тестовые стеки из набора связанных микросервисов, потому что их десятки и они связаны; тестировать один сервис отдельно вы можете в самом начале его разработки, ибо потом он обрастает зависимостями и вам нужен будет стек и да, юнит-тесты уже не канают или это моковые монстры; в монолите - запустили инстанс, прогнали функциональные/интеграционные тесты - всё!
Не дай бог вы в качестве дефолтной изоляции для микросервисов используете докер - тут вообще всё плохо ибо это все еще теперь надо билдить и пайплайны будут идти часами. Цена ошибки и внедрения новой фичи в таких случаях очень велика, как и кол-во ресурсов на инфру (оно огромно) ну и конечно эмоции разработчиков! Не забудьте, что билдить надо будет так же и для того, что бы просто запустить интегр. тесты на стеке - а это то время, когда вы не можете работать с исходниками
Если вы не хотите репутационных проблем - вам ОБЯЗАТЕЛЬНО нужно будет делать всё, что описано в этой статье, а это далеко не для новичков;
Все апишки, контракты взаимодействия между сервисами нужно будет описывать и держать их в актуальном состоянии; мультиверсионность - та еще боль! ... я могу продолжать дальше, но работа ждёт)
Я вам так скажу. Раньше, где-то до появления докера (до середины 10ых), такие продукты были только у компаний с огромными нагрузками, изоляциями типо jail (FreeBSD, первая) и LXC (linux, позднее) и инфы про такие системы было мало, ибо это были их конкурентные преимущества, а в отрасли было чёткое понимание того, что когда ты выходиш из общего адресного пространства, да и ещё имеешь нагрузки выше среднего, ты получаешь возможность масштабировать и терминировать эту нагрузку, но тебе нужно будет обеспечивать целостность разделяемых ресурсов между разными окружениями, а это как в многопоточном приложении - самые трудноуловимые ошибки и даже сложнее - в многопоточке у тебя общее адресное пространство и там ты можешь использовать ipc примитивы а в микросервисной - всё гораздо жёсче. Так что как-то так, коллега)
Вы просто пройдитесь по плюсам микросервисов и вам будет всё понятно. Это Архитектурная преждевременная оптимизация по Кнуту.
А в чём профит? В том, что вы не несёте на сервера всю кодовую базу, а всего лишь один сервис? Всего то? Тут всё очень зависит от реализации монолита.
UPD Думаете это стоит того, что бы удорожать разработку в несколько раз?
Всё то же, но у меня еще и бизнес был по теме. В итоге - просто программер.
Любую концепцию, прежде чем использовать, надо понять. ООП сложнее в изучении, чем процедурный подход, но профит от его использования на масштабных проектах - очевиден.
Без проблем. Смотрите tokio и асинхронный подход.
Энтерпрайз так решил, потому что деньги! А все ваши приведенные вопросы - мало имеют отношения к предмету и местячковы по масштабам планеты.
Гугл сделали молоток с рюшечками что-бы джуниорам было просто код писать - они об этом прямо говорят, а не от того, что он процедурный. Почему программисты с опытом клюют на это - для меня лично непонятно, но маркетинг у них хороший, да. Про себя скажу, что для таких задач я выбираю rust и радуюсь.
И на что этот энтерпрайз с кобола смигрировал?
Цитаты не нужны, нужна просто статистика по ЯП в ентерпрайзе, всё. Коллективный разум порешал все давно.
Все так. И все вот эти неодушевленные предметы - это обычные value object, обычно не имеющие поведения и прекрасно ложащиеся на концепт ООП+DDD ) а то, что у вас функции сбоку, так это добавляет сложности, так как у вас теперь методы "обезличены" (или всё-таки нет?) и во-первых вам нужно их куда то осмысленно класть в исходниках, во-вторых в этих функциях теперь вам нужно понимать, какой объект у вас на входе. И, не забывайте, в ООП тоже есть функции вообще-то. И никто не запрещал их использовать)
Да, именно об этом и речь. Делать большие проекты с кучей абстракций, предметных областей и прочее будет гораздо сложнее с функциональным образом мышления, ибо сама реализация подобного функционала будет все равно подталкивать вас к ООП парадигме, потому что мозг не обманешь - ему так проще) и не успеете оглянуться, как начнете реализовывать "интерфейсы, фабрики и представления"
И вообще, у вас довольно странное абстрактное мышление) С чего вы вообще взяли, что метод наполнения кружки должен лежать в классе кружка? Если вам по бизнес ложике важен процесс наливания чая, то вообще этот процесс инициирует не кружка, а вторая абстракция, которая собственно это делает. Всё как в жизни, не так ли?