Комментарии

Запускали новый маркетплейс с товарами широкого профиля. Долго выбирали CMS. Нам нужна была удобная и гибкая платформа, которая будет удобна и нашим сотрудникам, и продавцам, и которую мы сможем легко перенастроить под свои потребности.

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

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

Запускали новый маркетплейс с товарами широкого профиля. Долго выбирали CMS. Нам нужна была удобная и гибкая платформа, которая будет удобна и нашим сотрудникам, и продавцам, и которую мы сможем легко перенастроить под свои потребности.

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

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

Запускали новый маркетплейс с товарами широкого профиля. Долго выбирали CMS. Нам нужна была удобная и гибкая платформа, которая будет удобна и нашим сотрудникам, и продавцам, и которую мы сможем легко перенастроить под свои потребности.

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

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

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

Админ-панель очень удобно, логично, быстро. Нет необходимости использовать стороннюю CRM-систему для ведения заказов. Приняли заказ и в один клик: создали трекинг посылки — распечатали — отправили смс клиенту. Всё! Это очень удобно.

Добавление товара — все легко и понятно. Импорт-экспорт, вариативные товары позволяет делать все в разы быстрее чем на других CMS системах.

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

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

Админ-панель очень удобно, логично, быстро. Нет необходимости использовать стороннюю CRM-систему для ведения заказов. Приняли заказ и в один клик: создали трекинг посылки — распечатали — отправили смс клиенту. Всё! Это очень удобно.

Добавление товара — все легко и понятно. Импорт-экспорт, вариативные товары позволяет делать все в разы быстрее чем на других CMS системах.

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

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

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

Совершенно очевидно что этот год за нишевыми маркетплейсами. Последние несколько лет на рынке постоянно обсуждают нишевые маркетплейсы. Это активно растущий сегмент, который в ближайшие годы может достигнуть 1 трлн рублей, и очень важно не упустить этапы его развития. В 2023 году, когда большие интернет-магазины начали переходить на модель нишевых маркетплейсов, а в новостях каждую неделю появляются упоминания новых подобных площадок, не разбираться в них уже просто стыдно. Tinkoff eCommerce и Data Insight решили проанализировать эту молодую прогрессивную нишу и наконец отметить на карте рынка этих игроков.

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

А почему kafka с databricks не подходит? Hdfs вы имеете в виду не в облаке, а в в своих датацентрах?

Если выбирать DB as a Service, то Snowflake — отличный конкурент Redshift, BigQuery. Если же надо развернуть BigData кластер в облаке, то здесь Databricks даёт готовое «скучное» решение.

Проблема в том, что «скучное» решение не подходит, когда у вас на проекте Kafka, Cassandra и HDFS. Тут уж берёте Spark и пишете нескучный BigData код.

Так одно другого не исключает.

Допустим, у вас приложение, состоящее из двух бэков + базы.
И у вас Docker и Helm Chart лежат прямо с кодом, который они обсуждивают — у каждого из двух бэков свой набор.

Вы сделали изменение в брэнче одного из бэков. Он улетел в ориджин. Оттуда хуком пнулся Дженкинс, тот увидел новый брэнч, сгенерировал под него джобу (multibranch) и запустил pipeline. Один из шагов — деплоймент.

Допустим, Helm не используется. Деплоймент пойдет напрямую через apply deployment.yml в k8s. В таком случае получается, что деплоймент только одного бэка. То есть у вас прилетит бэк1 новый, а бэк2 будет стоять старый. Вместе они работать не рассчитаны, так как находятся на разных версиях.
А теперь тот же сценарий, но с Helm.

Вы ставите бэк1 через helm upgrade. Он по зависимостям вытягивает правильную версию базы (да может даже у вас там прибавилось еще других зависимостей даже) и правильную версию парного бэка2.

Другими словами, Helm дает вам консистентность на уровне всего приложения. И Git это никак не отменяет. Они даже никак не связаны. Вы, конечно, могли изначально в Jenkinfile захардкодить это поведение, но боюсь, это не так элегентно и гибко.

Хороший концепт и я его применяю с самого начала, как я стал использовать Kubernetes. И на фоне этого я не очень вижу как можно применять helm, а я так хотел.

Каковы основные выводы?

