Что такое Cloud Native?
Ранее при разработке программного обеспечения использовалась монолитная архитектура, при которой приложение представляло собой одно неделимое целое и располагалось на одном физическом сервере. Со временем появился новый подход к архитектуре — микросервисный, при котором разрабатываемое приложение разбивается на несколько независимых подпрограмм, называемых сервисами. Так как количество приложений значительно выросло, то выросла и сама инфраструктура, а точнее количество используемых серверов или виртуальных машин. Помимо затрат на разработку, у IT-департаментов появились затраты на обслуживание парка возросшего количества серверов. Однако время не стоит на месте, и все чаще используются облачные сервисы. Для приложений, разрабатываемых и публикуемых в облачной инфраструктуре, был придуман принцип Cloud Native. В данной статье мы рассмотрим, что такое Cloud Native, его принцип работы, а также преимущества, которые предлагает данный подход.
Что такое Cloud Native
Cloud Native — это подход, предназначенный для разработки, публикации и развертывания приложений в облачной инфраструктуре. В работе Cloud Native используются инструменты и технологии, которые имеют поддержку для работы с облачными технологиями. При использовании Cloud Native разрабатываемые приложения легко модифицировать и обновлять, не нанося ущерба пользователям. Cloud Native используется исключительно для облачной разработки.
Развитием Cloud Native занимается сообщество Cloud Native Computing Foundation (CNCF), основанное в 2015 году. Основная цель CNCF заключается в продвиженииopen-source-инструментов для контейнеризации и облачных платформ. Сообщество регулярно проводит вебинары, живые выступления и конференции, а также публикует собственные материалы. На сегодняшний день в развитии CNCF принимают участие такие крупные компании, как Amazon, Apple, Boeing, Cisco, Google, Huawei, IBM, Intel, Microsoft, Oracle, Red Hat, VMware и многие другие.
Ключевые особенности приложений, использующих подход Cloud Native
Приложения, которые разрабатываются с помощью Cloud Native, используют такие компоненты и подходы, как:
- Контейнеризация — подход при разработке программного обеспечения, при котором код приложения, его зависимости и прочие компоненты упаковываются в изолированную среду под названием контейнер. Контейнер не зависит от хостовой операционной системы и может быть запущен в любой операционной системе, где установлена программа для запуска контейнеров (например, Docker).
- Оркестрация — процесс автоматического управления, а также увеличения инфраструктурных компонентов и приложений. В контексте микросервисной архитектуры термин «оркестрация» обычно применяется к контейнерным приложениям.
- Микросервисная архитектура — вариант разработки программного обеспечения, при котором разрабатываемый продукт разбивается на несколько отдельных независимых компонентов. Основное преимущество микросервисной архитектуры заключается в том, что при выходе из строя одного компонента, из строя не выходит вся система. Также микросервисные приложения легче обслуживать, обновлять и масштабировать.
- API — Application Programming Interface, программный интерфейс приложения. Под API подразумевают способы и правила общения между приложениями. API позволяет расширять функционал разрабатываемых приложений.
В Cloud Native большой упор делается на автоматизацию и использование практик DevOps, а также на внесение значимых изменений в конфигурацию приложений с минимальными усилиями.
Организация CNCF выпускает и поддерживает огромное количество программ с открытым исходным кодом, в том числе и для работы с Cloud Native. С полным списком утилит, которые поддерживаются и развиваются сообществом CNCF, можно ознакомиться по ссылке.
Преимущества Cloud Native
Среди преимуществ Cloud Native обычно выделяют следующие:
- Масштабируемость. При использовании облачных технологий масштабируемость инфраструктуры и приложений выполняется автоматически. Благодаря этому система адаптируется к нагрузкам и грамотно использует свои ресурсы.
- Автоматизация. Разработка приложений ведется по методологии DevOps. Соответственно, используются концепции CI/CD — непрерывного развертывания и непрерывной доставки.
- Отказоустойчивость. Благодаря облачным технологиям, открывается путь к созданию отказоустойчивых и высокодоступных приложений. Обновления и добавление новых функций в разрабатываемые приложения не приводят к простоям, тем самым команды разработки и эксплуатации могут увеличивать ресурсы приложений и инфраструктуры в наиболее нагруженные периоды, чтобы обеспечить высокое качество обслуживания клиентов.
- Снижение издержек. Так как за «железную» инфраструктуру отвечает облачный провайдер, то снижаются возможные проблемы, связанные с аппаратной инфраструктурой.
- Прозрачная модель оплаты. При использовании облачных технологий клиент всегда знает, за что он платит. Для это используется модель оплаты Pay-as-you-go (оплата по мере использования). Соответственно, оплата идет только за потребляемые ресурсы.
Процесс перехода на Cloud Native
Как правило, чтобы перейти к использованию Cloud Native, необходимо выполнить четыре основных шага.
-
Подготовка
На этапе подготовки следует провести тщательный анализ архитектуры и функциональности разрабатываемого вами приложения. Сюда входит окончательный переход на микросервисную архитектуру, асинхронная обработка данных, внедрение оркестрации.
-
Разработка новой модели
В связи с переходом на новый облачный подход потребуется разработка технической модели, в которой будет представлено описание, как приложение будет взаимодействовать с новой платформой.
-
Доработка нового функционала
После того как был составлен подробный план и проведена предварительная оценка, необходимо доработать ваше приложение, учитывая функционал и бизнес-логику. При этом стоит отметить, что универсального способа не существует, и все будет зависеть только от вашего разрабатываемого продукта.
-
Тестирование
После того как переход был успешно завершен, необходимо провести тестирование и проверку функциональности вашего приложения.
Сравнение приложений Cloud Native и On-premises
В последнее время основными способами развертывания программного обеспечения являются Cloud Native, при котором приложения разрабатываются и публикуются исключительно в облаке, и On-premises, при котором приложения разворачиваются локально в своей инфраструктуре. Рассмотрим отличия между двумя этими способами.
|
Приложения Cloud Native |
Приложения On-premises |
|
Отсутствие привязки к ОС При использовании облачных систем и благодаря технологии виртуализации приложение можно развернуть значительно быстрее в заранее подготовленной для этого операционной системе со стороны облачного провайдера. |
Зависимость от ОС On-premises-решения зависят от используемой операционной системы. Также в некоторых случаях может потребоваться дополнительная настройка операционной системы. |
|
Гибкая масштабируемость Интерфейсы облаков спроектированы таким образом, чтобы можно было быстро и легко увеличить ресурсы вашего приложения или инфраструктуры. Также вам не придется самим покупать необходимое «железо». |
Возможные трудности при масштабируемости On-premises-приложения используют вашу собственную инфраструктуру. Соответственно, вам необходимо заранее продумать, сколько мощностей вам понадобится, а также как вы будете масштабировать ваши приложения. |
|
Данные и инфраструктура находятся под контролем поставщика услуг Так как у заказчика есть только доступ до арендуемых сервисов, все остальные компоненты, включая используемые приложения и их данные, находятся под контролем поставщика облака. |
Полный контроль над вашими данными и инфраструктурой Вся используемая инфраструктура, приложения и их данные находятся под вашим контролем. |
|
Необходим постоянный доступ во внешнюю сеть для получения доступа к данным Облака привязаны ко внешней сети. Чтобы получить доступ до ваших данных, вам всегда потребуется доступ во внешнюю сеть. |
Доступ к данным без доступа ко внешней сети Так как вся инфраструктура находится в вашем распоряжении, вам не нужен доступ во внешнюю сеть (кроме случаев, когда вы разрабатываете веб-приложения, используемые в сети Интернет). |
|
Меньшее количество сотрудников для обслуживания физических серверов В связи с тем, что аппаратной инфраструктурой занимается сам поставщик облака, вам не потребуются дополнительные сотрудники. |
Наличие дополнительных квалифицированных сотрудников для обслуживания физических серверов Сюда относят, например, архитекторов по проектированию систем, администраторов баз данных. Как как On-premises-приложения используют вашу собственную инфраструктуру, вам потребуются квалифицированные кадры, которые будут заниматься поддержкой вашего оборудования и программного обеспечения. |
|
Наличие поддержки со стороны поставщика облака При возникновении инфраструктурных проблем вы сможете обратиться за помощью к поставщику облака. |
Самостоятельное решение инфраструктурных проблем При сбоях в инфраструктуре все возникающие проблемы решаются вашими силами. |
|
Зависимость от поставщика У каждого поставщика свои требования к обеспечению безопасности, использованию лицензий и т.д. В некоторых случаях вам придется подстраиваться под поставщика с невозможностью изменений в некоторых аспектах. |
Независимость от третьей стороны Так как вся инфраструктура, приложения и данные находятся в вашем распоряжении, у вас больше вариантов принятия решений. |
|
Меньше вариантов кастомизации В первую очередь это касается дополнительных компонентов, например, СУБД или брокеров сообщений. Облачные провайдеры могут предоставлять не весь спектр функциональности программ. |
Больше вариантов кастомизации Так как продукт полностью развернут у вас, вы можете использовать дополнительный функционал для расширения или модификации существующего продукта. |
|
Отсутствие вложений в IT-инфраструктуру При использовании облачных решений всю необходимую инфраструктуру предоставляет облачный провайдер. Соответственно, вам не нужно выделять дополнительный бюджет на покупку физических мощностей, и платите вы только за те ресурсы, которые используете. |
Необходимо выделять отдельный бюджет для IT инфраструктуры При проектировании собственной инфраструктуры вам потребуется определенный бюджет. |
Заключение
Приложения, которые используют модель Cloud Native, отличаются устойчивостью, простотой управления и возможностью бесперебойного внесения изменений. С помощью Cloud Native разработчики могут без особых затруднений достаточно часто вносить значимые изменения в разрабатываемый продукт.