Бесплатная миграция IT-инфраструктуры в облако

Что такое Cloud Native?

Александр Бархатов
Александр Бархатов
Технический писатель
08 мая 2024 г.
165
9 минут чтения
Средний рейтинг статьи: 5

Ранее при разработке программного обеспечения использовалась монолитная архитектура, при которой приложение представляло собой одно неделимое целое и располагалось на одном физическом сервере. Со временем появился новый подход к архитектуре — микросервисный, при котором разрабатываемое приложение разбивается на несколько независимых подпрограмм, называемых сервисами. Так как количество приложений значительно выросло, то выросла и сама инфраструктура, а точнее количество используемых серверов или виртуальных машин. Помимо затрат на разработку, у 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, необходимо выполнить четыре основных шага.

  1. Подготовка

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

  1. Разработка новой модели 

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

  1. Доработка нового функционала

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

  1. Тестирование

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

Сравнение приложений Cloud Native и On-premises

В последнее время основными способами развертывания программного обеспечения являются Cloud Native, при котором приложения разрабатываются и публикуются исключительно в облаке, и On-premises, при котором приложения разворачиваются локально в своей инфраструктуре. Рассмотрим отличия между двумя этими способами.

Приложения Cloud Native

Приложения On-premises

Отсутствие привязки к ОС

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

Зависимость от ОС

On-premises-решения зависят от используемой операционной системы. Также в некоторых случаях может потребоваться дополнительная настройка операционной системы.

Гибкая масштабируемость

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

Возможные трудности при масштабируемости

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

Данные и инфраструктура находятся под контролем поставщика услуг

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

Полный контроль над вашими данными и инфраструктурой

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

Необходим постоянный доступ во внешнюю сеть для получения доступа к данным

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

Доступ к данным без доступа ко внешней сети

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

Меньшее количество сотрудников для обслуживания физических серверов

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

Наличие дополнительных квалифицированных сотрудников для обслуживания физических серверов

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

Наличие поддержки со стороны поставщика облака

При возникновении инфраструктурных проблем вы сможете обратиться за помощью к поставщику облака.  

Самостоятельное решение инфраструктурных проблем

При сбоях в инфраструктуре все возникающие проблемы решаются вашими силами.

Зависимость от поставщика

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

Независимость от третьей стороны

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

Меньше вариантов кастомизации

В первую очередь это касается дополнительных компонентов, например, СУБД или брокеров сообщений. Облачные провайдеры могут предоставлять не весь спектр функциональности программ.

Больше вариантов кастомизации

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

Отсутствие вложений в IT-инфраструктуру

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

Необходимо выделять отдельный бюджет для IT инфраструктуры

При проектировании собственной инфраструктуры вам потребуется определенный бюджет.

Заключение

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

08 мая 2024 г.
165
9 минут чтения
Средний рейтинг статьи: 5
Пока нет комментариев