1. Разделение проблем: Обратите внимание, что оба пайплайна могут обмениваться данными, только обновляя Git или репозиторий образов. Другими словами, существует сетевой экран между CI и runtime-средой. Мы называем его «брандмауэром неизменяемости» (immutability firewall), поскольку все обновления репозиториев создают новые версии. Для дополнительной информации по данной теме обратитесь к слайдам 72-87 этой презентации.

2. Можно использовать любой CI- и Git-сервер: GitOps работает с любыми компонентами. Вы можете продолжать использовать свои любимые CI- и Git-серверы, репозитории образов и наборы тестов. Почти все остальные инструменты для Continuous Delivery на рынке требуют собственного CI-/Git-сервера или хранилища образов. Это может стать ограничивающим фактором в развитии cloud native. В случае GitOps вы можете использовать привычные инструменты.

3. События как инструмент интеграции: Как только данные в Git обновляются, Weave Flux (или оператор Weave Cloud) извещает об этом runtime. Всякий раз, когда Kubernetes принимает набор изменений, Git обновляется. Это обеспечивает простую модель интеграции для организации рабочих процессов для GitOps, как показано ниже.

GitOps предоставляет весомые гарантии обновления, необходимые любому современному инструменту CI/CD:

автоматизация;
конвергенция;
идемпотентность;
детерминизм.

Это важно, поскольку он предлагает модель эксплуатации для разработчиков в области cloud native.

— Традиционные инструменты для управления и мониторинга систем связаны с командами эксплуатации, действующими в рамках runbook'а (набора рутинных процедур и операций — прим. перев.), привязанного к конкретному deployment'у.

— В управлении cloud native-системами инструментарий для наблюдения является лучшим способом оценки результатов развертываний, чтобы команда разработчиков смогла оперативно реагировать на них.

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

Kubernetes CI/CD: сравнение GitOps с другими подходами

Как говорилось, GitOps — это две вещи:

1. Модель эксплуатации для Kubernetes и cloud native, описанная выше.

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

Для многих GitOps — это прежде всего рабочий процесс на основе Git push'ей. Нам он тоже нравится. Но это не все: давайте теперь посмотрим на CI/CD-пайплайны.

GitOps обеспечивает непрерывное развертывание (CD) под Kubernetes

GitOps предлагает механизм непрерывного развертывания, устраняющий необходимость в отдельных «системах управления развертываниями». Всю работу за вас выполняет Kubernetes.

— Обновление приложения требует обновления в Git'е. Это транзакционное обновление до желаемого состояния. «Развертывание» затем осуществляется внутри кластера самим Kubernetes на основе обновленного описания.

— Из-за специфики работы Kubernetes эти обновления конвергентны. Так обеспечивается механизм для непрерывного развертывания, в котором все обновления атомарны.

— Примечание: Weave Cloud предлагает GitOps-оператор, интегрирующий Git и Kubernetes и позволяющий выполнять CD путем согласования желаемого и текущего состояния кластера.

Без kubectl и скриптов

Следует избегать использования Kubectl для обновления кластера, а в особенности — скриптов для группирования команд kubectl. Вместо этого, с помощью GitOps-пайплайна пользователь может обновить свой кластер Kubernetes через Git.

Преимущества включают в себя:

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

2. Безопасность. Цитируя Kelsey Hightower: «Ограничьте доступ к кластеру Kubernetes инструментам автоматизации и администраторам, в обязанности которых входит его отладка или поддержание работоспособности». См. также мою публикацию о безопасности и соответствии техническим условиям, а также статью о взломе Homebrew путем хищения учетных данных из небрежно составленного Jenkins-скрипта.

3. Пользовательский опыт. Kubectl обнажает механику объектной модели Kubernetes, которая весьма сложна. В идеале пользователи должны взаимодействовать с системой на более высоком уровне абстракции. Здесь я снова сошлюсь на Kelsey и рекомендую посмотреть такое резюме.

Разница между CI и CD

GitOps улучшает существующие CI/CD-модели.

Современный CI-сервер представляет собой инструмент для оркестрации. В частности, это инструмент для оркестрации CI-пайплайнов. Они включают в себя build, test, merge to trunk и т. д. CI-серверы автоматизируют управление сложными многошаговыми пайплайнами. Распространенный соблазн состоит в том, чтобы создать скрипт для набора обновлений Kubernetes и выполнить его в качестве элемента пайплайна для push'а изменений в кластер. Действительно, так поступают многие специалисты. Однако это неоптимально, и вот почему.

