Свой сервер или публичное облако?
Когда я в очередной раз готовил для руководства аналитическую записку о нюансах перехода в публичное облако, то обратил внимание, что большая часть статей об облаках (даже на Хабре) написана теми, кто их продаёт (хотя это общем-то логично). Поэтому я решил немного свою записку доработать до более общей картины и выложить сюда. Таким образом, это рассуждение о целесообразности использования публичных облаков уже не с позиции тех, кто облака продаёт, а с позиции тех, кто их использует. Сразу предупрежу, что я не буду делать никаких однозначных выводов (или упоминать бренды).
Ситуации с облаками бывают разными. Например, в одной компании, далёкой от ИТ, несколько лет назад, я с большим трудом убеждал директора вывести пару сервисов в публичное облако, так как содержание штата квалифицированных серверных администраторов только ради сопровождения этих виртуалок никогда не окупилось бы, а эникейщики, обслуживающие персоналки, не совсем подходят для таких задач. Тогда меня не послушали, но затем жизнь безжалостно доказала мою правоту: на имеющийся бюджет толкового специалиста взять не смогли, железа не купили и в итоге это всё крепко прилегло, после чего сервера таки переехали в облако. В другом случае очень крупный оператор связи настойчиво хотел 500 виртуальных машин нашей (уже другой) компании перенести к себе. С парадоксально низкой арендной платой. И тут я уже придерживался прямо противоположной, антиоблачной, позиции. Ведь публичные облака — это отличный инструмент, но, к сожалению, не серебряная пуля. Почему — попробую раскрыть свою точку зрения под катом.
Облаком сейчас называют всё подряд, поэтому давайте сразу определимся с терминами. Облако — это модель обеспечения доступа по требованию к некоторому общему фонду конфигурируемых вычислительных ресурсов (сокращённое под наш контекст определение из Википедии[1]). По облачной модели могут предоставляться разные услуги: VPS/VDP (Virtual Private/Dedicated Server — аренда виртуальных машин), VDI (Virtual Desktop Infrastructure — аренда виртуальных рабочих мест), уже банальный и немного вымирающий хостинг веб-приложений, SaaS (Software as a Service — аренда приложений), IaaS (Infrastructure as a Service — аренда инфраструктуры), DaaS (Desktop as a Service — другое маркетинговое название VDI), BaaS (Backup as a Service — аренда инфраструктуры для резервного копирования) — и ещё вагон и маленькая тележка всяких »…aaS», которые только может придумать маркетолог. По сути всё это многообразие сводится к аренде виртуальных машин с теми или иными нюансами доступа и установленного ПО.
Облака бывают частными (функционирующими внутри компании для решения её задач) и публичными (функционирующими для широкого круга лиц на базе оператора). Далее речь пойдёт именно о публичных облаках, которые для простоты я буду называть просто облаками. С позиции рассматриваемых вопросов не так важно, представлены собственные вычислительные ресурсы компании: частным облаком или классические серверами под отдельные задачи. Поэтому совокупность собственных вычислительных ресурсов компании я буду называть локальными серверами или просто серверами, не вдаваясь в особенности организации вычислительного процесса. Таким образом, обещанное сравнение будет производиться между арендой вычислительных ресурсов («облаками») и собственными силами («идеями чучхе«серверами»). Оно базируется на моём личном опыте и опыте общения с коллегами. Конечно я не претендую на всесторонний независимый обзор, по-этому приглашаю всех несогласных обязательно высказаться в комментариях. Возможно это позволит найти ошибки или дополнить сравнение.
Итак, сравним, два описанных подходов по ряду критериев. Для тех, кому лень читать весь текст, я в каждом пункте курсивом выделил итог, поэтому вы сможете пропустить то, что вам и так очевидно и не читать всё.
Сравнение облака и собственных серверов
Стоимость
Часто можно встретить утверждение о том, что облака позволяют экономить на ИТ. Это действительно бывает так, но не всегда. Чтобы получить выгоду от облачного размещения необходимо понимать механизм её образования: ведь чудес не бывает, особенно в экономике. Если вы не только снижаете свои затраты, но и даёте заработать на хлеб с маслом посреднику между вами и железом (оператору облака), то это можно объяснить так.
- Снижение доли условно-постоянных затрат. В затратах на вычислительный процесс есть составляющие, которые слабо зависят от количества работающих серверов — условно-постоянные затраты (объектовая и информационная безопасность, аренда помещений, количество администраторов и т.д.). И те, которые сильно зависят от объёма вычислений — переменные затраты[2] (диски, процессоры, электроэнергия, подписка на ПО и т.д.). Конечно, все названные параметры зависят от объёма вычислений. Но если у вас есть серверная 18 м2 с администратором, вахтёром и кондиционером производительностью в десяток киловатт холода (который надо регулярно обслуживать вне зависимости от нагрузки) то она будет отнимать у вас одинаковое количество ресурсов и при двух работающих в ней ядрах и при двух сотнях (стоимость же самих ядер и потреблённой ими энергии будет линейно зависеть от их количества). Поэтому во втором случае суммарные затраты в расчёте на одно работающее ядро будут драматически ниже. У профессиональных облачных операторов условно-постоянные затраты эффективно размазываются между клиентами и чем больше клиентов — тем эффективнее.
- Переподписка ресурсов. Замечательное свойство систем виртуализации — перераспределение простаивающих ресурсов. Например, если у вас есть два ядра, то вы можете дать их сразу двум виртуальным машинам, но только при условии, что они не будут использовать их одновременно. Ваши виртуальные машины будут уверены, что у них есть 4 ядра на двоих! Конечно, для двух машин нельзя гарантировать, что ресурсы не понадобятся им одновременно. Но чем больше таких машин и общего ресурса между ними будет, тем, в силу законов больших чисел, меньше вероятность коллизии при использовании общего ресурса. Я сам имел дело с облаком на несколько сотен ядер, в котором переподписка по ЦП составляла 3 (виртуальным машинам было выдано в три раза больше серверов, чем было по факту). И всё прекрасно работало. Допускаю, что в крупных облаках переподписка может быть выше. Переподписывтаь оперативную память и диск опаснее и сложнее, но тоже вполне возможно. Многие облачные операторы позволяют вам оплачивать только то время, в течении которого ваша машина работала, с точностью до минуты или часа. Оплата так же может увеличиваться при интенсивной работе машины и снижаться в моменты покоя. Когда ваши вычисления простаивают, оператор облака загружает железо задачами другого клиента. Использовать такой эффект в рамках собственных систем виртуализации может только крупная компания с очень разнообразными бизнес-процессами и информационными си-стемами.
- Скидки на оборудование и ПО от производителей. Здесь я просто ограничусь отсылкой к известному тезису «оптом дешевле», который используют любители совместных закупок. Производители железа и ПО готовы давать операторам облаков, которые берут их продукцию сотнями и тысячами штук большую скидку, нежели розничным клиентам. Вполне естественно, что сервер условного HPE для ООО «Рога и копыта» обходится дороже, чем для Мегателекома или какого-нибудь другого гиганта.
Итого: экономия при использовании облака зависит от объёмов. Чем меньше ваша потребность в вычислительных ресурсах, тем выгоднее их арендовать. Недаром крупные игроки ИТ-рынка строят собственные ЦОД.
Но не только прямые затраты должны учитываться при обосновании технического решения. Финансовая оценка рисков (например, нарушение доступности сервиса) и дополнительные затраты (например, на полное резервное копирование вне облака) могут всё изменить, даже если изначально облако казалось выгодным решением. Эти нюансы будут описаны далее.
Гибкость
Рассуждения о стоимости выше были справедливы для долгосрочного размещения серверов. Но бывает и такое, что мощности нужны разово, на короткий срок: под какое-нибудь мероприятие, научную работу и т.д. В качестве крупных примеров можно привести олимпиаду, чемпионат мира, универсиаду или массовую дистанционную работу во время пандемии нового вируса («shit happens»). Поэтому даже если вам нужно большое количество серверов и инфраструктуры, но на коротки срок, после которого они станут бесполезны, то приобретение собственных ресурсов и строительство инженерных систем вряд ли окупится (и ещё не факт, что вы успеете это сделать). Тут проще арендовать.
Для небольшого мероприятия потребность в ресурсах, значительная для вас, может оказаться для оператора статистической погрешностью.
Для крупных проектов не у каждого облачного оператора хватит эластичности, чтобы по первому вашему требованию предоставить 100500 виртуальных машин. Но даже в этом случае, ко-гда оператор будет планировать их приобретение то в модели окупаемости он переложит на ваш проект только часть затрат, рассчитывая на последующую сдачу в аренду этих ресурсов другими клиентам.
Итого: для срочных и разовых мероприятий хорошо подходит аренда вычислительных мощностей. Облака более гибки к потребностям. И это вопрос не только цены, но и сроков: у оператора уже есть квалифицированный персонал, планы масштабирования и опыт, которые быстро не купить даже за большие деньги.
CapEx vs. OpEx
Бизнес очень любит конвертировать капитальные затраты (CapEx) в операционные (OpEx). Особенно это любят всякие финансовые директора, которые оторваны от «физики» процесса. Им предпочтительнее регулярно платить маленькими порциями, даже если есть переплата, чем купить какой-то ресурс разом и потом долго его амортизировать. Т.е. этим людям сервер арендовать выгод-нее, чем его покупать. И тут зёрна продавцов облаков падают на благодатную почву. Экономист с радостью отправит свою компанию в облако, даже не смотря на инфаркт директора по ИТ или руководителя подразделения, ответственного за безопасность.
Но всё неожиданно меняется, когда речь заходит о государственных или полугосударственных компаниях. В большинстве случаев они наоборот предпочитают CapEx операционным затратам. Причём происходит это вовсе не из желания сэкономить, а из особенностей планирования. За-дача часто ставится так: «Что бы нам сейчас такого купить, чтобы потом долго использовать, когда денег не будет?». По крайней мере так происходит в российском образовании, здравоохранении, науке и т.д. Им периодически подкидывают программы развития, повышения конкурентоспособности, модернизации, цифровизации и т.п. То, что купленное дорогостоящее оборудование имеет конечный срок рекомендуемой работы (а не «пока не сломается»), а также то, что оно нуждается в не бесплатном сопровождении, ремонте, ЗИП и т.д. (при очень грубой оценке закладывают 10–15% стоимости оборудования на каждый год эксплуатации) обычно не учитывается. Но это тема отдельного разговора.
Итого: облако лучше подходит тем, кто предпочитает OpEx, а собственная инфраструктура — любителям CapEx. Но это только с точки зрения финансовой стратегии, а не с точки зрения «дороже — дешевле», которую мы уже рассмотрели выше.
Доступность
Почему-то в среде руководителей часто встречается мнение о том, что облака обладают исключительной доступностью: «вот отдадим на аутсорсинг профессионалам и будет с кого спросить (да и не зачем — у них всё и так работает)».
Но проблема в том, что падают все. Вообще все. И профессионалы, и любители. Кто-то реже, кто-то чаще. Но рано или поздно — все. Падали Гугл, Яндекс, Амазон. Здесь скорее важно, как устраняются последствия таких падений. И то, сможете ли вы сами предпринять что-то в экстренной ситуации или будете ждать милости провайдера (т.е. есть ли у вас бэкап и запасные мощности). Вот, например, в 2011 году 1С-Битрикс упал в облаке от Амазона: https://habr.com/ru/company/bitrix/blog/125932/ (в статье хорошие выводы, кстати);, а вот в 2018 Битрикс24 три дня (!) лежал в облаке КорпСофт https://habr.com/ru/post/349018/. Причём в последнем случае, со слов пострадавших, они заказывали услуги размещения в двух якобы независимых ЦОД одного оператора, но…упали оба одновременно. Поэтому для особо критичных систем лучше использовать не просто разные датацентры, а датацетны разных операторов.
Причиной отказа датацентра может быть не только техническая неисправность. Встречаются ещё юридические проблемы. Так, например, недавно активы делили владельцы Айхора (https://vc.ru/services/97845-hosting-provayder-ayhor-zahvachen-servery-otklyucheny-v-dc-nikogo-ne-puskayut) и Мастерхоста (https://habr.com/ru/news/t/491450/). Вылились эти разборки в неожиданное отключение машин клиентов. Очень неприятно. И это ещё один повод использовать разных опера-торов облаков при резервировании.
Ещё не мало жару с доступностью облаков добавил Роскомнадзор, когда в 2018 г. начал квадратно-гнездовым способом блокировать рандомные адреса иностранных и даже российских площадок в борьбе против телеграмма. Тут даже ссылок давать не будут — все и так знают.
Из-за множества рисков некоторые компании содержат реплики своих ресурсов у разных операторов в разных странах (в основном на рынки которых ориентирована их деятельность). Но это всё сказывается на стоимости облаков.
Примеры, которые я привёл, это, конечно, заметные случаи (и далеко не все), а более мелких падений сотни и даже тысячи (пользуясь случаем, передаю привет Михаилу Климареву, владельцу канала ЗаТелеком, в котором есть интересная рубрика #ХЕРАКС).
Итого: слухи о надёжности облаков сильно преувеличены. Они страдают не только от технических сбоев, но и из-за действий собственников, властей и даже других арендаторов (есть облака с токсичной репутацией, которые блокируются межсетевыми экранами и антивирусами). Если доступность сервисов для вас критична, то при использовании облака у вас должен быть план экстренного «приземления» ресурсов на собственные мощности или к другому оператору (хотя бы в сокращённом виде).
Сетевая нагрузка
При планировании переезда в облако этот фактор иногда недооценивают. Нельзя забывать про эти процессы:
- снятие резервной копии вне облака (все облака предлагают бэкап на своих мощностях, но если вам дороги данные — вы должны хранить их где-то вовне; просто вспомните обесточенный ЦОД Айхора);
- репликацию между площадками, если когда-то вы решите развернуть зеркало в другом облаке или локально;
- если вы переводите в облако рабочие места сотрудников организации или другие ёмкие процессы, то вам надо позаботиться о хороших и более надёжных каналах уже не в облаке, а в своём офисе (одно дело, когда у вас в офисе просто пропал Интернет и другое, когда пропал даже рабочий стол).
Итого: при оценке стоимости облаков не забывайте про затраты на производительную и надёжную сеть. Это может существенно повлиять на итоговую стоимость решения.
Контроль над данными
Перенос данных из одного облака в другое затруднён.
Во-первых, из-за ограниченности пропускной способности сети, о которой мы поговорили (представьте, что вам резко понадобилось забрать пару-тройку Тб в актуальном состоянии, да ещё и сделать это «на лету», т.е. не останавливая работу виртуальной машины).
Во-вторых, из-за отсутствия универсальных инструментов. Владельцы облаков не заинтересованы, чтобы вы уносили у них виртуальные машины и плохо работают в этом направлении.
В-третьих, если облако «упало», то у вас уже и нет инструментов для изъятия данных. В своём ЦОД, в конце концов, вы можете вытащить диски даже из нерабочего оборудования. В облаке такой фокус не пройдёт. И тут мы снова возвращаемся к репликам и бэкапам, сделанным заблаговременно.
Но есть и обратная сторона медали. Некоторые владельцы данных их блокировки или кражи боятся больше, чем утраты. Сейчас не будем вдаваться в подробности, в каких случаях это необходимо, но, я думаю, многие ИТ-специалисты сталкивались с такими задачами в своей практике. В этом случае заказчики наоборот заинтересованы в том, чтобы облако располагалось где-нибудь подальше офиса, желательно в другой стране.
Действительно, случается, что в офис приходят люди в масках и опечатывают ЦОД или вы-носят серверы. Облачные данные, в другой юрисдикции, это, скорее всего, не затронет. И в случае такого форс-мажора хотя бы онлайн часть бизнеса сможет продолжить свою работу. Или, как минимум, данные не «утекут».
Теоретически возможна и ситуация, когда наоборот — захваченным окажутся данные и «железо» в удалённом датацентре. Но тут всё зависит от характера вашей деятельности и того, кто ваши враги (или чей враг вы).
Итого: если вы боитесь физического изъятия или блокировки данных, то удалённое облако — вам поможет. Но оно же может стать проблемой, при проблемах с его доступностью.
Финансовая безопасность
Выше было сказано, что вытащить данные из облака не так-то просто. Особенно если речь идёт о переезде на ПМЖ сложных систем с множеством взаимосвязей. Для крупных компаний смена облака — это целая история, которая может затянуться на годы. Оператор облака понимает это, поэтому действует со своими клиентами подобно дилеру, подсаживающему на свой «товар». Сначала бесплатно, потом индивидуальные скидки, а потом можно и поднять цены.
В конце 2019 года приключилась неприятная история: РосНИИРОС продал почти 490 тыс. своих «белых» IP-адресов, которые сдавал в аренду организациям образования, науки и др., чешской компании Reliable Communications. Первое, что сделал новый владелец — поднял цены на аренду этих адресов в 10–12 раз. А просто потому, что может (и потому, что РосНИИРОС держал своих абонентов на ценах «ниже рынка»). Но потом прокуратура возбудилась, хотя и не на рост цен, а на другие аспекты сделки. И сделку отыграли назад [3]. Цены вернулись к прежнему уровню, но осадочек остался.
Этот пример мало касается облачного рынка, но на нём возможна подобная ситуация. Представьте, что у вас крупный ИТ-бизнес и какой-нибудь жёлтый оператор делает вам предложение: ввиду вашего исключительного размера и положения на рынке получите скидку в 80% и пользуйте наше облако. Вы соглашаетесь и переезжаете. Пару лет всё хорошо, финансисты счастливы, вы продаёте уже своим клиентам дешёвые услуги и совсем было привыкли к цене…как жёлтый оператор начинает испытывать проблемы из-за своей непродуманной тарифной политики, «режет косты», объявляет облако непрофильным активом и продаёт его синему оператору. Новый владелец облака рассказывает вам, как он ценит старого клиента, но всё-таки будьте добры и заплатите по рынку. И тут ваши расходы резко увеличиваются в пять раз. По-моему, вполне реальный сценарий, хоть он ещё и не имел места в жизни. И даже если у вас был хитрый договор, ограничивавший рост стоимости, скорее всего найдётся способ его просто расторгнуть.
В конце концов вы не застрахованы от того, что оператор облака просто не заложил в свои тарифы развитие, а потом столкнулся с необходимостью больших вложений и поднимет цены (или попросту закроется). Это бывает, когда менеджеры живут одним днём и минутными KPI.
Итого: будьте осторожны со скидками и специальными предложениями на облака. Они при-ходят и уходят, а инфраструктура — это надолго. Вы всегда должны быть готовы выдержать рыночные цены.
Требования к персоналу
Когда вы содержите небольшой парк собственных серверов (например, пара-тройка производительных серверов и СХД) можете столкнуться с кадровой проблемой. Вам просто негде будет взять персонал соответствующей квалификации для грамотного обслуживания железа, среды виртуализации и бэкапа. И проблема не только в деньгах. Отрасль серверного администрирования меняется очень стремительно. Поэтому человеку с хорошей квалификацией будет просто скучно, и он будет постепенно деградировать на таком малом поле деятельности («оверквалифайд», как говорят кадровики), а человек, которого вы возьмете «для роста» может быстро вас покинуть (или наоборот слишком надолго задержаться, особо не совершенствуясь). Кроме того, один администратор — это всегда точка отказа. Необходимо минимум 2–3 человека, которые могут страховать друг друга в отпусках и на больничных.
В таких случаях выручает аутсорсинг администраторов, расширенный договор на администрирование серверов или публичное облако, которое мы обсуждаем.
Для небольших проектов облачное развёртывание машин, снятие бэкапов и т.д. будет занимать пару кликов (вот прям реально разгружает) и позволит вам сэкономить на персонале. Но сложных проектов взаимодействие нескольких облаков с репликацией и мониторингом может наоборот потребовать большего числа людей уже совсем другой квалификации.
Итого: облака для вас актуальны, если объём сопровождения не позволяет содержать хотя бы небольшой отдел администраторов «железа» с более-менее равномерной нагрузкой. В этом случае вы сможете сэкономить на персонале. Но переход в облако для крупных проектов не обязательно приведёт к сокращению штата и даже наоборот может его увеличить.
Соблюдение SLA
Service Level Agreement, оно же SLA, оно же соглашение о качестве услуг не всегда можно проверить. Вы не можете себе позволить постоянно гонять бенчмарки, а простое наблюдение за показателями виртуальной машины не всегда может указать на проблемы. Оператор умышленно или по недосмотру может ограничивать скорость чтения, предоставляемую квоту CPU, пропускную способность сети и так далее.
Кроме того, вы не можете заранее проверить обещания провайдера о независимости площадок (см. случай Битрикс24 выше) и времени устранения типовых неисправностей. Тут только ваше доверие, которое является не самой надёжной штукой. Оператор же наоборот, зная о невысоких вероятностях действительно крупных аварий, может годами не вкладывать в резервирование и экономить на технике и людях, живя сегодняшним днём. Конечно, так поступают только очень плохие и жадные люди. Но они существуют.
Итого: облачное SLA может не соответствовать ожиданиям/договорённостям из-за скрытой экономии со стороны оператора. Доказать это может быть сложно или невозможно.
Требования законодательства
Как говорится,»Dura Lex, Sed Lex»: многие государства предъявляют требования по обязательно защите информации (персональных данных, банковской тайны и т.д.). Соблюдение национальных требований лучше всего (а иногда только лишь и возможно) выполнять в национальном облаке или в собственном ЦОД. Например, проблематично обрабатывать данные граждан РФ в облаке Amazon. Как минимум их копия должна находиться на отечественных серверах.
Ещё бывает, что современный Lex в области ИБ бывает слишком Dura, при этом ещё и невыполнимым (примеры приводить не буду, чтобы не порождать лишней дискуссии о выполнимости тех или иных мер знаменитого пакета). Тогда лучше покупать облачную услугу у оператора, который готов взять все риски на себя. Фактически он выступает «крышей» (некоторые крупные операторы хорошо дружат с контролирующими органами, по-этому легко берут на себя подобные обязательства и услуги). Но может получится, что безопасность облака есть только на бумаге или только от специфических угроз (опять же см. историю Битрикс24, где компания выбирала хостинг под требования регулятора).
Итого: выбор облака для соблюдения требований закона в области ИБ — дело очень тонкое. Но по крайней мере выбор облака, берущего на себя защиту информации, снимает с вас если не технические, то хотя бы юридические риски.
Использование имеющихся ресурсов
Некоторые инженерные и научные системы очень-очень плохо переживают перенос в облако. Либо по соображениям безопасности (охранная сигнализация, система контроля и управления доступом — СКУД, автоматизированные системы управления технологическим процессом — АСУ ТП) либо по соображениям стоимости (объектовое видеонаблюдение, если в нём сотни и тысячи ка-мер, специальные вычислители, суперкомпьютеры, многотерабайтные результаты компьютерной томографии и т.д.). Эксплуатирующая их организация просто вынуждена содержать инженерною инфраструктуру серверной или маленького ЦОД. Эти затраты относятся к условно постоянным рас-ходам, поэтому, если они уже существуют, то организация может использовать их и для организации других вычислительных процессов.
Ещё отмечу, что инженерные системы ЦОД могут обойтись дороже его вычислительной и программной начинки. А по надёжности они не должны уступать собственно ИТ-решениям. И тут тоже могут быть предпосылки для экономии. Например, если вы имеете доступ к очень дешёвой и бесперебойной (хорошо зарезервированной) электроэнергии, или мощной системе охлаждения, или собственным неиспользуемым помещениям, или ещё чему-нибудь в этом роде, то развитие собственного ЦОД может оказаться выгоднее облаков.
Итого: если у вас уже есть инженерная инфраструктура, от содержания которой вы никак не можете отказаться, то переход в облако для вас становится менее выгодным. Экономия на со-держании инфраструктуры просто не наступит или будет небольшой. Возможно в этом случае в облаке стоит держать только какие-то резервные сервера, если надёжность инженерной инфраструктуры не полностью соответствует требуемой доступности.
Заключение
Из всего вышесказанного следует, что у использования облаков есть множество нюансов. Если вы представляете предсказуемо развивающийся малый или средний бизнес локального значения не ИТ-профиля, то облака — это ваш выбор. Во всех остальных случаях надо очень внимательно считать не только прямую стоимость, но и риски для бизнеса и репутации.
Я надеюсь, что всё написанное здесь будет кому-нибудь полезно. По крайней мере моему шефу отчёт о возможностях перехода в облако, на основе которого я написал эту статью в общем виде, понравился.
