Azure Service Fabric: вторые шаги

[centur]

А почему не взяли Orleans? Из всего что вы описали выглядит так, что решение принималось — "потому что это Майкрософт", а не исходя из объективных потребностей проекта и удобств фреймворков.
А тут так много описаний низкоуровневых кейсов, т.е. то что фремворк призван решить и спрятать — он выдает наружу и создает сложности программистам. К тому же можно взгромоздить Orleans на SF в Stateless Worker, хотя мы чем дальше — тем более скептически смотрим на это решение. SF выглядит хорошо в плане возможностей devops, но в плане актеров — Orleans ощутимо впереди. В gitter проекта Orleans народ плачет когда их заставляют переходить на SF...

[Caraul]

Ключевое слово тут «для примеров». Это не реальная разработка, а изучение ASF. Orleans есть у нас в реальном проекте, и да, по акторам Orleans выглядит симпатичнее. Но у ASF и Orleans разные цели — ASF это все «из коробки», включая какую-нито панель управления, Orleans именно что фреймворк. Завести Orleans в Stateless сервис наверное, можно, но с ходу выглядит как уж с ежом — на мой взгляд если уж Orleans, то и вся обвязка должна быть своя. А про какие низкоуровневые кейсы Вы говорите?

[centur]

Ну кстати в сообществе, есть желание сделать глубокую интеграцию с SF, чтобы не было всякого головняка с деплоем и обновлениями. И я знаю что так некоторые делают (и мы тоже возможно соберемся). потому как орлеанс не предоставляет хостинг сам по себе — нужно или в консольке или в вин-сервисе или в клауд сервисе хостить. Там у каждого свой велосипед с обновлениями, кластером и мониторингом здоровья. А СФ именно предлагает полный стек — с хорошей штукой вокруг инфраструктуры и убого скопированной моделью акторов.

Низкоуровневые кейсы это например про описанный сценарий TcpListener. Может я не очень понял для чего такие сложности, хотя видно необходимы без поддержки клиентской подписки. А при наличии стримов — такие коммуникации организовываются очень просто.

[Caraul]

Вот мы в Cloud Service и хостим — нам еще нужен WebApi, так вот в ASF это было бы все вместе, а в Cloud Service приходится поднимать Web Role. Зато масштабируем как хотим. Как обычно «сразу из коробки» vs «делай сам как хочешь».
TcpListener нужен для ADC, тут без вариантов.

[centur]

Та же самая схема…
Ну учитывая что орлеанс хост жадный до памяти и CPU чтобы работать наиболее эффективно — засовывать все на одну машину все равно не рекомендуется, что в cloud service, что в SF. Сейчас вы это тоже можете сделать захостив Host или клиента в отдельном AppDomain, примеры есть в тестах. Это даст отсутствие раундтрипа по сети только если клиент обращается к зерну в сило на нем самом. А так — будете также общаться по сети между вебролями.
А теперь представьте кейс когда в SF у вас по какой-то причине на одной машине будет 2-3 сило крутиться и драться за CPU — чем это полезно то? Да, фабрика из коробки прикольная, но все же я бы ставил на орлеанс.

[Caraul]

А откуда в ASF «на одной машине 2-3 сило»? Насколько я понимаю, там на каждом узле крутятся инстансы stateless и реплики stateful (поскольку акторы в AFS это специальная разновидность stateful), причем ASF старается primary реплики раскидывать по разным узлам. Они, конечно, могут и сойтись на одном узле, но это все-таки не «монолитное» silo Orleans, внутренняя организация скорее всего другая.

[centur]

Да, точно, это я смешал со своими размышлениями о потенциальных граблях Орлеанс когда они поверх SF… Мой косяк.

А вы кстати тут упомянуты ? Если нет — отправляйте PR, adoption cases всегда интересны.

[Caraul]

Нет, мы только-только прошли коммерческий релиз (не скажу что во избежание рекламы), да и надо согласовать с NDA, но, может, и объявимся.

[centur]

а, про Tcp теперь понял, у нас наверное похожая ситуация с вебсокетами — стримы просто сказка для этого...

[Caraul]

Не туда попал ответом.