CLOUD

Сейчас появляется разделение облаков на гиперскейлеры и неоклауды.
Пока это не четкие термины, больше наминальное разделение.
Как я это понимаю.
Гиперскейлеры - огромные облака с десятками датацентров. В них огромное количество сервисов, от барметала и виртаулизации, до менедж куба и лямбда вычислений. Например AWS и GCP.
Неоклауды - несколько датацентров и фокус на определенные сервисы. Тот же самый nebius, которые делает клауд для AI вычислений и делает это очень хорошо.

Понятно, гиперскейлеры могут делать сервисы для AI а неоклауды кучу сервисов. Но тут вопрос качества и фокуса)

LAMBDA

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

GHZ

Про частоты процессора.
Если мы проектируем кластер то что делать с частотами процессора. Больше частоты и меньше ядер? Или же больше ядер и меньше частоты?
Допустим у нас есть два процесса которым для расчета нужно по 250 миллионов операций. Где одна операция это один такт процессора.
И допустим у нас есть два варианта:
1. Одно ядро на 3 Ггц
2. Два ядра по 2 Ггц

Тут 1ггц это миллиард операций в секунду.
По итогу - нам надо выполнить на обоих вариантах 500 операций для двух равных процессов.
В первом случае мы займем 1/6 времени процессора.
Во втором разделим два процесса по ядрам и выполним за 1/8 времени процессора.

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

SYNC

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

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

MEM

В gpu кластерах, когда у нас несколько карт в рамках сервера, важня шина данных.
Ведь мы делаем это что бы поместить в общую память данные или модель и считать их на нескольких чипах. Поэтому скорость синхронизации между памятью чипов тут очень критична.
У nvidia сейчас это nvlink, который позволяет сделать кластер из 8 карт, с минимальным латенси.
Понятное дело, перегонять данные между чипами все равно вызовит задержку, поэтому современные алгоритмы стараются считать данные на том чипе который ближе. Но nvlink все равно довольно быстрый)

DIST

Радует тенденция. Вендоры софта который ставится на сервер все чаще предоставляют его в виде докер образов и композа.
Выдает креды до своего регистри и манифест разворачивания, плюс лиценцию.
Очень удобно, можно развернуть весь софт буквально за 5 минут и сразу начать пользоваться)

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

TBD

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

Пару лет назад уже кидал сюда, но снова залип на концерты в Берлинской филармонии)

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

Ну и как уж не закончить вечер на shortparis)
https://www.youtube.com/watch?v=IMRxAi8_xx0

DOCKER

Контейнеризацию можно воспринимать как ООП.
Где образ это класс, по сути набор методов которые можно исполнять, слепок.
А контейнер это объект класса, отдельная сущность на основе обьекта, с своими параметрами. Мы можем плодить множество объектов одного класса которые со старта будут отличатся аргументами.
Например - образ с постгресом, на его основе мы можем запустить множество контейнерв с разными настройками авторизации. Это будет множество разных объектов одного класса постгрес)

Погнали)

FEDORA

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

DOCKER

В контексте контейниризации нам больше важно ядро а не сам дистрибутив.
Ведь она использует миханимы ядра, cgroups и неймспейсы. Тут весь остальной дистрибутив играет роль, но больше в контексте стабильности, что бы система просто не падала.
Поэтому мы можем быстро мигрировать контейнеры между дистрибутивами линукса, и идеале использовать минималистичные. Есть например fedora coreos, в которой нет почти ничего, кроме вещей нужных для контейнеров)
Для меня тут оснавная красота в том, что мы можем собрать образ в котором есть только бинарник и запустить его на системе в которой нет почти ничего кроме ядра. Очень минималистично)

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

Если что вот
https://www.youtube.com/watch?v=Wkl-lqf6ZU8&t

INFRA

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

AI

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

FEDORA

Сегодня у меня небольшой челендж - просидеть весь день на федоре,
Пока успешно, поделал задачи и сейчас занимаюсь своими делами. Самое главное для меня - при грамотной настройке федора под гномом может быть максимально удобной для перехода с макоси. Очень близкий дизайн и флоу работы.
С прошлых моих эксперементов с федорой, пару лет назад, особо ничего не изменилось но стало просто чуть удобнее.
Из плюсов:
- Удобнее работать с файлами
- Реальный контроль над системой
- Один основной способ установки софта
- НАТИВНЫЙ ДОКЕР
Из минусов - сама железка. Все же макбук для меня это эталон как сама железяка)

Пересел за мак обратно)
Тактильно приятно, плавная работа и большая герцовка экрана. Что еще нужно для счастья?)

BOOT

Зачем нужны зашрузчики оси.
Затем что операционка может загружаться разными способами. Да, есть дефолтный путь где после биоса загружается ядро и потом сама система. В этом случае мы даже не замечаем загрузчик, просто нажимаем кнопку и система поднимается.
Но есть случаи когда у нас есть несколько вариантов ядер и варинтов загрузки. Тогда мы после загрузки биоса попадаем в загрузчик и выбираем способ загрузки системы.
Задача загрузчика по сути в том что бы правильно стартануть систему с нужными нам настройками. В линукс мире чаще всего используется grub. У него довольно гибка конфигурация которая позволяет писать разные флоу загрузки и подстраиваться под системы с множеством ядер и дистрибутивов.

WINDOWS

Вчера решил почитать про мир виндовых серверов, это что то далекое от меня.
Из интересного, там все чаще начинают применять инфровые методологии которые есть в мире линукса.
Например декларативное описание системы, инфра как код, GitOps подход. Да, для этого там используется другое стек технологий, но сам факт.
Это радует, может когда ни будь винда станет адекватной системой без переусложнений и легаси наследия. Там даже аналог линуксовой контейниризации начинает использоваться)
Но пока что винда явно не проникнет в мир веб разработки, сейчас самые современные технологии все равно лучше работают на линуксе. Да и хорошо что не проникнет, меньше рвотного рефлекса будет)