Пользователь
2,4
рейтинг
29 августа 2011 в 17:47

Администрирование → «Облако» как альтернатива традиционному хостингу


На последнем РИФе я рассказывал об «облаке» как альтернативе традиционному хостингу (на примере Амазона).

С тех пор прошло несколько месяцев. За это время я многократно дискутировал как с ярыми противниками «облака», так и с не менее активными сторонниками.

Последний такой спор случился пару дней назад непосредственно с хостерами. И закончился (с их стороны) примерно таким выводом: «Сейчас облако в хостинге — маркетинговое зло, которое только путает людей».

Тема, как мне кажется, не просто популярная и интересная, но и очень важная. Поэтому я хотел бы обобщить свой собственный опыт (у меня есть несколько личных сайтов на виртуальном shared хостинге, периодически по знакомству присматриваю за одним дедиком, а все рабочие проекты размещены в «облаке» Амазона) и вместе с вами постараться разобраться во всех плюсах и минусах облачного хостинга по сравнению с традиционным.

Говоря в целом о традиционном хостинге, я буду подразумевать любое размещение веб-проектов – чаще VPS, colo или dedicated и чуть в меньшей степени шаред хостинг.

Под «облаком» я в общем случае буду иметь в виду IaaS (Infrastructure as a Service) – «предоставление компьютерной инфраструктуры (как правило в форме виртуализации) как услуги на основе концепции облачных вычислений» (Wikipedia).

(Вообще, обещаю в тексте пореже употреблять разные «...aaS» :) «Облако» — звучит позитивнее, а для конечных пользователей создается хотя бы видимость понятности того, о чем идет речь. Хотя и этот термин уже «замусорен».)

Для потребителя «облако» — это любая вычислительная структура, предоставляемая как сервис по его запросу или автоматически.

С точки зрения провайдера это:
  • Аппаратные ресурсы (серверы, сетевое оборудование, системы хранения данных, каналы связи и т.д.)
  • Системное ПО (виртуализация)
  • Управляющее ПО (биллинг, API и т.д.)

Едва ли не самый частый и самый активно использующийся посыл к переходу на «облака» вообще (и IaaS – в частности) – уменьшение затрат и экономия.

И в этом, как мне кажется, состоит очень большая и серьезная ошибка «облачных» маркетологов.

Давайте попробуем разобраться, есть ли эта самая экономия, и в чем она.

Табличка ниже – сравнение некоторой типовой конфигурации VPS «традиционных» хостеров и виртуальных машин в облаке: приблизительно 800 Mhz CPU, 512 Mb RAM. (Обычный shared хостинг в данном случае не берем в расчет, так как не сможем оценить выделенные ресурсы. Как бы ни лимитировали хостеры те или иные ресурсы, все равно обычный хостинг – это общежитие: кто первый встал – того и тапки.)



Цены — в у.е. (похожие на доллары :)).

Сравнение это не идеально, не следует его использовать как серьезный ориентир при выборе провайдера. Например, у некоторых хостеров нет строго той конфигурации, которую сравниваем мы, поэтому – выбираем ближайшую похожую.

Цель таблички – показать лишь соотношение цен. «Облако» в среднем в полтора-два раза дешевле.

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

Вроде бы – дешевле, но...

Мы начинаем работать в облаке и сталкиваемся с такими (не самыми очевидными на первый взгляд) сложностями:
  • Почти всегда отдельно рассчитывается стоимость траффика.
  • Мы (возможно, впервые в жизни) начинаем сталкиваться с таким понятием как «расчеты по потреблению»: если наша виртуальная машина не с жесткой фиксированной ценой, то мы платим за потребленное процессорное время, использованную память; в любом случае – сталкиваемся с таким понятием как IOPS (Input-Output Operations Per Second) – и платим за это.
  • При оплате «по потреблению» при резком росте нагрузки (DDoS, «хабраэффект», ошибки в разработке) возможны значительные расходы (в разы больше запланированных).

Где же реальная экономия?

На самом деле, мы не напрямую сокращаем текущие расходы, а оптимизируем несколько иные процессы.

Нет инсталляционных платежей

Для больших проектов – если речь идет о покупке собственного оборудования – больше не нужно выделять значительные средства из бюджета.

Из этого пункта автоматически следует еще одно важное преимущество «облака»:

Минимальные финансовые риски на старте нового проекта

Если вы запускаете новый стартап, то не можете заранее гарантированно знать, взлетит он или нет. «Пошел» проект – отлично, все вложения (в том числе в инфраструктуру) будут окуплены.

А если нет? И вы при этом уже потратились на серверы, софт, заплатили зарплату тем сотрудникам, которые занимались разворачиванием всей инфраструктуры?

В «облаке» вы рискуете только абонентской платой за тот период, в течение которого обслуживалась ваша виртуальная инфраструктура.

Потери в случае неудачи не столько велики (а зачастую – вообще минимальны). И они не отобьют у вас желания реализовывать новые идеи и запускать новые стартапы. :)

Человеческие ресурсы для обслуживания системы

Если речь идет о большом парке машин (десятки-сотни-тысячи), то в виртуальной среде обслуживать их гораздо легче. Компания Microsoft рассказывала о собственном опыте: один системный администратор может обслуживать в «облаке» в десять (и более) раз больше машин, чем реальных физических серверов.

Экономия времени

Любые сервисные работы (добавление дисков в серверы, добавление новых машин и т.п.) в «облаке» будут выполнены быстрее.

* * *

А теперь давайте попробуем разобраться, есть ли у «облака» другие (возможно, даже более очевидные) преимущества?

Must have любого по-настоящему хорошего проекта – регулярные нагрузочные тесты (как перед запуском, так и в процессе работы – на стендах). Нагрузочное тестирование позволяет определить предел работоспособности созданного проекта именно на выбранном оборудовании и дает примерную оценку — когда потребуется масштабирование тех или иных ресурсов.

А иногда масштабирование нужно внезапно! :)

Например, живет себе в сети сайт, посвященный шахматам. И заходит на него 1-2 тыс. человек в день. И тут «внезапно» и непредсказуемо случается шахматный турнир. Посещаемость вырастает в разы, а администратор оказывается не готов к подобной нагрузке.

Оба этих проекта – и «сферический идеальный веб-сайт», и наш шахматный сервер объединяет одно: любое масштабирование потребует времени на выделение новых ресурсов, на перенос проекта на более мощное оборудование и т.п. Во время этих работ (если переезд внезапный) сайт, скорее всего, будет недоступен для посетителей. А это все — деньги владельца проекта.

Следующий момент. Рано или поздно мы упираемся в потолок: мы не можем наращивать мощность сервера неограниченно. К тому же с ростом мощности сервера его стоимость растет не пропорционально. И тут мы переходим к горизонтальному масштабированию (если поддерживает архитектура проекта) – наращиваем не мощности одного сервера, а добавляем новые машины.

И наконец, последний крайне важный момент – обратное масштабирование, чтобы ресурсы не работали вхолостую, и чтобы мы не думали о том, куда деть незадействованные серверы. Шахматный турнир идет не круглый год. Через некоторое время ресурсы, выделенные на пиковую посещаемость оказываются невостребованными (до следующего столь же значимого события).

Масштабирование в «облаке» — простая, понятная и чрезвычайно легкая операция!
  • Увеличение ресурсов виртуальной машины доступно моментально.
  • Столь же моментально доступно не только вертикальное, но и горизонтальное масштабирование (можно получить практически любое количество виртуальных машин нужной конфигурации).
  • После того, как отпадает необходимость в большом количестве ресурсов, мы просто отказываемся от них и перестаем за них платить.

Моментальная доступность любых ресурсов – вообще одно из важнейших преимуществ «облака».

Живой пример, с которым мне как-то довелось столкнуться на практике – срочная необходимость переноса большого «тяжелого» проекта (который жил на отдельном выделенном физическом сервере) в другой датацентр 7-го января.

В нашей стране Новый год отмечают с размахом. И работают в новогодние каникулы лишь те проекты, которым посчастливилось не столкнуться с проблемами в тот период, когда вся страна пьет и гуляет.

