Облачные сервисы в той или иной степени проникли в нашу повседневность – это и файловые хранилища с доступом для любых устройств, имеющих подключение к интернету, и облачные офисные приложения, позволяющие легко организовать совместную работу с документами, и государственные услуги, и доступ к своему банковскому счету, и многое другое. Это явное свидетельство того, что частные, публичные и гибридные облака накрыли, если не большинство, то значительное число площадок коммерческих и частных центров обработки данных. Как показывают различные исследования, эта тенденция будет только набирать обороты, и поэтому вариант аренды мощности все чаще выглядит достойной альтернативой. Но является ли он ей на самом деле?
Сколько вешать в граммах?
Задумываясь об облачных сервисах для оптимизации бизнес-процессов, нельзя забывать о том, что современные технологии не стоят на месте: производительность процессоров, ёмкость памяти, вместительность SSD-дисков дополняется программно-определяемыми решениями и современными программными платформами, начиная от операционных систем и заканчивая прикладными сервисами зачастую предоставляют нам очень широкие возможности. Настолько широкие, что для них не всегда получается найти рациональное соотношение затраченных денежных средств и получаемой отдачи. Данная ситуация схожа, как для уже существующего бизнеса, так и для стартапа. В первом случае вопросы возникают при перерастании существующей IT-инфраструктуры или её физической деградации, во втором случае, проблема заключается в том, что определить «конфигурацию для начала» бывает очень сложно.
Многие решают идти проторенными тропами и вкладываться в железо, ПО, места в стойках, инженеров, в общем – все, как привыкли. И это не удивительно, ведь стратегию развития IT, как в крупном бизнесе, так и в государственных структурах обычно отдают на откуп соответствующих подразделений, которым «все эти облака» и даром не нужны. Но за прошедшее десятилетие в России достигнут существенный прогресс в плане развития широкополосного доступа на значительной территории нашей необъятной страны, и активные работы в этом направлении продолжаются (по крайней мере, по заверениям Минкомсвязи). Кроме этого существует ещё два фактора, способных привести, если не к взрывному, то по крайней-мере довольно бурному росту облачного спроса:
- Слабые кадры. Компетентный IT-персонал и наиболее сильные кадры вымываются в столичные регионы, а также уезжают за рубеж. Такая ситуация будет подталкивать руководство на местах избавляться от IT-обузы в виде недееспособных сотрудников.
- Требования и нормативы. А ведь облачные площадки полностью соответствуют регулирующему законодательству, прежде всего в разрезе защиты персональных данных. Реализация требований законодательства, как для бизнеса, так и для государственных ведомств – все это дополнительная головная боль, которая способна привести к целому ряду неприятных последствий. Хочется, чтобы она была изначально устранена.
Что касается доступных решений, в РФ для создания вычислительной инфраструктуры в облаке наибольшее распространение получили продукты VMware, вариации на базе Openstack и сервисы Microsoft. Любая из данных категорий обладает обширным инструментарием, который позволяет создавать все разновидности облачных решений, кроме того, в каждом семействе продуктов доступна расширенная функциональность, позволяющая выйти за рамки IaaS. Благодаря возможности создания гибридных облаков помимо публичных, перечисленные платформы легко адаптируются для соответствия законодательной базе РФ. Но каждый раз возникает вопрос: к каким рискам может привести облачная система, и сколько она в действительности будет стоить?
Пример расчета
В качестве примера попробуем рассмотреть типовой сценарий использования облачного решения. Например, в компании требуется внедрение новой ИС, которая формирует бизнес-аналитику на основе уже существующих баз данных. Как следствие, влияние на уже эксплуатируемые подсистемы должно быть минимально. Они (подсистемы) не являются неизменными, что предполагает эпизодическую адаптацию процедур выгрузки данных в warehouse, рефакторинг отчётов, проведение цикла нагрузочных испытаний и перевод адаптированной ИС в продуктивное состояние.
Таким образом, внедрение новой ИС предполагает наличие трёх контуров — продуктивного, предпродуктивного (нагрузочное тестирование и резервный сервер для продуктивного) — конфигурация близкая к продуктивной, тестовый. Расчётные показатели по потребностям в ресурсах показывают необходимость в трёх серверах с конфигурацией 2 CPU класса E5-2640v3, RAM 64GB, порядка 2-3 Тб емкости, желательно на быстрых дисках (например, 12 дисков SAS 15k rpm по 600ГБ, а лучше – SSD). Цикл формирования отчётности ежемесячный, соответственно, в течение месяца преимущественно требуется доступ к уже сформированным отчётам.
Характер данных, находящихся в системах – коммерческая информация, возможно присутствие персональных данных. Исходя из этого очевидно, что два сервера — продуктивный и предпродуктивный — являются плохими кандидатами на размещение в облаке, по крайней мере в публичном. А вот тестовый сервер при условии использования механизма обезличивания данных – как раз тот самый вариант, когда облако можно использовать.
Предположим, что в существующей инфраструктуре уже нет ресурсов для его размещения, например, для задействования существующего тестового контура потребуется увеличение ёмкости СХД, приобретение дополнительного сервера под расширение фермы виртуализации. Нередко одновременно с этим в SAN-сети оказываются исчерпаны свободные порты и потребуется значительно большее вложение. Но даже бюджет сервера в указанной конфигурации с трёхгодичной поддержкой будет составлять порядка $30000 (если говорить про HPE DL380 G9, хотя можно взять что-то подешевле и ограничиться $15000).
Что же предлагает нам облако? Так как тип загрузки тестовых ресурсов – эпизодический, интерес представляет размещение со схемой оплаты pay-as-you-go, т.е. по фактически потреблённым ресурсам. На этапе внедрения ИС, тестовая среда используется интенсивно на протяжении трёх месяцев, что примерно составляет 8ч x 24дня x 3 = 576 часов, в последствии, тестовая система используется каждые два месяца по 40 часов, то есть за первый год получаем 576 + 160 часов, за последующие два по 240 часов в год.
К сожалению, online-калькуляторы с указанной схемой оплаты доступны для сервисов, которые официально на нашем рынке не работают – это Amazon и Google. Но чтобы сделать грубую оценку, можно ориентироваться и на них.
Итак, берём ВМ с профилем m4.4xlarge в Amazon AWS EC2:
vCPU — 16.
ECU — 53.5.
Память (ГиБ) — 64.
Хранилище инстансов (ГБ) — EBS.
Использование Linux/UNIX — $0.96 за час.
В результате получается следующий расчет:
1-ый год $0.96 * (576+160) = $706,56.
2-ой год $0.96 * 240 = $230,4.
3-ий год $230,4.
Что касается системы хранения, берем EBS. Например, возьмём Amazon EBS General Purpose SSD (gp2) по $0.119 за ГБ-месяц выделенного хранилища. Для дискового пространства расчёты несколько отличаются, так как ВМ будет использоваться только в рабочие часы, а резервировать дисковое пространство придётся на весь период эксплуатации ВМ. Таким образом, получаем 24 ч x 30 дней x 3 = 2160 часов на внедрение и 480 часов сопровождение в первый год, а также по 720 часов на сопровождение в последующие годы. После выполнения каждого цикла работ диск с данными высвобождается и за его аренду можно уже не платить.
Итого по дисковой подсистеме получаем:
1-ый год $0.119 * 3000 * 2160/(24*90) + $0.119 * 3000 * 480/(24*120) = $1309.
2-ой год $0.119 * 3000 * 720/(24*180) = $357.
3-ий год $357.
Общая сумма за всю аренду достигает следующих показателей:
1-ый год 706,56 + 1309 = $2015,56.
2-ой год 230,4 + 357 = $587,4.
3-ий год $587,4.
Получается, что мы заплатим $3190,36 за три года. Хорошо, пусть придется брать эти сервисы у других провайдеров, так что округлим сумму до $5000. Возможно также потребуется использование снэпшотов или продолжительность работы ВМ окажется выше, но стоимость нового сервера будет проблематично достичь даже при самом пессимистичном прогнозе.
Заключение
Да, оценка была проведена достаточно грубая, фактически «для сферического коня в вакууме», но она позволяет всё же сделать вывод, что имеет смысл рассматривать публичные облака для решения по крайней мере второстепенных задач. Если есть потребность в выделении дополнительных ресурсов под тестовые проекты и разработку, создание сервисов с нуля, когда оборудование уже «дышит на ладан», в большинстве сценариев, требующих приобретения нового оборудования, вполне оправданным будет посмотреть сначала на облака.
Более того, поскольку облачные решения по сути своей являются экстерриториальными, желающим доступны любые сервисы, в том числе таких «монстров» как Microsoft или VMware, предоставляющих, как инструментарий для построения собственно облачных платформ, так и свои готовые облачные продукты. Сервисы таких мировых лидеров облачных решений, как Amazon и Google, менее востребованы отечественным бизнесом, что обусловлено их политикой продвижения услуг в России (а точнее её отсутствием). Но зато у них есть удобные калькуляторы, и никто не запрещает использовать их продвинутым командами или индивидуалами в сфере разработки ПО. Для большинства же будут актуальны многочисленные российские платформы, которые с радостью предоставят по запросу свою версию подобного расчета, причем совершенно бесплатно. Так что не стесняйтесь считать и спрашивать – может быть уже сегодня облако окажется дешевле, удобнее и надежнее, чем перегруженная инфраструктура, если говорить о задачах разработки и тестирования.
Комментарии (18)
hippoage
24.07.2017 15:488 часов в день на тестирование — явно занижено. Во-первых, на обед вряд ли эффективно выключать (+1 час). Во-вторых, если тестируют несколько человек и свободный график, то редко все приходят в одно время (+2-3 часа). Ещё люблю время от времени на ночь оставлять для отработки на более-менее реальном объеме.
Но важнее другое. Сравнивается bare metal и публичное облако. Сразу хочется вспомнить о приватном облаке. Тема сложная, нужно учитывать все проекты, а не только один, квалификацию людей на внедрение и поддержку, но в таких расчетах тоже стоит учитывать.
RedSys
25.07.2017 12:18Как упоминалось в посте, наш расчёт очень «сфероконичен». Это только пример. Можно посчитать процессорное время по тем же нормативам, что и дисковое пространство, накинуть время для загрузки данных, например, если из творческого порыва их вдруг захочется не генерить скриптом, а заливать все два-три терабайта каждый раз. Но даже при этом стоимость облака останется более привлекательной в сравнении с железкой.
Но ведь и ситуация, когда под задачу требуется один хост без обвязки, по нынешним временам скорее атипична, поэтому в реальности, скорее-всего, расчет будет посложней (как минимум, может потребоваться vpn в контур разработки). В случае построения частного/гибридного облака затраты для большинства сценариев будут отличаться в большую сторону, по сравнению с облаком публичным, и не факт, что будут оправданы для одной ВМ. А с точки зрения квалификации персонала на внедрение и сопровождение, если рассматривать вариант с частным облаком на инфраструктуре сервис-провайдера, то планка требований может оказаться заметно ниже, чем при организации и сопровождении эквивалентной инфраструктуры на своих мощностях.
Конечно, сложно не согласиться с тем, что при оценке возможности использования облачных решений следует рассматривать все их грани с учётом характерных им особенностей. Но мы не ставили задачу посчитать все «от и до». Мы хотели показать, как быстро прикинуть стоимость одного сервиса – для собственного понимания или для аргументации руководству.
SirEdvin
24.07.2017 16:05Слабые кадры. Компетентный IT-персонал и наиболее сильные кадры вымываются в столичные регионы, а также уезжают за рубеж. Такая ситуация будет подталкивать руководство на местах избавляться от IT-обузы в виде недееспособных сотрудников.
Но ведь для управления облаком тоже нужны кадры. И там тоже много трудностей, например, в том же aws.
Arty_K
25.07.2017 05:52Подразумеваются слабые кадры "на местах". Облаком управляют сотрудники IaaS провайдера (зачастую работающие из Москвы и СПб), да, криворучки попадаются и там, но если провайдер заботится о своей репутации и качестве оказываемых услуг, то и инженеров/саппортёров будут набирать квалифицированных и платить им хорошо, чтобы не "вымывались".
А если говорить про какую-нибудь крупную, но региональную компанию (то есть НЕ МТС, Альфа-банк и т.д.), то возможностей найти хорошего спеца и хорошо ему платить при этом у нее будет куда меньше…
RedSys
25.07.2017 12:19Позвольте с вами не согласиться. Сопровождение зоопарка железа, сервисные контракты, ЗИП, инфраструктурное ПО, резервное копирование – весь этот слой и сопутствующая головная боль передаются (не безвозмездно) сервис-провайдеру. Кроме того, на местах, как правило, наблюдаются низкие зарплаты и высокая текучка кадров, особенно, если таковые действительно оказываются квалифицированы. То есть затраты на обучение оказываются постоянными. Кроме этого требования к информационной безопасности могут сопровождаться проверками соответствия этим требованиям. А это значит, что понадобятся существенные вложения в собственную инфраструктуру, в персонал. На этом фоне при использовании типичных консолей облачных сервисов, сопровождение оказывается более-менее тривиальным и требует минимального времени на освоение.
SirEdvin
25.07.2017 12:22Особенно это заметно для aws, в котором половина вещей делается (делалась) исключительно через aws-cli. А большинство виндовых админов, которые отлично справляются со всеми зоопарками железа и прочим почему-то не умеют в консоль.
Ну и почему-то облачники по зарплатам пока дороже обычных админов. Возможно, в силу того, что вместо того, что бы делать все эти перечисленные штуки ручками они их автоматизириют.
DisM
25.07.2017 16:50В вашем примере 2 сервера на сайте, один в облаке. В реальности, где 2 там и 3. Нет никакого смысла разносить инфраструктуру, издержки только увеличатся.
Есть принципиальное ограничение который носит этакий национальный признак — в некоторых странах, вот прям не допускают что критичная для бизнеса информация будет храниться, где-то, и у кого-то, а не у тебя под столом.
В некоторых странах — на это вообще не смотрят. Это как то связано с национальным менталитетом. (сразу скажу, что Россия тут не уникальна ). По этой причине — что бы вы там не насчитали — это для многих не важно.
PS
Если не брать сервера А брендов, то даже по вашим расчетам они за год могут отбиться.RedSys
25.07.2017 16:51Не отрицая национальных особенностей, можно утверждать, что в нашей стране есть живые примеры, когда разработку выводят в облака, и их – немало. Если вы внимательно читали пост, то, наверное, заметили, что из 3 серверов с разными ролями мы допустили перевод в облако только разработки… поэтому рассматриваемый пример — вполне себе жизненный.
Но если уж зарываться в тему отношения к хранению критичной информации, как сдерживающего фактора для активного использования облачных решений, то со стороны операторов уже есть предложения сервисов, соответствующих по защите требованиям ФСТЭК и ФСБ. А при реализации должных мер защиты на уровне СУБД/серверов приложений, их расположение становится непринципиальным. Другое дело, что под такой сценарий программный стек должен проектироваться изначально. И поэтому мы пока предлагаем посчитать только машину разработчика/тестировщика. Остальное требует более детальной оценки.DisM
26.07.2017 23:46как сдерживающего фактора для активного использования облачных решений, то со стороны операторов уже есть предложения сервисов, соответствующих по защите требованиям ФСТЭК и ФСБ.
Вы понимаете что предложили козлу охранять капусту?
shepemic
25.07.2017 16:51Стоимость DL380 явно завышена. В Вашей конфигурации, но на процессоре 2650v4 и с SSD 5x800GB SAS такой сервер стоит около 16000$. Соответственно, «что-то подешевле» будет стоить еще дешевле. К тому-же, сейчас даже в малом бизнесе вовсю используется виртуализация и под тест одного приложения, как правило, не приобретается отдельный сервер. Если даже текущих ресурсов не хватает, то новый сервер увеличит вычислительные ресурсы существующего кластера виртуальных машин и впоследствии его ресурсы будут задействованы и для решения других задач.
RedSys
25.07.2017 16:53По цене спорить сложно, хотя стоимость сервера взята из GPL, отпускная будет скорее-всего ближе к 20000$. Но оставим его в покое – действительно, сервер noname будет дешевле в двое. А когда надо «здесь и сейчас», а бюджет не резиновый (в примере из нашего поста таких серверов требуется три), то возможны варианты. Отобьётся ли он за год? Сомнительно. Хотя, просим расчеты в студию, если у вас своя точка зрения)
Мы не стремились рассматривать все возможные конфигурации и разводить эдакое многостраничное исследование, которое с большой вероятностью всё равно будет не полным. Суть поста в том, что облачные решения вполне применимы и могут использоваться и в качестве «костыля», и для растягивания или даже замены собственной инфраструктуры. Взяли для этого калькулятор – открытый и доступный. Вот и все.
К слову, чем содержать админа, пусть даже лишь изредка приходящего на свой пост, а также тратиться на закупку и поддержку самосборных серверов и СХД, лицензиями на инфраструктурное ПО, неопределённостью с резервными копиями и при этом отсутствием представления, что с этим всем делать, если, например, безвозвратно выйдет из строя какой-либо из аппаратных компонентов, малому бизнесу вполне имеет смысл посчитать, а сколько будет стоить то же самое в облаке, расписав для себя плюсы и минусы по обоим вариантам. Никто же не говорит «берите облако». Речь идет о «давайте посчитаем»)shepemic
28.07.2017 14:03А что делать со всей ИТ-инфраструктурой, которая уже имеется в компании? Ну возьмете Вы один или три сервера в облаке под новую задачу, свои то серверы все равно кто-то должен обслуживать. Как правило, облако на много дороже решения на своих серверах. Однако, если считать не переход в облако, а разворачивание в облаке всего бизнеса для новой компании, у которой нет никакой ИТ-инфраструктуры, то в этом случае облако получается гораздо выгоднее. Такие расчеты мы уже делали и сами предлагаем своим клиентам.
RedSys
31.07.2017 13:52Если эксплуатируемая IT-инфраструктура современна и её ресурсов достаточно для текущих бизнес-задач, кроме того есть запас для дополнительных нагрузок, то видимо и дальше поддерживать её в рабочем состоянии.
Как у Вас совершенно верно подмечено, облачные решения целесообразно рассматривать для нового бизнеса, кроме того, для вариантов, когда требуется модернизация или расширение уже используемой инфраструктуры, либо если есть проблемы с её сопровождением. В общем, по сути, во всех случаях, когда предполагаются заметные, по меркам компании, затраты на ИТ-инфраструктуру, имеет смысл посчитать, «а что если».
r-moiseev
В мире существует не только AWS. AWS раза в два дороже чем в среднем по больнице.
Машину уровня m4.4xlarge можно взять за $0.50 и даже меньше. (без имен и явок дабы не разводить холивар)
RedSys
Нет, мы не говорим, что этот пост — руководство к действию :) Мы предлагаем задуматься, а не просто использовать калькулятор Amazon. Речь идет о том, чтобы задействовать дополнительный ресурс или хотя бы учитывать его, если не в построении инфраструктуры, то по крайней мере для её диверсификации.
Почему выбрали пример на AWS? Просто потому что этот вариант доступен и для него есть готовый калькулятор. Но даже с AWS облако бывает куда выгоднее. Для конкретных задач, конечно, нужно проводить расчеты с рядом потенциальных поставщиков сервиса. AWS в данном случае, так – первая прикидка.
r-moiseev
Тут я с вами согласен. Часто встречаю людей которые вообще не задумываются что есть варианты.