📍Олег Козырев - IT и жизнь ️

Postgres вместо Redis, Kafka и Elasticsearch это реально? Англоязычный YouTube в этом году хайпит видосами в духе "я заменил весь стек одним Postgres и кайфую". Я че хуже, тоже такой ролик сделал)) Поговорим не только о там, как заменить весь зоопарк технологий постгресом, но и оценим когда это стоит делать, а когда это большая ошибка А то можно, как Recall.ai огрести в проде так, что 500 процессов лягут к чертям хех Го смотреть и сразу пилить свои SaaS на чистом постгресе без всякой ерунды ахаха СМОТРЕТЬ РОЛИК СМОТРЕТЬ РОЛИК СМОТРЕТЬ РОЛИК

Монолит воняет, а микросервисы - топ? В эпоху хайпа микросервисов принято считать, что монолит - это жуткое легаси, к которому лучше не прикасаться. Но давайте включим критическое мышление и признаем уже один факт: монолит - это охуенно. Когда проект только стартует, это просто сказка. У тебя одна база данных. Никакой ебли с распределёнными транзакциями, двухфазными коммитами и сагами. Сделал всё в одной БД - и спишь спокойно. Логи, трейсы, метрики собираются в одном месте. Проблемы начинаются, когда проект обрастает мясом. Монолит реально сложнее масштабировать горизонтально. Чтобы сделать конфетку, ты должен реально шарить: строить чистую архитектуру, грамотно резать систему на bounded-контексты и не допускать жесткой связанности. В микросервисах с этим проще. Навалить говнокода на Go там как нефиг делать, но из-за малого размера сервисов это не так критично бьет по рукам. Да, микросервисы решают проблему масштабирования. Но вместе с этим они приносят с собой просто тьму инфраструктурного геморроя. Вам резко понадобится нанять кучу девопсов и инженеров, чтобы всё это чинить. Распределённый деплой, сбор метрик из сотни мест, согласованность данных. У каждого сервиса своя база - а что делать, если соседний инстанс недоступен? Как жить с CAP-теоремой? Что делать с разными дата-центрами? Начинается такая свистопляска, что масштабирование уже не кажется легкой прогулкой. В итоге, микросервисы - это не волшебная пилюля. Это вынужденная мера, к которой индустрия пришла, когда уперлась в проблемы больших монолитов. И это точно не конец эволюции. Погуглите кейс Amazon Prime Video - ребята пожрали говна с микросервисами, переехали обратно на модульный монолит и счастливо выдохнули. Туда же можно докинуть историю компании Segment, которые наплодили больше 150 микросервисов, сошли с ума от сложности поддержки, а потом бахнули всё обратно в единый монолит. Итог: количество критических инцидентов упало на 60%, а экономия на инфре составила больше $6 млн ежегодно! Так что не исключено, что мода скоро развернется. Когда-нибудь человечество придумает новую архитектуру, и мой курс по микросервисам на Go придется переименовывать во что-то типа «Моносервис и Микролит» ахах А вы в команде сейчас на чём сидите? Пилите микросервисы или спокойно живёте с монолитом? 👇

Тот момент, когда вышел на рынок уверенный в себе, а у рынка иное мнение на твой счет😂 Смотреть до конца!!! P.S. ощущение от ноги в бочину словно вкусный офер отозвали - также щемит в груди ахах

От 150К до 450К: один Worker Pool на Go Разбираю задачу про worker pool так, как её решают junior, middle и senior Go-разрабы. Показываю что отличает каждый уровень в глазах интервьюера: какие косяки валят джуна и заставляют его код паниковать на проде, какие архитектурные приёмы тянут на крепкого мидла, и какие 6 уточняющих вопросов сверх кода могут задать на сложном собесе. Попадалась на собесах эта задача? СМОТРЕТЬ ВИДЕО СМОТРЕТЬ ВИДЕО СМОТРЕТЬ ВИДЕО

