Cloud-native подход – очередной шаг эволюции в эре облачных вычислений

Экспертный материал

Денис Афанасьев | Руководитель направления облачных решений

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

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

Самый большой вопрос из всех может звучать так: «Как моя организация может добиться успеха с применением облачных технологий и какое влияние этот подход окажет на мои бизнес-цели?»

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

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

Развитие и эволюция

Прежде чем мы перейдем к тому, что означает Сloud Native и как оптимизировать ценность, получаемую от современных информационных систем. Рассмотрим в целом  эволюцию в ИТ.

Дооблачная эра

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

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

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

Облачная эра

Разработка ПО. Гибкая разработка и подходы DevOps стали альтернативой традиционному подходу для более быстрой разработки качественного и оптимизированного ПО.

Инфраструктура. Общедоступное облако сделало ресурсы, требуемые для запуска приложений, доступными как услуга (парадигма XaaS). Компании стали пользоваться облаком и получили возможность сосредоточиться на своем основном бизнесе и разгрузить части своей ИТ-инфраструктуры платя только за потребляемые ресурсы.

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

Cloud Native эра

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

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

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

Переход к эре cloud native подчеркивает тот факт, что простой миграции или «поднятия и переноса» приложений в облако уже недостаточно для использования истинных облачных преимуществ облака. Фактически организации, которые внедряют облачные технологии, должны ориентироваться на следующие принципы: 

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

• Применение подхода «инфраструктура как код» (IaC) и современных методов развертывания и конвейерной разработки;

• Использование преимуществ концепции PaaS (платформа как услуга);

• Разработка приложений уже ведется в концепции cloud native.

Добро пожаловать в Cloud Native эру

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

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

Cloud native подход = лучшие инновации + расширенная трансформация бизнеса + улучшенный клиентский опыт.

Приложения, созданные для работы в облачных средах, имеют следующие характеристики:

• применяются микросервисы и контейнеры;

• разработаны и развернуты на распределенных вычислительных ресурсах для получения эффекта масштаба;

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

• имеют простоту развертывания и управления по запросу;

• устойчивы к сбоям;

• применяют «сервисное сито» (service mesh) - абстрактного слоя инфраструктуры, определяющего взаимодействие между различными микросервисами.

• используют API. Одним из способов обеспечить совместимость между платформами и упростить сложность являются API. Наиболее распространенным API в отрасли является RESTful API;

• используют комплексный мониторинг.

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

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

Хорошо реализованная Cloud Native стратегия позволяет компаниям двигаться быстрее и получать лучшие результаты за счет:

• улучшения клиентского опыта и повышение лояльности;

• создания конкурентного преимущества за счет повышенной гибкости и более быстрого выхода на рынок;

• преобразования отрасли за счет внедрения новых бизнес-моделей;

• снижения затрат за счет повышения операционной эффективности;

• повышения прибыли за счет увеличения ценности для клиентов и создания новых источников дохода.

Переход на Cloud Native — процесс не быстрый

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

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

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

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

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

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

Переход к микросервисам

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

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

 

Рис.1. Архитектура микросервисов

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

• увеличить скорость и масштаб развертывания ПО;

• улучшить масштабируемость приложений и эластичность реакции на нагрузку;

• повысить гибкость бизнеса;

• улучшить контроль и изоляцию сбоев и ошибок в коде;

• применять небольшие эффективные команды разработки.

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

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

При всех преимуществах микросервисной архитектуры есть и недостатки:

• сложность архитектуры микросервисов;

• трудность трекинга зависимостей между микросервисами;

• размер микросервиса имеет критическое значение для функционирования всего приложения;

• успешная разработка требует продуманного и своевременного взаимодействия между командами DevOps. 

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

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

Использование Cloud Native DevOps

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

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

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

• рост инноваций, основанных на инсайтах, которые бросают вызов конкурентам;

• быстрое внедрение новых технологий;

• развитие организационной культуры, поощряющей смелые идеи;

• четкое соответствие бизнес-целям и результатам.

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

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

Оптимизация облачных сред

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

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

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

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

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

 

Рис.2. Схема кластера Kubernetes

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

Сбор обратной связи при разработке

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

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

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

Заключение

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