Экономическая целесообразность облаков
Экономическая целесообразность облаков:
на какие факторы нужно обратить внимание
Несмотря на то, что российский облачный рынок растет более чем на 20% в год и степень проникновения облачных услуг практически во все сегменты экономики достаточно велика, пользователи не всегда однозначно оценивают экономическую выгоду от аренды вычислительных ресурсов и аутсорсинга.
На одном конце спектра мнение, будто выгоднее в любом случае держать инфраструктуру и людей у себя («своя рубашка ближе к телу»).
На другой — вера в облака как в спасительную таблетку, которая поможет сократить затраты на оборудование и решит проблему с поиском квалифицированных ИТ-администраторов. Как это часто бывает, истина посередине. Конкретная польза возможна при всестороннем изучении облачных сервисов, модели потребления облачных ресурсов и специфики бизнес-приложений, которые клиент стремиться перенести в облачное окружение. В экономической целесообразности облаков TAdviser разбирался вместе с «Крок Облачные сервисы».
Российские компании используют следующие модели потребления облачных ресурсов:
- Аренда выделенных ресурсов (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%. Если есть такая возможность, то с облаком будет сложно тягаться в экономическом плане.
Источник: https://www.tadviser.ru/index.php/%D0%A1%D1%82%D0%B0%D1%82%D1%8C%D1%8F:%D0%AD%D0%BA%D0%BE%D0%BD%D0%BE%D0%BC%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B0%D1%8F_%D1%86%D0%B5%D0%BB%D0%B5%D1%81%D0%BE%D0%BE%D0%B1%D1%80%D0%B0%D0%B7%D0%BD%D0%BE%D1%81%D1%82%D1%8C_%D0%BE%D0%B1%D0%BB%D0%B0%D0%BA%D0%BE%D0%B2:_%D0%BD%D0%B0_%D0%BA%D0%B0%D0%BA%D0%B8%D0%B5_%D1%84%D0%B0%D0%BA%D1%82%D0%BE%D1%80%D1%8B_%D0%BD%D1%83%D0%B6%D0%BD%D0%BE_%D0%BE%D0%B1%D1%80%D0%B0%D1%82%D0%B8%D1%82%D1%8C_%D0%B2%D0%BD%D0%B8%D0%BC%D0%B0%D0%BD%D0%B8%D0%B5
