Создание облачных приложений

12-ти факторная модель создания облачных приложений

Создание облачных приложений

Методология 12 факторов представляет собой популярный набор принципов созда­ния облачных приложений, составленный создателями облачной платформы Heroku.

Twelve-Factor Арр — сайт, изначально созданный Адамом Виггинсом (Adam Wiggins), соучредителем Heroku, в виде манифеста с описанием SaaS-приложений, разрабо­танных с целью получить преимущества от использования приемов, свойственных современным облачным платформам.

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

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

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

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

Таблица 1. Ключевые идеи 12-факторных приложений

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

Все 12 факторов, перечисленных в табл. 2, описывают требования, способ­ствующие созданию приложений, использующих идеи, изложенные в табл. 1.

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

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

Таблица 2. Приемы создания 12-факторных приложений

Кодовая базаИспользование одной кодовой базы, отслеживаемой в системе контроля версий при множестве развертываний
ЗависимостиЯвное объявление и изолирование зависимостей
КонфигурацияСохранение конфигурации в среде
Вспомогательные сервисыОтношение к вспомогательным сервисам как к подключенным ресурсам
Сборка, выпуск, практическое применениеЧеткое разделение стадий сборки и практического применения
ПроцессыВыполнение приложения в виде одного или нескольких процессов, не использующих состояния
Привязка портовЭкспорт сервисов через привязку портов
Многопоточное выполнениеГоризонтальное масштабирование с помощью модели процесса
УтилизируемостьМаксимальная надежность за счет быстрого запуска и корректного завершения работы
Функциональная совместимость разработки и практического примененияМаксимально возможная схожесть разработки, доводки и практического применения
Ведение регистрационных записейОтношение к регистрационным записям как к потокам событий
Процессы администрированияЗапуск задач администрирования и управления в виде разовых процессов

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

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

Кодовая база

Одна кодовая база, отслеживаемая в системе контроля версий при множестве развертываний

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

Рис. 1. Исходный код создается 1 раз и отслеживается для каждой среды

Зависимости

Явное объявление и изолирование зависимостей

Зависимости приложения необходимо объявить явным образом, и все без исклю­чения зависимости должны быть доступны из репозитория компонентов, который может загружаться с помощью такого диспетчера зависимостей, как Apache Maven.

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

Конфигурация

Сохранение конфигурации в среде

Код приложения нужно полностью отделить от конфигурации. Последняя должна определяться средой.

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

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

Приложение двенадцати факторов

Рис. 2. Выделение конфигурации, специфичной для среды, в саму среду

Вспомогательные сервисы

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

К вспомогательному относится любой сервис, используемый 12-факторным при­ложением в качестве части его обычной работы. Примерами таких сервисов могут послужить базы данных, веб-сервисы RESTful, управляемые через API, SMTP- или FTP-сервер.

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

Сборка, выпуск, практическое применение

Четкое разделение стадий сборки и практического применения

В 12-факторном приложении имеется четко выраженное разделение стадий сбор­ки, выпуска и практического применения.

  • Стадия сборки. Происходит либо компиляция исходного кода приложения, либо его сборка в пакет. Созданный пакет называется сборкой.
  • Стадия выпуска. Сборка объединяется со своей конфигурацией. Затем выпуск, созданный для развертывания, готов для работы в среде выполнения. Каждый выпуск должен иметь уникальный идентификатор, использующий либо семан­тическое обозначение версии, либо метку времени. Каждый выпуск нужно до­бавить к каталогу, который может использоваться инструментами управления выпусками для отката на предыдущий выпуск.
  • Стадия практического применения. На данной стадии, зачастую называемой временем выполнения (runtime), приложение в виде выбранного выпуска запускается в среде выполнения.

Разбиение этой стадии на отдельные процессы позволяет устранить возможность изменения кода приложения во время выполнения. Единственным способом изменить код остается запуск стадии сборки для создания нового выпуска или запуск отката для развертывания предыдущего выпуска.

Процессы

Выполнение приложения в виде одного или нескольких процессов, не исполь­зующих состояния

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

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

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

Двенадцатифакторные приложения не сохраняют состояние на локальной файло­вой системе в среде выполнения.

Привязка портов

Экспорт сервисов через привязку портов

Двенадцатифакторные приложения полностью автономны, то есть им в ходе вы­полнения для внедрения в среду выполнения с целью создания интернет-сервиса
веб-сервер не требуется.

Каждое приложение откроет к себе доступ через порт HTTP, который привязан к приложению в среде выполнения.

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

