Привязка к одному облачному провайдеру — в чем опасность?

Эффективная облачная стратегия не заканчивается выбором поставщика облачных услуг (cloud service provider, CSP). Мартин Гаффни, вице-президент Yugabyte по региону EMEA, обсуждает на портале Information Age, почему ИТ-директорам необходимо избегать долгосрочной привязки к одному провайдеру, а также рассказывает о преимуществах открытого подхода к облачной стратегии и выбору ПО.

Многие CIO приложили все усилия, чтобы избавиться от локальных систем и перейти в облако. Однако это еще не конечная точка путешествия. Причина, почему вам нужно вернуться к вопросу, который вы считали давно решенным, когда приняли стратегическое решение перейти в облако, заключается в том, что переход на любую из публичных облачных служб не является универсальным решением проблем бизнеса. Хуже того: вам опять придется сразиться с драконом, с которым вы сталкивались до появления облака, — опасностью привязки к одному поставщику.

Соблюдайте нейтралитет по отношению к провайдерам

В спешке перехода в облако компании в основном фокусируются на том, как реализовать новый проект, забывая о том, что поспешное решение о выборе CSP приводит к рискам. Исходить в первую очередь нужно из того, как лучше всего оптимизировать использование облака для вашего бизнеса. Чтобы достичь этой цели, нужно рассмотреть проблему облаков с географической точки зрения. Эту проблему часто рассматривают в контексте местоположения данных, но оно не исчерпывает ее. Во-первых, услуги ведущих CSP доступны не во всех странах, что может стать проблемой для предприятий, работающих, например, в Стамбуле или Южной Африке. Во-вторых, есть и другие аспекты: американские ритейлеры, например, не видят особого смысла платить Amazon за ИТ, если они так жестко конкурируют с ней.

На глобальном рынке привязка к одному облачному сервису может быть либо невозможной, либо неприемлемой для бизнеса, поэтому важной деталью является нейтральность по отношению к CSP. Практичность — один из факторов, побуждающих всегда быть открытым для нескольких облачных решений. У CSP своя стратегия: в его интересах навязать клиенту свою версию ключевых компонентов программного стека, к примеру, облачную версию базы данных, поскольку Amazon хочет, чтобы вы не переносили в ее облако приложения Oracle, а использовали ее БД.

Само по себе такое решение не является безумным или рискованным; если вы уже являетесь клиентом Amazon, в этом есть свои преимущества, и, вероятно, будет достигнут эффект масштаба. Это может быть даже дешевле (хотя в случае с облачными контрактами это не всегда так). Выбор БД поставщика выглядит более простым решением, но может стать настоящей головной болью, если предприятие перешло на микросервисы и имеет всевозможные приложения на базе Open Source, работающие отовсюду (что действительно является наилучшим выбором), а БД бэк-офиса — это БД Amazon. Что произойдет, если вы рассоритесь с этим провайдером или если при обновлении он скажет, что арендная плата повышается, поскольку вы используете больше ресурсов, чем было запланировано, или у него произойдет очередной сбой?

«Единое облако для всего» — препятствие для бизнеса

Переход в облако должен быть рациональным, чтобы предприятие сохранило пространство для маневра и операционную гибкость. Со временем ему может понравиться другой облачный сервис в конкретном регионе, поскольку он лучше с политической точки зрения или более устойчив при эксплуатации (например, благодаря стабильности телекоммуникаций). Нужно понимать, что в разных частях мира, где хочет работать компания, предлагаемые CSP цены, уровень гарантированной поддержки или возможности отличаются.

Это означает, что «единое облако для всего» будет препятствием для бизнеса. Вот почему крупные организации все больше присматриваются к мультиоблаку как к определяющей стратегии, даже если они не начинали с него. Иногда компания выбирает Amazon для операций и вдобавок, к примеру, Azure, поскольку пользуется ПО Microsoft для совместной работы, поддержки или для других целей. Последнее в равной мере касается и Google.

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

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

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

Проприетарные 10% БД — ключевой момент

Открытость касается практически всех частей стека приложений, кроме одного довольно важного элемента — БД. Причина, по которой CIO в первую очередь обратились к облаку, заключается в том, что они хотят избавиться от локальных дата-центров с дорогостоящим оборудованием для работы БД Oracle или DB2, чтобы сэкономить на инвестициях в них. CSP, конечно, приветствуют такое решение, и если вам не нравится их БД, то они не против, чтобы вы использовали вместо нее решение на базе Open Source или NoSQL. Но затем они рассказывают вам о своем специальном замечательном SQL для монолитных приложений и все заканчивается тем, что ваш стек на 90% состоит из открытого исходного кода, тогда как 10% жизненно важной кодовой базы привязаны к проприетарной SQL вашего поставщика.

Эти 10% позволяют ему замкнуть на себе фактически весь ваш стек — ведь это специальный соус, который гарантирует, что ваш бизнес на плаву! Поэтому вам нужно искать свободу на уровне SQL и БД: если вы хотите запустить SQL Server в одной стране на полгода или какое-то время сотрудничать с региональным облачным стартапом, то в итоге вам придется «выкорчевать» одну БД и заменить ее на другую. Это грубая и дорогая работа, которая негативно скажется на способности вашей компании выполнять свои обязательства.

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