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 порт и принимать запросы из интернета.

UPTIME

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

FLOW

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

PHP

Большая часть интернета написана на php. Но по ощущениям люди который поддерживают эти сайты и пишут новые живут где то в другом мире.
Там до сих пор можно подрубится к серверу по ftp, просто загрузить файлы и перезапустить nginx. Без докера и cicd процессов.
Но тут важно поднимать, большенство этих сайтов максимально простые лендосы и интернет магазины без особой нагрузки. А все эти процессы релизов, кластаризация и отказоустойыивость больше нужна для больших и сложных систем которые и будут писать на php. Отсюда этот разрыв в понимании процессов)

URL

Часто, когда очень много стендов, не удобно вшивать бекенд урл на фронт каждого стенда.
Удобнее сделать относительный путь, по типу:
- фронт на example.com
- бекенд урл указываем /api/
- при обращении на бекенд фронт ображется на свой же домен на урл /api/
- nginx стенда уже сам разруливает куда что отправлять
Это экономит много времени на настройку роутинга запросов)

CONFIG

Столкнулся с интересным кейсом - сеть ресторанов с большим количеством оборудования типа кисков, планшетов и телевизоров. На них стоит софт которые обрашается на сервер.
И вот как обновлять этот софт? Учитывая что ресторан это закрытй контур.
Выбрали pull модель. Есть контролер, это пини пк на каждой точке. Сделали сервис в нашем клауде который хранит актуальные вресии софта. И вот этот контроллер опрашивает этот сервис раз в какое то время и при наличии обновлений сам обновляет все железки.
Это удобная модель обновлений, так как не нужно обращаться на каждую железку, а можно просто опубликовать изменения и все железки сами придут к желаемому состоянию.