Технологии Azure для процесса создания
В этом уроке вы узнаете о связи между процессом инноваций и некоторыми технологиями в отрасли, которые помогут вам создать новые функциональные возможности в приложениях.
DevOps
Когда вы начали этап создания для проверки гипотезы об инновациях, требуемые циклы разработки, интеграции и развертывания должны быть как можно лучше оптимизированы. На этом этапе выполняется DevOps. DevOps можно определить как "процессы и средства для быстрой и надежной доставки программных компонентов". Ниже приведено подробное объяснение этого определения.
Процессы и инструменты: методика DevOps, и процесс внедрения инноваций в целом, основана на культурных моделях, стимулирующих изменения. Azure и GitHub предлагают эффективные средства для DevOps, но недостаточно просто купить лицензию на них. Сами процессы и корпоративная культура должны развиваться, чтобы принять изменения и инновации.
Быстрая доставка программных компонентов: процессы и средства DevOps несут в себе концепцию быстрого реагирования на неудачи. Создание продуктов MVP или прототипов для быстрой проверки правильного курса при разработке компонента является основой концепции DevOps.
Надежная доставка программных компонентов: организации, которые не любят изменения, часто считают, что изменения приводят к простою. Однако DevOps дает в точности противоположный эффект: высокая скорость изменения и высокий уровень надежности. Эта надежность возможна путем интеграции тестирования на ранних этапах цикла разработки в процессе с именем "переход влево".
Если разработка функции в течение времени рассматривается как линия слева направо. Затем процесс разработки прежних версий будет выполнять проверку и контроль качества пользователей в конце цикла разработки. В правом конце этой строки. DevOps рекомендует проводить тестирование и проверку как можно раньше — в "левой" части этой временной шкалы.
В DevOps воплощены те же основные понятия здоровой культуры инноваций. Внедрение этой методологии является ключом к созданию гибкого цикла инноваций.
Архитектуры микрослужб
Модульный подход — это хорошо известная методика для упрощения проектирования сложных систем. Если система является сложным взаимодействием многих частей, которые не могут быть сняты (часто называемые "монолитом"), тесные взаимозависимости компонентов затрудняют улучшение системы. Каждое изменение необходимо проверить во всей системе, поэтому тестирование требует много усилий.
Если система является модульной, ее можно разделить на небольшие подсистемы, взаимодействующие друг с другом с помощью хорошо определенных интерфейсов. Внедрение изменений в одну из этих подсистем упрощается, так как до тех пор, пока его интерфейс с другими модулями остается постоянным, общая система продолжает работать.
Архитектура микрослужб — это шаблон приложений, который использует модульный подход. Приложения делятся на отдельные небольшие компоненты, которые могут разрабатываться независимо друг от друга, даже на разных языках программирования. Каждый компонент или микрослужба может работать по отдельности. Их можно масштабировать по мере необходимости, устранять неполадки в них как в цельном проекте, а также изменять независимо от других микрослужб.
Организации часто спрашивают, что делать, если приложение представляет собой монолит. Следует ли разделить его на микрослужбы, прежде чем внедрять инновации, или можно менять архитектуру приложений параллельно с инновациями? Нет единого ответа на этот вопрос. Все зависит от сложности и важности конкретного приложения для бизнеса.
Компания Tailwind Traders столкнулась с этим вопросом, когда готовилась к инновациям на своей платформе электронной коммерции. Компания решила запустить проект по перепроектированию приложения электронной коммерции, чтобы разделить его на микрослужбы, так как уровень важности для бизнеса оправдывал затраченные усилия. Отсутствие модульного приложения серьезно подорвало бы способность Tailwind Traders реагировать на постоянно меняющиеся тенденции интернет-рынка в будущем.
Тем не менее, Tailwind Traders принял решение решить некоторые из основных пробелов в своей платформе в то же время. Если бы пришлось ждать, пока приложение не будет полностью перепроектировано, они не выдержали бы конкуренции со стороны стартапов, которые в настоящее время активно пытаются завоевывать рынок.
Проекты взаимодействуют друг с другом, руководствуясь бизнес-ценностью инноваций. Усилия по изменению предназначены для того, чтобы сосредоточиться на наиболее важных областях приложений, где необходимость изменения для улучшения взаимодействия с клиентами является самым высоким.
Контейнеры
Технология контейнеризации не является эксклюзивной для архитектур микрослужб, но основные понятия работают вместе. Контейнеры — это способ инкапсуляции кода приложения и его зависимостей, что позволяет легко развертывать их на любой платформе.
В традиционных развертываниях приложений организация должна сначала установить программное обеспечение, например среду выполнения приложений, библиотеки программирования или внешние компоненты. Этот подход часто приводит к проблеме, при которой приложение правильно работает лишь на отдельных компьютерах, так как сложно полностью реплицировать всю среду, включая среды разработки, тестирования, промежуточного хранения и рабочую среду. Небольшие различия в способе установки зависимостей приложения могут привести к тому, что приложение будет работать нормально во время тестирования, но при развертывании в рабочей среде будет завершаться со сбоем.
Контейнеры изменяют правила игры. Зависимости приложения упаковываются вместе с кодом приложения в автономном модуле развертывания, называемом образом контейнера. Независимо от того, развертывается контейнер приложения на ноутбуке разработчика или в рабочем кластере с сотнями узлов, обработка зависимостей выполняется одинаково. Контейнер работает точно так же, поэтому тестирование приложений является более надежным и надежным.
Контейнеры продли длинный путь развития с выпуска решения Docker с открытым кодом в 2013 году. Теперь контейнеры поддерживают как Linux, так и Windows, а также различные архитектуры ЦП. В Azure существует множество предложений, которые позволяют выполнять рабочие нагрузки на основе контейнеров. В этом уроке вы узнаете о некоторых из них.
Kubernetes и Red Hat OpenShift
Среда выполнения контейнера — это технология, которая запускает контейнеры на компьютере, но в рабочей среде требуется больше логики. Кто развертывает больше контейнеров, если требуется больше производительности? Кто перезапускает контейнеры, если у них возникла проблема? Если доступны несколько компьютеров, кто решает, какой из них должен быть запущен определенный контейнер? За эти и другие задачи отвечает платформа оркестрации контейнеров.
Первая версия Kubernetes была выпущена в 2015 году и вскоре стала стандартом де факто для оркестрации контейнеров. Кластеры Kubernetes состоят из нескольких рабочих узлов. Каждый рабочий узел имеет среду выполнения контейнера, поэтому он может запускать контейнеры, в которых плоскость управления Kubernetes планирует развертывание контейнерных приложений. Эта плоскость управления обычно выполняется в наборе основных узлов. Он отвечает за поддержание правильной работы приложения, масштабирование приложения и выполнение всех необходимых обновлений.
Одной из основных причин популярности Kubernetes является независимость оборудования, которую предоставляют контейнеры. Так как приложения на основе контейнеров можно надежно развертывать в любой среде выполнения контейнера, вы можете запускать Kubernetes в облаках, использующих различные низкоуровневые оболочки. Развернутые приложения должны работать аналогичным образом (если базовые ресурсы оборудования также аналогичны). Многие организации использовали Kubernetes в качестве слоя абстракции, который обеспечивает единообразное развертывание приложений как в локальной среде, так и в общедоступных облаках.
Запустить Kubernetes в Azure очень просто. Служба Azure Kubernetes прост в развертывании и экономичности, так как клиент взимается только за стоимость рабочих узлов. Корпорация Майкрософт несет стоимость и эксплуатацию плоскости управления, содержащей основные компоненты. Корпорация Майкрософт обновляет операционную систему рабочих узлов, что снижает операционную сложность управления кластером Kubernetes для запуска контейнеров Linux и Windows.
OpenShift — это платформа развертывания приложений на основе Kubernetes, разработанная и поддерживаемая Red Hat. Он включает множество других функций. Некоторые организации предпочитают запускать свои приложения в OpenShift как раз из-за таких дополнительных функций и поддержки. Использовать OpenShift в Azure очень просто. Azure Red Hat OpenShift состоит из кластера OpenShift , где корпорация Майкрософт управляет многими ее аспектами, включая весь жизненный цикл кластера.
Служба приложений Azure
Служба приложений Azure — это платформа, в которой организации могут выполнять свои рабочие веб-нагрузки без необходимости управления оркестратором или базовой операционной системой. Единственным требованием является передача кода приложения в службу через один из множества доступных методов развертывания. Azure выполняет остальные действия: масштабирование приложения в и выходе, исправление и обслуживание базовых виртуальных машин и многое другое, не требуя кривой обучения Kubernetes.
Служба приложений Azure поддерживает рабочие нагрузки на основе контейнеров, поэтому вы можете отправить образ контейнера вместо кода приложения. Она также поддерживает рабочие нагрузки Linux и Windows и множество различных сред выполнения приложений.
Служба приложений Azure поддерживает различные модели ценообразования, включая бессерверный вариант, называемый Функции Azure. В Функциях Azure плата взимается только за использование приложений. Постоянные затраты отсутствуют.
Бессерверная модель интересна для инноваций, так как она позволяет развертывать новые микрослужбы, не вызывая высокие ежемесячные счета, если рынок не принимает их. Эта модель является еще одним примером стратегии быстрого сбоя, где инновации не обязательно означают высокие расходы.
Служба приложений Azure также предлагает функции, поддерживающие развертывания в рамках методологии DevOps, такие как слоты веб-приложений. Слоты представляют собой промежуточные области, в которых можно развертывать новые компоненты, не затрагивая фактическую рабочую среду. Слоты отлично подходят с точки зрения инноваций, так как вы можете перенаправить небольшой выбор клиентов в эту новую версию приложения. Затем можно проверить правильность гипотезы инноваций. Если со временем вы захотите повысить уровень нового кода до рабочей среды, то сможете "переключить" слоты так, чтобы промежуточная среда стала рабочей версией.
Итоги
В этом уроке вы узнали, как технологии могут способствовать внедрению инноваций:
- Процессы и средства DevOps позволяют командам разработчиков и операций быстро и надежно предоставлять новые функции.
- Вы можете переархитировать приложения в микрослужбы, чтобы разрешить инновации в своих компонентах по отдельности, не влияя на остальные.
- Контейнеры обеспечивают надежное развертывание приложений на разных платформах и в разных средах.
- Kubernetes — это независимая от облака платформа оркестрации для запуска контейнерных приложений.
- Служба приложений Azure может выполнять рабочие веб-нагрузки с минимальными затратами на управление. Они предоставляют множество функций, таких как бессерверная модель и слоты приложений, предназначенных для ускорения цикла инноваций.
Компания Tailwind Traders решила начать перенос своего приложения для электронной коммерции на архитектуру микрослужб. Первая подсистема приложений, отделяемая от монолитной, — это служба оплаты, так как вы определили ее как важную область, в которой конкуренция предлагает лучшее значение для клиентов.
После подсистемы оплаты другие компоненты приложения будут преобразованы в независимые микрослужбы. Микрослужбы могут взаимодействовать через REST API. Код приложения для каждой микрослужбы должен быть контейнеризован, а организации разработки и операций должны внедрять рекомендации DevOps.
Так как Tailwind Traders не хочет зависеть от какого-либо конкретного общедоступного облака, он решил создать опыт Kubernetes в собственной среде и развернуть приложение на Служба Azure Kubernetes кластерах. Если необходимо разработать новые микрослужбы, компания решила рассмотреть Функции Azure в качестве платформы развертывания MVP для снижения затрат на разработку.
Дополнительные материалы
Многие из концепций в этом уроке более подробно рассматриваются в посвященных Cloud Adoption Framework статьях о внедрении цифровых инноваций и использовании Kubernetes в Cloud Adoption Framework.