🔥 Alibaba представила open-source интеграцию DuckDB — AP-движок для аналитических запросов прямо в MySQL

Крупнейший китайский облачный вендор Alibaba открыл исходный код глубокой интеграции аналитической СУБД DuckDB в AliSQL (форк MySQL). Это позволяет запускать аналитические запросы (OLAP) в тысячи раз быстрее, чем на InnoDB, с полным сохранением MySQL-синтаксиса.

Проект доступен полностью в open source — разработчики и компании могут использовать, модифицировать и внедрять эту технологию самостоятельно, без привязки к облачным сервисам.

🛠 Как это работает:

DuckDB встроен как плагинный storage-движок в архитектуру MySQL. Аналитические реплики синхронизируются через бинарный лог (binlog), что обеспечивает согласованность данных и отказоустойчивость. Под капотом реализованы оптимизации:
- Пакетное выполнение транзакций
- Поддержка DDL через INPLACE / INSTANT или COPY - механизмы
- Многопоточная конвертация таблиц

📊 Производительность:

На тестах TPC-H SF100 DuckDB показал впечатляющие результаты — общее время выполнения 22 запросов:
• DuckDB: 15.31 сек (в 1648 раз быстрее!)
• InnoDB: 25 234.31 сек

🌐 Исходный код и документация:

Решение полностью открыто и доступно в репозитории AliSQL. Сообщество может изучать, использовать и развивать эту интеграцию.

👉 Репозиторий и подробная документация

#OpenSource #AliSQL #DuckDB #MySQL #OLAP #Database #Analytics #Alibaba #GitHub

Выжидание не самая лучшая тактика...

С пятницей!

#mems

📚 Database Trends and Applications Magazine: December 2025/January 2026 Issue

❗️Тема номера: Флагманы управления данными на 2026

Дисклеймер: традиционно разбираю только небольшой набор статей.

➡️Survey:Tracking the Diversification and Decentralization Revolution in Databases

Опрос посвящён текущим тенденциям и вызовам в области баз данных. И так:

📊Разнообразие и децентрализация

Организации не отказываются от существующих систем (например, Oracle), но активно расширяют экосистему. Большинство респондентов также используют SQL Server (59%), MySQL (45%), PostgreSQL (40%) и облачные решения (Amazon RDS — 28%). Где-то на задворках MongoDB

Забавно, что ИТ-ландшафт опрошенных компаний представляют различные реляционные СУБД. О NoSQL почти ничего не написали. Поставили только MongoDB ради приличия...

🤖 Спрос на интеграцию с ИИ

Более половины опрошенных стремятся к тесной интеграции баз данных с фреймворками машинного обучения и ИИ. Нехватка квалифицированных кадров для таких инициатив (52%) — ключевое препятствие.

Чем это напоминает хайп вокруг GO. Разработчики на GO буквально год или 2 назад могли смело претендовать на ЗП 200% и выше процентов от среднего по рынку. И эти ЗП давали. Сейчас такая же песня с ИИ-специалистами. Деньгами их осыпают весьма щедро! Думаю этот тренд сохранится еще несколько лет.

⚡️ Проблемы производительности

Производительность БД остаётся больной темой: 62% сталкиваются с проблемами ежемесячно или чаще, что напрямую влияет на продуктивность и доходы компаний.

☁️ Планы по переходу в облако

Сейчас 45% БД размещены локально, 37% — в облаке. В течение 3–5 лет доля облачных баз данных, по прогнозам, вырастет до 53%, а локальных — сократится до 30%. Однако гибридные среды останутся нормой.

Для РФ не могу сказать, что это статистика актуальна, ну, может быть.

🚧 Нехватка навыков

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

Разработчики и администраторы по прежнему актуальные профессии.

➡️ Information Management Trends in the Year Ahead
Разберем тренды. Спойлер: все тренды связаны с ИИ

1. Демократизация ИИ. ИИ-инструментария станет еще больше и он будет более доступный для всех сотрудников компании.
2. Предметные AI-агенты: Появятся автономные агенты, глубоко обученные для конкретных отраслей (например, здравоохранения или логистики), которые будут самостоятельно управлять, очищать и оптимизировать данные.
3. Цифровая рабочая сила: AI-агенты станут полноценными «сотрудниками» в организационной структуре компании, будут участвовать в проектах и вносить свой вклад.