Джошу Лонгу, одному из соавторов этой книги, в сообществе Java приписывается изречение: «Make JAR not WAR» («Создавайте не WAR, a JAR»). Джош использует данное выражение, чтобы объяснить, как в сборочном JAR-файле самые новые Spring-приложения могут встраивать такой сервер Java-приложения, как Tomcat.

Многопоточное выполнение

Горизонтальное масштабирование с помощью модели процесса

Приложения должны быть пригодны к масштабированию процессов или потоков для параллельного выполнения работы по требованию. JVM-приложения могут автоматически справляться с оперативным распараллеливанием с помощью не­скольких потоков.

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

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

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

Утилизируемость

Максимальная надежность за счет быстрого запуска и корректного завершения работы

Процессы 12-факторных приложений спроектированы с прицелом на утилизиру­емость. Приложение в ходе выполнения процесса может быть остановлено в любое время и при этом достойно справиться с утилизацией процессов.

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

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

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

Функциональная совместимость разработки и практического применения

Максимально возможная схожесть разработки, доводки и эксплуатации

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

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

Ведение регистрационных записей

Отношение к регистрационным записям как к потокам событий

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

Процессы администрирования

Запуск задач администрирования и управления в виде разовых процессов

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

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

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

Источник: https://oracle-patches.com/net-cloud/3750-12-ti-faktornaya-model-sozdaniya-oblachnyh-prilozhenij

Cloud-native приложения: быстро загружаются, снижают риски, стимулируют рост бизнеса

Создание облачных приложений

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

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

Разработаны как слабосвязанные микросервисы. Микросервисы — архитектурный подход к разработке приложения как набора небольших сервисов.

Каждый сервис реализует определенную бизнес-возможность, работает в собственном процессе и обменивается данными через HTTP API или сообщения.

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

У микросервисной архитектуры есть и минусы. Такая распределенная система сложнее на системном уровне. Чтобы снизить сложность, нужно стремиться к независимости микросервисов друг от друга.

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

Также систему микросервисов сложнее мониторить, чем несколько монолитных сервисов.

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

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

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

Какие еще особенности у cloud-native приложений?

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

  2. Сосредоточены вокруг API для взаимодействия и совместной работы. В облачных сервисах используются легковесные API, основанные на таких протоколах, как REST, gRPC или NATS. REST используется в качестве наименьшего общего знаменателя для предоставления API через протокол передачи гипертекста (HTTP).

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

  3. Архитектура с четким разделением сервисов без сохранения состояния и с сохранением состояния.

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

  4. Независимы от сервера и операционной системы.

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

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

Почему бизнес переходит на cloud-native приложения

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

Облако как конкурентное преимущество. Cloud-native — это когда облако используют не для экономии IT-ресурсов, а как инструмент развития бизнеса. В эпоху программного обеспечения успешны компании, которые умеют быстро разрабатывать и поставлять приложения под запросы клиентов.

Фокус на стабильность. Когда устаревшая IT-инфраструктура выходит из строя, сервисы могут пострадать. В облачной среде разработчики уделяют особое внимание архитектуре, чтобы обеспечить ее устойчивость. Облака помогают проектировать системы, которые остаются в сети независимо от сбоев в любой среде.

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

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

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

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

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

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

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

Главные различия между cloud-native и традиционными корпоративными приложениями

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

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

Хороший пример документа, отражающего методологию создания приложений, это 12 факторов разработки приложения (12-factor principles).

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

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

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

Оптимизация ресурсов. Облачная платформа автоматизирует предоставление и настройку инфраструктуры.

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

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

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

DevOps. Процесс разработки cloud-native приложений подразумевает совместную работу. Облачная среда упрощает DevOps — объединение людей, процессов и инструментов. Это обеспечивает тесное взаимодействие между разработкой и операционным IT-персоналом, что способствует быстрой и плавной выкатке нового кода приложения в производство.

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

Непрерывная разработка. Для cloud-native приложений работает непрерывная доставка. IT-подразделения выпускают обновления программного обеспечения по мере их готовности.

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

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

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

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

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

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

Компоненты архитектуры традиционных приложений зависят друг от друга. В монолитной архитектуре множество отдельных сервисов объединены в единый пакет. Из-за ненужных зависимостей между ними разработка и развертывание приложений становятся менее гибкими.

Автоматическое масштабирование. Автоматизированные инструменты масштабирования в облаке исключают простои инфраструктуры, вызванные человеческим фактором.

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

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

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

