Ко всем новостям

Что такое Cloud Native и зачем бизнесу внедрять этот подход?

Публикации в СМИ
15.12.2022

Источник: Cnews: "Технологический тренд 2022: как и зачем бизнесу внедрять подход Cloud Native"

Облачные технологии остаются одним из основных технологических трендов не первый год. Все больше компаний, от самых малых до крупнейших, из различных отраслей экономики выбирают облака как основу для построения собственной ИТ-инфраструктуры. По мнению Gartner, облачные вычисления и Cloud Native — одни из главных технологических трендов 2022 г. Несмотря на известность подхода и многообразие архитектурных и организационных паттернов, приемов разработки, в реальной жизни его грамотное применение зачастую нетривиально. О том, какие нюансы стоит учесть при переходе к Cloud Native, рассказывает Матвей Ульянычев, директор по развитию цифровой облачной платформы Platform V компании «СберТех».

Зачем бизнесу Cloud Native?

Говоря кратко, Cloud Native — это подход, при котором возможности и специфика облачных технологий учитываются не просто для организации и управления инфраструктурой, но во всех аспектах ИТ-систем — архитектуре, контуре безопасности, алгоритмах обработки данных, процессах DevOps.

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

Масштабируемость

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

Отказоустойчивость

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

Time-to-market

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

Гибкость

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

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

Оптимизация

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

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

Переход к Cloud Native

Шаг №1: Подготовить архитектуру

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

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

  1. Микросервисная архитектура дает возможность регулярно обновлять, масштабировать и перезапускать отдельные сервисы в составе приложений, не влияя на работу других приложений и их частей.
  2. Автоматизация предоставления и настройки инфраструктуры позволяет перераспределять ресурсы, предполагает простое масштабирование и минимизацию простоев в случае сбоев.
  3. Они более предсказуемы за счет того, что контейнеризация и автоматизацияинфраструктуры определяет, как будет развернуто и как будет функционировать программное обеспечение.
  4. Непрерывная доставка приложений как часть DevOps-конвейера позволяет выпускать обновления сразу по мере их готовности, ускорить получение обратной связи и эффективнее реагировать на потребности бизнеса.

Шаг №2: Определиться с подходом

Перед началом перехода к Cloud Native необходимо описать, какими свойствами должны будут обладать ваши приложения, какой эффект вы планируете получить, а также определить паттерны, которые должны применятся к инфраструктуре и приложению. Этот шаг позволит объяснить всей команде, как работать в новой парадигме, облегчить адаптацию новых сотрудников. Скорее всего, на каком-то этапе это выльется в полноценный стандарт по построению Cloud Native-архитектуры.

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

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

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

Шаг №3: Работа над приложениями

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

Поделюсь некоторыми примерами того, как можно добиться масштабирования приложений. Это можно сделать посредством увеличения количества реплик контейнеров с компонентами приложения, после чего масштабировать уже базы данных. Для обеспечения отказоустойчивости приложений можно сделать несколько кластеров оркестратора и протестировать, как приложение будет переживать возможный сбой дата-центра. Обеспечивать отказоустойчивость stateful-слоя можно посредством репликации СУБД или использования современных NewSQL баз данных. Можно использовать подход application sharding, который позволяет масштабировать не только слой вычислений, но и слой хранения. При этом вы получаете не только масштабируемость системы, но и минимизируете зоны поражения при сбое, так как каждая шарда (блок) полностью изолирует данные и вычисления и может переключаться на резервную копию абсолютно независимо.

Шаг №4: Проверки

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

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

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

Опыт Сбера

Мы сами прошли этот путь и создали Cloud Native-платформу — Platform V. Она позволяет нам быстро и эффективно разрабатывать бизнес-приложения любого масштаба и сложности. Платформа содержит все необходимые продукты, которые закрывают потребности разработки на всех уровнях архитектуры предприятия. В ней предусмотрено все для правильного создания приложений на базе микросервисов, управления ими, интеграции и мониторинга, организации управляемой среды для приложений. 

Например, на интеграционном слое мы предлагаем продукты для организации типовых моделей взаимодействия между сервисами — синхронные (Platform V Synapse Service Mesh), асинхронные (Platform V Synapse EDA), файловые (Platform V File Exchange), а также автоматического шардирования приложений (Platform V Application Sharding). Наш опыт и практики по созданию, проверке и сборке приложений, управлению жизненным циклом ПО мы объединили в рамках линейки продуктов Platform V Works.

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

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