Есть замечательный микросервисный подход к архитектуре ПО, суть которого в обеспечении ортогональности, изолированности (разные БД и контейнеры для каждого микросервиса) и расчлененности ПО.
Вроде, такая архитектура для более-менее больших проектов хороша со всех сторон:
0. Наконец-то заказчик (который в россии всегда лох и самодур невменяемый) не сможет помешать релизу своими хотелками. Хотелки можно быстро реализовывать, а релизы часто выкатывать.
1. Легкое масштабирование - просто запускаем больше контейнеров в нужным микросервисом и http/https-балансер настраиваем на раскидывание запросом.
2. HA из коробки: добавляем в балансер скрипт мониторинга и легко отслеживаем падение какого-то куска ПО (микросервиса), перенаправляя на резервный вызовы приложений.
3. Просто разработать приемлемую архитектуру, рефакторинг через переписывание блоков ПО, а не всего приложения. Просто сменить архитектуру.
4. Простой откат, т.к. откатить можно только куски приложения и их БД, а всего монстра.
5. Простой деплой, т.к. деплоятся только куски. В ходе деплоя другие микросервисы точно не пострадают и выйдут из строя.
6. 9 женщин прогеров наконец-то могут родить за 1 месяц. Можно покупать более дешевых прогеров (т.к. микросервисы можно писать на любом языке, и спецзнания и особый опыт не требуется). Задача разработки прекрасно раскидывается на несколько прогеров, если архитектура составлена правильно и API специфицирован. Поэтому можно даже не держать штат специалистов (кроме архитектора и то не всегда), а прогеров из Индии через интернеты нанимать.
7. Легкое тестирование. Юнит-тесты не нужны: микросервис не большого размера, тестирование осуществляется просто развёрткой контейнера с микросервисом и проверкой ответов на API-запросы.
8. Безопасность. Микросервисы изолированы как в плане БД так и на уровне контейнеров. Взлом одного микросервиса позволяет получить доступ только его данным.
9. Независимость от технологий. Микросерисы работают очереди или простые http/https-запросы, поэтому они могут вообще быть реализованы в гомогенной среде, где часть работает на php в линуксе с mysql, часть на solaris с явой и oracle db, а часть вообще на C# на винде с MS SQL.
Мой вопрос в следующем: когда такая архитектура может не быть лучшем вариантом?
Исключаем джумлы, хелловорлды (мелки проекты), нищеговнище (когда клиент - лох нищебродный и не имеет кластера своего), а также алгоритмы с высокой степенью синхронизации (типа некоторых научных вычислений, нейронный сетей или бигдаты) или требований с сверхнизким задержкам. Кроме этих проблем, вроде, проблема только при программировании на заказ: нам сложно сделать для клиента vendor lock-in своим говнокодом, после чего на платную обязательную поддержку посадить.
Перемещено leave из development
