Итоговая конверсия в первую беседу с рекрутером вышла приблизительно 5 из 200. До первого технического собеседования дошел с 3-мя компаниями, среди которых был, к примеру, amazon. Привет Безосу!

➡️ Подготовкой к собесам в современные бигтехи, как бы это неправильно ни звучало, нужно заниматься несколько месяцев, включая не только литкод, но и system design и поведенческие интервью, особенно учитывая, что литкод встречается в работе примерно никогда ;) На самом деле кейсы применимости знания сложных алгоритмов есть в индустрии, но это уже очень специфические позиции. Например, разработчики СУБД.

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

Мой 2024: часть 2

Продолжаю рассказывать про переезд в Нидерланды и работу в международном бигтехе.

Процесс собеседований прошел на удивление неплохо, учитывая выделение достаточно большого времени на подготовку и вот он, желанный оффер. Да и еще и с поддержкой в релокации, включая все требуемые документы. Набор достаточно обычный: собеседование с рекрутером, литкод, system design, behavioral interview и финальная встреча с рекрутером. Затем 3 месяца подготовки к переезду с семьей и котом из Еревана в Амстердам, получение визы и так далее.

➡️ Отдельная история с перевозкой кота, с необходимостью подготовить все требуемые документы для животных, но это ни в какое сравнение не идет с историей, которой со мной поделился рекрутер компании. Они помогали перевозить в Нидерланды… Лошадь! Так что кот - это мелочи :)

И вот, наконец, Амстердам. На удивление солнечный. Все лето было довольно немного дождей, но Северное море даже в жару все равно холодное, а полчища медуз так и норовят ужалить тебя :)

Процесс онбординга, знакомство с продуктами компании и используемыми инструментами и вся изначальная суета длились порядка 2-х месяцев, после чего я начал брать довольно сложные проекты для реализации, требующие изучение нового тулинга, взаимодействия с множеством команд с разных концов Земли, написания design docs и претворения всех технических фантазий в жизнь.

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

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

А как прошел ваш 2024?

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

Привет, как ваше настроение? Готовы к двухдневной рабочей неделе?))

Тем, кто дежурил в праздники, соболезную, тем, кто отдыхал — держитесь, скоро вы втянетесь.

Врываюсь в канал, чтобы позвать вас на вебинар, который мы вместе с Кириллом Борисовым проведем 16 января (соскучились?))

Тема вебинара 👉 Observability и k8s: полный контроль над инфраструктурой и сервисами

Поговорим о том, какие проблемы решает Observability:
▶️Выявление аномалий в работе кластера
▶️Мониторинг сетевой активности и предотвращение сбоев
▶️Обеспечение соответствия политик безопасности
▶️Снижение времени простоя за счет быстрого устранения инцидентов
▶️Упрощение эксплуатации сложных систем с минимальными затратами

А ещё:
✅ Рассмотрим внутренние инструменты k8s, связанные с безопасностью и отладкой работы кластера
✅ Посмотрим на инструменты, полезные для понимания работы больших систем без необходимости внедрения большого кол-ва изменений в сервисы, написанные на разных языках и фреймворках.

Когда: 16 января в 19:00 мск
Регистрация — через бота ⬅️

Всех жду!

Что такое Design Patterns?

Если говорить нормальным языком, то это — проверенные временем костыли для типичных проблем разработки.

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

Составил краткий гайд по самым популярным 👇

1️⃣ Sidecar Pattern
Добавляем контейнер в Pod, чтобы расширить функциональность без переделки основного приложения. Например, можно расширять логи, мониторить запросы или проксировать их, добавляя полезную (или не очень) нагрузку.

Его можно условно разделить на 2 подвида:

1.1 Adapter Pattern – натягиваем старые приложения на новые реалии. Например, парсер логов, который делает их читаемыми (ну или хотя бы похожими на читаемые). Вскоре познакомимся с ним поближе.

1.2 Ambassador Pattern – добавляем посредника для общения сервисов. По сути на нем построен service mesh, работу которого мы еще разберем в одном из будущих постов.

