Экономическая целесообразность облаков:
на какие факторы нужно обратить внимание

Российские компании используют следующие модели потребления облачных ресурсов:

Аренда выделенных ресурсов (HaaS) Инфраструктура как сервис (IaaS) Платформа как сервис (PaaS) Аренда приложений (SaaS)

Максим Березин, Крок Облачные сервисы:

На деле в РФ корпоративные клиенты используют IaaS-подход, применяют отдельные элементы PaaS при общем доминировании IaaS-сервисов. Кейсы, связанные с SaaS малочисленны, так как, по нашему опыту, корпоративные клиенты тяготеют к кастомизации, и у каждого клиента есть с десяток очень важных технических и организационных требований, ставящих крест на подходе SaaS.

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

Максим Березин, Крок Облачные сервисы:

Аудит ИТ-инфраструктур и ИТ-сервисов, который мы проводим для наших заказчиков, позволяет взглянуть на вопрос целесообразности выноса в облако с разных углов и в конце концов принять взвешенное решение. В крупных компаниях редко бывает так — все облаке или все локально. Часто мы видим следующую картину: 25% систем размещено в облаке, 40% работает на базе аренды выделенной инсталляции и 35% — onprem или colocation. Нередко клиенты пользуются связкой из 2-3 публичных облаков (мультиклауд), арендуют выделенную инфраструктуру для части сервисов, а часть держат у себя. У нас есть опыт реализации таких проектов и понимание, где какие сервисы целесообразнее размещать.

Считается весьма полезным и даже необходимым формирование стратегии развития облачных решений. Как это делать — отдельный (и отчасти до сих пор дискутируемый) вопрос. Однако в любом случае ряд обязательных для рассмотрения пунктов этой стратегии так или иначе коснется классификации ИТ-сервисов с точки зрения целесообразности их размещения в облаке, а также того, как оценивать результат экономически.

В частности: Нацелены ли мы на разработку новых ИТ-систем или управление данными для их последующего анализа. В двух последних случаях бизнес-эффект будет, скорее всего, более опосредованным, чем в первом.

В случае переноса среды разработки и тестирования в облако может иметь место как прямой экономический эффект, так и косвенный. Облаком можно автоматизированно управлять через API, что значительно сокращает нагрузку на штат ИТ-команды, отвечающей за инфраструктуру, комментирует Максим Березин.

Является ли нагрузка на серверную инфраструктуру, связанную с эксплуатацией сервиса, относительно стабильной, или она подвержена определенным колебаниям (как планируемым, так и плохо предсказуемым). Для того, чтобы иметь возможность предсказывать подобные изменения точнее, часто «подтягивают» исторические данные и пользуются методами математической статистики. Но сделать это более или менее точно все равно удается далеко не всегда.

Высоконагруженные фронт-сервисы с плавающей нагрузкой (e-com, порталы, программы лояльности и пр.) мы однозначно рекомендуем размещать в облаке, говорит эксперт КРОК Облачные сервисы. Здесь облако точно позволит сэкономить за счет Pay as You Go модели оплаты. В противном случае в своей собственной инфраструктуре придется сильно перезакладывать по ресурсам.

Являются ли перспективы дальнейшего развития ИТ-сервиса вполне определенными или же нет. Быстрый запуск и быстрое сворачивание многих новых продуктов, услуг, направлений легко организовать в том числе технически, и это не считается признаком плохой управляемости бизнесом. Наоборот, это нередко изначально закладывается в бизнес-модель.

Весьма целесообразно размещение в облаках новых ИТ-сервисов, будущее которых не определено, считает Максим Березин. Они могут вырасти в 30 раз, как, например, сервис «Самокат» в пандемию. А могут не прожить и полугода вместе с породившей эти сервисы бизнес-идеей. Часто это можно считать штатной ситуацией, потенциально сопряженной тем не менее с финансовыми потерями. Облако в подобных случаях «прощает» ошибки с планированием ресурсов.

Является ли тот или иной сервис, наоборот, абсолютно стандартным, присутствующем в ландшафте автоматизации многих (или даже абсолютного большинства) корпоративных заказчиков. В контексте проектов миграции выделение таких сервисов также представляется важным.

Существуют своего рода базовые инфраструктурные сервисы. Почта, портал, 1С, VDI. Мы такие сервисы обычно рекомендуем размещать в облаке, говорит эксперт КРОК Облачные сервисы.

Если возможно заранее определить группу сервисов, которые предприятие по тем или иным причинам считает нецелесообразным размещать в облаке, это также необходимо сделать.

Немаловажный момент — необходимо оценить уровень собственной культуры (традиций, зрелости) автоматизации отдельно для прикладной автоматизации, для технологий разработки приложений и для управления корпоративным информационным ресурсом.

В частности, для прикладной автоматизации: наличие технологий, предполагающих распределенную обработку информации наличие сервисно-ориентированной архитектуры, микросервисов и контейнеризации для корпоративной разработки: наличие культуры DevOps-разработки и ее компонентов (continuous integration, continuous delivery и др.). для управления данными: наличие хранилищ данных (DW) наличие, помимо централизованных реляционных баз данных (они на практике есть в каждой инфраструктуре), распределенных файловых хранилищ, баз данных категории NoSQL, озер данных (data lakes).

В совокупности почти все эти технологии являются элементами популярной концепции нативных облаков (Native Cloud). Конечно, «классическая» программная инфраструктура в большинстве случаев тоже с успехом переносится в облако, однако нативные для нее элементы (которые уже имеются в рамках ИТ-инфраструктуры или планируются к внедрению) всегда легче мигрировать в публичное облако и впоследствии в этой среде развивать, администрировать и масштабировать.