CI должна использоваться для внесения обновлений в trunk, а кластер Kubernetes должен менять себя на основе этих обновлений, чтобы управлять CD «внутренне». Мы называем это pull-моделью для CD, в отличие от CI push-модели. CD является частью runtime-оркестрации.

Почему CI-серверы не должны делать CD через прямые обновления в Kubernetes

Не используйте CI-сервер для оркестрации прямых обновлений в Kubernetes в виде набора CI-заданий. Это анти-паттерн, о котором мы уже рассказывали в своем блоге.

Давайте вернемся к Алисе и Бобу.

С какими проблемами они столкнулись? CI-сервер Боба применяет изменения к кластеру, но если в процессе он упадет, Боб не будет знать, в каком состоянии находится (или должен быть) кластер и как его исправить. То же самое справедливо и в случае успеха.

Давайте предположим, что команда Боба собрала новый образ и затем пропатчила свои deployment'ы, чтобы развернуть образ (все это из CI-пайплайна).

Если образ соберется нормально, но пайплайн упадет, команде придется выяснять:

— Развернулось ли обновление?

— Запускаем ли мы новую сборку? Приведет ли это к ненужным побочным эффектам — с возможностью получить две сборки одного и того же неизменного образа?

— Стоит ли нам дождаться очередного обновления, прежде чем запустить сборку?

— Что именно пошло не так? Какие шаги нужно повторить (и какие из них безопасно повторять)?

Организация основанного на Git'е рабочего процесса не гарантирует, что команда Боба не столкнется с этими проблемами. Они по-прежнему могут ошибиться с push'ем коммита, с тегом или каким-либо другим параметром; однако этот подход все же гораздо ближе к явному все-или-ничего.

Подытоживая, вот почему CI-серверы не должны заниматься CD:

— Скрипты обновления не всегда детерминированы; в них легко наделать ошибок.

— CI-серверы не конвергируют к декларативной модели кластера.

— Сложно гарантировать идемпотентность. Пользователи должны разбираться в глубокой семантике системы.

— Сложнее провести восстановление после частичного сбоя.

Примечание о Helm'e: если вы хотите использовать Helm, мы рекомендуем объединить его с GitOps-оператором, таким как Flux-Helm. Это поможет обеспечить конвергентность. Сам по себе Helm не является ни детерминированным, ни атомарным.

GitOps как лучший способ осуществлять Continuous Delivery для Kubernetes

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

Модель эксплуатации для Kubernetes

Посмотрите на следующую диаграмму. Она представляет Git и хранилище образов контейнеров как общие ресурсы для двух оркестрированных жизненных циклов:

— Пайплайна непрерывной интеграции, который считывает и записывает файлы в Git и может обновлять репозиторий контейнерных образов.

— Пайплайна Runtime GitOps, сочетающего деплой с управлением и наблюдаемостью. Он считывает и записывает файлы в Git и может загружать образы контейнеров.

Представьте себе Алису. Она управляет компанией Family Insurance, предлагающей полисы по страхованию здоровья, автомобилей, недвижимости и туристическую страховку людям, которые слишком заняты, чтобы разбираться в нюансах контрактов самостоятельно. Ее бизнес начинался как сторонний проект, когда Алиса работала в банке как data scientist. Однажды она поняла, что может использовать передовые компьютерные алгоритмы для более эффективного анализа данных и формирования страховых пакетов. Инвесторы профинансировали проект, и теперь ее компания приносит более 20 млн долларов в год и стремительно растет. В настоящий момент в ней на различных должностях работают 180 человек. В их числе технологическая команда, которая занимается разработкой, обслуживанием сайта, базы данных и анализом клиентской базы. Команду из 60 человек возглавляет Боб — технический директор компании.

Команда Боба развертывает production-системы в облаке. Их основные приложения работают на GKE, пользуясь преимуществами Kubernetes в Google Cloud. Кроме того, они используют в работе различные инструменты для работы с данными и аналитики.

Family Insurance не собиралась использовать контейнеры, но заразилась энтузиазмом вокруг Docker. Вскоре специалисты компании обнаружили, что GKE позволяет развертывать кластеры для тестирования новых функций легко и непринужденно. Были добавлены Jenkins для CI и Quay для организации реестра контейнеров, написаны скрипты для Jenkins, которые push'или новые контейнеры и конфигурации в GKE.

