что такое cloud native

Путеводитель CNCF по решениям Open Source (и не только) для cloud native

8 марта фонд CNCF, созданный при The Linux Foundation, представил значительно обновлённую версию своей «карты ранее неизведанной территории облачных (cloud native) технологий» — Cloud Native Landscape 2.0. Собранная в рамках этого проекта информация ориентирована на компании, которые только начинают свой путь в мир инфраструктуры для cloud native-приложений, и призвана познакомить их с множеством имеющихся решений с открытым исходным кодом и не только.

Путь к cloud native

Для начала разберёмся, что же называют «cloud native» в фонде с созвучным названием (Cloud Native Computing Foundation). В понимании CNCF это приложения (и сопутствующая инфраструктура), которые наделены следующими свойствами:

Итак, рекомендуемый в CNCF Trail Map — процесс освоения облачной инфраструктуры — выглядит следующим образом:

Cloud Native Landscape

Сам же «ландшафт» — это довольно обширный каталог продуктов, не ограниченных проектами самой CNCF и даже свободными лицензиями (хотя большинство из них относятся к Open Source). Для удобства они разбиты по категориям:

(Полное изображение в GitHub.)

(Примечание: в этой таблице можно также увидеть, что Kubernetes стал первым в истории CNCF проектом, достигнувшим статуса graduated, т.е. «выпускника». Об этом было объявлено совсем недавно — 6 марта. Все остальные проекты CNCF относятся к категориям incubating и inception.)

Интерактивный Landscape

Кроме того, со второй версией Cloud Native Landscape в CNCF запустили интерактивную веб-версию каталога, доступную как landscape.cncf.io (для serverless — s.cncf.io).

Контент для Landscape

Каталоги Cloud Native Landscape генерируются на основе данных, получаемых из специального YAML, к которому добавляются сведения из внешних сервисов (информация о проекте в GitHub, финансовые показатели из Crunchbase и Yahoo Finance), в результате чего получается новый YAML, а также JSON, который уже и используется приложением для вывода данных.

В CNCF приветствуют добавление новых проектов, что делается через pull request к упомянутому landscape.yml. У проекта должно быть хотя бы 250 звёздочек на GitHub и он должен соответствовать одной из имеющихся категорий (подробнее о предъявляемых требованиях см. здесь).

Основная таблица Cloud Native Landscape, как и её аналог для serverless, и упомянутый ранее Trail Map, доступны в разных форматах. Все данные проекта распространяются на условиях свободной лицензии Apache License 2.0 за исключением графических файлов и YAML (они лицензированы под Creative Commons Attribution 4.0), сведений от Crunchbase и логотипов проектов/продуктов.

Источник

Особенности cloud-native архитектуры

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

Таким образом, используя преимущества модели облачных вычислений, подход Cloud-native объединяет в себе концепции микросервисов, контейнеризации, непрерывной доставки и DevOps:

Атрибуты cloud-native приложений

Рассмотрим каждый из атрибутов подробнее: 1. Cloud-native приложения управляются с помощью процессов DevOps. Взаимодействие разработчиков и IT-подразделений позволят вам поставлять действительно качественное ПО, решающее проблемы клиентов. Разработка, тестирование и релизы новых продуктов осуществляются быстро, часто и последовательно. Реализуются принципы Agile — гибкой методологии разработки. То есть обеспечивается непрерывная поставка программных продуктов, постоянный и автоматизированный выпуск в production небольших партий ПО. Все шаги надёжны и стандартизированы, поэтому появляется возможность делать релизы чаще и с наименьшими рисками. Плюс, обеспечивается быстрое получение обратной связи от пользователей. 2. Cloud-native приложения разрабатываются с использованием микросервисного архитектурного подхода. Каждый сервис работает в собственном процессе и реализует определённую бизнес-возможность. Каждый микросервис можно развернуть, масштабировать, обновить либо перезапустить вне зависимости от прочих служб. Это значит, что при обновлении приложений неудобства клиентам не причиняются.
Правда, у микросервисной архитектуры существуют и минусы, ведь распределённая система сложнее на системном уровне. 3. Cloud-native приложения упакованы в контейнеры. Основная идея контейнера — упаковать приложение в один исполняемый пакет, изолировав его от среды и прочих приложений. Считается, что контейнеры более эффективны и работают быстрее стандартных виртуальных машин. При виртуализации на уровне ОС один экземпляр операционной системы динамически распределяется между одним либо несколькими изолированными контейнерами, причём у каждого из них есть уникальная файловая система и собственный объём выделенных ресурсов. Кроме того, контейнеры отлично подходят для развёртывания отдельных микроуслуг.

