Журнал об IT-бизнесе, технологиях и цифровой трансформации

Cloud-native приложения: быстро загружаются, снижают риски, стимулируют рост бизнеса Mail.ru Cloud Solutions
Mail.ru Cloud Solutions
  • 28 октября
  • Технологии

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

Популярное
Разработка
Путь к Kubernetes и его преимущества для разработки
Бизнес
Анализ больших данных в облаке: как бизнесу стать дата-ориентированным
Бизнес
Опыт Lamoda: как пережить «черную пятницу»

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

Статья подготовлена на основе перевода материала «Сloud-native Applications: Ship Faster, Reduce Risk, Grow Your Business» с дополнениями.

Что такое cloud-native приложения

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

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

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

Cloud-native объединяет концепции контейнеризации, микросервисов, непрерывной доставки и DevOps

Основные атрибуты 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. Лучше купить, а не разработать. Многие компании рассматривают создание собственной облачной платформы, комбинируя программное обеспечение для автоматизации с открытым исходным кодом и контейнерные технологии. Но вскоре выясняется, что для этого нужно больше компонентов, чем предполагалось, так как не все они могут совместно работать. Это задерживает старт работ над самими приложениями. Плюс добавляется еще один фактор — необходимость поддержки рабочей платформы. При использовании готовой облачной платформы можно сразу сосредоточиться на создании приложений, не думая об организации процесса и инфраструктуре.
Ссылка скопирована!

Что еще почитать про ИТ-бизнес