Роботы начинают захватывать мир! Предвесники Скайнет (с)

➡️When the Cloud Comes Home: What DBAs Need to Know About Cloud Repatriation

Статья рассказывает о феномене репатриации из облака (cloud repatriation) — обратном перемещении рабочих нагрузок из публичного облака обратно в локальную инфраструктуру

Основные причины возврата данных "домой":
💵 Непредвиденные расходы:
⚡️ Производительность и задержки (Latency):
🛡 Контроль и соответствие нормам (Compliance):

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

📚Решил немного полисать книжку
Основы инженерии данных: как создавать надёжные системы обработки данных, 2024 год, ISBN 978-601-08-4116-1

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

Data Engineer строит “фабрику данных” и отвечает за то, чтобы она работала.

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

Инженерия данных — дисциплина про построение и эксплуатацию надёжных систем обработки данных

❇️Общее впечатление от книги
Впечатление двойственное. С одной стороны, книга аккуратно раскладывает профессию на жизненный цикл и фоновые процессы и даёт много здравых идей, а с другой, она говорит языком архитектуры и принципов, высоких материй и т.п. Мне бы хотелось больше “бытового” уровня: типовых кейсов, ошибок, компромиссов и примеров решений. Получается, что ты понимаешь слова и фразы, но не всегда очевидно, а зачем это знать? В итоге книга оставляет хорошую теоретическую рамку, но требует параллельной практики или примеров, иначе легко запутаться.

Короче, мне нужна книга "Инженерия данных для чайников" 🤓. Есть такая? 🤪

p.s. конечно можно на курсы сходить, но это совсем другая история

❇️Выделю несколько тезисов

👉 Жизненный цикл инженерии данных: Это центральная концепция книги, включающая пять стадий: генерация, хранение, поглощение, преобразование и предоставление данных. Эти 5 стадий сквозят через всю книгу.

👉 Принципы «качественной» архитектуры: Хорошая система должна быть масштабируемой, слабосвязанной, безопасной и экономически оптимизированной (FinOps).

👉 Технологии выбирают после архитектуры

👉 Эволюция хранения и поглощения: Разбираются различия между пакетной и потоковой обработкой, а также современные концепции хранилищ (Data Lake, Data Warehouse, Data Lakehouse)

👉 Понимание источников (схема, форматы, время события, ограничения прод-систем) заранее задаёт границы качества и SLA всего конвейера

👉 Хранение — ключевой архитектурный рычаг: lake/warehouse/lakehouse, compute–storage, кеширование и экономические компромиссы.

👉 Моделирование и трансформации превращают данные в продукт: выбор модели (Кимбалл/Инмон/Data Vault и др.), управляемые конвейеры ETL/ELT и контроль производительности запросов

👉 Безопасность и приватность — сквозной процесс: начинать нужно с людей и процедур (least privilege, управление учётками/секретами), затем — технологии (шифрование, патчи, мониторинг).

👉 Будущее смещается к real-time и “данным в продукте”: меньше ручных отчётов, больше автоматизированных действий и потоковых контуров.

🤯 Понавыдумавали кучу терминов, Data Engineer, Data Warehouse Analyst, DataOps, Data Scientist. И еще сборку Data Quality. Жесть какая-то 🤬. Кто за что отвечает знают только в БигТехе. В остальных компаниях всё это размывается на 2-3-х человек.

📚 NoSQL vs SQL in 2026: Why We Moved Back to Postgres After 4 Years of MongoDB Flexibility

Статья с Medium*, так еще за "пейволом". Придется вам поверить мне на слово 😅

Суть статьи: Жили-жили мы на MongoDB 4 года. Наворотили кучу сервисов и превратили данные в настоящий хаус 🐣.
Пример

// Found in production, January 2024
{ email: "sarah@company.com", signup_date: "2023-01-15" }
{ emailAddress: "john@test.io", signupDate: "Jan 15, 2023", signUpDate: null }
{ mail: "alex@startup.co", created: 1673740800, active: 1 }
{ contact_email: "maria@corp.com", created: "2023-01-15T00:00:00Z", active: true, isActive: true }

