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

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

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.

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

5 стадий жизни IT-компании: от стартапа до кровавого Энтерпрайза. ЧАСТЬ 2️⃣

3. Medium Tech
Это компании среднего размера, которые уже прошли начальные этапы становления и очень активно масштабируются.

Характерные черты:

- управленческая иерархия: появляются полноценные отделы, направления, а внутри команд формируются четкие роли (Team Lead, Product Owner, QA и т.д.). Численность сотрудников IT может достигать примерно 100-400 человек.

- Часть работы может быть всё ещё на аутсорсе: но ключевые вещи стараются держать внутри. И идут к тому чтобы стать полностью самодостаточными.

- Инфраструктурная команда: появляется отдельная команда, ответственная за DevOps, SRE, инфраструктуру и поддержание серверов. Также может быть команда платформы, которая разрабатывает общие инструменты, фреймворки для остальных разработчиков.

- Гибкие процессы: используются Agile-подходы (Scrum, Kanban), есть планирование и ретроспективы. В общем все самое модное и молодежное в гибких процессах. В таких компаниях все еще чувствуется дух «стартапа» (по крайней мере они так его преподносят). Но это уже совсем не стартап, хотя пока еще нет бюрократии, жестких ограничений ИБ (исключение: если это не финтех). Стабильность приносится пока еще в жертву в угоду фичам.

- Собственные наработки: начинают появляться внутренние библиотеки, фреймворки, утилиты, shared-код, которые ускоряют разработку продукта и фич.

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

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

Плюсы:

- Стабильность: компания уже завоевала себе место на рынке и имеет жизнеспособную модель бизнеса. Переживать о том что завтра компанию могут закрыть не приходится (хотя в России всякое бывает).

- Карьерные возможности: такие компании идеально подходят для Middle м Senior специалистов, которые хотят в короткий срок дорасти до Lead позиции. Расти вместе с компанией всегда проще и быстрее, к тому же еще и интереснее.

- Процессы на столько гибкие, что очень просто взаимодействовать с другими командами и руководителями. В целом все прозрачно в компании до определенного момента.

Минусы:
- компания отстает в техническом плане от Big Tech-ов
- несовершенство процессов
- большой бэклог и очень высокий темп разработки
- на тех. долг отводится мало времени

На мой взгляд компании на данном этапе это лучшая возможность для продолжения своего карьерного роста (при условии, что бизнес будет активно расти, иначе продвижение по карьерной лестнице не принесет существенного увеличения заработка, а лишь добавит обязанностей).

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

5 стадий жизни IT-компании: от стартапа до кровавого Энтерпрайза. ЧАСТЬ 3️⃣

5. Кровавый Enterprise

Компании, которые существуют десятилетиями и чаще всего работают в классических отраслях (банки, страхование, телеком).

Характерные черты:

- Бюрократия: сложные согласования, жёсткие процессы, которые редко меняются. Здесь можно получать месяц доступы при трудоустройстве, и еще месяц знакомиться с многообразием процессов и порядков.

- Много Legacy: поддержка старых систем становится основной задачей. Тонны кода, которые придется изучать еще очень долго.

- Автоматизация процессов: всё, что можно автоматизировать, уже автоматизировано (но далеко не всегда оптимально и удобно)

- Устаревшие технологии:
Поскольку компания уже давно на рынке большинство используемых технологий и инструментов уже устарели.

- Тяжелые релизы: всё тестируется по полгода, а потом раскатывается с кучей ограничений.

- Маленький рост: карьерные возможности ограничены, а влияние на продукт минимальны. Никто не заинтересован тут в вашем росте и развитии.

- Удобство разработчика не в приоритете: главное — соблюдение процессов и бизнес-задач.

Плюсы для разработчиков:
- стабильная зарплата (возможно даже выше рынка)
- минимальные риски увольнения (тут можно затеряться среди остальных и делать свою работу тихонько создавая видимость деятельности, если конечно ваш руководитель соответствует духу этой компании и ему также всеравно)

Минусы:
- рутина (я бы сказал болото, интересных задач здесь нет)
- отсутствие новых технологий (даже не пытайтесь вводить здесь что-то новое, все упрется в бесконечное согласование)
- сложные процессы

