Продолжаем опросы)

Второй год подряд ребята из DevCrowd проводят большое исследование Go-разработчиков:
• Что входит в обязанности и каких навыков не хватает
• Сколько в среднем зарабатывают в профессии в зависимости от грейда
• Какие инструменты, сервисы наиболее популярны
• Что читают, слушают и смотрят для профессионального развития.

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

👀Посмотреть результаты прошлого года

Podlodka Go Crew снова в деле! Это онлайн-конференция, где обсуждаются актуальные темы для go-разработчиков.

В новом сезоне особое внимание уделяется архитектуре приложений на Golang. Сессии проводятся в удобное время — утром и вечером.

Чего ожидать?
- «От 1000 скриптов на Bash к (микро)сервисам на Go» — Максим Набоких поделится опытом миграции на Go в рамках крупнейшей kubernetes-платформы.
- «System design: Saga from zero to Temporal» — Антон Цитульский рассмотрит принципы оркестрации и хореографии, используя Temporal, и объяснит, как управлять бизнес-процессами в сложных системах.
- «Спецификации и код: Как выбрать правильный путь между генерацией и интеграцией?» — Леонид Ченский покажет плюсы и минусы разных подходов к работе с API-спецификациями и представит обзор инструментов, которые помогут с автоматизацией.

Билеты в продаже на сайте: https://podlodka.io/gocrew

Также делюсь с вами промокодом:

go_crew_4_drzJzG

Который даёт скидку в 500 руб💖

Делюсь свои докладом с Podlodka Go Crew 🧑‍💻

👀 Запись на YouTube

ЧТО БУДЕТ ПОСЛЕ МИКРОСЕРВИСОВ?

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

1️⃣Сложность управления. Увеличение количества микросервисов приводит к усложнению их координации, мониторингу и отладки. Каждый сервис требует отдельного управления, что увеличивает операционные затраты. Мониторинг становится по-настоящему сложной задачей, когда количество сервисов, инстансов БД и кешей переваливает за 10000.

2️⃣Повышенные требования к инфраструктуре. Микросервисы требуют сложной инфраструктуры для обеспечения надежности и масштабируемости, что может быть дорогостоящим и трудоемким в поддержке. К тому же каждая компания решает проблемы с инфрастурктурой по-своему, как может и умеет, и это накладывает некоторые ограничение на дальнейшее развитие инфраструктуры.

3️⃣Сложность тестирования и отладки. Распределенная природа микросервисов затрудняет проведение интеграционного тестирования и отладки. Протестировать взаимодейтсие 2, 3, 4 сервисов еще вполне можно, но, когда фича затрагивает 10+ доменов, и в каждом домене еще по нескольку сервисов, учавствующих в цепочке взаимодействия, тестирование и координация интеграции превращается в тот еще квест)

4️⃣Снижение производительности из-за необходимости сериализации и передачи данных по сети между сервисами.

5️⃣Проблемы с управлением API, дороговизна изменения и актуализация API сервисов, передача лишних данных или наоборот недостаточных данных. У меня в сервисе был метод, на который было завязано более 80 других микросервисов, и потребовалось больше года, чтобы все клиенты смогли перейти на новый API.

Крупные компании, такие как Google и Amazon, всегда задавали тренд развитию облачных технологий и, естественно, с проблемами огромной микросервисной архитектуры они уже знакомы. В 2023 году, как гром среди ясного неба, начали выходить статьи о проблемах микросервисной архитектуры и новых подходах разработки облачных приложений.

Так, например, инженеры Google предложили разрабатывать приложения как логические монолиты, передавая их в автоматизированные среды выполнения, которые самостоятельно решают, где запускать рабочие нагрузки. По их словам, это позволило снизить задержки в 15 раз и сократить затраты до 9 раз. Для этого они разработали свой собственный фреймворк — Service Weaver

Команда Amazon Prime Video поделились своим опытом перехода от микросервисной к монолитной структуре для мониторинга видеопотоков, который привел к снижению операционных затрат на 90% и улучшению производительности.