2️⃣ Init Container Pattern
Контейнеры для подготовки основного приложения перед запуском. Подходит для выполнения миграций БД, прогрева кеша или просто оттягивания неизбежного падения сервиса. Тут важно понимать, что если у вас N реплик приложения, то N init контейнеров и запустится, поэтому те же миграции БД должны поддерживать атомарные операции с взятием блокировок, например, для избежания race conditions.

3️⃣ Operator Pattern
Автоматизируем управление сложными штуками в Kubernetes: базы, кеши, stateful-приложения – пусть лучше за этим следит робот, а не вы.

4️⃣ Controller Pattern
Те же операторы, но встроенные в Kubernetes. Меньше кода писать самому – меньше боли в поддержке (но это не точно).

5️⃣ Leader Election Pattern
Организуем выбор лидера среди нескольких экземпляров сервиса. Полезно, если ваша база данных хочет знать, кто тут главный. Применимо, конечно, не только для баз данных.

6️⃣ Self-Healing Pattern
Kubernetes сам перезапускает упавшие или зависшие сервисы. Использует Liveness и Readiness Probe, чтобы не ждать, пока кто-то из команды заметит, что всё давно сломалось.

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

Привет! Надеюсь, все окончательно стряхнули с себя остатки новогодних праздников и готовы к плодотворной работе 🔥

В предыдущем посте мы рассмотрели, какие бывают паттерны в k8s. Сегодня хочу немного подробнее поговорить про сайдкары, и как они применяются на практике.
#полезный_материал

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

Смотреть 👇👇👇

Продолжаем говорить про паттерны в кубах.
#полезный_материал

Ловите вторую часть видео: кейсы сбора и модификации логов с приложений, которые пишут логи в файл.

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

Подробнее про сайдкары и хранение секретов мы говорим в 8 теме Kubernetes Мега. В конце курса отдельно говорим и про другие паттерны — operatror и service mesh. Предлагаю разобраться вместе 🤗

Старт потока 27 января. Занять место — по ссылке 👈

Всем привет!

Вебинар по observability уже совсем скоро — завтра в 19:00. Ведущих будет трое: я, кот и Кирилл Борисов.

Ставьте лайки и огонечки, если хотите, чтобы Маркус тоже был на вебе❤️🔥

Занять место — через бота ⬅️

Маркус выглянул из укрытия, чтобы напомнить:

👉 Вебинар по Observability сегодня в 19:00

Поговорим о том, какие проблемы решает Observability:
▶️Выявление аномалий в работе кластера
▶️Мониторинг сетевой активности и предотвращение сбоев
▶️Обеспечение соответствия политик безопасности
▶️Снижение времени простоя за счет быстрого устранения инцидентов
▶️Упрощение эксплуатации сложных систем с минимальными затратами

А ещё:
✅ Рассмотрим внутренние инструменты k8s, связанные с безопасностью и отладкой работы кластера
✅ Посмотрим на инструменты, полезные для понимания работы больших систем без необходимости внедрения большого количества изменений в сервисы, написанные на разных языках и фреймворках.

Ссылки на трансляцию будут в боте. Подключайтесь!

🔥 Мы начинаем 🔥

Ссылки уже в боте. Всех жду!

Привет! На связи Маркус.

Я тут питон решил изучать. По мне видно, насколько он мне заходит, но я не сдаюсь!

А пока я продираюсь сквозь синтаксис, ловите документацию, про которую мой человек говорил вчера на вебинаре:

👉 Kubernetes auditing

👉 How to use Kubernetes events for effective alerting and monitoring

👉 OpenTelemetry

Впереди выходные, отличный повод, чтобы изучить. До понедельника!

Привет!

Мы с вами успели уже довольно много поговорить о кубах — потрогали паттерны, разобрались с сайдкарами, вникли в работу реквестов и лимитов. Думаю, у некоторых из вас в процессе возникли вопросы, которые хотелось бы обсудить.

Предлагаю встретиться в прямом эфире и поговорить о том, что больше всего болит — по темам, которые уже были в канале, или просто в контексте кубов и инфраструктуры.

➡️ Когда: 23 января в 18:30 мск