Куча разных полей с email.

Накопили кучу техдолга и вместо того, чтобы "причесать" данные в MongoDB решили от нее отказаться в пользу PostgreSQL. Конец 🤯.

Такое ощущение, что это статья из 2017 года, которая появилась только сейчас. Сама ситуация банальная 🥱.
MongoDB плохая, т.к. разработчики не ограничены схемой данных и каждый творит, что хочет. Зачем нам такая свобода? 🤷‍♂️ Срочно вернуть схему данных и жесткие ограничения! ASAP! 😡

По мне звучит как детский сад. 🐥
Я понимаю, когда люди принимают осознанное решение при миграции с MongoDB на PostgreSQL. Основная причина - это люди и DBA в частности.

DBA на PostgreSQL начти - в разы проще, чем на MongoDB. Всё сводится к тому, что не хватает компетентных людей, которые могут "приготовить" MongoDB надлежащим образом ☹️.

Грустно как-то. Я в свое время очень хотел стать настоящим спецом по MongoDB, но после их ухода их РФ 🚪 бросил эту идею .

*заблокирована на территории РФ

Каникулы еще не закончились, поэтому продолжайте наслаждаться!

С пятницей!

#mems

Просто оставлю это здесь.
Гифка зачётная 😊

📚Что такое реплики чтения и когда их следует использовать

Уже не первый раз мне попадаются статьи с ресурса https://www.devx.com, но они все какие-то странные и бессмысленные 🚮. Текущая статья примерно в такой же духе.

Текста много. Смысл в тексте тоже есть. Но всё какое-то абстрактное, все выводы банальны 🐣 и после прочтения у меня в голове новых знаний и понимания не появляется 😶‍🌫️.

Многие ругаются, что сейчас народ статьи пишет с ИИ 👯‍♀️. В статье больше ИИ текста, чем текста человека 🤖. Тут ситуация другая. Если я попрошу ИИ рассказать мне о "читающих репликах", то он мне напишет в разы интереснее текст 😀.

Может у меня уже пошла профдеформация какая-то. Не знаю. Подобные тексты я более упоминать не буду. В этот раз поделился мнением... 😑🙂‍↕️

p.s Руководство по выбору между базами данных SQL и NoSQL. Еще одно подтверждение. Заголовок же классный! Провоцирует на чтение. Но после прочитанного полное разочарование. На какой это уровень читателя расчитан я не поманию. Бросаю читать этот ресурс. Хорош...😑

💬 3-4 февраля 2026, прошла 26-ая конференция iFin-2026.

Крупнейший форум по электронным финансам в России с 2001 года🔝. Исключительно оффлайн-формат.

✅ Пока опишу общее впечатление. Более детальный разбор сделаю позже.

Напомню, что основная направленность конференции -

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

Я туда хожу последние лет 10 с целью узнать о трендах банковских услуг и продуктов и составить понимание куда всё движется.

Из нового организаторы решили поставить сделать дополнительные "круглые столы" в середине мероприятия. Я побывал на обоих

Круглый стол №1. «Будущее ДБО: эволюция ожиданий клиентов vs технологические возможности»
Круглый стол №2. «Инфраструктура, ориентированная на клиента: как ИТ влияет на эффективность обслуживания»

Темы то классные, но с таймингом организаторы не угадали ⌛️. Дали 40 минут и позвал по 6-7 участников. Каждый взял слово на 2-3 минуты и стол закончился. Даже вопросов никто не успел задать. Все это превратилось в короткое интервью с одним вопросом, что вы думаете о <тема круглого стола>. Конец 🏁.

🫤 - итог

✅ О стендах

Группа Астра
Они впервые на этом форуме. Притащили "макет" машины баз данных Tantor XData. Внутри этой чудесной коробки почти ничего не было. Сплошные заглушки 🫥. Но смотрелось красиво 🥹! Спору нет. Жаль, что не было тех.специалистов, а были только маркетологи. Но я от них словил несколько тезисов, которые еще надо будет подтвердить.