Подводные камни при разработке cloud-native приложений

  1. Не переносите в облако все-все задачи. Бизнес и IT-специалисты должны совместно расставить приоритеты среди унаследованных и новых задач, оценить в каждом случае техническую возможность, стратегическую важность и окупаемость инвестиций при переносе в облако.
  2. Не экспериментируйте слишком много с инструментами. Разработчикам нужно договориться о том, как и на чём они пишут. При использовании облачной среды разработчикам, вероятно, понадобится больше дисциплины, чтобы следовать 12 принципам разработки приложений, стандартизировать свою платформу и сервисы разработки. Так хочется использовать новые технологии и шаблоны для каждого нового приложения. Но продвинутые команды специально ограничивают себя в выборе, чтобы сосредоточиться на разработке инновационного ПО, а не изобретать базовые вещи заново.
  3. Лучше купить, а не разработать. Многие компании рассматривают создание собственной облачной платформы, комбинируя программное обеспечение для автоматизации с открытым исходным кодом и контейнерные технологии. Но вскоре выясняется, что для этого нужно больше компонентов, чем предполагалось, так как не все они могут совместно работать. Это задерживает старт работ над самими приложениями. Плюс добавляется еще один фактор — необходимость поддержки рабочей платформы. При использовании готовой облачной платформы можно сразу сосредоточиться на создании приложений, не думая об организации процесса и инфраструктуре.

Источник: https://mcs.mail.ru/blog/cloud-native-prilozheniya-bystro-zagruzhayutsya-snizhayut-riski-stimuliruyut-rost-biznesa

Облачные приложения – Россия | IBM Cloud

Создание облачных приложений

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

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

Такой подход позволяет разработчикам быстро добавлять новые функции.

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

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

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

Разработка с использованием контейнеров

Загрузите весь отчет (PDF; 2,2 МБ)

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

Использование такого подхода дает целый ряд преимуществ:

  • Облачные приложения можно быстро развернуть, а затем масштабировать в зависимости от текущих потребностей.
  • Приложения можно дополнить такими передовыми технологиями, как ИИ, Интернет вещей (IoT), средства аналитики, блокчейн и т. п.
  • Облачными приложениями проще управлять, чем традиционными монолитными приложениями, так как методологии Agile и DevOps предполагают пошаговое улучшение.
  • Для внесения улучшений не нужно приостанавливать работу приложения, то есть пользователи могут не прерывать свою работу: это упрощает масштабирование вверх и вниз.

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

Загрузите весь отчет (PDF; 2,2 МБ)

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

  • Когда стоит переписывать заново: В ряде случаев может быть проще с нуля создать новые приложения, используя методологию разработки для облачных сред, вместо того чтобы модернизировать имеющееся монолитное приложение. Это может быть обусловлено несколькими причинами. Такое решение может быть принято исходя из корпоративной культуры, предполагаемых рисков или ограничений, прописанных в нормативных требованиях. Создание нового приложения позволяет предоставить пользователям передовые возможности, не ограниченные рамками существующего дизайна, а разработчикам — возможность экспериментировать.
  • Когда стоит модернизировать: В большинстве случаев создавать приложение с нуля не нужно. Модернизация существующего приложения позволяет использовать гибкость и масштабируемость облачной среды, не делая дополнительные инвестиции и не продумывая заново бизнес-логику. Используя такие приемы, как контейнеризация, расширение применения, разбиение на части или перепроектирование, можно преобразовать традиционное монолитное приложение в приложение для облака.

И при создании новых облачных приложений, и при модернизации существующих, разработчики должны следовать одному набору базовых принципов:

  • Использовать архитектуру микросервисов: Приложение должно быть разделено на микросервисы, обеспечивающие поэтапное, автоматизированное, непрерывное улучшение приложения без необходимости приостанавливать его работу.
  • Упаковывать в контейнеры для обеспечения гибкости и масштабируемости: Контейнер содержит код программы и все зависимости, позволяя выполнять программу где угодно. Это обеспечивает максимальную гибкость и переносимость в гибридной мультиоблачной среде. Кроме того, контейнеры позволяют быстро изменять масштаб в большую или меньшую сторону, используя определенное пользователем ПО контейнеров Kubernetes.
  • Внедрение методологии Agile: Методология Agile ускоряет создание и улучшение приложений. Разработчики могут быстро вносить изменения с учетом отзывов пользователей, чтобы рабочая версия приложения в максимальной степени соответствовала их ожиданиям.

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

1 IBM. Корпоративный взгляд на облачную разработку. 2018.

Загрузите весь отчет (PDF; 2,2 МБ)

Более 75% организаций столкнутся с перебоями в работе цифровой инфраструктуры из-за недостаточной квалификации сотрудников.2

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

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

Все это доступно в IBM Garage — методологии комплексного обслуживания, которая предоставляет клиентам надежный, воспроизводимый, безопасный способ для успешного внедрения облачных технологий.

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

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