Вопросы собираем в комментариях к этому посту 👇 (спросить голосом тоже можно будет, так что если планируете прийти и спросить, но писать комментарий лень — ставьте 🔥)

Маркус ждет ваших вопросов!

Привет! Сегодня поговорим про деньги.

Но не про те деньги, про которые вы могли бы подумать. Не про зарплаты.

Сегодня про деньги, которые вы сливаете в облако, не подозревая об этом. Вроде бы мелочь: пропустил одну строку конфигурации — а потом обнаружил, что финдир поставил тебе встречу после ежегодного анализа бюджета компании.

❗️Disclaimer: важно понимать, что у облаков много плюсов, но подходить к их использованию стоит аккуратно. Пост не ставит целью призвать кого-то бежать из облаков на собственные сервера, а лишь служит напоминанием про масштабы ответственности, которую на себя берут инженеры в компаниях.

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

Посмотрим типичные примеры, озаглавленные общей идеей «Играл с облаками и проиграл»

1️⃣ Overprovisioning

Вы решили прикинуть размер виртуальных машин для нового сервиса и выбрали X4 на основе ожидаемой нагрузки. Но по факту оказалось, что сервис потребляет от силы 10% выделенных ресурсов, а в графики потребления ресурсов мало кто заглядывает, пока все идет хорошо. Вы только что переплатили облаку в 5 раз, но узнаете про это немного позже.

2️⃣ Стоимость трафика

Поставили тестовый сервис, который через NAT Gateway ходит в S3. Да, в проде. А что, работает же. Потом пришли счета за трафик — просто космос. А всего-то нужно было использовать S3 VPC Gateway Endpoint, и было бы счастье. Но опять же, никто это не мониторил и не задумывался об оптимизации.

3️⃣ Автоскейлинг (нет)

Вы ведь не тестируете в проде, правда? Для таких случаев у вас наверняка есть dev инфраструктура. Надеюсь, полностью в отдельном аккаунте облака, чтобы случайно не сломать прод. Но вот нюанс: dev простаивает ночами. Его можно было бы тушить с 18:00 до 9:00, а заодно отключить лишние реплики, бэкапы, CDN и прочее, что в проде критично, а тут — нет. Но вы об этом могли забыть, и облако снова забирает себе деньги, чтобы подогревать воздух в датацентрах.

4️⃣ Платим за мусор

Представьте, в коде настройки одного ресурса terraform пропущена важная опция. Но это вы уже потом узнаете, когда начнете счета анализировать.
Конкретно речь про incomplete multi-part uploads S3 (почитать подробнее — тут).

S3 bucket конечно же создан новый, под новый сервис. Плановая стоимость его использования рассчитана очень приблизительно, поэтому еще предстоит узнать его реальную стоимость.

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

5️⃣ Но как же мониторинг и алерты?

Спросят дотошные читатели. А вот так. Большие инфраструктуры — это сложно: сегодня ты настраиваешь Kubernetes, завтра разбираешься с S3, послезавтра — с репликацией базы данных. Команда, которая управляет бюджетами, вообще может сидеть в другой стране. Пока вы укладываетесь в их планы, никто не проверяет, на что именно идут деньги.

6️⃣ FinOps — спаситель или костыль?

В современном мире появилась даже специальная должность — FinOps. Но если у вас нет отдельного человека, то будьте добры: садитесь и разберитесь, как оптимизировать свои расходы самостоятельно. И помимо стандартного мониторинга подумайте и настройте еще и мониторинг костов.

➡️ Почему это важно?

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

➡️ Мораль
Никогда не рассчитывайте, что облако всё сделает за вас. Настройки по умолчанию — это компромисс, который подходит на старте. Что применяет компания X, может частично или полностью не работать для компании Y. Хотите надежную, оптимальную и недорогую инфраструктуру? Изучите возможности и ограничения каждого сервиса, который используете. И не поленитесь почитать документацию сервиса перед выполнением terraform apply).

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

Остались вопросы? Напоминаю, что о наболевшем можно спросить в комментариях к этому посту — на лайве разберем 🔥