👉 XData работает на процессорах Baikal-S и такие мышины выходят дешевле и даже лучше аналогичных сборок на Intel/AMD.
👉 Разработчики процессоров Baikal-S наладили производство в Китае, поэтому поставки идут полным ходом
👉 Из-за переоринтирования производства с Тайваня на Китай пришлось серьезно переработать архитектуру процессоров. За пару лет ребята справились.
👉 Тантор считает, что их решение "на глову" лучше аналогов от Скалы-Р и PostgresProMachine. Пруфов нет.

Мобиус Безопасность
Спецы ИБ, которые работают в банковской сфере. Но примечательны они своими промо и видеороликами 🎦. Просто гляньте их оф.сайт. Сделали прикольный видос с огромным красно-черным инопланетным пауком 🕷🕸! Смотрится реально круто 👍! Если бы они сделали какой-то мерч с ним, хотя бы футболки, блин, это был бы разрыв для всего форума 👕! Но... не та это конфа...ой, не та 😑. Из прикольного мерча был только тюлень в шапке от наших БазальтСПО (AltLinux). Эххх 🤷‍♂️

Больше и отметить нечего. Глаз особо не за что не зацепился 👁

Пока на этом всё. Сделаю обзор по докладам позже...

С началом нового учебного семестра!

За каждым великим человеком есть кто-то в его тени...

С пятницей!

#mems

📚Memory wall: что это и почему важно для индустрии хранения данных
Мне понравилась статья! 😎

Она хорошо написана и погружает читателя в мир аппаратных средств хранения информации. КЭШ процессора (L1,L1,L3), RAM, SSD, NAS(SAS), S3. Здорово, что автор обо всем этом пишет, но хотелось бы глубины 🌊. Наверное в формат одной хабр-статьи не влезет всё. Хорошо бы прочитать по подробнее про каждый вид хранения. Можно развернуться на целый цикл. 🌀

Можно самому написать такие статьи 🥸, но весомее об этом почитать от представителей облачных провайдеров, т.к. у них самая актуальная информация и это их хлеб.

Подождем. Может кто-то отважится 😉

⚡️ В один прекрасный момент мне сразу на глаза попались две статьи:

1️⃣ Мысли вслух. Протоколы и механизмы синхронизации транзакций в распределённом вычислительном кластере СУБД

Это философский этюд в жанре «а что если мы сделаем распределённую СУБД, которая ведёт себя как монолит, но не разваливается». Хммм 🤨.
Автор аккуратно размышляет про 2PC, прокси, парсинг SQL и детерминизм, периодически натыкаясь на фундаментальные законы физики, CAP-теорему и здравый смысл - и каждый раз честно признавая, что да, быстро, надёжно и распределённо одновременно всё-таки нельзя. Но почему бы и не помечтать... 😇

2️⃣ Разбираемся в функциональных зависимостях БД
Автор спокойно и вежливо объясняет, что если в проектируйте из разряда «студент → кафедра», то вы уже одной ногой в аду аномалий 🤔. Также подчёркивается, что функциональные зависимости - это не то, что случайно получилось в данных, а то, что изначально задумал архитектор. Правда, в реальной жизни все не так 🙃.

Я как раз уже в 14-ый раз 🤯😳 переписываю свой доклад для PG.Conf.Russia на этот счет. Ловлю себя на мысли, что очень не хватает какой-то современной литературы по проектированию баз данных. У PostgresPro есть современный учебник и демо базу они недавно обновили, но на этом всё. Больше ничего такого нет.

Периодически смотрю западные "книжные магазины" 😎 и там литературы по моделированию схем баз данных довольно много 📚. Каждый год книги 3-5 выходит. А то и больше📖. По хорошему надо бы скупить все эти книжки, почитать и вычленить из них что-то новое, чего нет в нашей "отечественной школе" 🏫.

❗️Прекрасная тема для доклада на PG.Conf.Academy в 2027 году. Доклад на этот году у меня уже есть 😁

🚧 ОФФТОП🚧 

📚 В Госдуме заявили, что россиянам «вредно» мечтать о зарплате в 1 млн рублей

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

