Comments 6
Микросервисная архитектура не была ответом на задачу быстрейшего CI/CD. Она решает ровно одну проблему — нехватку team lead'ов на всех. team lead тщательно думает про интерфейсы, а дальше джуниоры в пределах интерфейсов творят любую фигню. Если это важная фигня, то её фиксят. Если это не важная фигня, то она так и страдает в углу, не задевая при этом приложения.
Если bottleneck'а в teamlead'ах нет, или нет сильных teamlead'ов, вытаскивание микросервисов, это отличный метод перевести лапшу в коде в лапшу в инфраструктуре, которую будут отлаживать… кто?
Короче, удачи. Пачка миддлов, решившая поиграть в микросвервисы в отсутствие тимлида и сильной команды админов — это новый антипаттерн для долгострочного, глубокого, фундаментально-персистентного факапа всея проекта с вынесением момента факапа на несколько итераций разработки в будущее.
— для тех, кому надо будет искать работу есть вопрос о том, какие навыки стоит иметь
— для тех, кому надо нанимать, надо понимать какой идеологии будут придерживаться люди и какие навыки, опять же, будут иметь.
Но вообще, это тема другой статьи :)
То что я во вступлении сказал, это скорее про то, что надо понять что это все не временно и надо учиться жить с тем, что породила эта идеология (толерантность к техническому долгу, которая может привести к проблемам в эксплуатации про которые раньше не думали).
Микросервисы — не решение проблемы, о которой вы говорите. Т.е. это всё равно, что утверждать, что тротуары на улицах — это решение проблемы загрязнённого воздуха. Совершенно ортогональные явления, не связные друг с другом.
Да, бывает так, что админу предлагают это всё "починить", вывалив на него лапшу из коннективити и плавающих api. В принципе, я помню электрика, который отказывался чинить что-либо в доме, где проводка была сделана с помощью knob-and-spool, причём частично. Вот примерно такое же ощущение.
«такой healthcheck должен осмотреть здоровье/доступность критичных для функционирования сервиса систем (доступы до очередей, БД, доступность сервисов И так далее)»
Слишком глубокий healthcheck может привести к расширению радиуса проблемы, если их дергает балансировщик. В случае проблемы с БД или внешним сервисом — все healthcheck-и могут отвалиться и балансировщик может вывести из строя чуть ли не весь флот. Поэтому смотря для чего используется healthcheck — ему стоит или не стоит проверять здоровье внешних зависимостей. Для мониторинга — стоит дергать deep healthcheck (не говоря конечно о том, что внешние зависимости должны иметь и свой мониторинг тоже). Для работы балансировщика — стоит дергать только local healthcheck, который проверяет что сервис локально здоров (память, диск, конфиги, credentials) и способен обрабатывать запросы.
Хорошая статья от AWS с более детальным анализом healthcheck-ов (как и вся коллекция).
Мониторинг микросервисных приложений: взгляд SRE