Прошло некоторое время. Алиса и Боб разочаровались в производительности выбранного подхода и его влиянии на бизнес. Внедрение контейнеров не повысило производительность настолько, насколько надеялась команда. Иногда deployment'ы ломались, и было неясно, виноваты ли в этом изменения кода. Также оказалось тяжело отслеживать изменения конфигов. Часто приходилось создавать новый кластер и перемещать в него приложения, поскольку так было проще всего ликвидировать тот бардак, в который превратилась система. Алиса боялась, что ситуация ухудшится по мере развития приложения (кроме того, назревал новый проект на основе машинного обучения). Боб автоматизировал большую часть работы и не понимал, почему пайплайн по-прежнему неустойчив, плохо масштабируется и периодически требует ручного вмешательства?

Затем они узнали о GitOps. Это решение оказалось именно тем, что им было нужно для уверенного движения вперед.

Алиса и Боб уже не один год слышали о рабочих процессах на основе Git, DevOps и infrastructure as code. Уникальность GitOps в том, что он привносит ряд лучших практик — категоричных и нормативных — по реализации этих идей в контексте Kubernetes. Эта тема неоднократно поднималась, в том числе и в блоге Weaveworks.

Family Insurance решает внедрить GitOps. Теперь у компании есть автоматизированная модель эксплуатации, совместимая с Kubernetes и сочетающая скорость со стабильностью, поскольку они:

— обнаружили, что у команды вдвое выросла производительность и никто при этом не сходит с ума;

— перестали обслуживать скрипты. Вместо этого теперь они могут концентрироваться на новых функциях и совершенствовать инженерные методы — например, внедрить канареечные выкаты и улучшить тестирование;

— усовершенствовали процесс развертывания — теперь он редко ломается;

— получили возможность восстанавливать deployment'ы после частичных сбоев без ручного вмешательства;

— приобрели большую уверенность в системах поставки. Алиса и Боб обнаружили, что можно разделить команду на группы, занимающиеся микросервисами и работающие параллельно;

— могут вносить по 30-50 изменений в проект каждый день усилиями каждой группы и пробовать новые техники;

— легко привлекают к проекту новых разработчиков, которые имеют возможность накатывать обновления на production с помощью pull request'ов уже через несколько часов;

— легко проходят аудит в рамках SOC2 (на соответствие поставщиков услуг требованиям по безопасному управлению данных; подробнее читайте, например, здесь — прим. перев.).

Что произошло?

GitOps — это две вещи:

1. Модель эксплуатации для Kubernetes и cloud native. Она предоставляет набор лучших практик для развертывания, управления и мониторинга собранных в контейнеры кластеров и приложений. Элегантное определение в виде одного слайда от Luis Faceira:
2. Путь к созданию ориентированного на разработчиков окружения для управления приложениями. Мы применяем рабочий процесс Git как к эксплуатации, так и к разработке. Обратите внимание, что речь идет не просто о Git push, а об организации всего набора инструментов CI/CD и UI/UX.

Пара слов о Git

Если вы не знакомы с системами контроля версий и основанном на Git рабочим процессом, мы настоятельно рекомендуем изучить их. Поначалу работа с ветвями и pull request'ами может показаться черной магией, но плюсы стоят затраченных усилий. Вот хорошая статья для начала.

Как работает Kubernetes

В нашей истории Алиса и Боб обратились к GitOps, некоторое время проработав с Kubernetes. Действительно, GitOps тесно связан с Kubernetes — это модель эксплуатации для инфраструктуры и приложений, основанных на Kubernetes.

Что Kubernetes дает пользователям?

Вот некоторые основные возможности:

— В модели Kubernetes все можно описывать в декларативной форме.

— API-сервер Kubernetes принимает такую декларацию как вводные данные, а затем постоянно пытается привести кластер в состояние, описанное в декларации.

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

— В результате, внесение изменений в приложение и кластер происходит из-за:
изменений в образах контейнеров;
изменений в декларативной спецификации;
ошибок в среде — например, падений контейнеров.

Прекрасные способности Kubernetes по конвергенции

Когда администратор вносит изменения в конфигурацию, оркестратор Kubernetes будет применять их к кластеру до тех пор, пока его состояние не приблизится к новой конфигурации. Эта модель работает для любого ресурса Kubernetes и расширяется с помощью Custom Resource Definitions (CRDs). Поэтому deployment'ы Kubernetes обладают следующими чудесными свойствами:

