Отсутствие правильного мониторинга — классическая проблема таких систем.
Одинаково плохо и когда в мониторинге ничерта нет, и когда мониторинг представляет собой пуль управления АЭС с пятью сотнями лампочек и пимпочек. И там нихрена не видно, что не так.  

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

Мне нравится идея макро-сервисов: склад, маркетинг, продажи, доставка. И все. Ну аналитика где-то сборку.
Если 64 микросервиса в 99.5% случаев выкатываются вместе, да еще и в один под, чтобы не тупила сеть, нафиг это не нужно.

Если подытожить. Никогда не видел, чтобы ставился вопрос сравнения условного opex микросервисов и монолита в разрезе затрат на ту же память.
На монолите обычно тяжелее обеспечить SLA, высокий темп разработки и релизов. Для растущего бизнеса это важнее.
Раздутие ФОТа микросервисами - такое в принципе слышу впервые) Закон Конвея не так работает.

Это позиция человека в белом пальто.

Тесты на проприетарные библиотеки тоже предлагаешь писать?

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

Например, libmagic на некоторых файлах может задуматься на несколько часов.

1) Есть разница во времени перезапуска.
2) При падении монолит может ещё что-то покорраптить
3) отказ сервиса должен быть штатной ситуацией с частичной деградацией
4) можно(и нужно) бюджетировать сервисы

На проприетарные библиотеки- да, разумеется. Вообще, откуда эта идея, что для написания тестов надо смотреть в код? Мне почему-то всегда казалось, что надо в API. ))

А чтобы libmagic не тупил, так надо либо вместо него использовать gd2, если это возможно, а если нет — делать конвейер с очередью и таймаутами обработки на каждой стадии.

Т.е. мы берём чужую библиотеку и пишем для неё свои тесты. Я правильно понял идею?

А gd2 тут не причем, потому что речь вот об этом
https://man7.org/linux/man-pages/man3/libmagic.3.html

1) Это не имеет значения если ваш сервис живёт на более чем двух серверах. Мне, например, всё равно, поднимется у меня сервис за 30 миллисекунд или за полчаса. Он как минимум дублирован, а как максимум дублирован 32 раза. Нода может лежать хоть сутки.

2) При падении монолит ломает что-то только если он мультипоточный. Не пишите таких сервисов, если нет навыков делать так, чтобы он не корраптил при падении. В помощь — читать про 2 phase commit, журналы и транзакции

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

4) Мощности вычислительной системы должно заведомо хватать на штатный режим работы плюс перекрытие кратковременных пиков. Ситуация когда сервис регулярно упирается в лимиты в штатном режиме — недопустима.

отказ одного сервиса может приводить к деградации для всех сервисов если соблюдаются SLA. Надежность  не бывает абсолютной. Если мы уже рассматриваем только аспект HA/FT, то развязывание на сервисы не всегда дает увеличенную надежность - если в конкретном сценарии отрабатывают несколько сервисов для успешной работы, то надежность будет  мультипликативной величиной. Поэтому внезапно надежность конечной системы закладывается на этапе дизайна системы, все остальное - костыли

Да. Берём чужую библиотеку и пишем тесты, если её поведение чем-то смущает. Это абсолютно нормально и более того — тестировщики должны и для своих библиотек поступать так же. Как минимум одна фаза тестирования должна быть на совместимость чёрного ящика по API.

Это вообще базовое требование при разработке любой законченной единицы ПО. Будь то библиотека или микросервис, но соглашения по API должны быть протестированы без доступа внутрь.

плохо можно сделать все что угодно, монолит или SOA или микросервисы. Просто с микросервисами это куда проще 🙂

нет такого требования

А, это не тот мэйджик. Так не надо им пользоваться, он кривой, и для большинства задач излишний.
В нашей системе электронной почты мы от него отказались, потому что смысла в этой штуке нет.

Ну, если у вас нет, то и результат выходит в соответствующем виде.

Вы, например, можете вообще писать без покрытия тестами. Или без регулярных проверок безопасности. Кто же вам запретит писать говнокод? Никто, конечно)))

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

Мне вообще до фонаря чужая библиотека, ибо я работаю с фиксированными версиями, соотвественно я не собираюсь менять их постоянно.   Если мне понадобились изменения в сторонней библиотеке/сервисе так же часто, как в моем коде, значит  что-то идет не так)

и да - никто не может дать определение говнокода с позиции - “нет тестов - говнокод”

Значит вы настолько непрофессиональны, что не можете найти ошибку при сценарном использовании.

Это очень печально — писать тесты на то, что проще тестировать, а не на то, что на самом деле приводит к падениям.

Стыдно.

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

Тут нет эмоций. Неспособность написать тесты для сценарного использования — квалифицирующий признак непрофессионализма.