Также немаловажную роль играет то, какая аппаратная инфраструктура традиционно преобладала в ИТ-ландшафте заказчика. Крупонблочно здесь можно выделить два известных шаблона: наличие множества относительно дешевых серверов, которые при современных программных технологиях легко объединяются в единый вычислительных кластер или кластер хранения информации. Это так называемая scale-out архитектура. scale-up архитектура, ориентированная на работу известного числа дорогих высокопроизводительных вертикально-масштабируемых серверов ведущих мировых вендоров. Их использование часто связано с наличием у организации давно эксплуатируемых ключевых для бизнеса ИТ-систем и баз данных.

Архитектура облаков — это всегда scale-out, и если обсуждаются перспективы миграции решений в облако, то, казалось бы, чисто технические нюансы решений напрямую выводят нас на экономическую эффективность их использования.

Максим Березин, КРОК Облачные сервисы:

В крупных организациях часто используются «тяжелые» серверы СУБД или приложений с исключительно вертикальным масштабированием. Во-первых, такие системы, требующие 256 ядер и 4096ГБ ОЗУ, просто могут не стартовать в облаке. Во-вторых, если речь идет, скажем, о решениях Oracle, возникают проблемы с лицензированием физического узла для этого ПО в средах виртуализации. Придется купить в 2-4 раза больше лицензий СУБД, чем при размещении на физическом оборудовании. В результате пропадет вся облачная экономия. Наконец, довольно странно размещать в облаке виртуальные машины, занимающие целиком физический узел. Они будут точно работать лучше на выделенном физическом оборудовании.

По совокупности мнений специалистов можно составить усредненное, но при этом вполне объективное мнение о том, какие решения эффективно размещать в облаке, а какие не рекомендуется. Однако искать универсальную методику подчета экономического эффекта от внедрения не стоит даже и пытаться.

Максим Березин, КРОК Облачные сервисы:

Чтобы сделать подробный отчет о стоимости размещения конкретных ИТ-систем, надо проводить аудит. Мы смотрим текущую загрузку ИТ-сервисов, состояние оборудования (возраст и статистику сбоев), планы по росту, динамичную и статичную нагрузку, параметры RTO/RPO, определяющие качество процессов резервирования. Считаем стоимость владения каждым ИТ-сервисом и показываем, где она будет ниже — в облаке, в арендованной выделенной инфраструктуре или в on premise. Делаем высокоуровневые сравнения разных подходов методом сведенного TCO с учетом ставки дисконтирования. Сухие цифры позволяют принять решение взвешенно.

При выборе исполнителя решения (иными словами, провайдера облачной услуги) тоже необходимо учитывать ряд факторов Зрелость рынка предложения как такового Зрелость сервис-провайдера и как следствие его способность проделать всю необходимую методическую, а при необходимости и разъяснительную работу, предваряющую принятие детального бизнес- и технического решения. В данном случае во многом имеется в виду аудит существующей инфраструктуры и возможность сделать объективные выкладки относительно эффективности (или неэффективности) перевода того или иного ИТ-сервиса в облако. Также очень важно не забывать про длительность эксплуатации облачного решения. С учетом этого фактора в сравнении облачного и on premise решений более рельефно проступает ряд экономических нюансов.

Провайдер время от времени обновляет инфраструктуру своего ЦОД. Предположим, на 2021 год у него в бюджете заложено 8 млн рублей на капитальный ремонт дизель-динамического ИБП. На длинном промежутке эти 8 млн размываются. Но в конкретном 2021 году финансовая нагрузка достаточно ощутимая. Стоимость для заказчика, вероятно, подрастет, но не очень ощутимо — примерно на 10-15%. Но по сравнению с затратами, которые клиент понес бы, эксплуатируя такую инфраструктуру у себя, это небо и земля, считает Максим Березин.

наличие у исполнителя проекта целого спектра предложений, связанных с аутсорсингом ИТ-услуг и при этом вовсе необязательно облачных. Это может быть предложения по построению на своей площадке частного облака для заказчика или, например, аренда физических серверов в ЦОДе. Дело в том, что иногда возможна обратная миграция из облака на традиционные инфраструктурные решения. Если такая ситуация все же возникла, то хорошо, если у заказчика опять-таки есть выбор. Разумеется, он вправе откатить ситуацию к исходной, задействовав собственные серверы. Он также может построить частное облако или арендовать физическую инфраструктуру у сервис-провайдера. Для сервисов, работа которых в облаке признана неэффективной, последний вариант имеет право на жизнь.

Максим Березин, КРОК Облачные сервисы:

Если инфраструктура крупная (от 1000 пользователей), мы рекомендуем воспользоваться услугой аренды выделенной инфраструктуры. По сути, это частное облако заказчика, размещенное в одном из коммерческих ЦОД. Для ИТ-сервисов со статичной или предсказуемой нагрузкой затраты станут ниже, чем в публичном облаке, на 15-20% в горизонте 3-5 лет. При этом услуга будет дешевле или по крайней мере сопоставима с размещением в on premise. Также заказчик может просто арендовать «железо» во внешнем ЦОД.

В публичном облаке клиент всегда платит строго за тот сервис, который потребляет в течение определенного промежутка времени. Контролировать затраты и гибко ими управляют помогают как правило системы биллинга облачных провайдеров.

Заказчик Облака КРОК имеет доступ к биллинговой системе в режиме 24х7 для контроля расходов, рассказывает Максим Березин. Он может настраивать себе алерты, которые срабатывают в случае перерасхода средств. В таком случае начальство быстро об этом узнает и примет меры. У нас честный почасовой биллинг. Выключая в нерабочее время часть инфраструктуры (ночь, выходные), можно оптимизировать чек на 60%. Если есть такая возможность, то с облаком будет сложно тягаться в экономическом плане.