RK
и где тут слабосвязанность? одна точка отказа. отказала и всё - туши свет. каламбурчик :)
мой вопрос — а нужны ли плюшки микросервисов в данном случае? ну база часто у вас падает (падала бы)?
Size: a a a
2017 May 25
IK
понятно, что это очень дорогой вопрос :) но если представить? хранимки не в разных базах, а в одной? одна база бы по перфомансу потянула бы?
а это вопрос, от ответа на который я пришел к тому что у нас все-таки MSA. дело в том, что изначально делали классический монолит. Настолько классический, что там там было совсем все - даже аутентификация и авторизация. но как говорилось выше - из-за требования высокой скорости изменения - не взлетело. попилили - дело пошло.
KB
"попилили" звучит интригующе 😉
RK
а это вопрос, от ответа на который я пришел к тому что у нас все-таки MSA. дело в том, что изначально делали классический монолит. Настолько классический, что там там было совсем все - даже аутентификация и авторизация. но как говорилось выше - из-за требования высокой скорости изменения - не взлетело. попилили - дело пошло.
а пытались запустить?
IK
мой вопрос — а нужны ли плюшки микросервисов в данном случае? ну база часто у вас падает (падала бы)?
Тут понимаете как. У нас MSA в результате образовался потому что MSA, а потому что требовалось разделить скорости обновленией и самое главное ответственность владельцев сервисов. собственно как только несколько раз люди получили недоступность из-за смежников, следующая система всегда стартовала так - нам нужна система полностью независимая от ... ну и т.д.
IK
"попилили" звучит интригующе 😉
куда ж без этого. но это от архитектуры не зависит. пилили и после.
RK
Тут понимаете как. У нас MSA в результате образовался потому что MSA, а потому что требовалось разделить скорости обновленией и самое главное ответственность владельцев сервисов. собственно как только несколько раз люди получили недоступность из-за смежников, следующая система всегда стартовала так - нам нужна система полностью независимая от ... ну и т.д.
Cпасибо за развернутый ответ! 👍 Отдельное спасибо за информацию о метриках: 60 сервисов, 40 разработчиков, 2-3 разработчика на сервис — стало понятней.
KB
Да, большое спасибо!👍🏻
IK
а пытались запустить?
в смысле пытались? оно даже работало, до сих пор ядро служит в плане CRM. (хотя и кривое и косое и съело много нервов и ресурсов). сам подход был признан неэффективным. кроме того, свою роль сыграл переход на тотальную виртуализацию.
RK
в смысле пытались? оно даже работало, до сих пор ядро служит в плане CRM. (хотя и кривое и косое и съело много нервов и ресурсов). сам подход был признан неэффективным. кроме того, свою роль сыграл переход на тотальную виртуализацию.
я это и имел в виду, спасибо за пояснения
IK
Поделитесь плиз статистикой. Сколько микросервисов, сколько разработчиков, сколько запросов на доработку по каждому сервису появляется в неделю? Не слишком много хочу знать? 😃
дело в том, что скорость непостоянна - на старте может и много быть, потом в большинстве систем все сходит на нет. но есть системы где может быть и 2-3 запроса в неделю. у нас длинный цикл - 1 месяц приблизительно. это связано с внешними условиями работы (принятие законов, нормативных документов). но зато компенсируется жесткостью соблюдения сроков.
AS
Соглашусь, кроме того показательным является тот факт, что успешное внедрение микросервисов с их плюсами и минусами в настоящий момент есть только в организациях с быстро меняющимися бизнес функциями и сложной командой. Типа Amazon, Uber и Netflix. А среднестатистический ынтерпрайз микросервисы в их каноническом исполнении могут принести лишнюю сложность и крайне мало выгод
А монолит сложность не приносит? Она там закопана настолько глубоко, что только могила исправит. Все зависит от того сколько времени бизнес готов терпеть релизы раз в полгода из которых половина тестирование. А штат тестировщиков превышает штат разработчиков раза в два.
RK
А монолит сложность не приносит? Она там закопана настолько глубоко, что только могила исправит. Все зависит от того сколько времени бизнес готов терпеть релизы раз в полгода из которых половина тестирование. А штат тестировщиков превышает штат разработчиков раза в два.
Про релизы раз в полгода и штат тестировщиков -- это случай из жизни? :)
AS
Это и есть жизнь в кровавом энтерпрайзе :)
RK
Монолит не такой уж монолит. Я же спрашивал что такое 'монолит'? Единый экзешник?
RK
Или все-таки всего лищь отдельный класс и формочка в большом приложении?
MS
А монолит сложность не приносит? Она там закопана настолько глубоко, что только могила исправит. Все зависит от того сколько времени бизнес готов терпеть релизы раз в полгода из которых половина тестирование. А штат тестировщиков превышает штат разработчиков раза в два.
Встречный вопрос - что должно релизиться не раз в полгода в среднестатистической компании для бизнес-приложения, который автоматизирует, например, управленческий учёт? Или расчет на то, что фанаты новых технологий из ИТ-службы будет постоянно рефакторить, менять платформы и внедрять новые плюшки?
Ещё раз, никто не говорит, что что одно - это априори плохо, а другое - хорошо (почти никто в этом чате😉). Речь о том, что всему своё место, и пока у довольно большого количества компаний бизнес - и соответственно ИТ-экосистема не меняется с такой частотой и на таком уровне сложности, чтобы микросервисы были безоговорочно оправданы.
Ещё раз, никто не говорит, что что одно - это априори плохо, а другое - хорошо (почти никто в этом чате😉). Речь о том, что всему своё место, и пока у довольно большого количества компаний бизнес - и соответственно ИТ-экосистема не меняется с такой частотой и на таком уровне сложности, чтобы микросервисы были безоговорочно оправданы.
RK
А еще все забыли про agile :) Что помешает бравой команде разработчиков релизить монолит ежемесячно?
AS
Цикл тестирования
RK
А в микросервисах тестирование какое-то другое?