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 - отсюда можно в дев
- потом сразу в мастер ветку - оттуда тест и препод
- выставляем тег и катим в прод

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

INGRESS

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

LB

Лоад балансер в кубе это такой тип сервиса который под капотом имеет node port и делает запрос в провайдера на сетевым балансером.
Nodeport по сути просто начинает биндить порт на нодах, и как раз на него вешается таргер балансера.
Это может быть нужно как раз для ингресов, что бы начать слушать 443 порт и принимать запросы из интернета.