Комментарии

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

Допустим, у вас приложение, состоящее из двух бэков + базы.
И у вас 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 года чего-то особенного. Их прогнозы во многом похожи на заявления прошлых лет. Но может быть, это даже неплохо. Смотреть в будущее порой бывает приятнее, когда видишь горизонты четко и не ждешь сюрпризов.

Инвестиции в облака растут как на дрожжах. В Gartner отмечают, что объем рынка за последний год уже увеличился на 20,4%. Речь идет о 678,6 млрд долларов. Именно столько, по мнению аналитиков, конечные потребители потратят на облачные сервисы в 2024 году.

Есть и более смелые ожидания от мирового рынка. Аналитики IDC, например, недавно заявляли, что к 2024 году мировые расходы на облака могут превысить 1 трлн долларов.

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

На вкус и цвет облака разные

Еще один тренд от Gartner — развитие отраслевых платформ. Универсальные облака все реже соответствуют требованиям разных сфер бизнеса. Именно поэтому возникает спрос на отраслевые виртуальные решения и услуги, в том числе предоставляемые по модели IaaS.

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

Из горячего — Web3

Как считают аналитики McKinsey, многое на рынке облачных технологий изменит интернет следующего поколения (что бы это ни значило). Эксперты называют его Web3 и связывают перемены с блокчейном.

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

Главное — не обжечься

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

Многие компании уже используют инфраструктуру с архитектурой нулевого доверия (zero-trust). Более 80% уже применяют этот подход в облаках. Во всяком случае, такие данные появились в недавнем исследовании MIT.

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

Горько, но факт: больше 50% успешных атак на веб-ресурсы совершаются из-за слабых логинов и паролей. К таким выводам пришли аналитики Google. В том числе из-за слабых учетных данных пользователей страдают компании.

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

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

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

Миру уже хорошо известны ChatGPT, DELLE-2 и другие продукты с GenAI под капотом. Масштабы их использования в корпоративном сегменте будут стремительно расти, считают во многих аналитических агентствах.

По мнению Gartner, к 2026 году применять или развертывать модели GenAI в облаке будут 80% компаний по всему миру. И главная причина такого спроса — демократизация генеративного ИИ, к которой приводит сочетание облачных технологий и открытого кода.

Так в итоге и не понятно, зачем вам даталейк, если подшел в итоге вариант с реляционной ДБ

У нас несколько иной опыт работы со Snowflake. Нужен был data lake, а самописное решение на Postgress/RDS уже явно не тянуло.

Ребята из Snowflake аккуратно и правильно собрали все требования и выкатили кастомизированную презентацию, которая покрывала 97% проблем. Не было никаких продаванов и левых менеджеров. Было 2 программиста-ставших-сейлсами, которые очень грамотно и четко отвечали на все проблемы либо сами сразу, либо посовещавшись с командой разработки.

Прототип запилили тоже они, причем всего за пару недель.

В итоге осталось очень приятное впечатление. Единственный неприятный момент — негибкая система кредитов по принципу «use it or loose it», которая держит на коротком поводке.

Отчасти, поэтому и ушли в итоге на BigQuery, но это уже совсем другая история…

Databricks — это в первую очередь Spark и сопутсвующая экосистема, плюс сейчас инструменты для всяких ML/AI/Data Science. Данные они для вас тоже могут хранить, но это необязательно — мы, например, этой функциональностью не пользуемся. Никакую БД они не предлагают — lakehouse это другое, но SQL интерфейс у этого всего есть.

Как я понимаю Databricks, как и Snowflake, предлагает быструю, размещаемую на хостинге поставщика базу данных с практически бесконечными возможностями масштабирования.

MVC — это шаблон программирования, который позволяет разделить логику приложения на три части:

Model (модель) — получает данные от контроллера, выполняет необходимые операции и передаёт их виду.

View (вид или представление) — получает данные от модели и выводит их для пользователя.

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

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

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

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

Наверно три основные библиотеки, которые использую вместе с Django, это Celery для асинхронных тасков, Django Rest Framework для REST API и Python Social Auth для интеграции с соцсетями.