13.02.23 13:45

Новости

Автор:

Администратор

3 причины не репатриировать облачные приложения и наборы данных

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

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


Автор: Дэвид Линтикум, InfoWorld

 

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

 

Ещё раз повторю свою позицию: общая цель — найти наиболее оптимизированную архитектуру для поддержки вашего бизнеса. Иногда это находится в общедоступном облаке, а иногда нет. Или еще нет. 

 

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

 

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

 

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

 

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

 

Перепроектирование архитектуры обходится дорого

 

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

 

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

 

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

 

Общедоступные облака обеспечивают большую гибкость

 

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

 

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

 

Привязанность к физической инфраструктуре и навыкам старой школы

 

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

 

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

 

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

 

Как и во всем остальном, здесь есть компромиссы. Просто убедитесь, что вы задаете вопросы: «Должен ли я?» и «Мог бы я?». Пока вы отвечаете на фундаментальные вопросы, посмотрите на компромиссы между бизнесом, технологиями и затратами для каждой рабочей нагрузки и набора данных, которые вы рассматриваете.

 

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

 

Ссылка на источник