Во-первых - не фантазируйте! Такие зависимости появляются крайне редко.
Так я не фантазирую. Я вам описываю реальную ситуацию.
Во-вторых - такие зависимости как-раз таки можно вынести в отдельные окружения, заставить общаться по апи и жить с этим.
Ну так что делать если в теории практически 99% кода могут словить такую зависимость? Что куда выносить? Как организовать архитектура чтобы в каждом новом проекте можно было переиспользовать как можно больше базового кода?
В-третих - только нагрузки - объективная причина появления таких архитектур.
А теперь переходим к следующему уровню сложности: в теории 80-90% всего решения могут получить такую зависимость. Ну или точнее от проекта к проекту это реально происходит.
Не проще тогда построить инфраструктуру на микросервисах, написать "стандартные" сервисы для всего что надо и потом только по необходимости менять отдельные сервисы на проприетарные решения в отдельных проектах?
Именно так. Статья 81 ТК РФ, на которую я дал ссылку - это все возможные законные причины для увольнения без согласия работника, других нет. Вы можете написать в договоре хоть запрет на ношение платья в горошек, хоть на подработки на стороне - но когда дело дойдет до увольнения, в трудовой вы будете должны указать пункт ТК РФ, на основании которого расторгнут трудовой договор.
Но там же есть пункт:
предусмотренных трудовым договором с руководителем организации, членами коллегиального исполнительного органа организации;
То есть получается в трудовой договор можно прописать какие-то пункты, которые позволят уволить человека если он их нарушит. Или я опять таки что-то не так понимаю?
"Возможно использовать монолит" не означает "удобнее/дешевле использовать монолит".
Монолит вам создаёт кучу проблем, потому что вы не умеете всё вышеперечисленное.
Я точно так же могу вам сказать что микросервисы создают вам кучу проблем потому что вы не умеете их правильно использовать.
Ну и как бы расскажите мне как правильно использовать монолит когда:
-Часть функционала пишется не нами, а самими клиентами или нашими партнёрами или даже просто отдаётся на аутсорс.
Из-за сторонних зависимостей приходится использовать абсолютно разные тех-стеки.
Работать разные части кода должны на разном железе. Причём так что одна часть на винде, другая на соседней машине на линуксе, третья интегрируется в какой-нибудь TestStand, а четвёртая запускается в эмбеддед-окружении на каких-нибудь датчиках или производственном железе.
Тут где то написали - если у вас бизнес масштаба Вайлдберриз - то микросервисы необходимы
Это не значит что во всех остальных случаях они не нужны.
Предположу, что у вас это тоже не так (хотя могу ошибаться) и все ваши сервисы только лишь приносят боль. Не вам - компании!
У нас это по разному. И в отдельных проектах мы используем микросервисы(или точнее распределённую архитектуру} потому что монолит создаёт там гораздо больше проблем.
Для меня порядки цены разработки очевидны - это минимум x3.
А для меня это очень зависит от ситуации. И в некоторых ситуациях микросервисы даже дешевле будут.
Нужна очень квалифицированная и добросовестная команда
Возьмите не квалифицированную и не добросовестную команду и попробуйте написать и поддерживать монолит на миллион строк кода.
Удорожается отладка - вам нужно делать тестовые стеки из набора связанных микросервисов
Вы про моки ничего не слышали?
Не дай бог вы в качестве дефолтной изоляции для микросервисов используете докер
Вообще смешной аргумент. Ну не используйте докер если видите в этом проблему.
Если вы не хотите репутационных проблем - вам ОБЯЗАТЕЛЬНО нужно будет делать всё, что описано в этой статье, а это далеко не для новичков;
Нет, совсем не обязательно делать всё, что описано в этой статье.
Все апишки, контракты взаимодействия между сервисами нужно будет описывать и держать их в актуальном состоянии
Это и в монолите надо делать.
Я вам так скажу. Раньше, где-то до появления докера (до середины 10ых), такие продукты были только у компаний с огромными нагрузками, изоляциями типо jail (FreeBSD, первая) и LXC (linux, позднее) и инфы про такие системы было мало,
Я вам так скажу: микросервисы существуют гораздо дольше. Только их далеко не всегда называли микросервисами :)
Тогда можно предположить что жизнь не самозарождалась, а существовалв всегда. А потом в какой-то момент триггернулась эволюция конкретно на Земле.
Так я не фантазирую. Я вам описываю реальную ситуацию.
Ну так что делать если в теории практически 99% кода могут словить такую зависимость? Что куда выносить? Как организовать архитектура чтобы в каждом новом проекте можно было переиспользовать как можно больше базового кода?
Это вы сейчас сами придумали?
А теперь переходим к следующему уровню сложности: в теории 80-90% всего решения могут получить такую зависимость. Ну или точнее от проекта к проекту это реально происходит.
Не проще тогда построить инфраструктуру на микросервисах, написать "стандартные" сервисы для всего что надо и потом только по необходимости менять отдельные сервисы на проприетарные решения в отдельных проектах?
Ну так я то не считаю что моё мнение не важно. В отличии от вас.
А про что вы говорили когда писали "Подобного мы больше не увидим."?
Для меня это не является чем-то аналогичным.
https://lenta.ru/news/2005/03/16/code/
https://www.stuff.co.nz/entertainment/80454186/controversial-show-the-preacher-gets-christians-hot-under-the-collar
И так далее и тому подобное.
Для внешнего наблюдателя и участников дискуссии? Всё ещё голословные заявления.
А причём здесь абсолют?
Всё очень занимательно. Но я так и не понял откуда появилось это "нечто"...
Как будто в таких делах здравый смысл кого-то интересует :)
Конечно можно. Но имея свой поисковый ИИ можно ещё больше заработать.
Тяжко вам там в параллельной вселенной...
Нагрузки это не единственная причина для использования распределённой архитектуры.
Ок, теперь понял. Обожаю канцелярит...
Мы себе ничего не сделали. Это требования от клиентов на реальных производственных линиях.
А весь мир ограничивается среднестатистическими веб-приложениями?
Тогда надо менять законы, а не начинать нарушать имеющиеся.
Конечно пробовали. А вы не пробовали интегрировать в монолит библиотеки из кучи разных ЯП, фрэймворков, версий и так далее?
У вас есть статистика? Можете ссылочку дать?
Ещё раз: это просто голословное утверждение. Более того я вам привёл конкретный пример когда это не так.
Но там же есть пункт:
То есть получается в трудовой договор можно прописать какие-то пункты, которые позволят уволить человека если он их нарушит. Или я опять таки что-то не так понимаю?
"Возможно использовать монолит" не означает "удобнее/дешевле использовать монолит".
Я точно так же могу вам сказать что микросервисы создают вам кучу проблем потому что вы не умеете их правильно использовать.
Ну и как бы расскажите мне как правильно использовать монолит когда:
-Часть функционала пишется не нами, а самими клиентами или нашими партнёрами или даже просто отдаётся на аутсорс.
Из-за сторонних зависимостей приходится использовать абсолютно разные тех-стеки.
Работать разные части кода должны на разном железе. Причём так что одна часть на винде, другая на соседней машине на линуксе, третья интегрируется в какой-нибудь TestStand, а четвёртая запускается в эмбеддед-окружении на каких-нибудь датчиках или производственном железе.
Это не значит что во всех остальных случаях они не нужны.
У нас это по разному. И в отдельных проектах мы используем микросервисы(или точнее распределённую архитектуру} потому что монолит создаёт там гораздо больше проблем.
Бритва Оккама не может ничего отвергать. Грубо говоря она только говорит что логичнее при прочих равных выбирать самое простое объяснение.
Но это не значит что остальные объяснения из-за этого автоматически становятся неверными.
Потому что тогда всё ещё остаётся открытым вопрос откуда взялся этот разум. Ну если самозарождение не работает.
Да это сколько угодно. Взялся то он откуда? :)
Зато постоянно происходит :)
Даже близко нет. И этот комментарий намекает мне что вы не особо разбираетесь в теме.
Ага. Я посмотрю на вас когда у вас пара сотен "просто программистов" начнут работать над общей кодовой базой в несколько миллионов строк кода :)
А в монолите их не нужно писать? У вас там только интеграционные тесты?
Нет. Особой боли там нет. И делается это не только ради распределения нагрузки.
А для меня это очень зависит от ситуации. И в некоторых ситуациях микросервисы даже дешевле будут.
Возьмите не квалифицированную и не добросовестную команду и попробуйте написать и поддерживать монолит на миллион строк кода.
Вы про моки ничего не слышали?
Вообще смешной аргумент. Ну не используйте докер если видите в этом проблему.
Нет, совсем не обязательно делать всё, что описано в этой статье.
Это и в монолите надо делать.
Я вам так скажу: микросервисы существуют гораздо дольше. Только их далеко не всегда называли микросервисами :)