10 миллиардов долларов в расходах на облака являются потерями
Аналитики RightScale задались вопросом, сколько доходов облачных провайдеров приходится на арендаторов, которые не понимают, как они могли бы предотвратить напрасные потери в совокупных затратах на облачные вычисления. Ранее в отчете «RightScale 2017 State of the Cloud Report» было отмечено, что пользователи облачных вычислений считают, что излишние затраты достигают 30 процентов от расходов на облако. На самом деле, вероятно, что эта цифра даже выше.
Фактически, было рассмотрено 60 предварительных оценок оптимизации стоимости облачных вычислений, которые были выполнены для клиентов RightScale, до того, как была начата деятельность по оптимизации. Было обнаружено, что средний объем потерь в затратах на облако составляет 35 процентов. Это соответствует потерям до 10 миллиардов долларов в затратах на AWS, Azure и Google ежегодно. Вероятно, что число будет расти в следующем году, так как темп внедрения облачных технологий ускоряется. В таких условиях IT-специалистам необходимо идентифицировать излишние затраты и принять необходимые меры в целях экономии и оптимизации затрат.
Оптимизация облачных затрат обеспечивает мгновенную экономию
Прежде всего, нам нужно признать, что излишние затраты в IT не являются новой проблемой. На протяжении десятилетий мы покупаем инфраструктуру для дата-центров за несколько месяцев или даже лет до того, когда она действительно потребуется в таком масштабе. И с внедрением виртуализации компании продолжают разворачивать виртуальные машины, как правило, с большим количеством ресурсов, чем это действительно необходимо, и часто оставляют их включенными, даже когда они не используются в течение длительного времени.
Однако, стимул для повышения эффективности виртуализированных сред несколько выше, поскольку преимущество оптимизации кажется менее ощутимым, когда оборудование уже куплено и полностью оплачено.
Разница в случае с публичным облаком заключается в том, что оптимизация ресурсов начинает приносить деньги сразу. В тот момент, когда вы отключите ресурс или уменьшите количество потребляемых ресурсов, вы больше не будете платить за лишнее и в конце месяца счёт за облако будет ниже. Итак, теперь есть мотивация экономить деньги и есть возможность получить практически мгновенное удовлетворение, когда вы это сделаете.
3 фактора, «раздувающие» облачные затраты
Существует три фактора, которые в ряде случаев приводят к образованию потерь в составе облачных затрат:
- сложность ценообразования и биллинга облачных вычислений,
- постоянное изменение цен и продуктового портфеля облачных провайдеров и
- децентрализация при использовании облака.
1. Сложность облачного ценообразования и счетов на оплату
Первая причина, по которой в публичном облаке могут иметь место потери такого масштаба, объясняется невероятной сложностью ценообразования и выставления счетов в облаках. Вам нужно «получить учёную степень» в облачном ценообразовании, чтобы понимать все особенности и отслеживать на что потрачены деньги. Чтобы проиллюстрировать объем проблемы, приведем несколько примеров:
- Счета за облачные услуги зачастую могут иметь миллионы отдельных позиций. Даже не ждите, что при открытии в вашем любимом табличном редакторе счёт всегда будет разумного размера.
- Облачные провайдеры предлагают сотни тысяч ценовых точек. Один AWS имеет более 70 000 ценовых точек только для инстансов.
- Облачные арендаторы не имеют наглядного представления какой из вариантов самый доступный по цене. При предоставлении ресурсов в облаке пользователи часто не знают, какие регионы или типы инстансов, отвечающие их потребностям, будут предлагаются по наименьшей цене.
- Есть множество вариантов скидок. AWS предлагает зарезервированные инстансы, причем более 90 процентов ценовый предложений будут иметь разные варианты скидок. Azure также добавил возможность покупки зарезервированных экземпляров виртуальных машин и ценообразование работает иначе, чем на AWS. Google имеет свой собственный автоматизированный подход к предоставлению скидок двух типов: Sustained Use Discounts (возрастающая скидка за постоянное использование инстанса более 25% времени в месяц) и Committed Use Discounts (скидка на инстанс, зарезервированный на 1 или 3 года).
2. Постоянные изменения услуг облачными провайдерами
Помимо описанной выше сложности ценообразования, в ваших расходах на облачные услуги постоянно происходят изменения. Изменения могут происходить не только в объеме и структуре использованных вами ресурсов, но и со стороны облачных провайдеров, которые меняют цены, развивают модели скидок и добавляют новые услуги с совершенно новыми ценами. Также важно отметить, что провайдеры иногда изменяют то, как позиции расходов представлены в счете на оплату, нарушая автоматизированные процессы, которые клиенты могли внедрить для распределения расходов и анализа счета.
3. Децентрализованное использование облака
Третья причина потерь возникает из-за восходящего внедрения облака. Облако позволяет компаниям быть более гибкими. Отдельные команды разработчиков или бизнес-подразделения могут получить мгновенный доступ к необходимой им инфраструктуре посредством нажатия кнопки или вызова простого API. Больше не требуется проходить через длительные процедуры утверждения или выделения, которые требовались в традиционных центрах обработки данных.
Тем не менее, специалисты, которые занимаются предоставлением ресурсов, часто не имеют достаточных оснований для эффективного использования облачных ресурсов. Цены на отдельные виртуальные машины или ресурсы кажутся небольшими, но только до тех пор, пока объем использования облака не вырос, а затраты на облако не стали значительными. При достижении определённых значений, у бизнеса и сотрудников происходит осознание, как потери накапливаются. Даже когда они осознают проблему, отсутствие опыта в облачном ценообразовании и отсутствие наглядности в структуре облачных затрат затрудняют решение проблемы.
Большинство предприятий имеют централизованные облачные команды, которые работают над уменьшением стоимости облачных вычислений, делая использование облачных технологий более эффективным. Но для того, чтобы изменения вступили в силу, такие специалисты должны тесно сотрудничать с бизнес-пользователями, чтобы определить, какие конкретные действия предпринять.
Где скрываются самые большие потери в затратах на облако?
Три самые широкие области для поиска источников экономии на облачных вычислениях — это инстансы, скидки и хранение данных.
Инстансы
Самая большая доля в облачных расходах и, следовательно, самая большая возможность для потерь — это инстансы или виртуальные машины.
- Инстансы с избыточными ресурсами: в среднем, по данным RightScale Optima 56% расходов приходится на виртуальные машины. Однако, обычно 40 процентов инстансов имеют размер в два-три раза больше, чем требуется для текущих рабочих нагрузок. Это означает 50-75 процентов излишних затрат на каждый неоптимизированный инстанс. Типичная экономия средств составляет 20-30 процентов затрат на виртуальные машины, или 11-16 процентов от всех расходов на облако.
- Простой в работе виртуальных машин: многие пользователи облака запускают свои облачные серверы в режиме 24x7, даже если они используются только в определенные часы и дни. Типичный пример – облачная инфраструктура, которая нужна только в будние дни, когда разработчики работают. Использование скриптов для переключения этих инстансов из графика 24x7 в расписание 12x5 экономит 64 процента затрат этого типа. Аналогично, виртуальные машины, необходимые для разработки, QA, обучения, демонстраций и других применений временного характера, часто не отключаются после завершения проекта. Их немедленное отключение в периоды простоя может быть причиной значительной экономии.
- Выбор типа инстансов или региона (по сути ЦОДа) с более высокой ценой: многие пользователи облачных вычислений не понимают, что при выборе соседних регионов может быть получена значительная экономия в зависимости от выбранного типа инстанса. Например, из регионов AWS в США, Северная Калифорния дороже, чем штат Орегон. Azure имеет несколько регионов на восточном побережье США, а цены различаются для многих семейств виртуальных машин. Кроме того, поскольку поставщики облачных услуг предлагают новые типы инстансов, они часто имеют лучшие спецификации и стоят меньше, чем замененные ими инстансы. Выключение семейств виртуальных машин устаревшего типа может сэкономить значительные средства. Выбор оптимального варианта в среднем дает экономию в 3-5 процентов от расходов на облако.
Скидки на инстансы
Еще одной важной возможностью для экономии средств является использование скидок от провайдеров облачных вычислений. Каждый провайдер имеет разные правила и подходы к предоставлению скидок, но основные принципы одинаковы. RightScale предлагает поэтапно планировать и действовать при поиске варианта получения скидки.
Размер скидки и схема получения зависят от облачного провайдера. Ниже в таблицу сведены некоторые условия скидок AWS, Azure и Google.
|
AWS |
Azure |
|
Тип |
Зарезервированный инстанс |
Зарезервированный инстанс |
Sustained Use Discounts (за длительность использования), Committed Use Discounts |
Период |
1 или 3 года |
1 или 3 года |
1 или 3 года |
Размер скидки |
20-75% |
|
37-55% |
Возможность внести изменения |
Standard: Изменение AZ (зоны), типа сети. Без возможности сменить регион или семейство виртуальных машин. Convertible: Любые изменения |
Любые изменения
|
Изменение семейства или типа инстанса. Без возможности сменить регион. |
Возможность вернуть деньги |
Самостоятельная продажа другому пользователю (может быть сложно) |
Возврат за 12% платежа |
Нет вариантов возмещения |
Хранение данных
Стоимость хранения обычно составляет 10-25 процентов от счета за облачные услуги, хранилище может быстро расти и раздувать расходы. RightScale выделяет следующие самые значительные возможности для оптимизации затрат на хранение:
- Неприкрепленные тома: тома (диски), прикрепленные к инстансу, часто не удаляются вместе с полным удалением виртуальной машины. Эти данные накапливаются. В результате непривязанные к существующим виртуальным машинам тома могут занимать значительный объем хранилища. Администратору необходимо выявить и удалить непривязанные тома или предусмотреть автоматические действия на основе политики хранилища.
- Старые снэпшоты: созданные снэпшоты (моментальные копии состояния данных в системе хранения, зафиксированные на определенный момент времени) также часто не очищают. В каждой организации есть политики, описывающие как долго сохранять снэпшоты. Зачастую эффективным решением является автоматизация этих действий.
- Выбор дорогостоящих вариантов для хранения. Часто пользователи облачных вычислений выбирают более дорогие диски (SSD vs HDD), опции резервирования и частоту.
Управление и оптимизация затрат на облачные вычисления
Организации, внедряющие облачные технологии, быстро понимают, что им нужно научиться управлять затратами на облачные услуги. Предприятия, которые уже широко используют облачные технологии, стремятся оптимизировать расходы и использовать автоматизированные политики, чтобы держать их под контролем. Арендаторы облака нуждаются в отчетах и средствах контроля, помогающих предотвратить потери до того, как это произойдет. Одним из инструментов оптимизации является RightScale Optima, однако, подходит только при выборе зарубежного облачного провайдера.
Комментарий Cloud4Y
Disclaimer: Перевод этой статьи выполнен облачным провайдером Cloud4Y, предлагающим конкурирующий продукт.Облако Cloud4Y построено на базе стека технологий виртуализации VMware с поддержкой всех кластерных опций (HA, DRS, vMotion) и соответствует концепции программно-определяемого дата-центра (SDDC). Арендаторы могут самостоятельно создавать свой виртуальный ЦОД (vDC) и изменять его конфигурацию в кратчайшие сроки с помощью единой и удобной панели управления vCloud Director 9.0.
Платформа виртуализации поддерживает не только создание необходимого количества виртуальных машин с нужными характеристиками и операционными системами, но и виртуализацию сетей и СХД. Благодаря этому, арендаторы облака могут объединять облачные серверы в сети с любой топологией и добиться точного соответствия IT-ресурсов своим актуальным бизнес-потребностям. Аппаратная часть платформы провайдера расположена в нескольких российских дата-центрах TIER III. Оптические каналы связи между ЦОДами облака дублируются, образуя кольцо высокой доступности.
В облаке Cloud4Y происходит преобразования физических вычислительных ресурсов и ресурсов хранения в виртуальные пулы. Этот общий пул представляет собой уровень абстракции, из которого ресурсы могут быть получены для потребления конечными пользователями как отдельные вычислительные единицы. Так как управление происходит через панель самообслуживания vCloud Director 9.0, арендатор сам может в любое время вносить изменения в свой «сборный» облачный ЦОД. По этой причине при использовании облака Cloud4Y у клиентов отсутствует проблема с выбором типа инстанса из предопределенных провайдером и проблема с внесением изменений в конфигурацию своего облака.
Статистику своих VM клиенты могут смотреть сами через Tenant Portal с помощью 'Monitoring Chart'. vCloud Director собирает и хранит различные показатели по производительности ВМ. Эти метрики включают данные по использованию CPU/памяти/хранилища виртуальной машины, средней латентности операций с дисками и прочее. Мониторинг и метрики VM могут быть использованы вами для принятия решений по оптимизации затрат на основе фактов с целью получения максимальной выгоды в пределах используемых ресурсов.
Мы не Google, в этом есть свои плюсы. Cloud4Y предоставляет немного другую модель оплаты, отличную от инстансов — модель «Pay as you go» по каждому типу ресурса по отдельности. Такой более подход дает возможность оплачивать ресурсы по факту потребления. Стоит отметить, что во всех случаях, плата за CPU и RAM берётся только за «включенное» время, в момент, когда вы не пользуетесь виртуальной машиной — плата не взимается, а вот за хранилище придётся платить в независимости от того, включена машина или выключена — плата берётся до момента, пока на диске есть данные, если диск чистый — плата не взимается.
На сайте вы можете найти калькулятор стоимости услуг, но стоит отметить, что он работает на основе предположения использования ВМ в режиме 24х7х30. Используя инстанс в режиме 12х5х30, стоимость услуги для вас может быть ниже более чем на 60%.
Предусмотрен 100% возврат неиспользованных средств с Личного счёта заказчика и постоплата по факту потребления в конце месяца для юридических лиц. Для клиентов из России оплата происходит в рублях, а русскоязычная техподдержка оказывается в режиме 24х7х365.
Имеется гибкая система скидок, в основном зависимость от объема используемых ресурсов. Если Ваша компания занимается разработкой и хочет получить услугу виртуальный облачный сервер (IaaS) со скидкой 40%, тогда заполните небольшую форму и укажите промо-код: «developer40». Предложением могут воспользоваться любые компании, зарегистрированные в РФ, основной вид деятельности которой относится к категории «Разработка программного обеспечения и консультирование в этой области».
Комментарии (31)
achekalin
28.05.2018 06:45А для варианта, когда компания арендует N физических серверов (что дешевле аренды виртуалок в облаке примерно в M раз), и поверх них сама разводит хоть облако, хоть просто свою виртуализацию — в чем выгода облака, кроме наличия API и отсутствия необходимости поддерживать это своими силами?
Спрашиваю, потому что даже в такой «скандальной» по заголовку статье даже близко на вопрос вроде моего ответа нет. Есть только критика того, как другие облака не очень стараются экономить ресурсы юзеров, и указание, что у вас-то всё хорошо. Но при этом: если говорить про Amazon и прочих крупных игроков, им есть смысл платить за API и за то, что знающих их облачные завихи софт и спецов на рынке хотя бы найти можно, а платить неизвестным облакам (да, в т.ч. и вам) — это как свое облако строить (просто большие риски, потому что нет опыта в долгое годы работы), и вот тут уже финансовый момент будет давить.Cloud4Y Автор
28.05.2018 08:04Экономический эффект по сравнению с построением собственного облака есть, особенно значительный он по сравнению с построением собственного облака «с нуля».
1) Собственная инфраструктура будет иметь мощности превосходящие текущие потребности, строгого соответствия между «тем, что нужно» и «тем, что есть» не добиться. Варианта два — простой мощностей или нехватка ресурсов.
2) Потребуются большие первоначальные инвестиции, а значит % кредита или стоимость денег во времени в пользу аренды.
2) Провайдер реализует аппаратное резервирование. Резервирование провайдера благодаря применимости статистики (вероятность выхода из строя n из m физических серверов за T) на большом количестве хостов — эффективнее.
3) Экономия на лицензиях ПО (например, VMware), экономия на оплате труда дополнительного персонала
4) Электроэнергия и аренда ЦОДа
5) Провайдер постоянно находится в состоянии конкуренции и, из-за риска потери контракта, не может позволить себе работать некачественно, а собственная ИТ-служба является монополией. Потери за время простоев и сбоев ожидаемо ниже.
Реализация собственной инфраструктуры маловероятно позволит приблизится в уровню надежности и отказоустойчивости облака профессионального провайдера, либо будет экономически неэффективным.
Подробнее мы ответим на этот в одной из следующих статей, в которых опишем и сравним TCO (совокупную стоимость владения) облака и собственной IT-инфраструктуры.achekalin
28.05.2018 08:29А скажите, сколько сегодня обойдется аренда сервера с парой xeon-ов ядер по 12, с 256 Гб ОЗУ, с хранением данных на SSD + HDD? На такой машине мы с вами уместим, скажем, 8 ВМ по 32 Гб ОЗУ (утрирую). А теперь скажите, сколько такие ВМ обойдутся у вас в облаке?
Подозреваю что разговор будет идти о соотношении 1:5...1:10. При таких цифрах, мне кажется, можно не только двойным, но и тройным образом по железу заложиться, (заодно имея резерв для маневра), и на VMWare потратиться, если KVM и прочие варианты вас не порадают.
И это, заметьте, без единоразовых вложений в железо (и без принятия его на баланс), без взятия кредита на его покупку, и провайдер железа раз года в два-три его на свежее поменяет, и за свет-канал и охрану будет отвечать.
Ожидаемая надёжность, у вас, наверное, выше. Реальная… Ну, как в том анекдоте, 50:50 наверное, либо авария, либо нет? Конечно, у вас опыт, но и цена в разы выше in-house решения, так что надо крепко думать, идти ли в облако.
Cloud4Y Автор
28.05.2018 08:47Подозреваю что разговор будет идти о соотношении 1:5...1:10
Ваш вопрос понятен, чтобы не говорить безосновательно о том, что соотношение будет в пользу облака при учете именно совокупной стоимости владения в течение, например 5 лет, мы добавим этот вариант с арендой bare metal в актуальных на сегодня ценах в статью про TCO, которая планируется. Это просто не поместится в формат комментария.
Hardened
28.05.2018 19:18Чтобы сделать сопоставимое решение на bare metal вам потребуется собирать vSAN на 3 узла или что-то типа SoFS + Hyper-v. Желательно на сети 10G. А вот последний пункт в РФ вам ещё поискать придётся за разумный ценник.
Плюс стоимость содержания соответствующей инженерной компетенции внутри компании учтите. Поставщик ФОТ на много клиентов и кластера в десятки серверов размазывает. А для маленькой компании это будет до 40-50% расходов проекта
aikixd
28.05.2018 10:51По достижении некоего размера, использовать облако становится невыгодным. Сказать где граница именно нельзя, нужно смотреть по конкретному решению, тем более что облака быстро обрастают новыми сервисами. Нужно учесть все накладные расходы тоже. Даже если стойка не у вас, а в ДЦ, все равно на вас будет висеть развертка, настройка железа, сетей, политик и т.д. Плюс неустойки, даунтайм, обновления железа и другие форс мажоры. И конечно зарплаты новому персоналу.
Как правило пальца, можно сказать, что если вы не можете уверенно взвесить этот вопрос, то вам нужно облако.
Hardened
28.05.2018 19:32VMware vCloud Director тоже вполне себе стандарт и нет проблем ни с инженерами, ни с API.
Для интереса посмотрите сервис VMware on AWS
Tangeman
28.05.2018 08:23Есть одна «небольшая» проблема.
Если, условно, час простоя для компании обходится в $10K денег, и облачный хостер готов это компенсировать в случае чего (а случаи бывают даже у Амазона) — ок, это того стоит.
Если же нет (в вашем случае — максимум 100% месячной стоимости) — то облако того не стоит и почти неотличимо от «самого дешевого хостинга» — в соответствии с вашими SLA вы не отвечаете ни за что (как и практически все остальные облачные провайдеры, впрочем).
Если же вы и пойдете на более адекватные условия SLA, это взвинтит цены настолько что
проще будет нанять своих админов на голое железо где подешевле.
Ну а теперь простой вопрос — зачем платить больше, если можно взять сервера на том же Hetzner и развернуть там своё облако за гораздо меньшие деньги (даже если придётся взять своих админов)? Hetzner, кстати, декларирует «всего» 99,9% доступности, хотя де-факто она на порядок выше.Cloud4Y Автор
28.05.2018 08:32Условная и неполная аналогия: Зачем заказывать такси с безопасными по результатам независимых краш-тестов и комфортными автомобилями и квалифицированными водителями, если можно попросить соседа на «самом дешевом автомобиле» или купить такой, заплатив гораздо меньшие деньги и оплатив бензин?
Дело в том, что при достаточном количестве испытаний ожидаемая математически вероятность становится равна фактической частоте проблем. Если допустимо попасть в аварию «на самом дешевом авто», выгоднее брать его.alkresin
28.05.2018 09:51Аналогия, действительно, крайне неудачная, даже если предположить на минутку, что такси предлагает какие-то особо безопасные по сравнению с «соседскими» автомобили.
Возможный результат автомобильной аварии — смерть. А результат связанного с аварией на сервере временного перерыва в функционировании сервиса — всего лишь деньги.Cloud4Y Автор
28.05.2018 10:06Модель не предполагает передачу всех свойств реальности. Аналогия не приравнивает модели, а указывает на частичное сходство. Возможный крайний результат аварии в IT — смерть бизнеса.
Tangeman
28.05.2018 13:49Если уж сравнивать с такси… то вот более полная аналогия.
Можно взять такси (облако), с условным автомобилем фирмы X в качестве оного, и можно взять в аренду (dedicated server) автомобиль фирмы X — что будет выгодней (водители свои и очень квалифицированные)? Если ездить много и постоянно — явно не такси, хотя качество и характеристики самого автомобиля одинаковое в обоих случаях. Впрочем, в случае постоянных и непрерывных поездок на протяжении длительного времени этот самый X можно будет купить — это будет дешевле и такси, и аренды, без потери качества.
Как уже выше отметили, построить своё облако (при наличии ресурсов и специалистов) будет выгодней чем использовать чужое — в конце концов, большинство фирм которые выросли именно так и поступают.
Приведу более простой личный пример. У меня есть парочка серверов, довольно мощных, для хобби, экспериментов и иногда контрактых работ, их простой не нанесет мне убытка хотя и будет неприятен. Обходятся они мне в сумме около $100/мес, работают надежно (де-факто SLA > 99,99 при обещанных 99,9). Сервера на разных провайдерах и в разных странах (мало ли что), оба провайдера крупные игроки на рынке и предлагают также облачные решения. Но если бы я выбрал аналогичные по мощности и ресурсам облачные решения (не только у этих провайдеров — а из всех более-менее крупных), то это бы стоило уже раз в 10 дороже.
Да, я переплачиваю, ибо не использую мощности и ресурсы серверов на 100%, даже на 10%, но в любой момент могу это сделать (и делаю периодически), в то время как облачный вариант этого бы не позволил — если просуммировать все случаи таких резких всплесков, облако всё равно оказалось бы дороже (я считал).
К чему это всё… Нет, я не утверждаю что облако невыгодно в принципе — это конечно не так, своя ниша у него есть, но вы его пытаетесь подавать как серебрянную пулю с низкой стоимостью — а это не совсем честно, как мне кажется.
Без точного знания конкретной задачи и учета всех переменных невозможно сказать заранее что будет выгодней — IaaS, PaaS, своё облако или свой датацентр, всё нужно считать для каждого конкретного случая.Cloud4Y Автор
28.05.2018 14:10не использую мощности и ресурсы серверов на 100%, даже на 10%
Но если бы я выбрал аналогичные по мощности и ресурсам облачные решения (не только у этих провайдеров — а из всех более-менее крупных), то это бы стоило уже раз в 10 дороже.
(0; 10%)*10Х < Х
Вы его пытаетесь подавать как серебрянную пулю с низкой стоимостью — а это не совсем честно, как мне кажется.
Это нечестно, поэтому продавать как панацею не пытаемся, но внимание привлекаем, чтобы каждый разобрался в своем случае.
Без точного знания конкретной задачи и учета всех переменных невозможно сказать заранее что будет выгодней
Узнаем точную задачу, чтобы помочь клиенту.
что будет выгодней — IaaS, PaaS, своё облако или свой датацентр, всё нужно считать для каждого конкретного случая.
Забыли про гибридную модель облакаTangeman
28.05.2018 15:23(0; 10%)*10Х < Х
Вы, видимо, не обратили внимания на «если просуммировать все случаи таких резких всплесков, облако всё равно оказалось бы дороже».
Один месяц полной загрузки одного сервера в случае облака обошелся бы мне в стоимость двух полноценных серверов за год — вот почему мне выгодней держать DS, и подозреваю, у многих небольших компаний или контрактников примерно аналогичная ситуация.
А также, в случае DS я точно знаю где и как используются его ресурсы, в случае облака я не могу быть уверен на 100% что получу свои vCPU и vRAM, нет гарантии что на хосте никто не тормозит мой инстанс, и т.д. — а если гарантии даются, то это уже сравнимо со стоимостью аналогичного DS (что логично), но поскольку это облако, то чаще всего оно ощутимо дороже аналогичного DS. В сравнении с вашими услугами, к примеру — всего два дня у вас в конфигурации моего DS стоят больше одного месяца (в 17(!) раз выше), не говоря уже про SLA на диски и сеть (очень мало). Если взять три DS чтобы обеспечить «bulletproof» HA/LB, они всё равно обойдутся в несколько раз дешевле чем конфигурация одного из них в вашем облаке.
Самое печальное, впрочем, не это — дело в том, что в случае DS, что в случае PaaA/IaaS, провайдер отвечает не более чем стоимостью времени простоя (в редких случаях это выше, но всё равно не выше 250%-500%) — то есть бремя затрат/потерь в случае проблем всё равно на клиенте, в то время как SLA для DS и облака (в пределах одного провайдера) редко отличаются.Cloud4Y Автор
28.05.2018 16:40Опишите, пожалуйста, характеристики каждого сервера. Не могу понять как у вас получилось в 17 раз дороже.
в случае облака я не могу быть уверен на 100% что получу свои vCPU и vRAM, нет гарантии что на хосте никто не тормозит мой инстанс
Количество MIPS на одно vCPU составляет не менее 2900, что гарантируется по SLA. Также не допускается «переподписка» физической оперативной памяти, RAM Swaped равен 0%. Это означает, что выделенная при создании виртуальной машины Configured Virtual RAM, которую будет видеть гостевая ОС, является 100% выделенной физической памятью, которая доступна виртуальной машине в любой момент времени.Tangeman
28.05.2018 17:51Я считал по этому: 64 GB RAM, 2x 2000GB HDD, 1Gbit network, 30TB traffic, Core i7-7700, в вашем конфигураторе указывал соответствующие параметры: 4 x CPU, 64 GB RAM, 1000 GB HDD Medium (в моём случае это всё равно RAID1, и IOPS/Latency явно получше).
Получилось €26/день(!) или €780/мес — мой же DS стоит около €40/месяц.
К тому же, у вас «Free guaranteed unlimited channel 5 Mbps expandable to 1000 Mbps» — а у меня это гарантированный 1 Gbit/s (пусть и с траффиком — но он более чем достаточен, к тому же лишние терабайты стоят мелочи, или unlimit с 10 Mbit/s).Cloud4Y Автор
28.05.2018 18:35«сервер, довольно мощный, для хобби, экспериментов и иногда контрактых работ» = около €40/месяц
Облако:
1) Скидка: Соответствующая VM €550/мес
2) Использование 10% = €55/мес (включая 14 точек резервного копирования в другой географически удаленный ЦОД)
Всплески ограничены мощностью серверов. В облаке изменение мощности может потребовать перезагрузки VM, но тарификация почасовая.
N часов на 100% мощности + M часов на средней мощности + X часов простоя могут стоять меньше €40/месяцTangeman
28.05.2018 20:42Пока это выглядит так, что вы рекомендуете мне платить примерно столько же, но за сервер который даст мне только 10% от того что у меня уже есть, а если мне потребуется больше на какое-то время, придётся совершать лишние телодвижения (как минимум перезагрузку инстанса в случае изменения конфигурации) и платить больше (пусть и временно).
Проблема в том что потребности в ресурсах не всегда предсказуемы — я не знаю когда и насколько мне понадобятся все 64GB с 4 CPU (хотя всё же чуть больше чем 4, если учесть HT), зато я точно знаю что мне в обозримом будущем не потребуется больше, т.е. если вдруг это таки будет месяц 100% загрузки — всё, я попал на годовую стоимость DS всего за месяц. OK, если это нужно клиенту — не совсем попал — клиент заплатит, конечно, но не всегда это нужно только клиенту, да и драть втридорога с клиентов тоже не хочется.
Если вдруг мой клиент решит что ему нужен инстанс у меня на какое-то время (или нужен буден инстанс для выполнения работы на длительное время — так бывает), я смогу это сделать не заплатив лишнего цента провайдеру и не урезая своих ресурсов.
Некоторые из крутящихся приложений расчитаны на то что в любой момент (при запросе извне) они получат всю мощь, а не будут урезаны текущим инстансом и его ресурсами, т.е. вдруг нужно 50G RAM (без свопа!) на несколько секунд-минут, и так с периодичностью в час-два — как вы догадываетесь, в случае облака мне всё равно придётся держать эти 50G готовыми 24/7/365 — а это львиная доля стоимости — и вот уже вроде как и 10% «в среднем», но де-факто все 90% «мощности», то же самое с диском — вряд-ли какой-то облачный провайдер позволяет динамически менять эти параметры в живой системе, при этом считая только реальное потребление за время использования (ок, AWS/Azure/Google могут, но это требует поддержки со стороны приложений, а это не всегда возможно).
Или другой пример — мне вдруг нужно 4-5 инстансов в KVM на несколько дней для выполнения какой-то работы или эксперимента — в случае облака придётся брать их отдельно (ибо вложение KVM несколько неадекватно) — в вашем случае, к примеру, 4 инстанса по 8G RAM / 100G disk на неделю обойдутся минимум в две месячных стоимости всего DS.
Заметьте, это всё — только на моём личном примере, речь всего-то о несчастных €40-50/мес, но ведь похожие условия могут быть в небольшой фирме, которой периодически (но только чаще и всё также непредсказуемо) могут быть нужны по несколько десятков инстансов на несколько дней-недель — и тут сумма увеличивается раз эдак в 10-20, в пересчете на год уже проще будет купить свои сервера для экспериментов, чем пользоваться облаком.
И есть ещё один важный момент. Поскольку в случае cloud речь про VM и гипервизор, нет абсолютно никакой гарантии что провайдер не лезет внутрь и не наблюдает за клиентом по распоряжению соответствующих структур (или в связи с любопытством админов, или в связи с подкупленным админом) — в случае DS это на 99% решается шифрованием диска, в случае VM — увы, не решается вообще никак, даже если провайдер говорит что всё супер-пупер-надежно-и-муха-не-пролетит — потому что если бы это было действительно так, гарантии на это были бы прописаны в договоре, а пока это ограничено стоимостью времени простоя — это не гарантии. Да, DS могут конфисковать, в теории — но я не говорю про случаи когда нарушается закон, а в других случаях никто DS трогать не будет — ибо это невозможно сделать незаметно.Hardened
29.05.2018 04:46На виртуалках диски тоже можно шифровать клиентским ключом. Или на уровне ОС. Если считать алгоритмы стойкими, то профита с клона диска органам никакого и разницы между DS и Cloud нет
Tangeman
29.05.2018 14:51К сожалению, в случае виртуалки всё намного печальней — host имеет полный доступ к памяти guest в любое время, совершенно необнаруживаемый, не говоря уже о возможности трейсинга.
Соответственно, имея доступ к памяти, можно легко получить все ключи шифрования, или, как пример, все сертификаты с приватными ключами — благо структуры данных в памяти известны.
В случае DS для этого придётся как минимум его отключить и загрузится со своей recovery system, но это невозможно сделать незаметно, да и просто любопытный это вряд ли сделает.
achekalin
28.05.2018 08:33SLA — это хорошо (знаю ЦОД, где мне прямо ответили про простой, что раз мы Tier-3, то больше положенных в год часов простоя не будет — и уже лет 7 обещание выполняют; не рекламы ради, но им я сейчас верю вполне), а как провайдер увидит реальные потери бизнеса за ту минуту, что в середине дня сервер был недоступен?
Надо идти не на дешевейшие сервера, а на средние, они все равно дешевле облака. Свои админы тоже недесплатны, но это компетенция в компании, а не у дяди.
Cloud4Y Автор
28.05.2018 08:38Нужно спросить у заказчика. Если нужно, можно использовать катастрофоустойчивое решение (кластер из территориально распределенных ЦОДов с синхронным зеркалированием). Тогда 99,99% не потеряется ни одна транзакция. Эта услуга дороже, нужно сопоставить размер потерь и вложений в дополнительные 0,01-0,02%
Hardened
28.05.2018 19:58Назовите хотя бы несколько примеров B2B услуг, где бы поставщик компенсировал убытки и упущенную выгоду?
Вообще в деловой среде принято страховать свои риски в специальных компаниях и за отдельные деньги (космические пуски). Если клиент не готов платить, значит это ему не нужно.
Почему в ИТ должно быть как-то по другому?
Tangeman
28.05.2018 20:49Не должно — но об этом-то и речь — ответственность провайдера в случае облака и DS практически одинакова, SLA такое же, только первое стоит дороже (даже с учетом 2-3х-кратного резервирования) чем второе (при эквивалентных параметрах).
Что и приводит к вопросу — зачем платить больше?Hardened
29.05.2018 04:51Вы что в SLA включаете? Только Availability %?
Будет ли на ваших дедиках со стороны провайдера тот же RPO и RTO?
То что у вас кластер на прикладом уровне это уже ваша ЗО и далеко не во всех случаях корпоративный приклад можно заставить работать в такой схеме.Tangeman
29.05.2018 15:06Я что-то не встречал в SLA облачных провайдеров RPO и RTO — в конце концов, это сильно зависит от конкретного приложения, просто восстановление железа (виртуального или реального) или бэкапа не обязательно ведет к восстановлению сервиса, это в 99% случаев ЗО клиента.
В случае DS, есть SLA на RTO по железу, остальное уже ЗО клиента.
BugM
Ну вы в курсе что вы в 10 дороже того же Hetzner?
Никакими скидками на 30% и оптимизациями использования эту разницу не исправить.
Cloud4Y Автор
У нас услуги разные по количественному и качественному составу и возможностям. Подробнее описывали в статье Сравниваем то, что нельзя: дешевый хостинг и облако на стеке VMware (не имели ввиду именно Hetzner)
lotse8
Здесь Вы не совсем правы. Мне как заказчику, например, нет разницы что там у Вас и на каком софте и железе, это не мои, а ваши проблемы. Мне главное, чтобы мой проект работал без проблем, был всегда доступен и при этом за хостинг (облако, виртуальный или выделенный сервер — без разницы) много денег не требовал.
Хотелось бы, чтобы вы поняли, что есть еще такое понятие как рентабельность проекта или бизнеса. И если аренда облака съедает большой кусок прибыли или всю прибыль, то смысла на арендодателя работать никакого нет.
Skerrigan
Понимаю, что могу что-либо упускать и не видеть всей картины в целом, тем не менее…
Они в свою очередь могут вам сказать абсолютно то же самое — ваша рентабельность их не волнует и им без разницы что там у вас, это ваши и только ваши проблемы.
Ведь у них своя бизнес модель, выбранная уже ими на основе их умозаключений, навыков и возможностей.
А рынок уже расставит все по своим местам: может быть они и не правы (и тогда разорятся), а может быть вы просто не их клиентская аудитория (и есть люди, что понимают преимущества их варианта, которым не все равно что-там и как крутится).
Hardened
Поддерживаю. Рынок расставит все по своим местам. Hertzner дешевле AWS, но при этом не может сравниться с последним по выручке и набору услуг.