Итог обзвона полутора десятков российских хостеров, который предлагают услуги dedicated / colocation: можно разместить свой проект только на типовой стандартной конфигурации, которая уже есть в прайс-листе. И то – только по знакомству. И в лучшем случае — в течение суток. А что-то нестандартное и тем более быстрее – не получится… :(

Итог – проект перенесен в «облако» Амазона.

Напоследок хочу немного поговорить о надежности размещения проектов в «облаке».

Часто слышу такой тезис: облако надежнее.

На мой взгляд, он вводит пользователей в заблуждение и в итоге работает только против.

Не «облако надежнее», а «облако» дает гораздо больше возможностей построить надежную инфраструктуру.

1. Почти все серьезные «облачные» провайдеры владеют несколькими датацентрами, что позволяет им резервировать (на своем уровне) практически все ресурсы. Для конечных пользователей это дает возможность разместить свой веб-проект не на одном виртуальном сервере, а на веб-кластере, состоящем из нескольких резервирующих друг друга серверов, расположенных в разных датацентрах.

Если же нет возможности (например, дорого) постоянно держать полную копию проекта, можно использовать значительно более слабую машину, например, под бэкап данных и базы (например, slave MySQL). В случае аварии проект на резервном сервере быстро переводится в рабочий режим, а сам сервер масштабируется до нужного количества доступных ресурсов (память, CPU и т.д.)

2. Многие «облачные» провайдеры предлагают специализированные облачные хранилища для статического контента (например, Amazon S3).

Они на самом деле надежны, так вся их архитектура такова, что уже непосредственно в ней заложено резервирование на уровне датацентра.

Перенос статического контента в такое хранилище позволяет минимизировать размер и время создания бэкапов. Соответственно – минимизировать и время их разворачивания в случае какой-либо аварии.

3. Те же бэкапы – можно хранить в том же облачном хранилище.

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

Если же проект размещается в одном датацентре на одном или нескольких физических серверах, то в случае аварии (обесточен датацентр):
  • У владельца нет доступа к данным. Вообще. Остается только ждать, когда авария будет ликвидирована.
  • Если нет возможности ждать (крайне критична доступность сервиса) — нужно брать данные из бэкапа. Из какого? Как и куда его делать? В другой датацентр?
  • Отдельный вопрос – в какой другой датацентр переезжать во время аварии. Найти сервер нужной конфигурации (как мы уже разбирали выше) – не самая тривиальная задача. Требующая времени.
  • Переехали. Надо менять DNS. Это – опять время. В случае использования «облака», у которого есть несколько датацентров, можно просто «перевесить» прежний IP на новую машину.


* * *

Давайте резюмируем.

Минусы «облака»:
  • Не является альтернативой хостингу за 200-300 руб./мес.
  • Затраты (время) на обучение сотрудников специфике конкретного сервиса
  • Ограничения инфраструктуры (аппаратная часть, специфичное ПО)
  • Сложность расчетов «по потреблению»

Плюсы «облака»:
  • Экономия за счет возможности планирования ресурсов
  • Экономия и отсутствие рисков, связанные с вложениями в инфраструктуру
  • Моментальное вертикальное и горизонтальное масштабирование
  • Удобство администрирования
  • Экономия времени
  • Дополнительные сервисы

Кстати, именно дополнительные сервисы зачастую являются одним из факторов, по которым в итоге выбирается «облачный» провайдер.

Возможность размещения в разных датацентрах, множество готовых образов операционных систем, обеспечение доступности в SLA, гибкие конфигурации дисков, «облачные» базы данных, «облачный» кэш данных, конфигурирование файрволла через веб-интерфейс для групп машин, создание копий виртуальных машин и т.д. и т.п.

Масса возможностей для «облачных» провайдеров для конкуренции и привлечения клиентов. :)

* * *

Закончу я свой пост цитатой Брета Тейлора, ныне — технического директора Facebook, а немного ранее — сооснователя FriendFeed: «Когда мы только начинали работу над стартапом (FriendFeed), нам нужно было решить, покупать собственные серверы или же выбрать одного из «облачных» хостинг-провайдеров – таких как Amazon (AWS). Мы выбрали первое – решили приобрести собственные серверы. Оглядываясь назад, я думаю, что это было большой ошибкой.»
Alexander Demidov @adamant
карма
59,0
рейтинг 2,4
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Администрирование

