👩‍💻 PostgreSQL - СОВЕТЫ ПО ЭФФЕКТИВНОЙ РАБОТЕ.
ЧАСТЬ 2.

5️⃣РАЗДЕЛЯЙ И ВЛАСТВУЙ

При проектировании схемы БД и модели данных сразу прогнозируйте объем данных через год-два. Если вы понимаете, что число записей сильно переваливает за миллион, стоит задумать о том по какому принципу стоит делить эти данные. Например, если у вас интернет магазин и вы храните записи о заказа клиента, скорее всего заказы сделанные давно вам редко будут нужны. В этом случае поможет партиционирование таблицы по временному интервалу (в данном случае ключ партиционирования - время создания заказа). Postgres будет иметь набор условно маленьких табличек, каждая из которых содержит свои маленькие индексы. в 90% случаях вы будете работать со свежими заказами, и все запросы будут идти в последние партиции, которые уже полностью могут помещаться в кеш Postgres. Вы можете выбрать ключом партиционирования что угодно, главное, чтобы партиции были +- одного размера и обращения происходили к минимальному их количеству.

6️⃣RAM - НАШЕ ВСЁ

Берегите оперативную память Postgres. Не бойтесь накидывать больше оперативной памяти кешу Postgres - чем больше он, тем больше данных там поместится, и тем меньше будет чтений с диска, и, соотвественно, меньше задержек. Но оперативная память нужна не только кешу, она нудна также для обработки запросов приложения. Следите за потреблением памяти вашими запросами, старайтесь доставать как можно меньше данных из БД. По максимум фильтруйте записи, где это возможно. Не делайте 10 JOIN-ов ради того, чтобы обогатить ответ парочкой полей, которые могли бы хорошо закешироваться в вашем приложении.

7️⃣ДЕНОРМАЛИЗАЦИЯ ДАННЫХ

3-я нормальная форма - это конечно хорошо, но если 90% запросов в БД - это чтение с постоянными одними и теме же JOIN-ами, то стоит задуматься о денормализации данных. Денормализованные данные сложнее обновлять, но довольно просто получать по одному ключу.

8️⃣ДОЛГИЕ ТРАНЗАКЦИИ - ЗЛО

Любая транзакция несет много накладных расходов, а долгоживущая транзакция - это ноша, которая тяжелеет с каждой новой параллельно выполненной транзакцией. Долгая транзакция также не позволяет пуллеру переиспользовать соединение с БД для других запросов. Также не стоить делать большое число изменений/удалений в рамках одной транзакции, это может вызвать bloat.
Маленькие быстрые транзакции лучше себя ведут.

9️⃣МАСШТАБИРОВАНИЕ

Postgres можно мастшабировать двумя способами:

1. За счет добавления реплик и чтения из них. В этом случае не стоит использовать мастер только на запись, так как Postgres собирает статистику использования данных только с мастера. Эта статистика очень хорошо помогает при планировании исполнения запросов. При чтении с мастера эта статистика попадет в реплики и они начнут более эффективно строить планы запросов.
2. За счет шардирования. Тут все просто, вы разделяете ваши данные по разным инстансам и контролируете где какие лежат. К сожалению из коробки PostgreSQL не умеет шардировать данные и вам скорее всего придется использовать сторонние решения.

🔟 МОНИТОРИНГ

Ну и последний совет: собирайте статистику и метрики, которые предоставляет Postgres. Обеспечьте мониторинг вашей БД 24/7 и своевременно находите узкие места. Анализируйте запросы. Не увлекайтесь ненужными индексами, они не всегда ускоряют запросы. Создавайте индексы под определенные частые запросы.

Вот и прошли майские праздники 📆

Давно не ходил на конференции, да и некогда особо...
Наткнулся на онлайн конференцию по любимому 👩‍💻 - Podlodka Go Crew (кстати, темы там не только по Go). Взял себе билет🎫Конференция идет всю неделю по 2 доклада в день.

Решил, что буду всю неделю делиться своим мнением по докладам тут. Вы тоже можете в комментариях делиться свои мнением)

