Многие предприятия переоценивают свои облачные миграции после того, как не смогли добиться обещанной экономии средств и повышения эффективности бизнеса, пишет на портале The New Stack Рик Кларк, руководитель отдела глобального консалтинга по облачным технологиям компании UST.
Предприятия могут выражать сожаление по поводу состоявшейся миграции в облако. Это одно из самых распространенных мнений об облаке, которые мы слышали в нашей консультационной практике по облачным технологиям за последние несколько лет. Является ли это очередным подтверждением поговорки «Задним умом все крепки»?
Устаревшая модель капитальных затрат (CapEx) была более медленной и бюрократичной, чем облачная модель операционных затрат (OpEx), а облако рассматривалось как панацея, которая повысит гибкость бизнеса и сократит время выхода на рынок. Предприятия переводили рабочие нагрузки в облако, невзирая на целесообразность. Переход оказывался сложнее, чем предполагалось, и часто занимал гораздо больше времени. После завершения миграции расходы становились значительно выше, чем онпремис.
Почему облако не оправдало своих обещаний
Для предприятий облако кажется «черным ящиком», который скрывает истинные финансовые затраты и не обеспечивает гибкость бизнеса. Оглядываясь назад, можно извлечь ценные уроки о том, как мы дошли до такого состояния.
- Дорогостоящая стратегия переноса без модификации (lift-and-shift). Одна из самых больших проблем, с которыми мы сталкиваемся, — это когда компании «поднимают и переносят» приложения, думая, что постепенно перепишут их, но потом этого не происходит. Как правило, это самые дорогие типы рабочих нагрузок в облаке. Нам приходилось видеть, как весь годовой бюджет компании на облачные вычисления был исчерпан за месяц из-за того, что тесно связанные устаревшие приложения не были переписаны для использования преимуществ облачной инфраструктуры.
- Облачные технологии оторваны от бизнеса. При переходе на облачные технологии многие решения перешли от бизнеса к технологической группе, что значительно снизило прозрачность. Если вы посмотрите на счет за облачные услуги, он может состоять из миллионов строк с очень специфической технической информацией: «эти данные были переданы сюда», «этот процессор использовался столько-то». Но для бизнеса это ничего не значит. Видимость и прослеживаемость затрат были утрачены, а принятие решений о соотношении затрат и выгод, таких как уровень отказоустойчивости системы или производительности приложения, подходящий для бизнеса, было переложено на плечи технологов, а не финансовых аналитиков.
- Переоценка гибкости разработчиков. Переход к программируемой облачной инфраструктуре сопровождался одновременным переходом к автономии разработчиков. Во имя гибкости разработчиков были сняты многие ограждения, обеспечиваемые архитектурными и инфраструктурными командами предприятия. Разработчики получили возможность самостоятельно подключать облачные ресурсы, настраивать виртуальные машины и даже решать, какого облачного провайдера использовать для каждого конкретного приложения. По сути, они получили возможность свободно использовать самую современную, самую крутую и самую модную технологию. Это ловушка, в которую легко могут попасть энтузиасты и истинно верующие в облако, как я.
Стоит ли возвращать рабочие нагрузки онпремис?
В условиях растущего давления, связанного с необходимостью сокращения расходов, многие технические и ИТ-директора рассматривают возможность возвращения облачных рабочих нагрузок обратно онпремис. Каким бы сложным это ни казалось, важно думать не только о затратах. Вы должны понимать требования к рабочей нагрузке, чтобы принять правильное решение для каждого приложения. Например:
- Если ваше приложение нуждается в быстром масштабировании, например сайт электронной коммерции испытывает внезапные скачки трафика, вам потребуется столь же быстрое наращивание мощностей. Онпремис это невозможно.
- Рабочие нагрузки, связанные с искусственным интеллектом, лучше всего размещать в облаке. Для них требуется специализированное оборудование, которое с готовностью предоставляют облачных провайдеры, и они быстро создают дополнительную инфраструктуру в преддверии будущих потребностей.
- Большие данные — одна из основных рабочих нагрузок, которые переносятся в облако. Поставщики облачных решений предлагают множество инструментов и услуг, которые делают аналитическую обработку быстрой и эффективной. Это не обязательно дешевле, но это хороший пример того, когда преимущества облака стоят дополнительных затрат.
Многие организации забыли о том, как сильно изменились ИТ-операции после перехода в облако. Облачная трансформация означала перестройку ИТ-операций в зависимости от выбранного сочетания инфраструктурных, платформенных или программных сервисов (IaaS, PaaS или SaaS). Возвращение приложений онпремис лишает их этих уровней обслуживания, и операционные команды могут оказаться не в состоянии или не захотеть снова брать на себя бремя администрирования и обслуживания.
И последнее соображение перед репатриацией рабочих нагрузок из облака — безопасность. Я считаю, что безопасность — это одно из многих преимуществ облачной инфраструктуры. Когда компании только начинали переходить на облачные технологии, безопасность была одной из самых больших проблем. Но оказалось, что облачные провайдеры лучше вас разбираются в вопросах безопасности. Они не могут устранить дыры в безопасности вашего ПО или другие сценарии ошибок оператора, но облачная инфраструктура обеспечивает бóльшую изоляцию в случае нарушения безопасности. При взломе брандмауэра дата-центра хакер проникает в ваш ЦОД, но не в облачный экземпляр, который ни к чему не подключен.
Ценность облака налицо
Предприятия ожидали экономии средств за счет финансовой модели облачных вычислений, но, как мне кажется, серверная виртуализация была главным средством экономии бюджета дата-центра. Когда все было виртуализировано, дополнительной возможности для экономии не осталось.
Но реальная ценность облака по-прежнему сохраняется. Облако надежнее, безопаснее и масштабируемее, чем локальный дата-центр, а нативно-облачная разработка и программируемая инфраструктура приводят к экспоненциальному росту производительности разработчиков и гибкости бизнеса.