Как сказал когда-то один из моих руководителей, такие компании отлично подходят для того чтобы встретить «пенсию», но не для активного карьерного роста.

Какой этап подходит вам?

Разработчики выбирают компании, исходя из своих целей. Стартапы — для тех, кто хочет попробовать всё и сразу. Mini и Medium Tech — для тех, кто ценит баланс между интересными задачами и стабильностью. Big Tech — для экспертов, готовых к вызовам. Интерпрайз — для тех, кто ищет стабильность и размеренность.

Какие этапы вы прошли или хотите попробовать? Пишите свои мысли в комментариях!

ИЩУ GO РАЗРАБОТЧИКА В КОМАНДУ🚀

Всем доброе утро, мои глубокоуважаемые подписчики!

Открылась вакансия в мою команду. Нужен скиловый Go разработчик, который «и коня на скаку остановит, и в горящую избу войдет».

Кратко чем предстоит заниматься:
- разрабатывать и развивать платформу в облаке Ozon, позволяющую администрировать кластера Cassandra/ScyllaDB;
- улучшать существующие opensource инструменты в экосистеме Scylla/Cassandra и разрабатывать собственные.

Чего жду от кандидата:
- уверенно знает Go;
- умеет работать с большой кодовой базой и писать чистый код;
- умеет проектировать качественное REST и RPC API;
- работал или знаком с kubernetes;
- будет еще большим плюсом, если и в Ansible, и Python силен.

Подробнее о вакансии 👉 тут

Там же можете оставить свой отклик👌

P.S. удаленка возможна, сам сейчас пишу этот пост, находясь в Малайзии 🇲🇾

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

Теперь о болях:

1. Найти человека, который идеально впишется в команду, имеет крутые хард скиллы, а ещё и мотивирован перформить — задача не из лёгких. Приходится собеседовать много кандидатов, и иногда (когда луна в козероге или другие астрономические явления) повезёт, и второй или третий кандидат окажется именно тем, кто нужен команде. А может и не повезти. И вот тут важно не поддаваться соблазну:

«ну давай хотя бы этого возьмём, может, он раскроется».

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

2. Дефицит квалифицированных кадров на рынке — настоящая боль, особенно на российском рынке труда. Множество классных специалистов уехали за границу или уже нашли своё место мечты с такой зарплатой, что ни один оффер их не заинтересует. Недостаток хороших кадров приводит к снижению стандартов отбора, а на фоне этого в вакансиях часто создаются «тепличные условия» (рынок соискателя). Это не плохо, но отсутствие конкуренции среди кандидатов часто приводит к тому, что они перестают расти, развиваться и даже не стараются готовиться к собеседованиям.

Очень грустно тратить полтора часа на общение с кандидатом, который не только не заинтересован в работе, но и не подготовился к собеседованию, и при этом считает, что это нормально: «я специально не читал эту тему». А были ещё такие, которые ответы с ChatGPT читали... Такие провальные собесы останутся в архивах компании, и в следующий раз отношение к кандидату будет совсем другим.

Итак, TL;DR:
➡️ Всегда готовьтесь к собеседованию и показывайте свою заинтересованность. Даже если вы чего-то не знаете, но можете это грамотно преподнести и показать другие свои сильные стороны, это будет большим плюсом.
➡️ Невозможно расти, просто выполняя рабочие задачи. Зачастую в рамках рабочих задач нет времени на эксперименты с новыми технологиями и паттернами. Нужно делать то, что хорошо умеешь, но также важно параллельно учить новое, пробовать это в личных проектах и потом внедрять в работу.
➡️ Лучше перенести встречу, чем проводить её с телефона на прогулке в парке, при плохом интернете или в условиях ремонта/переезда. Нет ничего хуже, чем постоянно останавливаться и переспрашивать из-за плохой связи, нет.
➡️ Постоянно обучайтесь и развивайтесь как специалисты. Время сейчас меняется так быстро, что важно всегда быть на шаг впереди.

Желаю всем хорошей рабочей недели!