Служба приложений Azure и Azure Service Fabric

к сожалению, нет никаких официальных указаний о том, когда использовать то, что. Это две отдельные платформы, следующие разным парадигмам развития.

служба приложений предоставит вам функциональность, которую Service Fabric не предоставляет из коробки. Такие вещи, как автоматическое масштабирование, аутентификация, ограничение скорости, интеграция с приложениями SaaS и т. д. Некоторые или все эти вещи могут прийти к Service Fabric постепенно, но я бы сказал, что в данный момент они нацелены на разные аудитории-менее опытной команде может быть проще работать со Службой приложений.

структура службы, с другой стороны, делает состав частей легче. Например, в" традиционном " подходе, если у вас есть API, который говорит с хранилищем данных и кэшем, чтобы избежать забивания хранилища данных, вам придется обрабатывать различные сценарии отказоустойчивости. С Service Fabric ваш кэш может находиться в процессе API в надежной коллекции, и вам не придется иметь дело с наличием компонент внешнего кэша. Данные расположены совместно с сервисом (быстрее для получения/редактирования!) и является надежным, поскольку он распределен по всем узлам, в которые развертывается служба. Аналогичная вещь с очередями. Если вы думаете о системе типа рабочего процесса, где есть API, служба заданий и очередь, которая сидит между ними и позволяет им общаться, вам придется управлять 3 различными компонентами и связью между ними. С Service Fabric очередь входит в приложение. И это только половина:) вы также получаете возможность использовать модель актера для распределенных вычислений без обычных головных болей параллелизма. Наконец, с Service Fabric вы получаете преимущество наличия более полной среды разработки в локальном окне - вам не нужно иметь дело с созданием очередей и т. д. в учетной записи Azure dev или что-то в этом роде.

также стоит отметить, что ничто не мешает вам использовать обе парадигмы - представьте себе два приложения, по крайней мере один из них будучи приложением service fabric, которое предоставляет API и логическое приложение, которое находится поверх них.

ваше решение должно основываться на том, что вы пытаетесь построить, за сколько времени, когда вы хотите выпустить (Service Fabric в настоящее время только в частном предварительном просмотре, поэтому это будет некоторое время, пока они не доберутся до GA) и какая у вас команда. Я предполагаю, что с сервисом приложений будет легко попасть на землю, даже если у вас нет массово опытной команды, но Service Fabric даст вам больше силы, гибкости и контроля.

App service является более управляемым сервисом, SF больше вы управляете своими собственными, и вы можете работать на своих собственных помещениях, а также. SF имеет лучшую поддержку для non MS stack dev, например, родных приложений и т. д.

Как говорится в этом документе "ткань сервис-хороший выбор, если вы создаете новое приложение или переписывание существующего приложения, чтобы использовать архитектуру микрослужб. "

Если ваш хостинг несколько приложений вы не должны смотреть на SF , с другой стороны, если ваше развертывание больше чем 10 услуг, чем это становится лучшим решением.

также Примечание SF имеет механизм хранения данных, который входит в состав служб . Хорошо на 3 вещи 1) массивные кластеры данных 2) простые данные, часто в службах Micros DBs становятся тяжелым бременем, поскольку каждая служба должна иметь свои собственные данные, а такие вещи, как SQL, немного избыточны, когда у вас есть только 1-3 таблицы. 3) хранение состояния для модели программирования актора.

Я думаю, что SF и веб-приложения будут нарезать " облако Сервис " база пользователей в будущем.