Для того, чтобы я мог наиболее полным образом ответить на Ваш вопрос, Вы могли бы объяснить в чем состоит сомнительность технологии?
Главной причиной выбора стала экономия на плате за ресурсы проекта, а не экономия на процессах дэвопса. У функций такой же процесс деплоймента, как и у других апп сервисов. Функции в сравнении с обычными апп сервисами значительно дешевле.
Еще среди плюсов, в сравнении могу выделить легкость в работе с keyvault, уменьшение количества кода за счет использования готовых bindings и outputs. Но в принципе все они описаны в статье. Еще одна причина, это наша общая командная вера, что за serverless будущее :)
В то же время, не могу выделить каких-то особых преимуществ «классических веб сервисов», да ASP.NET Core предоставляет middleware, но у нас не было какой-то исключительной потребности в этом.
P.S. Желание инженеров попробовать какие-то новые вещи, по-моему, всегда очень хорошая мотивация для использования технологии, при прочих равных :)
К сожалению, не могу поделиться этой информацией, не получил разрешение от клиента. Постараюсь сделать тестовое хранилище и провести сравнение, чтобы не быть голословным.
Да, на данном этапе все работает через функции. По поводу ограничений, из уже реализованного функционала не могу вспомнить каких-то проблем. Но сейчас начали работу над функционалом, в котором ряд операций будет занимать значительное время. А в http функциях, есть ограничение на время ответа. Сейчас думаем вместе с бизнесом, как можно изменить флоу или будем выбирать другие варианты и придется отказаться от функций для этой задачи.
Да, возможно, я не совсем понятно выразился в своем ответе. Я не говорил, что Cosmos дешевый. Моя мысль состоит в том, что соотношение производительность/цена у Cosmos будет лучше, чем у SQL.
Спасибо за Ваше замечание, Вы затронули очень важную тему в целом, и одну из критических тем для функций, поскольку в Azure function есть ограничение на количество активных исходящих подключений равное 600. Поэтому действительно необходимо использовать Singleton для разнообразных клиентов (http, cosmos и т. д.) иначе будут происходить весьма неприятные вещи, которые на данный момент плохо мониторятся самим Azure.
Но вряд ли можно однозначно сказать, что лучше всегда использовать тот или иной тип. При выборе времени жизни сервиса необходимо смотреть на очень многие факторы. Например, используя Singleton мы забиваем память, которая не будет высвобождена в течении всей работы. Кроме того, любые другие сервисы, которые будут внедрены в Singleton будут сами превращены по сути в синглтоны, что не всегда является очевидным.
Что касается моего демо-проекта, я выбрал Transient как самый легковесный вариант, возможно, стоит заменить его на Scoped. Немного не понял Ваше замечание, на счет одного раза, Singleton ведь будет создан только во время первого обращения к нему.
Я лично не использовал mongodb API в серьезных проектах. Слышал о подобных проблемах от коллег, а чем был обусловлен выбор именно mongodb? Вы мигрировали в Cosmos уже существующее решение?
Вы используете различных cloud провайдеров в Вашем решении? Просто терраформ очень долго догоняет все изменения, также замечал, что он крайне нестабильно работает на других проектах. Нам в этом плане проще, мы используем только Azure, поэтому нам полностью подходит ARM, в нем доступна вся конфигурация космоса.
Спасибо, надеюсь, это не сарказм :)
Да, sql. По поводу бэкапа мы используем дефолтную конфигурацию, фул бэкап каждые 4 часа, здесь, как мне кажется, хорошо описано в официальной документации. Восстановление работает через сапорт, но не думаю, что это большая проблема.
По поводу стоимости, согласен, сервис довольно-таки дорогой. Но если сравнивать cosmos с sql, то, чтобы добиться такого же перформанса нужно использовать сервис план, который будет значительно дороже, чем космос. Так как наше решение построено на функциях, время выполнения для нас критически важно, поэтому нам нужна высокая производительность. Кроме того, проанализировав использование космоса, мы смогли провести ряд оптимизаций, что значительно сократило стоимость.
Мы выбрали космос по ряду причин:
1. У нас очень часто изменяются требования, что ведет за собой изменение моделей, мы не хотели уделять очень много времени миграциям, джоинам, нормализации и т.д.
2. Были требования от бизнеса, которые идеально закрываются за счет использования Time to live у документов.
3. Сейчас мы начали активную работу над внедрением change feed, что должно значительно облегчить и вероятно удешевить часть функционала.
4. Ну и в качестве клауд провайдэра мы выбрали Azure:)
Так, у нас гарні шанси виграти :)
Під Azure function Ви розумієте окрему функцію чи апп сервіс? Для кожного ендпоінту ми створюємо окрему функцію. Функції об’єднані в єдиний апп сервіс за принципом єдності домену. Є невелика проблема з використанням APIMу, оскільки на данному етапі експорт функцій як API у нас не автоматизовано, а створених API вже багато і для кожного з філіалів необхідно додавати їх вручну.
Щодо питання про девопс, звісно ні, ми оновлюємо ресурси за рахунок використання інкрементал деплойменту.
Есть еще вариант использования durable функций для задач, которые требуют большого времени выполнения или зависят от результатов выполнения других операций. Но да, они значительно дороже, потому что подразумевают существование функции-оркестратора, которая работает все время.