Сегодня уже было два доклада:
1. «SQLite как основная база данных» / Никита Галушко (ВКонтакте)
2. «Мокирование vs предзаполнение базы данных» / Павел Вирский (Озон Банк), Глеб Карпушкин (Ozon Fintech)!

Естественно онлайн я пропустил, приходится ночью досматривать записи)

По первому докладу могу сказать, что идея использовать в простых системах SQLite может быть оправдана. Но на мой взгляд, если поддержка инфраструктуры (IaaS, DBaaS) в компании автоматизирована и на высоком уровне (как например в Ozon), то проще развернуть маленький Postgres по клику кнопки, чем потом с SQLite слезать при масштабировании сервиса.

Второй доклад от моего коллеги по цеху я пропустил, но завтра надеюсь запись выложат.

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

Ну и в общем-то я понял, что задачи разработчика глобально можно разделить на 3 типа:

1️⃣Разработка новых решений с нуля (ресерч)

Это то, о чем мечтают многие разработчики и спрашивают на собеседованиях у работодателя. Конечно, в разработке с нуля есть ряд плюсов:
✅не надо разбираться в чужом коде,
✅можешь спроектировать космолет по всем правила и канонам сам
✅и вообще применить все свои наработки, подходы и т. д.
Но также есть и минусы таких задач: очень много вопросов о конечном продукте (чаще всего новые проекты - это какие-то MVP, которые не всегда понятно как будут расширяться потом и куда пойдут).
Можно уйти в долгую полемику выбора архитектуры, проработки API, схемы БД (ведь хочется сразу все сделать универсально и на века!). Также вы можете столкнуться с проблемой, которую никто до вас еще не решал, и это может стать настоящим rocket since (но есть и те, кого это драйвит).

2️⃣Поддержка и развитие существующего проекта, технологии

Вообще таких задач, как правило, больше остальных.
➕Из плюсов: уже есть устоявшаяся архитектура, подходы и технологии. Могут попасться изящные примеры и подходы в коде, на которых можно всегда научиться и поднять свою экспертизу.
🌟Из минусов: как правило, требуется не мало умственных усилий на погружение в проект, уменьшается гибкость разработки новых фич. Иногда приходится ломать голову, как не сломать все и при добавлении новой функциональности (тут требуется скилл ювелирного внедрения).

3️⃣Поддержка легаси

Легаси - это что-то старое, страшное, запутанное, мало освещенное, но худо-бедно работающее решение.
Ночной кошмар для большинства разработчиков: ты пришел в новую IT компанию, чтобы разрабатывать новые крутые проекты, а тебе дают ЭТО... И вот 3 бессонные ночи ты отлаживаешь код, чтобы понять, что тут вообще происходит и что автор кода пытался донести.
Но и в таких задачах можно найти жилу радости и успеха: переписывание легаси! Если сделать его качественно, быстро, да еще если это закроет существующие проблемы... Оооо, вам обеспечено место на доске почета в компании, такое точно запомнят!

Самое смешное, что как только надоедает один тип задач, хочется другой. Но и он тоже надоест, и так по кругу... Одна из причин ухода разработчика в другую команду/компанию, как правило, становится как раз "однообразие задач".

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

📌В общем, совет руководителям: следите за разнообразием задач у разработчиков.
Разработчики - не бойтесь просить у лидов смену характера задач, когда понимаете, что уже начинает надоедать. Уйти всегда можно)

❔А какой тип задач сейчас у вас на данный момент?

👨‍💻Junior Go разработчик:

for i := range jobs {
    job()
}

👨‍💻Middle Go разработчик:

var wg sync.WaitGroup
for i := range jobs {
    wg.Add(1)
    go func(job jobType) {
        defer wg.Done()
        job()
    }(jobs[i])
}
wg.Wait()

👨‍💻Senior Go разработчик:

var workersNum = runtime.NumCPU()

var (
    wg sync.WaitGroup
    in = make(chan jobType, workersNum)
)
for i := 0; i < workersNum; i++ {
     wg.Add(1)
     go func() {
         defer wg.Done()
         for job := range in {
             job()
         }
     }()
}

for i := range jobs {
    in <- jobs[i]
}
close(in)
wg.Wait()

