Что означает нативное облако в эпоху контейнеров

Опубликовано: 5 Марта, 2023
Что означает нативное облако в эпоху контейнеров

Облачные приложения — это относительно новый термин, появившийся благодаря относительно новой технологии. Чтобы приложение было родным для облака, оно должно быть разбито на микросервисы, которые работают независимо друг от друга, а также не связаны с какими-либо физическими ресурсами. При отсутствии каких-либо физических ресурсов облачные приложения, в свою очередь, должны зависеть от сред облачных вычислений, которые, по сути, представляют собой слабо связанные облачные сервисы. Эти облачные сервисы, которые позволяют разбивать приложения на микросервисы и упаковывать их в контейнеры, преимущественно имеют открытый исходный код. Некоторые из ведущих инструментов этого движения, такие как Kubernetes, Prometheus и gRPC, являются частью CNCF (Фонд облачных вычислений). Другими словами, CNCF — это набор инструментов с открытым исходным кодом, которые позволяют создавать современные облачные приложения.

CNCF

Облачные приложения относятся к приложениям, которые «упакованы в контейнеры, динамически планируются и ориентированы на микросервисы». CNCF является частью Linux Foundation и была объявлена в июле 2015 года для продвижения передовых технологий для создания облачных приложений и сервисов. Хотя изначально он был основан, чтобы внести некоторый порядок в мир Kubernetes, с тех пор он превратился в управляемую и курируемую группу из девяти многообещающих проектов с открытым исходным кодом, которые, по сути, представляют собой все, что вам нужно, чтобы войти в мир контейнеров и микросервисной архитектуры. В число членов-основателей входят Google, Huawei, Mesosphere, CoreOS, Docker, Twitter, RedHat и IBM, и это лишь некоторые из них.

Скорость, свобода и доверие

«Скорость, свобода и доверие» — вот что Алексис Ричардс, генеральный директор Weaveworks, говорит, это все, что касается облачных технологий. Привязка к поставщику происходит, когда поставщики общедоступного облака поставляют инструменты с открытым исходным кодом, объединяя их в сервисы, которые нельзя переносить между облаками и которые плохо интегрируются с другими важными инструментами, составляющими стек разработки программного обеспечения. В эпоху контейнеров, когда переносимость — это все, облачные приложения должны быть кросс-совместимыми, и это один из основных принципов CNCF. Хотя CNCF курирует и продвигает надежный набор инструментов для современной архитектуры, он категорически против привязки к поставщику и обеспечивает совместимость всех приложений на всех платформах.
Изображение 590

Скорость релизов

Одним из первых примеров облачного веб-приложения с высокой доступностью является Netflix, и они сделали это в то время, когда люди все еще заказывали DVD по почте, а живое видео по запросу было неслыханно. Они сосредоточились на двух вещах: высокой доступности и скорости улучшения своих услуг. Обе эти характеристики являются ключевыми для того, какими должны быть облачные приложения. Доступность — это то, что представляет собой облако, и выпуск обновлений в бешеном темпе находится в центре методологии DevOps, а также в центре внимания большинства современных приложений.

Свобода переключения поставщиков

Чтобы еще больше подчеркнуть этот момент, было бы большим разочарованием, если бы вы создали инструмент до такой степени, что он почти идеально работает в Azure, но вы обнаружите, что вы не можете легко перейти на AWS, если бы захотели. Теперь вы можете не захотеть переходить на AWS, но привязка к поставщику — или теперь привязка к облаку, как мы ее называем, — это один из главных врагов, для борьбы с которым были созданы Linux Foundation и сообщество разработчиков открытого исходного кода. Одна из мантр CNCF заключается в том, что «каждый должен иметь возможность использовать любое программное обеспечение в любом облаке». Это на уровне приложений, потому что люди хотят иметь возможность использовать свои приложения где угодно. Инструменты с открытым исходным кодом, которые не являются кроссплатформенными, на самом деле не являются открытым исходным кодом и ограничивают пользователя. Это противоположно свободе.

Доверие между участниками

Как упоминалось ранее, CNCF изначально создавалась как дом для Kubernetes и была основана Linux Foundation, которая отвечает за защиту Linux. Первоначально CNCF была создана для борьбы с проблемой предприятий, которые используют открытый исходный код (Kubernetes) для предоставления услуг с целью его монетизации. Теперь, чтобы проект с открытым исходным кодом заслужил доверие предприятия, он должен быть поддержан фондом поставщиков, где никто не контролирует его или не имеет большинства. Вот почему важно, чтобы проекты с открытым исходным кодом управлялись несколькими организациями, а не одним поставщиком, чтобы не было «творцов королей» или ни одной компании, которая имела бы чрезмерное влияние. Это помогает создать долгосрочное доверие, поскольку отдельная корпорация может исчезнуть в одночасье, и тогда вы, по сути, останетесь с бесполезным инструментом.

Открытый исходный код от нескольких поставщиков

Все согласны с тем, что для удовлетворения потребностей современного постоянно требовательного рынка облачных вычислений на конкурентной основе требуется сообщество из всех частей мира и всех слоев общества. Это неоднократно демонстрировалось успехом ряда проектов с открытым исходным кодом, таких как Kubernetes, Prometheus, OpenTracing, FreeCAD, Apache Spark, Git и им подобных. Проекты с открытым исходным кодом одного поставщика, скорее всего, будут управляться разработчиками с повесткой дня, исходящей от поддерживающих их венчурных капиталистов, в то время как проекты от нескольких поставщиков, скорее всего, будут создавать инструменты исключительно для полезности и производительности.

В то время как в прошлом сообщества и фонды часто занимались стандартами и протоколами, с облачными приложениями это чрезвычайно сложно. Это связано с тем, что отрасль не только молода, но и находится на переднем крае современных технологий, а изменения и прорывы происходят каждый месяц. Однако, в отличие от традиционных фондов, CNCF не занимается установлением стандартов или решением того, как все должно выглядеть через пять лет, потому что, откровенно говоря, это невозможно. Однако речь идет о том, чтобы все сообщество поддерживало несколько проектов с открытым исходным кодом, которые, по их мнению, имеют потенциал и полезны при переходе к облаку. Сейчас у них девять проектов: Kubernetes, Prometheus, OpenTracing, Fluentd, Linkerd, gRPC, CoreDNS, containerd и rkt. Что интересно и что их всех объединяет, так это то, что все они кросс-совместимы и могут работать друг с другом, даже если все они независимы.

Преимущество домашнего облака

Что касается того, что сегодня означают облачные приложения, то они означают приложения с беспрецедентным уровнем переносимости и гибкости. Слово «родной» означает «домашняя территория», что означает преимущество домашней команды, и это то, что означает облачное рождение, приложение, работающее на своей домашней территории, со значительными преимуществами. Одним из преимуществ домашней команды является то, что вас поддерживает весь город. Облачные приложения работают не только сами по себе, но и на основе инструментов и приложений, поддерживаемых крупнейшими именами на предприятии, такими как Cisco, Red Hat, IBM, Google, Intel, Docker и Dell.

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