Какие проблемы решают микросервисы?

Проще:
Писать
Тестировать
Деплоить
Включать в свой проект
Сохранять версии
Групировать
И многое другое.

цель микросервисов — достичь хорошего горизонтального масштабирования. Микросервисы позволяют выполнять ряд задач намного гибче. Если анализ показывает что узким местом является конкретный сервис, достаточно просто запустить его копию. По ресурсам — намного менее затратно.

Важно понимать, что микросервисы применимы не везде. Наибольшим препятствием для использования микросервисов являются CAP-теорема и распределенные транзакции. Микросервисы — это хорошо тогда, когда они реально «микро» и реально изолированы друг от друга.

я вижу только один жирный плюс - микросервис можно написать на любом случайном языке, который умеет в сеть.

А ещё микросервисы позволяют писать на разных языках, выбирая для каждой отдельной задачи наиболее пригодный.

микросервисы

Неплохая криокамера, где брал?

Ага.

А сейчас чего модно? Я просто как-то не слежу.

Можно переписать за 2 недели (ну или за 2 месяца).

Можно обмазать тестами.

Упал один — упал только один.

Лямбды и серверлесс.

Спроси разрабов Postfix

Это скорее вопрос организации людей, чем приложения. Можно нанять какого-нибудь баклана по дешёвке, чтобы он добавил Фичу Икс и не поломал всё остальное. А если накосячит - то просто избаиться от него и нанять другого ещё дешевле.

Это кстати тоже.

Главное их можно собирать вместе по мере необходимости.

И не волнует где сервис, на чём он ниписан.

С микросервисами получается более тонкое масштабирование, т.к. масштабируется только то, что требуется в данный момент и настолько, насколько требуется, а не сразу + целая VM. Это дешевле в эксплуатации, вот и вся история. Как уже сказали, сейчас модно лямбды и серверлесс, что выходит ещё дешевле.

Всякую охинею про «проще тестировать», «можно писать на любом языке» и т.п. морковки для гребцов можно не рассматривать - это на самом деле никого не волнует.

Ну, тот свежий утырок которого эффективные менеджеры посадят после тебя, скорее всего обосрется. Потому что большая картина видна хуже.

Я всегда думал, чио микросервисы, это тот самый юникс вей. Ну типа одна программа, которая делает что-то, и которую можно скомпоновать с другой.

Можно быстрее найти инвесторов.

Микросервисы не решают никаких проблем. Они просто другой тип архитектуры.

Хорошо масштабируется.

Не всегда. Как вариант. Есть доступ к бирже там 1 логин и пароль. паралельные учетки лочатся....

Та же фишка, что и у модификаторов private/public. Легче контролировать, что может сломать систему и насколько.

Решают проблему занятости девопсов

Я всегда думал, чио микросервисы, это тот самый юникс вей.

Проблема в том, что мы живём во времена нарастающего кома оверинжиниринга. Программу, выводящую «hello world» предлагается разбить минимум на два сервиса, выводящих «hello» и «world», которые должны быть запущены в облаке amazon.
А когда вы задаётесь вопросом «что за нах», вы обнаруживаете, что все прочие способы объявлены устаревшими и не поддерживаются.

ты пропустил сервис мониторинга сервисов, сервис запуска сервисов, сервис мониторинга сервиса запуска сервисов как минимум.

У меня как раз такой случай...

Видел микросервисы даже там, где испокон веков ничего не масштабировалось.

лямбды и серверлесс

это вообще параллельные штуки

даже там, где испокон веков ничего не масштабировалось

Жертвы хайпа. Бывает.

параллельные штуки

Написано же через «и». Может ты не понял о чём речь?

Проще масштабировать(в том числе и в плане отказоустойчивости) систему где издержки на i/o незначительны при коммуникации подсистем. Легче прототипировать.

Спорный вопрос - возможность писать подсистемы на разных языках(для коммерческого применения бесполезно в 90% случаев, за исключением прототипирования см. выше). Был у на COM, Corba и D-BUS(ну технически он даже есть). По факту ими пользуются масштабно разве что только их создатели.

Это всё. Остальное лишь дополнительные накладные расходы и недостатки. Все остальные преимущества которые приписывают этой технике призванной помочь гигантам и придушить сявок в зародыше покрываются библиотеками и грамотным выбором клея, если таки хочется писать на разных(а обычно это максимум 2 один для прототипа/мокапа/фейка второй для няшной реализации) языках.

