Архитектор мысли

Шаблоны внедрения облака: основные шаблоны перехода в облако

Набор шаблонов для разработчиков и архитекторов

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

Паттерн - это решение проблемы в контексте.

Облачный дизайн

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

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

  • Он будет основан на архитектуре микросервисов. Мы можем использовать доменно-ориентированный дизайн для извлечения сервисов из монолита.
  • Следование принципам DevOps.
  • Использование 12-факторных правил¹: (1) кодовая база, (2) зависимости, (3) конфигурация, (4) вспомогательные службы, (5) сборка-выпуск-запуск, (6) процессы, (7) привязка порта, (8) параллелизм, (9) доступность, (10) четность разработки и продукта, (11) журналы, (12) процессы администрирования.

Сначала внедрите Monolith

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

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

  • Первый вариант - сохранить прочную монолитную основу и начать строить вокруг нее микросервисы.
  • Второй вариант - итеративно преобразовать все приложение в микросервисы.

Лифт и сдвиг

  • Контекст. Вы оцениваете несколько различных вариантов облачного провайдера. Вы имеете в виду уже существующее приложение, которое хотите перенести в облако, но у вас нет возможности переписать его.
  • Проблема. Как получить преимущества облака, развернув приложение в облаке, при этом минимизируя изменения, которые необходимо внести в приложение?
  • Решение. Выберите облачного провайдера IaaS, который может создать максимально близкое соответствие среде, для которой изначально было создано приложение. Затем выполните Lift и Shift² существующего приложения на облачной платформе.

Контейнеризация монолита

  • Контекст. Вы переносите существующую систему в облако.
  • Проблема. Каков наилучший подход для быстрого перехода в облако, но при этом дает вам гибкость для разработки или развертывания локально?
  • Решение. Создайте контейнер для монолитного приложения в качестве первого шага в облаке. При необходимости вы можете продолжать запускать свое приложение локально в Docker, но это позволяет со временем перейти к нескольким вариантам общедоступного и частного облака.

Облачный рефакторинг

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

Ищите трещины на линии роста волос

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

Применение душителя

  • Контекст. Вы начинаете с унаследованного монолита, который реализован как веб-приложение. При переносе устаревших приложений в облако вам часто нужно подумать о том, как заменить приложение по частям.
  • Проблема. Вам нужен подход, который позволит вам избежать полного «большого взрыва» перезаписи и замены, но все же позволит вам в конечном итоге заменить весь монолит.
  • Решение. Используйте структуру веб-приложения и HTTP для перенаправления запросов к частям приложения от унаследованного монолита к новой реализации этих функций. Постепенно добавляйте функции в новое приложение (приложение-душитель³) и обновляйте логику перенаправления в сторону новых функций по мере их добавления.

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

использованная литература

[1] https://12factor.net

[2] https://www.ibm.com/cloud/learn/lift-and-shift

[3] https://martinfowler.com/bliki/StranglerFigApplication.html