Как стать автором
Обновить

Колокейшен и непрерывность бизнес-процессов: безопасный удаленный доступ — залог успеха

Время на прочтение4 мин
Количество просмотров1.4K
Всего голосов 2: ↑2 и ↓0+2
Комментарии13

Комментарии 13

А что лучше, запушить лямбду в aws или тащить циски с блейдами в дата-центры?

Надо считать TCO всегда.

Если это херак-херак и в продакшн, а потом разбежались, то лямбды - ваш выбор.

Если вы собираетесь работать долго и развиваться , то onprem/colocation (с гибридом) - вариант к которому вы в конце обязательно придёте.

Циски/блейды/SAN/СХД покупают те, кто умеет хорошо считать большие заработанные деньги.

Интересно, а (условный) netflix - это херак-херак или на годы? Сколько цисок купил гугль, который умеет считать заработанные деньги?

Google живёт на своих серверах. И железа у них много. Как и Майкрософт, и Meta (ex.facebook).
Netflix подсел на Амазон в период взрывного роста, это было сложным, дорогим, но на тот момент правильным решением. Насколько я знаю, с такими объемами потребления у них очень эксклюзивные цены в AWS. Так что их пример нетипичен. И не факт, что в какой-то момент их доля рынка (и прибыли) не упадут быстро и критично, иначе зачем они в рынок онлайн игр позезли?

Есть и другой сценарий. Выросли и стали барыжить своим облаком. От Алибабы до яндекса/мэйл.ру.

Я ж специально сказал цисок. Не покупает гугль ни вендоровых СХД, ни цисок. Потому что умеет считать деньги.

Для многих "циска" синоним брендового дорогого сетевого железа. Хотя они и не только сетевое железо выпускают.
Ответ был больше про "земля, своё" vs "облако, аренда"

Облака достаточно взрослые, чтобы выбор был на уровне capex/opex. Рассказывать что "своя циска" полезнее, чем глобальный cdn от гугла/aws/ibm - мягко говоря, недальновидно.

Разумеется, есть куча контор, у которых уже есть груда купленного железа, но с каждым годом эта груда всё более "востребована" (6-тонник от циски, который не может full view всосать? 4-сокетный сервер с производительностью в 1/10 от m1?), а дальше вопрос возвращается к capex/opex.

Я ровно о том же и написал. Считаем TCO и идём в гибрид.

Облака only - временное решение.

Про кучу устаревающего железа, кстати, миф. Я как раз занимаюсь расчетами TCO инфраструктуры, и у меня закладывается и рост и плановое обновление железа, у когорого заканчивается срок поддержки. На 5 лет при плавном прогнозируемом росте своё практически всегда выходит дешевле. А если надо "занять" ресурсов - то да, пара облачных провайдеров всегда законтрактовано.

А вы 24/7 on-site включаете в стоимость?

Т.е. в моём представлении, colo на своём железе выглядит так:

  • Железо, аммортизация

  • cold spare, аммортизация

  • colo (электричество, место, коннективити)

  • Сотрудники on-site

И вот это "on-site" на самом деле едва ли не самая дорогая статья. У провайдера эти расходы размазываются по большому числу клиентов, а у "своего colo" - это очень дорого. Особенно, если мы говорим про геораспределённость.

Вы не поверите, но да.

Солярка, аутсорс по договорам на ДГУ, кондиционирование, каналы связи, ФОТ, дежурства, подписки , лицензии, дублирование всего и вся. Обеспечение disaster recovery планов и прочих обязательных накладных расходов...

Начиная с некоторого масштаба, по моим прикидкам где-то от 10-15 стоек оборудования в своих мини ЦОД, облачным сказочникам очень тяжело становится что-то вкусное и выгодное предлагать.

Понятно, что CDN мне свой даром не сдался, этот сервис проще арендовать, как и ряд других вещей. Но...

TCO при заданном SLA решает всё достаточно однозначно. И чем больше масштаб, тем виднее необходимость всегда считать.

Ну, солярка в 2021 - это весьма специальная дисциплина, но в целом, между "облаками" и "своё железо" есть ещё банальный dedicated. С учётом, что при наличии нескольких поставщиков появляется свобода балансировать (low-impact CI - в хецнер, mission critical в условный equinox), то "свой ДЦ" (или "свой colo") становится реально странным.

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

Согласен. Colocation снимает кучу головняка, но и добавляет тоже...

А вот с дедиками вопрос однозначно в финансовой плоскости. Чужое в аренде при больших объемах редко когда будет дешевле, чем купленное своими силами. Если речь не идет о едниницах юнитов, конечно. Тут за счет объемов закупки и эффекта масштаба у провайдера могут быть и хорошие варианты.

Надо понимать, что и в ценах dedicated, если есть твёрдый коммитмент, то цены делаются соответствующими. Ключевые аспекты расходов, на самом деле, это операционные. Если вы строите свои ДЦ (в количестве нескольких штук), то свой ДЦ может быть оправдан (хотя и конкурирует по cost of ownership с лучшими на рынке), если речь про некоторое количество стоек... Чем больше pipe (как у операторов - become a pipe) вы отдаёте поставщику, тем меньше вам нужно концентрировать компетенций в компании.

Волшебный скилл заменить процессор не погнув ножки? Не нужен. Скилл отличить U.2 от M.2? Не нужен. Знание как правильно втыкать multipath топологию у scsi? Не нужен? Магия прошивки биосов и bmc? Не нужна.

Т.е. чем большее commodity спихивается на поставщика, тем меньше непрофильных расходов у компании и тем меньше шанс ошибиться.

Что вызывает оправданное возмущение у целого отдела экспертов по втыканию scsi и нежной смене процессоров - job security в опасности.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий