Рационализация облака

Рационализация облака — это процесс оценки активов, который определяет наилучший подход к миграции или модернизации каждого ресурса в облаке. Дополнительные сведения о процессе рационализации см. в разделе Что такое цифровые активы.

Контекст рационализации

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

Миф: решения по рационализации могут быть легко приняты на ранних этапах процесса

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

Миф: для внедрения облачных технологий необходимо дождаться рационализации всех рабочих нагрузок

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

Миф: для разработки бизнес-обоснования необходимо дождаться рационализации всех рабочих нагрузок

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

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

Пять принципов рационализации

В следующих пяти вариантах рационализации описываются наиболее распространенные варианты рационализации.

Повторное размещение

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

Распространенными драйверами могут быть:

• Сокращение капитальных затрат.
• Освобождение места в центре обработки данных.
• Быстрый возврат инвестиций в облако.

Количественные факторы анализа:

• Размер виртуальной машины, включая ЦП, память и хранилище.
• Зависимости, такие как сетевой трафик.
• Совместимость ресурсов.

Качественные факторы анализа:

• Устойчивость к изменениям.
• Бизнес-приоритеты.
• Критически важные бизнес-события.
• Зависимости процесса.

Рефакторинг

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

Рефакторинг также относится к процессу разработки приложения и позволяет реализовать в вашем приложении новые бизнес-возможности.

Общие факторы могут включать в себя:

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

Количественные факторы анализа:

• Размер ресурсов приложения, таких как ЦП, память и хранилище.
• Зависимости, такие как сетевой трафик.
• Пользовательский трафик, например просмотры страниц, время на странице и время загрузки.
• Платформы разработки, такие как языки, платформы данных и службы среднего уровня.
• База данных, включающая ЦП, память, хранилище и версию.

Качественные факторы анализа:

• Продолжение инвестиций в бизнес.
• Ускорение параметров или временных шкал.
• Зависимости бизнес-процессов.

Перепроектирование

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

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

Общие факторы могут включать в себя:

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

Количественные факторы анализа:

• Размер ресурсов приложения, таких как ЦП, память и хранилище.
• Зависимости, такие как сетевой трафик.
• Пользовательский трафик, например просмотры страниц, время на странице и время загрузки.
• Платформы разработки, такие как языки, платформы данных и службы среднего уровня.
• База данных, включающая ЦП, память, хранилище и версию.

Качественные факторы анализа:

• Для роста инвестиций в бизнес.
• Эксплуатационные затраты.
• Потенциальные циклы обратной связи и инвестиции DevOps.

Перестроение

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

Распространенными драйверами могут быть:

• Ускорение внедрения инноваций.
• Создавайте приложения быстрее.
• Сокращение операционных расходов.

Количественные факторы анализа:

• Размер ресурсов приложения, таких как ЦП, память и хранилище.
• Зависимости, такие как сетевой трафик.
• Пользовательский трафик, например просмотры страниц, время на странице и время загрузки.
• Платформы разработки, такие как языки, платформы данных и службы среднего уровня.
• База данных, включающая ЦП, память, хранилище и версию.

Качественные факторы анализа:

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

Заменить

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

Распространенными драйверами могут быть:

• Стандартизация на основе отраслевых стандартов.
• Ускорьте внедрение подходов на основе бизнес-процессов.
• Перенаправление инвестиций на разработку приложений, которые создают конкурентные различия и преимущества.

Количественные факторы анализа:

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

Качественные факторы анализа:

• Анализ стоимости текущей архитектуры по сравнению с решением SaaS.
• Карты бизнес-процессов.
• Схемы данных.
• Пользовательские или автоматизированные процессы.

Дальнейшие действия

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