CPU

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

Небльшой оффтоп. Тут nvidia и шмайкрасофт выпустили новые arm процы и винду оптимизированную под него. Очень жду осени что бы посмотреть что получилось)

SOC

Системы на чипе очень неплохо подходят для локальных маделей.
Прикол в том что основные вычесления там проходят на GPU ядрах, и когда этим ядрам доступна общая RAM всего чипа то это сильно повышает доступный размер моделей. Если брать стандартные GPU которые стоят не миллионы рублей то больше чем 24гб памяти сложно найти. И поднять там модель на 120 миллиардов параметров там не выйдет.
А вот современные M процы от эпла, и новые чипы от nvidia решают эту проблему. Там на одном чипе спокойно может быть хоть 128гб памяти, и можно поместить довольно большие модели.

FRONT

Одна из сложностей в фронтенде это енв.
Часто переменки с настройками можно задать только при билде. И если нам нужно, например, изменить бекенд урл то обычно приходится пересобирать весь фронт.
Это можно обойти. Например указать в entrypoint разные скрипты которые при старте будут подбирать енв и заменять значения во всей статики. Но это очень больно и костыльно.

SSR это когда зумеры переизабрели php шаблоны

FLOW

Флоу разработки не говорит нам как и когда релизить.
Гит флоу, транк, гитлаб флоу и что угодно это по сути способ доставки изменений до прод вети или тега. В теории мы можем использовать любой флоу только с одним прод стендом и все. Ведь они не заставляют деплоить что либо.
Мы можем взять любой флоу и положить на него любой способ релизов и любые дев/тест стенды. Главное что бы было просто удобно)

SH

Шмайкрософт выпустила пакет для винды который расширяет cli юниксовыми командами.
Теперь на винде можно спокойно использовать ls, cp, grep и тд. Раньше для этого приходилось поднимать wcl, по сути почти вм с линукс ядром.
Ну чтож, ждем перехода на юниксовое ядро)

ENV

Цепочка доступа до переменных.
Как переменка из хранилища доходит до приложения на стенде в классическом случае:
- Переменка лежит в ci системе или вольте
- При деплое она подставляется в манифест
- Прокидывается в окружение контейнера
- Приложение подтягивает ее из окружения

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

Пока самое сесурити решение:
- Переменная в вольте рядом с приложением
- Доступ к нему только у одного человека
- Приложение при старте само обращается к вольту и подбирает переменные
- Только приложение по фингерпринту моджет прочесть переменки

Это сильно уменьшает поверхность атаки.

FAST

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

Это поможет сильно ускорить работу сайта и снизить нагрузку. И не придется усложнять себе жизнь с кубом и всей остальной сложной инфрой)

ARM

Сейчас есть тенденция оценивать датацентры не с точки зрения мощности и цены, а с точки зрения потребления энергии.
С современным нейросетями и облачными вычеслениями потребление датацентров ушло далеко за сотни мегават. А в перспективе перешагнет за гигават.
Это большая проблема. Во первых, эту энергию нужно откуда то брать. Во вторых, она почти полностью переходит в тепло которое нужно отводить.
И да, хоть бОльшую часть энергии будут потреблять GPU, ну и CPU все еще потребляет много энергии. Поэтому снижение расхода хотя бы на несколько процентов уже сильно снизит расходы на масштабе.
Тут на сцену выходит ARM архетектура чипов. В большенстве задач она дают такую же производительность на меншей потребляемой мощности. Это позволит датацентрам снизить расходы на миллионы долларов на энергии и охлаждении)

Обновился до macos Tahoe
Придется привыкать к отсутствию лаунчпада
А в целом смотрится красиво

IO

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

ASYNK

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

IOPS

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

INIT

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

LOCAL

Локальные модели которые могут влезть в 24гб макбука довольно тупенькие.
Но, instruct модели могут легко обогощаться поисковым тулингом. И при правельном промте он будет на каждой итерации дозапрашивать данные из интернете и учитывать их при запросе. В целом это помогает, особенно когда делаешь сложный флоу с частым обращением к модели.
Сейчас просто играюсь с ИБ агентом, который работает на локальной модели и строит план сканирования учитывая инфу из интернета. Ну и итеративно вызвает shell мака для запуска разных команд.

MONO

Монореп с микросервисами это необычное удовольствие.
Обычно принято что один репозиторий это один микросервис, а общие либы выносятся в артифакты и тянутся при билде. Это классика.
Но можно сделать все иначе:
- Одна репа
- Каждая директория в репе это отдельный сервис
- Директории с общими либами которые включаются в билд
- На уровне CI/CD множество джоб для билда конкретного сервиса
Ну и на выбор - деплоить каждый сервис как отдельный чарт, или же делать общий чарт, кому как удобнее.
А зачем так делать? Ну это проще. Все в одном месте и нет необхожимости ходить по десяткам реп и настраивать все отдельно. Для небольших команд идеально.
Из минусов, более увесистый CI/CD и сложнее рулить доступами.

FLOW

За последние годы флоу разработки довольно поменялся.
Раньше было так:
feature branch - develop - test - preprod - master
То есть множество бранчей за каждым из которых закреплен стенд.

Ну и по моему все поняли что это не очень удобно. То что нужны более гибкие стратегии.
Сейчас чаще всего это выглядит так:
- feature branch - отсюда можно в дев
- потом сразу в мастер ветку - оттуда тест и препод
- выставляем тег и катим в прод

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