— Автоматизация: обновления Kubernetes предоставляют механизм для автоматизации процесса применения изменений корректно и своевременно.

— Конвергенция: Kubernetes будет продолжать попытки обновлений до достижения успеха.

— Идемпотентность: повторные применения конвергенции приводят к тому же результату.

— Детерминизм: при достаточности ресурсов состояние обновленного кластера зависит только от желаемого состояния.

Как работает GitOps

Мы достаточно узнали о Kubernetes, чтобы объяснить принципы работы GitOps.

Давайте вернемся к командам Family Insurance, связанным с микросервисами. Чем им обычно приходится заниматься? Посмотрите на перечень ниже (если какие-то пункты в нем покажутся странными или незнакомыми — пожалуйста, повремените с критикой и оставайтесь с нами). Это всего лишь примеры рабочих процессов на основе Jenkins. Существует и множество других процессов при работе с другими инструментами.

Главное — мы видим, что каждое обновление заканчивается внесением изменений в конфигурационные файлы и репозитории Git. Эти изменения в Git приводят к тому, что «оператор GitOps» обновляет кластер:

1. Рабочий процесс: «Сборка Jenkins — ветка master».
Список задач:

Jenkins push'ит тегированные образы в Quay;
Jenkins push'ит конфиг и Helm-чарты в бакет master-хранилища;
Облачная функция копирует конфиг и чарты из бакета master-хранилища в Git-репозиторий master;
Оператор GitOps обновляет кластер.

2. Сборка Jenkins — ветка release или hotfix:

Jenkins push'ит нетегированные образы в Quay;
Jenkins push'ит конфиг и Helm-чарты в бакет staging-хранилища;
Облачная функция копирует конфиг и чарты из бакета staging-хранилища в Git-репозиторий staging;
Оператор GitOps обновляет кластер.

3. Сборка Jenkins — ветка develop или feature:

Jenkins push'ит нетегированные образы в Quay;
Jenkins push'ит конфиг и Helm-чарты в бакет develop-хранилища;
Облачная функция копирует конфиг и чарты из бакета develop-хранилища в Git-репозиторий develop;
Оператор GitOps обновляет кластер.

4. Добавление нового клиента:

Менеджер или администратор (LCM/ops) вызывает Gradle для первоначального развертывания и настройки сетевых балансировщиков нагрузки (NLB);
LCM/ops коммитит новый конфиг для подготовки deployment'а к обновлениям;
Оператор GitOps обновляет кластер.

Краткое описание GitOps

Опишите желаемое состояние всей системы, используя декларативные спецификации для каждого окружения (в нашей истории команда Боба определяет всю конфигурацию системы в Git).

Git-репозиторий является единственным источником истины в отношении желаемого состояния всей системы.
Все изменения в желаемое состояние осуществляются путем коммитов в Git.
Все желаемые параметры кластера также наблюдаемы в самом кластере. Таким образом мы можем определить, совпадают (конвергируют, converge) или отличаются (дивергируют, diverge) желаемое и наблюдаемое состояния.
Если желаемое и наблюдаемое состояния отличаются, то:

Существует механизм конвергенции, который рано или поздно автоматически синхронизирует целевое и наблюдаемое состояния. Внутри кластера этим занимается Kubernetes.
Процесс запускается незамедлительно с оповещением «change committed».
Через некоторый настраиваемый промежуток времени может быть послано оповещение «diff», если состояния отличаются.
Таким образом, все коммиты в Git вызывают проверяемые и идемпотентные обновления в кластере.

Откат — это конвергенция к ранее желаемому состоянию.
Конвергенция окончательна. О ее наступлении свидетельствуют:

Отсутствие оповещений «diff» в течение определенного промежутка времени.
Оповещение «converged» (например, webhook, событие Git writeback).

Что такое дивергенция?

Повторим еще раз: все желаемые свойства кластера должны быть наблюдаемы в самом кластере.

Несколько примеров дивергенции:

Изменение в файле конфигурации из-за слияния веток в Git.
Изменение в файле конфигурации из-за коммита в Git, сделанного GUI-клиентом.
Множественные изменения в желаемом состоянии из-за PR в Git с последующей сборкой образа контейнера и изменениями конфига.
Изменение состояния кластера из-за ошибки, конфликта ресурсов, приводящего к «плохому поведению», или просто случайного отклонения от оригинального состояния.

