Облачно-ориентированные приложения (cloud-native applications, CNA) продолжают набирать популярность в ИТ-средах. Портал TechTarget рассказывает о том, что из себя представляют CNA и какие инструменты подходят для их создания и управления ими.

1. Разработка CNA

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

Фундамент CNA

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

Сборка, релиз, выполнение

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

Процессы

В облачных вычислениях несвязанные процессы без сохранения состояния (stateless processes) гораздо более масштабируемые и управляемые, чем процессы с сохранением состояния (stateful processes). Хотя создание процесса без сохранения состояния может показаться нелогичным, он подчеркивает зависимость от служб поддержки с сохранением состояния, которые позволяют масштабировать процессы без сохранения состояния (или полностью перезагружать) с минимальным риском для качества работы приложения.

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

Параллелизм

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

Одноразовость

Волатильная инфраструктура по сниженным ценам предлагается несколькими облачными провайдерами, к примеру, Amazon. Последний предлагает Spot-инстансы — это, по сути, продажа свободных в данный момент ресурсов, что позволяет удешевить масштабируемость, но сопряжено с риском внезапного удаления процессов. Несмотря на то, что это нечастое явление, оно подчеркивает важность самовосстанавливающихся CNA, разработанных для одноразового применения. В этой связи важно спланировать вероятность непредвиденных сбоев — это позволит обеспечить более плавные процедуры завершения работы и хранить любые данные с сохранением состояния без привязки к изолированному процессу. Проще всего для этих целей спроектировать самовосстанавливающуюся систему, прибегнув к инструментам оркестрации типа Kubernetes и надежному серверному бэкэнду — AWS Elastic Beanstalk или RabbitMQ.

2. Мониторинг и управление CNA

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

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

Мониторинг, логи, оповещения

Одним из самых больших преимуществ разработки CNA является доступ к инструментам управления и мониторинга облачного провайдера, таким как Amazon CloudWatch, Azure Monitor и Google Stackdriver. Мониторинг, логирование (журналирование данных) и получение оповещений о CNA и сервисах, на которые они полагаются, — основополагающий элемент управления облаком. Тем не менее, между ними существуют значительные различия.

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

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

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

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

Контейнеры

Контейнеры предназначены для придания согласованности различным ИТ-процессам, будь то разработка, тестирование, развертывание или хостинг. Несмотря на то, что их по большей части применяют для создания приложений, они обладают рядом преимуществ для управления нативными облачными приложениями. Такие инструменты для оркестровки контейнеров, как Kubernetes, в значительной мере облакозависимые, но их также можно применять в локальных средах. В сочетании с гибкостью облака инструменты оркестровки могут по мере необходимости применяться для автоматического масштабирования инфраструктуры. Кроме того, AWS, Microsoft и Google оказывают непосредственную поддержку оркестрации контейнеров, что позволяет уменьшить объем служебных данных, необходимых для начала работы.

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