Comments 6
Все сомнения начали быстро рассеиваться, когда вместо расчётных пиковых 40 транзакций в секунду, мы начали получать минимально.
Сколько начали получать? Как?? Или это куда??
И в целом читается как плохой машинный перевод
Практика показала, что неприятие такой архитектуры микросервисов очень значительно. Чаще всего используются слова "слишком дорого", но что если организации простой служит дороже?
Архитектура определяется нефункциональными требованиями. Требования к надежности нужно прорабатывать очень аккуратно, поскольку в зависимости от ответов, стоимость решения будет варьироваться на порядки.
В теории, ни DDD, ни CQRS ни какой конкретики и ни каких гарантий в этом плане не предлагают. Поэтому играют скорее гигиеническую роль. Ну как умение стильно одеваться - на среднюю продолжительность жизни.
На самом деле из статьи не понятно, как вы рассчитывали надежность решений, которые сравниваете. Без цифр все выглядит довольно сомнительно.
Метрики реальных проектов уже мне не показать. Да и нет в этом никакой необходимости - все крупные организации делают это одинаково - стенды нагрузочного тестирования, SLA, расследование инцидентов и т.п. Я бы сказал, что надёжность - это как раз НФТ, а не архитектура. Это требование куда больше зависит от процесса и вашей инфраструктуры. Описанное выше - это про T2M, perfomance, slalability в первую очередь.
Один из примеров описывал продукт в котором пользователи росли кратно. Закрученная пружина маркетинга далеко не сразу, но очень скачкообразно привела миллионы новых клиентов. Насколько слышал от коллег, большинство строят свою надёжность от конкретных цифр, после чего по мере роста аудитории, доступность падает, требуется пересмотр решения. Наш ответ на подобное плавающее НФТ заключался в работе над типовым микросервисом и связке его с облаком, ит-услугами, с целью формирования сценариев масштабирования.
С одной стороны, я подумаю как осветить в будущих статьях тему доступности, развивающих описанное выше. С другой стороны, мне казалось что слова CloudNative и облако говорят сами за себя - SLA, OPEX/CAPEX обычно подразумеваются (возможно это мои домыслы).
Тем самым, простите, но косвенно отсылаю вас к другим материалам на тему надёжности, которые фокусируются на методологии.
Я бы сказал, что надёжность - это как раз НФТ, а не архитектура. Это требование куда больше зависит от процесса и вашей инфраструктуры
Несколько раз прочитал. Не понял логику, что означает утверждение "надёжность - не архитектура"?
А дальше - перепутаны паровоз и вагоны. Выше @funca верно сказал - " Архитектура определяется НФТ", а не наоборот. Это инфраструктура должна подчиняться требованиям надёжности и прочих НФТ. На то они и требования
В идеале наверное да (да и видно что я описался). Базово, согласен. На практике, далеко не любая инфраструктура позволяет получить SLA 99%, не любые требования могут быть реализованы так, как кто-то хочет, далеко не любую архитектуру можно реализовывать по "политическим" решениям. НФТ напрямую не определяют архитектуру, а являются вводными для принятия архитектурно-важных решений. Надеюсь, что все мы разделяем архитектуру и дизайн системы, в том смысле, что первое - это решения трудоёмкие к изменению, а второе - это все детали решения.
На мой взгляд, смысл CN - в том что если всё реализовано правильно, надёжность дело наживное до определённого момента. Я упомянул про облако, про его ИТ-услуги, про зоны доступности - на мой взгляд, это говорит о заданном вопросе до определённой степени. Хорошая вводная на эту тему в книге указанной в источнике: Облачные архитектуры: разработка устойчивых и экономичных облачных приложений | Лащевски Том, Арора Камаль, Фарр Эрик, Зонуз Пийум | 978-5-4461-1588-4
Применение DDD. От моделей до EDM — поиск новых форм и архитектурные излишества