Быстрое и гибкое приложение без сбоев и багов — уже не рыночное преимущество, а параметр по умолчанию. Сейчас пользователи ждут от бизнеса постоянных инноваций в функциональности и интерфейсе. Для компаний это означает необходимость выбирать подходящие инструменты для новых задач, наращивать мощности, увеличивать расходы на оборудование и его обслуживание, что ведёт к росту и усложнению ИТ-инфраструктур. С этими вызовами бывает проще справляться, если приложение работает не на локальных серверах, а нативно в облаке, то есть является Cloud Native.
В этой статье мы расскажем, что такое Cloud Native, из чего обычно состоят нативные облачные приложения и какие у них особенности, а также какие преимущества Cloud Native даёт компаниям.
Что такое Cloud Native
Ниже — выдержка из определения Cloud Native от Cloud Native Computing Foundation (CNCF):
Нативные облачные (Cloud Native) технологии позволяют организациям создавать и запускать масштабируемые приложения в современных динамических средах, таких как публичные, частные и гибридные облака.
Таким образом, Cloud Native — это не только про запуск приложений в облаке, но и про такое их создание, при котором приложения изначально рассчитаны на работу в облаке.
Сразу отметим, что к Cloud Native не относятся приложения, которые:
- работали на локальных серверах, а затем были минимально, без существенных изменений в архитектуре, адаптированы под облако и перенесены в него;
- работают в смешанной среде — частично локально, частично в облаке.
«Пересборка» локального приложения в Cloud Native теоретически возможна, но это технически сложный, длительный и дорогой процесс. Поскольку это ознакомительный материал, мы не будем затрагивать здесь эту тему.
В определении от CNCF также сказано, что пример применения подхода Cloud Native — это микросервисная архитектура, API, сетка сервисов (service mesh), контейнеры и неизменяемая инфраструктура. Эти сущности — части и особенности архитектуры нативного облачного приложения. Ниже мы рассмотрим их подробнее.
Как устроено Cloud Native-приложение
Микросервисы. Cloud Native-приложение обычно разделено на микросервисы — небольшие независимые части, каждая из которых выполняет отдельную функцию. Например, в приложении по доставке еды могут быть микросервисы, отвечающие за меню, оформление и обработку заказов, оплату, доставку и отзывы клиентов.
В приложение, построенное на микросервисах, проще вносить изменения, поскольку микросервисы не зависят друг от друга. За разработку каждого отвечает отдельная инженерная команда, что позволяет повысить скорость внесения изменений. Например, одна из команд разработки может добавить в приложение новый способ доставки заказа и при этом не бояться, что эти изменения затронут остальные микросервисы и приложение целиком. Даже при сбое в одном из микросервисов все остальные продолжат работать.
API. Несмотря на то что микросервисы независимы, они должны взаимодействовать, чтобы приложение работало. Для этого предназначен механизм API (Application Programming Interface, программный интерфейс приложения). Для каждого микросервиса прописано, какие данные и в каком формате он может отдавать и принимать. Например, микросервис оплаты может получать стоимость заказа и платёжные данные клиента, а отдавать подтверждение оплаты.
Сетка сервисов (service mesh). Если API — это возможность связи между микросервисами, то service mesh — сама связь и наблюдение за ней. Service mesh мониторит трафик между микросервисами, и если один из них выходит из строя, перенаправляет запросы на резервный. Кроме того, сетка сервисов позволяет отслеживать проблемы во взаимодействии микросервисов, чтобы разработчики могли оперативно реагировать на них. Service mesh также может шифровать данные, которыми обмениваются микросервисы, тем самым делая приложение более защищённым от атак.
Контейнеры. Микросервисы упаковываются в контейнеры — изолированную среду, в которую кроме кода самого микросервиса помещается всё, что необходимо ему для работы, например, файлы библиотек и фреймворков.
В крупных приложениях контейнеров много, поэтому ими необходимо управлять. Для этого используются системы оркестрации контейнеров, например Kubernetes. На базе Kubernetes также строятся платформы для всестороннего управления приложениями, такие как Deckhouse Kubernetes Platform.
Неизменяемая инфраструктура. Это не часть архитектуры Cloud Native-приложения, а скорее её особенность. Неизменяемость подразумевает, что если приложению для работы требуется больше ресурсов, то серверы, на которых оно развёрнуто, не меняются под новые потребности, а просто удаляются, и приложение автоматически «переселяется» на новые, более мощные серверы. Такой подход позволяет уйти от ручного развёртывания и сократить число человеческих ошибок.
Чем Cloud Native-приложение отличается от on-premise-приложения
В отличие от Cloud Native-приложений, которые разработаны специально для облака и работают в нём, on-premise-приложения развёрнуты на собственных серверах компании. Этим обусловлены различия в архитектуре, подходе к разработке и эксплуатации.
Архитектура и разработка. Особенности архитектуры Cloud Native-приложений позволяют легко вносить изменения в отдельные компоненты и добавлять новые по мере необходимости. On-premise-приложения нередко разрабатываются как монолитные структуры, где изменения в одной части могут повлиять на весь проект, что усложняет развитие продукта.
Автоматизация. Для Cloud Native-подхода характерна высокая степень автоматизации процессов. Важную роль здесь играют практики DevOps, например, непрерывная интеграция и доставка (CI/CD). Они помогают обеспечить те самые частые обновления приложения. On-premise-системам автоматизация тоже не чужда, но процесс обновления может быть более сложным и рискованным.
Масштабируемость. Это одно из ключевых преимуществ Cloud Native-подхода. Облака позволяют быстро и легко увеличить ресурсы для работы приложения. В случае с физическими серверами так не получится — придётся обновлять существующие серверы или покупать новые, а также искать место в дата-центрах, что может быть непросто.
Управление расходами. При использовании облаков компании обычно платят за фактически использованные ресурсы. Это обеспечивает гибкость управления бюджетом. Например, в периоды высокого трафика можно быстро получить дополнительные мощности, а затем от них отказаться. В случае on-premise преобладают капитальные затраты на приобретение оборудования и его обслуживание. При этом часть серверов может простаивать в моменты, когда нагрузки не такие высокие.
Обслуживание и обновление инфраструктуры. В случае использования публичных облаков, ответственность за обслуживание и обновление «железа» лежит на облачном провайдере. Это позволяет компаниям сосредоточиться на улучшении своего продукта, а не поддержке серверов. В случае on-premise ответственность за все аспекты надёжности инфраструктуры ложится на сам бизнес, что потребует наличия в штате отдельных специалистов. Но при этом on-premise обеспечивает полный контроль за данными и инфраструктурой, без которого не могут работать компании с особо высокими требованиями к безопасности.
Есть и промежуточное решение — частные облака. Их стоит рассмотреть, если вы хотите реализовать Cloud Native-подход на собственном железе и получить лучшее от двух миров. С реализацией вам могут помочь инженеры «Фланта».
Итого, Cloud Native-подход предлагает бизнесу гибкость и возможность быстрого реагирования на изменения. Тогда как on-premise обеспечивает полный контроль за данными и инфраструктурой, но связан с бо́льшими сложностями в поддержке.
Чем Cloud Native полезен компаниям
Cloud Native-подход позволяет компаниям создавать масштабируемые и отказоустойчивые приложения, которые эффективно используют ресурсы. Это увеличивает их надёжность и гибкость, позволяя бизнесу оперативно реагировать на изменения рынка и отвечать ожиданиям пользователей.
Микросервисная архитектура, свойственная Cloud Native-приложениям, повышает скорость разработки. С ней инженерные команды могут обновлять и изменять компоненты приложения независимо друг от друга, что упрощает внедрение новых функций и исправление ошибок.
Более того, облачные провайдеры и отдельные вендоры, такие как Deckhouse, предоставляют компаниям комплексные инструменты для разработки, развёртывания и наблюдения за работой Cloud Native-приложений. Они упрощают жизнь разработчикам и администраторам, сокращая количество операционных задач. Это помогает компаниям сконцентрироваться на улучшении своих продуктов и снизить time to market.
Облака позволяют компаниям более гибко управлять расходами на инфраструктуру: не нужно ждать поставки серверов и настраивать «железо». Однако следует учитывать, что при значительном росте компании использование облаков может стать более затратным по сравнению с собственными серверами. В таком случае можно рассмотреть гибридный подход, о котором рассказывал в одном из своих докладов Константин Аксёнов, руководитель разработки Deckhouse.
В конечном итоге, Cloud Native-подход предоставляет компаниям значительные конкурентные преимущества. Он позволяет создавать надёжные и масштабируемые решения, которые способны быстро адаптироваться к изменениям и обеспечивать успех бизнеса в быстро изменяющемся технологическом ландшафте.