Здравствуйте, Cyberax, Вы писали:
S>>Ну а как до изобретения мс работал тот же гугл? Распределенная система была, микросервисов не было. S>>Сложный деплоймент, настройки, но система распределенная и нету никаких микросервисов. C>В Гугле была сервисная система с самого начала, со своим аналогом контейнеров. Не знаю про MS. C>Сервисы были не "микро", это да. Но именно микро-сервисы не очень-то нужны.
А чего микро сразу в мейнстрим не ушли? Чего не хватало -- контейрезация была давно, еще со времен Sun.
Облака? А сильно они нужны, если мы накупим для себя серверов или арендуем дц? Что еще?
Я так понимаю, что с того момента как по лок. сети стало можно прочитать данные из памяти др. машины быстрее чем
с собственного жесткого диска, вот тогда дело и пошло. Т.е. все утыкалось в сеть -- bandwidth, latency.
Или же именно организационные вопросы типа маленьких команд не дозрели?
Кстати, можно сказать, что SOA промежуточный этап эволюции от монолитов к мс?
Здравствуйте, Sharov, Вы писали:
S>Кстати, можно сказать, что SOA промежуточный этап эволюции от монолитов к мс?
с интересом слежу за всей дискуссией
вставлю свои пять копеек
SOA я впервые увидел, пощупал и отведал со всем гуаном, заложенным внутрь менеджерами и продавцами, ещё в 2005
а чуть позже на единой кодобазе, но модульной, с гетерогенным деплойментом со специфическими конфигурациями под каждый элемент в HA-конфигурации и прочим параллелизмом как в обработке потоков информации, так и обновлении — в 2007-2008
при этом баззвордов типа монолит vs микросервисы тогда никто не знал, докеров не было, а всё деплоилось на реальное железо в ДЦ почти пешей доступности
свойства с точки зрения бизнеса были всё те же:
— надо обновить конкретное направление? обновляем конфигурацию с коммитом в svn, пересобираем, тестируем, после удовлетворительных тестов — по одной останавливаем и обновляем ноды в отдельно взятом HA-кластере
— надо усложнить правила обработки? меняем кодобазу с коммитом в svn, пересобираем, тестируем на первом заинтересованном направлении, после удовлетворительных тестов — по одной останавливаем и обновляем ноды в отдельно взятом HA-кластере, по мере вовлечения остальных кластеров — их тоже обновляем
когда сейчас я вижу противопоставление единой кодобазы и микросервисов мне приходит в голову только одна мысль: границы физической ответсвенности за работоспобность модуля не должны быть равны границам программистских способностей, и для меня попытка разделить команды по микрообластям — проблемы неумелого аутсорсинга во всей своей красе
SD>> каждый конкретный сервис отвечает быстро, но суммарное время большое, потому что все выполняется последовательно, и везде сплошные RPC. НС>Так это другая проблема, для лечения которой нужны другие подходы.
C этого места поподробнее. И как же предлагается решать такую проблему в реалиях микросервисов, когда каждый в отдельности работает как задумано, но все вместе — тормозит?
НС>Я ж говорю, это другая проблема, больше из области архитектуры всей системы.
Так вот на моем опыте, в случае с "монолитом" именно такие проблемы (не одной медленной функции, все быстрые, но вместе — тормозят) решается прокручиванием очередной дырочки сквозь десять слоев. Что и цементирует монолит, делая невозможным его дальнейший рефакторинг.
В случае с микросервисами этот трюк попросту не проходит. Что, с одной стороны, плюс, ибо при наличии той самой "политической воли" хранит чистоту API. Но на практике ведет к созданию сервиса "с перламутровыми крылышками", который слепляет функциональность пачки других сервисов, только при этом имеет внутри ту самую дырку сквозь слои. В итоге эффект тот же, что и с монолитом, только теперь распределенный.
S>А чего микро сразу в мейнстрим не ушли? Чего не хватало
Готовых решений. Их, кстати, и сейчас не хватает. Так чтоб это решение было с мониторингом, алармами, масштабируемостью, распределенным трейсингом, деплойментом взад-вперед (slowroll, revert). И чтоб при этом было надежным и простым как в установке, так и в эксплуатации. Потому как если это сложно, то смысл микросервисов резко уходит.
А сложно потому, что решения разрабатывались интеграцией, суть накидыванием, разных софтин в один котел. Каждая со своим подходом и слоями, глюками и особенностями. В итоге либо нужно верить в магию (AWS, GCP и прочие) и непогрешимость облачных провайдеров, либо самому разбираться.
Но если разобраться в чем-то конкретном (или вовсе сделать свое, как поступают очень многие), нужно и хороших специалистов, и много сил. Что для мейнстрима не годится, там надо быстро-вкусно-дешево (выберите чего-нибудь два).
Здравствуйте, SkyDance, Вы писали:
C0s>>и для меня попытка разделить команды по микрообластям — проблемы неумелого аутсорсинга во всей своей красе
SD>А как иначе вы предлагаете работать монструозным компаниям типа гугла?
я до сих пор в сегменте маленьких да уродливых (или удаленьких), уже много лет в философских размышлениях, нужны ли мне мегаразмеры.
большие пусть сами себе грабли раскладывают, у них хотя бы бюджет не предполагает микрооптимизаций
Здравствуйте, Sharov, Вы писали:
C>>В Гугле была сервисная система с самого начала, со своим аналогом контейнеров. Не знаю про MS. C>>Сервисы были не "микро", это да. Но именно микро-сервисы не очень-то нужны. S>А чего микро сразу в мейнстрим не ушли? Чего не хватало -- контейрезация была давно, еще со времен Sun.
Полноценная контейнеризация в Линуксе с cgroup и namespaces появилась в районе 2010-го года. До этого были местечковые решения типа Virtuozzo или vserver, требующие сторонних патчей. Примерно к тому же времени AWS начал экспоненциально расти.
Добавим к этому пару лет на то, чтобы ядра с поддержкой контейнеров проникли в дистрибутивы. Итог: первая версия Docker'а была в марте 2013-го года.
Если говорить не про популярные в народе решения, то внутри Гугла была своя "сервисная" система с середины 2000-х (Babysitter/Borg), внутри Амазона — с начала 2000-х (Apollo).
S>Облака? А сильно они нужны, если мы накупим для себя серверов или арендуем дц? Что еще?
До облачных систем обычно покупали Один Большой Сервер, и ставили на него 100500 разного софта.
S>Я так понимаю, что с того момента как по лок. сети стало можно прочитать данные из памяти др. машины быстрее чем S>с собственного жесткого диска, вот тогда дело и пошло. Т.е. все утыкалось в сеть -- bandwidth, latency. S>Или же именно организационные вопросы типа маленьких команд не дозрели?
Две причины:
1. Организационные вопросы. Именно в начале 2010-х годов начали появляться многочисленные компании с очень большой инфраструктурой.
2. Технические: доступность решений для контейнеризации, доступность крупных вычислительных мощностей. Стало не нужно тратить сразу миллионы долларов на запуск кластера из 100 узлов.
S>Кстати, можно сказать, что SOA промежуточный этап эволюции от монолитов к мс?
Микросервисы — это не пик эволюции, это просто вариант SOA. Со своими недостатками и преимуществами.
Здравствуйте, Ziaw, Вы писали:
НС>>Несоответствие SLA. Z>В моей практике SLA не константа, а какие-то вводные типа "15 февраля в 14:00 к нам придет 20к юзеров в промежутке около 5 минут. Они пройдут примерно по _____ сценарию. Остальная нагрузка будет примерно на прежнем уровне. Платформа должна выдержать.".
Значит, нужно увольнять тех, кто не может сформулировать SLA.
Здравствуйте, C0s, Вы писали:
C>>нужно увольнять тех, кто не может сформулировать SLA. C0s>по моему опыту в контекстах с "большим" бюджетом ответственность за эту формулировку тоже размазывается.?
Ну да. Но большие системы обычно развиваются эволюционно, и в целом можно экстраполировать производительность за счёт нормальных вариаций нагрузки.
Здравствуйте, SkyDance, Вы писали:
НС>>Так это другая проблема, для лечения которой нужны другие подходы. SD>C этого места поподробнее. И как же предлагается решать такую проблему в реалиях микросервисов, когда каждый в отдельности работает как задумано, но все вместе — тормозит?
Ты мне предлагаешь дать тебе рецепты по заочному описанию в виде одной фразы?
НС>>Я ж говорю, это другая проблема, больше из области архитектуры всей системы. SD>Так вот на моем опыте, в случае с "монолитом" именно такие проблемы (не одной медленной функции, все быстрые, но вместе — тормозят) решается прокручиванием очередной дырочки сквозь десять слоев.
Это очень недолго решается. От таких дырочек монолит быстро умирает под тяжестью техдолга.
SD>В случае с микросервисами этот трюк попросту не проходит.
И это один из их плюсов.
SD>Но на практике ведет к созданию сервиса "с перламутровыми крылышками"
Здравствуйте, Cyberax, Вы писали:
C>Значит, нужно увольнять тех, кто не может сформулировать SLA.
Такая вводная приходит всегда, поскольку изначально идет от людей которые ничего не знают про запросы и облака. Во что она трансформируется дальше и насколько легко ее превратить во что-то инженерное, в этом топике как раз и обсуждается.
В идеальном мире можно представить себя руководителем команды которая пишет микросерис и требовать SLA по ГОСТу. В реальном же задача понять в какие вызовы оно превратится не имеет алгоритмического решения. Все превращается в личную магию типа — смотрим трейс и все понимаем. Причин много, к примеру — на продовых данных погонять нагрузку не всегда выходит, а на тестовых картина ни разу не релевантная. И регрессить эти наборы вводных к SLA тот еще квест.
Можете кидать в меня помидорами, но лично у меня эта магия дает сбои достаточно регулярно и требует множества итеративных подходов с привлечением многих людей и глубоким пониманием всего процесса. Поэтому когда я слышу заявления о том, что в микросервисах это все давно просто и отлажено, меня разбирает любопытство, как это работает.
Здравствуйте, Ziaw, Вы писали:
Z>В идеальном мире можно представить себя руководителем команды которая пишет микросерис и требовать SLA по ГОСТу.
Какой руководитель команды, какие ГОСТы? Твои продажники подписывают с клиентом контракт, где прописаны конкретные цифры. И за несоответствие этим цифрам клиент вправе потребовать прописанную в договоре же компенсацию. В каком месте тут может помочь твоя мухлефилософия про магию в реальном мире?
Здравствуйте, Cyberax, Вы писали:
C>Ошибку такого подхода поняли достаточно быстро, но полный переход на сервисы занял что-то около 10 лет.
Облачные провайдеры и прочие госуслуги легко бьются на слабо-связанные куски, это отличные кандидаты на разбиение на множество кусков-приложений.
А вот будет ли это хотя бы близко к классике микросервисов: один микро-сервис — одна простая функция — одно хранилище — один разработчик, вопрос открытый.
Лично я их подход вижу как несколько монолитов слабо связанных по ресту и небольшой набор общих сервисов.
Здравствуйте, Ziaw, Вы писали:
Z>Облачные провайдеры и прочие госуслуги легко бьются на слабо-связанные куски
Тут дело такое. Госуслуги легко бьются на куски не только потому что они такие по исходной задаче, а в том числе и потому что изначально проектировались с учетом этого. Ты погляди на современные high load сервисы — они почти все подобным образом устроены.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Какой руководитель команды, какие ГОСТы? Твои продажники подписывают с клиентом контракт, где прописаны конкретные цифры. И за несоответствие этим цифрам клиент вправе потребовать прописанную в договоре же компенсацию. В каком месте тут может помочь твоя мухлефилософия про магию в реальном мире?
Что-то у тебя какое-то совсем неприкрытое хамство пошло. Если у тебя клиенты прописывают SLA в договоре — тебе просто повезло, одной неопределенностью меньше.
Здравствуйте, Ziaw, Вы писали:
НС>>Какой руководитель команды, какие ГОСТы? Твои продажники подписывают с клиентом контракт, где прописаны конкретные цифры. И за несоответствие этим цифрам клиент вправе потребовать прописанную в договоре же компенсацию. В каком месте тут может помочь твоя мухлефилософия про магию в реальном мире? Z>Что-то у тебя какое-то совсем неприкрытое хамство пошло.
Тебе показалось. Не стоит претензии к написанному тобой переносить на себя лично.
Z> Если у тебя клиенты прописывают SLA в договоре — тебе просто повезло
Офигеть просто.
Z>, одной неопределенностью меньше.
Это тебе повезло, можно расслабиться и не иметь никаких четких рамок. В современном мире облачных сервисов не так чтобы частая ситуация, мало кто хочет использовать сервис, который в один прекрасный момент начнет тормозить и никаких обязательств по этому поводу ни у кого не будет.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Тебе показалось. Не стоит претензии к написанному тобой переносить на себя лично.
Не показалось. Претензии можно привязать к фактам, хамство — обтекаемо и оценочно.
НС>Это тебе повезло, можно расслабиться и не иметь никаких четких рамок. В современном мире облачных сервисов не так чтобы частая ситуация, мало кто хочет использовать сервис, который в один прекрасный момент начнет тормозить и никаких обязательств по этому поводу ни у кого не будет.
Сервис который используют другие бизнесы не весь мир, а довольно узкий класс приложений в сегменте b2b и еще чуть-чуть в b2g.