Почему бизнес отдаёт предпочтение cloud-native-приложениям?

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

Есть и другие плюсы: 1. Облако как конкурентное преимущество. В случае с cloud-native облако используется не в целях экономии IT-ресурсов, а в качестве инструмента развития бизнеса. Также стоит заметить, что в наше время успешны те компании, которые способны быстро разработать и поставить необходимое приложение с учётом клиентских запросов. 2. Фокус на стабильность. Если IT-инфраструктура устаревает и выходит из строя, могут пострадать сервисы. В облачной среде уделяется особое внимание архитектуре, что обеспечивает повышенную устойчивость. Облака помогают создавать системы, находящиеся в сети вне зависимости от сбоев. 3. Ещё больше гибкости. Современные провайдеры предлагают широкие возможности за приемлемую цену. Но компании не готовы останавливаться на одной инфраструктуре. А благодаря платформе, поддерживающей облачные технологии, можно разрабатывать и запускать сервисы и приложения там, где это выгоднее бизнесу без привязки к какому-нибудь одному облачному провайдеру. 4. Оптимизация IT-процессов с учётом бизнеса. Если выполнить автоматизацию IT-операций, подразделения компании превратятся в небольшие, но специализированные команды, отвечающие текущим бизнес-приоритетам. Автоматизация уменьшит рутину, снизит риски отказов по причине человеческих факторов, сократит время простоя, избавит от потребности в специалистах по ручным процессам. 5. Высокая скорость разработки. Cloud-native приложения позволяют быстро создавать и выводить на рынок продукты, тестировать гипотезы. От идеи до реализации может уйти от нескольких часов до нескольких дней, вместо нескольких месяцев, как это обычно бывает.

Источник

Что такое Cloud Native и почему это важно?

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

В своё время публичные облачные инфраструктуры изменили инвестиционные тенденции рынка, и показали, что можно использовать инфраструктуру, как настоящий и прежде всего эффективный инструмент. Cloud Native разработка тоже по своей сути меняет приоритет с того “Где размещаются приложения” на то “Как они разрабатываются”.

Почему публичные облака выгоднее своего железа, загружайте и читайте в нашем материале “Iaas vs Свое Железо”.

Что такое Cloud Native?

Как создаются Cloud Native приложения?

Для создания и использования cloud native приложений организациям необходимо переосмысливать подход к системе разработки и внедрять основополагающие принципы cloud native.

De Novo предоставляет набор инструментов Cloud Container Infrastructure для удобного управления кластерами Kubernetes непосредственно в облаках De Novo.

Почему Cloud Native приложения важны?

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

Облачные нативные приложения против традиционных корпоративных приложений

CLOUD NATIVE APPLICATIONS

TRADITIONAL ENTERPRISE APPLICATIONS