Хочешь добавить ещё девятку к availability? Готовь двойной бюджет Твой сервис за год висит меньше часа, не пятисотит, факапы решаются моментально, пользователи довольны. Красота же? Не совсем. Есть в индустрии такая штука, как availability - уровень доступности сервиса. Если отвечает ошибкой на ошибку пользователя, все ок. А вот если вылетает «500 Internal Server Error», то с доступностью проблемы. И в этой теме важны показатели SLA, SLO и SLI. То есть что ты обещаешь клиенту, какая у тебя внутренняя цель и что есть по факту. Почему? Все просто. Во-первых, если SLI за период просел ниже SLA, всё, ты сосёшь. Бизнесу может прилететь за нарушение договора. Во-вторых, от этих показателей фактически зависит, сколько в пересчете на год будет лежать сервис. Вот примерное время простоя сервиса при разной доступности: → 99% (две девятки) – 3,65 дня → 99,9% (три девятки) – 8,76 часа → 99,99% (четыре девятки) – 52,6 минуты → 99,999% (пять девяток) – 5,26 минуты И чем больше девяток после запятой, тем меньше времени все лагает. А теперь прикинь, как нужно обмазаться гарантиями, чтобы добиться часа простоя в год? Просто, чтобы добавить одну девятку после запятой, ты потратишь столько же денег, сколько уже вложил. Казалось бы, какая ерунда, 0,09%. А бабла вылетит немеренно. Вот, как это обычно происходит в реальности. Есть сервис, который в любой момент может наебнуться. И будет лежать, пока инженеры не поднимут. А это время. Если мы хотим крутую доступность, придется страховаться. Создавать несколько копий, подключать кубер, который их поднимет, нанимать инженеров, которые кубер настроят и будут поддерживать, подключать сервера под кластер. Вот и полетели бабки ради одной девятки))) Датацентры горят, железо умирает, экскаваторы перерезают кабели – закон Мёрфи никто не отменял) Есть база данных, в которой рано или поздно отрубится нода. Че делать, чтобы доступность держать? Создавать реплики, учитывать в проектировании расхождение данных между ними. А под это нужна отдельная команда базистов и команда, которая делает платформу поверх, чтобы разрабам не было больно. Вот так все и раздувается ради красивых циферок 99,999%. И спрашивается, нахера? А все просто. В апреле 2025 году сбой Spotify в 43 минуты обошелся компании по приблизительным оценкам $387 000. У Amazon аутаж в 59 минут в 2021 году съел ~$34 млн. По грубым оценкам, минута простоя Amazon стоит около миллиона долларов. И да, им важна каждая девятка после запятой. С другой стороны, если у тебя внутренняя админка для пяти человек из бэк-офиса, пять девяток тут точно не сдались и стоить это будет космических усилий и бабок. Так что главный вопрос не в том, как получить 99,999%, а зачем это вообще нужно? И стоит ли простой тех денег, которые нужно вложить в очередную девятку. А тебя менеджеры задалбывали дрочью на доступность и полировкой старых фич вместо работы над новыми? 👇

Открываю менторство по Go У меня уже было много ребят, которым я помогал свитчнуться на Go благодаря курсу по микросервисам. И в целом по техничке вытаскивать людей получается норм. Но там есть нюанс. Курс закрывает только техническую часть. А сам переход на Go - это ебать какая нетривиальная задача. Тут начинаются вопросы с собеседований, легенда, резюме, HR-фильтры, и для многих ребят это тёмный лес. Курс прошёл, технически разобрался, всё круто, а как это в оффер на гошке превратить - непонятно. И чтобы закрыть полностью все эти моменты, я решил сделать менторство, для тех кто хочет максимально комфортно перейти на го, без потери в ЗП. Сейчас фокус заточен именно на свитчеров. Это middle/senior с Java, PHP, C#, Python, кто уже шарит за HTTP, базы и бэкенд и устал от своего языка. Плюс фронтендеры, которым надоело верстать и хочется переехать в нормальный бэк. Максимальный упор делаем на практику и технические навыки, чтобы ты после оффера и испыталки понимал что делаешь, а не плыл первые полгода в новом стеке Внутри учебный проект с REST API на chi, PostgreSQL в Docker с миграциями, транзакции с обработкой конфликтов, поход во внешний API с context и graceful degradation с полноценным ревью кода. Мок-собесы по Go и проектированию сервисов под реальные интервью в Авито, Озоне, Т-Банке. Дальше ментор тебе составляет нормальную легенду и резюме, которое проходит авто и нейро-фильтры на хх. А когда устроишься на работу, чтобы ты на испыталке не переживал за свои навыки, я пошарю тебе курс по микросервисам, который отдельно стоит 70 тысяч, абсолютно бесплатно. Чтобы ты по ходу работы смог подтянуть все технологии и чувствовать себя увереннее. Более подробно про менторство, программу и прочее я буду освещать в отдельном канале, посвященному менторству: ЗАЛЕТЕТЬ В КАНАЛ ПО МЕНТОРСТВУ Туда же буду закидывать эксклюзивные штуки, которых не будет в основном канале. Поэтому если откликается - жду тебя там)

