Не начинайте с микросервисов в продакшене — монолиты вам в помощь Перевод
Это перевод статьи Arnold Galovics про то, почему начинать с микросервисов для совершенно нового проекта часто бывает плохой идеей (ссылки и продолжение в конце перевода).
Arnold Galovics, December 16, 2021
Микросервисы становятся естественными, и нам почти кажется, что мы всегда жили в мире микросервисов. Недавно, когда я разговаривал с другими разработчиками и спрашивал, как они будут запускать проект с нуля, почти наверняка ответ был, ну, один микросервис для этого, другой для этого, еще один для управления пользователями, еще один для аутентификации, еще один для авторизации, еще один для управления сеансом, и этот список можно продолжить.
Я попытаюсь пролить свет на то, о чем никто не говорит, когда речь идет о микросервисах. И да, это будет личный опыт прошлых проектов, над которыми я работал.
Ложь
Я собрал некоторые плюсы использования микросервисов, которые упоминаются в других статьях:
- Локализация отказов
- Устранение технологической блокировки
- Более легкое понимание
- Более быстрое развертывание
- Масштабируемость
И да, это не ложные обещания в книге, но я должен быть честен с вами, это не так просто с вашей системой только потому, что вы используете микросервисы.
Позвольте мне разбить каждое преимущество из списка.
Изоляция неисправности. Поскольку приложение состоит из нескольких служб, если одна из них выйдет из строя или с ней что-то случится, пострадает только эта часть системы. Подумайте о Netflix, когда вы смотрите сериал, вас не интересуют рекомендации. Итак, если у них есть служба для обработки текущих наблюдателей и предоставления им видеопотока; и у них есть еще один сервис для обработки личных рекомендаций пользователей. Если служба рекомендаций выйдет из строя, это не повлияет на наиболее важные функции в их системе, т.е. просмотр шоу. Неисправность изолирована.
Устранение технологической блокировки. Подумайте о монолитах. Это огромное приложение с сотнями/тысячами API, управляемыми сотнями таблиц базы данных. Приложение было написано на Java, и команда потратила на его разработку последние 5 лет. Появляется причудливый новый язык, который на бумаге обеспечивает лучшую производительность, лучшую безопасность и так далее. Это может быть Go/Rust, и команда хочет поэкспериментировать с языком и его техническим стеком. Как они могут сделать это в монолитной среде? Они не могут, потому что это единый пакет развертывания. Вы можете просто — по крайней мере, нелегко — переключать части приложения на разные языки.
В то время как с микросервисами вы можете использовать разные стеки технологий для разных сервисов. Служба A может быть написана на Java, служба B может быть написана на Go, служба C может быть написана на Whitespace, если вы достаточно смелы. 
Легче понимания. Когда у вас есть несколько служб, отвечающих за меньшую часть общей функциональности, служба будет по своей природе меньше, а значит, ее будет легче понять.
Более быстрое развертывание. В обычной монолитной системе вы либо полностью развертываете, либо не развертываете вообще. У вас есть один пакет для развертывания, и это сценарий «все или ничего».
С микросервисами у вас есть возможность развертывания независимо, а это означает, что если вам нужно развернуть обновление до службы рекомендаций (возвращаясь к примеру с Netflix), вы можете полностью развернуть эту единственную службу и значительно сэкономить время.
Масштабируемость. Мой фаворит на все времена. Вы можете масштабировать свои службы, запустив несколько экземпляров, чтобы увеличить емкость для определенной функциональности. Как видно из предыдущего примера, если люди просматривают множество рекомендаций на Netflix, они могут легко запустить несколько экземпляров службы рекомендаций, чтобы справиться с нагрузкой. Находясь в монолитной среде, вы либо масштабируете каждую часть своего приложения, либо ничего.
Микросервисы В Реальной Жизни
Я собираюсь поразить тебя суровой правдой, мой друг. Я не говорю, что эти преимущества недостижимы, но вы, ваш проект, ваша организация должны очень много работать, чтобы сделать их возможными.
Требования К Инфраструктуре
Позвольте мне начать с одной из моих самых больших трудностей с микросервисами.
Инфраструктурный след.
Читать далее: https://arnoldgalovics.com/microservices-in-production/
Вторая часть статьи: Вся правда о том, как начать с микросервисов
Многое из этого резонирует со мной. Организационная структура и инженерная культура очень важны при принятии решения об архитектуре.
В предыдущем стартапе, где было около 50−100 человек, у нас были микросервисы, и это стало смешно. Инициирование успешного развертывания микросервисов привело к тому, что некоторые микросервисы представляли собой всего 1−2 функции, которые на самом деле должны были быть объединены в другие. (В конце концов кто-то заметил и выступил за объединение…).
Свобода выбора языка в сервисах — это хорошо, но на практике может выйти из строя. Например, компания наняла в основном экспертов по NodeJS и несколько человек, знавших Golang. Что ж, их микросервисы были на Go, и… они ушли… а другим пришлось выучить новый язык, чтобы его поддерживать (сама по себе не такая уж и плохая вещь, но вы можете видеть, насколько это может быть проблемой, когда компания пытается масштабироваться). !).
Честно говоря, я не думаю, что проблема заключалась в том, что они использовали микросервисы, а скорее в том, насколько легко (замечательные) ребята из DevOps смогли развернуть новые микросервисы, и в свободе, которая была предоставлена всем.