Предсказуемые. Cloud Native приложения соответствуют рамочной программе или «контракту», разработанному для обеспечения максимальной устойчивости к внешним воздействиям за счет предсказуемого поведения. Автоматизированная, управляемая контейнерами инфраструктура, используемая в облачных платформах, определяет способ написания программного обеспечения. Хорошим примером такого «контракта» является 12 принципов, впервые задокументированных как 12-факторное приложение.Непредсказуемые. Традиционные приложения не всегда могут реализовать все преимущества работы из-за уникального способа архитектуры или разработки каждого отдельно взятого приложения. Этот тип приложения часто занимает больше времени на сборку, выпускает обновления в больших, нечастых партиях, масштабируется, а не выходит, и предполагает, что зависимые сервисы обеспечивают высокую доступность.Отсутствие привязки к ОС. Оригинальная архитектура облака дает разработчикам возможность абстрагироваться от базовых зависимостей инфраструктуры. Вместо того чтобы настраивать, исправлять и обслуживать операционные системы, команды сосредоточиваются на программном обеспечении. Наиболее эффективным средством абстракции является формализованная платформа.Зависимость от ОС. Традиционная архитектура приложения позволяет разработчикам строить тесные зависимости между приложением и лежащими в его основе ОС, оборудованием, хранилищем и службами поддержки. В отличие от cloud native модели, эти зависимости делают миграцию и масштабирование приложения в новой инфраструктуре сложным и рискованным делом.Мощности правильного размера. Родная платформа облачных приложений автоматизирует инициализацию и настройку инфраструктуры, динамически распределяя и перераспределяя ресурсы во время развертывания в соответствии с потребностями приложения. На основе собственного времени выполнения в такой архитектуре оптимизируется управление жизненным циклом приложения, включая масштабирование в соответствии с потребностями, использование ресурсов, оркестровку по доступным ресурсам и восстановление после сбоев с минимальным временем простоя.Потребность в большей мощности. Традиционные ИТ-специалисты разрабатывают специальное, индивидуальное инфраструктурное решение («снежинка») для приложения, откладывая развертывание приложения. Решение часто имеет чрезмерный размер и построено для удовлетворения наихудших прогнозов по пропускной способности с минимальной способностью масштабирования за пределы проектных ограничений для удовлетворения спроса.Уровень взаимодействия. Cloud Native архитектура улучшает концепцию DevOps, облегчает взаимодействие людей, процессов и инструментов. Это в свое время увеличивает сотрудничество между командами разработчиков и операционными командами, чтобы ускорить и сгладить передачу готового кода приложения в производство.Понижение уровня взаимодействия. В традиционных приложениях используется передача готового кода приложения от разработчиков к операциям. Организационные приоритеты имеют приоритет над потребительской ценностью, что приводит к внутренним конфликтам, медленной и скомпрометированной доставке и низкому моральному духу команд.Continuous delivery. Команды IT-специалистов выпускают индивидуальные обновления программного обеспечения, как только они готовы. Организации, выпускающие программное обеспечение, быстро получают более тесный цикл обратной связи и могут более эффективно реагировать на потребности клиентов. Непрерывная поставка лучше всего работает с другими смежными подходами, включая разработку на основе тестирования и непрерывную интеграцию.Waterfall разработка. IT-команды выпускают программное обеспечение периодически, обычно с интервалами в недели или месяцы, несмотря на то, что многие компоненты релиза, возможно, были готовы гораздо раньше, без каких-либо зависимостей. Функции, которые клиенты хотят или нуждаются в них, задерживаются, и бизнес упускает возможности конкурировать, завоевывать клиентов и увеличивать доходы.Независимость. Архитектура микроуслуг разбивает приложения на небольшие, свободно связанные и независимо работающие сервисы. Эти сервисы разрабатываются небольшими независимыми группами разработчиков и делают возможным частое обновление, масштабирование и отказоустойчивость/перезапуск без влияния на другие сервисы.Зависимость. Монолитные архитектуры объединяют множество разрозненных сервисов в единый пакет развертывания, вызывая ненужные зависимости между сервисами и приводя к потере гибкости во время разработки и развертывания.Быстрое восстановление. Рабочее время контейнера и оркестратор обеспечивают динамическое наложение виртуализации высокой плотности, идеально подходящее для архитектуры микросервисов. Оркестровка динамически управляет размещением контейнеров на кластере для обеспечения эластичного масштабирования и восстановления/перезапуска в случае отказа приложения или инфраструктуры.Медленное восстановление. Традиционные инструменты сами по себе являются более медленными и менее эффективными основами для микропроцессорных приложений из-за более медленного запуска/остановки и накладных расходов операционной системы для каждой отдельно взятой ВМ.

Пользуйтесь Cloud Native с умом

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

Определяйте приоритеты рабочих нагрузок для модернизации

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

Решайте, создавать или покупать платформу

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

В нашей прошлой статье мы составили рейтинг самых необычных ЦОД в мире.

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

Источник

Общие сведения о приложениях, ориентированных на облако

Еще один день в офисе, работающий над «следующим большим предметом».

Кольца целлфоне. Это ваш удобный набор сотрудников — тот, кто звонит ежедневно с новыми возможностями.