🧠Lead Go разработчик:

import "github.com/sourcegraph/conc/iter"


iterator := iter.Iterator[jobType]{MaxGoroutines: runtime.NumCPU()}

iterator.ForEach(jobs, func(job jobType) {
   job()
})

Да, асинхронность в 👩‍💻 довольно изящна и проста (если сравнивать с другими языками). Но все же она требует от разработчика внимательности и хорошего знания языка. А в случае ошибки вам будет обеспечена утечка памяти или deadlock.

Что отличает ведущего (Lead) разработчика от других? Он пишет эффективные решения довольно быстро, а главное эти решения надежные и, в идеале, изящны. Часто это достигается путем использования проверенных инструментов.

Одним из таких инструментов - github.com/sourcegraph/concНа мой взгляд это то, чего не хватает в стандартной библиотеке Go. Максимально изящная асинхронность, спрятанная за синтаксическим сахаром. С этой библиотекой шансов словить утечку памяти резко уменьшаются, а скорость проведения код ревью увеличивается.

Делайте вещи проще! (KISS)

УБИЙЦА GO И RUST?

Пока 👩‍💻 и 👩‍💻 разработчики спорят друг с другом чей же язык круче и лучше, Marco Sampellegrini, автор книги The Simple Haskell Handbook и разработчик системы непрерывной интеграции Quad CI,
написал новый язык программирования — Borgo.

Borgo пытается быть более выразительным, чем Go, но менее сложным, чем Rust. Он комбинирует лучшие черты Go и Rust, восполняя недостатки каждого из языков. Компилятор написан на Rust. Сам язык совместим с пакетами Go (можно вызывать гошный код).

Что-ж, там есть enum :)

go:use fmt

enum NetworkState {
    Loading,
    Failed(int),
    Success(string),
}

let msg = match state {
    NetworkState.Loading => "still loading",
    NetworkState.Failed(code) => fmt.Sprintf("Got error code: %d", code),
    NetworkState.Success(res) => res,
}

Начнут ли все переходить на Borgo? Думаю, вряд ли… Пиар команда слабая и нет локомотивного комьюнити. Но мб это хороший толчок к скорому Go 2.0🤔

А вас заинтересовал Borgo?
Ставь:
🔥 - да
❤ - Go one love
😎 - пошел писать дальше на Rust

👩‍💻 Docker заблокировал доступ к своему главному репозиторию Docker Hub для пользователей из России!

Что ж... еще одна компания придерживается принципов "демократии", "свободы слова" и за справедливость во всем мире!

Docker - не первый и не последний, кто уходит из РФ или блокирует доступ:
- Redis
- Buf.build
- Swagger
- Jetbrains
- ...
Список можно продолжать бесконечно...

Холодная война в самом разгаре, что еще нам заблокируют...? Вопрос риторический. Тем не менее выход разработчики всегда найдут 😉
_________

Инструкция по восстановлению доступа к Docker Hub для пользователей из России

🔗 Читать статью
🔗 Зеркало

ЗАПИСЬ ОТКРЫТОГО УРОКА ОСНОВЫ gRPC В GO❗️

👉ссылка тут 👈

Ставь 🔥, если хочешь узнать больше о gRPC!

❗РАБОТА С PROTOBUF НА ОТРАСЛЕВОМ УРОВНЕ. ЧАСТЬ 1.

1️⃣ В любом современном языке есть средства форматирования, например prettier для 👩‍💻, gofmt для 👩‍💻 и rustfmt для 👩‍💻. К сожалению долгое время форматирования в protobuf отсутствовало на должнем уровне. И вот в CLI buf появилась функцию format, которая позволяет форматировать Protobuf файлы в соответствии с отраслевыми стандартами.

Вот пример отформатированного файла:

syntax = "proto3";

package moguchev.my.awesome.package.api.users;

import "google/api/field_behavior.proto";
import "protoc-gen-openapiv2/options/annotations.proto";
import "validate/validate.proto";

option csharp_namespace = "Moguchev.My.Awesome.Package.Api.Users";
option go_package = "github.com/moguchev/my/awesome/package/pkg/api/users;users";

