Ранее при разработке программного обеспечения использовалась монолитная архитектура, при которой приложение представляло собой одно неделимое целое и располагалось на одном физическом сервере. Со временем появился новый подход к архитектуре — микросервисный, при котором разрабатываемое приложение разбивается на несколько независимых подпрограмм, называемых сервисами. Так как количество приложений значительно выросло, то выросла и сама инфраструктура, а точнее количество используемых серверов или виртуальных машин. Помимо затрат на разработку, у IT-департаментов появились затраты на обслуживание парка возросшего количества серверов. Однако время не стоит на месте, и все чаще используются облачные сервисы. Для приложений, разрабатываемых и публикуемых в облачной инфраструктуре, был придуман принцип 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 большой упор делается на автоматизацию и использование практик DevOps, а также на внесение значимых изменений в конфигурацию приложений с минимальными усилиями.
Организация CNCF выпускает и поддерживает огромное количество программ с открытым исходным кодом, в том числе и для работы с Cloud Native. С полным списком утилит, которые поддерживаются и развиваются сообществом CNCF, можно ознакомиться по ссылке.
Среди преимуществ Cloud Native обычно выделяют следующие:
Как правило, чтобы перейти к использованию Cloud Native, необходимо выполнить четыре основных шага.
Подготовка
На этапе подготовки следует провести тщательный анализ архитектуры и функциональности разрабатываемого вами приложения. Сюда входит окончательный переход на микросервисную архитектуру, асинхронная обработка данных, внедрение оркестрации.
Разработка новой модели
В связи с переходом на новый облачный подход потребуется разработка технической модели, в которой будет представлено описание, как приложение будет взаимодействовать с новой платформой.
Доработка нового функционала
После того как был составлен подробный план и проведена предварительная оценка, необходимо доработать ваше приложение, учитывая функционал и бизнес-логику. При этом стоит отметить, что универсального способа не существует, и все будет зависеть только от вашего разрабатываемого продукта.
Тестирование
После того как переход был успешно завершен, необходимо провести тестирование и проверку функциональности вашего приложения.
В последнее время основными способами развертывания программного обеспечения являются Cloud Native, при котором приложения разрабатываются и публикуются исключительно в облаке, и On-premises, при котором приложения разворачиваются локально в своей инфраструктуре. Рассмотрим отличия между двумя этими способами.
Приложения Cloud Native |
Приложения On-premises |
Отсутствие привязки к ОС При использовании облачных систем и благодаря технологии виртуализации приложение можно развернуть значительно быстрее в заранее подготовленной для этого операционной системе со стороны облачного провайдера. |
Зависимость от ОС On-premises-решения зависят от используемой операционной системы. Также в некоторых случаях может потребоваться дополнительная настройка операционной системы. |
Гибкая масштабируемость Интерфейсы облаков спроектированы таким образом, чтобы можно было быстро и легко увеличить ресурсы вашего приложения или инфраструктуры. Также вам не придется самим покупать необходимое «железо». |
Возможные трудности при масштабируемости On-premises-приложения используют вашу собственную инфраструктуру. Соответственно, вам необходимо заранее продумать, сколько мощностей вам понадобится, а также как вы будете масштабировать ваши приложения. |
Данные и инфраструктура находятся под контролем поставщика услуг Так как у заказчика есть только доступ до арендуемых сервисов, все остальные компоненты, включая используемые приложения и их данные, находятся под контролем поставщика облака. |
Полный контроль над вашими данными и инфраструктурой Вся используемая инфраструктура, приложения и их данные находятся под вашим контролем. |
Необходим постоянный доступ во внешнюю сеть для получения доступа к данным Облака привязаны ко внешней сети. Чтобы получить доступ до ваших данных, вам всегда потребуется доступ во внешнюю сеть. |
Доступ к данным без доступа ко внешней сети Так как вся инфраструктура находится в вашем распоряжении, вам не нужен доступ во внешнюю сеть (кроме случаев, когда вы разрабатываете веб-приложения, используемые в сети Интернет). |
Меньшее количество сотрудников для обслуживания физических серверов В связи с тем, что аппаратной инфраструктурой занимается сам поставщик облака, вам не потребуются дополнительные сотрудники. |
Наличие дополнительных квалифицированных сотрудников для обслуживания физических серверов Сюда относят, например, архитекторов по проектированию систем, администраторов баз данных. Как как On-premises-приложения используют вашу собственную инфраструктуру, вам потребуются квалифицированные кадры, которые будут заниматься поддержкой вашего оборудования и программного обеспечения. |
Наличие поддержки со стороны поставщика облака При возникновении инфраструктурных проблем вы сможете обратиться за помощью к поставщику облака. |
Самостоятельное решение инфраструктурных проблем При сбоях в инфраструктуре все возникающие проблемы решаются вашими силами. |
Зависимость от поставщика У каждого поставщика свои требования к обеспечению безопасности, использованию лицензий и т.д. В некоторых случаях вам придется подстраиваться под поставщика с невозможностью изменений в некоторых аспектах. |
Независимость от третьей стороны Так как вся инфраструктура, приложения и данные находятся в вашем распоряжении, у вас больше вариантов принятия решений. |
Меньше вариантов кастомизации В первую очередь это касается дополнительных компонентов, например, СУБД или брокеров сообщений. Облачные провайдеры могут предоставлять не весь спектр функциональности программ. |
Больше вариантов кастомизации Так как продукт полностью развернут у вас, вы можете использовать дополнительный функционал для расширения или модификации существующего продукта. |
Отсутствие вложений в IT-инфраструктуру При использовании облачных решений всю необходимую инфраструктуру предоставляет облачный провайдер. Соответственно, вам не нужно выделять дополнительный бюджет на покупку физических мощностей, и платите вы только за те ресурсы, которые используете. |
Необходимо выделять отдельный бюджет для IT инфраструктуры При проектировании собственной инфраструктуры вам потребуется определенный бюджет. |
Приложения, которые используют модель Cloud Native, отличаются устойчивостью, простотой управления и возможностью бесперебойного внесения изменений. С помощью Cloud Native разработчики могут без особых затруднений достаточно часто вносить значимые изменения в разрабатываемый продукт.