Миграция в облако, начавшаяся в
Cloud native — это один из тех терминов, которые подхватила волна шумихи в технологической прессе. Он настолько популярен сейчас, что некоторые компании перекрашивают свои продукты и услуги в нативно-облачные, чтобы оседлать новую волну.
К сожалению, многие из них не понимают, что такое cloud native, и не осознают основных преимуществ этой концепции. Однако, подобно акулам, учуявшим кровь в воде, эти компании ощущают близость второй облачной революции.
Для начала давайте разберемся с путаницей. Многие воспринимают термин «нативная облачная разработка» именно так, как он звучит: создание программных систем, которые являются «родными» для определенного облачного провайдера. Таким образом, они могут использовать его собственные службы безопасности, управления, баз данных и т. д., что позволяет приложению получить максимальную отдачу от данного провайдера.
В отличие от этого, «неродные» системы отвязаны от конкретного облачного провайдера и не используют преимущества его нативных сервисов. Их эксплуатация может стоить немного дороже, и вам придется писать или интегрировать сервисы самостоятельно.
В то же время растет число людей и организаций, которые рассматривают cloud native в другом разрезе — как развивающийся архитектурный паттерн.
В чем ценность нативного облака?
Cloud native можно считать настоящей революцией в том, как мы проектируем, создаем, развертываем и эксплуатируем системы. Другими словами, этот новый подход переосмысливает то, как мы получаем бóльшую ценность от создаваемых нами программных систем и как мы используем их на всех платформах, а не только в публичных облаках.
Cloud Native Computing Foundation (CNCF) так объясняет этот новый взгляд на ценность cloud native: «Технологии cloud native позволяют организациям создавать и запускать масштабируемые приложения в современных динамичных средах, таких как публичные, частные и гибридные облака». Возможно, лучше сказать, что нативные облачные приложения могут быть развернуты в различных облачных средах, включая традиционные платформы. Это является основой формирующегося предложения cloud native и определяет, вокруг чего поднялась шумиха.
CNCF работает с более широкой идеей: если вы реализуете cloud native правильно, вы обеспечите динамичное и масштабируемое поведение приложений на многих платформах, включая публичные облака, частные облака и даже унаследованные системы. Многих удивляет поддержка унаследованных систем и даже старых частных облаков. Однако идея заключается в том, чтобы продвигать метод достижения цели, не зацикливаясь на базовой технологии.
Контейнеры и микросервисы
Как правило, нативный облачный подход требует сложного использования контейнеров, контейнерной оркестровки и микросервисов, чтобы избежать привязки к вендору как желательный результат перехода к cloud native.
Новые нативные облачные системы обычно определяют общий стек, где частные и публичные облака являются основой, который может размещаться на любых платформах. К таким платформам относятся унаследованные вычисления, периферийные вычисления и любые новые платформы, которые могут появиться в будущем. Опять же, идея заключается в том, чтобы строить все по-другому, ориентируясь на «общую картину» конечных целей разрабатываемой системы. Если сосредоточиться только на конкретной технологии, ценность будет недолговечной.
Учитывая все вышесказанное, мы можем определить cloud native как подход, обладающий следующими преимуществами:
- Он использует архитектурные преимущества, предлагаемые публичными облаками, без необходимости запускаться на конкретных облаках.
- Архитектура представляет собой набор независимых микросервисов, которые могут существовать в одном или нескольких легких контейнерах.
- Основополагающие платформы, включая облака, обычно не предоставляют сервисы непосредственно приложению, вместо этого они используют уровень абстракции.
- Нативные облачные контейнеры позволяют упростить развертывание на любой платформе, включая унаследованные системы, облачные вычислительные платформы или даже удаленные устройства.
- Нативные облачные контейнеры могут получать общие сервисы, поддерживаемые платформами, в пределах возможностей платформы, таких как масштабируемость.
- Общие сервисы, такие как безопасность, управление и операции, могут быть определены для всех контейнеров и использованы как при непосредственном взаимодействии с платформой, так и без него.
- Нативные облачные контейнеры могут перемещаться с платформы на платформу, например, из облака в облако или из облака в унаследованную систему, без существенного изменения поведения ПО и моделей хранения данных.
Что представляет собой нативная облачная революция?
Многие из перечисленных выше преимуществ можно найти в прежних архитектурных подходах, таких как разработка и оркестровка контейнеров, или во вспомогательных технологиях, таких как сервисы, предлагаемые большинством провайдеров публичных облаков.
Новым здесь является то, что мы рассматриваем cloud native как концепцию «как», а не «что»: это не технология, это то, как мы подходим к проектированию, разработке и развертыванию систем, независимо от того, какую технологию и/или платформу мы используем.
Новые «горячие» облачные технологии для создания и развертывания приложений — это не то, на чем фокусируется cloud native. Концепция нативного облака ориентируется на ряд открытых технологий, которые сами по себе не являются истинными решениями. Однако в сочетании с конкретными архитектурными паттернами, которые мы перечислили выше, они становятся паттернами проектирования cloud native.
Целью нативного облака является создание программных систем, которые с большей вероятностью решат поставленные бизнес-задачи и будут более долговечными, чем традиционные подходы к разработке приложений. Cloud native также означает, что мы больше не фокусируемся на технологии разработки или платформах. Одним из побочных эффектов перехода к нативной облачной разработке является то, что теперь мы определяем, как что-то будет сделано, а не какую технологию мы используем.
Cloud native является сложной загадкой для тех поставщиков, как облачных, так и не облачных, которые хотят определить свою технологию как предоставляющую конкретную ценность, отличную от конкурентов. Этот подход заставит многих поставщиков технологий и провайдеров облачных услуг искать способы совместной работы, чтобы обеспечить разработку и внедрение в условиях, когда множество различных технологических конфигураций и решений становятся частью конечного нативно-облачного решения.
Необходимые элементы нативной облачной революции
Эта революция будет возможна только в том случае, если несколько составляющих встанут на свои места.
Во-первых, нативное облако должно быть принято теми, кто отвечает за создание и развертывание систем. Независимо от того, насколько убедительным выглядит этот подход, фактор принятия будет наиболее труднодостижимым, поскольку направление развития технологического рынка всегда трудно предсказать.
Во-вторых, вендоры и облачные провайдеры должны работать вместе, чтобы предоставлять взаимозаменяемые и в основном открытые технологии. Они не могут продолжать фокусироваться на уникальных способах выполнения задач, которые выходят за рамки нативного облака. Вместо этого они должны сосредоточиться на том, как их клиенты хотели бы строить системы, и на конечных целях этих систем.
Когда эти две составляющие будут на своих местах, понятие нативной облачной революции приобретет свое истинное значение. Cloud native — это кардинальное изменение того, как мы создаем и развертываем системы, двигаясь в будущее. Более того, цель этой революции — устранить зависимость от отдельных технологий.