// GetUsersRequest - GetUsersRequest request
message GetUsersRequest {
  option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_schema) = {
    json_schema: {
      noscript: "ListServicesRequest"
      denoscription: "ListServices request"
      required: [
        "pagination"
      ]
    }
  };
  // pagination - пагинация
  Pagination pagination = 1 [
    json_name = "pagination",
    (google.api.field_behavior) = REQUIRED,
    (validate.rules).message.required = true
  ];

  // ids - идентификаторы сервисов
  repeated uint64 ids = 2 [json_name = "id"]; // query param: ?id=1&id=2
}

Форматирует buf реально круто, но есть нюанс - нет возможности настроить правила форматирования. Разработчики buf посчитали, что отформатировать .proto файл можно лишь единственным образом. К сожалению инструмент еще не завезли в VSCode 👩‍💻 и IntelliJ 👩‍💻, но обещают в скором времени добавить. Ждем!)

❗РАБОТА С PROTOBUF НА ОТРАСЛЕВОМ УРОВНЕ. ЧАСТЬ 2.

2️⃣ Следить за форматированием и качеством оформления, нейминга и т.д. вручную почти невозможно и конечно же линтеры были созданы для этой рутинной задачи.

В buf также есть команда lint. Но на мой взгляд есть более удобный линтер protobuf - protolint, который можно гибко конфигурировать с помощью yaml файла. Также в VSCode 👩‍💻 можно поставить расширение protolint. И protolint довольно легко интегрировать в CI/CD:

protolint:
  image: yoheimuta/protolint:latest
  stage: lint
  noscript: protolint -config_path ./.protolint.yaml ./proto/

3️⃣ Экосистема protobuf и gRPC активно развивается, хоть и не так быстро как хотелось бы. На мой взгляд, gRPC и protobuf постепенно становятся отраслевым стандартом разработки микросервисов. Хотите узнать больше про protobuf и быть в курсе последних тенденций? ⬇️

📚Protocol Buffers Handbook: Getting deeper into Protobuf internals and its usage (2024) - Clement Jean

Эта книга поможет вам войти в мир протокольных буферов, раскрыв сложные нюансы синтаксиса Protobuf и расскажет о всех опциях и продвинутых плагинов.

-----------

❓А вы используете в своих проектах protobuf или gRPC?

🎬 ОТКРЫТОЕ СОБЕСЕДОВАНИЕ GO РАЗРАБОТЧИКА

Первое мое открытое mock собеседование: https://www.youtube.com/watch?v=sy09jrBhWzY

Задал самые частые вопросы и темы по теории Golang. К сожалению не хватило времени на вопросы про дженерики и паттерн контекст.

✔️100 ПОДПИСЧИКОВ ✔️

Спасибо всем, кто подписан на мой канал, это, правда, очень важно для меня ☝🏻

Сейчас нахожусь в отпуске. В следующем посте поделюсь впечатлениями о 2-х странах для релокации: Турция и Грузия.

ИДЕАЛЬНАЯ СТРАНА ДЛЯ РЕЛОКАЦИИ РАЗРАБОТЧИКА

В эпоху удаленной работы, высоких зарплат в IT и некоторых событий 🆘 — переезд за рубеж на некоторое время или на совсем перестал быть только мечтой. Наверное, сейчас у каждого есть хотя бы один знакомый из IT, уехавший куда-то из России.

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

Итак, первая страна — Турция🇹🇷. В 2022 большой поток русских устремился именно туда. Первая причина — на тот момент там было все сильно дешевле, чем в России. Вторая причина — Турция - это довольно развитая, южная страна с хорошей инфраструктурой, солнцем, морем и т.д. Сейчас в Турции цены сильно выросли и недвижимость тоже, так что финансово свободно там себя уже не почувствуешь. Совет по городам для проживания: Стамбул (развитый город со всеми привычными благами цивилизации), Измир (современный город без туристов), Каш (тихий городок у моря, подойдет для жизни пару месяцев летом).