Что это все значит? Да то, что ближайшие 2-3 года большие IT коммпании начнут пересматривать регламенты и подходы к разработке. Очевидно, мы будем наблюдать частичный возврат к монолитам и модульным монолитам. Разработчикам придется учиться работать с большой кодовой базой и уметь писать код так, чтобы в любой момент его можно было вынести на другой физический инстанс. В общем, господа разработчики, начинайте готовиться заранее 😉

От себя скажу, что эта тенденция реальная и она уже назревает и в Российских IT компаниях. Так что жду в следующем году на конференциях доклады касательно данного вопроса.

AI В ПОВСЕДНЕВНОЙ РАБОТЕ РАЗРАБОТЧИКА

За последние 5 лет случился бум в области AI: появилось множество инструментов доступных широкой публике. Бытует мнение, что пройдет еще лет 5-7 и разработчики будут больше не нужны, ведь AI сможет все сделать сам. Я не согласен с этим мнением. Да, возможно, часть ниши сможет занять AI, где раньше нужно было нанять фрилансера или небольшую команду разработки для создания простенького сайта, приложения. Однако сложные системы полностью с нуля AI вряд ли сможет создать без какой либо корректировки со стороны экспертов в области разработки ПО.

Зато уже сейчас можно использовать все «блага цивилизации» (AI) и применять их в своей работе. Так, например AI-инструменты на подобие нашумевшего Github Copilot, можно встроить в IDE. Такие инструменты сильно ускоряют процесс разработки и сводят количество человеческих ошибок к минимуму. Если вас беспокоит вопрос безопасности вашей кодовой базы, то есть self hosted аналоги, например — tabby.

Также ChatGPT может стать реально вашим помощником, если научиться правильно пользоваться им (писать промты). Приведу плохой и хороший пример использования ChatGPT.

Задача: вам нужно интегрироваться с какой-то внешней системой (пусть это будет рассылка sms сообщений). У системы есть сайт с подробной документацией API. Правда, она текстовая, не в формате openapi, готовых SDK или клиентов на вашем языке нет…

Плохой пример: вы скармливаете ChatGPT ссылку на эту документацию и просите его, допустим, создать Go клиента к этой системе. С 99% вероятность ChatGPT вам выдаст, полурабочий код, который подойдет в качестве pet проекта для теста интеграции с системой, но никак не для enterprise разработки (банально эту будет тяжело поддерживать и вряд ли пройдет ревью от коллег). Поэтому дальше вам самим придется многое переписать, чтобы довести это до ума (или долго и упорно просить это сделать ChatGPT). Такой подход в лоб будет малоэффективным и ленивый разработчик быстро поплатится за то это🙂

Хороший пример:
Скоре всего, вы все же опытный и многоуважаемый разработчик. Ваш багаж знаний и опыт огромен, и, пожалуй, этим надо воспользоваться. Как бы вы интегрировались с системой по рассылке sms, не будь у вас ChatGPT? 🤔 «Если бы была openapi спецификация API, то я бы взял свой любимый инструмент кодогенерации, например oapi-codogen, сгенерировал клиента и готово! Имею поддерживаемый клиент с удобным API в коде»
Да, но у нас нет openapi спецификации… Тут на помощь и придет наш слуга — ChatGPT, который отлично подходит для рутинных задач. Заходим на страницу документации API. Сохраняем html страницы. Загружаем файл в ChatGPT и просим его перевести документацию в формат OpenAPI v3.0. Обязательно уточняем все наши пожелания (что обязательно должно попасть в спеку): какие методы, писать ли все коды ошибок, описание методов и моделей , приводить примеры и т.д. ChatGPT, как и разработчики, ленивый поэтому тут действует правило «Какое ТЗ, такой и результат». После этого у вас на руках готовая спецификация, и, если вдруг вы не работали с инструментами кодогенерации, можете также спросить у ChatGPT какие есть, и как с помощью них сгенерировать клиента. В нашем случае будет достаточно сделать //go:generate go run github.com/oapi-codegen/oapi-codegen/v2/cmd/oapi-codegen --config=config.yaml ../../api.yaml. Готово! ✅