Комментарии (160)

  • +3
    Отличная статья. Хотел бы добавить, что облака предоставляют разработчику и архитектору море новых возможностей и инструментов — как для масштабирования, так и обеспечения надежности. Фактически тебе становятся доступны «неубиваемые» сервисы + даны инструменты для создания других «неубиваемых» сервисов. И можно сконцентрироваться на решении бизнес-задачи, а не бэкапах и рестартах апача :-)
  • +16
    Александр, Вы так и недождались нашей дуэли =)

    Пока я не вижу причин полагать, что изречение «Сейчас облако в хостинге — маркетинговое зло, которое только путает людей» — неверно.

    Есть несколько моментов, которые я не принимаю:

    1. «Облако» упрется вертикально — в 1 сервер (лезвие), горизонтальное мастабирование — нужно уметь с ним работа
    ть — нужен спец.
    2. Резервирование на уровне цод — только слова
    3. Стоимость. При нагруженном проекте — выгоднее свой сервер (несколько серверов в разных реальных ЦОДах)

    Покажите, пожалуйста, в России «облако», которое будет близко например по стоимости к серверу на одном Оптероне 6168, 8Gb, 3x1Tb за ~230 евро?

    Итог — «облако» может быть интересно только стартапу и сайтам визиткам, которые считают каждый рубль.

    Предлагаю с «облаков» спуститься на землю и продолжить оптимизироваться =)
    • +9
      1. Попробую без рекламы. ;) Скажем так, есть продукты, в которых горизонтальное масштабирование поддерживается «почти из коробки». Почти — потому что, конечно, некоторые действия потребуются.

      2. Резервирование на уровне ЦОД — реальность. ;) Вот, у нас лично — в Амазоне.

      Если взять Россию, то у Скалакси — два датацентра, у Селектел — четыре. Да, маловато пока, но, надеюсь, дорастем и до более масштабных сетей. :)

      3. Стоимость… Вот я как раз и начал с того, что это — не ключевой параметр.

      Вот, лично для меня — важнее надежность и доступность проекта. И я готов за это даже немного переплатить.
      • +3
        А как кореллирует количество ЦОД с резервированием на уровне ЦОД? У Амазона резервирование? Что там у них недавно грозой дёрнуло?
        • +1
          Трансформатор.

          И из-за пожара не получилось воспользоваться дизелем.
          • +10
            Так. И где «резервирование на уровне ЦОД»? Пшик?
            • 0
              Форс-мажор.

              Ну, правда, расскажи, что надо было делать Амазону?
              • +13
                Понятия не имею. Но причём тут резервирование на уровне ЦОД?
              • +3
                IaS это никак не облако. Это все же впски на стораджах и в нодах.
                Делать надо было не амазону, а тому кто делал решения в этом амазоне — поднимать на свои приложение в нескольких дц.

                IaS облака — это маркетинговый бред.

              • 0
                Бред, в нашем дц (T4), например 2 подстанции и 4е дизеля.
                Имхо утверждение schors верно, пшик это резервирование у облак.
      • +2
        1. пропускаем =)

        2. Не работает а Амазоне, а в России будет?

        3. В этом случае, ставят несколько серверов в разных цод-ах (города, страны, другое) и не думают о проблеме с доступностью сайтов.

        Более глобально проблема заключается в том, что если все делать «по уму», то это никто массово покупать не будет, это единичные проекты под конкретный бизнес.

        «Поставил контейнер на корабль и уплыл, все в норме....» =)
        • +1
          А если мы хотим получить гибкое соотношение «надежность / стоимость»? Хотим уметь добавлять серверы только тогда, когда нам это нужно? И уметь отказаться от них, когда в них больше нет необходимости?
          • +4
            «А если мы хотим получить гибкое соотношение «надежность / стоимость»?»

            — Здесь нужно правильно выбрать «cms» и «администратора».

            «Хотим уметь добавлять серверы только тогда, когда нам это нужно? И уметь отказаться от них, когда в них больше нет необходимости?»

            — Эта услуга называется «аренда сервера».
            Причем, здесь вы можете выбрать все. От типа, частоты процессора и памяти (кстати, у вас в облаке какой процессор? 3 или 4 канала памяти?), до типа, количества и размера ssd дисков, которые будут использоваться для кеша. Все для вашей конкретной задачи и типа ее выполнения.
            Если задача не требует много потоков — пусть будет меньше ядер и больше mhz, если требует — пусть будет больше ядер и mhz =)

            Да, и GPU Tesla в аренду тоже не проблема, хотите один или 4 =)

            • +1
              Вот, тот пример про январские каникулы в январе — он реальный. Мне очень-очень был нужен сервер в аренду. Некоторой определенной конфигурации.

              Никто не сумел мне его предоставить.

              Максимум, что получилось — вот, ровно те предустановленные конфигурации, которые есть. И примерно в течение 1-2 дней.

              Или — то, что мне надо. Но через пару дней после окончания каникул (то есть, в лучшем случае — через неделю).
              • 0
                Не помню, чтобы вы к нам обращались =)

                Здесь можно много рассуждать о том или другом случае, это все частности, которые можно «работать» по-разному.

                И интерпритировать облако можно по-разному, вкладывать в него разные определения, ожидать разных плюшек, каждый находит для себя именно то, что ищет.
              • 0
                А какие проблемы были обратиться не к российским хостерам, а в тот же Hetzner? Получили бы сервер в тот же день.
                • 0
                  Конкретно мы — да, могли. Но выбрали в итоге Амазон — и не жалеем.
    • +4
      Жжёшь напалмом, коллега :) Я уж думал, что у меня у одного иммунитет на это поветрие :)

      > Итог — «облако» может быть интересно только стартапу и сайтам визиткам, которые считают каждый рубль.

      Им интересны мы с тобой. Стартапу нужна эластичность, но он может в деньги влететь с ней, а падение он как раз переживёт. И вообще стартапу считающему копейки неплохо бы сразу думать о нагрузочном проектировании, а «облако» его только развратит. Если у разработчика голова не из задницы, прости Господи, то и у тебя, и у меня прекрасно живут порталы с дай боже функционалом и посещаемостью.

      «Облака» с самого начала вообще не совсем для веба предназначались, даже у того же Амазона. Задачи действительно «временнЫх» ресурсов. Вроде рендеринга изображений у дизайн-студий. Расчёты фракталов там и всё такое.
      • +1
        Рендеринг, фракталы и т.п. — есть конторы, которые этим и занимаются.

        Но это — немного о другом.
  • +3
    > Как бы ни лимитировали хостеры те или иные ресурсы, все равно обычный хостинг – это общежитие: кто первый встал – того и тапки

    А облачный хостинг тоже не имеет смысла без хоть какой-нибудь «эластичности». А она или вообще дискретная, или точно такая же «кто первый встал – того и тапки». И лимитирование – ну только если влоб конечно лимитировать, то всё плохо. Вроде ты должен был видеть эту гениальную вещь, хоть немного и устаревшую vimeo.com/7631344

    Детектед софистика в самой постановке вопроса — сравнение идеологии гарантированных ресурсов (VPS/VDS) с эластичными (shared, cloud).
    • 0
      Под тем словом, которое ты называешь «эластичным», я имею в виду несколько иное: если я захочу в облаке виртуалку с N RAM, и M CPU, я их и получу. На VPS (ну, у нас почти все на OpenVZ) — далеко не всегда.

      Оплата за потребление — второй важный момент.
      • 0
        Это прости с чего ты не получишь? Только потому что нет предложений? Ты думаешь на Амазоне что-то другое, а не тупой Xen с 9P FUSE? Это, как правильно сказал dtar — ограничение железки и только.
        • 0
          Это — из собственного опыта.

          Ну, да, Амазон — это Xen. И что? Scalaxy, Selectel — тоже Xen.

          И, вот, как показывает собственный мониторинг, здесь я получаю те ресурсы, за которые плачу.

          Я же не убеждаю, что на обычном VPS всегда все плохо. Нет. Но (опять же — по моему личному опыту!) зачастую — хуже.
          • +1
            И причём тут облака, казалось бы? :)
        • –4
          Ага. На амазоне не тупой Xen. На амазоне KVM =) На низком уровне.
          Xen у наших русских популярен, почему-то.
  • +3
    > Не «облако надежнее», а «облако» дает гораздо больше возможностей построить надежную инфраструктуру.

    Надо в цитаты записать. Ну хоть кто-то…
    • 0
      Ну, я надеюсь, что здравомыслящие люди это все-таки понимают…

      Вот отличная статья, написанная по результатам одного из самых масштабных падений Амазона (в апреле этого года): broadcast.oreilly.com/2011/04/the-aws-outage-the-clouds-shining-moment.html
  • 0
    облака, белогривые лошадки
  • +3
    И все таки SaaS не равно облаку… SaaS (и прочий ...aaS) это способ продаж и потребления. Т.е. мы потребляем ИТ как электричество или воду (по факту потребления) и нам ее предоставляют. Но как и с любой инфраструктурой надо уметь этим пользоваться. В случае с водопроводом придется сделать соответствующие сливы-стоки, чтобы можно было искупать слона или даже стадо слонов, в случае с ИТ обеспечить такую конфигурацию системы чтобы она диагностировала нехватку ресурсов и сама их подключала и отключала…

    Если моя система это делать не умеет и я не предусмотрел возможности масштабирования в архитектуре своего софта, то ничего не произойдет и я не получу никакой выгоды от ааS… А правильные с архитектурной точки зрения ИТ-системы можно было и раньше строить, когда ни про какие облака никто не говорил… Так что «облака» это всетаки выдумки маркетологов. Программист который делал многосерверные высоконагрузочные web-системы 10-15 лет назад всм скажет что от появления «облаков» проблем меньше не стало… Разве что набор функций изменился и всякие API сверху понавешали.
    • +1
      Не соглашусь.

      Продолжая Вашу аналогию: раньше для организации слива давали лопату. И жестко ограничивали территорию. Возможностей «слить» больше, чем водосток пропускает, не было почти никаких.

      Сейчас — все проще.

      Как раньше решались вопросы бэкапов большого объема данных? Как добавлялись ресурсы по мере роста проекта? При пиковых нагрузках? И т.д., и т.п.

      Понятно, что все эти задачи — решаемые. Но сейчас (в «облаке») решить их банально проще. И зачастую — дешевле (мы меряем не только «в лоб» деньги, но и время, и другие ресурсы).
      • +3
        Это мне напоминает разговоры про многопроцессорные системы. Когда появились многопроцессорные персоналки (а позже многоядерные процессоры) и оказалось что даже гарантированно паралелящиеся процессы нифига не быстрее (например 3D Studio — досовская версия 3ds max… кстати первые два версии 3ds тоже не умели параллелиться). Оказывается надо софт писать так чтобы он учитывал что могут быть несколько ядер и как-то что-то паралелил…

        С облаками то же фигня. 99.9% нынешнего web-софта не умеет жить в облаках. Точнее умеет, но ровно как старые дос-программы на современных i7… И спор «переходить на облака или нет» это как решать использовать высокоуровневые библиотеки для критичных многопроцессорных вычислений или нет. Библиотеки — это быстро, просто, без пыли… но никто не знает, что произойдет когда нагрузка станет реально большой и критичный процесс надо будет параллелить не на два, а на 200 ядер.
        • 0
          Да ну, бросьте…

          Куча современного веб-софта прекрасно масштабируется внешними средствами. Плюс рано или поздно станет больше инструментов «из коробки».
          • –2
            Я и говорю, что «разговоры про многопроцессорные системы»… времен эдак 98-года. И что намного стал быстрее Word на i7? Кроме расчетных приложений (типа FEA) это для дела кому-то нужно??? Ну да. Игрушки еще… О «новый дивный мир» :) :(
    • 0
      Согласен с предыдущим коментом про надежность. Надежность у «облаков» повыше. Но это тоже «трюки маркетологов». Надежность должна быть в любом дата-центре. Архитектурно ее можно обеспечить в любом дата-центре. Просто не все любят обеспечивать (проще в договор пункт о технических рисках вписать). В «облачном» же дата центре надежность встроена и вот тут раздолье маркетологов. Ура наш сахар гарантировано сладкий а вода мокрая… Впрочем это не мешает предусмотрительно сохранить пункт о технических рисках в договоре. :)
      • +1
        Если Вы прочитали текст, то, наверное, могли обратить внимание на то, что я как раз не говорю о том, что надежность «облаков» выше.

        Процитирую:

        Не «облако надежнее», а «облако» дает гораздо больше возможностей построить надежную инфраструктуру.
        • 0
          Надежную инфраструктуру построить можно и без облаков. Она должна быть надежна всегда, просто в облаке обходится дешевле (т.к. механизмы уже встроены и их надо только включить… я только не понимаю почему они не включены всегда)
          • +3
            Груз перевезти можно и на телеге. Просто на машине — обходится дешевле. :)
            • 0
              Именно потому для вывоза леса при точечной вырубке ценных пород деревьев до сих пор используют двойку лошадей…

              … а в производстве туалетной бумаги используют автоматические лесоукладчики… :(

              • 0
                Мы правда можем бесконечно продолжать аналогии.

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

                Вот, лично я считаю, что построить надежную инфраструктуру в облаке в общем случае проще и дешевле.
  • +4
    По поводу цен
    Не является альтернативой хостингу за 200-300 руб./мес.

    И чуть выше вы указывали сравнение стоимости VPS серверов с облачными ценами.

    Сейчас пользуюсь VPS в Лондоне, 10 Гиг винт, 256 Мб памяти, 100 Гб трафик в месяц — 25 фунтов в год, что приблизительно равно 100 р в месяц.

    Интересные предложения VPS сервисов публикуются здесь www.lowendbox.com (не сочтите за рекламу). Но будьте внимательны, далеко не все дешевые сервера надежны. Впрочем, горький опыт Clodo показывает, что и облачные сервера далеко не всегда надежны.
    • 0
      Если взять минимальную конфигурацию, то, может быть, и получится цена в 200-300 руб./мес.

      Но в этой конфигурации не будет никаких преимуществ.
      • +2
        Вот и я об этом.

        Но суть комментария в следующем: в топике вначале говорится, что облако выгоднее VPS (сравнивается конфигурация с 512Мб памяти). Затем, в минусах указывается, что облако не является альтернативой хостингу за 200-300 руб./мес.

        Следовательно, раз облако выгоднее VPS, то и VPS не может стоить такую сумму. По ссылке куча примеров дешевых VPS-ов и Ваше утверждение, что «Облако» в среднем в полтора-два раза дешевле" для меня очень сомнительно.
        • 0
          Первый же мой тезис, кстати, сводится к тому, что даже если «облако» и дешевле (если тупо сравнивать абонентскую плату), то дешевизна эта — не освновной критерий.

          Далее — я взял лишь некоторые компании. «Среднее по больнице».

          Конечно, можно найти дешевле. Но, во-первых, цель не в этом, а во-вторых, скорее всего, мы рискуем попасть на серьезный oversell.
          • +2
            Еще как рискуем, но и с облаком такие риски есть: в нужный момент у провайдера может просто не хватить ресурсов для масштабирования.

            А цель то как раз в этом — получить сервис приемлемого качества за минимальную цену. И выбор стоит между VPS, облаком и собственным сервером/серверами. И выбор далеко не так однозначен.
            • 0
              Вы сталкивались когда-нибудь с тем, что «облачный» провайдер не смог выделить столько ресурсов, сколько Вы запросили?

              Я — нет.
              • 0
                И я не сталкивался, но это еще не значит, что такого не было и не может быть )
                • +1
                  А я сталкивался с обратным — на RackSpace Cloud у нас появился «сосед», который все мощи себе зажрал, и в итоге мы иногда на диск писали со скоростью в десятки (!) iops. Создали тикет, позвонили, короче в течение 4-5 часов нас перемигрировали на другой физ. хост, даунтайм 20 мин.
                  • 0
                    Даунтайм этого инстанса, конечно. Был и запасной, который в это время получил 2х плюшек.
                  • 0
                    Да, ок. Согласен — такие перекосы, конечно, возможны.

                    Но именно RackSpace с их идеологией Fanatical Support готов переносить серверы и на самом деле решать проблемы.

                    А большинство традиционных хостеров на массовых тарифах — готовы?
                    • 0
                      Так он и денег дерет за это мама не горюй.
                      • 0
                        В разы больше?

                        Или на несколько процентов?
                        • 0
                          У RS Cloud саппорт совсем даже не fanatical. Linode те же самые или LiquidWeb гораздо быстрее отвечают и проблемы решают лучше.

                        • 0
                          Самоотправилось. :) Цена за Managed-решения у RackSpace выше в разы — около $1000 за средний сервер. В облаке порядка $150 за облачный хост. У Hetzner, например, есть managed dedicated за 100-150 евро. У StormOnDemand — fully-managed CentOS $20/мес. Ну да, они не будут так вылизывать, как RackSpace.
  • +3
    Основная задача практически любого цода — продать Вам/нам/им питание (иногда даже и бесперебойное) в прохладной комнате. А умные слова ..aaS, облака, вертикали, горизонтали — всего лишь способ ввести дополнительный множитель к цене, отличный от нуля и больше единицы. IMHO.
    • +2
      Так в любой отрасли. Можно купить/продать сырье (дешево) или некий результат (например, интеллектуальный) более дорого.

      Это правильно и нормально.
  • +1
    Имхо, русские облака совсем даже и не облака — или падучие (Клодо, Скалакси и пр.), или трафик между нодами считают как внешний (Селектел). Заморские облака или с огромным пингом (Ракспейс, ГГ), или серьезный трафик и мощности там стоят как нигерийские алмазы (Амазон). Так что и остается пока РФ-ориентированные вещи на Хецнере держать. VQ-впски они, кстати, дешевые у них и деплоятся тоже довольно шустро на случай каких-то непредвиденных вещей. Ну а EQ-10 вообще вне конкуренции по цене (24ГБ / i7-980X за 110 евро!).
    • 0
      Да, наши облака, конечно, несколько отстают (хотя и не во всем — у тех же Скалакси есть некоторые очень удобные фичи, которых, например, нет в том же Амазоне).

      Мы вообще всегда в роли догоняющих.

      Но — как бы пафосно это на первый взгляд ни звучало — я очень верю в наши облака. Верю в то, что они дорастут до качественно нового уровня. И будут уже не альтернативой, а первейшим вариантом при выборе хостинга. :)
      • 0
        По-моему, первейший аргумент — ценовая политика.
        • 0
          Один из важных. Но не первейший, думаю.

          Набор фич, SLA, суппорт, цены — это все примерно в одном ряду.
          • 0
            В том-то и дело, имхо, что сейчас у «облачников» цена идёт прежде всего за фичи типа динамического распределения ресурсов. Кому эти фичи нужны, тот за них заплатит, а тот, кому нужен просто хостинг либо заплатит столько же за большие ресурсы, SLA, суппорт или заплатит меньше за такие же. При одинаковой цене я всеми руками за хостинг, дающий больше фич. Но вот если фичи стоят дополнительных денег, но они мне сейчас не нужны, я трижды подумаю имеет ли смысл платить сейчас за то, что может быть когда-нибудь мне понадобится.
            • 0
              Кому нужен просто хостинг, тот может купить инстанс с фикс. ценой.

              Традиционный хостинг — часто ли дает вообще хоть какой-то SLA?
              • 0
                Если этот инстанс стоит столько же (или меньше) сколько (V)DS, то почему нет. Но вот стоит ли он столько?

                Дают.
                • 0
                  Например? Кто дает SLA?
                  • 0
                    • +1
                      Первые — это филькина грамота, а не SLA.

                      В тех редких случаях, когда качество работы сайта или предоставляемого сервиса будет отличаться от показателей, приведенных в пп.1, 2, 3 и 5 SLA, Вы имеете право потребовать от Компании ValueHost компенсацию простоя услуг. Решение о компенсации принимается на уровне начальника отдела Компании ValueHost.

                      То есть — никаких гарантий. Просто обещания под честное слово.
                      • 0
                        Любой договор является обещанием под честное слово, пока вам не передали материальный залог его исполнения.
                        • 0
                          Зависит от условий договора.

                          А тут… Даже условий никаких не нужно…
                          • –1
                            Пока у вас нет чего-то, чтобы сделать исполнение договора выгодным для контрагента (будь-то залог, ожидаемая прибыль, возможность устроить результативный антипиар или репрессивный аппарат государства), то договор это лишь честное слово. Вам обещают, но сделают это лишь в случае если не делать выйдет дороже.
                            • 0
                              Какой-то правовой нигилизм получается…

                              В моей личной практике, к счастью, чаще получается иначе.
                              • 0
                                Так называемое «право» это тоже лишь обещание государства защитить вас в конкретных случаях. Есть лишь два, имхо, реальных «прав» — право силы (можно не обращать внимания на тех, кто против твоих действий) и право хитрости (можно надеяться на то, что твои действия никто из сильных, которым не по нутру твои действия, не заметит).

                                Даже выполнение всех формальных законов, принятых в соответствии с формальными правилами, не гарантирует, что завтра к тебе не придут недовольные твоими действиями «при поддержке авиации НАТО» и не заставят тебя совершать неугодные тебе действия, а то и просто не лишать тебя свободы, а то и жизни.
  • –2
    А когда ждать habroblako или habrako? И какие будут плюшки? Это если хотя-бы 1/10 того, что тут( на хабре) описано внедрить — амазоны с рэкспейсами уйдут с рынка прямо в монастырь.
  • +8
    Минусы «облака»:
    Не является альтернативой хостингу за 200-300 руб./мес.


    Неправда ваша! Еще как является! В селектеле машинка с 10+ малопосещаемыми сайтами ~ 220 руб./мес.

    image

    Плюс ее бэкапы на Amazon S3 — меньше доллара в месяц.

    Эдакий симпатичный «шаред-хостинг для своих». При этом плюсы в сравнении с «классическим» shared'ом за те же деньги:
    1) Я могу в любой момент поставить любые требуемые расширения php, Perl
    2) Я могу туда засунуть еще 10, 20, 30 таких сайтов — стоимость возрастет, но не настолько, насколько возрастет на большинстве шаредов (почти везде есть ограничения на количество размещаемых доменов, особенно на таких дешевых тарифных планах)
    3) Аналогично нет ограничений на количество баз данных, в отличие от шаредов, особенно дешевых.
    4) Любые собственные конфигурации апача, nginx, и т.д.
    5) Если бы даже я не стерла доменное имя на картинке, машинка бы не прилегла от хабраэффекта :-) Просто на некоторое время обошлась бы чуть дороже.
    • +2
      согласен на все 100%. могу показать такую же картинку.
    • +1
      Отлично!

      Спасибо. На самом деле — очень хороший кейс.

      Я расширю немного свою мысль: такой «облачный» аналог за 220 рублей для нормального функционирования сайтов на нем требует хоть какого-то мало-мальски внятного администрирования. А это уже никак не shared (где в общем случае все администрирование осуществляет хостер).
      • +1
        Ну, для меня это дополнительный плюс :-) VPS по цене шареда, это же здОрово.
    • 0
      Судя по цифрам среднее потребление памяти у вас порядка 200 Мб. VDS с примерно таким объёмом памяти с примерно такими ценами на рынке есть. Причём их стоимость не возрастёт при добавлении 10-30 таких сайтов. Как и почти все остальные плюшки. Это просто плюшки выделенного сервера, а облачный он, виртуальный или реальная железка почти значения не имеет.

      Собственно самый важный пункт — пятый и уж тут главное, что важнее для владельца ресурса — обеспечить 100%-ю доступность ресурса при хабраэффекте или не попасть на деньги. А как вариант и попасть на деньги, и не выдержать хабраэффекта. Плюс для таких облаков навыки администрирования важнее чем для (V)DS — неверные настройки (например дефолтные для дистра) могут повлечь неоправданные расходы — 10 экземпляров ждущих апачей для хоста с посещаемостью 10 человек в сутки будут перебором.

      В общем, имхо, облака подходят хорошо для проектов с прямой монетизацией, где доходы прямо зависят от посещаемости, либо для благотворительных проектов, где готовы творить благо не взирая на цену (или хостер проявит сознательность и не отрубит социально важный ресурс, типа списков жертв очередной катастрофы, из-за исчерпания бюджета). Для проектов @just for fun@ лучше, имхо, фиксированная плата за фиксированные ресурсы.
      • +3
        Да, вы правы. Практически весь день потребление памяти — 192. Во время бэкапа — чуть больше, чем 280. Во время прохода поисковиков иногда — до 400. Не бэкапиться? Забить на то, что пока паучит Яндекс — никто не может на сайты попасть? Или взять VPS с 384-512 только из-за этого?
        У меня сейчас две машинки в селектеле, суммарно — чуть больше 750р. в месяц. Раньше содержимое этих машинок лежало вместе на зеноновском VPS (OpenVZ) с 768 памяти, и несколько раз в месяц VPS ложился при агрессивном проходе поисковиков. Про цену промолчу — там получалось почти вдвое дороже. Причем не получалось пользоваться плюшками PHP 5.3 для новых сайтов, т.к. для части сайтов (которые как раз сейчас на показанной дешевой машинке) требуется ZendOptimizer. Не его аналоги, а именно он сам.
        Ну а субъективно — даже после переезда в Клодо мне люди (посетители основного сайта) начали спасибо говорить. А в селектеле — даже по отзывам камчадалов и сибиряков «открывается, как со своего компа».
        • 0
          Ну за 750 р. в месяц можно взять VDS (честный KVM) с «гигом мозгов» уж точно. А то и дешевле раза в полтора. Со всеми плюшками рутового доступа. Не говоря о том, что своп нормальный есть.
          • +2
            Зачем? Просто вот из принципа, чтоб он был «нормальный»? Меня больше устраивают две машинки в облаке на разных ОСях. Вообще, спор беспредметный какой-то… Вам лучше нормальный VDS — вы берите себе нормальный. Мне больше нравится селектел. Перестанет нравиться — подберу что-то другое… Главное, без фанатизма ;-)
            • 0
              Если говорить о том, что нравится, то действительно бессмысленный. Я же говорил об экономической эффективности.
              • 0
                Если цена та же — почему обычный VDS эффективнее экономически, чем облачный? К тому же те VDS, о которых вы говорите — за границей, поэтому их эффективность априори ниже, ибо время доступа выше.
                • –1
                  Потому что на самом деле вдс с гигом мозгов стоит дешевле даже у реселлеров тех вдс, о которых я говорю :)

                  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 мс. Циферки приятные, но практической пользы мало, чтобы за них переплачивать.
                  • +1
                    А дело не в пинге, а именно во времени, за которое загружается страница с сервера. Полностью, со всеми скриптами и изображениями. Из-за границы это время чувствительно больше, проверено на сравнении Rackspace — Selectel.
                    К тому же Hetzner, к примеру, для меня отпадает раз и навсегда как минимум из-за того, что может попросить скан кредитки. А я принципиально плачу в тырнете только с виртуальных карт.
                    • 0
                      Конкретные цифры о времени загрузки сообщите?

                      А я принципиально не плачу с кредитки (банковской карты) вообще, там где можно обойтись вебманями, ядами, киви и т. п., или простым безналом, пускай даже придётся переплатить посредникам. Просто считаю, что мои траты как физического лица, не должны пересекаться с моими тратами как предпринимателя. Единственная трудность — не могу решить с какого счёта оплачивать доступ в тырнет, иметь два акка и переключаться между ними глупо имхо.
                      • 0
                        Нет, конкретные цифры не сообщу — мне незачем измерять, я свой сайт знаю как облупленный за 10 лет-то. И поэтому если он грузится откровенно медленно — для меня это заметно и без цифр.
                        • 0
                          Вот я прямо сейчас ругаюсь с девушкой. И аргументы в своей правоте у неё очень схожие с вашими: «Я не знаю сколько я гостила, но не долго, и фиг с ним, что обещала на 15 минут выйти, а пришла через 15 часов».
                          • 0
                            Так вы себя сравнивайте с той девушкой, а меня ;-)
                            Я попробовала оба варианта и сравнила. А вы как в анекдоте:
                            — Да ну этих битлов, фальшивят, шепелявят, слова перевирают…
                            — Это где ты такое услышал?
                            — Да мне Изя напел…
    • 0
      Спасибо за пример — попробую для своих проектов.
  • +3
    Как по мне так главное преимущество «облаков» возможность собрать «несбалансированную» конфигурацию типа метр мозгов и винт на два терабайта, которую у хостеров (V)DS не встретишь. Плюс да, возможность динамически (у некоторых даже автоматически) менять количество памяти, ЦПУ и винта. Речь идёт об «облаках» предоставляющих, по сути DS, а не типа GAE.
    • +1
      Да. Моментальная доступность любых ресурсов — именно об этом речь.
      • –1
        Но в случае с облаками типа GAE (во всех этих *aaS я плохо ориентируюсь, в общем с биллингом по фактически потребленным ресурсам) есть две опасности при «хаброэффекте» — либо попасть на сумасшедшие деньги, либо (при ограничении, например, суточного бюджета) столкнуться с тем, что сайт будет лежать мёртво. При традиционном хостинге хоть кто-то да пробьётся.
  • +4
    Облака придумали для жирных корпоративных клиентов, чтобы и дальше разводить их на деньги, используя новые красивые слова. Вы думаете, для чего майкрософт свое облако делает. Вы посмотрите, кто были первыми клиентами облачных систем и для кого их рекламируют.

    У вас неправильные цены на VPS — у firstvds.ru VPS с 512 Мб ситоит 399 р или $13/мес. К нему прилагается 500 Гб трафика. Есть дешевые хетцнеровские ВПС. А у вас всюду дорогущие цены. Зачем по $40 платить за то же самое.

    А, еще очень важно используемое для виртуализации ПО — 512 Мб на OpenVZ (который оверселлят только в путь) и честные 512 Мб на Xen — абсолютно разные вещи.

    Плюс, в облаках дорогой трафик: те же 500 Гб в селектеле вам выйдут в 500 рублей (при том что в упомянутом 399-рублевом VPS вам этот трафик дадут бесплатно).

    Единственный случай, когда облако выгоднее — крошечный сервер типа 128-256 Мб памяти, который потребляет мало трафика и стоит меньше 100 р в месяц. Во всех остальных случаях выгоднее купить  «безлимитный» VPS и юзать по полной программе, тем более что некоторые недалекие хостеры могут долго не замечать перерасход ресурсов, а вот в облаке у вас 100% все посчитают.

    Так что у меня складывается впечатление, что это какой-то подвох. ЛЮДИ! Не давайте себя зазомбировать! Не верьте автору!
    • 0
      Вы знаете, мне как-то хочется ответить на это одно: а, может, не надо идти к недалекому хостеру? Вдруг он через некоторое время станет недалеким не в пользу клиента? Или вообще прогорит и уйдет с рынка из-за своей недалекости?
      • –3
        Прогорит — уйдём к другому :) Но, если серьёзно, то, по-моему, действительно ценовая политика облачных хостеров более жадная (если считать, что затраты примерно равны), чем у традиционных.Да, есть за что платить, если плюсы облака нужны, но если нет, то аналогичный традиционный хостинг скорее обойдётся дешевле, даже если брать его с запасом.
        • 0
          Не жадная, а расчетливая. Сколько потребили — за столько и платите.

          Возьмите виртуальный сервер и держите его в качестве резерва без нагрузки — получатся копейки.
          • 0
            Просто почему-то получается, что за 1 Гб оперативки у традиционного хостера я плачу меньше, чем за тот же объём у «облачников». У кого из них 1 Гб стоит порядка 500 р в месяц, не считая цпу, винта и трафика?

            Вопросы резервирования, балансировки и прочей отказоустойчивой инфраструктуры (кроме бэкапов по ssh) не рассматриваю.
            • +3
              А бесполезно мерить стоимость 1Гб оперативки без учета тех вопросов, которые Вы не рассматриваете.

              Если так, то дешевле всего — купить плашку памяти (тот самый 1Гб) и положить себе на стол. Ну, или воткнуть в сервер под столом. Дешевле всего будет, правда. :)
              • 0
                Имхо, сейчас ЦА облачных хостингов — те, кто готов платить за фичи, предоставляемые именно облаком. Кому нужен простой (виртуальный) дедик не готовы переплачивать за эти фичи, а приходится.
                • 0
                  Что значит «приходится»? На аркане что ли в облако затащили? Под дулом пистолета платить заставляют? Покупайте простой (виртуальный) дедик и не переплачивайте.
                  • 0
                    Значит, что если брать облачный хостинг, но не использовать его фичи, то за них придётся всё равно переплачивать. Вполне разумно, если считать что поддержка облачной инфраструктуры стоит дороже, чем традиционной. Но если нет разницы, зачем платить больше?
  • +6
    Еще вопрос будет ли рад владелец шахматного сайта если из-за скачка трафика попадет на бабки от провайдера облака. А в случае с впс-ом он точно знает, что его расходы точно фиксированы.
    • +2
      В случае с VPS он — скорее всего — получит тормозящий / неработающий сайт. И в том случае, если владелец так или иначе зарабатывает на сайте — потеряет деньги. Гораздо бОльшие, чем оплата трафика.

      Плюс — потеря репутации. А ее уже за деньги не купишь.
      • –1
        Ну тут не все так очевидно. Ресурс ресурсу рознь и CTR и ROI везде разные. Вполне может выйти так, что уйдете в сильный минус, и тогда придется продать жилье и жена от вас после этого точно уйдет.

        P.S. Облака идеальное решение для:
        1. Ресурсов на подобие: «Сервиса по создание корпоративных сайтов.»
        2. Различных магазинов (доходность обычно не самая плохая).
        3. Держать на случай атомной войны больших нагрузок или выхода из строя одного из боевых серверов.
      • +3
        Одно дело получить не работающий сайт на один день, что случается у многих. Другое дело попасть на какой ботнет и получить счет на 3 нуля.

        Все-таки есть сайты чисто информационные и не являющиеся для компании основным видом деятельности.
        • 0
          А есть сайты с оборотом 1.5 млрд. руб. в год.

          Мы же отделяем мух от котлет, правда?
          • 0
            Вот мы и выделили нишу клиентов облаков?
          • +1
            Так а что за суммы 40 у.е. в месяц? :)
        • +4
          Что вы все счетами пугаете? С вас не снимут больше, чем было на счету (тут вам не Мегафон ;)). Счет в 0 (или другой порог), сервер выключится. Захотите включить, закинете еще денежку.
          • +1
            Честно говоря, я тоже не считаю это основной проблемой при граммотном подходе. Но вот серьезно не вижу экономии.
            Для вполне среднего ресурса, к которому себя отношу, имею практически анлим интернет (после 2 Тб скорость падает до 10 Мбит) в месяц, 40 Гб HDD, RAM 1 Gb + Swap 2 Gb, одно ядро) плачу 13 евро! Куда уж меньше, при том что я постоянно запускаю бэкенд операции на 168 часов в месяц?
            Изучал Amazon, Google Apps — кажется вроде привлекательно, но чуть надо задействовать машину на все ресурсы: интернет-трафик большой или процессор загружаешь, счета вылезают гораздо большие.

            По поводу расширения ресурсов, это конечно правда, по поводу миграции. По мне так лучше потратить программисто-часы и автомотизировать всю миграцию и экономить в деньгах, хотя зависит от бюджета :)
            • +2
              А я по секрету добавлю. Если у вас нет своего набора bash скриптов который все развернет на новой машине, то их не проблема найти или написать. В конце-концов есть специализированные инструменты для этого (chef).
          • 0
            Закинул, скажем, 1000 баксов в расчёте на год, а они внезапно сожрались за день. С обычным хостингом это исключено.
            • +1
              С облаками так же (в селектеле, по-крайней мере). Сколько положил с основного счета на облако — столько и израсходуется.
              • 0
                Но не за то время, которое планировалось, если вы не пророк, умеющий учитывать и общее количество визитов, и их относительный «вес». Я не прав?
                • 0
                  Вы можете ограничить производительность компонент в виртуальной машине. Как я уже сказал, единственный ресурс, который вы не можете контролировать — это входящий трафик.
      • +1
        А если это будет паразитный трафик? Небольшой ддос, левые пауки и тд? Тогда это будет вообще работа в чистый минус.
  • 0
    Вставлю всё-таки и свои 5 копеек. Я человек далекий от хостингобизнеса, обычный разработчик, «ваяю сайтеги за лавэ».

    Может быть, я остался по в каком-то крайне далеком прошлом и мыслю совершенно не теми категориями… Но те задачи с которыми я сталкиваюсь, четко разделяются на 3 категории:
    1) нужна какая-то площадка, на которой будет работать сайт с небольшой посещаемостью (магазин, презентационный, информационный сайтик и т д). Тут владельцы сайтов как предпочитали 5 лет назад managed shared у проверенных хостеров, так и предпочитают до сих пор). В крайнем случае (нестандартные требования) — небольшой managed vps. Главное — небольшие расходы и реактивный саппорт.
    2) нужна площадка, на котором будет крутиться некий ресурсоемкий инструмент (к примеру, сферический хрумер в вакууме, паук и т д). Здесь обычно нужна специфическая конфигурация; при этом ресурсоемкость процесса (требования к памяти, объему, траффику и т д) довольно предсказуема. Здесь обычно выбирается xen vps.
    3) Серьезный проект. Тут вариантов ровно два. Либо выделенный сервер (хоть atom, но свой), либо (можно договориться в идеале) xen с отдельным диском (лаги связанные с IO на виртуалках — это целый плач ярославны).

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

    Вот я тут выше написал много букв; это все преамбула.

    А теперь собственнно вопрос, на который я тщетно пытаюсь найти ответ. Где в этой классификации место облаку?

    PS: Разговоры о сравнении цен vds/облака/сервера — это вообще абзац. Если проект представляет собой что-то больше блога, то он сделан живыми людьми, которые за это взяли живые деньги. А месяц работы средненького пхп-кодера стоит как годовая аренда простенького дедика. Выбирать нужно по удобству, а не цене.
    • 0
      В этой классификации места облаку, может, и нет.

      Но на любом проекте, для которого простой критичен (простите, но такой проект не живет на одном сервере) — облако пригодится.
      • 0
        да, я слукавил, признаю. проекты, которые не живут на одном сервере, я умышленно оставил в стороне.

        в качестве резервных on-demand мощностей идея облака мне самому в общем-то нравится.

        но повсеместные попытки выдать это за silver bullet заставляют недоуменно пожимать плечами, вот в чем беда
        • 0
          Ткните, пожалуйста, в более-менее развёрнутую статью про облака, где говорится, что это silver bullet. Я таких не видел.
  • +10
    Я как представитель Селектела строго негодую от абстрактного «19» в табличке. 19 чего? Попугаев?

    Существует две мотивации для облаков: инфраструктурная (грубо говоря, концепция управления собственными ресурсами) и маркетинговая (то бишь связанная с куплей-продажей).

    Маркетинговая мотивация: не оплачивать неиспользуемое. Я внимательно смотрю за потреблением ресурсов клиентами, и я могу сказать, что даже самые нагруженные проекты (больше десяти виртуалок с запросами каждой на почти весь хост) не потребляют всех ресурсов. Если не рассматривать синтетику вроде cpuburn и специфичных применений (пережатие видео с очередью заданий, превышающей производительность серверов) во всех остальных случаях виртуальные машины сильно простаивают.

    Собственно, вот пример: визуально машина загружена примерно на 750% по CPU (с учётом IO это максимум, который мы предоставляем): реальное потребление за вчера: 124.367 часов, то есть 518%. Где оставшиеся 231%? Моменты простоя, когда ресурсы не используются в полном объёме. Не важно по какой причине — загрузка заданий, перезапуск приложения, утренний спад и т.д…

    То же самое касается и остальных ресурсов. Это и именно это является мотивирующей частью облаков.

    С обратной стороны (провайдера) это выглядит так: у нас есть ресурсы, которые клиенты заказывают, но не используют (в случае обычного VDS). Мы можем либо их оверселлить (то есть продать ещё раз в надежде, что эти ресурсы исходным заказчиком полностью не будут выбраны), либо нет. Если мы ресурсы оверселлим, мы получаем дополнительную прибыль с шансом, что кто-то из клиентов наткнётся на нехватку ресурсов (когда попытается воспользоваться тем, что он вроде бы оплатил). Если мы не оверселлим, у нас простаивают сервера. Дилемма?

    Вот тут и приходит идея с оплатой по потреблению. Мы не ставим лимитов «предоплаченных ресурсов», каждый клиент получает столько, сколько а) ему нужно, б) мы можем дать. В результате мы утилизуем (продаём) наши ресурсы настолько, насколько можем, а клиент получает то, что ему нужно. (В отличие от оверселла, где у поставщика нет стимула обеспечивать ВСЕ обещанные ресурсы, для нас каждая секунда недодачи ресурсов — это потеря средств, так что стимул обеспечивать максимум доступных ресурсов есть, и он куда более действенный, чем «держать качество» — это _деньги_. Не посуетился с балансировкой и миграцией — недополучил денег.

    Так вот, сравнение с классическим VDS приводит к простой вещи: у VDS внутри заложен либо простой серверов (задранная цена), либо оверселл (неиллюзорный шанс наткнуться на нехватку ресурсов). И лобовое сравнение цен совершенно неверно.
    • +3
      Лучший комментарий. Спасибо, коллега.
    • 0
      Спасибо за комментарий!
    • 0
      Так вот, сравнение с классическим VDS приводит к простой вещи: у VDS внутри заложен либо простой серверов (задранная цена), либо оверселл (неиллюзорный шанс наткнуться на нехватку ресурсов). И лобовое сравнение цен совершенно неверно.

      Согласен, что лобовое сравнение неприемлемо, но пока я предпочитаю оплачивать простой сервера в обычной ситуации и то, что не каждый посетитель моего ресурса в случае хабраэффекта получит ответ, чем оплачивать реально потребленные, но в случае хабраэффекта либо попасть на деньги (ресурсы не коммерческие), либо отказывать всем посетителям при ограничении суточного бюджета.
      • +1
        … в случае хабраэффекта либо попасть на деньги...

        Мне кажется вы преувеличиваете количество денег на которые можно попасть в случае хабраэффекта )

        У меня например есть облако в селектеле, плачу до 200р. вы в этом топике писали в пример о впс за 700р. с гигом памяти…

        впс еще не факт что выдержит хабраэффект, облако выдержит и не думаю что он на облаке обойдется дороже чем 500р. ;) а если хабраэффекта не будет, то сэкономлю 500р… а если посчитать за несколько месяцев?
        • 0
          Ну я цифру не называл, на самом деле 550 р/мес одно ядро на, кажется, 2,3ГГц и гиг памяти (KVM вроде исключает оверселлинг). Но я точно знаю один ресурс, который переехал (судя по whois) с селектела на мажордомо во время недельной ддос атаки (вроде 1000 http запросов в секунду) из-за финансовых причин.

          Не факт, что выдержит, но отрубится (если отрубится) по физическим причинам, а не финансовым, а если не отрубится, то хоть медленно, но будет отвечать на запросы, пускай и не на все. Страничку «владелец ресурса решил, что ему не стоит тратить деньги на вас» посетитель не увидит, а увидит в худшем случае сообщение браузера о таймауте или невозможности установить соединение.
          • +4
            Единственный ресурс облака, который вы не можете контролировать — это входящий трафик. И это самый дешёвый ресурс (я не видел ни кого, кто бы на это жаловался).

            Все остальные ресурсы вы, как системный администратор своего сервера, можете контролировать.

            Вы можете запретить апачу принимать слишком много соединений. Вы можете запретить вашему sql'ю выполнять запросы дольше N времени и т.д. Вы можете запретить или ограничить исходящий трафик с вашей машины.

            Всё в ваших руках.
          • +1
            То вы сначала о хабраэффекте, то уже о ддосе…

            А хабраэффект если будет, то скушает наверное суму явно меньшую за ту которою экономлю в месяц, не говоря уже о нескольких… напр

            А ддос, хм интересно многих ли ддосят? И часто?)) Люди где то услышали про ддос и думают что и их будут обязательно ддосить))
            • 0
              Например, сайт браузерной игры может быть задидосен обиженным игроком.
              • +1
                К чему этот пример?))) «Могут» и «ддосят» как бы совсем разные вещи)
                То есть все должны жить в страхе что их якобы заддосят и держать для этого свой дедик, при этом переплачивая за него значительную сумму?)))) бред…
                • 0
                  Это реальная ситуация, с которой я столкнулся на прошлой неделе.

                  А переплата будет, имхо, в случае облака.
                  • +1
                    Сначала пишите:
                    Но я точно знаю один ресурс, который переехал (судя по whois) с селектела на мажордомо во время недельной ддос атаки (вроде 1000 http запросов в секунду) из-за финансовых причин.

                    потом
                    Это реальная ситуация, с которой я столкнулся на прошлой неделе.

                    вы уж как то определитесь и цифры поконкретнее назовите)) вам здесь дали несколько реальных примеров как в облаке выходит дешевле, а у вас пока только свое «имхо» сами то и не пробовали)
                    • 0
                      Поточнее сказать не могу, наблюдал как свидетель и не со стороны сервера. Внешние симптомы так сказать.
      • +3
        Имея неограниченные ресурсы ограничить себя проще, чем имея ограниченные ресурсы получить анлим.

        По пунктам:

        лишние ядра выключаются: echo 0 >/sys/devices/system/cpu/cpu3/online
        Память/число процессов ограничивается ulimit'ом
        Сеть ограничивается iptables. Фактически ограничить получится только исходящий трафик, но входящий очень дешёвый, так что особых проблем не составит.
        Диск по производительности ограничивается хреново, по месту — квотами.
        • 0
          Имея физически ограниченные ресурсы, можно получить ситуацию, когда хоть кому-то ресурс но отвечает.

          Можно ли из вашей админки настроить политику «отвечать на 100 http запросов в секунду, остальным отдавать 5xx или вообще TCP/IP соединения не устанавливать»? Насколько я знаю — нет, а простых способов настроить такую политику из консоли я тоже не знаю. Я не администратор, а разработчик веб-приложений, а то и просто веб-мастер. Я могу настроить количество экземпляров nginx и рhp исходя из известных мне доступных ресурсов и потребления памяти каждым экземпляром, но не могу ограничить количество запросов в секунду, так чтобы не превысить бюджет. Или у вас всё же есть опция в админке ограничения бюджета в секунду, а не в сутки или час?
          • 0
            У нас нет «админки». Всё в ваших руках — как хотите виртуальный сервер, так и настраиваете.

            Если вы только веб-разработчик и знать ничего не знаете про шелл, права, менеджер пакетов и т.д., то вам к PaaS — там за вас эти вопросы разруливают как могут. Цена удовольствия — вендор лок, причём, чем удобнее и функциональнее, тем сильнее этот лок.
            • 0
              То есть я не могу ограничить потребляемый аккаунтом бюджет принудительно вообще? Не конфиги править с оглядкой на ваши тарифы, а тупо сказать вам «если работа машины стоит больше 86,4 р. в сутки или 1 коп. в секунду, то отрубайте нафиг до конца суток или секунды (а в идеале измерения и по суткам, и по секундам, с прогнозированием затрат, с возможностью выбора приоритетов и отсекания части запросов)».

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

              PaaS в виде GAE (sorry, если GAE не PaaS, я в ваших *aaS соабо разбираюсь) меня тоже не устроил в виду невозможности гибко регулировать свои расходы.
              • +2
                Можете. Я же писал выше. Вы идёте и настраиваете квоты, аккаунтинг и т.д. по своему усмотрению. Но да, если вы «во всём этом не разбираетесь», то вы не наш клиент, потому что мы предоставляет инфраструктуру и только.
                • 0
                  Я настраиваю свою ОС у вас или свой аккаунт у вас? Оперирую техническими характеристиками типа мегабайтов и процентов использования ЦПУ или финансовыми типа рублей? Когда я беру дедик (пускай и виртуальный), я оперирую физическими характеристиками, у вас так получится?
                  • 0
                    Вы настраиваете у нас свою ось. Пока что мы предоставляем вам в начале некую минимальную конфигурацию, в дальнейшем я надеюсь дать возможность вообще ставить «что попало» — и всю настройку осуществляет пользователь виртуальной машины.

                    В биллинге мы учитываем, сколько ресурсов потребила ваша машина — и только. Дальше это ваша и только ваша свобода решать сколько ресурсов будет просить ваша машина.
          • +1
            >>Я не администратор
            Ключевое заявление. Простите, но инфраструктуру надо администрировать.
            • 0
              Я покупаю не инфраструктуру, а ресурсы для своего приложения. А в худшем случае не для своего, а для стороннего типа вордпресса или друпала, в котором я не смогу малой кровью организовать хоть какой-то контроль за нагрузкой через, например, shared memory или прочие мьютексы. В Сети есть хаутушки по оптимальной настройки в условиях ограниченных вычислительных ресурсов, но нет хаутушек по настройке в условиях неограниченных ресурсов при ограниченном бюджете.

              Отпугивает меня от облаков прежде всего неограниченность расходов при желаемом уровне доступности. Я не хочу, чтобы мой ресурс лежал сутки после первой тысячи запросов в первую минуту суток, а хочу чтобы из каждой тысячи обслуживался один запрос при общем количестве в миллион. Также я не хочу, чтобы за первую минуту его анонсирования на хабре, он выжрал готодовой бюджет. Традиционный хостинг мне худо-бедно позволяет на системном уровне регулировать эти вопросы выбранным тарифом, пускай 999 запросов выдадут 5хх Out of memory, но тысячный ответ отдаст 200 ОК.
              • +1
                Секунду. Мы предоставляем IaaS. То есть «продаём» (точнее, сдаём в аренду) ресурсы инфраструктуры. Таким образом, действительно, ваши ожидания от «товара» не соответствуют его описанию (аналогично можно требовать в автосервисе услуг по вождению автомобиля — это просто другие услуги).

                Я ж выше написал, что есть PaaS, где вам предоставляют платформу.

                И главное — вы можете настроить свои сервера так, чтобы они работали с фиксированной производительностью. Пожалуй, я себе внесу в заметку и напишу отдельную статью по этой теме.
                • 0
                  Фиксированная производительность это фиксированный бюджет? Был бы рад видеть, а то от облаков меня отпугивает прежде всего возможность попасть на бюджет.
    • 0
      И при этом получается, что хетзнеровские VDS выходят дешевле, чему выше были примеры. Что-то не сходится, вам не кажется?
      • 0
        Так очевидно, по-моему, что за гибкость и возможность платить «по факту» нужно переплачивать. Пока, по крайней мере.
      • 0
        Вы это меряли или по циферкам из статьи смотрите? У нас есть множество клиентов, у которых машины хостят мелкие сайты в пределах «до 100р».

        Кстати, сравнение Хетзнеров и нас я не могу делать, потому что десктопное железо — несколько не гут. Извините за предвзятость.
        • 0
          Я мерял. Правда несколько абстрактно, анализируя логи и прочие *top'ы на хетцнеровском дедике и прикидывая их к вашим ценникам. Да, брать вдс для сайта с посещаемостью 1 заход в сутки, и то владельцем, смысла не имеет, лучше у вас. Когда доход от сайта напрямую зависит от посещаемости, тоже лучше у вас (если есть прибыль у владельца сайта). Но вот в ситуации когда платят только 5 посетителей, независимо от того было их 5 или 100 000, выгоднее, имхо, ограниченные ресурсы за ограниченную плату, даже с условием возврата части платежей за временную недоступность ресурса в случае хабраэффекта или ддоса.
          • 0
            А вы не меряйте абстрактно, а попробуйте залить один и тот же сайт в селектел и на хетцнер. И переместите ДНС на сутки-двое в селектел. И сразу увидите и примерную стоимость, и почувствуете разницу в скорости доступа.
            • 0
              В том и дело, что разница будет примерной и отражающей среднюю нагрузку, а не пиковую.
              • +1
                Проведите нагрузочный тест. JMeter, tsung и т.п. — масса инструментов для этого.
                • –4
                  Я знаю про существование даже ab и curl. В том-то и дело, что при тысяче запросов в секунду они за эту секунду выжирают суточный бюджет ресурса, а потом он становится недоступным для всех.
                  • +3
                    Я мерял. Правда несколько абстрактно, анализируя логи и прочие *top'ы на хетцнеровском дедике и прикидывая их к вашим ценникам


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


                    Вы явно здесь спорите о том чего не знаете, вот специально решил проверить на тисячу запросов

                    image

                    баланс до
                    image

                    баланс после (тест кстати запускался не один раз)

                    image

                    Debian Squeeze (32) apache+nginx
                    Память выставлена от 256.00 Mb до 1536.00 Mb во время теста больше 512мб не поднималась)

                    … при тысяче запросов в секунду они за эту секунду выжирают суточный бюджет ресурса...

                    как видите даже рубля не накапало)))
                    • –3
                      А если у меня суточный бюджет 15 копеек? :) Да и судя по 15 мс, у вас не происходит 30-40 SQL запросов на главной, как любит делать, например, Drupal.
                      • +2
                        А если у меня суточный бюджет 15 копеек? :)

                        ага, а месячный бюджет на хостинг 4,5 рубля?

                        Да и судя по 15 мс, у вас не происходит 30-40 SQL запросов на главной, как любит делать, например, Drupal.

                        это уже проблема не облака, здесь все зависит от прямоты ваших рук)))
                        • –3
                          Хотелось бы вообще войти в бесплатные лимиты. поскольку проект не коммерческий и даже 5 рублей раз в месяц ходить ложить на киви обломно, а говорят, что ещё и небезопасно и поступления денег на счёт хостера можно и не дождаться.
                          • +1
                            Сначала пишите о том что у вас дедик
                            Я мерял. Правда несколько абстрактно, анализируя логи и прочие *top'ы на хетцнеровском дедике и прикидывая их к вашим ценникам

                            а потом про бесплатные лимиты и не коммерческий проект?)
                            Хотелось бы вообще войти в бесплатные лимиты. поскольку проект не коммерческий и даже 5 рублей раз в месяц ходить ложить на киви обломно

                            не думаю что за дедик вы платите 5 рублей) вам здесь привели реальные примеры и реальные цифры, а ваши «аргументы» как то не очень впечатляют)
                            • 0
                              За дедик плачу для своих нужд (в основном коммерческих и закрытых), не хотелось бы смешивать и много платить за некоммерческий публичный проект.

                              Не впечатляют и ладно, переубедить никого не рассчитывал. Просто информация для размышления, что плата по потреблению ресурсов может оказаться в конкретном случае минусом, а не плюсом. Риском резко увеличить расходы (а где-то и в долги влезть) при неожиданном росте нагрузки, а не уменьшить их. Нет настройки «тратить каждую секунду максимум 1 копейку», чтобы положить 5000 и не переживать, что в конце месяца должен останешься или большую часть месяца сервер будет отключен.
                              • 0
                                Не впечатляют и ладно, переубедить никого не рассчитывал

                                Прям уже так и не рассчитывали? столько комментов к этому топику оставили)))

                                Просто информация для размышления, что плата по потреблению ресурсов может оказаться в конкретном случае минусом, а не плюсом

                                Только эти ваши конкретные случаи встречаются крайне редко)
                                «волков бояться — в лес не ходить»?

                                Риском резко увеличить расходы (а где-то и в долги влезть) при неожиданном росте нагрузки, а не уменьшить их

                                В этом топике уже не раз вам писали о том что в минус нельзя уйти

                                Нет настройки «тратить каждую секунду максимум 1 копейку»


                                Это вообще брэд, может еще ресурсы регулировать от погоды, или от ваших мыслей?)) Как бы сначала ресурсы, а деньги потом) у вас есть просто ограничить максимум этих выделяемых ресурсов…

                                положить 5000 и не переживать, что в конце месяца должен останешься или большую часть месяца сервер будет отключен

                                У вас просто облакофобия и вы думаете что при хабраэффекте с вас снимут бешеные деньги)) выше вы писали что

                                … при тысяче запросов в секунду они за эту секунду выжирают суточный бюджет ресурса...

                                я вам показал на примере что на самом деле там копейки, вот например еще один пример что деньги на хабраэффекты траться не большие — habrahabr.ru/blogs/cloud_computing/118235/ (там еще старые цены, сейчас цена на трафик меньше) хотя еще раз говорю что все зависит и от прямоты ваших рук…

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.