Где наконец-то говорится, что микросервисы это не так уж хорошо и не всегда применимо. В конце статьи очень интересный список ссылок.
Расцвет микросервисов закончился. Uber преобразовывает тысячи микросервисов в более управляемое решение [1]; Келси Хайтауэр предсказывает, что будущее за монолитами [2]; и даже Сэм Ньюман заявляет, что микросервисы никогда не должны быть выбором по умолчанию, а скорее крайним средством [3].
Что происходит? Почему так много проектов стало невозможно поддерживать, несмотря на обещание микросервисов простоты и гибкости? Или все-таки монолиты лучше?
Я вот сам трушных микросервисов ни разу не встречал. Так что бы 1 сервис — 1 бд. Обычно делали 1 ил 2 бд к которым подключались несколько сервисов.
Либо же вообще за работу с каждой бд отвечал свой сервис, а остальные уже подключались к нему.
А вся эта куча сервисов как правило была доступна фронту через какой-либо api gateway типа ocelot.
Несколько бд было только в том случае, если одна реляционная, а другая — нет.
Кто как делает?
Я тоже считаю, что плодить множество действительно микросервисов с кучей баз данных повышает трудоемкость разработки и поддержки проектов. В первую очередь — это необходимость согласовывать изменения между сервисами. И невозможность вытащить данные из одной бд sql запросом.
Здравствуйте, BlackEric, Вы писали: BE>Кто как делает?
не имел дел. но где-то у Александреску читал, что основная причина появления таких архитектур, что ЯП типа джава потребляет слишком много ресурсов.
в отличии от нативных ЯП. Я и сам удивлялся сколько гласфишу нужно памяти для пары крохотных веб-приложений.
сишарп кушает поменьше но тоже нехило. плюс эта вечная отмазка про компиляцию первого вызова. пробовал ngen но прикола так и не понял.
а всякие джанго и питоны еще и медленные.
Здравствуйте, BlackEric, Вы писали:
BE>Я тоже считаю, что плодить множество действительно микросервисов с кучей баз данных повышает трудоемкость разработки и поддержки проектов. В первую очередь — это необходимость согласовывать изменения между сервисами. И невозможность вытащить данные из одной бд sql запросом.
Оверхед на микросервисность (и ценность микросервисности) зависит от размера организации — чем больше организация, тем меньше оверхед, и тем больше ценность. Микросервисность — это в первую очередь про изоляцию команд друг от друга. Если речь идёт про 100 команд по 10 человек, вопрос изоляции/автономности есть и он важен. Когда одна команда из 5 человек начинает себе микросервисы делать, это конечно глупость.
Здравствуйте, vaa, Вы писали:
vaa>не имел дел. но где-то у Александреску читал, что основная причина появления таких архитектур, что ЯП типа джава потребляет слишком много ресурсов.
А разве не возможность делать изи горизонтальное масштабирование?
Здравствуйте, BlackEric, Вы писали:
BE>Я вот сам трушных микросервисов ни разу не встречал. Так что бы 1 сервис — 1 бд. Обычно делали 1 ил 2 бд к которым подключались несколько сервисов. BE>Либо же вообще за работу с каждой бд отвечал свой сервис, а остальные уже подключались к нему. BE>А вся эта куча сервисов как правило была доступна фронту через какой-либо api gateway типа ocelot.
BE>Несколько бд было только в том случае, если одна реляционная, а другая — нет.
BE>Кто как делает?
На новой работе сделали несколько сервисов. Каждый сервис с отдельной БД. Не сказал бы, что они микро. Мне не нравится. Любители копипаста. Нужен новый схожий проект — создают новый репозиторий в гитлабе, склонированный из старого, копируют базу и поехали менять. Надеюсь всё это выбросить и переделать в один универсальный сервис с единой БД. Хотя не факт, что дадут.
BE>Я тоже считаю, что плодить множество действительно микросервисов с кучей баз данных повышает трудоемкость разработки и поддержки проектов. В первую очередь — это необходимость согласовывать изменения между сервисами. И невозможность вытащить данные из одной бд sql запросом.
Ещё по моим наблюдениям такие сервисы имеют тенденцию по последней причине копировать куски базы между сервисами и пытаться их синхронизировать, обычно не особо удачно. В общем придумываем проблемы и героически их решаем.
Вот, кстати, "идея для стартапа" — надёжная и быстрая синхронизация некоторого подмножества БД между разными базами.
Здравствуйте, vaa, Вы писали:
BE>>Кто как делает? vaa>не имел дел. но где-то у Александреску читал, что основная причина появления таких архитектур, что ЯП типа джава потребляет слишком много ресурсов. vaa>в отличии от нативных ЯП. Я и сам удивлялся сколько гласфишу нужно памяти для пары крохотных веб-приложений.
Тут можно схитрить и не запускать отдельный сервер приложений для каждого микросервиса. Тогда накладные расходы на каждый микросервис будут небольшими. Правда там свои проблемы появляются, но в целом решаемые. Хотя это старые и не модные технологии нынче. Поэтому да, по факту жава жрёт память дико, если жалко гигабайта на каждый микросервис, лучше от жавы сразу отказываться в пользу го, ноды или пайтона.
Здравствуйте, rosencrantz, Вы писали:
R>Здравствуйте, BlackEric, Вы писали:
BE>>Я тоже считаю, что плодить множество действительно микросервисов с кучей баз данных повышает трудоемкость разработки и поддержки проектов. В первую очередь — это необходимость согласовывать изменения между сервисами. И невозможность вытащить данные из одной бд sql запросом.
R>Оверхед на микросервисность (и ценность микросервисности) зависит от размера организации — чем больше организация, тем меньше оверхед, и тем больше ценность. Микросервисность — это в первую очередь про изоляцию команд друг от друга. Если речь идёт про 100 команд по 10 человек, вопрос изоляции/автономности есть и он важен. Когда одна команда из 5 человек начинает себе микросервисы делать, это конечно глупость.
Команда в 10 человек — это уже толпа. И она вполне способна сделать большой проект.
А на практике команды в 4-5 человек начинают плодить сервисы с кубернетисом, кучей нод и потом думаю как же все это поддерживать.
Здравствуйте, vsb, Вы писали:
vsb>На новой работе сделали несколько сервисов. Каждый сервис с отдельной БД. Не сказал бы, что они микро. Мне не нравится. Любители копипаста. Нужен новый схожий проект — создают новый репозиторий в гитлабе, склонированный из старого, копируют базу и поехали менять. Надеюсь всё это выбросить и переделать в один универсальный сервис с единой БД. Хотя не факт, что дадут.
Ну вот и мы при начале проектов обычно приходили к тому же выводу, что будет много накладных расходов на синхронизацию баз или запросов между базами и решали использовать одну бд на несколько веб-сервисов.
Здравствуйте, vsb, Вы писали:
vsb>Здравствуйте, vaa, Вы писали:
BE>>>Кто как делает? vaa>>не имел дел. но где-то у Александреску читал, что основная причина появления таких архитектур, что ЯП типа джава потребляет слишком много ресурсов. vaa>>в отличии от нативных ЯП. Я и сам удивлялся сколько гласфишу нужно памяти для пары крохотных веб-приложений.
vsb>Тут можно схитрить и не запускать отдельный сервер приложений для каждого микросервиса. Тогда накладные расходы на каждый микросервис будут небольшими. Правда там свои проблемы появляются, но в целом решаемые. Хотя это старые и не модные технологии нынче. Поэтому да, по факту жава жрёт память дико, если жалко гигабайта на каждый микросервис, лучше от жавы сразу отказываться в пользу го, ноды или пайтона.
Один сервис — один докер контейнер или ВМ. Иначе смысла нет. Даже перезапуск веб-сервера перезапускает все сервисы сразу. Ничем не будет отличаться от монолита.
Здравствуйте, BlackEric, Вы писали:
BE>Один сервис — один докер контейнер или ВМ. Иначе смысла нет.
Почему?
BE>Даже перезапуск веб-сервера перезапускает все сервисы сразу.
Перезагрузка компьютера тоже перезапускает все сервисы сразу, докер там или не докер.
BE>Ничем не будет отличаться от монолита.
Почему? Для меня отличие монолита от микросервиса в "толщине" границ. А что там используется для запуска — докер, процесс ОС или сервер приложений — это уже детали реализации.
G>А разве не возможность делать изи горизонтальное масштабирование?
ну да. и вообще тут вопрос выбора должен определятся тем действительно ли будет перегружено приложение? или в итоге все усилия будут потрачены впустую.
опять вспомнил доклад рича хикки от 2012 "значение значений".
там он предлагает уходит от "программирования на месте" к иммутабельному ФП аргументируя это тем что уже 5-10 лет железо не проблема. хватит мол экономить на байтах.
странно конечно слышать такое от сишника.
вот александреску так не считает. нам все еще нужны быстрые программы с малым потреблением ресурсов.
у раста в этом смысле есть будущее. если учесть что он на достаточно медленном llvm работает дебианбенчмарки впечатляют.
Здравствуйте, BlackEric, Вы писали:
vsb>>Тут можно схитрить и не запускать отдельный сервер приложений для каждого микросервиса. Тогда накладные расходы на каждый микросервис будут небольшими. Правда там свои проблемы появляются, но в целом решаемые. Хотя это старые и не модные технологии нынче. Поэтому да, по факту жава жрёт память дико, если жалко гигабайта на каждый микросервис, лучше от жавы сразу отказываться в пользу го, ноды или пайтона.
BE>Один сервис — один докер контейнер или ВМ. Иначе смысла нет. Даже перезапуск веб-сервера перезапускает все сервисы сразу. Ничем не будет отличаться от монолита.
Ну так сейчас уже поверх докеров и куберов накручивают опеншифт, очень удобная штука, решает ряд головняков. Так что микросервисная парадигма эволюционирует и развивается. Я считаю, что монолит — это прошлый век и ретроградство, тупиковая ветвь развития. Микросервисы лучше по многим показателям, пусть ещё пока имеют слабые стороны и нерешенные проблемы, их решение — вопрос времени.
Здравствуйте, rosencrantz, Вы писали:
BE>>Я тоже считаю, что плодить множество действительно микросервисов с кучей баз данных повышает трудоемкость разработки и поддержки проектов. В первую очередь — это необходимость согласовывать изменения между сервисами. И невозможность вытащить данные из одной бд sql запросом.
R>Оверхед на микросервисность (и ценность микросервисности) зависит от размера организации — чем больше организация, тем меньше оверхед, и тем больше ценность. Микросервисность — это в первую очередь про изоляцию команд друг от друга. Если речь идёт про 100 команд по 10 человек, вопрос изоляции/автономности есть и он важен. Когда одна команда из 5 человек начинает себе микросервисы делать, это конечно глупость.
Кроме изоляции команд, вторым мотивом является возможность дешевого горизонтального масштабирования. Если про это забыть, то даже у маленьких команд в 5 человек, реализующих по-старинке монолит, может настать момент когда они попадут со своим монолитом в ловушку масштабирования. У нас так один раз случилось, делали небольшой командой монолит, начали выводить на рынок, рынок захотел сразу много всяких новых фич, начали эти фичи прикручивать, уперлись в том, что монолит просто физически не справляется с задачами, диктуемыми рынком. Начали как говориться "распиливать монолит", потому что иначе невозможно распределить нагрузку. А если бы в начале подумали о масштабировании и изначально бы делали микросервисы, то проблемы бы не было.
Здравствуйте, vaa, Вы писали:
vaa>там он предлагает уходит от "программирования на месте" к иммутабельному ФП аргументируя это тем что уже 5-10 лет железо не проблема. хватит мол экономить на байтах.
Я в этом не эксперт. Но моё понимание такое: иммубательное ФП хорошо для процессоров с огромным числом ядер. Там работает модель с акторами, передачей сообщений. Чтобы было минимум синхронизаций через общую память. В идеале общей памяти вообще не должно быть. В 2012 году вероятно было представление, что число ядер будет расти. Правда расти оно начало лишь спустя 8 лет. В общем, имхо, когда у нас в ноутбуках будут тысячеядерные процессоры, в этом будет смысл.
vaa>вот александреску так не считает. нам все еще нужны быстрые программы с малым потреблением ресурсов. vaa>у раста в этом смысле есть будущее. если учесть что он на достаточно медленном llvm работает дебианбенчмарки впечатляют.
А ещё в последние годы всё актуальней встаёт вопрос безопасности со всех сторон.
Здравствуйте, gyraboo, Вы писали:
BE>>>Я тоже считаю, что плодить множество действительно микросервисов с кучей баз данных повышает трудоемкость разработки и поддержки проектов. В первую очередь — это необходимость согласовывать изменения между сервисами. И невозможность вытащить данные из одной бд sql запросом.
R>>Оверхед на микросервисность (и ценность микросервисности) зависит от размера организации — чем больше организация, тем меньше оверхед, и тем больше ценность. Микросервисность — это в первую очередь про изоляцию команд друг от друга. Если речь идёт про 100 команд по 10 человек, вопрос изоляции/автономности есть и он важен. Когда одна команда из 5 человек начинает себе микросервисы делать, это конечно глупость.
G>Кроме изоляции команд, вторым мотивом является возможность дешевого горизонтального масштабирования. Если про это забыть, то даже у маленьких команд в 5 человек, реализующих по-старинке монолит, может настать момент когда они попадут со своим монолитом в ловушку масштабирования. У нас так один раз случилось, делали небольшой командой монолит, начали выводить на рынок, рынок захотел сразу много всяких новых фич, начали эти фичи прикручивать, уперлись в том, что монолит просто физически не справляется с задачами, диктуемыми рынком. Начали как говориться "распиливать монолит", потому что иначе невозможно распределить нагрузку. А если бы в начале подумали о масштабировании и изначально бы делали микросервисы, то проблемы бы не было.
Здравствуйте, vsb, Вы писали:
G>>Кроме изоляции команд, вторым мотивом является возможность дешевого горизонтального масштабирования. Если про это забыть, то даже у маленьких команд в 5 человек, реализующих по-старинке монолит, может настать момент когда они попадут со своим монолитом в ловушку масштабирования. У нас так один раз случилось, делали небольшой командой монолит, начали выводить на рынок, рынок захотел сразу много всяких новых фич, начали эти фичи прикручивать, уперлись в том, что монолит просто физически не справляется с задачами, диктуемыми рынком. Начали как говориться "распиливать монолит", потому что иначе невозможно распределить нагрузку. А если бы в начале подумали о масштабировании и изначально бы делали микросервисы, то проблемы бы не было.
vsb>Ничего не мешает монолиту быть масштабируемым.
Если ты про горизонтальное масштабирование монолита, то да, но все равно придется реализовывать распределенные функции (иначе монолиты начнут перезатирать бд друг у друга и прочие косяки, связанные с неумением в распределнное взаимодействие), и тогда сама "монолитность" становится избыточным свойством такой системы, и переход на микросервисы становится неизбежным.
Расцвет микросервисов закончился. Uber преобразовывает тысячи микросервисов в более управляемое решение [1]; Келси Хайтауэр предсказывает, что будущее за монолитами [2]; и даже Сэм Ньюман заявляет, что микросервисы никогда не должны быть выбором по умолчанию, а скорее крайним средством [3].
То что сервисы (микросервисов не бывает) должны быть крайним средством — это факт. Но вот монолиты тоже не вариант, так как их сложно поддерживать.
BE>Я вот сам трушных микросервисов ни разу не встречал. Так что бы 1 сервис — 1 бд. Обычно делали 1 ил 2 бд к которым подключались несколько сервисов.
Я встречал. В Амазоне это сделано наиболее правильно из всего, что я видел. Границы сервисов — это границы команд. И публичный интерфейс сервисов — это то, о чём договорились на берегу.
BE>Я тоже считаю, что плодить множество действительно микросервисов с кучей баз данных повышает трудоемкость разработки и поддержки проектов. В первую очередь — это необходимость согласовывать изменения между сервисами. И невозможность вытащить данные из одной бд sql запросом.
При масштабах, на которых нужны сервисы, обычно данные одним запросом вытащить уже вообще нельзя.
Расцвет микросервисов закончился. Uber преобразовывает тысячи микросервисов в более управляемое решение [1]; Келси Хайтауэр предсказывает, что будущее за монолитами [2]; и даже Сэм Ньюман заявляет, что микросервисы никогда не должны быть выбором по умолчанию, а скорее крайним средством [3].
C>То что сервисы (микросервисов не бывает) должны быть крайним средством — это факт. Но вот монолиты тоже не вариант, так как их сложно поддерживать.
BE>>Я вот сам трушных микросервисов ни разу не встречал. Так что бы 1 сервис — 1 бд. Обычно делали 1 ил 2 бд к которым подключались несколько сервисов. C>Я встречал. В Амазоне это сделано наиболее правильно из всего, что я видел. Границы сервисов — это границы команд. И публичный интерфейс сервисов — это то, о чём договорились на берегу.
BE>>Я тоже считаю, что плодить множество действительно микросервисов с кучей баз данных повышает трудоемкость разработки и поддержки проектов. В первую очередь — это необходимость согласовывать изменения между сервисами. И невозможность вытащить данные из одной бд sql запросом. C>При масштабах, на которых нужны сервисы, обычно данные одним запросом вытащить уже вообще нельзя.
Будущее за в меру упитанными и воспитанными микросервисами.
Здравствуйте, gyraboo, Вы писали:
G>Если ты про горизонтальное масштабирование монолита, то да, но все равно придется реализовывать распределенные функции (иначе монолиты начнут перезатирать бд друг у друга и прочие косяки, связанные с неумением в распределнное взаимодействие), и тогда сама "монолитность" становится избыточным свойством такой системы, и переход на микросервисы становится неизбежным.
Просто запускаешь монолит на N-серверах и роутишь запросы к нему. Про перезатирать бд друг у друга — я не понял. БД одна обычно и для БД разницы нет, идут к ней 10 коннектов от одного сервера или от 10 разных. Единственное, про что нужно думать, это про распределённый кеш, но решений для этого хватает и ничего изобретать не нужно. Почему переход на микросервисы становится неизбежным — я не понимаю.
Если упрёшься в БД, то масштабирование БД это отдельная тема, опять же никак не зависящая от монолитов или микросервисов.
Здравствуйте, vsb, Вы писали:
G>>Если ты про горизонтальное масштабирование монолита, то да, но все равно придется реализовывать распределенные функции (иначе монолиты начнут перезатирать бд друг у друга и прочие косяки, связанные с неумением в распределнное взаимодействие), и тогда сама "монолитность" становится избыточным свойством такой системы, и переход на микросервисы становится неизбежным.
vsb>Просто запускаешь монолит на N-серверах и роутишь запросы к нему. Про перезатирать бд друг у друга — я не понял. БД одна обычно и для БД разницы нет, идут к ней 10 коннектов от одного сервера или от 10 разных. Единственное, про что нужно думать, это про распределённый кеш, но решений для этого хватает и ничего изобретать не нужно. Почему переход на микросервисы становится неизбежным — я не понимаю.
vsb>Если упрёшься в БД, то масштабирование БД это отдельная тема, опять же никак не зависящая от монолитов или микросервисов.
Под перезатиранием БД я имею ввиду, что монолиты часто проектируются так, как будто бы у 1 экземпляра монолита 1 БД в эксклюзивном доступе, без оглядки на то, что одой БД могут пользоваться несколько копий монолита. Например, какие-нибудь таблицы с информацией о настройках — юзер меняет через UI глобальные настройку, и все монолиты подцепят эту настройку, чего бы не хотелось. Или таблицы с текущей информацией по каким-то идущим процессам на текущем инстансе (его "подцепят" и другие инстансы, чего бы не хотелось). И получается, что дял того, чтобы несколько монолитов работали с одной БД и не мешали друг другу, не перезатирали части данных или не подцепляли данные от другой копии, нужно проектировать монолит так чтобы он работал распределенно, а это уже первый шаг к микросервисам.
от 2012 "значение значений".