В будущем AI ассистенты станут неотъемлемой частью нашей жизни. Я уверен, что от разработчиков потом будут требовать навыки умения работы с AI ассистентами. Почему? Да потому, что это ускоряет разработку, а значит повышает его эффективность, значит бизнес получает быстрее результат, значит быстрее получит потенциальную прибыль 💰

Как я перешел из продуктовой команды в инфраструктуру: итоги за год

Почти ровно год назад я сменил траекторию карьеры: из продуктовой команды, где я руководил двумя проектами в логистике, я перешел в инфраструктурную, став лидом команды в департаменте DBaaS.
Сейчас самое время подвести первые итоги.

Продуктовая разработка: скорость, highload и бесконечные встречи

В продуктовой команде я занимался двумя совершенно разными проектами:
1️⃣Highload-проект — ключевая часть логистики Ozon с жесткими требованиями:
🔍350k+ RPS, постоянные стресс-тесты, оптимизации и «танцы с бубном»
🔍минимальный Response Time (10-50ms 99q),
🔍высокая стабильность (особое внимание к тестированию и релизам),
🔍отсутствие downtime. Этот проект постоянно горел, и каждый день был похож на марафон: срочные задачи, дедлайны, стабильность любой ценой.
2️⃣Данные и аналитика — здесь highload сменился глубоким анализом. Нужно было переварить огромный бэклог от бизнеса, объединить данные из множества сервисов и создать стратегическое и уникальное решение, которое могло работать автоматизированно.

Работа была насыщенной: постоянные встречи с бизнесом, интеграции с соседними командами, контроль сроков. На одном дыхании мы запускали проекты и закрывали эпики. Но однажды я понял: все проекты для меня превратились в «перекладывание JSON -чиков из одного сервиса в другой». Завершение задач больше не приносило удовольствия.

Зачем я ушел в инфраструктуру?

На фоне выгорания мне вспомнился опыт работы с highload: Kafka, Redis, Postgres, Kubernetes, Go. Мне захотелось использовать этот опыт в более глубокой технической среде. Я поговорил с руководством, и мне предложили перейти в инфраструктурную команду, где предстояло:
🔍собрать команду с нуля,
🔍погрузиться в новые технологии,
🔍построить процессы с чистого листа.
Это был шанс выйти из зоны комфорта!

Чему пришлось учиться?
Мой продуктовый опыт оказался полезен, но этого было недостаточно. Мне пришлось:
🔍углубляться в Kubernetes, сети, Ansible;
🔍разбираться с CI/CD, observability;
🔍чтение документации, эксперименты, изучение чужого кода стали ежедневной рутиной.

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

Ключевые различия между продуктом и инфраструктурой

1️⃣Отсутствие формальных ролей
В инфраструктуре нет системных аналитиков, проектных менеджеров, скрам-мастеров. Ты делаешь всё сам: от сбора требований до проектирования. Это требует универсальности, четкого подхода к задаче и дисциплины, но одновременно дает большую свободу.
2️⃣Характер задач
В продукте сложнее понять, что конкретно хочет бизнес (он сам иногда не знает), а реализовать это — проще. Это похоже на игру в «Дженгу», где каждый новый блок должен не разрушить систему.
В инфраструктуре всё наоборот: ты знаешь, что нужно сделать, но реализация почти всегда — неизведанный путь. Приходится учиться на ошибках и жить с MVP.
3️⃣Роль команды
Инфраструктурные проекты требуют сильной синергии команды. Никто не знает всё, поэтому слаженная работа определяет успех. Также важно собрать экспертов своей области. Тут не получится уже взять джуна/мидла и научить его всему.
4️⃣Изменение фокуса
Появился баланс между встречами и временем на код. Ушли бесконечные митинги, зато добавились глубокие технические исследования.

Сложности и выводы

1️⃣Оценка результатов
В продукте успех проекта измеряется деньгами и масштабом влияния на пользователей. В инфраструктуре оценить значимость работы можно только спустя время, что добавляет неопределенности.
2️⃣Недостаток компетенций
Чувство, что ты знаешь недостаточно, никогда не покидает. Но я понял, что это нормально. Инфраструктура требует времени на освоение.
3️⃣Новая роль лидера
Быть тимлидом в инфраструктуре — это значит учиться у своей команды. Люди в команде часто знают больше, чем ты, и это правильно. Главное — уметь организовать их работу.

