А что, если у меня всего этого нет, потому что не нужно? Ладно, не суть
Вы не ответили ни на один мой вопрос. Но в вашем ответе прослеживается явное нежелание называть монолитом приложение использующее стороние сервисы. Продолжая ваши рассуждения, использование чужой внешней бд тоже не дает возможности называть приложение монолитом.
Я так не играю. Извините, но имхо, то, что вы описываете далеко от общепринятого понимания микро/нано-сервисов.
Т.е. вы утверждаете что любую задачу можно решить монолитным приложением
Не-а, мы вообще не об этом говорим. Однако то, что монолит не всем приложениям подходит, вовсе не значит, что монолит нужно списывать в утиль.
А если этого нельзя, то приложение сделано рукожопами?
Строго говоря, у разработчиков монолита могли быть весомые причины не добавлять возможность запуска на произвольном количестве серверов. Однако в таком случае и о микросервисах говорить бессмысленно.
Так что в рамках выбора монолит/микросервисы мы имеем, что такое монолитное приложение спроектировано рукожопами.
У вас просто монолита нормального не было. Вам никто не мешает строить монолит по нормальному, так чтобы можно было занять много серверов.
Личный опыт наблюдения за неправильными монолитами не значит, что большинство монолитов проектируются рукожопами.
А у меня, к примеру, общая кодовая база, но разные точки входа. Одна точка входа слушает API-запросы, другая точка входа слушает очередь. Вполне себе монолитище.
еще раз, я не говорил про микросервисы, я имел в виду минисервисы.
Разница только в объеме кода или есть еще какая-то разница?
По моему мнению, это все еще монолит. Это конечно же, спор о терминах, но давайте просто определимся с терминами.
Вот у меня есть монолитное API-приложение с in-memory database (это просто пример, ок :-)).
Я заменяю in-memory database на чужую внешнюю бд, которая имеет свой протокол обмена данных и может хоститься на отдельном сервере. Приложение перестало быть монолитом?
Я добавляю к приложению чужой внешний кэш, который имеет свой протокол обмена данных и может хоститься на отдельном сервере. Приложение перестало быть монолитом?
Я добавляю к приложению чужой фулл-текст (эластик, к примеру), который имеет свой протокол обмена данных и может хоститься на отдельном сервере. Приложение перестало быть монолитом?
Я добавляю к приложению балансировку нагрузки на одинаковые инстансы, которые не имеют возможности обмениваться данными, но могут хоститься на отдельном сервере. Приложение перестало быть монолитом?
Я добавляю к приложению сервис авторизации, который выношу на отдельный сервер и который может обмениваться с основным приложением. Приложение перестало быть монолитом?
Простите, но я действительно не понимаю, почему вы так думаете.
Если вы испытываете проблемы с объемами бд, то у вас есть возможность сделать шардирование. На крайняк, вы можете разбить бд руками на независимые бд.
Если вы испытываете проблемы с поступающей нагрузкой, то у вас есть возможность поднять кучу инстансов и сделать балансировщик нагрузки. Многие приличные бд имеют возможность создавать read replica. Вы также можете вынести отдельные тяжелые операции в фон на отдельный сервер с помощью очередей, если это возможно (если что, это вовсе не микросервисы).
Как мне кажется, описанный пример имеет мало общего с микросервисами. Конечно, очень трудно тут проводить чёткую границу.
Но это больше похоже на балансировку нагрузки, нежели на способ обеспечения независимости разработки.
Вы верно вспоминаете о том, что бд/кэш/elastic тоже вводят дополнительные сетевые заддержки.
Но есть некоторая разница. Написание собственной бд (и всего остального) в качественном виде — практически неподъемная задача для большинства. Не говоря уже о том, что использование общепринятого решения во многих случаях куда лучше велосипеда. Это приемлемая пеня. Тем не менее, для мелких (с точки зрения количества пользователей и объема данных) приложений идея держать все на одном сервере вполне имеет смысл.
Но даже, если ваши микросервисы (или приложение, и бд) крутятся на одном сервере, то вы все равно имеете довольно впечатляющую задержку.
Для того, чтобы сравнивать микросервисы и бд в этом плане, нужно показать, что микросервисы имеют такие же преимущества.
Но есть еще один важный момент. Вводя микросервисы вы увеличиваете длину цепочки пересылки данных. Причём в худших случаях, если перестать следить, то цепочка увеличится не на один микросервис, а на кучу.
У меня есть небольшая гипотеза, возможно объясняющая часть таких людей.
Микросервисы крайне хорошо заходят на чрезвычайно крупных проектах. На таких проектах большое количество разработчиков. Причём за пару лет ещё и происходит ротация разработчиков.
Часть этих разработчиков уходит в проекты помельче. И начинают применять практики, которые, как они видели, работают.
Замечательная статья.
Для меня удивительно, что в статье не упомянут важный момент: микросервисы вносят дополнительную сетевую задержку. Для мелких проектов этот недостаток реально трудно перекрыть.
Еще хуже, что при неправильной декомпозиции (а на старте она будет скорее неправильной, чем правильной) приложение будет напоминать пинг-понг: множественные пересылки данных между микросервисами в рамках исполнения одного api-запроса.
То есть каждое предположение по отдельности не кажется вам монструозным?
Каждое предположение по отдельности является просто предположением, а не твердым убеждением. Если ваш оппонент с вами не согласен, это не значит, что он псих.
Вы посчитайте не комментарии, а комментаторов. Процент, как вы их назвали, «чудил» окажется веселым.
Вы правы, так считать корректнее. Это однако не значит, что мысли этих людей можно объединять, чтобы получить монстра.
Вот рядом с приведенными цитатами вы найдете и теорию заговора.
Комментарий BlessYourHeart находится под комментарием Am0ralist. Как я понимаю, его грех в том, что он утверждает, что родственные связи Линуса с его дочерью сильно повлияли на принятие CoC. Это может быть некорректным утверждением, не спорю.
Но если вспомнить, что «теория заговора» имеет окраску связанную с псих.больными, то называние этого теорией заговора является дискредитирующим действием против оппонента в споре.
Это впрочем не отменяет всего остального, написанного мною. Включая «Хотя вполне может быть, что где-то среди 445 комментариев у какого-то чудилы такие мысли проскакивали.»
На всякий случай, про подкуп:
Нет, его лидерам его навязали, угрозами и подкупом
Просто капельку забавно, что вы потеряли смайлик при цитировании однострочного комментария.
А есть некоторая группа людей, которой интересно, какие конкретно «мудаки», и как.
Я сюда зашел потыкать только обвинения в теории заговора. Мне в общем-то не интересно участвовать в этой параолимпиаде, мне просто глаза режут некоторые вещи.
Я не люблю риторику «теория заговора» по двум причинам.
Первая причина заключается в том, что очень уж удобно назвать оппонентов псих.больными и забить на дискуссию.
Вторая причина (только дочитайте абзац, пожалуйста): заговоры реальны. Большинство людей не учатся на своих ошибках. И время от времени люди пытаются сделать заговор. Другое дело, что особым успехом заговоры не отличаются. Что не мешает другим людям наблюдать за заговором.
выстраивается длинная цепочка из созависимых событий каждое из которых мягко говоря не 100% вероятности
Если я попытаюсь описать любое сложное историческое событие с точки зрения человека, переживающего его, то мы получим такую же картину. Что не будет отменять того, что рассматриваемое историческое событие случилось в реальности.
многие бессмысленные с логической точки зрения, а некоторые прямо противоречат друг другу, то это не «мыслишки», а выстроенная концепция.
Есть некоторая группа людей на хабре, которые считают, что CoC пропихнули мудаки. У этих людей есть разные мысли о том, почему так получается. Вы собираете эти мысли, получаете нежизнеспособного монстра. Но вот почему виноваты в этом не вы, а ваши оппоненты?
Но вам мало того, вы начинаете извращать эти мысли, чтобы уж точно не было сомнений, что ваши оппоненты неадекваты. Хотя вполне может быть, что где-то среди 445 комментариев у какого-то чудилы такие мысли проскакивали.
… по-моему у сторонников лунного заговора было меньше шагов и меньше людей вовлечено в их теорию, этой гипотезе требуется для объяснения одного события.
Итак, первое ваше передергивание. Вы набросали в список не только шаги, а еще и просто разные утверждения. При этом вы не сделали этого же для лунного заговора, так что мы не имеем возможности сравнить, сколько шагов в их плане.
Если захотите реально сравнить, то вот важненькая вещь: количество шагов в плане зависит от детализации плана. А количество людей вы вообще не сравнивали.
м. имеет практически неограниченную власть над б.
-за м. стоят люди/организации, которые делают м. могущественными
Да, такое крайне маловероятно. И человек, говорящий это является неадекватом.
Но эй, вы хотите поспорить с тем, что есть куча примеров сообществ, где власть сосредоточена в руках меньшинства? Ведь не нужна «неограниченная власть» для того, чтобы объяснить возможность навязывания CoC.
СоС это краеугольный камень контроля мира который пришлось м. продавливать через сопротивление б.
Да, так действительно звучит зловеще. И похоже на слова псих.больного.
Но дайте угадаю, в оригинале было «с помощью CoC можно будет легче убирать неугодных». Причем автор вовсе не обязательно считал, что именно так и будет, его пугает просто возможность подобного.
Тем не менее, допустим, что человек действительно считает, что одной из целей CoC была возможность выкидывать неугодных людей. Я могу допустить, что у CoC больше одной цели и эта является опциональной. И что выкидывать получится не совсем эффективно, но хоть как-то. Что, это делает меня сумасшедшим?
методы продавливания, это гипноз, влияние через детей, подкуп
Я специально поискал, первым в комментариях к этому топику «гипноз» упомянули вы. За сим хочу вам сказать множество нехороших слов, которые запрещены на хабре.
Я не понимаю, зачем вы пытаетесь дискредитировать противников CoC на хабре. Я даже не уверен, что вы делаете это осознанно. Но вы явно это делаете.
Вот это будет последовательная позиция.
Если вы думаете, что последовательная позиция заключается в подчинении вашим передергиваниям, то вы слегка самонадеянны.
Последовательная позиция — это «заткнись и считай». Вы тоже не пытались сравнить вероятность гипотез «CoC приняли в сообществе нормально» и «CoC продавили»
… по-моему у сторонников лунного заговора было меньше шагов и меньше людей вовлечено в их теорию, этой гипотезе требуется для объяснения одного события.
Вот вы сейчас серьёзно? То, что у людей проскакивают мыслишки о специальном внешнем влиянии еще не делает этих людей верящими в теорию заговора. Психиатр хренов
Если у вас не хватает экспертизы, это не значит, что инструмент плохой
Омг. Вы бы прежде чем обвинять меня в отсутствии экспертизы хотя-бы спросили, что мне конкретно не нравится.
Skyeng и tinkoff активно используют и ничего, все работает
Это какой-то извращенный вариант демагогического аргумента про авторитеты? Или это ошибка репрезентативности, когда вы не в курсе про проблемы отдельных разработчиков?
Мой аргумент был, что в экосистеме react state manager обязателен и посколько facebook не озаботился все размыто (flux, reflux, refux и тд) и так со всеми библиотеками
Да, вы правы, когда говорите, что для react использование state manager скорее обязательно (хотя на самом деле нет). Но когда вы будете пилить сложное приложение на angular, то вам придется подключать state manager.
Между тем, я не считаю это серьезной проблемой, потому что сейчас нельзя заставить все веб-приложения работать только через один подход.
А неправы вот вы в чем: в вашем оригинальном сообщении был наезд на React за то, что проекты на React используют разные решения для управления стейтом. Но проекты на Angular тоже используют разные решения для управления стейтом!
ChangeDetectionStrategy, которые по сути аналогичны Component и PureComponent
Вообще не правильно.
При ChangeDetectionStrategy.Default у вас компонент перерисовывается на каждое событие, в том числе и на каждый mousemove. У реакта такого чуда нет.
При ChangeDetectionStrategy.OnPush ваш компонент начинает работать чем-то похоже на React.PureComponent
Ок, redux, ramda, flow, immutable.js за пределами React.js «мало кому сдался по объективным причинам». Но я не ловлю с этого лулзов, потому что это нормально, инструмент обычно нужен для определенных целей
Драма в том, что redux, ramda, flow, immutable.js не являются обязательным для работы с react. А вот rxjs является обязательным для работы с Angular, потому что Angular очень многое делает через него. Но это не более чем забавный момент.
А что, если у меня всего этого нет, потому что не нужно? Ладно, не суть
Вы не ответили ни на один мой вопрос. Но в вашем ответе прослеживается явное нежелание называть монолитом приложение использующее стороние сервисы. Продолжая ваши рассуждения, использование чужой внешней бд тоже не дает возможности называть приложение монолитом.
Я так не играю. Извините, но имхо, то, что вы описываете далеко от общепринятого понимания микро/нано-сервисов.
Строго говоря, у разработчиков монолита могли быть весомые причины не добавлять возможность запуска на произвольном количестве серверов. Однако в таком случае и о микросервисах говорить бессмысленно.
Так что в рамках выбора монолит/микросервисы мы имеем, что такое монолитное приложение спроектировано рукожопами.
Личный опыт наблюдения за неправильными монолитами не значит, что большинство монолитов проектируются рукожопами.
Разница только в объеме кода или есть еще какая-то разница?
Вот у меня есть монолитное API-приложение с in-memory database (это просто пример, ок :-)).
Я заменяю in-memory database на чужую внешнюю бд, которая имеет свой протокол обмена данных и может хоститься на отдельном сервере. Приложение перестало быть монолитом?
Я добавляю к приложению чужой внешний кэш, который имеет свой протокол обмена данных и может хоститься на отдельном сервере. Приложение перестало быть монолитом?
Я добавляю к приложению чужой фулл-текст (эластик, к примеру), который имеет свой протокол обмена данных и может хоститься на отдельном сервере. Приложение перестало быть монолитом?
Я добавляю к приложению балансировку нагрузки на одинаковые инстансы, которые не имеют возможности обмениваться данными, но могут хоститься на отдельном сервере. Приложение перестало быть монолитом?
Я добавляю к приложению сервис авторизации, который выношу на отдельный сервер и который может обмениваться с основным приложением. Приложение перестало быть монолитом?
Если вы испытываете проблемы с объемами бд, то у вас есть возможность сделать шардирование. На крайняк, вы можете разбить бд руками на независимые бд.
Если вы испытываете проблемы с поступающей нагрузкой, то у вас есть возможность поднять кучу инстансов и сделать балансировщик нагрузки. Многие приличные бд имеют возможность создавать read replica. Вы также можете вынести отдельные тяжелые операции в фон на отдельный сервер с помощью очередей, если это возможно (если что, это вовсе не микросервисы).
Почему описанные стратегии не подходят?
Я больше говорил о том, что одного только желания недостаточно. Еще нужны знания/понимание/опыт.
Как мне кажется, описанный пример имеет мало общего с микросервисами. Конечно, очень трудно тут проводить чёткую границу.
Но это больше похоже на балансировку нагрузки, нежели на способ обеспечения независимости разработки.
Вы верно вспоминаете о том, что бд/кэш/elastic тоже вводят дополнительные сетевые заддержки.
Но есть некоторая разница. Написание собственной бд (и всего остального) в качественном виде — практически неподъемная задача для большинства. Не говоря уже о том, что использование общепринятого решения во многих случаях куда лучше велосипеда. Это приемлемая пеня. Тем не менее, для мелких (с точки зрения количества пользователей и объема данных) приложений идея держать все на одном сервере вполне имеет смысл.
Но даже, если ваши микросервисы (или приложение, и бд) крутятся на одном сервере, то вы все равно имеете довольно впечатляющую задержку.
Для того, чтобы сравнивать микросервисы и бд в этом плане, нужно показать, что микросервисы имеют такие же преимущества.
Но есть еще один важный момент. Вводя микросервисы вы увеличиваете длину цепочки пересылки данных. Причём в худших случаях, если перестать следить, то цепочка увеличится не на один микросервис, а на кучу.
У меня есть небольшая гипотеза, возможно объясняющая часть таких людей.
Микросервисы крайне хорошо заходят на чрезвычайно крупных проектах. На таких проектах большое количество разработчиков. Причём за пару лет ещё и происходит ротация разработчиков.
Часть этих разработчиков уходит в проекты помельче. И начинают применять практики, которые, как они видели, работают.
Замечательная статья.
Для меня удивительно, что в статье не упомянут важный момент: микросервисы вносят дополнительную сетевую задержку. Для мелких проектов этот недостаток реально трудно перекрыть.
Еще хуже, что при неправильной декомпозиции (а на старте она будет скорее неправильной, чем правильной) приложение будет напоминать пинг-понг: множественные пересылки данных между микросервисами в рамках исполнения одного api-запроса.
Не хотеть говнокодить и не говнокодить — две большие разницы.
Комментарий BlessYourHeart находится под комментарием Am0ralist. Как я понимаю, его грех в том, что он утверждает, что родственные связи Линуса с его дочерью сильно повлияли на принятие CoC. Это может быть некорректным утверждением, не спорю.
Но если вспомнить, что «теория заговора» имеет окраску связанную с псих.больными, то называние этого теорией заговора является дискредитирующим действием против оппонента в споре.
BlessYourHeart мои глубочайшие извинения.
Это впрочем не отменяет всего остального, написанного мною. Включая «Хотя вполне может быть, что где-то среди 445 комментариев у какого-то чудилы такие мысли проскакивали.»
Просто капельку забавно, что вы потеряли смайлик при цитировании однострочного комментария.
Я сюда зашел потыкать только обвинения в теории заговора. Мне в общем-то не интересно участвовать в этой параолимпиаде, мне просто глаза режут некоторые вещи.
Первая причина заключается в том, что очень уж удобно назвать оппонентов псих.больными и забить на дискуссию.
Вторая причина (только дочитайте абзац, пожалуйста): заговоры реальны. Большинство людей не учатся на своих ошибках. И время от времени люди пытаются сделать заговор. Другое дело, что особым успехом заговоры не отличаются. Что не мешает другим людям наблюдать за заговором.
Если я попытаюсь описать любое сложное историческое событие с точки зрения человека, переживающего его, то мы получим такую же картину. Что не будет отменять того, что рассматриваемое историческое событие случилось в реальности.
Есть некоторая группа людей на хабре, которые считают, что CoC пропихнули мудаки. У этих людей есть разные мысли о том, почему так получается. Вы собираете эти мысли, получаете нежизнеспособного монстра. Но вот почему виноваты в этом не вы, а ваши оппоненты?
Но вам мало того, вы начинаете извращать эти мысли, чтобы уж точно не было сомнений, что ваши оппоненты неадекваты. Хотя вполне может быть, что где-то среди 445 комментариев у какого-то чудилы такие мысли проскакивали.
Итак, первое ваше передергивание. Вы набросали в список не только шаги, а еще и просто разные утверждения. При этом вы не сделали этого же для лунного заговора, так что мы не имеем возможности сравнить, сколько шагов в их плане.
Если захотите реально сравнить, то вот важненькая вещь: количество шагов в плане зависит от детализации плана. А количество людей вы вообще не сравнивали.
Да, такое крайне маловероятно. И человек, говорящий это является неадекватом.
Но эй, вы хотите поспорить с тем, что есть куча примеров сообществ, где власть сосредоточена в руках меньшинства? Ведь не нужна «неограниченная власть» для того, чтобы объяснить возможность навязывания CoC.
Да, так действительно звучит зловеще. И похоже на слова псих.больного.
Но дайте угадаю, в оригинале было «с помощью CoC можно будет легче убирать неугодных». Причем автор вовсе не обязательно считал, что именно так и будет, его пугает просто возможность подобного.
Тем не менее, допустим, что человек действительно считает, что одной из целей CoC была возможность выкидывать неугодных людей. Я могу допустить, что у CoC больше одной цели и эта является опциональной. И что выкидывать получится не совсем эффективно, но хоть как-то. Что, это делает меня сумасшедшим?
Я специально поискал, первым в комментариях к этому топику «гипноз» упомянули вы. За сим хочу вам сказать множество нехороших слов, которые запрещены на хабре.
Я не понимаю, зачем вы пытаетесь дискредитировать противников CoC на хабре. Я даже не уверен, что вы делаете это осознанно. Но вы явно это делаете.
Если вы думаете, что последовательная позиция заключается в подчинении вашим передергиваниям, то вы слегка самонадеянны.
Последовательная позиция — это «заткнись и считай». Вы тоже не пытались сравнить вероятность гипотез «CoC приняли в сообществе нормально» и «CoC продавили»
Вот вы сейчас серьёзно? То, что у людей проскакивают мыслишки о специальном внешнем влиянии еще не делает этих людей верящими в теорию заговора. Психиатр хренов
Это какой-то извращенный вариант демагогического аргумента про авторитеты? Или это ошибка репрезентативности, когда вы не в курсе про проблемы отдельных разработчиков?
Да, вы правы, когда говорите, что для react использование state manager скорее обязательно (хотя на самом деле нет). Но когда вы будете пилить сложное приложение на angular, то вам придется подключать state manager.
Между тем, я не считаю это серьезной проблемой, потому что сейчас нельзя заставить все веб-приложения работать только через один подход.
А неправы вот вы в чем: в вашем оригинальном сообщении был наезд на React за то, что проекты на React используют разные решения для управления стейтом. Но проекты на Angular тоже используют разные решения для управления стейтом!
Вообще не правильно.
При ChangeDetectionStrategy.Default у вас компонент перерисовывается на каждое событие, в том числе и на каждый mousemove. У реакта такого чуда нет.
При ChangeDetectionStrategy.OnPush ваш компонент начинает работать чем-то похоже на React.PureComponent
Драма в том, что redux, ramda, flow, immutable.js не являются обязательным для работы с react. А вот rxjs является обязательным для работы с Angular, потому что Angular очень многое делает через него. Но это не более чем забавный момент.