Вторая популярная страна для «релокантов» стала… ГРУЗИЯ!🇬🇪
Не просто так: граничит с Россией и можно даже на машине туда попасть, вкусная еда, красивые виды, есть море. Многие говорят на русском (хоть сейчас там антироссийские настроения, на русском и английском вас всегда поймут). В Грузии я выделил два города, где большинству будет привычно - Тбилиси (столица со своей атмосферой, антуражем) и Батуми («мини Дубай» в стадии зачатка с огромным числом продающейся и сдающейся недвижимости). Но цены там не ниже московских, а на что-то даже выше.

Армения 🇦🇲 — дружественная страна для России. Здесь принимают карту МИР (актуально для тех у кого нет зарубежной), все спокойно говорят на русском. Для жизни подойдет наверное больше всего Ереван. Но будьте готовы, наши соотечественники вызвали тут рост цен во всех сегментах: аренда жилья, цены в ресторанах, аренда авто, отели, гостиницы и т д. Жизнь тут в среднем на 15-45% дороже чем в Москве.

Азербайджан 🇦🇿 — почему-то не такая популярная страна и, на мой взгляд, недооцененная. Выбор тут из городов для жизни, пожалуй, единственный, но очень хороший - Баку. Поистине столица! Тут точно есть все условия для жизни, инфраструктура, жилье и прочее. А цены на жизнь и аренду еще не разогнаны до околокосмических цифр.

——————

Надеюсь, было интересно. Если кто-то живет сейчас в этих странах, поделитесь пожалуйста в комментариях🙂

⚡️ЗНАНИЕ И ПОНИМАНИЕ ЭТИХ ТЕРМИНОВ И ТЕОРЕМ ПОВЫСИТ ВАШ ГРЕЙД НА СОБЕСЕДОВАНИИ. ЧАСТЬ 1⚡️

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

👀Дисклеймер:

Понятие согласованности — одно из самых неоднозначных в ИТ.
❗️Важно: значение термина меняется, если речь идет о БД или распределенных системах. В CAP, ACID и модели согласованности данных - термин согласованность имеет разные оттенки смысла.

CAP - теорема (теорем Брюера)

В CAP говорится, что в распределенной системе возможно выбрать только 2 из 3-х свойств:

-🔠 Consistency — согласованность данных. На всех не отказавших узлах одновременно одинаковые (с точки зрения пользователя) данные.
-🔠 Availability — доступность. Каждый не отказавший узел всегда успешно отвечает (на чтение и запись).
-🔠 Partition tolerance — устойчивость к фрагментации. Даже если между узлами нет связи, они продолжают работать независимо друг от друга.

Следствие из этой теоремы: распределённые системы делятся на три класса в зависимости от поддерживаемых свойств — CA, CP, AP.

🟧CA
В системах класса CA во всех узлах данные согласованы и обеспечена доступность, при этом она жертвует устойчивостью к распаду на части. Другими словами, мы можем достичь высокой степени согласованности при относительно небольшом времени простоя, но мы рискуем, что проблемы с сетью приведут к сбою всей системы или, по крайней мере, вызовут сбои.
Системы CA обычно основаны на традиционных реляционных базах данных, таких как MySQL👩‍💻, PostgreSQL👩‍💻, MSSQL👩‍💻 или Oracle.

🟧CP
Система вычислений класса CP в каждый момент обеспечивает целостный результат и способна функционировать в условиях распада, но достигает этого в ущерб доступности: может не отвечать на запрос. Самый популярный пример CP системы — MongoDB👩‍💻.

🟧AP
В системе вычислений класса AP не гарантируется свойство согласованности данных, но при этом выполнены условия доступности и устойчивости к разделению. Большинство NoSQL-систем принципиально не гарантируют целостности данных, и ссылаются на теорему CAP как на мотив такого ограничения. Яркий пример AP системы — CouchDB, Cassandra, ScyllaDB.

Поскольку в AP системах мы не можем добиться очень важного свойства - согласованности данных (а, если быть точнее, в терминах моделей согласованности - строгой согласованности), то главной задачей при построении AP-систем становится обеспечение некоторого практически целесообразного уровня целостности данных (т.е. понижения требования к свойству согласованности). В этом случае про AP-систем, как правило, говорят, либо как о «согласованных в конечном итоге» (eventually consistent) или как о «слабо согласованных» (weak consistent).

