Комментарии 91
Извечный вопрос: облако или своё железо? На первый взгляд, облако кажется идеальным решением: ваши ресурсы в кластере, практически неуязвимы. Но, поверьте, контроль над своими ресурсами и прямой доступ для администрирования — это тоже серьёзный плюс.
Я остаюсь при мнении, что облако подходит для:
1. Маленьких компаний, у которых пока нет финансов на покупку целого сервера.
2. Гигантов, которые не считают расходы на IT и готовы оплачивать любые счета.
Но всем остальным стоит задуматься о собственном железе и колокейшене.
Например, у меня был опыт работы в компании с высоконагруженными приложениями. Мы подсчитали, что окупаемость нашей инфраструктуры всего ~7-8 месяцев, плюс колокейшен в Tier3 в 30 минутах от офиса.
По итогу оборудование взяли в лизинг — и всё было прекрасно. За год сломался только один жесткий диск (спас RAID5) и вентилятор в сервере Huawei.
Аналогично. Считали облако - свой сервер окупится менее чем за год.
Для гигантов облако тем более вредно. У них ресурсов хватает на собственный ЦОД, можно ещё и продавать, зачем им класть свои тестикулы в непонятно чью руку? Чувствительность к безопасности данных растёт вместе с размером компании. Прачечной нечего терять даже если все её данные выложат в Одноклассниках или если они просто грохнутся. А гиганту есть чего терять.
Предположу, что имеются в виду не около-ИТ гиганты. Например, производство продуктов питания. ИТ - не их вотчина, ИТ решения у них не формируют бизнес как таковой, при этом денег ОЧЕНЬ много. Держать армию дорогущих ИТшников просто лень и нет таких важных задач. А тем более ЦОД... Ну и увеличение основных средств, ниже ебида.
Вообще гиганты это как раз единственные, кому облако особо и не нужно, им содержать внутри как раз выгоднее.
Для мелких облако, мне кажется интересно в контексте SAAS и не просто ВМ. Потому что разворачивать и админинить приклад тоже нужны люди.
ну а нет если денег на сервер новый- покупаешь старый, прошлых поколений. Или обычный системник, делая кластер из 2 nvme дисков. ну в процессор современный даже в моём ноуте даёт хорошую фору двухпроцессорному серваку с ксеонами который стоит у меня в дальнем углу
А для гигантов- там облако своё. Приватном. с vmware директор, iass и прочим. Слишком критичную часть для бизнеса отдавать на аутсорс -ну такая идея. и в плане ИБ. И в плане риска контрагента. А ещё есть специфичные потребности. Который облачный провайдер предоставляющий унифицированные решения не всегда может учесть. А своя команда -может. Ей вы платите, что бы она подстраивалась под нужды ваши. А провайдеру интересно иметь универсальное решение для широкого круга клиентов
Кто то амазон хостился- общался я году в 21 с одной компанией, они искали спеца по миграции туда. Не знаю уж как они после санкций бегом возвращали всё из за рубежа и успели ли
Но есть ситуации когда эта игра стоит свеч. На одной из прошлых работе внешний сайт был исторически на хостинге. Возвращать мы не стали, не хотелось заморачиваться с сегментацией сети и выделением dmz.
Или пример получше- когда непонятен уровень нагрузки. Или она сильно носит нестабильный характер. Вы написали игру, запустили рекламу но не понимаете 100 пользователей придет или 100 000
А в целом- это вопрос не технический. Это вопрос выбора между ОПЕКС или Капекс. Дешевле купить своё (на свои средства, в кредит. используя лизинг) или арендовать чужое (с одной стороны отдав и часть проблем, но с другой - неся доп риски в т ч финансовые. Доллар скаканул в 2 раза -ваш сервер также работает, а цена за облака подросла).
В теории облачный провайдер может предоставлять услуги и дешевле. За счёт эффекта масштаба- как по содержанию, тех же админов виртуализации с автоматизацией. Так и с закупкой серверов с минимальной наценкой (ибо он очень крупный клиент). Но на практике, тут добавляется ещё и его интерес (прибыль он на вас зарабатывает), транзакционные издержки (ЗП его бухгалтеров, расходы на отдел маркетинга который убеждает вас что облако это выгодно и клиент менеджеров).
А ещё есть позиция ЛПР. У нас (в России) руководители, особенно старой закалки, часто любят под контролем у себя держать критичные элементы.
Своё железо прекрасно, но дело ведь не только в железе. Если мы считаем стоимость одного сервера, это принипиально неправильно.
Мы должны заложить туда и стоимость необходимых ресурсов для работы (аренда помещения и электроэнергия или колокейшн), стоимость квалифицированных спецов, стоимость компонентов и всего прочего.
Собственно и облако это не только Elastic Compute, да и как правило не на одном сервере, а бывает даже с тройным резерваированием. Если пересчитать всё, то уже не так выгодно и совсем не год
Всё так. но мы и не говорили об одном только железе в статье. Кокнертно в расчётах с конфигурациями серверов мы учли только железо, так как со всем остальным слишком много переменных и статья уже начала бы превращаться не то в доклад с аналитикой по рынку, не то в диссертацию/дипломную работу по экономике.
Как человек который непосредственно связан с физ. железом хочу сказать, что лучшее решение - это гибридная инфраструктура.
Если вы чувствуете, что выполнение вашей задачи в облаке обойдется в копеечку - берите сервак.
Если же задача легко выполняется VM 2 ядра 4 гига - смело берем виртуалку, сгенерированную в облаке с поминутной оплатой.
Нет смысла быть адаптером одной из сторон. Есть смысл получить лучшее от каждой.
Проверить реальную частоту процессора в облаке зачастую непросто. Команда lscpu может не отображать точную информацию. Вы можете увидеть что-то вроде:
Как видите, никаких 5 ГГц тут и близко нет. В итоге вы можете платить за ресурсы, не получая той производительности, на которую рассчитываете.
Так может реальная частота всё таки есть, а это lscpu неправильно всё отобразил? И как тогда это вообще верифицировать? KVM доступ к хосту на котором облако запущено вряд ли дадут, как и какой-либо другой мониторинг независимый от "подкручивания" площадкой. Да и такой доступ, это уже не облако выходит, а частный сервер.
Оптимальное решение часто лежит где-то посередине. Многие компании выбирают гибридный подход, комбинируя собственную инфраструктуру и облачные сервисы. Это позволяет получить преимущества обоих вариантов и минимизировать их недостатки.
Либо внезапно решают сами стать облачными провайдерами, по ощущениям за последние пару лет их особенно много появилось, как чисто-облачных, так и когда грубо говоря"DevOps-подразделение" какого-нибудь банка решает стать полуавтономным юридическим лицом и обслуживать как материнскую компанию, так и клиентов на публичном/частном облаке.
Либо внезапно решают сами стать облачными провайдерами, по ощущениям за последние пару лет их особенно много появилось, как чисто-облачных, так и когда грубо говоря"DevOps-подразделение" какого-нибудь банка решает стать полуавтономным юридическим лицом и обслуживать как материнскую компанию, так и клиентов на публичном/частном облаке.
Да, согласен, например история со сбером и клауд ру.
Наверное эти мысли могут навести на еще один вывод. Если вы овербольшая компания вам будет выгоднее открыть свое облако))) И помимо обеспечения стабильности собственной инфраструктуры еще и получать доход.
Для меня выгодно брать сервер с GPU с поминутной оплатой, так как на данном этапе проводятся исследования и нет нужды в постоянном использовании GPU. Но если нагрузка на GPU будет постоянной, то тут расчеты окупаемости нужно будет проводить заново.
Решения для своего личного сервера имхо гораздо более интересны и выгодны любой компании, облака интересны в случае "Тест драйва" например у селектела есть вариант на Ampere Altra. Купить их голову с кошельком сломаешь, а не факт, что ваше ПО будет адаптировано под АРМ), а адаптировать его нужно время. Тест драйв позволяет вынести полученный опыт эксплуатации и понять - нужен ли тебе действительно именно такой сервер или можно обойтись сервером проще/мощнее. Именно такую пользу облака я вижу сразу, если же у вас серьезный бизнес, то не вижу смысла не брать свой личный сервер, тем более что можно более гибко подобрать конфигурацию, развернуть ESXI на собственных накопителях и т.д. если мы говорим о данных, которые являются конфиденциальными и утечка может повлечь солидную сумму либо репутацию.
Интересная статья получилась, много даёт ответов на вопросы, особенно в сфере формирования прайса)
Что касается обычных виртуальных машин для программистов, то для меня дешевле всего поставить свой сервер и использовать там Proxmox. Старый сервер можно обновить, установив там диски SSD и добавив память.
При попытке просчитать аналогичные конфигурации в облаке получаю троекратное превышение стоимости владения по сравнению с собственным сервером.
Если речь идет о серверах для продакшена, то с учетом необходимости ремонта серверов для меня выгоднее арендовать физические серверы. Но при небольших нагрузках также можно обновить старые серверы.
Аренда облаков для продакшена также ведет к троекратному повышению затрат. Даже с учетом возможного масштабирования виртуалки в облаке дешевле получается просто взять физический сервер помощнее.
Есть компании, которые предлагают отказоустойчивые облака, при этом ресурсы находятся в разных дата-центрах и каналы связи тоже резервированные. При попытке предложить решение для интернет-магазина столкнулся со слишком высоким бюджетом. Пришлось предложить решение, основанное на аренде физических серверов в разных дата-центрах, соединенных отказоустойчивым каналом связи.
Реально помогло три раза в новогоднем пике продаж при выходе из строя мастер-сервера.
Старый сервер можно обновить, установив там диски SSD и добавив память.
Ну или на первое время брать БУ сервера фирменных брендов HPE / DELL и обычные серверные диски Кингстон / Самсунг. БУ скорее всего отработает еще года 3 если обслужить или было обслужено. А БУ может начинаться с 100 т.р за сервер.
Но со своим сервером не посчитана сетевка сети SAN схд под данные и хоть что-то под бекапы.
Сейчас минималка со своим БУ железом 3 сервера сетевкой 10G данные храним на общей сторе vSAN или аналоги и стора нетарр/нутаникс/самосбор под бекап думаю в районе 1 миллиона стоит. С дисками и шкафом комната с кондеем. Ну и можно считать облако. Но со своими серваками VM имеют свойство расти как грибы
НО главное это оплата труда того кто это все настроит и будет поддерживать. Я не говорю о лицензиях на софт.
Ну и взять облако. Имеем 85000 в месяц. Сколько на это можно купить ресурсов с учетом бекапа и прочего. ? Я бы еще рассмотрел именно аренду самого железного сервера.
Бу может и 10+ лет отработать :)
Дам комментарий как раз в качестве профильного специалиста по сборке бу серваков.
Сетевка 2x SFP+ Intel + пара трансиверов ~ 10 т.р.
схд под данные и хоть что-то под бекапы.
Тут же можно собрать JBOD полку на базе супермикровского корпуса(как без начинки, так можно и сделать ZFS хранилище если минимальную начинку интегрировать). Вопрос решаемый и по стоимости будет оптимально.
НО главное это оплата труда того кто это все настроит и будет поддерживать. Я не говорю о лицензиях на софт.
Тут вынужден согласиться. Часто сталкиваюсь с не самими опытными сис. админами, что затрудняет поддержку серверов. Ну и лицухи это отдельная боль в РФ.
Странно сравнивать задачи для рабочих станций (типа запуска 1С) с серверными и, тем более, облачными решениями. Причем тут стоимость одного (подержанного) сервера, когда смысл облаков в динамическом предоставлении сотен и тысяч распределенных хостов. Скажем, Cloudflare CDN обещает отклик менее 50мс для почти всех интернет пользователей в мире. Во что обойдется организовать аналогичную связность на собственном «железе»? А обеспечить нужный уровень доступности сервисов? Что касается цены, то для крупных компаний кастомный прайс, а китайские хостеры и для небольших компаний отличные условия предлагают (хотя, скажем, порядок сортировки в локали по умолчанию может очень удивить, есть и другие странности, но решаемые). Если уж говорить о серверах от хуавей, то логично их окупаемость считать по ценам от китайских хостеров (алибаба клауд), и тут совсем другие цифры для окупаемости получаются. Конечно, мало смысла офисную 1С хостить в Китае, а вот вычисления запускать все равно, где, тут важна производительность на доллар.
Вы считаете задачи по типу 1С - задачами для рабочих станций?
У нас пол страны работает на 1С и ее стабильность обеспечивает работу миллионов торговых точек. Поэтому я считаю, что 1С - строго серверная задача, которая не терпит проблемы с резервированием и т.д. Должна запускаться на серверных мощностях и гарантировать стабильную работу годами.
Конечно 1С нельзя сравнить с Cloudflare, уж очень громоздкий пример, понятно, что для работы Cloudflare нужны сотни тысяч серверов и затраты на такую инфраструктуру будут соразмерны бюджету некоторых стран.
Также не совсем понимаю ваши слова про Huawei. За эти годы Fusion Server стали полноценным конкурентом Supermicro, HPE и DELL. Да может менюшки слегка китайские, но по надежности вполне сопоставимо. Может какой Tyan или Insur надо сравнивать с китайскими хостерами, но никак не хуавей.
Вы серьезно эти «пол страны», работающих на 1С, предлагаете хостить на одном б/у сервере с админом, найденным по объявлению в «из рук в руки», как в статье описано? А если брать качественное оборудование, обеспечивать распределенную 24/7 работу и поддержку, то облако и получается.
Может какой Tyan или Insur надо сравнивать с китайскими хостерами, но никак не хуавей.
Алибаба клауд это китайский аналог амазон, а в вашем понимании китайские хостеры это какие-то подвальные конторы? Погуглите, прежде чем такую ерунду писать.
С чего вы взяли, что я решил половину страны посадить на один сервер? У половины страны есть свой парк серверов. У кого-то сервер один, а у кого-то целые группы, размещенные в различных ДЦ по всей стране для достижения лучшего аптайма. Кто-то не возится и сидит в облаке — и это тоже прекрасный выбор. Человек с облаком "решил" кучу проблем, которые стоят перед владельцем собственного железа. И, по факту, он платит за решение этих проблем и отсутствие "головной боли" с настройкой и отладкой.
Касательно китайских хостеров. С чего вы взяли, что я так считаю? Я же ни слова не написал про хостеров. Я уделил внимание Huawei и отметил, что этот бренд серверов уже перерос в высшую лигу и работает наравне с "западной" техникой. Я представляю масштабы Alibaba и четко даю себе отчет, что китайские мощности готовы дать фору многим европейским компаниям.
Скажем, Cloudflare CDN обещает отклик менее 50мс для почти всех интернет пользователей в мире.
А нужна ли мне потребность в этих всех пользователях мира? Какой товар/услугу вы собираетесь одновременно предложить такой ЦА?
А обеспечить нужный уровень доступности сервисов?
Если завтра в интернете отключить 75% сайтов, никто и не заметит, если продолжат работать банки/гуглы/ютубы. В то же время из-за "замедление" одного лишь дискорда хабр уже неделю полыхает. Но вы же не дискорд.
Большинству проектов никакх 5 девяток, которые успешно продают вам сейлзы клаудов, не нужны, вполне хватит и двух. Причем с другой стороны от запятой.
Я буквально сегодня ночью качал одну софтину, потестить/покрутить. Да, у них нет проблем с доступностью сайта, и скачалось все быстро, мое почтение. Правда с "Encountered an unexpected error" при ее запуске, это не особо помогает =( Лучше бы у них сайт лежал, я бы спать со спокойной душой пошел, а с утра бы продолжил, а не дебажил бы ее полночи без успешного успеха в результате.
Вот именно, высокий уровень надежности нужен не всем.
Когда предлагаешь клиентам увеличить надежность работы сайтов интернет-магазинов, оказывается что очень немногие согласны утроить абонентскую плату. А приходится, ведь вся надежность обеспечивается за счет горячего резервирования.
Логика понятна - если ожидание 1-2 дня не сильно скажется на прибыли, зачем платить больше. А если даже 5 минут простоя дают ощутимый ущерб - лучше использовать отказоустойчивое решение.
Всё никак не могу найти одну лекцию кажется от гугловских инженеров, с критикой Big Data.
Большей части сайтов/компаний нужен был накопитель от силы на 1тб(лекция 2022 кажется года была). И никакой Big Data, убер-сложными БДшками и СХДшками там и не пахнет, а хватает обычных Postgres/MySQL.
Вот как раз для гугл я делал проект по загрузке всей базы OpenStreetMap в BigQuery парсингом тематических слоев, с правильной индексацией, понижением детальности карты «на лету» для отображения на разных уровнях масштаба (встроенная фича платформы) и прочее. И вы всем пользователям этого (бесплатного, кстати) сервиса предложите что?.. Или другой проект, тоже для гугла, с загрузкой терабайтов растровых данных в BigQuery для запуска моделей машинного обучения - тут хранилища уже на петабайты нужны для регулярно обновляемых климатических моделей и прочего. Оба проекта у меня на гитхабе есть, можете сами попробовать. А еще есть радарные космоснимки, для обработки которых я пишу софт и тысячи пользователей и компаний его запускают - там на каждый запуск терабайты данных это обычное дело. Если же следовать вашей ущербной логике, то и космические ракеты не нужны, и компиляторы не нужны и так далее, ведь их создают и используют единицы, а «большинству» все это не нужно.
вы сравниваете теплое с мягким. 99.99% пользователям это все не нужно. у оставшихся да есть такие задачи требующих много ресурсов.
Большей части сайтов/компаний нужен был накопитель от силы на 1тб
не вижу противоречий в высказываниях вашего собеседника
Если же следовать вашей ущербной логике
Во-первых, следите за словами, прежде чем кидаться громкими обвинениями в сторону тех, кто с вами диалога и не начинал. Работая на гугл манерам и этикету в коммуникациях вас видимо не научили.
Вот как раз для гугл я делал проект по загрузке всей базы OpenStreetMap в BigQuery парсингом тематических слоев, с правильной индексацией, понижением детальности карты «на лету» для отображения на разных уровнях масштаба (встроенная фича платформы) и прочее. И вы всем пользователям этого (бесплатного, кстати) сервиса предложите что?..
А вы читали вообще что я написал или у вас просто зудело посамопиариться? Или те инженеры которые непосредственно в гугле работали и лекцию вели они менее гугловские и в отличие от вас, центра вселенной, их мнение не важно? Они речь вели о большинстве компаний и сайтов, где объёмы данных с натягом достигают 1 терабайта. А не вообще всех и конкретно гугловских, где Big Data по определению нужна из-за больших объёмов данных?
то и космические ракеты не нужны, и компиляторы не нужны и так далее, ведь их создают и используют единицы, а «большинству» все это не нужно.
Милое соломенное чучело, но я ничего подобного не утверждал, если вы хотите играть в игру приписывай собеседнику что угодно, что тебе взбредёт в голову, то в эту игру могут играть двое. Только вряд ли оно вам понравится.
Когда предлагаешь клиентам увеличить надежность работы сайтов интернет-магазинов, оказывается что очень немногие согласны утроить абонентскую плату.
Если вы не способны оценить задачи клиентов и предложить адекватное решение, то это не проблема технологий. Вы будете менеджеру тут рядом упомянутого гугл объяснять, как вам точно известно, что никому нафиг не нужна надежность и доступность, пользователи через денек-другой зайдут снова? Или зачем студенту для продажи открыток на сайте какие-то девятки надежности, вы ему так хотите как для гугла прайс выставить?
В статье же утверждается, что всем подойдет один б/у сервер с 1С, в том числе, видимо, НАСА для хранения петабайтов космоснимков (которые как раз амазоновские серверы используют, и им это выходит дешевле, чем свои датацентры содержать). Если вы не понимаете совсем, о чем идет речь, погуглите (пока гугл не последовал вашим советам и не ограничил доступность парой часов в день, да).
В статье же утверждается, что всем подойдет один б/у сервер с 1С, в том числе, видимо, НАСА для хранения петабайтов космоснимков
Этого не утверждается в статье, о чем вы говорите
Если вы не способны оценить задачи клиентов и предложить адекватное решение, то это не проблема технологий.
Что касается владельцев интернет-магазинов, то дело не в оценке задач и технологиях, а в бюджете. Бюджет владельца интернет-магазина определяется объемом продаж и прибылью.
Когда идет речь о выборе решения для отказоустойчивости, то оказывается, что любая отказоустойчивость требует избыточности и резервирования, а в критичных случаях - горячего резервирования.
Мой опыт показывает, что при минимальном бюджете достаточно отказоустойчивого RAID-массива и нормальной системы бекапов. Если, конечно, клиент согласен с тем, что восстановление из бекапа при полном выходе из строя сервера может занять 1-2 дня. При этом свой или арендованный сервер может работать без проблем годами.
Но если объемы продаж значительны, и в день оформляются сотни заказов, то лучше использовать горячее резервирование серверов или отказоустойчивые облака. При этом далеко не все облака обеспечивают отказоустойчивость на уровне выхода из строя дата-центров и каналов передачи данных.
Владельцы интернет-магазинов оценивают риски и возможные убытки от выхода из строя серверов, и сравнивают их с дополнительными затратами на создание "настоящей" отказоустойчивости.
Мой опыт показывает, что при минимальном бюджете достаточно отказоустойчивого RAID-массива и нормальной системы бекапов. Если, конечно, клиент согласен с тем, что восстановление из бекапа при полном выходе из строя сервера может занять 1-2 дня. При этом свой или арендованный сервер может работать без проблем годами.
Вот теперь все верно - когда при пункте в договоре о гарантированном времени отклика не более 4 секунд и среднем времени менее 1 секунды вы не пытаетесь один сервер (с рейдом или без него) предлагать. С другой стороны, в «облаке» задачи вашего уровня вообще на бесплатных тарифах решаются, и если вы не умеете - это не проблема технологии. Скажем, у меня на бесплатном тарифе Cloudflare порой терабайты данных выкачивают в сутки и запускаются до сотни тысяч облачных функций, что потребует достаточно дорогого тарифа на колокейшен собственных серверов (нагрузка очень не равномерная) или на их аренду, не говоря уже о стоимости этих серверов. Вы же при сотнях-тысячах запросов в сутки предлагаете заказчику за сервер платить? Да вы пират просто.
Что касается Cloudflare, то я не считаю возможным привязывать свой бизнес и бизнес своих клиентов к чужим платформам, которые могут вдруг стать недоступными или сильно подорожать. Даже если сейчас это бесплатно. Как говорят, если вы получаете что-то бесплатно, то товар - это вы.
Поэтому на своей платформе я использую свои или арендованные серверы, на которых работает свое же, а не чужое ПО.
Вопрос приоритетов.
В англоязчном твиттере DHH - создатель Ruby On Rails активно разгоняет тему ухода на собственные сервера и переоцененности облаков. Как подтверждение - счета получаются в десятки и сотни раз ниже.
Мне кажется раньше облака подразумевали обещание, что это будет дешевле чем собственный сервер за счет масштаба и покупки только того, что нужно, но теперь наоборот - берут деньги за каждый чих, у некоторых вендоров даже нет способа понять на какую сумму придет счет в конце месяца и нет ограничений по тратам.
Пусть сначала покажет, как этот собственный сервер на типовом канале выдержит DDOS, который и не заметит Cloudflare.
Речь шла про AWS.
Пусть AWS - НАСА перешли на амазоновскую инфраструктуру, чтобы хранить спутниковые данные, много петабайт, потому что это оказалось качественнее и дешевле собственных датацентров и уймы высокооплачиваемого персонала для них, плюс еще договариваться с провайдерами для получения адекватных тарифов на раздачу огромного трафика по всему миру и так далее. А вы почему так свято уверены, что «формошлепам» виднее, как надо хранить и обрабатывать спутниковые данные, к примеру?
Кто мешает поставить Cloudflare перед своим сервером?
Да.
Но вместе с тем - Cloudflare может внезапно захотеть много денег а вот потому что - https://habr.com/ru/companies/productivity_inside/articles/818533/
Всё зависит запросов, интернет-каналов и т.п.
У нас принципиально всё внутри, потому что интернет тонкий. Делать бэкапы терабайтной базы через 100 мегабит, не мешая при этом людям работать нет никакой возможности.
А сами сервера нам не то, чтобы особо мощные нужны. Да и живут они долгие годы, до сих пор в продакшне на 775 сервера - потому что устраивает.
В англоязчном твиттере DHH - создатель Ruby On Rails активно разгоняет тему ухода на собственные сервера
В современном мире стоимость собственно железа легко может быть менее 10%. А остальное собственно ПО. Я никогда не считал во сколько встанет своей облако на базе vSphere (vCenter + ESXi+NSX+VCD) чтобы была страничка как в облаке для своих пользователей. На те-же 10 серверов. Да можно сделать и на open source но там оплата труда штата специалистов которые развернут и будут все поддерживать в США думаю может легко уйти за 0,5 млн$. в год.
Ну и да как говориться каждая следующая 9 в надежность в 10 раз дороже предыдущей.
Хостить свои сервисы для теста можно и на десктопах на 32 ядерных AMD благо они поддерживают ECC память. А вот бизнес критичное приложение да тут можно и облако рассмотреть. Ну или нужно тебе нейросеть доучить а десктопной карты не хватает. Тут можно и в облаке инстанс купить
Как подтверждение - счета получаются в десятки и сотни раз ниже.
Ну да облака непрерывно дорожают. Инфляция и все дела. Ну и под облаками понимают Amazon и Google видимо. Хостеры средней руки кратно дешевле. Ну и ответственность не думаю что тот же Amazon настолько кратно надежнее как дороже факапы есть у всех.
Как я обычно спрашиваю сколько стоит час / день простоя вашего бизнеса ? И от этого считать облака свой сервер / колокейшен и прочее.
А так да Гибриды и прочее не надо уходить в крайности и все хостить в облаках. У многих контор найдется кладовка где можно приткнуть стойку. Таже кроссовая в БЦ часто можно поставить свою стойку с серваками.
В случае наших клиентов и коллег, в числе которых как те кто пользуются on-prem, гибридом, облаком, либо сами являются облачными провайдерами, условный vSphere и прочее проприетарное от VMware не вариант по причине санкций.
Западные коллеги, в силу того что VMware штормит на фоне покупки Broadcom, а также из финансовых соображений также, всё чаще смотрят в сторону OpenStack/Cloudstack/Proxmox и т.д. Но тут мы упираемся в то, что специалистов умеющих с ними работать меньше и соответственно они будут дороже. Однако, с учётом того что лицензии у VMware на ряд продуктов формируются по количеству ядер, а также в целом далеки от гуманных, даже так это окупается.
При выборе между облаком и особенно "б\у серверами с серверными SSD" есть большой слон в комнате с выключенным светом: надежность решения. Если правильно сравнивать "б\у серверы с серверными SSD" и облачные ВМ, требуется учитывать отказоустойчивую архитектуру: 2, а то и 3 сервера (для кворума кластера), отказоустойчивое хранение (в пределах стоек или гео). Т.е. то, уровень надежности, что обеспечивается облаком должен обеспечиваться несколькими "б\у серверами с серверными SSD" при расчётах окупаемости. Не говоря уже о ФОТ персонала, обслуживающего свои сервера и сетевую инфру.
Но я ни в коем случае не пытаюсь "продавать облака". Я хочу подсветить проблему, что для многих решений достаточно надежности "б\у сервера с серверными SSD" и для таких решений SLA облачных ВМ в виде пяти девяток не требуется. Мне очевидно, что чем дальше тем дешевле будут стоит облачные ресурсы, согласно законам роста рынка. Но сейчас гораздо большая надёжность облачных ВМ не может конкурировать по цене с дешевым решениями на внутренней инфре: нет таких дешевых решений в виде "ненадежных" облачных ВМ с условными SLA 98.0.
Всё так, но все эти проблемы становятся актуальны особенно для больших компаний, и отдельно стоит выделить, для больших IT-компаний.
Но далеко не весь малый и средний бизнес IT-специфичен, и даже для IT-бизнеса малого и среднего размера, инфраструктура часто оказывается весьма скромного размера и по большей части ограничивается личными рабочими машинами разработчиков.
Мне очевидно, что чем дальше тем дешевле будут стоит облачные ресурсы, согласно законам роста рынка.
Но пока что статистика что рынка в России, что США, что ЕС, что где-либо ещё говорит только о повышающихся ценах на тарифы облачных провайдеров и тарифы растут быстрее, чем растёт та же инфляция.
Не понимаю за что топит автор, и в статье и в комментариях одни противоречия.После слов, что JBOD полка является оптимальным решением и отдельный, но свой сервер чем-то там надежнее, остается сильно сомневаться в опыте и практике эксплуатации каких-либо серьезных инфраструктур. Поработайте хотя бы с инфраструктурой из 100 серверов в проде и под нагрузкой и сразу поймете как часто что-то ломается.Отдельный сервер может годами работать без проблем, а может сгореть сразу после покупки и по умолчанию надежным решением не является. А за JBOD полкой должен постоянно следить админ Linux с опытом замены в ней дисков.Даже если вы хотите надежности on-premise это встанет дороже, чем какой-то там сервер.Уже нужен кластер и отказоустойчивость по сети и по пути я системы хранения, а потом еще и бэкапы. Прошли времена, когда вам админ Вася за копейки готов круглосуточно сидеть в серверной и смотреть чтобы инфра из говна и палок работала.Наоборот многие компании перевозят свою инфраструктуру в облака, так как там хотя бы есть еще кадры, кто будет за этим смотреть и в конечном счете даже дешевле получается.А вы считаете не понятно что на потолке.Посчитайте бюджет на содержание инфраструктуры и персонала за год для облака и on-premise и тогда сразу все будет понятно. А облака еще за объем скидку дают.
Не понимаю за что топит автор, и в статье и в комментариях одни противоречия.
Потому что как мы и сказали в статье и в комментах, мы не топим за конкретный вариант, это не в наших интересах. Как поставщик железа мы поставляем его всем, как новоиспечённым облачным провайдерам, так и тем кто делает всё чисто под себя on-prem. И чисто объективно, нету универсальных решений, очём мы опять же написали. У всех разные вводные условия и разные конечные задачи.
> Поработайте хотя бы с инфраструктурой из 100 серверов в проде и под нагрузкой
Это не задача для малой и средней компании, особенно если они не из IT-сферы.
> Даже если вы хотите надежности on-premise это встанет дороже, чем какой-то там сервер.
Если у вас есть такие расчёты, то мы были бы рады, если бы вы ими поделились. Так как то что есть в интернете от западных коллег, коллег из России, и даннные наших клиентов, говорят об обратном.
> Посчитайте бюджет на содержание инфраструктуры и персонала за год для облака и on-premise и тогда сразу все будет понятно.
Это считали не раз и до нас, примеры уже приводили в комментах. После определённого момента Облако перестаёт быть выгодным даже для крупных игроков с почти безлимитными бюджетами. А также об этом говорит факт того что такие крупные игроки как Сбер, ВТБ, VK - не пользуются сторонними услугами, а приходят к тому чтобы самим становиться облачными провайдерами. В случае ВТБ ещё и Холдинг Т1 помимо их VTB Cloud, но первый стал самостоятельным.
Понятно что 100 сервером малой компании не нужно. Пример был приведен для того, чтобы показать как часто выходит из строя обычное оборудование, просто это можно увидеть на большой выборке, а когда у вас один или два сервера вы можете с этим не столкнуться и думать что они надежные и так везде и поэтому не нужна отказоустойчивость и даже бэкапы.Но это обычно до первой большой потери данных.Потом деньги находят.
А по поводу не выгодности облаков для больших компаний, все совсем наоборот, они очень выгодны, так как могут в любой момент удовлетворить любые потребности бизнеса в ресурсах и обеспечить нужную защиту и отказоустойчивость.За это большие компании готовы платить.А так же не надо содержать свой огромный штат для поддержки этой инфраструктуры.
А по поводу цен.К примеру.
VDC в облаке.
180 vCPU Xeon 6248
600 GB ram
8tb ssd
17tb hdd
бэкапы и интернет 200 мбит / с
8-9 тыс. рублей в сутки.
Чуть больше 3 млн р в год.
Чтобы on-premis такое собрать, при утилизации в 50% нужно минимум 2 двух сокетных сервера с такими процами + 1 сервер на отказоустойчивость + cхд + один или два свитча 10gb + серверная с нормальным охлаждением и питанием, думаю на старте 3 млн не хватит, а с учетом дальнейшего роста потребностей еще оборудование придется покупать, и опять же нужен ЗИП какой-то, диски, память, БП.
Плюс сюда еще ЗП админа добавляется.
Все зависит конечно от задач, для маленких контор наверное облака кажутся дороже, но скорее всего они какие-то затрату просто не учитывают, на безопасность, на бэкапы, на доступность.
Чуть больше 3 млн р в год.
Не забывайте, что должна быть резервная площадка. Ну или, как минимум, оффлайновый бэкап. Потому что первый вопрос после того, как всё настроили, должен заключаться в том - "а что будем делать, если потеряем доступ к облаку?"
И вот когда возникает вопрос регулярной выгрузки теребайтов из облака, выгода может казаться уже не такой выгодной. Потому надо всё обдумывать. Вообще, в интернет-канал очень часто всё упирается.
Есть еще один нюанс, критичность данных и их защита, если у вас свой офис, окруженный забором и овчарками, то в целом можно и на своем железе построить защищенную систему. Если вы арендуете в бизнес центре обычный офис на N помещений, то задача создать серверную, которая пройдет аттестацию уже становится не такой тривиальной и тут аттестованные облачные решения, скорей всего выиграют. Для средней конторы, у которой на сервере крутится 1С и все клиенты в локальной сети, может оказаться выгодней кластер из б/у серверов, если у сборщика руки прямые. Коллеги по приколу собрали резервный кластер на б/у Хеоn`ах и двупроцессорных китайских матерях, 2 года полет нормальный, но это скорее не тиражируемое решение, а просто фан, с железками повозится.
Всё так, лицензирование часто пьёт много крови и нервов, но через это нужно пройти только один раз. А судя по выборке наших клиентов, жёсткая аттестация для большей части бизнеса, не столь критична, впрочем, сделаем ещё поправку на то, что далеко не у всех у них IT-специфичный бизнес и инфраструктура используется по больше части в внутреннем контуре.
Физические сервера хороши, когда нагрузка постоянная и предсказуемая.
А если нагрузка подвержена всплескам (типа хабраэффекта), и если это не статический сайт, то только в облаке вы сможете поднять десятки инстансов по требованию в реальном времени.
Никто не запрещает создать кластерную инфраструктуру с резервными ресурсами с заделом под пиковые нагрузки.
Сервисы размещённые на облачных ресурсах точно также регулярно падают как от органических пиковых нагрузок, так и из-за искуственных будь то DDoS-атака или косяк задеплоенный в продакшен.
"создать ... с резервными ресурсами с заделом под пиковые нагрузки" - т.е. купить железо заведомо в несколько раз дороже (и между пиками оно месяцами будет молотить воздух) - где же это дешевле облаков?
"на облачных ресурсах точно так же регулярно падают ..." - так же регулярно, как на своем железе, извините? или Вы здесь пошутить изволили? )
Ваша статья состоит из двух частей. В начале просто пиар своего железа и обкладывание всем плохим облаков - выглядит как пропаганда со всеми ее приемами, не буду перечислять, там к каждой фразе можно придраться. Вторая часть - но уже без цифр и подробностей - о том, что все не так просто, что есть плюсы-минусы всегда и надо взвешивать, что гибридный подход очень популярен и эта золотая середина и есть золотая середина. Согласен с Вашими выводами и не согласен с первой частью.
Облако выгоднее на старте. А то купишь железо с запасом, вложишься - а проект не взлетел и железо не потребовалось. Потом продашь уже значительно дешевле, да еще и время потратишь.
У нас как-то раз купили GPU, заплатили кучу денег. А через некоторое время выяснилось, что нам надо переключаться на модели большего размера, которые та GPU уже не тянула. Деньги оказались потрачены зря.
Другая проблема. Планировался новый проект, под него приходится заказывать гораздо более мощное оборудование. .. и тут неожиданно проект отменили. Опять деньги зря пропали.
Третья проблема. Масштабирование это не только когда нагрузка резко растёт, иногда она и резко падает. Свое оборудование приходится покупать из расчёта на самую большую возможную нагрузку, то есть сильно переплачивать.
Мораль сей сказки: конечно, лучше иметь свое оборудование - оно окупится через несколько месяцев, но только если нагрузка хорошо предсказуема, и поэтому понятно, что покупать.
У всех облачных провайдеров еще и программы для стартапов есть, с бесплатными ресурсами на десятки и сотни тысяч долларов. А если стартап выживет и вырастет - то скидки за объемы и прочие предложения. А попробуйте у поставщиков за просто так на сотню-другую тысяч долларов физического оборудования на годик взять :)
У всех облачных провайдеров еще и программы для стартапов есть, с бесплатными ресурсами на десятки и сотни тысяч долларов. А если стартап выживет и вырастет - то скидки за объемы и прочие предложения.
То есть опять же облако как временное решение, так как потом бесплатные ресурсы в десятки и сотни тысяч долларов могут и часто спокойно превращаются в переплату в миллионы долларов в год.
А попробуйте у поставщиков за просто так на сотню-другую тысяч долларов физического оборудования на годик взять :)
Партнёрские соглашения на индивидуальной основе существует везде. А также никто не запрещает воспользовать не бесплатными, но сравнимыми с облаками по расценкам лизингом/кредитом/ипотекой.
По моим текущим оценкам и расчетам гибридное решение будет оптимальным. Тяжелые терабайтные БД будет выгоднее держать на своих серверах. А вот сотни небольших сайтов и приложений микросервисной инфраструктуры удобнее и выгоднее держать в облаке.
Сап, лично я считаю, что свое железо - это высший уровень безопасности .
Что является весомым плюсом, учитывая надежность отечественных облачных провайдеров
Про техническую часть выбора написали выше. Я же добавлю ещё, что не надо забывать и про разные фин модели работы компаний (да-да, те самые капексы и опексы)
Кому-то важнее наращивать капитализацию любой ценой, даже если аренда была бы дешевле. Кто-то всеми силами старается, чтобы на балансе ничего дороже степлера не числилось
Считал использование GPU (rtx3090) - своё окупается за несколько месяцев 🤷 Сервер до года.
"Облако" хороший выбор для микро и малого бизнеса. Не нужно тратиться на закуп оборудования и его настройку. Для среднего бизнеса и крупного бизнеса будет оптимальным co-location. Крупный бизнес может "использовать" облако для задач тестирования, а также для сглаживания пиковых нагрузок.
Во всех случаях "Облако" можно использовать для резервного копирования.
Мы начинали с размещения интернет-магазинов на обычном хостинге в Мастерхосте, и на тот момент это вполне себя окупало. Потом арендовали сервер, и купили еще свой. Свой сервер обходился дешевле, поэтому дальше мы купили еще несколько серверов.
Когда цены на серверы взлетели, оказалось более приемлемым арендовать физические серверы, а уже имеющиеся мы переделали для виртуалок разработчиков.
Облака используем для экспериментов с GPU, так как для других задач пока хватает своих виртуалок.
Что же касается резервного копирования, то у нас есть и свой сервер, и арендованный. Что выгоднее - надо считать в зависимости от объема данных.
В любом случае для правильного выбора оборудования и способа его использования необходимы расчеты рентабельности.
Производительный RAID-контроллер с модулем резервного копирования
Этто что за покемон?
Это всё отлично, но ... Статья однозначно относится только к внутренним сервисам бизнеса.
И эта тема не поднята ни в статье, ни в комментах, а именно:
Стоит выпустить какой-либо сервис наружу (неважно, это магазин, учебная LMS, любой иной сайт с формой обратной связи и даже личным кабинетом), т.е. такой сервис, который собирает персональные данные (ФИО, почта, телефон и т.д.) - вы автоматом попадаете под действие 152-ФЗ у нас или GDPR за бугром.
На собственной инфре закупить ПО, аппаратные средства защиты, и получить необходимый сертификат соответствия - встанет ещё не в одну сотню тысяч рублей и скорее всего в несколько месяцев времени подготовки бумажек.
А при нарушениях есть риск ещё и ответственность схлопотать.
Так вот подумайте - так ли вам необходимо нарушать закон, имея собственную инфру в угоду экономии?
Главная ошибка 10 из 10 людей, которые никогда плотно не касались вопросов инженерного обеспечения и "девяток" - сравнивать "свое" и "облачное" исключительно с позиции вычислительных ресурсов / ресурсов хранения...
Где затраты на физическое размещение? На кондиционирование? На обеспечение бесперебойного питания, включая дизель-генераторную установку (которой, к слову, требуется регулярное плановое обслуживание) и контракт на непрерывный подвоз топлива? На пожарку? Не забывайте, что в облаке все эти вопросы решает поставщик собственно решения, а у "себя" либо вы, либо кто-то из ваших коллег - а это то еще удовольствие , скажу я вам...
Да, если ваша компания не масштабов Сбера или Майл.ру, но хочется максимально свое, то лучше установить свои серверы в хороший дата-центр, где все эти вопросы решены. И даже можно нанять инженера и системного администратора для обслуживания этих серверов.
А крупные компании могут построить свое здание для дата-центра и сделать там все нужное, либо купить готовый дата-центр.
Я бы предпочёл железо, потому что это первым делом полный физический контроль и ощущение владения всеми данными, какие хранятся на железе. Если и размещать что в облаках, то только по минимуму, всякие морды для массовой доступности, и т.п. А критически важные данные и внутренние ресурсы хранить лучше у себя. Наличие железа в дополнение к облаку позволяет ещё делать свои личные резервные копии всего и вся независимо от провайдера (и что в случае чего можно взять и легко перейти к другому провайдеру или запустить у себя "дома" даже если первый возьмёт и внезапно унесёт все доверенные данные "в могилу").
Какой бы ни был провайдер облаков, ничто не защищает от того, что может случиться с самим провайдером (может взять и накрыться, или произойти какое-нибудь ЧП, например вспомните конфликт собственников МастерХоста, от куда я мигом сбежал, выкачав 27 гигабайт данных).
Если что-то делается для себя и своих без массового публичного доступа - только железо. Если предполагается массовый доступ, а ресуросв маловато, то вполне можно разместить морду и в облаке, но основную инфраструктуру и резервные копии держать у себя на железе. Морду и не жалко отдать облаку под нагрузку и под всевозможные попытки атаки, а внутренние ресурсы надёжно защищены на физическом уровне, если, конечно же, не пускать их в Интернет полноценно.
Я говорю с точки зрения чувства надёжности и безопасности и физического владения всеми данными. Облако - априори доверять свои данные сторонней компании, не зависимо от её репутации. Ничто не страхует от факта, что эта компания может либо улететь вникуда, либо нарушить сохранность и безопасность (и при этом никакие компенсации через суд не помогут спасти уже утраченные данные по вине провайдера. С другой стороны, и самому можно взять и потерять всё по глупости, но тут уже ситуация, что сам дурак, и "не чего валить на других").
Полностью поддерживаю. За примерно 30 лет работы уже повидал многое - пожары в дата-центрах, и переезды дата-центров, взломы и исчезновения облачных провайдеров, изменения цен в дата-центрах и в облаках. Если вам что-то по настоящему дорого, храните это на своих ресурсах и платите за все сами. Чтобы в случае чего можно было быстро перенести сервисы к другим провайдерам.
Обязательно настраивайте многоуровневый бекап, чтобы данные бекапа хранились в трех разных местах как минимум, и одно из них - у вас дома.
Что выгодней — свое железо или облако?