Эта публикация прекрасна во всей красе 🤬! Нельзя даже помечтать в 2026 году о ЗП 1 млн рублей 💔

❇️Немного рассуждений

Сразу скажу, что людей со своим бизнесом я брать в расчет не буду, хотя налоговое бремя в этом году стало тяжелее. Добиться ЗП для себя любимого 🥰 в 1 млн.рублей стало в разы сложнее 🤔. Факт. 👊

Я человек из найма в сфере ИТ, поэтому и буду говорить за найм.

Если вы работайте на одну компанию, то получить в ней должность с ЗП в 1 млн - это великое достижение 🏆! Респект вам 🥳! Скорей всего это руководящая должность (я не знаю примера, чтобы какой-нибудь высококлассный инженер получал столько). За это придется платить высоким уровнем ответственности 🕴 и стресса 😱.

Вариант попроще добиться желаемой ЗП стал возможен после ковида и популяризации удаленки. Люди смело устраивались в несколько компаний, скажем в 3-4 штуки, на простые позиции программистов/специалистов и суммарно можно было получать 1 млн рублей в месяц без проблем 😎.
Тут минусы немного другие, и основной из них - это время ⏰. Рабочий день уже не 8 часов, а все 12, а то и больше. Перегрузка на лицо. Зато 🍋 в кармане.

Я сам пошел по второму сценарию. У меня несколько работ (больше 4-х), но доход ниже заветного 🍋. Чтобы преодолеть эту планку мне нужно еще 3 доп.работы 🤯. Мой рабочий график уже вышел за 68 часов в неделю. Брать на себя ЕЩЕ доп.активности - это путь подорвать здоровье 🤕🤧.

Признаюсь, порой очень хочется хотя бы несколько месяцев получать на карту 1 млн.рублей 😌🤤. Просто ради "лычки" для самого себя🎖.

Зафиналю пост небольшим анонсом. Начиная с 24 февраля мой рабочий график преподавания будет выглядеть так:

Вторник - курс Redis/Valkey - записывайтесь пока есть места!
Среда - лекция/семинар в МАИ / МГТУ им.Баумана
Четверг - лекция/семинар в МФТИ каф БИТ
Пятница - лекция/семинар в МФТИ каф блокчейн

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

📚 OLTP vs OLAP in 2026: Key differences, definitions & examples
Статья из блога ClickHouse.

Можно смело заявить, что это академическая попытка расставить все точки над "i" в фундаментальном вопросе различия транзакционных (OLTP) и аналитических (OLAP) систем. Автор справился с задачей очень хорошо 💪

✔️ Четко обозначены границы. Грамотно разложено по полочкам цели, запросы, и архитектура. Разбор идёт по всем фронтам: от определения и примеров запросов до таблицы различий по 15+ параметрам. Это готовый учебный материал

✔️ Тренд на конвергенцию. Границы стираются. OLAP (как ClickHouse) учатся работать в реальном времени, а OLTP-движки (PostgreSQL) прокачивают аналитику. Это главный тренд ближайших лет.

✔️ CDC как критическая технология. Правильно делают акцент на Change Data Capture. CDC — это не просто синхронизация, а «кровеносная система» современной data-архитектуры, и поддержка СУБД этого формата становится must-have.

Статья весьма объемная, но довольно интересная. Если есть возможность, то обязательно почитайте оригинал. Не пожалеете! 💯

Старый мем, но каждый учебный год актуальный как никогда!

С пятницей!

#mems

📚 Шардинг MongoDB: что нужно знать перед началом шардинга

Я немного соскучился по статьям про MongoDB 😚. Приятно снова почитать что-то из серии "перед тем как шардировать, остановись, подумай и сверься с ИИ" 😉

Каких-то откровений тут нет. Если вы уже сталкивались с шардингом, targeted vs scatter-gather и вечным вопросом выбора shard key (ключ локальности, на русском звучит забавно), то всё будет знакомо 🪧. Но в этом и плюс, автор не пытается изобрести что-то новое, а аккуратно напоминает про грабли: запросы без shard key превращаются в прогулку по всем шардам, монотонные ключи легко делают вам hot shard, а hashed/range - это компромисс, а не «правильный ответ».