Полгода работы. Последняя задача. И всё рассыпалось Расскажу один случай с прошлой работы из времён бигтеха. Была у меня большая фича на полгода - в Q1 фокус был на проектировании, в Q2 на разработке. И проектирование это не так, что сел, по-быстрому набросал чё-то на коленке и побежал кодить. Это ты готовишь серьёзный дизайн-док, где расписываешь контракты, модели данных, что куда сохраняется, под каким гейтвеем сидит, где рейтлимитером прикрываемся, как роутинг между сервисами устроен, как это работает на стейджинге и в проде. Потом отдаёшь на ревью - сначала команде, потом опытным инженерам, а эти тебе точно в панамку напихают по полной, ахах. Потом стейкхолдерам от продукта, которые этой фичи ждут. С ними же договариваешься, что в Q2 они тоже должны заехать со своими ресурсами. И параллельно думаешь, как эта новая штука с уже существующей системой подружится. Когда всё согласовано, начинается нарезка. Есть 6 спринтов по 2 недели, и в них надо упаковать всю фичу. Дробишь большую задачу на маленькие, и набегает штук 40. Потом раскидываешь, что тянешь сам, а что отдаёшь команде. И тут главное правило, которое я выучил по жизни, не забивай свою пропускную способность на 100%. Максимум на 80. Остальные 20 это запас на форс-мажоры. Кто-то заболеет, кто-то в отпуск свалит, без этого запаса прочности ты на первой же неожиданности едешь в перенос сроков. И вот Q2, разработка пошла. И знаешь, прям кайф программировать, когда заранее всё хорошо спланировал. Спокойненько, задачка за задачкой, спринт за спринтом, всё славно. И так доходим до финального спринта. Буквально последняя задача, по сути просто пустить трафик на готовую фичу. И тут всплывает та самая мелочь, которая на этапе проектирования ушла из виду, а в разработке её никто не замечал, все были заняты самой фичей, а не вводом в эксплуатацию. Тут мы сели в лужу. В продукте было нестандартное устройство окружений - окружений было целых четыре. У пользователя свой прод и свой стейджинг, и у нас внутренний прод и стейджинг. И между нашими четырьмя и его двумя нужно было как-то хитро прокинуть роутинг. А он, сука, не мэтчился. Просто не работало оно в такой схеме. Если совсем честно, корни проблемы были не в моей фиче, а в устоявшейся архитектуре всего продукта. Но это никого особо не волнует, делать-то надо, неделя осталась. И на кону не задачка из спринта, которую можно дропнуть. На кону полугодовая фича, квартальные цели, перформанс-ревью. И вопрос «а хер ли ты делал?». Долго сидел, башку ломал, нейронки напрягал, но чё-то вообще никак. В шахматах это называется цугцванг, когда любой ход хуже текущей позиции)) Единственный выход, который придумал, прорубить окно со стейджинга на прод в одном из сервисов. Понятно, что это не самая безопасная штука, но в итоге, клятвенно молясь, удалось уговорить безопасников. И ааааа, все заработало, KPI закрыли, премии получили. Вот тогда до меня и дошло, что ADR это не страховка. Можно его вылизать, прогнать через 10 ревью, заложить все корнер-кейсы, но всё равно часть нюансов вылезет только в коде, и часто ближе к финишу. И это норм. Главное не паниковать, а садиться и думать, как из этой жопы выехать 😱 Кста, забавный момент. Костыль, который пришлось ставить, потом стал поводом пересмотреть всю архитектуру. Та особенность с четырьмя окружениями стрейнила и в других местах, не только в моей фиче. Так что моя жопа на финише квартала, по сути, породила прогресс ахах А у вас бывали такие истории, когда план разваливается на последнем шаге? Как выкручивались?

Ты пишешь middleware в Go неправильно За 40 минут разбираем все 5 middleware, которые нужны продакшн-сервису и почему их порядок применения ломает сервис так, что в логах будет тишина, а ты полночи разбираешься, почему всё легло. СМОТРЕТЬ РОЛИК СМОТРЕТЬ РОЛИК СМОТРЕТЬ РОЛИК