Но на этот раз это отличается: запуск, капитал и масса финансирования.

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

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

Как вы будете строить его?

Если следовать инструкциям за последние 15 лет, скорее всего, будет построена система, показанная на рис. 1,1.

Рис. 1-1. Традиционный монолитный дизайн

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

Поздравляем! Вы только что создали монолитное приложение.

Не все — плохое. Монолитные части предлагают некоторые различные преимущества. Например, они просты в.

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

Однако в некоторый момент вы можете приступить к неудобному. Вы обнаружите, что вы теряете контроль над приложением. По мере того, как пройдет время, чувство становится более интенсивным, и в конечном итоге вы вводите состояние, называемое Fear Cycle :

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

Рис. 1-2. Разработка в собственном облаке

Обратите внимание, что приложение разбивается по набору небольших изолированных микрослужб. Каждая служба самодостаточна и инкапсулирует свой собственный код, данные и зависимости. Каждый из них развертывается в контейнере программного обеспечения и управляется контейнером Orchestrator. Вместо большой реляционной базы данных каждая служба владеет хранилищем данных, тип которого зависит от потребностей, связанных с данными. Обратите внимание, что некоторые службы зависят от реляционной базы данных, а другие — в базах данных NoSQL. Одна служба хранит свое состояние в распределенном кэше. Обратите внимание, как весь трафик проходит через службу шлюза API, отвечающую за маршрутизацию трафика к основным серверным службам и применение множества перекрестных проблем. Что важнее всего, приложение использует все преимущества функций масштабируемости, доступности и устойчивости, имеющихся в современных облачных платформах.

Облачные вычисления

Странно. Мы только что использовали этот термин — облако Native. Первое, что можно сделать, — «что именно это значит?» Еще одна отрасль, термин конкоктед поставщиками программного обеспечения, на рынке дополнительных материалов?»

К счастью, это далеко не так, и надеюсь, что эта книга поможет убедить вас.

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

В отличие от непрерывных устанавливать ориентиры, которые применяют нашу отрасль, облачный машинный код — реальная. Рассмотрим облачный машинный фундамент (кнкф), который является консорциумом более чем 400 основных организаций. Его Устав заключается в том, чтобы обеспечить повсеместную облачную вычислительную производительность по технологиям и облачным стекам. Как одна из самых влиятельные групп с открытым исходным кодом, она содержит множество самых быстро увеличивающихся проектов с открытым исходным кодом в GitHub. К этим проектам относятся Kubernetes, Prometheus, Helm, делегатыи gRPC.

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

Итак, что именно является облачным машинным кодом? Перейдем, не стоит, и позвольте нам помочь вам исследовать новый мир.

Источник

Облачные приложения и Kubernetes: основы Cloud Native

Поскольку облачные платформы, инфраструктура и инструментарий быстро развивались с момента первой публикации «Двенадцати факторов», а масштабные облачные миграции и развертывания сформировали сообщество разработчиков программного обеспечения, появилась расширенная методология под названием Cloud Native. Приложения Cloud Native (или просто облачные приложения) контейнеризованы, сегментированы на микросервисы и предназначены для динамического развертывания и эффективного запуска такими системами оркестровки, как Kubernetes.

Какие приложения считаются Cloud Native?

Для эффективного развертывания, запуска и управления в облачном приложении должны быть реализованы несколько основных методов Cloud Native. Например, приложение Cloud Native должно:

Чтобы стимулировать распространение основных методов Cloud Native, а также поддержку и продвижение растущего Cloud Native Landscape, под эгидой Linux Foundation был создан фонд Cloud Native Computing Foundation (CNCF), который призван способствовать росту и развитию высококачественных проектов (например, Kubernetes). Среди других проектов, которые поддерживает CNCF, – Prometheus (система мониторинга и база данных временных рядов, часто развертываемая вместе с Kubernetes) и FluentD (сборщик данных и логов, часто используемый для реализации распределенного логирования в больших кластерах).

Согласно текущей документации CNCF определяет три базовых свойства, которые лежат в основе приложений Cloud Native:

Масштабирование с помощью Kubernetes на примере Snappy

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

В этой серии статей мы модернизируем Snappy таким образом:

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

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

Источник