Статья приятная визуально ☺️. Примеры и картинки реально помогают, а кейс с книжным магазином хорошо "прожёвывает" логику выбора ключа 🔑.

Материал местами слишком дружелюбный (не ИИшный ли часом? 🫤 ). Не хватает чувства боли 😖 от реальных проблем с прода (миграции, паттерны запросов, балансер, стоимость scatter-gather под нагрузкой), но как короткий чек-лист перед шардированием сгодится!

📚 Хроники Valkey: сайдкары, операторы и один очень упрямый кластер

В Авито один из самых крупных внедрений Redis'а на территории РФ 👍. С ними разве что-то Яндекс.Облако посоперничать, но от последних давно ничего не слышал.

Авитовцы наконец решились переехать на Valkey и уйти от Redis. Даже смена лицензии с Redis 8 обратно в opensource проект не остановило. Я думаю, что статья вышла довольно поздно. Мне кажется, что проект по миграции был сделан месяца за 3-4. По сути, чего там менять то? API полностью совместимы. И с точки зрения эксплуатации и мониторинга ничего не меняется. Даже чуть лучше становится.

Я думаю, что товарищей из Авито подкупила то, что Valkey будет активно прокачивать свой Valkey Cluster 😎. А в Авито это 400+ инсталяций!

Думаю, стоит ждать новых статей от ребят по Valkey. Хотя я больше надеюсь на их доклады 📇

А пока, записывайтесь на мой курс по Redis/Valkey! Старт чуть съехал на 1 неделю, поэтому начала 2 марта!

📚 Миссия выполнима: как мы добились актуальности двух тысяч кешей

Еще одна статья про Valkey 🙄. И про скрытаю миграцию. Как я понял, все уже было сделано, но нужно еще как-то "улучшить", возможно упростить 😅. Поэтому ребята с Redis и Memcashed переехали на Valkey.

В контексте этого проекта озоновцам был важен функционал Pub/Sub и Streams. После небольших доработок "напильником" 🛠(100 пудов они не чистый opensource задеплоили в кубик) все поставленные задачи были решены. Успех! 😎

Поскольку подов у нас 2000, а кешей в Valkey — 115 терабайт

Размеры данных потрясают! Вау! ☝️Я с таким объемом в проде дел не имел. БигТех всё-таки...

Очередное подтверждение того, что спустя 1.5 года существования Valkey он начинает набирать популярность и применимость в проде у серьезных ребят. Единственно, что смущает - это неизвестность в области доработок. Что они меняли "в коробке"? ❓ Очень интересно 🤔

Надеюсь, что ребята из Озон и Авито будут активно контребьютить в проект ☑️. Спрошу их об этом на конференциях в этом году. Пока на примете только DevOpsConf2026 в апреле и HighLoadSPB++ в июне.

Всегда в коллективе найдется такой человек. Грустнее всего, что приходиться с ним работать всё равно 🥲.

С пятницей!

#mems

📚OpenEverest: платформа с открытым исходным кодом для автоматизации баз данных

Буквально недавно Percona объявила о том, что их продукт Percona Everest трансформируется в OpenEverest и становится opensource.

OpenEverest — новый открытый проект от Percona, который представляет собой базу управления базами данных на Kubernetes. В ней объясняется, что OpenEverest — это модульная платформа для автоматического развёртывания, масштабирования, резервного копирования и восстановления кластеров БД (PostgreSQL, MySQL, MongoDB и др.) на Kubernetes-инфраструктуре, будь то облако или собственный сервер. Он использует Kubernetes-операторы и CRD, чтобы операции с базами выглядели как обычные, декларативные ресурсы Kubernetes, и цель проекта — уменьшить зависимость от проприетарных баз данных в облаке и упростить DBaaS-опыт

К сожалению, в моей среде обитания кубера нет, поэтому мне тяжело рассуждать насколько этот проект будет полезен современным DevOps специалистам. Это прекрасная тема для разработки НИР 😏

Помню с 2020-2023 на кафедре было много тем про Кубнетес. Каждый третий студент искал возможности его "улучшить". Думаю пришла пора вернуть подобные темы в список для защиты 😈