Я ругал геткурс за упоротый ux и в целом говнистый сервис, но эпл переплюнул их. У меня отвалился варик оплаты подписок с телефона. Первая тупость в том, что нельзя скачать даже бесплатные приложения, если метод оплаты битый. Я думаю ну ок, просто закину на бабла на эпл аккаунт через подарочную карту и дело в шляпе Закинул, то есть появился второй варик оплаты с аккаунта, взамен битому с телефоном. Пробую качать и вновь ошибка. Мол нельзя, чтоб хоть один метод оплаты был битый. Кринж нарастает Думаю удалю битый метод и все точно будет хорошо, НО яблочный сервис говорит неее брать низя удалять метод оплаты, когда подписки активные имеются и пофиг, что есть еще один метод оплаты Отменяю все подписки и все равно хрен, этого мало. Эпл хочет, чтоб эти подписки истекли, а одна из них до ноября По итогу имеем рабочий метод оплаты, но из-за второго нерабочего я не могу скачивать вообще никакие приложения до ноября! Иной раз кажется, что там спец департамент сидит, который придумывает наиболее идиотские решения в сфере финансов. А если кто-то здравое принесет в беклог, то его сразу увольняют) Сталкивались с таким? P.S. а в форме сапорта, до которой можно добраться только с помощью клода, всего 250 символов лимит) будь краток, блять, говорит корпорат ахаха

Монорепа звучит удобно, пока не упрёшься в общий CI Вспомнил тут одну историю из проекта на котором работал какое-то время назад - монорепа, общий CI, всё в одном месте. Звучит удобно, а на деле получилась та ещё история) Сначала на всякий случай, чтобы не путали. Монорепа это не монолит. Это вполне могут быть те же самые микросервисы, просто весь код лежит в одном репозитории, и там как-то разделён по модулям. В чём плюс этой штуки понятно: всё в одном месте, не нужно подтягивать импорты из других репозиториев, постоянно синхронизировать версии и всю эту хрень. Всё рядышком лежит, бери и работай Но проблема вот в чём. В монорепе сильно повышаются требования к изоляции модулей друг от друга, чтобы абстракции не протекали и всё такое. И конечно же CI должен быть настроен хорошо, потому что если нет, то это превращается в какой-то хаос Такая схема часто встречается в стартапах, но и не только. И вот тут часто так получается, что все бегут вперёд паровоза, быстрее быстрее, фичи фичи, а на нормальную настройку CI всем плевать. И потом на дистанции это начинает очень сильно аффектить скорость разработки Так, я работал в одной компании(достаточно крупной), где было несколько десятков сервисов в одной репе навалено, и общий CI. И вот этот CI, это пиздец Ну то есть ситуация такая. Выкатываешь простенький релиз, даже на стейджинг. Проходят стадии билда, линтеры, тесты, и вот наконец-то в ручном режиме можно нажать кнопку чтобы раскатить на стейдж. Ты пытаешься это сделать, а параллельно кто-то уже лезет в мастер с каким-то релизом. И где-то на середине выполнения джоба у тебя вылезает ошибка со словами, типа "Чувак, у тебя там обновился мастер, я ничего не буду раскатывать, давай подтягивай мастер сперва". Ты подтягиваешь, и весь CI начинает по новой. Билд, линтеры, тесты, прочая херня. Ты такой окей, раскатываем на стейдж. И опять тоже самое. ААААА. И я не знаю, я раз в пять наверное, если не больше, об эту хуйню спотыкался. Мне нужно было какой-то маленький фикс сделать, и я такой ёбаный в рот. Спрашиваю у других, типа у вас такая же фигня? А они мне базарят, ой да это классика. Учитывая что современная разработка предполагает частый цикл релизов, это не история когда ты накопил кучу изменений и одним релизом раз в две недели сделал, а ты в день можешь несколько релизов гонять, это приводит к откровенному безумию. Постоянно какие-то заторы на стейдже, и ты сидишь и думаешь, блядь, а как это тестировать нормально, если ты раскатить не можешь, всё это снесут к херам Пути решения этой проблемы есть, но там это просто не было настроено. Самый просто способ - это разделить код на репозитории и итакого хаоса просто не будет. Это не значит что отдельные репы это панацея, там своих проблем хватает, синхронизация версий, один сервис может сломать контракт, второй ещё ничего не обновит и так далее. Но вот этой проблемы с выкаткой точно не будет. У тебя просто разные CI-пайплайны, и они вообще не пересекаются Короч, этот момент настолько остро во мне разыграл, что я до сих пор иногда вспоминаю. А у вас на работе монорепа или мультирепа?