Маркетинговая копипаста, а с Микросервисы — это хорошо тогда, когда они реально «микро» даже Ричардсон не согласен.

А обоснование такой точки зрения у тебя есть?

Можно быстрее найти инвесторов

Это скорее следствие.

Они просто другой тип архитектуры.

Есть вещи, которые микросервисами получаются лучше.

Создание искуственных границ между отдельными частями системы чтобы они могли разрабатываться и релизиться своим жизненым циклом. Потом возможно даже огранизационно разные сервисы могут передаваться в разные команды, так как интерфейсы поддерживались в лучшем состоянии, чем в случае гигантского мегаприложения.

Даже в плане ресурсов с каждым компонентом ассоциируется разное соотношение потребления процессора и памяти. Если у тебя система навигации по картам, то скейлить инстансы, которые в памяти держат карты городов, лучше отдельно чем другие сервисы.

Если бы все было вместе, то каждый инстанс содержал бы полный набор нужных данных для приложения.

Юниксвей нужен когда у тебя каждый день возникают всякиа мелкие разноплановые задачи - сегодня ты сделал файнд + сед, завтра греп + курл. Микросервисы же никто каждый день не переставляет по очередности.

огранизационно разные сервисы могут передаваться в разные команды

Ага, ты не можешь передать права на половину репозитория. А с микросервисами всегда можно докинуть аутсорсеров если своих людей не хватает.

Микросервисы же никто каждый день не переставляет по очередности.

Завтра вылезает новый проект, а у тебя уже готов компонент.

У кого какие аргументы за?

Когда у тебя 100500+ разрабов и еще больше денег, то это наверное удобно. Можно каждому дать задание написать класс-сервис. А затем запустить их в облаке, переплатив за это всё в десятки-сотни раз дороже дедика с хетцнера со стендалон приложением. В общем, самое то для освоения денег инвесторов.

Ага, ты не можешь передать права на половину репозитория

Слышал что-нибудь про разбиение проекта на модули (библиотеки)?

Получаются лучше, но не решают...

Есть вещи, которые микросервисами получаются лучше.

Нету, но есть просто сервисы (без микро), когда их действительно полезно вынести в отдельное приложение на отдельный сервер (не контейнер), чтобы съесть все его ресурсы и не мешать есть ресурсы основного сервера, основным приложением.

что-то неочевидны преимущества в этом плане перед вариантом, когда у вас на каждую задачу по .so, а не по микросервису

Зришь в суть.

что-то неочевидны преимущества в этом плане перед вариантом

Связанность меньше, можно раскидывать по куче хостов.

По хостам, как правильно подсказывают выше, просто сервисы раскидывают, а не -микро. Можно, конечно, каждый сервис в своей песочнице, только непонятно зачем.

По хостам, как правильно подсказывают выше, просто сервисы раскидывают, а не -микро

Что мешает раскидывать микро?

Написано же через «и». Может ты не понял о чём речь?

если вы про гугло-что-то-там и амазон- AWS сервисы с облаком, то там сферические микросервисы в вакууме

можно и микро, просто это не ответ на вопрос, зачем именно микро

Чтоб в большой куче дерьма не приходилось рыться же. Оно типа да, юникс-[ой-]вей. Входные данные - обработка - выходные данные. Ты можешь всё загнать в эту тупую схему. Ты можешь контролировать обработку (нагрузка и т.п. херово работает, бьёшь кодера током. Можно сделать скрипт на баш для этого) Ты можешь контролировать вход/выход без того, чтобы залазить в кишки. То есть юнит тесты уходят из самого кода, у тебя приложение и есть юнит. Подключаешь его куда-нибудь и тестишь (вспомни про баш скрипт). Выхлоп можно перенаправлять, мониторить, грепать, сваливать в логи, выкидывать из логов и всё это без пересборки/остановки/передеплоя. Многопоточка становится не нужна, по большей её части. Короче гибче всё становится.

Хотя вышесказанное относится больше к pipeline архитектуре, чем к микросервисам, но последние без первого нахер не нужны, ибо тот же монолит, только по сети.

сферические микросервисы в вакууме

Там много чего есть, речь про лямбды, которые ни разу ни микросервисы и вообще не сервисы/серверы в обычном понимании.

Завтра вылезает новый проект, а у тебя уже готов компонент.

Есть такая штука - переиспользование кода, существует отдельно от микросервисов.