Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 160
Отличная статья. Хотел бы добавить, что облака предоставляют разработчику и архитектору море новых возможностей и инструментов — как для масштабирования, так и обеспечения надежности. Фактически тебе становятся доступны «неубиваемые» сервисы + даны инструменты для создания других «неубиваемых» сервисов. И можно сконцентрироваться на решении бизнес-задачи, а не бэкапах и рестартах апача :-)
Александр, Вы так и недождались нашей дуэли =)
Пока я не вижу причин полагать, что изречение «Сейчас облако в хостинге — маркетинговое зло, которое только путает людей» — неверно.
Есть несколько моментов, которые я не принимаю:
1. «Облако» упрется вертикально — в 1 сервер (лезвие), горизонтальное мастабирование — нужно уметь с ним работа
ть — нужен спец.
2. Резервирование на уровне цод — только слова
3. Стоимость. При нагруженном проекте — выгоднее свой сервер (несколько серверов в разных реальных ЦОДах)
Покажите, пожалуйста, в России «облако», которое будет близко например по стоимости к серверу на одном Оптероне 6168, 8Gb, 3x1Tb за ~230 евро?
Итог — «облако» может быть интересно только стартапу и сайтам визиткам, которые считают каждый рубль.
Предлагаю с «облаков» спуститься на землю и продолжить оптимизироваться =)
Пока я не вижу причин полагать, что изречение «Сейчас облако в хостинге — маркетинговое зло, которое только путает людей» — неверно.
Есть несколько моментов, которые я не принимаю:
1. «Облако» упрется вертикально — в 1 сервер (лезвие), горизонтальное мастабирование — нужно уметь с ним работа
ть — нужен спец.
2. Резервирование на уровне цод — только слова
3. Стоимость. При нагруженном проекте — выгоднее свой сервер (несколько серверов в разных реальных ЦОДах)
Покажите, пожалуйста, в России «облако», которое будет близко например по стоимости к серверу на одном Оптероне 6168, 8Gb, 3x1Tb за ~230 евро?
Итог — «облако» может быть интересно только стартапу и сайтам визиткам, которые считают каждый рубль.
Предлагаю с «облаков» спуститься на землю и продолжить оптимизироваться =)
1. Попробую без рекламы. ;) Скажем так, есть продукты, в которых горизонтальное масштабирование поддерживается «почти из коробки». Почти — потому что, конечно, некоторые действия потребуются.
2. Резервирование на уровне ЦОД — реальность. ;) Вот, у нас лично — в Амазоне.
Если взять Россию, то у Скалакси — два датацентра, у Селектел — четыре. Да, маловато пока, но, надеюсь, дорастем и до более масштабных сетей. :)
3. Стоимость… Вот я как раз и начал с того, что это — не ключевой параметр.
Вот, лично для меня — важнее надежность и доступность проекта. И я готов за это даже немного переплатить.
2. Резервирование на уровне ЦОД — реальность. ;) Вот, у нас лично — в Амазоне.
Если взять Россию, то у Скалакси — два датацентра, у Селектел — четыре. Да, маловато пока, но, надеюсь, дорастем и до более масштабных сетей. :)
3. Стоимость… Вот я как раз и начал с того, что это — не ключевой параметр.
Вот, лично для меня — важнее надежность и доступность проекта. И я готов за это даже немного переплатить.
А как кореллирует количество ЦОД с резервированием на уровне ЦОД? У Амазона резервирование? Что там у них недавно грозой дёрнуло?
Трансформатор.
И из-за пожара не получилось воспользоваться дизелем.
И из-за пожара не получилось воспользоваться дизелем.
Так. И где «резервирование на уровне ЦОД»? Пшик?
Форс-мажор.
Ну, правда, расскажи, что надо было делать Амазону?
Ну, правда, расскажи, что надо было делать Амазону?
Понятия не имею. Но причём тут резервирование на уровне ЦОД?
IaS это никак не облако. Это все же впски на стораджах и в нодах.
Делать надо было не амазону, а тому кто делал решения в этом амазоне — поднимать на свои приложение в нескольких дц.
IaS облака — это маркетинговый бред.
Делать надо было не амазону, а тому кто делал решения в этом амазоне — поднимать на свои приложение в нескольких дц.
IaS облака — это маркетинговый бред.
Бред, в нашем дц (T4), например 2 подстанции и 4е дизеля.
Имхо утверждение schors верно, пшик это резервирование у облак.
Имхо утверждение schors верно, пшик это резервирование у облак.
1. пропускаем =)
2. Не работает а Амазоне, а в России будет?
3. В этом случае, ставят несколько серверов в разных цод-ах (города, страны, другое) и не думают о проблеме с доступностью сайтов.
Более глобально проблема заключается в том, что если все делать «по уму», то это никто массово покупать не будет, это единичные проекты под конкретный бизнес.
«Поставил контейнер на корабль и уплыл, все в норме....» =)
2. Не работает а Амазоне, а в России будет?
3. В этом случае, ставят несколько серверов в разных цод-ах (города, страны, другое) и не думают о проблеме с доступностью сайтов.
Более глобально проблема заключается в том, что если все делать «по уму», то это никто массово покупать не будет, это единичные проекты под конкретный бизнес.
«Поставил контейнер на корабль и уплыл, все в норме....» =)
А если мы хотим получить гибкое соотношение «надежность / стоимость»? Хотим уметь добавлять серверы только тогда, когда нам это нужно? И уметь отказаться от них, когда в них больше нет необходимости?
«А если мы хотим получить гибкое соотношение «надежность / стоимость»?»
— Здесь нужно правильно выбрать «cms» и «администратора».
«Хотим уметь добавлять серверы только тогда, когда нам это нужно? И уметь отказаться от них, когда в них больше нет необходимости?»
— Эта услуга называется «аренда сервера».
Причем, здесь вы можете выбрать все. От типа, частоты процессора и памяти (кстати, у вас в облаке какой процессор? 3 или 4 канала памяти?), до типа, количества и размера ssd дисков, которые будут использоваться для кеша. Все для вашей конкретной задачи и типа ее выполнения.
Если задача не требует много потоков — пусть будет меньше ядер и больше mhz, если требует — пусть будет больше ядер и mhz =)
Да, и GPU Tesla в аренду тоже не проблема, хотите один или 4 =)
— Здесь нужно правильно выбрать «cms» и «администратора».
«Хотим уметь добавлять серверы только тогда, когда нам это нужно? И уметь отказаться от них, когда в них больше нет необходимости?»
— Эта услуга называется «аренда сервера».
Причем, здесь вы можете выбрать все. От типа, частоты процессора и памяти (кстати, у вас в облаке какой процессор? 3 или 4 канала памяти?), до типа, количества и размера ssd дисков, которые будут использоваться для кеша. Все для вашей конкретной задачи и типа ее выполнения.
Если задача не требует много потоков — пусть будет меньше ядер и больше mhz, если требует — пусть будет больше ядер и mhz =)
Да, и GPU Tesla в аренду тоже не проблема, хотите один или 4 =)
Вот, тот пример про январские каникулы в январе — он реальный. Мне очень-очень был нужен сервер в аренду. Некоторой определенной конфигурации.
Никто не сумел мне его предоставить.
Максимум, что получилось — вот, ровно те предустановленные конфигурации, которые есть. И примерно в течение 1-2 дней.
Или — то, что мне надо. Но через пару дней после окончания каникул (то есть, в лучшем случае — через неделю).
Никто не сумел мне его предоставить.
Максимум, что получилось — вот, ровно те предустановленные конфигурации, которые есть. И примерно в течение 1-2 дней.
Или — то, что мне надо. Но через пару дней после окончания каникул (то есть, в лучшем случае — через неделю).
Не помню, чтобы вы к нам обращались =)
Здесь можно много рассуждать о том или другом случае, это все частности, которые можно «работать» по-разному.
И интерпритировать облако можно по-разному, вкладывать в него разные определения, ожидать разных плюшек, каждый находит для себя именно то, что ищет.
Здесь можно много рассуждать о том или другом случае, это все частности, которые можно «работать» по-разному.
И интерпритировать облако можно по-разному, вкладывать в него разные определения, ожидать разных плюшек, каждый находит для себя именно то, что ищет.
А какие проблемы были обратиться не к российским хостерам, а в тот же Hetzner? Получили бы сервер в тот же день.
Жжёшь напалмом, коллега :) Я уж думал, что у меня у одного иммунитет на это поветрие :)
> Итог — «облако» может быть интересно только стартапу и сайтам визиткам, которые считают каждый рубль.
Им интересны мы с тобой. Стартапу нужна эластичность, но он может в деньги влететь с ней, а падение он как раз переживёт. И вообще стартапу считающему копейки неплохо бы сразу думать о нагрузочном проектировании, а «облако» его только развратит. Если у разработчика голова не из задницы, прости Господи, то и у тебя, и у меня прекрасно живут порталы с дай боже функционалом и посещаемостью.
«Облака» с самого начала вообще не совсем для веба предназначались, даже у того же Амазона. Задачи действительно «временнЫх» ресурсов. Вроде рендеринга изображений у дизайн-студий. Расчёты фракталов там и всё такое.
> Итог — «облако» может быть интересно только стартапу и сайтам визиткам, которые считают каждый рубль.
Им интересны мы с тобой. Стартапу нужна эластичность, но он может в деньги влететь с ней, а падение он как раз переживёт. И вообще стартапу считающему копейки неплохо бы сразу думать о нагрузочном проектировании, а «облако» его только развратит. Если у разработчика голова не из задницы, прости Господи, то и у тебя, и у меня прекрасно живут порталы с дай боже функционалом и посещаемостью.
«Облака» с самого начала вообще не совсем для веба предназначались, даже у того же Амазона. Задачи действительно «временнЫх» ресурсов. Вроде рендеринга изображений у дизайн-студий. Расчёты фракталов там и всё такое.
> Как бы ни лимитировали хостеры те или иные ресурсы, все равно обычный хостинг – это общежитие: кто первый встал – того и тапки
А облачный хостинг тоже не имеет смысла без хоть какой-нибудь «эластичности». А она или вообще дискретная, или точно такая же «кто первый встал – того и тапки». И лимитирование – ну только если влоб конечно лимитировать, то всё плохо. Вроде ты должен был видеть эту гениальную вещь, хоть немного и устаревшую vimeo.com/7631344
Детектед софистика в самой постановке вопроса — сравнение идеологии гарантированных ресурсов (VPS/VDS) с эластичными (shared, cloud).
А облачный хостинг тоже не имеет смысла без хоть какой-нибудь «эластичности». А она или вообще дискретная, или точно такая же «кто первый встал – того и тапки». И лимитирование – ну только если влоб конечно лимитировать, то всё плохо. Вроде ты должен был видеть эту гениальную вещь, хоть немного и устаревшую vimeo.com/7631344
Детектед софистика в самой постановке вопроса — сравнение идеологии гарантированных ресурсов (VPS/VDS) с эластичными (shared, cloud).
Под тем словом, которое ты называешь «эластичным», я имею в виду несколько иное: если я захочу в облаке виртуалку с N RAM, и M CPU, я их и получу. На VPS (ну, у нас почти все на OpenVZ) — далеко не всегда.
Оплата за потребление — второй важный момент.
Оплата за потребление — второй важный момент.
Это прости с чего ты не получишь? Только потому что нет предложений? Ты думаешь на Амазоне что-то другое, а не тупой Xen с 9P FUSE? Это, как правильно сказал dtar — ограничение железки и только.
Это — из собственного опыта.
Ну, да, Амазон — это Xen. И что? Scalaxy, Selectel — тоже Xen.
И, вот, как показывает собственный мониторинг, здесь я получаю те ресурсы, за которые плачу.
Я же не убеждаю, что на обычном VPS всегда все плохо. Нет. Но (опять же — по моему личному опыту!) зачастую — хуже.
Ну, да, Амазон — это Xen. И что? Scalaxy, Selectel — тоже Xen.
И, вот, как показывает собственный мониторинг, здесь я получаю те ресурсы, за которые плачу.
Я же не убеждаю, что на обычном VPS всегда все плохо. Нет. Но (опять же — по моему личному опыту!) зачастую — хуже.
Ага. На амазоне не тупой Xen. На амазоне KVM =) На низком уровне.
Xen у наших русских популярен, почему-то.
Xen у наших русских популярен, почему-то.
> Не «облако надежнее», а «облако» дает гораздо больше возможностей построить надежную инфраструктуру.
Надо в цитаты записать. Ну хоть кто-то…
Надо в цитаты записать. Ну хоть кто-то…
Ну, я надеюсь, что здравомыслящие люди это все-таки понимают…
Вот отличная статья, написанная по результатам одного из самых масштабных падений Амазона (в апреле этого года): broadcast.oreilly.com/2011/04/the-aws-outage-the-clouds-shining-moment.html
Вот отличная статья, написанная по результатам одного из самых масштабных падений Амазона (в апреле этого года): broadcast.oreilly.com/2011/04/the-aws-outage-the-clouds-shining-moment.html
облака, белогривые лошадки
И все таки SaaS не равно облаку… SaaS (и прочий ...aaS) это способ продаж и потребления. Т.е. мы потребляем ИТ как электричество или воду (по факту потребления) и нам ее предоставляют. Но как и с любой инфраструктурой надо уметь этим пользоваться. В случае с водопроводом придется сделать соответствующие сливы-стоки, чтобы можно было искупать слона или даже стадо слонов, в случае с ИТ обеспечить такую конфигурацию системы чтобы она диагностировала нехватку ресурсов и сама их подключала и отключала…
Если моя система это делать не умеет и я не предусмотрел возможности масштабирования в архитектуре своего софта, то ничего не произойдет и я не получу никакой выгоды от ааS… А правильные с архитектурной точки зрения ИТ-системы можно было и раньше строить, когда ни про какие облака никто не говорил… Так что «облака» это всетаки выдумки маркетологов. Программист который делал многосерверные высоконагрузочные web-системы 10-15 лет назад всм скажет что от появления «облаков» проблем меньше не стало… Разве что набор функций изменился и всякие API сверху понавешали.
Если моя система это делать не умеет и я не предусмотрел возможности масштабирования в архитектуре своего софта, то ничего не произойдет и я не получу никакой выгоды от ааS… А правильные с архитектурной точки зрения ИТ-системы можно было и раньше строить, когда ни про какие облака никто не говорил… Так что «облака» это всетаки выдумки маркетологов. Программист который делал многосерверные высоконагрузочные web-системы 10-15 лет назад всм скажет что от появления «облаков» проблем меньше не стало… Разве что набор функций изменился и всякие API сверху понавешали.
Не соглашусь.
Продолжая Вашу аналогию: раньше для организации слива давали лопату. И жестко ограничивали территорию. Возможностей «слить» больше, чем водосток пропускает, не было почти никаких.
Сейчас — все проще.
Как раньше решались вопросы бэкапов большого объема данных? Как добавлялись ресурсы по мере роста проекта? При пиковых нагрузках? И т.д., и т.п.
Понятно, что все эти задачи — решаемые. Но сейчас (в «облаке») решить их банально проще. И зачастую — дешевле (мы меряем не только «в лоб» деньги, но и время, и другие ресурсы).
Продолжая Вашу аналогию: раньше для организации слива давали лопату. И жестко ограничивали территорию. Возможностей «слить» больше, чем водосток пропускает, не было почти никаких.
Сейчас — все проще.
Как раньше решались вопросы бэкапов большого объема данных? Как добавлялись ресурсы по мере роста проекта? При пиковых нагрузках? И т.д., и т.п.
Понятно, что все эти задачи — решаемые. Но сейчас (в «облаке») решить их банально проще. И зачастую — дешевле (мы меряем не только «в лоб» деньги, но и время, и другие ресурсы).
Это мне напоминает разговоры про многопроцессорные системы. Когда появились многопроцессорные персоналки (а позже многоядерные процессоры) и оказалось что даже гарантированно паралелящиеся процессы нифига не быстрее (например 3D Studio — досовская версия 3ds max… кстати первые два версии 3ds тоже не умели параллелиться). Оказывается надо софт писать так чтобы он учитывал что могут быть несколько ядер и как-то что-то паралелил…
С облаками то же фигня. 99.9% нынешнего web-софта не умеет жить в облаках. Точнее умеет, но ровно как старые дос-программы на современных i7… И спор «переходить на облака или нет» это как решать использовать высокоуровневые библиотеки для критичных многопроцессорных вычислений или нет. Библиотеки — это быстро, просто, без пыли… но никто не знает, что произойдет когда нагрузка станет реально большой и критичный процесс надо будет параллелить не на два, а на 200 ядер.
С облаками то же фигня. 99.9% нынешнего web-софта не умеет жить в облаках. Точнее умеет, но ровно как старые дос-программы на современных i7… И спор «переходить на облака или нет» это как решать использовать высокоуровневые библиотеки для критичных многопроцессорных вычислений или нет. Библиотеки — это быстро, просто, без пыли… но никто не знает, что произойдет когда нагрузка станет реально большой и критичный процесс надо будет параллелить не на два, а на 200 ядер.
Согласен с предыдущим коментом про надежность. Надежность у «облаков» повыше. Но это тоже «трюки маркетологов». Надежность должна быть в любом дата-центре. Архитектурно ее можно обеспечить в любом дата-центре. Просто не все любят обеспечивать (проще в договор пункт о технических рисках вписать). В «облачном» же дата центре надежность встроена и вот тут раздолье маркетологов. Ура наш сахар гарантировано сладкий а вода мокрая… Впрочем это не мешает предусмотрительно сохранить пункт о технических рисках в договоре. :)
Если Вы прочитали текст, то, наверное, могли обратить внимание на то, что я как раз не говорю о том, что надежность «облаков» выше.
Процитирую:
Не «облако надежнее», а «облако» дает гораздо больше возможностей построить надежную инфраструктуру.
Процитирую:
Не «облако надежнее», а «облако» дает гораздо больше возможностей построить надежную инфраструктуру.
Надежную инфраструктуру построить можно и без облаков. Она должна быть надежна всегда, просто в облаке обходится дешевле (т.к. механизмы уже встроены и их надо только включить… я только не понимаю почему они не включены всегда)
Груз перевезти можно и на телеге. Просто на машине — обходится дешевле. :)
Именно потому для вывоза леса при точечной вырубке ценных пород деревьев до сих пор используют двойку лошадей…
… а в производстве туалетной бумаги используют автоматические лесоукладчики… :(
… а в производстве туалетной бумаги используют автоматические лесоукладчики… :(
Мы правда можем бесконечно продолжать аналогии.
Смысл в том, что для каждого дела лучше использовать то решение, которое подходит лучше всего. И если есть несколько решений на выбор — тем лучше для пользователя. И выбор — за ним.
Вот, лично я считаю, что построить надежную инфраструктуру в облаке в общем случае проще и дешевле.
Смысл в том, что для каждого дела лучше использовать то решение, которое подходит лучше всего. И если есть несколько решений на выбор — тем лучше для пользователя. И выбор — за ним.
Вот, лично я считаю, что построить надежную инфраструктуру в облаке в общем случае проще и дешевле.
По поводу цен
И чуть выше вы указывали сравнение стоимости VPS серверов с облачными ценами.
Сейчас пользуюсь VPS в Лондоне, 10 Гиг винт, 256 Мб памяти, 100 Гб трафик в месяц — 25 фунтов в год, что приблизительно равно 100 р в месяц.
Интересные предложения VPS сервисов публикуются здесь www.lowendbox.com (не сочтите за рекламу). Но будьте внимательны, далеко не все дешевые сервера надежны. Впрочем, горький опыт Clodo показывает, что и облачные сервера далеко не всегда надежны.
Не является альтернативой хостингу за 200-300 руб./мес.
И чуть выше вы указывали сравнение стоимости VPS серверов с облачными ценами.
Сейчас пользуюсь VPS в Лондоне, 10 Гиг винт, 256 Мб памяти, 100 Гб трафик в месяц — 25 фунтов в год, что приблизительно равно 100 р в месяц.
Интересные предложения VPS сервисов публикуются здесь www.lowendbox.com (не сочтите за рекламу). Но будьте внимательны, далеко не все дешевые сервера надежны. Впрочем, горький опыт Clodo показывает, что и облачные сервера далеко не всегда надежны.
Если взять минимальную конфигурацию, то, может быть, и получится цена в 200-300 руб./мес.
Но в этой конфигурации не будет никаких преимуществ.
Но в этой конфигурации не будет никаких преимуществ.
Вот и я об этом.
Но суть комментария в следующем: в топике вначале говорится, что облако выгоднее VPS (сравнивается конфигурация с 512Мб памяти). Затем, в минусах указывается, что облако не является альтернативой хостингу за 200-300 руб./мес.
Следовательно, раз облако выгоднее VPS, то и VPS не может стоить такую сумму. По ссылке куча примеров дешевых VPS-ов и Ваше утверждение, что «Облако» в среднем в полтора-два раза дешевле" для меня очень сомнительно.
Но суть комментария в следующем: в топике вначале говорится, что облако выгоднее VPS (сравнивается конфигурация с 512Мб памяти). Затем, в минусах указывается, что облако не является альтернативой хостингу за 200-300 руб./мес.
Следовательно, раз облако выгоднее VPS, то и VPS не может стоить такую сумму. По ссылке куча примеров дешевых VPS-ов и Ваше утверждение, что «Облако» в среднем в полтора-два раза дешевле" для меня очень сомнительно.
Первый же мой тезис, кстати, сводится к тому, что даже если «облако» и дешевле (если тупо сравнивать абонентскую плату), то дешевизна эта — не освновной критерий.
Далее — я взял лишь некоторые компании. «Среднее по больнице».
Конечно, можно найти дешевле. Но, во-первых, цель не в этом, а во-вторых, скорее всего, мы рискуем попасть на серьезный oversell.
Далее — я взял лишь некоторые компании. «Среднее по больнице».
Конечно, можно найти дешевле. Но, во-первых, цель не в этом, а во-вторых, скорее всего, мы рискуем попасть на серьезный oversell.
Еще как рискуем, но и с облаком такие риски есть: в нужный момент у провайдера может просто не хватить ресурсов для масштабирования.
А цель то как раз в этом — получить сервис приемлемого качества за минимальную цену. И выбор стоит между VPS, облаком и собственным сервером/серверами. И выбор далеко не так однозначен.
А цель то как раз в этом — получить сервис приемлемого качества за минимальную цену. И выбор стоит между VPS, облаком и собственным сервером/серверами. И выбор далеко не так однозначен.
Вы сталкивались когда-нибудь с тем, что «облачный» провайдер не смог выделить столько ресурсов, сколько Вы запросили?
Я — нет.
Я — нет.
И я не сталкивался, но это еще не значит, что такого не было и не может быть )
А я сталкивался с обратным — на RackSpace Cloud у нас появился «сосед», который все мощи себе зажрал, и в итоге мы иногда на диск писали со скоростью в десятки (!) iops. Создали тикет, позвонили, короче в течение 4-5 часов нас перемигрировали на другой физ. хост, даунтайм 20 мин.
Даунтайм этого инстанса, конечно. Был и запасной, который в это время получил 2х плюшек.
Да, ок. Согласен — такие перекосы, конечно, возможны.
Но именно RackSpace с их идеологией Fanatical Support готов переносить серверы и на самом деле решать проблемы.
А большинство традиционных хостеров на массовых тарифах — готовы?
Но именно RackSpace с их идеологией Fanatical Support готов переносить серверы и на самом деле решать проблемы.
А большинство традиционных хостеров на массовых тарифах — готовы?
Так он и денег дерет за это мама не горюй.
В разы больше?
Или на несколько процентов?
Или на несколько процентов?
У RS Cloud саппорт совсем даже не fanatical. Linode те же самые или LiquidWeb гораздо быстрее отвечают и проблемы решают лучше.
Я об этом: www.rackspace.com/whyrackspace/support/
Самоотправилось. :) Цена за Managed-решения у RackSpace выше в разы — около $1000 за средний сервер. В облаке порядка $150 за облачный хост. У Hetzner, например, есть managed dedicated за 100-150 евро. У StormOnDemand — fully-managed CentOS $20/мес. Ну да, они не будут так вылизывать, как RackSpace.
Основная задача практически любого цода — продать Вам/нам/им питание (иногда даже и бесперебойное) в прохладной комнате. А умные слова ..aaS, облака, вертикали, горизонтали — всего лишь способ ввести дополнительный множитель к цене, отличный от нуля и больше единицы. IMHO.
Имхо, русские облака совсем даже и не облака — или падучие (Клодо, Скалакси и пр.), или трафик между нодами считают как внешний (Селектел). Заморские облака или с огромным пингом (Ракспейс, ГГ), или серьезный трафик и мощности там стоят как нигерийские алмазы (Амазон). Так что и остается пока РФ-ориентированные вещи на Хецнере держать. VQ-впски они, кстати, дешевые у них и деплоятся тоже довольно шустро на случай каких-то непредвиденных вещей. Ну а EQ-10 вообще вне конкуренции по цене (24ГБ / i7-980X за 110 евро!).
Да, наши облака, конечно, несколько отстают (хотя и не во всем — у тех же Скалакси есть некоторые очень удобные фичи, которых, например, нет в том же Амазоне).
Мы вообще всегда в роли догоняющих.
Но — как бы пафосно это на первый взгляд ни звучало — я очень верю в наши облака. Верю в то, что они дорастут до качественно нового уровня. И будут уже не альтернативой, а первейшим вариантом при выборе хостинга. :)
Мы вообще всегда в роли догоняющих.
Но — как бы пафосно это на первый взгляд ни звучало — я очень верю в наши облака. Верю в то, что они дорастут до качественно нового уровня. И будут уже не альтернативой, а первейшим вариантом при выборе хостинга. :)
По-моему, первейший аргумент — ценовая политика.
Один из важных. Но не первейший, думаю.
Набор фич, SLA, суппорт, цены — это все примерно в одном ряду.
Набор фич, SLA, суппорт, цены — это все примерно в одном ряду.
В том-то и дело, имхо, что сейчас у «облачников» цена идёт прежде всего за фичи типа динамического распределения ресурсов. Кому эти фичи нужны, тот за них заплатит, а тот, кому нужен просто хостинг либо заплатит столько же за большие ресурсы, SLA, суппорт или заплатит меньше за такие же. При одинаковой цене я всеми руками за хостинг, дающий больше фич. Но вот если фичи стоят дополнительных денег, но они мне сейчас не нужны, я трижды подумаю имеет ли смысл платить сейчас за то, что может быть когда-нибудь мне понадобится.
Кому нужен просто хостинг, тот может купить инстанс с фикс. ценой.
Традиционный хостинг — часто ли дает вообще хоть какой-то SLA?
Традиционный хостинг — часто ли дает вообще хоть какой-то SLA?
Если этот инстанс стоит столько же (или меньше) сколько (V)DS, то почему нет. Но вот стоит ли он столько?
Дают.
Дают.
Например? Кто дает SLA?
Из тех, кем пользовался www.valuehost.ru/ru/hosting/service/shared/sla/ www.1gb.ru/services_premium_plan_sla.php
Первые — это филькина грамота, а не SLA.
В тех редких случаях, когда качество работы сайта или предоставляемого сервиса будет отличаться от показателей, приведенных в пп.1, 2, 3 и 5 SLA, Вы имеете право потребовать от Компании ValueHost компенсацию простоя услуг. Решение о компенсации принимается на уровне начальника отдела Компании ValueHost.
То есть — никаких гарантий. Просто обещания под честное слово.
В тех редких случаях, когда качество работы сайта или предоставляемого сервиса будет отличаться от показателей, приведенных в пп.1, 2, 3 и 5 SLA, Вы имеете право потребовать от Компании ValueHost компенсацию простоя услуг. Решение о компенсации принимается на уровне начальника отдела Компании ValueHost.
То есть — никаких гарантий. Просто обещания под честное слово.
Любой договор является обещанием под честное слово, пока вам не передали материальный залог его исполнения.
Зависит от условий договора.
А тут… Даже условий никаких не нужно…
А тут… Даже условий никаких не нужно…
Пока у вас нет чего-то, чтобы сделать исполнение договора выгодным для контрагента (будь-то залог, ожидаемая прибыль, возможность устроить результативный антипиар или репрессивный аппарат государства), то договор это лишь честное слово. Вам обещают, но сделают это лишь в случае если не делать выйдет дороже.
Какой-то правовой нигилизм получается…
В моей личной практике, к счастью, чаще получается иначе.
В моей личной практике, к счастью, чаще получается иначе.
Так называемое «право» это тоже лишь обещание государства защитить вас в конкретных случаях. Есть лишь два, имхо, реальных «прав» — право силы (можно не обращать внимания на тех, кто против твоих действий) и право хитрости (можно надеяться на то, что твои действия никто из сильных, которым не по нутру твои действия, не заметит).
Даже выполнение всех формальных законов, принятых в соответствии с формальными правилами, не гарантирует, что завтра к тебе не придут недовольные твоими действиями «при поддержке авиации НАТО» и не заставят тебя совершать неугодные тебе действия, а то и просто не лишать тебя свободы, а то и жизни.
Даже выполнение всех формальных законов, принятых в соответствии с формальными правилами, не гарантирует, что завтра к тебе не придут недовольные твоими действиями «при поддержке авиации НАТО» и не заставят тебя совершать неугодные тебе действия, а то и просто не лишать тебя свободы, а то и жизни.
А когда ждать habroblako или habrako? И какие будут плюшки? Это если хотя-бы 1/10 того, что тут( на хабре) описано внедрить — амазоны с рэкспейсами уйдут с рынка прямо в монастырь.
Минусы «облака»:
Не является альтернативой хостингу за 200-300 руб./мес.
Неправда ваша! Еще как является! В селектеле машинка с 10+ малопосещаемыми сайтами ~ 220 руб./мес.
Плюс ее бэкапы на Amazon S3 — меньше доллара в месяц.
Эдакий симпатичный «шаред-хостинг для своих». При этом плюсы в сравнении с «классическим» shared'ом за те же деньги:
1) Я могу в любой момент поставить любые требуемые расширения php, Perl
2) Я могу туда засунуть еще 10, 20, 30 таких сайтов — стоимость возрастет, но не настолько, насколько возрастет на большинстве шаредов (почти везде есть ограничения на количество размещаемых доменов, особенно на таких дешевых тарифных планах)
3) Аналогично нет ограничений на количество баз данных, в отличие от шаредов, особенно дешевых.
4) Любые собственные конфигурации апача, nginx, и т.д.
5) Если бы даже я не стерла доменное имя на картинке, машинка бы не прилегла от хабраэффекта :-) Просто на некоторое время обошлась бы чуть дороже.
согласен на все 100%. могу показать такую же картинку.
Отлично!
Спасибо. На самом деле — очень хороший кейс.
Я расширю немного свою мысль: такой «облачный» аналог за 220 рублей для нормального функционирования сайтов на нем требует хоть какого-то мало-мальски внятного администрирования. А это уже никак не shared (где в общем случае все администрирование осуществляет хостер).
Спасибо. На самом деле — очень хороший кейс.
Я расширю немного свою мысль: такой «облачный» аналог за 220 рублей для нормального функционирования сайтов на нем требует хоть какого-то мало-мальски внятного администрирования. А это уже никак не shared (где в общем случае все администрирование осуществляет хостер).
Судя по цифрам среднее потребление памяти у вас порядка 200 Мб. VDS с примерно таким объёмом памяти с примерно такими ценами на рынке есть. Причём их стоимость не возрастёт при добавлении 10-30 таких сайтов. Как и почти все остальные плюшки. Это просто плюшки выделенного сервера, а облачный он, виртуальный или реальная железка почти значения не имеет.
Собственно самый важный пункт — пятый и уж тут главное, что важнее для владельца ресурса — обеспечить 100%-ю доступность ресурса при хабраэффекте или не попасть на деньги. А как вариант и попасть на деньги, и не выдержать хабраэффекта. Плюс для таких облаков навыки администрирования важнее чем для (V)DS — неверные настройки (например дефолтные для дистра) могут повлечь неоправданные расходы — 10 экземпляров ждущих апачей для хоста с посещаемостью 10 человек в сутки будут перебором.
В общем, имхо, облака подходят хорошо для проектов с прямой монетизацией, где доходы прямо зависят от посещаемости, либо для благотворительных проектов, где готовы творить благо не взирая на цену (или хостер проявит сознательность и не отрубит социально важный ресурс, типа списков жертв очередной катастрофы, из-за исчерпания бюджета). Для проектов @just for fun@ лучше, имхо, фиксированная плата за фиксированные ресурсы.
Собственно самый важный пункт — пятый и уж тут главное, что важнее для владельца ресурса — обеспечить 100%-ю доступность ресурса при хабраэффекте или не попасть на деньги. А как вариант и попасть на деньги, и не выдержать хабраэффекта. Плюс для таких облаков навыки администрирования важнее чем для (V)DS — неверные настройки (например дефолтные для дистра) могут повлечь неоправданные расходы — 10 экземпляров ждущих апачей для хоста с посещаемостью 10 человек в сутки будут перебором.
В общем, имхо, облака подходят хорошо для проектов с прямой монетизацией, где доходы прямо зависят от посещаемости, либо для благотворительных проектов, где готовы творить благо не взирая на цену (или хостер проявит сознательность и не отрубит социально важный ресурс, типа списков жертв очередной катастрофы, из-за исчерпания бюджета). Для проектов @just for fun@ лучше, имхо, фиксированная плата за фиксированные ресурсы.
Да, вы правы. Практически весь день потребление памяти — 192. Во время бэкапа — чуть больше, чем 280. Во время прохода поисковиков иногда — до 400. Не бэкапиться? Забить на то, что пока паучит Яндекс — никто не может на сайты попасть? Или взять VPS с 384-512 только из-за этого?
У меня сейчас две машинки в селектеле, суммарно — чуть больше 750р. в месяц. Раньше содержимое этих машинок лежало вместе на зеноновском VPS (OpenVZ) с 768 памяти, и несколько раз в месяц VPS ложился при агрессивном проходе поисковиков. Про цену промолчу — там получалось почти вдвое дороже. Причем не получалось пользоваться плюшками PHP 5.3 для новых сайтов, т.к. для части сайтов (которые как раз сейчас на показанной дешевой машинке) требуется ZendOptimizer. Не его аналоги, а именно он сам.
Ну а субъективно — даже после переезда в Клодо мне люди (посетители основного сайта) начали спасибо говорить. А в селектеле — даже по отзывам камчадалов и сибиряков «открывается, как со своего компа».
У меня сейчас две машинки в селектеле, суммарно — чуть больше 750р. в месяц. Раньше содержимое этих машинок лежало вместе на зеноновском VPS (OpenVZ) с 768 памяти, и несколько раз в месяц VPS ложился при агрессивном проходе поисковиков. Про цену промолчу — там получалось почти вдвое дороже. Причем не получалось пользоваться плюшками PHP 5.3 для новых сайтов, т.к. для части сайтов (которые как раз сейчас на показанной дешевой машинке) требуется ZendOptimizer. Не его аналоги, а именно он сам.
Ну а субъективно — даже после переезда в Клодо мне люди (посетители основного сайта) начали спасибо говорить. А в селектеле — даже по отзывам камчадалов и сибиряков «открывается, как со своего компа».
Ну за 750 р. в месяц можно взять VDS (честный KVM) с «гигом мозгов» уж точно. А то и дешевле раза в полтора. Со всеми плюшками рутового доступа. Не говоря о том, что своп нормальный есть.
Зачем? Просто вот из принципа, чтоб он был «нормальный»? Меня больше устраивают две машинки в облаке на разных ОСях. Вообще, спор беспредметный какой-то… Вам лучше нормальный VDS — вы берите себе нормальный. Мне больше нравится селектел. Перестанет нравиться — подберу что-то другое… Главное, без фанатизма ;-)
Если говорить о том, что нравится, то действительно бессмысленный. Я же говорил об экономической эффективности.
Если цена та же — почему обычный VDS эффективнее экономически, чем облачный? К тому же те VDS, о которых вы говорите — за границей, поэтому их эффективность априори ниже, ибо время доступа выше.
Потому что на самом деле вдс с гигом мозгов стоит дешевле даже у реселлеров тех вдс, о которых я говорю :)
У меня нет задач где пинг в 6 мс был бы качественно лучше, чем в 50 мс. Циферки приятные, но практической пользы мало, чтобы за них переплачивать.
volch@ubuhost:~$ ping -c 5 selectel.ru
PING selectel.ru (188.93.16.18) 56(84) bytes of data.
64 bytes from selectel.ru (188.93.16.18): icmp_req=1 ttl=57 time=19.2 ms
64 bytes from selectel.ru (188.93.16.18): icmp_req=2 ttl=57 time=9.73 ms
64 bytes from selectel.ru (188.93.16.18): icmp_req=3 ttl=57 time=7.24 ms
64 bytes from selectel.ru (188.93.16.18): icmp_req=4 ttl=57 time=6.86 ms
64 bytes from selectel.ru (188.93.16.18): icmp_req=5 ttl=57 time=10.7 ms
--- selectel.ru ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 6.866/10.764/19.283/4.500 ms
volch@ubuhost:~$ ping -c 5 hetzner.com
PING hetzner.com (213.133.107.241) 56(84) bytes of data.
64 bytes from dedihetzner.your-server.de (213.133.107.241): icmp_req=1 ttl=55 time=48.5 ms
64 bytes from dedihetzner.your-server.de (213.133.107.241): icmp_req=2 ttl=55 time=41.8 ms
64 bytes from dedihetzner.your-server.de (213.133.107.241): icmp_req=3 ttl=55 time=46.1 ms
64 bytes from dedihetzner.your-server.de (213.133.107.241): icmp_req=4 ttl=55 time=43.0 ms
64 bytes from dedihetzner.your-server.de (213.133.107.241): icmp_req=5 ttl=55 time=49.7 ms
--- hetzner.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4004ms
rtt min/avg/max/mdev = 41.839/45.856/49.761/3.071 ms
У меня нет задач где пинг в 6 мс был бы качественно лучше, чем в 50 мс. Циферки приятные, но практической пользы мало, чтобы за них переплачивать.
А дело не в пинге, а именно во времени, за которое загружается страница с сервера. Полностью, со всеми скриптами и изображениями. Из-за границы это время чувствительно больше, проверено на сравнении Rackspace — Selectel.
К тому же Hetzner, к примеру, для меня отпадает раз и навсегда как минимум из-за того, что может попросить скан кредитки. А я принципиально плачу в тырнете только с виртуальных карт.
К тому же Hetzner, к примеру, для меня отпадает раз и навсегда как минимум из-за того, что может попросить скан кредитки. А я принципиально плачу в тырнете только с виртуальных карт.
Конкретные цифры о времени загрузки сообщите?
А я принципиально не плачу с кредитки (банковской карты) вообще, там где можно обойтись вебманями, ядами, киви и т. п., или простым безналом, пускай даже придётся переплатить посредникам. Просто считаю, что мои траты как физического лица, не должны пересекаться с моими тратами как предпринимателя. Единственная трудность — не могу решить с какого счёта оплачивать доступ в тырнет, иметь два акка и переключаться между ними глупо имхо.
А я принципиально не плачу с кредитки (банковской карты) вообще, там где можно обойтись вебманями, ядами, киви и т. п., или простым безналом, пускай даже придётся переплатить посредникам. Просто считаю, что мои траты как физического лица, не должны пересекаться с моими тратами как предпринимателя. Единственная трудность — не могу решить с какого счёта оплачивать доступ в тырнет, иметь два акка и переключаться между ними глупо имхо.
Нет, конкретные цифры не сообщу — мне незачем измерять, я свой сайт знаю как облупленный за 10 лет-то. И поэтому если он грузится откровенно медленно — для меня это заметно и без цифр.
Спасибо за пример — попробую для своих проектов.
Как по мне так главное преимущество «облаков» возможность собрать «несбалансированную» конфигурацию типа метр мозгов и винт на два терабайта, которую у хостеров (V)DS не встретишь. Плюс да, возможность динамически (у некоторых даже автоматически) менять количество памяти, ЦПУ и винта. Речь идёт об «облаках» предоставляющих, по сути DS, а не типа GAE.
Да. Моментальная доступность любых ресурсов — именно об этом речь.
Но в случае с облаками типа GAE (во всех этих *aaS я плохо ориентируюсь, в общем с биллингом по фактически потребленным ресурсам) есть две опасности при «хаброэффекте» — либо попасть на сумасшедшие деньги, либо (при ограничении, например, суточного бюджета) столкнуться с тем, что сайт будет лежать мёртво. При традиционном хостинге хоть кто-то да пробьётся.
Облака придумали для жирных корпоративных клиентов, чтобы и дальше разводить их на деньги, используя новые красивые слова. Вы думаете, для чего майкрософт свое облако делает. Вы посмотрите, кто были первыми клиентами облачных систем и для кого их рекламируют.
У вас неправильные цены на VPS — у firstvds.ru VPS с 512 Мб ситоит 399 р или $13/мес. К нему прилагается 500 Гб трафика. Есть дешевые хетцнеровские ВПС. А у вас всюду дорогущие цены. Зачем по $40 платить за то же самое.
А, еще очень важно используемое для виртуализации ПО — 512 Мб на OpenVZ (который оверселлят только в путь) и честные 512 Мб на Xen — абсолютно разные вещи.
Плюс, в облаках дорогой трафик: те же 500 Гб в селектеле вам выйдут в 500 рублей (при том что в упомянутом 399-рублевом VPS вам этот трафик дадут бесплатно).
Единственный случай, когда облако выгоднее — крошечный сервер типа 128-256 Мб памяти, который потребляет мало трафика и стоит меньше 100 р в месяц. Во всех остальных случаях выгоднее купить «безлимитный» VPS и юзать по полной программе, тем более что некоторые недалекие хостеры могут долго не замечать перерасход ресурсов, а вот в облаке у вас 100% все посчитают.
Так что у меня складывается впечатление, что это какой-то подвох. ЛЮДИ! Не давайте себя зазомбировать! Не верьте автору!
У вас неправильные цены на VPS — у firstvds.ru VPS с 512 Мб ситоит 399 р или $13/мес. К нему прилагается 500 Гб трафика. Есть дешевые хетцнеровские ВПС. А у вас всюду дорогущие цены. Зачем по $40 платить за то же самое.
А, еще очень важно используемое для виртуализации ПО — 512 Мб на OpenVZ (который оверселлят только в путь) и честные 512 Мб на Xen — абсолютно разные вещи.
Плюс, в облаках дорогой трафик: те же 500 Гб в селектеле вам выйдут в 500 рублей (при том что в упомянутом 399-рублевом VPS вам этот трафик дадут бесплатно).
Единственный случай, когда облако выгоднее — крошечный сервер типа 128-256 Мб памяти, который потребляет мало трафика и стоит меньше 100 р в месяц. Во всех остальных случаях выгоднее купить «безлимитный» VPS и юзать по полной программе, тем более что некоторые недалекие хостеры могут долго не замечать перерасход ресурсов, а вот в облаке у вас 100% все посчитают.
Так что у меня складывается впечатление, что это какой-то подвох. ЛЮДИ! Не давайте себя зазомбировать! Не верьте автору!
Вы знаете, мне как-то хочется ответить на это одно: а, может, не надо идти к недалекому хостеру? Вдруг он через некоторое время станет недалеким не в пользу клиента? Или вообще прогорит и уйдет с рынка из-за своей недалекости?
Прогорит — уйдём к другому :) Но, если серьёзно, то, по-моему, действительно ценовая политика облачных хостеров более жадная (если считать, что затраты примерно равны), чем у традиционных.Да, есть за что платить, если плюсы облака нужны, но если нет, то аналогичный традиционный хостинг скорее обойдётся дешевле, даже если брать его с запасом.
Не жадная, а расчетливая. Сколько потребили — за столько и платите.
Возьмите виртуальный сервер и держите его в качестве резерва без нагрузки — получатся копейки.
Возьмите виртуальный сервер и держите его в качестве резерва без нагрузки — получатся копейки.
Просто почему-то получается, что за 1 Гб оперативки у традиционного хостера я плачу меньше, чем за тот же объём у «облачников». У кого из них 1 Гб стоит порядка 500 р в месяц, не считая цпу, винта и трафика?
Вопросы резервирования, балансировки и прочей отказоустойчивой инфраструктуры (кроме бэкапов по ssh) не рассматриваю.
Вопросы резервирования, балансировки и прочей отказоустойчивой инфраструктуры (кроме бэкапов по ssh) не рассматриваю.
А бесполезно мерить стоимость 1Гб оперативки без учета тех вопросов, которые Вы не рассматриваете.
Если так, то дешевле всего — купить плашку памяти (тот самый 1Гб) и положить себе на стол. Ну, или воткнуть в сервер под столом. Дешевле всего будет, правда. :)
Если так, то дешевле всего — купить плашку памяти (тот самый 1Гб) и положить себе на стол. Ну, или воткнуть в сервер под столом. Дешевле всего будет, правда. :)
Имхо, сейчас ЦА облачных хостингов — те, кто готов платить за фичи, предоставляемые именно облаком. Кому нужен простой (виртуальный) дедик не готовы переплачивать за эти фичи, а приходится.
Еще вопрос будет ли рад владелец шахматного сайта если из-за скачка трафика попадет на бабки от провайдера облака. А в случае с впс-ом он точно знает, что его расходы точно фиксированы.
В случае с VPS он — скорее всего — получит тормозящий / неработающий сайт. И в том случае, если владелец так или иначе зарабатывает на сайте — потеряет деньги. Гораздо бОльшие, чем оплата трафика.
Плюс — потеря репутации. А ее уже за деньги не купишь.
Плюс — потеря репутации. А ее уже за деньги не купишь.
Ну тут не все так очевидно. Ресурс ресурсу рознь и CTR и ROI везде разные. Вполне может выйти так, что уйдете в сильный минус, и тогда придется продать жилье и жена от вас после этого точно уйдет.
P.S. Облака идеальное решение для:
1. Ресурсов на подобие: «Сервиса по создание корпоративных сайтов.»
2. Различных магазинов (доходность обычно не самая плохая).
3. Держать на случайатомной войны больших нагрузок или выхода из строя одного из боевых серверов.
P.S. Облака идеальное решение для:
1. Ресурсов на подобие: «Сервиса по создание корпоративных сайтов.»
2. Различных магазинов (доходность обычно не самая плохая).
3. Держать на случай
Одно дело получить не работающий сайт на один день, что случается у многих. Другое дело попасть на какой ботнет и получить счет на 3 нуля.
Все-таки есть сайты чисто информационные и не являющиеся для компании основным видом деятельности.
Все-таки есть сайты чисто информационные и не являющиеся для компании основным видом деятельности.
А есть сайты с оборотом 1.5 млрд. руб. в год.
Мы же отделяем мух от котлет, правда?
Мы же отделяем мух от котлет, правда?
Что вы все счетами пугаете? С вас не снимут больше, чем было на счету (тут вам не Мегафон ;)). Счет в 0 (или другой порог), сервер выключится. Захотите включить, закинете еще денежку.
Честно говоря, я тоже не считаю это основной проблемой при граммотном подходе. Но вот серьезно не вижу экономии.
Для вполне среднего ресурса, к которому себя отношу, имею практически анлим интернет (после 2 Тб скорость падает до 10 Мбит) в месяц, 40 Гб HDD, RAM 1 Gb + Swap 2 Gb, одно ядро) плачу 13 евро! Куда уж меньше, при том что я постоянно запускаю бэкенд операции на 168 часов в месяц?
Изучал Amazon, Google Apps — кажется вроде привлекательно, но чуть надо задействовать машину на все ресурсы: интернет-трафик большой или процессор загружаешь, счета вылезают гораздо большие.
По поводу расширения ресурсов, это конечно правда, по поводу миграции. По мне так лучше потратить программисто-часы и автомотизировать всю миграцию и экономить в деньгах, хотя зависит от бюджета :)
Для вполне среднего ресурса, к которому себя отношу, имею практически анлим интернет (после 2 Тб скорость падает до 10 Мбит) в месяц, 40 Гб HDD, RAM 1 Gb + Swap 2 Gb, одно ядро) плачу 13 евро! Куда уж меньше, при том что я постоянно запускаю бэкенд операции на 168 часов в месяц?
Изучал Amazon, Google Apps — кажется вроде привлекательно, но чуть надо задействовать машину на все ресурсы: интернет-трафик большой или процессор загружаешь, счета вылезают гораздо большие.
По поводу расширения ресурсов, это конечно правда, по поводу миграции. По мне так лучше потратить программисто-часы и автомотизировать всю миграцию и экономить в деньгах, хотя зависит от бюджета :)
Закинул, скажем, 1000 баксов в расчёте на год, а они внезапно сожрались за день. С обычным хостингом это исключено.
А если это будет паразитный трафик? Небольшой ддос, левые пауки и тд? Тогда это будет вообще работа в чистый минус.
Вставлю всё-таки и свои 5 копеек. Я человек далекий от хостингобизнеса, обычный разработчик, «ваяю сайтеги за лавэ».
Может быть, я остался по в каком-то крайне далеком прошлом и мыслю совершенно не теми категориями… Но те задачи с которыми я сталкиваюсь, четко разделяются на 3 категории:
1) нужна какая-то площадка, на которой будет работать сайт с небольшой посещаемостью (магазин, презентационный, информационный сайтик и т д). Тут владельцы сайтов как предпочитали 5 лет назад managed shared у проверенных хостеров, так и предпочитают до сих пор). В крайнем случае (нестандартные требования) — небольшой managed vps. Главное — небольшие расходы и реактивный саппорт.
2) нужна площадка, на котором будет крутиться некий ресурсоемкий инструмент (к примеру, сферический хрумер в вакууме, паук и т д). Здесь обычно нужна специфическая конфигурация; при этом ресурсоемкость процесса (требования к памяти, объему, траффику и т д) довольно предсказуема. Здесь обычно выбирается xen vps.
3) Серьезный проект. Тут вариантов ровно два. Либо выделенный сервер (хоть atom, но свой), либо (можно договориться в идеале) xen с отдельным диском (лаги связанные с IO на виртуалках — это целый плач ярославны).
Более мощные проекты я оставляю за бортом, там уже обычно довольно специфическая инфраструктура.
Вот я тут выше написал много букв; это все преамбула.
А теперь собственнно вопрос, на который я тщетно пытаюсь найти ответ. Где в этой классификации место облаку?
PS: Разговоры о сравнении цен vds/облака/сервера — это вообще абзац. Если проект представляет собой что-то больше блога, то он сделан живыми людьми, которые за это взяли живые деньги. А месяц работы средненького пхп-кодера стоит как годовая аренда простенького дедика. Выбирать нужно по удобству, а не цене.
Может быть, я остался по в каком-то крайне далеком прошлом и мыслю совершенно не теми категориями… Но те задачи с которыми я сталкиваюсь, четко разделяются на 3 категории:
1) нужна какая-то площадка, на которой будет работать сайт с небольшой посещаемостью (магазин, презентационный, информационный сайтик и т д). Тут владельцы сайтов как предпочитали 5 лет назад managed shared у проверенных хостеров, так и предпочитают до сих пор). В крайнем случае (нестандартные требования) — небольшой managed vps. Главное — небольшие расходы и реактивный саппорт.
2) нужна площадка, на котором будет крутиться некий ресурсоемкий инструмент (к примеру, сферический хрумер в вакууме, паук и т д). Здесь обычно нужна специфическая конфигурация; при этом ресурсоемкость процесса (требования к памяти, объему, траффику и т д) довольно предсказуема. Здесь обычно выбирается xen vps.
3) Серьезный проект. Тут вариантов ровно два. Либо выделенный сервер (хоть atom, но свой), либо (можно договориться в идеале) xen с отдельным диском (лаги связанные с IO на виртуалках — это целый плач ярославны).
Более мощные проекты я оставляю за бортом, там уже обычно довольно специфическая инфраструктура.
Вот я тут выше написал много букв; это все преамбула.
А теперь собственнно вопрос, на который я тщетно пытаюсь найти ответ. Где в этой классификации место облаку?
PS: Разговоры о сравнении цен vds/облака/сервера — это вообще абзац. Если проект представляет собой что-то больше блога, то он сделан живыми людьми, которые за это взяли живые деньги. А месяц работы средненького пхп-кодера стоит как годовая аренда простенького дедика. Выбирать нужно по удобству, а не цене.
В этой классификации места облаку, может, и нет.
Но на любом проекте, для которого простой критичен (простите, но такой проект не живет на одном сервере) — облако пригодится.
Но на любом проекте, для которого простой критичен (простите, но такой проект не живет на одном сервере) — облако пригодится.
Я как представитель Селектела строго негодую от абстрактного «19» в табличке. 19 чего? Попугаев?
Существует две мотивации для облаков: инфраструктурная (грубо говоря, концепция управления собственными ресурсами) и маркетинговая (то бишь связанная с куплей-продажей).
Маркетинговая мотивация: не оплачивать неиспользуемое. Я внимательно смотрю за потреблением ресурсов клиентами, и я могу сказать, что даже самые нагруженные проекты (больше десяти виртуалок с запросами каждой на почти весь хост) не потребляют всех ресурсов. Если не рассматривать синтетику вроде cpuburn и специфичных применений (пережатие видео с очередью заданий, превышающей производительность серверов) во всех остальных случаях виртуальные машины сильно простаивают.
Собственно, вот пример: визуально машина загружена примерно на 750% по CPU (с учётом IO это максимум, который мы предоставляем): реальное потребление за вчера: 124.367 часов, то есть 518%. Где оставшиеся 231%? Моменты простоя, когда ресурсы не используются в полном объёме. Не важно по какой причине — загрузка заданий, перезапуск приложения, утренний спад и т.д…
То же самое касается и остальных ресурсов. Это и именно это является мотивирующей частью облаков.
С обратной стороны (провайдера) это выглядит так: у нас есть ресурсы, которые клиенты заказывают, но не используют (в случае обычного VDS). Мы можем либо их оверселлить (то есть продать ещё раз в надежде, что эти ресурсы исходным заказчиком полностью не будут выбраны), либо нет. Если мы ресурсы оверселлим, мы получаем дополнительную прибыль с шансом, что кто-то из клиентов наткнётся на нехватку ресурсов (когда попытается воспользоваться тем, что он вроде бы оплатил). Если мы не оверселлим, у нас простаивают сервера. Дилемма?
Вот тут и приходит идея с оплатой по потреблению. Мы не ставим лимитов «предоплаченных ресурсов», каждый клиент получает столько, сколько а) ему нужно, б) мы можем дать. В результате мы утилизуем (продаём) наши ресурсы настолько, насколько можем, а клиент получает то, что ему нужно. (В отличие от оверселла, где у поставщика нет стимула обеспечивать ВСЕ обещанные ресурсы, для нас каждая секунда недодачи ресурсов — это потеря средств, так что стимул обеспечивать максимум доступных ресурсов есть, и он куда более действенный, чем «держать качество» — это _деньги_. Не посуетился с балансировкой и миграцией — недополучил денег.
Так вот, сравнение с классическим VDS приводит к простой вещи: у VDS внутри заложен либо простой серверов (задранная цена), либо оверселл (неиллюзорный шанс наткнуться на нехватку ресурсов). И лобовое сравнение цен совершенно неверно.
Существует две мотивации для облаков: инфраструктурная (грубо говоря, концепция управления собственными ресурсами) и маркетинговая (то бишь связанная с куплей-продажей).
Маркетинговая мотивация: не оплачивать неиспользуемое. Я внимательно смотрю за потреблением ресурсов клиентами, и я могу сказать, что даже самые нагруженные проекты (больше десяти виртуалок с запросами каждой на почти весь хост) не потребляют всех ресурсов. Если не рассматривать синтетику вроде cpuburn и специфичных применений (пережатие видео с очередью заданий, превышающей производительность серверов) во всех остальных случаях виртуальные машины сильно простаивают.
Собственно, вот пример: визуально машина загружена примерно на 750% по CPU (с учётом IO это максимум, который мы предоставляем): реальное потребление за вчера: 124.367 часов, то есть 518%. Где оставшиеся 231%? Моменты простоя, когда ресурсы не используются в полном объёме. Не важно по какой причине — загрузка заданий, перезапуск приложения, утренний спад и т.д…
То же самое касается и остальных ресурсов. Это и именно это является мотивирующей частью облаков.
С обратной стороны (провайдера) это выглядит так: у нас есть ресурсы, которые клиенты заказывают, но не используют (в случае обычного VDS). Мы можем либо их оверселлить (то есть продать ещё раз в надежде, что эти ресурсы исходным заказчиком полностью не будут выбраны), либо нет. Если мы ресурсы оверселлим, мы получаем дополнительную прибыль с шансом, что кто-то из клиентов наткнётся на нехватку ресурсов (когда попытается воспользоваться тем, что он вроде бы оплатил). Если мы не оверселлим, у нас простаивают сервера. Дилемма?
Вот тут и приходит идея с оплатой по потреблению. Мы не ставим лимитов «предоплаченных ресурсов», каждый клиент получает столько, сколько а) ему нужно, б) мы можем дать. В результате мы утилизуем (продаём) наши ресурсы настолько, насколько можем, а клиент получает то, что ему нужно. (В отличие от оверселла, где у поставщика нет стимула обеспечивать ВСЕ обещанные ресурсы, для нас каждая секунда недодачи ресурсов — это потеря средств, так что стимул обеспечивать максимум доступных ресурсов есть, и он куда более действенный, чем «держать качество» — это _деньги_. Не посуетился с балансировкой и миграцией — недополучил денег.
Так вот, сравнение с классическим VDS приводит к простой вещи: у VDS внутри заложен либо простой серверов (задранная цена), либо оверселл (неиллюзорный шанс наткнуться на нехватку ресурсов). И лобовое сравнение цен совершенно неверно.
Лучший комментарий. Спасибо, коллега.
Спасибо за комментарий!
Так вот, сравнение с классическим VDS приводит к простой вещи: у VDS внутри заложен либо простой серверов (задранная цена), либо оверселл (неиллюзорный шанс наткнуться на нехватку ресурсов). И лобовое сравнение цен совершенно неверно.
Согласен, что лобовое сравнение неприемлемо, но пока я предпочитаю оплачивать простой сервера в обычной ситуации и то, что не каждый посетитель моего ресурса в случае хабраэффекта получит ответ, чем оплачивать реально потребленные, но в случае хабраэффекта либо попасть на деньги (ресурсы не коммерческие), либо отказывать всем посетителям при ограничении суточного бюджета.
… в случае хабраэффекта либо попасть на деньги...
Мне кажется вы преувеличиваете количество денег на которые можно попасть в случае хабраэффекта )
У меня например есть облако в селектеле, плачу до 200р. вы в этом топике писали в пример о впс за 700р. с гигом памяти…
впс еще не факт что выдержит хабраэффект, облако выдержит и не думаю что он на облаке обойдется дороже чем 500р. ;) а если хабраэффекта не будет, то сэкономлю 500р… а если посчитать за несколько месяцев?
Ну я цифру не называл, на самом деле 550 р/мес одно ядро на, кажется, 2,3ГГц и гиг памяти (KVM вроде исключает оверселлинг). Но я точно знаю один ресурс, который переехал (судя по whois) с селектела на мажордомо во время недельной ддос атаки (вроде 1000 http запросов в секунду) из-за финансовых причин.
Не факт, что выдержит, но отрубится (если отрубится) по физическим причинам, а не финансовым, а если не отрубится, то хоть медленно, но будет отвечать на запросы, пускай и не на все. Страничку «владелец ресурса решил, что ему не стоит тратить деньги на вас» посетитель не увидит, а увидит в худшем случае сообщение браузера о таймауте или невозможности установить соединение.
Не факт, что выдержит, но отрубится (если отрубится) по физическим причинам, а не финансовым, а если не отрубится, то хоть медленно, но будет отвечать на запросы, пускай и не на все. Страничку «владелец ресурса решил, что ему не стоит тратить деньги на вас» посетитель не увидит, а увидит в худшем случае сообщение браузера о таймауте или невозможности установить соединение.
Единственный ресурс облака, который вы не можете контролировать — это входящий трафик. И это самый дешёвый ресурс (я не видел ни кого, кто бы на это жаловался).
Все остальные ресурсы вы, как системный администратор своего сервера, можете контролировать.
Вы можете запретить апачу принимать слишком много соединений. Вы можете запретить вашему sql'ю выполнять запросы дольше N времени и т.д. Вы можете запретить или ограничить исходящий трафик с вашей машины.
Всё в ваших руках.
Все остальные ресурсы вы, как системный администратор своего сервера, можете контролировать.
Вы можете запретить апачу принимать слишком много соединений. Вы можете запретить вашему sql'ю выполнять запросы дольше N времени и т.д. Вы можете запретить или ограничить исходящий трафик с вашей машины.
Всё в ваших руках.
То вы сначала о хабраэффекте, то уже о ддосе…
А хабраэффект если будет, то скушает наверное суму явно меньшую за ту которою экономлю в месяц, не говоря уже о нескольких… напр
А ддос, хм интересно многих ли ддосят? И часто?)) Люди где то услышали про ддос и думают что и их будут обязательно ддосить))
А хабраэффект если будет, то скушает наверное суму явно меньшую за ту которою экономлю в месяц, не говоря уже о нескольких… напр
А ддос, хм интересно многих ли ддосят? И часто?)) Люди где то услышали про ддос и думают что и их будут обязательно ддосить))
Например, сайт браузерной игры может быть задидосен обиженным игроком.
К чему этот пример?))) «Могут» и «ддосят» как бы совсем разные вещи)
То есть все должны жить в страхе что их якобы заддосят и держать для этого свой дедик, при этом переплачивая за него значительную сумму?)))) бред…
То есть все должны жить в страхе что их якобы заддосят и держать для этого свой дедик, при этом переплачивая за него значительную сумму?)))) бред…
Это реальная ситуация, с которой я столкнулся на прошлой неделе.
А переплата будет, имхо, в случае облака.
А переплата будет, имхо, в случае облака.
Сначала пишите:
потом
вы уж как то определитесь и цифры поконкретнее назовите)) вам здесь дали несколько реальных примеров как в облаке выходит дешевле, а у вас пока только свое «имхо» сами то и не пробовали)
Но я точно знаю один ресурс, который переехал (судя по whois) с селектела на мажордомо во время недельной ддос атаки (вроде 1000 http запросов в секунду) из-за финансовых причин.
потом
Это реальная ситуация, с которой я столкнулся на прошлой неделе.
вы уж как то определитесь и цифры поконкретнее назовите)) вам здесь дали несколько реальных примеров как в облаке выходит дешевле, а у вас пока только свое «имхо» сами то и не пробовали)
Имея неограниченные ресурсы ограничить себя проще, чем имея ограниченные ресурсы получить анлим.
По пунктам:
лишние ядра выключаются: echo 0 >/sys/devices/system/cpu/cpu3/online
Память/число процессов ограничивается ulimit'ом
Сеть ограничивается iptables. Фактически ограничить получится только исходящий трафик, но входящий очень дешёвый, так что особых проблем не составит.
Диск по производительности ограничивается хреново, по месту — квотами.
По пунктам:
лишние ядра выключаются: echo 0 >/sys/devices/system/cpu/cpu3/online
Память/число процессов ограничивается ulimit'ом
Сеть ограничивается iptables. Фактически ограничить получится только исходящий трафик, но входящий очень дешёвый, так что особых проблем не составит.
Диск по производительности ограничивается хреново, по месту — квотами.
Имея физически ограниченные ресурсы, можно получить ситуацию, когда хоть кому-то ресурс но отвечает.
Можно ли из вашей админки настроить политику «отвечать на 100 http запросов в секунду, остальным отдавать 5xx или вообще TCP/IP соединения не устанавливать»? Насколько я знаю — нет, а простых способов настроить такую политику из консоли я тоже не знаю. Я не администратор, а разработчик веб-приложений, а то и просто веб-мастер. Я могу настроить количество экземпляров nginx и рhp исходя из известных мне доступных ресурсов и потребления памяти каждым экземпляром, но не могу ограничить количество запросов в секунду, так чтобы не превысить бюджет. Или у вас всё же есть опция в админке ограничения бюджета в секунду, а не в сутки или час?
Можно ли из вашей админки настроить политику «отвечать на 100 http запросов в секунду, остальным отдавать 5xx или вообще TCP/IP соединения не устанавливать»? Насколько я знаю — нет, а простых способов настроить такую политику из консоли я тоже не знаю. Я не администратор, а разработчик веб-приложений, а то и просто веб-мастер. Я могу настроить количество экземпляров nginx и рhp исходя из известных мне доступных ресурсов и потребления памяти каждым экземпляром, но не могу ограничить количество запросов в секунду, так чтобы не превысить бюджет. Или у вас всё же есть опция в админке ограничения бюджета в секунду, а не в сутки или час?
У нас нет «админки». Всё в ваших руках — как хотите виртуальный сервер, так и настраиваете.
Если вы только веб-разработчик и знать ничего не знаете про шелл, права, менеджер пакетов и т.д., то вам к PaaS — там за вас эти вопросы разруливают как могут. Цена удовольствия — вендор лок, причём, чем удобнее и функциональнее, тем сильнее этот лок.
Если вы только веб-разработчик и знать ничего не знаете про шелл, права, менеджер пакетов и т.д., то вам к PaaS — там за вас эти вопросы разруливают как могут. Цена удовольствия — вендор лок, причём, чем удобнее и функциональнее, тем сильнее этот лок.
То есть я не могу ограничить потребляемый аккаунтом бюджет принудительно вообще? Не конфиги править с оглядкой на ваши тарифы, а тупо сказать вам «если работа машины стоит больше 86,4 р. в сутки или 1 коп. в секунду, то отрубайте нафиг до конца суток или секунды (а в идеале измерения и по суткам, и по секундам, с прогнозированием затрат, с возможностью выбора приоритетов и отсекания части запросов)».
Я знаю про шелл, права, менджеры пакетов и т. п. (иначе бы не дискутировал на тему что лучше, вдс или облако), но я не знаю как в линуксе (или виндовсе) ограничить входящий трафик или как ограничить потребление цпу и/или иопов машиной в целом, да даже отдельным процессом, из шелла или менеджера пакетов :)
PaaS в виде GAE (sorry, если GAE не PaaS, я в ваших *aaS соабо разбираюсь) меня тоже не устроил в виду невозможности гибко регулировать свои расходы.
Я знаю про шелл, права, менджеры пакетов и т. п. (иначе бы не дискутировал на тему что лучше, вдс или облако), но я не знаю как в линуксе (или виндовсе) ограничить входящий трафик или как ограничить потребление цпу и/или иопов машиной в целом, да даже отдельным процессом, из шелла или менеджера пакетов :)
PaaS в виде GAE (sorry, если GAE не PaaS, я в ваших *aaS соабо разбираюсь) меня тоже не устроил в виду невозможности гибко регулировать свои расходы.
Можете. Я же писал выше. Вы идёте и настраиваете квоты, аккаунтинг и т.д. по своему усмотрению. Но да, если вы «во всём этом не разбираетесь», то вы не наш клиент, потому что мы предоставляет инфраструктуру и только.
Я настраиваю свою ОС у вас или свой аккаунт у вас? Оперирую техническими характеристиками типа мегабайтов и процентов использования ЦПУ или финансовыми типа рублей? Когда я беру дедик (пускай и виртуальный), я оперирую физическими характеристиками, у вас так получится?
Вы настраиваете у нас свою ось. Пока что мы предоставляем вам в начале некую минимальную конфигурацию, в дальнейшем я надеюсь дать возможность вообще ставить «что попало» — и всю настройку осуществляет пользователь виртуальной машины.
В биллинге мы учитываем, сколько ресурсов потребила ваша машина — и только. Дальше это ваша и только ваша свобода решать сколько ресурсов будет просить ваша машина.
В биллинге мы учитываем, сколько ресурсов потребила ваша машина — и только. Дальше это ваша и только ваша свобода решать сколько ресурсов будет просить ваша машина.
>>Я не администратор
Ключевое заявление. Простите, но инфраструктуру надо администрировать.
Ключевое заявление. Простите, но инфраструктуру надо администрировать.
Я покупаю не инфраструктуру, а ресурсы для своего приложения. А в худшем случае не для своего, а для стороннего типа вордпресса или друпала, в котором я не смогу малой кровью организовать хоть какой-то контроль за нагрузкой через, например, shared memory или прочие мьютексы. В Сети есть хаутушки по оптимальной настройки в условиях ограниченных вычислительных ресурсов, но нет хаутушек по настройке в условиях неограниченных ресурсов при ограниченном бюджете.
Отпугивает меня от облаков прежде всего неограниченность расходов при желаемом уровне доступности. Я не хочу, чтобы мой ресурс лежал сутки после первой тысячи запросов в первую минуту суток, а хочу чтобы из каждой тысячи обслуживался один запрос при общем количестве в миллион. Также я не хочу, чтобы за первую минуту его анонсирования на хабре, он выжрал готодовой бюджет. Традиционный хостинг мне худо-бедно позволяет на системном уровне регулировать эти вопросы выбранным тарифом, пускай 999 запросов выдадут 5хх Out of memory, но тысячный ответ отдаст 200 ОК.
Отпугивает меня от облаков прежде всего неограниченность расходов при желаемом уровне доступности. Я не хочу, чтобы мой ресурс лежал сутки после первой тысячи запросов в первую минуту суток, а хочу чтобы из каждой тысячи обслуживался один запрос при общем количестве в миллион. Также я не хочу, чтобы за первую минуту его анонсирования на хабре, он выжрал готодовой бюджет. Традиционный хостинг мне худо-бедно позволяет на системном уровне регулировать эти вопросы выбранным тарифом, пускай 999 запросов выдадут 5хх Out of memory, но тысячный ответ отдаст 200 ОК.
Секунду. Мы предоставляем IaaS. То есть «продаём» (точнее, сдаём в аренду) ресурсы инфраструктуры. Таким образом, действительно, ваши ожидания от «товара» не соответствуют его описанию (аналогично можно требовать в автосервисе услуг по вождению автомобиля — это просто другие услуги).
Я ж выше написал, что есть PaaS, где вам предоставляют платформу.
И главное — вы можете настроить свои сервера так, чтобы они работали с фиксированной производительностью. Пожалуй, я себе внесу в заметку и напишу отдельную статью по этой теме.
Я ж выше написал, что есть PaaS, где вам предоставляют платформу.
И главное — вы можете настроить свои сервера так, чтобы они работали с фиксированной производительностью. Пожалуй, я себе внесу в заметку и напишу отдельную статью по этой теме.
И при этом получается, что хетзнеровские VDS выходят дешевле, чему выше были примеры. Что-то не сходится, вам не кажется?
Так очевидно, по-моему, что за гибкость и возможность платить «по факту» нужно переплачивать. Пока, по крайней мере.
Вы это меряли или по циферкам из статьи смотрите? У нас есть множество клиентов, у которых машины хостят мелкие сайты в пределах «до 100р».
Кстати, сравнение Хетзнеров и нас я не могу делать, потому что десктопное железо — несколько не гут. Извините за предвзятость.
Кстати, сравнение Хетзнеров и нас я не могу делать, потому что десктопное железо — несколько не гут. Извините за предвзятость.
Я мерял. Правда несколько абстрактно, анализируя логи и прочие *top'ы на хетцнеровском дедике и прикидывая их к вашим ценникам. Да, брать вдс для сайта с посещаемостью 1 заход в сутки, и то владельцем, смысла не имеет, лучше у вас. Когда доход от сайта напрямую зависит от посещаемости, тоже лучше у вас (если есть прибыль у владельца сайта). Но вот в ситуации когда платят только 5 посетителей, независимо от того было их 5 или 100 000, выгоднее, имхо, ограниченные ресурсы за ограниченную плату, даже с условием возврата части платежей за временную недоступность ресурса в случае хабраэффекта или ддоса.
А вы не меряйте абстрактно, а попробуйте залить один и тот же сайт в селектел и на хетцнер. И переместите ДНС на сутки-двое в селектел. И сразу увидите и примерную стоимость, и почувствуете разницу в скорости доступа.
В том и дело, что разница будет примерной и отражающей среднюю нагрузку, а не пиковую.
Проведите нагрузочный тест. JMeter, tsung и т.п. — масса инструментов для этого.
Я знаю про существование даже ab и curl. В том-то и дело, что при тысяче запросов в секунду они за эту секунду выжирают суточный бюджет ресурса, а потом он становится недоступным для всех.
Я мерял. Правда несколько абстрактно, анализируя логи и прочие *top'ы на хетцнеровском дедике и прикидывая их к вашим ценникам
В том-то и дело, что при тысяче запросов в секунду они за эту секунду выжирают суточный бюджет ресурса, а потом он становится недоступным для всех.
Вы явно здесь спорите о том чего не знаете, вот специально решил проверить на тисячу запросов
баланс до
баланс после (тест кстати запускался не один раз)
Debian Squeeze (32) apache+nginx
Память выставлена от 256.00 Mb до 1536.00 Mb во время теста больше 512мб не поднималась)
… при тысяче запросов в секунду они за эту секунду выжирают суточный бюджет ресурса...
как видите даже рубля не накапало)))
А если у меня суточный бюджет 15 копеек? :) Да и судя по 15 мс, у вас не происходит 30-40 SQL запросов на главной, как любит делать, например, Drupal.
А если у меня суточный бюджет 15 копеек? :)
ага, а месячный бюджет на хостинг 4,5 рубля?
Да и судя по 15 мс, у вас не происходит 30-40 SQL запросов на главной, как любит делать, например, Drupal.
это уже проблема не облака, здесь все зависит от прямоты ваших рук)))
Хотелось бы вообще войти в бесплатные лимиты. поскольку проект не коммерческий и даже 5 рублей раз в месяц ходить ложить на киви обломно, а говорят, что ещё и небезопасно и поступления денег на счёт хостера можно и не дождаться.
Сначала пишите о том что у вас дедик
а потом про бесплатные лимиты и не коммерческий проект?)
не думаю что за дедик вы платите 5 рублей) вам здесь привели реальные примеры и реальные цифры, а ваши «аргументы» как то не очень впечатляют)
Я мерял. Правда несколько абстрактно, анализируя логи и прочие *top'ы на хетцнеровском дедике и прикидывая их к вашим ценникам
а потом про бесплатные лимиты и не коммерческий проект?)
Хотелось бы вообще войти в бесплатные лимиты. поскольку проект не коммерческий и даже 5 рублей раз в месяц ходить ложить на киви обломно
не думаю что за дедик вы платите 5 рублей) вам здесь привели реальные примеры и реальные цифры, а ваши «аргументы» как то не очень впечатляют)
За дедик плачу для своих нужд (в основном коммерческих и закрытых), не хотелось бы смешивать и много платить за некоммерческий публичный проект.
Не впечатляют и ладно, переубедить никого не рассчитывал. Просто информация для размышления, что плата по потреблению ресурсов может оказаться в конкретном случае минусом, а не плюсом. Риском резко увеличить расходы (а где-то и в долги влезть) при неожиданном росте нагрузки, а не уменьшить их. Нет настройки «тратить каждую секунду максимум 1 копейку», чтобы положить 5000 и не переживать, что в конце месяца должен останешься или большую часть месяца сервер будет отключен.
Не впечатляют и ладно, переубедить никого не рассчитывал. Просто информация для размышления, что плата по потреблению ресурсов может оказаться в конкретном случае минусом, а не плюсом. Риском резко увеличить расходы (а где-то и в долги влезть) при неожиданном росте нагрузки, а не уменьшить их. Нет настройки «тратить каждую секунду максимум 1 копейку», чтобы положить 5000 и не переживать, что в конце месяца должен останешься или большую часть месяца сервер будет отключен.
Не впечатляют и ладно, переубедить никого не рассчитывал
Прям уже так и не рассчитывали? столько комментов к этому топику оставили)))
Просто информация для размышления, что плата по потреблению ресурсов может оказаться в конкретном случае минусом, а не плюсом
Только эти ваши конкретные случаи встречаются крайне редко)
«волков бояться — в лес не ходить»?
Риском резко увеличить расходы (а где-то и в долги влезть) при неожиданном росте нагрузки, а не уменьшить их
В этом топике уже не раз вам писали о том что в минус нельзя уйти
Нет настройки «тратить каждую секунду максимум 1 копейку»
Это вообще брэд, может еще ресурсы регулировать от погоды, или от ваших мыслей?)) Как бы сначала ресурсы, а деньги потом) у вас есть просто ограничить максимум этих выделяемых ресурсов…
положить 5000 и не переживать, что в конце месяца должен останешься или большую часть месяца сервер будет отключен
У вас просто облакофобия и вы думаете что при хабраэффекте с вас снимут бешеные деньги)) выше вы писали что
… при тысяче запросов в секунду они за эту секунду выжирают суточный бюджет ресурса...
я вам показал на примере что на самом деле там копейки, вот например еще один пример что деньги на хабраэффекты траться не большие — habrahabr.ru/blogs/cloud_computing/118235/ (там еще старые цены, сейчас цена на трафик меньше) хотя еще раз говорю что все зависит и от прямоты ваших рук…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
«Облако» как альтернатива традиционному хостингу