Какие знаешь плюсы и минусы микросервисного подхода

А, ну это ж классика, блядь! Микросервисы, ёпта! Все сейчас только о них и говорят, как будто панацея от всех бед. Давайте разберем, что за зверь такой, а то в рот меня чих-пых от этой моды.

Плюсы, которые все так любят:

• Масштабируемость: Это когда один сервис, например, с картинками котиков, ложится от нагрузки, а остальным похуй. Ты просто добавляешь ещё серверов для этого одного сервиса, а не для всей своей здоровенной монолитной туши. Удобно, чё.
• Гибкость: Хочешь новый сервис написать на каком-нибудь новомодном языке, где переменные объявляются через «ёмаё»? Пожалуйста, пиши. Остальное пусть на старом добром колхозе работает. Никто не мешает.
• Независимость команд: Каждая команда сидит в своей песочнице и не лезет в чужую. Одна команда делает «сервис оплаты», другая — «сервис доставки». Главное — договориться, как друг с другом общаться, а то будет ебаный бардак.
• Устойчивость: Один сервис накрылся медным тазом? Ну и хуй с ним. Остальные-то работают. Пользователь, конечно, не сможет оплатить заказ, но зато посмотреть каталог товаров — запросто! Удивление пиздец.
• Быстрое развертывание: Не надо каждый раз, когда поправил запятую, разворачивать всю систему, размером с «Войну и мир». Залил обнову в один маленький сервисик — и всё, пошёл пить чай.

Минусы, о которых все скромно молчат (а зря):

• Сложность: Это ж надо всю эту ораву сервисов как-то организовать, чтобы они друг друга находили и не передрались. Оркестрация, блядь! Целый цирк с конями, а не архитектура.
• Нагрузка на сеть: Раньше всё в одной памяти болталось, а теперь каждый чих — это сетевой вызов. «Сервис заказа» спрашивает у «сервиса пользователей», а тот дергает «сервис рейтингов». Половина времени уходит на болтовню между собой, ебать мои старые костыли.
• Сложность отладки: Пользователь нажал кнопку, и всё упало. А где? В каком из двадцати сервисов? Придётся трассировать запрос, который пробежал через пол-интернета, как угорелый. Подозрение ебать чувствую, что где-то косяк.
• Согласованность данных: Вот это вообще пиздец. В монолите была одна база, и данные там были консистентные. А тут у каждого сервиса своя база. «Сервис заказа» говорит: «Заказ оплачен!». А «сервис доставки» такой: «А я нихуя не знаю, у меня статус „ожидает оплаты“». И пошла писать губерния.
• Операционные расходы: Раньше мониторил один сервер, а теперь тебе надо следить за целым зоопарком. Логи, метрики, алерты от каждого. Терпения ноль ебать, чтобы это всё настроить.

Ну и пример, чтобы было понятно, о чём речь:

// Было: один здоровенный монолит, где всё свалено в кучу.
// class OrderService {
//   createOrder() { /* тут и логика заказа, и вызов оплаты, и вызов доставки, и пляски с бубном */ }
// }

// Стало: три отдельных сервиса, которые переругиваются между собой по сети.
// order-service (сервис заказов)
// payment-service (сервис оплаты)
// delivery-service (сервис доставки)

Короче, технология мощная, но не для всех. Если у тебя маленький проект, то нахуй тебе эти микросервисы? Ты их больше времени настраивать будешь, чем писать полезный код. А если система реально большая и команды разбежались по разным этажам (или городам), тогда — да, может и выстрелить. Главное — не прыгать в эту моду с головой, а то будет больно.