Что представляет собой механизм конвергенции?

Несколько примеров:

Для контейнеров и кластеров механизм конвергенции предоставляет Kubernetes.
Тот же механизм можно использовать для управления приложениями и конструкциями на основе Kubernetes (например, Istio и Kubeflow).
Механизм для управления рабочим взаимодействием между Kubernetes, репозиториями образов и Git'ом предоставляет GitOps-оператор Weave Flux, являющийся частью Weave Cloud.
Для базовых машин механизм конвергенции должен быть декларативным и автономным. По своему опыту можем сказать, что Terraform ближе всего к этому определению, однако все же требует контроля со стороны человека. В этом смысле GitOps расширяет традиции Infrastructure as Code.

GitOps объединяет Git с прекрасным механизмом конвергенции Kubernetes, предлагая модель для эксплуатации.

GitOps позволяет нам заявить: автоматизации и контролю поддаются только те системы, которые можно описывать и наблюдать.

GitOps предназначен для всего cloud native-стека (например, Terraform и т.п.)

GitOps — это не только Kubernetes. Мы хотим, чтобы вся система управлялась декларативно и использовала конвергенцию. Под всей системой мы подразумеваем совокупность сред, работающих с Kubernetes — например, «dev cluster 1», «production» и т. п. В каждую среду входят машины, кластеры, приложения, а также интерфейсы для внешних сервисов, обеспечивающих данные, мониторинг и т. п.

Заметьте, насколько в данном случае Terraform важен для проблемы bootstrapping'а. Kubernetes должен быть где-то развёрнут, и использование Terraform означает, что мы можем применить те же самые рабочие процессы GitOps для создания управляющего слоя, лежащего в основе Kubernetes и приложений. Это полезная лучшая практика.

Большое внимание уделяется применению концепций GitOps к слоям над Kubernetes. На данный момент имеются решения GitOps-типа для Istio, Helm, Ksonnet, OpenFaaS и Kubeflow, а также например, для Pulumi, что создают слой для разработки приложений под cloud native.

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

Кстати отметил что большинство мировых трендов будут также актуальны для российского рынка. Активную миграцию в облака стимулирует растущий объем корпоративной информации и растущий дефицит специалистов, которые нужны для поддержки физической инфраструктуры. Ежегодно рост рынка облачных сервисов растет на 35-40%. При этом российские разработчики также работают над развитием новых технологий, например, по данным «Сколково» в 2023 году было одобрено финансирование ИИ-проектов более чем на 1,6 млрд рублей.

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

Кому нужны расчеты ядерного синтеза, это бред, а sql нужен всем

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

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

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

Что подают в России

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

К кон­цу 2023-го ры­нок об­лач­ных ре­шений увеличился на 40% — сообщают эксперты Comnews. В 2022 году прирост был таким же (42%). Активную миграцию в облака стимулируют импортозамещение, бум на разработку собственных ИИ-решений и растущий объем корпоративной информации. Особую роль играет растущий дефицит специалистов, которые нужны для поддержки материальной инфраструктуры.

Второй общий тренд, который только недавно появился на российском поле, — усиленная кибербезопасность. По данным F.A.C.C.T. (Group-IB), за три квартала 2023 года на 140% выросло число атак по политическим мотивам. За тот же период на 44% увеличилась интенсивность атак на веб-ресурсы организаций — отмечают в Positive Technologies.

Теперь российский бизнес поспешно защищается от хактивистов, в том числе от утечек данных и DDoS. Атаки все чаще выводят из строя ключевую инфраструктуру компаний, оставляя их с огромными финансовыми и репутационными потерями. Именно поэтому компании стремятся обеспечить максимальную безопасность виртуальной инфраструктуры, переходят в защищенные облака, используют услуги и продукты ИБ-ориентированных провайдеров. А еще — активно интересуются возможностями хранения бэкапов и быстрого восстановления инфраструктуры в облаке (Disaster Recovery).

Однако есть в России особый тренд, который явно отличает наш рынок от мирового. В 2023 году страну охватил бум на строительство дата-центров. По данным Tadviser, ажиотаж объясняется тем, что большинство крупных проектов были заморожены из-за геополитических событий. И именно поэтому многие ЦОД запускаются только сейчас.

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