Итоги года

Год прошел стремительно. Чувствую ли я себя в своей тарелке? Скорее нет. Но я вижу перспективы и планирую 2025 год посвятить углублению экспертизы.

⬆️Продолжение ⬆️

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

Этот переход стал для меня настоящим вызовом. Если вы задумываетесь о смене направления в IT, знайте: это возможно. Главное — быть готовым учиться, ошибаться и адаптироваться.

Как пройти интервью по системному дизайну?

Доброе утро всем и с прошедшей первой рабочей неделей этого года!

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

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

Вообще есть 18 фундаментальных тем и понятий, которые хорошо бы знать:

1️⃣DNS (Domain Name System)
Как работают доменные имена и их преобразование в IP-адреса? Основа основ, которую часто любят спрашивать на собеседовании.

2️⃣Балансировка нагрузки (Load Balancer)
Как распределять трафик между серверами для обеспечения отказоустойчивости? Какие существуют стратегии балансировки нагрузки и как они работают?

3️⃣API Gateway
Маршрутизация, аутентификация, управление доступом, и множество других задач, которые может выполнять API Gateway, нужно только знать их и применять:)

4️⃣CDN (Content Delivery Network)
Как ускорить доставку контента пользователям по всему миру или в России от Калининграда до Камчатки?

5️⃣Кэширование (Caching)
Уменьшение задержек и нагрузки на систему за счёт хранения часто используемых данных. Уровни кеширования, стратегии инвалидации кешей, алгоритмы вытеснения и т.д.

6️⃣Базы данных (SQL и NoSQL)
Понимание их различий и подходящих кейсов использования Большая, но очень важная тема. Как-то раз мне на архитектурной секции «сеньор» аргументировал выбор MySQL, только потому что в основном он работал с ним. Такой аргумент, естественно, не тянул на сеньерскую позицию.

7️⃣Шардинг (Sharding)
В продолжение к предыдущей теме. Разделение базы данных для повышения производительности. Важно понимать как те или иные БД могут шардироваться, какие гарантии дают. Какие есть еще механизмы разделения данных?

8️⃣Индексы (Indexes)
Оптимизация поиска данных в базе. Какие есть индексы и когда стоит их применять.

9️⃣Репликация (Replication)
Дублирование данных для повышения доступности и отказоустойчивости.

1️⃣0️⃣Прокси-серверы (Proxies)
Контроль трафика и безопасность запросов между клиентами и серверами. Отличие reverse от forward proxy.

1️⃣1️⃣CAP и PACELC теоремы
Баланс между консистентностью, доступностью и устойчивостью к разделению сети, а также компромисы между задержками и консистентностью в распределённых системах.

1️⃣2️⃣. Микросервисы
Еще одна большая тема. Тут важны и паттерны организации, и выбор протоколов общения и схемы взаимодействия. Тут же и брокеры сообщений, мониторинг. В общем можно тут бесконечно углубляться.

1️⃣3️⃣. Consistent Hashing
Эффективное распределение данных между серверами.

1️⃣4️⃣. Long-Polling, WebSockets и Server-Sent Events
Технологии для связи в реальном времени.

1️⃣5️⃣. Bloom Filters
Структуры данных для проверки принадлежности элемента множеству.

1️⃣6️⃣. Кворум (Quorum)
Механизм обеспечения консистентности данных в распределённых системах.

1️⃣7️⃣. Лидер и ведомый (Leader and Follower)
Организация узлов для управления данными.

1️⃣8️⃣. Контрольная сумма (Checksum)
Метод проверки целостности данных.

Какие есть материалы для изучения ?:
- System Design Interview (Alex Xu).
Designing Data-Intensive Applications (Martin Kleppmann).
- Краткий обзор тем, которые я упомянул
- Практикуйтесь с задачами на проектирование. Разбирайте популярные кейсы, например, проектирование YouTube, WhatsApp или Facebook.

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