💫 В следующей части рассмотрим модель согласованности данных.

В дополненни к прошлому посту ⬆️

AP СИСТЕМЫ

AP-системы, которые обеспечивают доступность (Availability) и устойчивость к разделениям (Partition Tolerance) в ущерб строгой согласованности (Consistency), необходимы в ситуациях, где важно, чтобы система всегда оставалась доступной, даже в условиях разделений сети или отказов отдельных узлов.

Вот несколько примеров самых популярных AP-систем:

1️⃣ Социальные сети

Facebook, Twitter и Instagram часто используют AP-системы для хранения и доставки контента, такого как посты и комментарии, которые могут быть временно несогласованными (eventually consistency), но всегда доступны.

2️⃣ Мессенджеры

WhatsApp, Telegram, Slack, VK, ... должны гарантировать, что сообщения доставляются пользователям, даже если некоторые серверы временно недоступны:

- Availability: Пользователи должны иметь возможность отправлять и получать сообщения в любое время.
- Partition Tolerance: Сообщения могут доставляться с некоторыми задержками или повторениями, но система продолжает работать даже при разделении сети.

Опять же в большинстве случаев применяется eventually consistency (сообщения в чатах в итоге на разных узлах серверов будут согласованы со временем)

3️⃣ Файловые системы и системы хранения данных

Пример: S3 - должен быть всегда доступными для чтения и записи данных, даже если часть серверов недоступна.

4️⃣ Системы доставки контента (CDN)

CDN — это распределенная сеть серверов, которая предоставляет контент пользователям с ближайших к ним серверов. Примеры CDNs включают Akamai, Cloudflare, ...

- Availability: CDN всегда старается предоставить пользователю контент. Если один из серверов недоступен, запросы будут перенаправлены на ближайший доступный сервер.

- Partition Tolerance: CDN продолжает работать даже при разделении сети. Пользователи будут обслуживаться ближайшими доступными серверами, даже если некоторые части сети становятся недоступными.

CDN может кэшировать устаревшую версию контента для обеспечения доступности. Обновления контента могут быть задержаны или не синхронизированы мгновенно между всеми серверами (опять eventually consistency)

5️⃣ DNS (Domain Name System)

- Availability: DNS должен всегда отвечать на запросы, чтобы пользователи могли находить нужные веб-сайты. Если один DNS-сервер недоступен, запросы будут отправлены на другой сервер.

- Partition Tolerance: DNS продолжает функционировать даже при разделении сети. Различные DNS-серверы могут продолжать работать независимо друг от друга.

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

6️⃣Базы данных Scylla, Cassandra

Лучше всего описано в первоисточниках тут и тут.

📏📏📏📏📏📏📏📏📏

Как достигается "достаточная согласованность"? Все зависит от системы, необходимого уровня консистентности данных (будем рассматривать позже) и применяемых алгоритмов консенсуса (2PC, Gossip, Paxos, ...). Чаще всего eventually consistency достигается дополнительными фоновым процессами приводящие данные на разных узлах в согласованное состояние.

🔔 ВНИМАНИЕ 🔔

📆2 августа ваш покорный слуга выступает с докладом на Ural Digital Weekend с темой:
«50 оттенков кеширования: от in memory к многослойному redis-кластеру».

В своем докладе расскажу про задачи, которые стояли перед моей командой в Ozon, как мы их решали и адаптировали нашу архитектуру кеширования данных на примере Redis. Также поведаю какие ошибки мы совершали и к чему в итоге пришли.

Делюсь с вами личным промокодом CHENSKYGIFT10, который дает СКИДКУ 10% на билет Ural Digital Weekend 2024. Количество билетов ограничено! Следите за новостями конференции по ссылке и на канале конфы!

Жду вас на конференции и до встречи!

Конференция организована компанией Spectr при поддержке Тэглайна

📹ЗАПИСЬ ОТКРЫТОГО УРОКА ПО KUBERNETES 👩‍💻

https://www.youtube.com/watch?v=NbXtSLv2ek0

⬇️Презентация урока ниже ⬇️