Комментарии 35
Ну вы в курсе что вы в 10 дороже того же Hetzner?
Никакими скидками на 30% и оптимизациями использования эту разницу не исправить.
Никакими скидками на 30% и оптимизациями использования эту разницу не исправить.
У нас услуги разные по количественному и качественному составу и возможностям. Подробнее описывали в статье Сравниваем то, что нельзя: дешевый хостинг и облако на стеке VMware (не имели ввиду именно Hetzner)
Здесь Вы не совсем правы. Мне как заказчику, например, нет разницы что там у Вас и на каком софте и железе, это не мои, а ваши проблемы. Мне главное, чтобы мой проект работал без проблем, был всегда доступен и при этом за хостинг (облако, виртуальный или выделенный сервер — без разницы) много денег не требовал.
Хотелось бы, чтобы вы поняли, что есть еще такое понятие как рентабельность проекта или бизнеса. И если аренда облака съедает большой кусок прибыли или всю прибыль, то смысла на арендодателя работать никакого нет.
Хотелось бы, чтобы вы поняли, что есть еще такое понятие как рентабельность проекта или бизнеса. И если аренда облака съедает большой кусок прибыли или всю прибыль, то смысла на арендодателя работать никакого нет.
Понимаю, что могу что-либо упускать и не видеть всей картины в целом, тем не менее…
Они в свою очередь могут вам сказать абсолютно то же самое — ваша рентабельность их не волнует и им без разницы что там у вас, это ваши и только ваши проблемы.
Ведь у них своя бизнес модель, выбранная уже ими на основе их умозаключений, навыков и возможностей.
А рынок уже расставит все по своим местам: может быть они и не правы (и тогда разорятся), а может быть вы просто не их клиентская аудитория (и есть люди, что понимают преимущества их варианта, которым не все равно что-там и как крутится).
Мне как заказчику, например, нет разницы что там у Вас и на каком софте и железе, это не мои, а ваши проблемы
Они в свою очередь могут вам сказать абсолютно то же самое — ваша рентабельность их не волнует и им без разницы что там у вас, это ваши и только ваши проблемы.
Ведь у них своя бизнес модель, выбранная уже ими на основе их умозаключений, навыков и возможностей.
А рынок уже расставит все по своим местам: может быть они и не правы (и тогда разорятся), а может быть вы просто не их клиентская аудитория (и есть люди, что понимают преимущества их варианта, которым не все равно что-там и как крутится).
А для варианта, когда компания арендует N физических серверов (что дешевле аренды виртуалок в облаке примерно в M раз), и поверх них сама разводит хоть облако, хоть просто свою виртуализацию — в чем выгода облака, кроме наличия API и отсутствия необходимости поддерживать это своими силами?
Спрашиваю, потому что даже в такой «скандальной» по заголовку статье даже близко на вопрос вроде моего ответа нет. Есть только критика того, как другие облака не очень стараются экономить ресурсы юзеров, и указание, что у вас-то всё хорошо. Но при этом: если говорить про Amazon и прочих крупных игроков, им есть смысл платить за API и за то, что знающих их облачные завихи софт и спецов на рынке хотя бы найти можно, а платить неизвестным облакам (да, в т.ч. и вам) — это как свое облако строить (просто большие риски, потому что нет опыта в долгое годы работы), и вот тут уже финансовый момент будет давить.
Спрашиваю, потому что даже в такой «скандальной» по заголовку статье даже близко на вопрос вроде моего ответа нет. Есть только критика того, как другие облака не очень стараются экономить ресурсы юзеров, и указание, что у вас-то всё хорошо. Но при этом: если говорить про Amazon и прочих крупных игроков, им есть смысл платить за API и за то, что знающих их облачные завихи софт и спецов на рынке хотя бы найти можно, а платить неизвестным облакам (да, в т.ч. и вам) — это как свое облако строить (просто большие риски, потому что нет опыта в долгое годы работы), и вот тут уже финансовый момент будет давить.
Экономический эффект по сравнению с построением собственного облака есть, особенно значительный он по сравнению с построением собственного облака «с нуля».
1) Собственная инфраструктура будет иметь мощности превосходящие текущие потребности, строгого соответствия между «тем, что нужно» и «тем, что есть» не добиться. Варианта два — простой мощностей или нехватка ресурсов.
2) Потребуются большие первоначальные инвестиции, а значит % кредита или стоимость денег во времени в пользу аренды.
2) Провайдер реализует аппаратное резервирование. Резервирование провайдера благодаря применимости статистики (вероятность выхода из строя n из m физических серверов за T) на большом количестве хостов — эффективнее.
3) Экономия на лицензиях ПО (например, VMware), экономия на оплате труда дополнительного персонала
4) Электроэнергия и аренда ЦОДа
5) Провайдер постоянно находится в состоянии конкуренции и, из-за риска потери контракта, не может позволить себе работать некачественно, а собственная ИТ-служба является монополией. Потери за время простоев и сбоев ожидаемо ниже.
Реализация собственной инфраструктуры маловероятно позволит приблизится в уровню надежности и отказоустойчивости облака профессионального провайдера, либо будет экономически неэффективным.
Подробнее мы ответим на этот в одной из следующих статей, в которых опишем и сравним TCO (совокупную стоимость владения) облака и собственной IT-инфраструктуры.
1) Собственная инфраструктура будет иметь мощности превосходящие текущие потребности, строгого соответствия между «тем, что нужно» и «тем, что есть» не добиться. Варианта два — простой мощностей или нехватка ресурсов.
2) Потребуются большие первоначальные инвестиции, а значит % кредита или стоимость денег во времени в пользу аренды.
2) Провайдер реализует аппаратное резервирование. Резервирование провайдера благодаря применимости статистики (вероятность выхода из строя n из m физических серверов за T) на большом количестве хостов — эффективнее.
3) Экономия на лицензиях ПО (например, VMware), экономия на оплате труда дополнительного персонала
4) Электроэнергия и аренда ЦОДа
5) Провайдер постоянно находится в состоянии конкуренции и, из-за риска потери контракта, не может позволить себе работать некачественно, а собственная ИТ-служба является монополией. Потери за время простоев и сбоев ожидаемо ниже.
Реализация собственной инфраструктуры маловероятно позволит приблизится в уровню надежности и отказоустойчивости облака профессионального провайдера, либо будет экономически неэффективным.
Подробнее мы ответим на этот в одной из следующих статей, в которых опишем и сравним TCO (совокупную стоимость владения) облака и собственной IT-инфраструктуры.
А скажите, сколько сегодня обойдется аренда сервера с парой xeon-ов ядер по 12, с 256 Гб ОЗУ, с хранением данных на SSD + HDD? На такой машине мы с вами уместим, скажем, 8 ВМ по 32 Гб ОЗУ (утрирую). А теперь скажите, сколько такие ВМ обойдутся у вас в облаке?
Подозреваю что разговор будет идти о соотношении 1:5...1:10. При таких цифрах, мне кажется, можно не только двойным, но и тройным образом по железу заложиться, (заодно имея резерв для маневра), и на VMWare потратиться, если KVM и прочие варианты вас не порадают.
И это, заметьте, без единоразовых вложений в железо (и без принятия его на баланс), без взятия кредита на его покупку, и провайдер железа раз года в два-три его на свежее поменяет, и за свет-канал и охрану будет отвечать.
Ожидаемая надёжность, у вас, наверное, выше. Реальная… Ну, как в том анекдоте, 50:50 наверное, либо авария, либо нет? Конечно, у вас опыт, но и цена в разы выше in-house решения, так что надо крепко думать, идти ли в облако.
Подозреваю что разговор будет идти о соотношении 1:5...1:10
Ваш вопрос понятен, чтобы не говорить безосновательно о том, что соотношение будет в пользу облака при учете именно совокупной стоимости владения в течение, например 5 лет, мы добавим этот вариант с арендой bare metal в актуальных на сегодня ценах в статью про TCO, которая планируется. Это просто не поместится в формат комментария.
Чтобы сделать сопоставимое решение на bare metal вам потребуется собирать vSAN на 3 узла или что-то типа SoFS + Hyper-v. Желательно на сети 10G. А вот последний пункт в РФ вам ещё поискать придётся за разумный ценник.
Плюс стоимость содержания соответствующей инженерной компетенции внутри компании учтите. Поставщик ФОТ на много клиентов и кластера в десятки серверов размазывает. А для маленькой компании это будет до 40-50% расходов проекта
2. Аутсорс — пригласили компанию, она один раз настроила, сделала мониторинги, то-се, обучила местных спецов (куда чего нажимать, если лампочка загорелась красным, и при каких метриках звонить им) и все. Единожды вложили ~200 тысяч и забыли. Делите на 2, если пригласили специалиста, работающего на себя.
В плане размазывания эксплуатационных на аутсорсера с несколькими клиентами может быть и эффективней (когда не нужна скорость реакции), чем inhouse. Но не будет лучше, чем операционные расходы поставщика, у которого инфра на уровне платформы одинаковая для всех клиентов. Аутсорсер в итоге вынужден брать больше, так как у его клиентов уровень стандартизации ниже и обслуживается несколько площадок.
По достижении некоего размера, использовать облако становится невыгодным. Сказать где граница именно нельзя, нужно смотреть по конкретному решению, тем более что облака быстро обрастают новыми сервисами. Нужно учесть все накладные расходы тоже. Даже если стойка не у вас, а в ДЦ, все равно на вас будет висеть развертка, настройка железа, сетей, политик и т.д. Плюс неустойки, даунтайм, обновления железа и другие форс мажоры. И конечно зарплаты новому персоналу.
Как правило пальца, можно сказать, что если вы не можете уверенно взвесить этот вопрос, то вам нужно облако.
VMware vCloud Director тоже вполне себе стандарт и нет проблем ни с инженерами, ни с API.
Для интереса посмотрите сервис VMware on AWS
Есть одна «небольшая» проблема.
Если, условно, час простоя для компании обходится в $10K денег, и облачный хостер готов это компенсировать в случае чего (а случаи бывают даже у Амазона) — ок, это того стоит.
Если же нет (в вашем случае — максимум 100% месячной стоимости) — то облако того не стоит и почти неотличимо от «самого дешевого хостинга» — в соответствии с вашими SLA вы не отвечаете ни за что (как и практически все остальные облачные провайдеры, впрочем).
Если же вы и пойдете на более адекватные условия SLA, это взвинтит цены настолько что
проще будет нанять своих админов на голое железо где подешевле.
Ну а теперь простой вопрос — зачем платить больше, если можно взять сервера на том же Hetzner и развернуть там своё облако за гораздо меньшие деньги (даже если придётся взять своих админов)? Hetzner, кстати, декларирует «всего» 99,9% доступности, хотя де-факто она на порядок выше.
Если, условно, час простоя для компании обходится в $10K денег, и облачный хостер готов это компенсировать в случае чего (а случаи бывают даже у Амазона) — ок, это того стоит.
Если же нет (в вашем случае — максимум 100% месячной стоимости) — то облако того не стоит и почти неотличимо от «самого дешевого хостинга» — в соответствии с вашими SLA вы не отвечаете ни за что (как и практически все остальные облачные провайдеры, впрочем).
Если же вы и пойдете на более адекватные условия SLA, это взвинтит цены настолько что
проще будет нанять своих админов на голое железо где подешевле.
Ну а теперь простой вопрос — зачем платить больше, если можно взять сервера на том же Hetzner и развернуть там своё облако за гораздо меньшие деньги (даже если придётся взять своих админов)? Hetzner, кстати, декларирует «всего» 99,9% доступности, хотя де-факто она на порядок выше.
Условная и неполная аналогия: Зачем заказывать такси с безопасными по результатам независимых краш-тестов и комфортными автомобилями и квалифицированными водителями, если можно попросить соседа на «самом дешевом автомобиле» или купить такой, заплатив гораздо меньшие деньги и оплатив бензин?
Дело в том, что при достаточном количестве испытаний ожидаемая математически вероятность становится равна фактической частоте проблем. Если допустимо попасть в аварию «на самом дешевом авто», выгоднее брать его.
Дело в том, что при достаточном количестве испытаний ожидаемая математически вероятность становится равна фактической частоте проблем. Если допустимо попасть в аварию «на самом дешевом авто», выгоднее брать его.
Аналогия, действительно, крайне неудачная, даже если предположить на минутку, что такси предлагает какие-то особо безопасные по сравнению с «соседскими» автомобили.
Возможный результат автомобильной аварии — смерть. А результат связанного с аварией на сервере временного перерыва в функционировании сервиса — всего лишь деньги.
Возможный результат автомобильной аварии — смерть. А результат связанного с аварией на сервере временного перерыва в функционировании сервиса — всего лишь деньги.
Если уж сравнивать с такси… то вот более полная аналогия.
Можно взять такси (облако), с условным автомобилем фирмы X в качестве оного, и можно взять в аренду (dedicated server) автомобиль фирмы X — что будет выгодней (водители свои и очень квалифицированные)? Если ездить много и постоянно — явно не такси, хотя качество и характеристики самого автомобиля одинаковое в обоих случаях. Впрочем, в случае постоянных и непрерывных поездок на протяжении длительного времени этот самый X можно будет купить — это будет дешевле и такси, и аренды, без потери качества.
Как уже выше отметили, построить своё облако (при наличии ресурсов и специалистов) будет выгодней чем использовать чужое — в конце концов, большинство фирм которые выросли именно так и поступают.
Приведу более простой личный пример. У меня есть парочка серверов, довольно мощных, для хобби, экспериментов и иногда контрактых работ, их простой не нанесет мне убытка хотя и будет неприятен. Обходятся они мне в сумме около $100/мес, работают надежно (де-факто SLA > 99,99 при обещанных 99,9). Сервера на разных провайдерах и в разных странах (мало ли что), оба провайдера крупные игроки на рынке и предлагают также облачные решения. Но если бы я выбрал аналогичные по мощности и ресурсам облачные решения (не только у этих провайдеров — а из всех более-менее крупных), то это бы стоило уже раз в 10 дороже.
Да, я переплачиваю, ибо не использую мощности и ресурсы серверов на 100%, даже на 10%, но в любой момент могу это сделать (и делаю периодически), в то время как облачный вариант этого бы не позволил — если просуммировать все случаи таких резких всплесков, облако всё равно оказалось бы дороже (я считал).
К чему это всё… Нет, я не утверждаю что облако невыгодно в принципе — это конечно не так, своя ниша у него есть, но вы его пытаетесь подавать как серебрянную пулю с низкой стоимостью — а это не совсем честно, как мне кажется.
Без точного знания конкретной задачи и учета всех переменных невозможно сказать заранее что будет выгодней — IaaS, PaaS, своё облако или свой датацентр, всё нужно считать для каждого конкретного случая.
Можно взять такси (облако), с условным автомобилем фирмы X в качестве оного, и можно взять в аренду (dedicated server) автомобиль фирмы X — что будет выгодней (водители свои и очень квалифицированные)? Если ездить много и постоянно — явно не такси, хотя качество и характеристики самого автомобиля одинаковое в обоих случаях. Впрочем, в случае постоянных и непрерывных поездок на протяжении длительного времени этот самый X можно будет купить — это будет дешевле и такси, и аренды, без потери качества.
Как уже выше отметили, построить своё облако (при наличии ресурсов и специалистов) будет выгодней чем использовать чужое — в конце концов, большинство фирм которые выросли именно так и поступают.
Приведу более простой личный пример. У меня есть парочка серверов, довольно мощных, для хобби, экспериментов и иногда контрактых работ, их простой не нанесет мне убытка хотя и будет неприятен. Обходятся они мне в сумме около $100/мес, работают надежно (де-факто SLA > 99,99 при обещанных 99,9). Сервера на разных провайдерах и в разных странах (мало ли что), оба провайдера крупные игроки на рынке и предлагают также облачные решения. Но если бы я выбрал аналогичные по мощности и ресурсам облачные решения (не только у этих провайдеров — а из всех более-менее крупных), то это бы стоило уже раз в 10 дороже.
Да, я переплачиваю, ибо не использую мощности и ресурсы серверов на 100%, даже на 10%, но в любой момент могу это сделать (и делаю периодически), в то время как облачный вариант этого бы не позволил — если просуммировать все случаи таких резких всплесков, облако всё равно оказалось бы дороже (я считал).
К чему это всё… Нет, я не утверждаю что облако невыгодно в принципе — это конечно не так, своя ниша у него есть, но вы его пытаетесь подавать как серебрянную пулю с низкой стоимостью — а это не совсем честно, как мне кажется.
Без точного знания конкретной задачи и учета всех переменных невозможно сказать заранее что будет выгодней — IaaS, PaaS, своё облако или свой датацентр, всё нужно считать для каждого конкретного случая.
не использую мощности и ресурсы серверов на 100%, даже на 10%
Но если бы я выбрал аналогичные по мощности и ресурсам облачные решения (не только у этих провайдеров — а из всех более-менее крупных), то это бы стоило уже раз в 10 дороже.
(0; 10%)*10Х < Х
Вы его пытаетесь подавать как серебрянную пулю с низкой стоимостью — а это не совсем честно, как мне кажется.Это нечестно, поэтому продавать как панацею не пытаемся, но внимание привлекаем, чтобы каждый разобрался в своем случае.
Без точного знания конкретной задачи и учета всех переменных невозможно сказать заранее что будет выгоднейУзнаем точную задачу, чтобы помочь клиенту.
что будет выгодней — IaaS, PaaS, своё облако или свой датацентр, всё нужно считать для каждого конкретного случая.Забыли про гибридную модель облака
(0; 10%)*10Х < Х
Вы, видимо, не обратили внимания на «если просуммировать все случаи таких резких всплесков, облако всё равно оказалось бы дороже».
Один месяц полной загрузки одного сервера в случае облака обошелся бы мне в стоимость двух полноценных серверов за год — вот почему мне выгодней держать DS, и подозреваю, у многих небольших компаний или контрактников примерно аналогичная ситуация.
А также, в случае DS я точно знаю где и как используются его ресурсы, в случае облака я не могу быть уверен на 100% что получу свои vCPU и vRAM, нет гарантии что на хосте никто не тормозит мой инстанс, и т.д. — а если гарантии даются, то это уже сравнимо со стоимостью аналогичного DS (что логично), но поскольку это облако, то чаще всего оно ощутимо дороже аналогичного DS. В сравнении с вашими услугами, к примеру — всего два дня у вас в конфигурации моего DS стоят больше одного месяца (в 17(!) раз выше), не говоря уже про SLA на диски и сеть (очень мало). Если взять три DS чтобы обеспечить «bulletproof» HA/LB, они всё равно обойдутся в несколько раз дешевле чем конфигурация одного из них в вашем облаке.
Самое печальное, впрочем, не это — дело в том, что в случае DS, что в случае PaaA/IaaS, провайдер отвечает не более чем стоимостью времени простоя (в редких случаях это выше, но всё равно не выше 250%-500%) — то есть бремя затрат/потерь в случае проблем всё равно на клиенте, в то время как SLA для DS и облака (в пределах одного провайдера) редко отличаются.
Опишите, пожалуйста, характеристики каждого сервера. Не могу понять как у вас получилось в 17 раз дороже.
Количество MIPS на одно vCPU составляет не менее 2900, что гарантируется по SLA. Также не допускается «переподписка» физической оперативной памяти, RAM Swaped равен 0%. Это означает, что выделенная при создании виртуальной машины Configured Virtual RAM, которую будет видеть гостевая ОС, является 100% выделенной физической памятью, которая доступна виртуальной машине в любой момент времени.
в случае облака я не могу быть уверен на 100% что получу свои vCPU и vRAM, нет гарантии что на хосте никто не тормозит мой инстанс
Количество MIPS на одно vCPU составляет не менее 2900, что гарантируется по SLA. Также не допускается «переподписка» физической оперативной памяти, RAM Swaped равен 0%. Это означает, что выделенная при создании виртуальной машины Configured Virtual RAM, которую будет видеть гостевая ОС, является 100% выделенной физической памятью, которая доступна виртуальной машине в любой момент времени.
Я считал по этому: 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).
Получилось €26/день(!) или €780/мес — мой же DS стоит около €40/месяц.
К тому же, у вас «Free guaranteed unlimited channel 5 Mbps expandable to 1000 Mbps» — а у меня это гарантированный 1 Gbit/s (пусть и с траффиком — но он более чем достаточен, к тому же лишние терабайты стоят мелочи, или unlimit с 10 Mbit/s).
«сервер, довольно мощный, для хобби, экспериментов и иногда контрактых работ» = около €40/месяц
Облако:
1) Скидка: Соответствующая VM €550/мес
2) Использование 10% = €55/мес (включая 14 точек резервного копирования в другой географически удаленный ЦОД)
Всплески ограничены мощностью серверов. В облаке изменение мощности может потребовать перезагрузки VM, но тарификация почасовая.
N часов на 100% мощности + M часов на средней мощности + X часов простоя могут стоять меньше €40/месяц
Облако:
1) Скидка: Соответствующая VM €550/мес
2) Использование 10% = €55/мес (включая 14 точек резервного копирования в другой географически удаленный ЦОД)
Всплески ограничены мощностью серверов. В облаке изменение мощности может потребовать перезагрузки VM, но тарификация почасовая.
N часов на 100% мощности + M часов на средней мощности + X часов простоя могут стоять меньше €40/месяц
Пока это выглядит так, что вы рекомендуете мне платить примерно столько же, но за сервер который даст мне только 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 трогать не будет — ибо это невозможно сделать незаметно.
Проблема в том что потребности в ресурсах не всегда предсказуемы — я не знаю когда и насколько мне понадобятся все 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 трогать не будет — ибо это невозможно сделать незаметно.
На виртуалках диски тоже можно шифровать клиентским ключом. Или на уровне ОС. Если считать алгоритмы стойкими, то профита с клона диска органам никакого и разницы между DS и Cloud нет
К сожалению, в случае виртуалки всё намного печальней — host имеет полный доступ к памяти guest в любое время, совершенно необнаруживаемый, не говоря уже о возможности трейсинга.
Соответственно, имея доступ к памяти, можно легко получить все ключи шифрования, или, как пример, все сертификаты с приватными ключами — благо структуры данных в памяти известны.
В случае DS для этого придётся как минимум его отключить и загрузится со своей recovery system, но это невозможно сделать незаметно, да и просто любопытный это вряд ли сделает.
Соответственно, имея доступ к памяти, можно легко получить все ключи шифрования, или, как пример, все сертификаты с приватными ключами — благо структуры данных в памяти известны.
В случае DS для этого придётся как минимум его отключить и загрузится со своей recovery system, но это невозможно сделать незаметно, да и просто любопытный это вряд ли сделает.
SLA — это хорошо (знаю ЦОД, где мне прямо ответили про простой, что раз мы Tier-3, то больше положенных в год часов простоя не будет — и уже лет 7 обещание выполняют; не рекламы ради, но им я сейчас верю вполне), а как провайдер увидит реальные потери бизнеса за ту минуту, что в середине дня сервер был недоступен?
Надо идти не на дешевейшие сервера, а на средние, они все равно дешевле облака. Свои админы тоже недесплатны, но это компетенция в компании, а не у дяди.
Нужно спросить у заказчика. Если нужно, можно использовать катастрофоустойчивое решение (кластер из территориально распределенных ЦОДов с синхронным зеркалированием). Тогда 99,99% не потеряется ни одна транзакция. Эта услуга дороже, нужно сопоставить размер потерь и вложений в дополнительные 0,01-0,02%
Назовите хотя бы несколько примеров B2B услуг, где бы поставщик компенсировал убытки и упущенную выгоду?
Вообще в деловой среде принято страховать свои риски в специальных компаниях и за отдельные деньги (космические пуски). Если клиент не готов платить, значит это ему не нужно.
Почему в ИТ должно быть как-то по другому?
Не должно — но об этом-то и речь — ответственность провайдера в случае облака и DS практически одинакова, SLA такое же, только первое стоит дороже (даже с учетом 2-3х-кратного резервирования) чем второе (при эквивалентных параметрах).
Что и приводит к вопросу — зачем платить больше?
Что и приводит к вопросу — зачем платить больше?
Вы что в SLA включаете? Только Availability %?
Будет ли на ваших дедиках со стороны провайдера тот же RPO и RTO?
То что у вас кластер на прикладом уровне это уже ваша ЗО и далеко не во всех случаях корпоративный приклад можно заставить работать в такой схеме.
Будет ли на ваших дедиках со стороны провайдера тот же RPO и RTO?
То что у вас кластер на прикладом уровне это уже ваша ЗО и далеко не во всех случаях корпоративный приклад можно заставить работать в такой схеме.
Я что-то не встречал в SLA облачных провайдеров RPO и RTO — в конце концов, это сильно зависит от конкретного приложения, просто восстановление железа (виртуального или реального) или бэкапа не обязательно ведет к восстановлению сервиса, это в 99% случаев ЗО клиента.
В случае DS, есть SLA на RTO по железу, остальное уже ЗО клиента.
В случае DS, есть SLA на RTO по железу, остальное уже ЗО клиента.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как и почему 10 млрд долларов затрат на публичные облака являются неоправданными потерями