Comments 16
Описать финансовую сторону вопроса было бы неплохо. Мой сервис хостится тоже в Azure, но находится в стадии непубличной беты и было бы интересно узнать насколько адекватны мои прикидки по расходам на хостинг. А так в целом Azure очень радует.
присоединяюсь, вопрос про цену крайне интересен. выгодно ли использовать Azure при небольших нагрузках на систему? на что больше уходят финансы (hdd, cpu, память?)
при небольших нагрузках — не очень.
В целом — если мы знаете, что нагрузка у вас точно будет больше, чем на 1 сервер — тогда стоит смотреть на облака и там уже строить гибкие схемы оптимизации (ночью серверов меньше, чем днем).
Запускать 1 сервер — не рекомендуется (он может уйти на автоапдейт на пол часа например рано утром) или деградировать.
Micra instance обойдется вам в ~30$/month.
В целом — если мы знаете, что нагрузка у вас точно будет больше, чем на 1 сервер — тогда стоит смотреть на облака и там уже строить гибкие схемы оптимизации (ночью серверов меньше, чем днем).
Запускать 1 сервер — не рекомендуется (он может уйти на автоапдейт на пол часа например рано утром) или деградировать.
Micra instance обойдется вам в ~30$/month.
UFO just landed and posted this here
Насчет AWS не знаю, а в Azure есть:
https://www.windowsazure.com/ru-ru/pricing/spending-limits/
https://www.windowsazure.com/ru-ru/pricing/spending-limits/
Ну в системе по умолчанию нет никакого Auto-scaling механизма.
А любой сторонний софт — 100% будет иметь защиту от этого.
А любой сторонний софт — 100% будет иметь защиту от этого.
Я бы начала с того, что все зависит от цели. Например, возьмем статью Веб-технологии- Может ли правительство предотвратить DDoS-атаки? и цитату "DDoS-атаки — неотъемлемая часть Веб. От них нельзя защититься полностью, но можно предпринять ряд мер, позволяющих снизить риски."
По сути, мне кажется, что:
1. Либо мы не хотим «оплачивать» DDos, тогда в этом случае можно настроить алерты и отклонять запрос, т.е. ресурсы не будут тратиться, но и сервис может перестать быть таким же доступны.
2. Либо мы хотим, чтобы сайт выстоял DDos и затраты нас не сильно беспокоят. Тогда мы масштабируемся практически до «бесконечности» с облачными провайдерами и Windows Azure, в частности. Бесконечность здесь понятие условное, т.к. ресурсы хакеров тоже не безграничны и DDos для них тоже прямые затраты. Как раз в статье, упомянутой мной выше, предлагает два метода для противостояния DDos атакам, которые можно реализовать с помощью облачных вычислений: увеличение числа экземпляров (и их опалата) и гео-распределение сервиса, что усложнит проведение атак.
В реальности для большинства приложений, мне кажется, есть некоторый порог, после которого, если DDos его преодолел, можно не масштабироваться и сохранить ресурсы и свои деньги. При этом заDDos’ить, например, Windows Azure не так-то и просто (думаю, что аналогично и для других облачных платформ). В документе Security Best Practices For Developing Windows Azure Applications — в разделе Windows Azure Platform- & Infrastructure-layer security protections приведена информацию о том, как организована защита на уровне инфраструктуры.
И напоследок, приведу пример нам близкого портала – TechDays.ru. Его тоже DDos’или, но это не проблема сейчас как с финансовой точки зрения, так и сточки зрения доступности портала. Поправили один баг, и DDos атака уже стала слишком «дорогой» (ресурсоемкой), чтобы ее результаты были заметны для портала и пользователей. За счет небольшого увеличения ресурсов в момент самой атаки нам удалось не упасть, а за это время все поправить в коде.
Т.е. чего-то очень специфического с точки зрения DDos в облаке я бы не выделяла. Т.е. если писать код правильно :), то все будет хорошо. Неправильный код может быть, конечно, несколько дороже в облаке, но «не разорительно» дороже, если следить за своим приложением: мониторить его и вносить во время исправления.
Вот, поделилась своим мнение на этот счет.
По сути, мне кажется, что:
1. Либо мы не хотим «оплачивать» DDos, тогда в этом случае можно настроить алерты и отклонять запрос, т.е. ресурсы не будут тратиться, но и сервис может перестать быть таким же доступны.
2. Либо мы хотим, чтобы сайт выстоял DDos и затраты нас не сильно беспокоят. Тогда мы масштабируемся практически до «бесконечности» с облачными провайдерами и Windows Azure, в частности. Бесконечность здесь понятие условное, т.к. ресурсы хакеров тоже не безграничны и DDos для них тоже прямые затраты. Как раз в статье, упомянутой мной выше, предлагает два метода для противостояния DDos атакам, которые можно реализовать с помощью облачных вычислений: увеличение числа экземпляров (и их опалата) и гео-распределение сервиса, что усложнит проведение атак.
В реальности для большинства приложений, мне кажется, есть некоторый порог, после которого, если DDos его преодолел, можно не масштабироваться и сохранить ресурсы и свои деньги. При этом заDDos’ить, например, Windows Azure не так-то и просто (думаю, что аналогично и для других облачных платформ). В документе Security Best Practices For Developing Windows Azure Applications — в разделе Windows Azure Platform- & Infrastructure-layer security protections приведена информацию о том, как организована защита на уровне инфраструктуры.
И напоследок, приведу пример нам близкого портала – TechDays.ru. Его тоже DDos’или, но это не проблема сейчас как с финансовой точки зрения, так и сточки зрения доступности портала. Поправили один баг, и DDos атака уже стала слишком «дорогой» (ресурсоемкой), чтобы ее результаты были заметны для портала и пользователей. За счет небольшого увеличения ресурсов в момент самой атаки нам удалось не упасть, а за это время все поправить в коде.
Т.е. чего-то очень специфического с точки зрения DDos в облаке я бы не выделяла. Т.е. если писать код правильно :), то все будет хорошо. Неправильный код может быть, конечно, несколько дороже в облаке, но «не разорительно» дороже, если следить за своим приложением: мониторить его и вносить во время исправления.
Вот, поделилась своим мнение на этот счет.
Прочитал статью в надежде увидеть ответ на финансовый вопрос. напишите обязательно!
Да по ощущениям достаточно дорого выходит для сайта команды уж точно.
Килорубль минимум будет стоить хостинг и это только за виртуалки — обязательно надо иметь два инстанса, а самый дешевый — 15 баксов.
+ вот у нас траффик не сильно большой льется — по 5мб в минуту что ли, а уже тыщи полторы идет в месяц.
Боюсь, что при росте все это будет нерентабельно.
Килорубль минимум будет стоить хостинг и это только за виртуалки — обязательно надо иметь два инстанса, а самый дешевый — 15 баксов.
+ вот у нас траффик не сильно большой льется — по 5мб в минуту что ли, а уже тыщи полторы идет в месяц.
Боюсь, что при росте все это будет нерентабельно.
На WA хостится сайт не одной команды, а все наша платформа, на которой более 500 сайтов команд, так что не так уж и дорого.
Но в целом Вы правы, нужно все аккуратно посчитать.
Но в целом Вы правы, нужно все аккуратно посчитать.
Да, я бы согласилась с gamay, что разделяемая архитектура и сервис (мультитенантный) снижает расходы и сглаживает пики. Я так понимаю, что как раз такая архитектура разделяемая и выбрана. Если мы говорим об облаке, то выгода может быть, на мой взгляд:
1. За счет надежности.
2. За счет мультитенантности, т.е. использование всеми ресурсов всеми пользователями, в итоге стоимость подписки для пользователя снижается и выравнивается (т.к. триальные аккаунты, которые вы выдаете своим пользователям, тоже ведь фактически «оплачиваются», а не из воздуха берутся).
3. За счет сервисов, которые добавляют облачные провайдеры и их партнеры, т.е. получается экосистема.
1. За счет надежности.
2. За счет мультитенантности, т.е. использование всеми ресурсов всеми пользователями, в итоге стоимость подписки для пользователя снижается и выравнивается (т.к. триальные аккаунты, которые вы выдаете своим пользователям, тоже ведь фактически «оплачиваются», а не из воздуха берутся).
3. За счет сервисов, которые добавляют облачные провайдеры и их партнеры, т.е. получается экосистема.
Sign up to leave a comment.
Использование Windows Azure в бутстреппинговом SaaS-стартапе