Посетить Garage

2 Gartner. Прогнозы на 2018 год: ИТ-операции. 2018.

Загрузите весь отчет (PDF; 2,2 МБ)

Источник: https://www.ibm.com/cloud/ru-ru/yourcloud/build-cloud-native/article/5/

Создание облачного приложения

Создание облачных приложений

Начну с того, что вчера мне прислали приглашение на участие в тестировании Windows Azure.
И теперь я хочу поделиться своим первым опытом создания облачных приложений.

Это будет простой хостинг изображений.

Тем, кто еще не знает, что такое Windows Azure, я предлагаю прочитать статью «What is the Azure Services Platform?» на английском или короткое описание в википедии на русском.

Итак, приступим.
Windows Azure CTP содержит следующие ограничения:

  • Общее время вычислений: 2000 часов (≈ 83 дня в режиме 24/7)
  • Объем хранилища: 50 Гб
  • Максимальный трафик хранилища: 20 Гб/день

У меня появилась возможность создавать 2 вида компонентов сервиса:

  • Storage Account — распределенное хранилище для больших объемов структурированной и неструктурированной информации,
  • Hosted Services — 64-битное вычислительное облако Azure Services Platform, которое и является хостингом для облачных приложений.

Вот как выглядит интерфейс создания новых компонентов:
Так как решено было сделать хостинг изображений, то для этой задачи потребовалось создать одно хранилище данных (Storage1) и одно облако (Cloud1).

Для работы с Windows Azure в Visual Studio 2008 необходимо установить:

В комплекте SDK содержится архив с уже готовыми примерами. Один из них (Thumbnails) я взял за основу. Также в SDK есть проект StorageClient, который состоит из классов, позволяющих легко работать с хранилищем. Подключим его в качестве Reference к сервису.

Например, код загрузки данных в Blob-хранилище будет выглядеть так:// Получаем доступ к хранилищу по данным в конфигурационном файле BlobStorage blobStorage = BlobStorage.Create(StorageAccountInfo.

GetDefaultBlobStorageAccountFromConfiguration());

// Создание нового контейнера “photogallery” с публичными правами

BlobContainer blobContainer = blobStorage.GetBlobContainer(“photogallery”).CreateContainer(null, ContainerAccessControl.Public);
// Свойства контейнера
BlobProperties props = new BlobProperties(“NameOfFileInContainer”) { ContentType = upload.PostedFile.ContentType };
// Загрузка данных в контейнер
blobContainer.CreateBlob(props, new BlobContents(upload.FileContent), true);
После установки Windows Azure Tools в Visual Studio появятся новые типы проектов: Создадим Worker Cloud Service. Это будет сервис, который будет работать в облаке и генерировать превью для изображений. Шаблон кода его класса имеет вид:public class WorkerRole : RoleEntryPoint   {

    public override void Start()

    {

      // This is a sample worker implementation. Replace with your logic.

      RoleManager.WriteToLog(“Information”, “Worker Process entry point called”);

      while (true)

      {         Thread.Sleep(10000);

        RoleManager.WriteToLog(“Information”, “Working”);

      }     }

    public override RoleStatus GetHealthStatus()

    {

      // This is a sample worker implementation. Replace with your logic.

      return RoleStatus.Healthy;     }   }Как видно, сервис каждые 10 секунд пишет в лог, что он работает. Подключим к проекту Reference с классами работы с хранилищем (Microsoft.Samples.ServiceHosting.StorageClient):

Чтобы не угромождать статью, код сервиса приводить не буду, вот ссылка на него.

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

  • Загрузка проекта в Staging для проверки
  • Перевод проверенного проекта в Production

После публикации картина выглядит так: Теперь у нас есть сервис, который работает в облаке, и хранилище. Осталось последнее – сделать веб-оболочку.

Тут всё более привычно, обойдемся одной aspx-страницей (Default.aspx, Default.aspx.cs), которые я разместил на хостинге от мастерхост (хотя можно было и это поручить облаку).

На странице размещена одна UpdatePanel, на которой содержится ContentTemplate с ссылками-превьюшками. UpdatePanel обновляется каждые 5 секунд, получая все созданнные превью в хранилище на текущий момент. Ну очень простой хостинг картинок. =)

Всё готово: tinyakov.net/img.

Можно приступить к самому интересному — к тестированию! График нагрузки на хранилище я буду время от времени обновлять.

Поделиться:
Нет комментариев

    Добавить комментарий

    Ваш e-mail не будет опубликован. Все поля обязательны для заполнения.