У нативных облачных сервисов есть преимущества и обременения, выигравшие и проигравшие. И обращаясь к ним, всегда надо понимать, делает ли ваша компания выбор в свою пользу, пишет на портале eWeek Дэвид Линтикум, директор Deloitte Consulting по облачной стратегии.

Небольшое уточнение: понятие «нативное облако» означает, что мы используем сервисы и системы, имеющиеся только у конкретного поставщика облачных услуг.

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

Мы используем нативные облачные сервисы внутри приложений или других решений по следующим причинам:

  • они более продвинутые. Нативные облачные сервисы предоставляют прямой доступ к другим нативным ресурсам, таким как хранилище, вычисления и базы данных. Таким образом, они предполагают более современную функциональность, которую не нужно создавать, тестировать и развертывать;
  • у них более высокая производительность. Нативные облачные службы обычно работают лучше. Производительность обычно выше, потому что сервисы созданы и принадлежат облачному провайдеру и предназначены для его многопользовательской платформы;
  • они интероперабельны. Нативные облачные сервисы обычно работают и взаимодействуют с другими такими сервисами. Опять же, поскольку они специально созданы для конкретного поставщика облачных услуг, они обычно поддерживают интеграцию с другими нативными сервисами по принципу «подключи и работай». Например, нативная облачная система обмена сообщениями взаимодействует со своими нативными облачными базами данных без необходимости выполнения заказной интеграции;
  • у них более низкая стоимость. Нативные облачные сервисы обычно стоят дешевле, чем «неродные». Поскольку они созданы для конкретного поставщика облачных услуг и не поддерживают других поставщиков, они, как правило, настроены на использование меньшего количества ресурсов. Это означает, что счет за облако должен быть ниже, чем если бы вы использовали ненативные сервисы.

Если вышеприведенный список верен, зачем нам вообще использовать ненативные службы?

Ответ: потому что, как и во всем остальном в мире вычислений, бесплатного сыра не бывает. Когда вы используете нативные облачные сервисы, есть преимущества и обременения, выигравшие и проигравшие.

Проигравшие

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

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

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

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

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

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

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

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

Выигравшие

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

Допустим, мы хотим перенести систему управления запасами с традиционного стека LAMP (Linux, Apache, MySQL, Python) в дата-центре на такую же платформу LAMP, работающую в публичном облаке. И вместо того, чтобы просто перенести без модификаций, миграционная команда решила использовать некоторые нативные облачные сервисы, такие как безопасность, кластеризация, бессерверность, управление и мониторинг. Поэтому приложение должно быть модифицировано, повторно протестировано и развернуто для использования этих специфических сервисов. Команда ожидает, что все перечисленные выше преимущества в той или иной степени отразятся на перенесенном приложении. Однако дополнительная работа по переходу на нативное облако увеличит затраты примерно на 300% по сравнению с простым переносом приложения с минимальными изменениями. Будет ли конечное нативное облачное решение стоить таких затрат и рисков?

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

Если говорить в общих чертах, то средняя стоимость перехода на нативные облачные технологии составляет около 300% от стоимости подходов без модификаций. Так, если перенос с минимальными изменениями обойдется в 50 тыс. долл., то такое же нативное облачное приложение обойдется примерно в 150 тыс. долл. В этом примере команда миграции ставит 100 тыс. долл. на то, что предприятие как минимум вернет эту сумму в виде полученной ценности, если пойдет по пути нативного облака.

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

Несколько советов — но легких ответов нет

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

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