Как стать продуктивнее в IT, если вы уже прокачали свои харды (Рубрика #Management)

Сегодня я выступлю на конференции soft weekend, первой софтовой офлайн-конференция в России (что бы это ни значило). Я не могу сказать, что люблю рассказывать чисто про софты, но эту конференцию организует мой знакомый, Андрей Смирнов, автор подкаста "Frontend Weekend", куда я ходил в гости в прошлом году. В итоге, я решил рассказать что-то из серии набора качеств и навыков, что важны для всех: и для крутых инженеров и для хороших менеджеров.

Доклад будет состоять из 4х частей, которые описаны ниже, причем фокус будет на третьем пункте, а точнее навыках и умениях помимо hard skills, что помогали лично мне расти на протяжении всей карьеры

1) Зачем нам нужны soft skills
- В современном мире процессы разработки становятся все сложнее, зона ответственности IC (individual contributor) все увеличивается и включает system design, operation, data, security, ... (подробнее в моем рассказе о современном SDE и SDLC)
- Для борьбы с этой сложностью обычно применяют разные абстракции, например, для инфры это IaaS -> PaaS -> SaaS -> ...(подробнее в моем рассказе об облачных технологиях для Финтех Школы)
- Мы все живем в комплексном и хаотичном мире (complex и chaotic из фреймворка Cynefin)

2) Как расти в таких условиях
- Для инженеров есть две стандартные дороги: индивидуального контрибьютора или менеджера. В обоих, с какого-то уровня надо уметь проявлять лидерство. Условно, до middle+ IC можно дорасти только на хардах, а вот дальше ...(подробнее здесь)
- Например, в T есть матрица для инженера вида: scope, impact, complexity, leadership, improvement. По этой матрице оцениваются достижения инженеров в Т-рост (подробнее в отдельном посте)
- Т-рост - это процесс, по которому проходят повышения в Т. Инициатором является сам сотрудник, который готовит заявку на повышение с учетом своих достижений, упирая на то, что он закрыл оси вышеуказанной матрицы, а также прикладывает артефакты, которые это доказывает

3) Какие навыки и умения помогут проявлять лидерство и расти в таких условиях
- Умение планировать свое время (а дальше если повезет и своей команды)
- Умение и желание брать на себя ответственность (и главное доводить сложные дела до конца)
- Навыки общения с коллегами и договороспособность (эта часть часто западает)
- Навыки самомотивации и мотивации окружающих (правда, если разбираться в вопросе, то внешняя мотивация - это скорее стимуляция)
- Важность любопытства и желание копать глубже, чтобы действительно разобраться как что-то работает (или скорее что не работает)

4) Важность hard skills как базы для дальнейшего роста (пи... не мешки ворочать)
Если вы раскачаете софт скиллы с отсутствующей базой в виде hard skills, то это будет шатким фундаментом, который может рухнуть в произвольный момент. А в некоторые компании без них в принципе не попасть - например, у нас для инженеров есть интервью по программированию, языку разработки и system design. Такой набор эффективно отсеивает мастеров разговорного жанра.

P.S.
Запись выступления будет и потом я поделюсь ей в этом канале.

#Leadership #Processes #Management

What Goes Around Comes Around... And Around... Part I (Рубрика #Data)

Интересная обзорная статья 2024 года от Michael Stonebraker и Andrew Pavlo про развитие баз данных за последние 20 лет. Оба автора являются корефееями в области баз данных: Michael создал Postgres и еще кучу других баз, а Andrew - исследователь в области баз данных, профессор и преподаватель, лекции которого доступны на Youtube.

Сама статья продолжает статью 2005 года "What Goes Around Comes Around", которую написали Michael Stonebraker и Joseph M. Hellerstein. Они проанализировали историю развития баз данных за 35 лет и предсказали что модные тогда объектные и xml базы данных не смогут обойти по реляционную модель.

С тех пор прошло порядка 20 лет и пришло время сделать новый обзор мира баз данных. Для этого авторы решили посмотреть на это с двух сторон:
- Модели данных и языки запросов
- Архитектура баз данных

Начнем с разбора существующих data models и query languages:

1. MapReduce-системы
Изначально они были разработаны в Google для обработки больших объемов данных (веб-краулер). MapReduce не использует фиксированную модель данных или язык запросов, они выполняют пользовательские операции map и reduce. Открытой версией MapReduce стал Hadoop, который сейчас не очень популярен из-за низкой производительности и заменяется более современными платформами аля Apache Spark или просто СУБД.

2. Key-Value хранилища
У них максимально простая модель данных: пары "ключ-значение". Они используются для задач кэширования (Memcached, Redis) или хранения сессий. Возможности в модели ограничены - нет индексов или операций join, что усложняет применение для сложных приложений. Многие KV-хранилища (например, DynamoDB, Aerospike) эволюционировали в более функциональные системы с поддержкой частичной структуры (JSON). Среди популярных встроенных k/v решений популярны LevelDB и RocksDB.

3. Документные базы данных
Они хранят данные в виде документов (например, в формате JSON). Изначально получили популярность благодаря простоте интеграции с веб-приложениями (например, MongoDB), предлагая подход schema on read. Интресно, что к 2020-м годам большинство документных СУБД добавили SQL-подобные интерфейсы и поддержку ACID-транзакций, а иногда и schema on write.

4. Column-Family базы данных (wide columns)
По-факту, это упрощенная версия документной модели с ограниченной вложенностью. Начиналось все с Google BigTable, а в миру есть open source реализация в виде Apache Cassandra. Изначально в Cassandra не было вторичных индексов и транзакций. Но по мере развития они появились (но там все очень интересно)

5. Поисковые движки
Они нужны для полнотекстового поиска (Elasticsearch, Apache Solr). Поддерживают индексацию текста, но ограничены в транзакционных возможностях. Реляционные СУБД также предлагают встроенный полнотекстовый поиск, но с менее удобным API.

6. Базы данных для массивов
Они предназначены для работы с многомерными массивами, например, научные данные (SciDB, Rasdaman). Ниша ограничена специфическими областями применения: геоданные, изучение генома.

7. Векторные базы данных
Используются для хранения эмбеддингов из машинного обучения (Pinecone, Milvus). Основное применение — поиск ближайших соседей в высокоразмерных пространствах. Реляционные СУБД уже начали добавлять поддержку векторных индексов.

8. Графовые базы данных
Моделируют данные как графы (узлы и связи). Примеры: Neo4j для OLTP-графов, TigerGraph для аналитики. Большинство графовых задач можно реализовать на реляционных СУБД с помощью SQL/PGQ (новый стандарт SQL:2023).

Общие выводы
- Большинство нереляционных систем либо занимают нишевые рынки, либо постепенно сближаются с реляционными СУБД.
- SQL остается основным языком запросов благодаря своей гибкости и поддержке современных приложений.
- Реляционные СУБД продолжают развиваться и интегрировать новые возможности (например, JSON, векторные индексы), что делает специализированные системы менее конкурентоспособными.

В продолжении поста будет про архитектуру баз данных.

#Data #Architecture #Software #DistributedSystems

What Goes Around Comes Around... And Around... Part II (Рубрика #Data)

В продолжение рассказа про эту статью 2024 стоит поговорить про разные подходы к системной архитектуре, которые развивались в последние два десятилетия. Эти архитектуры отражают изменения в software (менялись типы приложений и их требования), а также изменения в hardware, а точнее изменения в параметрах аппаратного обеспечения (мощность CPU, скорость оперативной памяти, разные типы дисков, скорость сети и так далее).

1. Колоночные системы (columnar systems)
Эти системы стали стандартом де-факто в мире аналитических баз данных. Суть в том, что там запросы часто обращаются только к небольшому числу атрибутов таблиц. Колоночное хранение данных позволяет читать только нужные данные, а также лучше сжимать их благодаря однородности значений. Кроме того, можно добиться ускорения выполнения запросов за счет векторизованной обработки данных. Примерами таких баз данных являются Vertica, Amazon Redshift, Google BigQuery, Clickhouse, DuckDB.

2. Облачные базы данных (cloud databases)
Эти базы данных предоставляются в облаках, в которые было модно перевозить свою инфраструктуру. Такие базы обеспечивали масштабируемость и эластичность, что позволяло клиентам динамически изменять ресурсы. Восход этих баз данных связан с тем, что за последние 20 лет скорость сети увеличивалась гораздо быстрее, чем скорость диска, поэтому использование NAS (network attached storage) стало привлекательной альтернативой для стандартного устройства хранения. Собственно, основные вендоры в качества NAS используют объектные хранилища (например, AWS S3). Такая архитектура приводит к тому, что у нас разделяется compute и storage и мы имеем такие преимущества
- Можно обеспечить эластичность на уровне отдельных запросов
- Вычислительные ноды можно отправить на другие задачи, если DBMS не полностью утилизируется
- Можно переместить вычисления прямо на ноды хранения данных - подход называется "pushing the query to the data" и он показывает себя лучше, чем стандартный "pulling the data to the query".
Интересно, что два первых подхода называются serverless computing и в мир DBMS их принесла Snowflake. А среди популярных облачных баз данных есть
- Google Spanner - рекомендую интересный whitepaper
- Amazon Aurora - рекомендую интересный whitepaper, который мы даже как-то разбирали в выпуске подкаста "Code of Leadership", а также рекомендую глянуть рассказ с AWS Re:Invent 2023 о том, как они завезли туда шардирование

3. Озера данных (Data Lakes) и Lakehouses
Облачные платформы разожгли интерес к тому, чтобы отказаться от монолитов в аналитике и перейти к data lakes, где данные как есть загружались в объектные хранилища (S3 like). То есть тут был отход от стандартных ранее ETL (extract-transform-load) к ELT (extract-load-transform). После загрузки, прямо поверх данных выполнялись вычисления при помощи движков lakehouse, минуя стандартные DBMS (типа Greenplum). Собственно lakehouse - это комбинация из data warehouse и data lake:) Данные в data lake хранятся в бинарном виде: Parquet, ORC (optimized row columnar), а для обмена данных in-memory можно использовать формат Apache Arrow. В каждом облаке есть managed data lake сервисы, а также есть отдельные варианты в виде Databricks, Dremio, PrestoDB, Trino.

4. NewSQL-системы
В 2010х годах появился этот класс систем, чтобы совместить ACID транзакции из RDBMS и масштабируемость NoSQL решений. Одним из первых представителей стал уже упоминавшийся Google Spanner. По-факту, тут было 2 типа систем in-memory и стандартные disk-oriented. Часть стартапов ставили на больший спрос на in-memory подходы, но ставка не сыграла. На смену этим подходам пришли распределенные и транзакционные SQL RDBMS навроде TiDB, CockroachDB и думаю, что можно туда добавить YDB с их Calvin-транзакциями. Эти системы подходят для приложений, требующих как высокой производительности, так и строгой консистентности данных.

В продолжении окончание разбора статьи.

#Architecture #Software #DistributedSystems

What Goes Around Comes Around... And Around... Part III (Рубрика #Data)

В продолжение рассказа (1 и 2) про эту статью 2024 стоит закончить про разные подходы к системной архитектуре, а дальше рассказать про прощальные комментарии авторов, что повторяют частично предостережения из 2005 годов, когда вышла первая статья "What Goes Around Comes Around"

Архитектуры
5. Аппаратные ускорители
Этот подход предполагает использование специализированного оборудования (например, GPU или FPGA) для ускорения выполнения запросов. Подход выглядит работоспособным только для cloud вендоров из-за стоимости разработки кастомного железа и написания кастомного софта. Кроме того, обычно это не дает кратного роста эффективности.
6. Базы данных на основе блокчейна
Блокчейн обещал гарантии неизменяемости данных и прозрачности транзакций. Но такие системы остаются нишевыми из-за ограничений производительности и сложности интеграции с традиционными приложениями.

Выводы относительно архитектур баз данных
Авторы статьи отмечают, что многие из этих архитектур либо заняли нишевые рынки, либо постепенно интегрируются в реляционные СУБД
- Колоночные системы теперь являются стандартом для аналитики.
- Облачные базы данных доминируют благодаря удобству управления.
- NewSQL-системы становятся мостом между традиционными реляционными базами и масштабируемыми NoSQL-подходами.
- Эти изменения демонстрируют адаптацию СУБД к современным требованиям приложений и аппаратным инновациям.

Прощальные комментарии
- Никогда не недооценивайте значение хорошего маркетинга для плохих продуктов: как было с Oracle в 1980х, MySQL в 2000х, MongoDB в 2010х:) Последние 2 примера я видел своими глазами
- Опасайтесь DBMSs от крупных вендоров не из рынка DBMS. Крупные технологические компании часто пишут свои базы данных in-house, а дальше отпускают их на волю (в мир open source). У некоторых bigtech компаний так получаются крутые продукты: Apache Hive, Presto, Apache Cassandra, RocksDB или Apache Kafka, Apache Pinot, Voldemort, а у других нет. Авторы делают предположение, что система промоушенов внутри таких компаний приветствует создание новых технологий внутри, а не использование готовых инструментов. Так на свет появляется куча уродцев от команд, которые не имеют опыта в создании баз данных
- Не игнорируйте первое впечатление пользователя при с вашей базой (out-of-box experience). Важно, чтобы продуктом было удобно пользоваться новичкам (иначе они пойдут крутить данные с помощью Python notebooks)
- Разработчикам все еще надо иногда делать запросы к базам данных напрямую, несмотря на старания создателей ORM:)
- Влияние AI/ML на базы данных будет значительным. Скорее всего запросы на естественном языке не заменят SQL для OLTP типов запросов, но вот для OLAP - это может быть делом ближайшего будущего. Внутри корпораций для принятия решений используются данные, но LLMs не так просто будет помочь с этим. Есть проблема с тем, чтобы объяснить их результаты людям, а также с количеством данных, которые требуются для обучения. А эти данные так просто не отправишь для генерации в крауд системы. Отдельно авторы отмечают направление исследований об оптимизации работы самих DBMSs при помощи ML/AI. И даже если в этом результаты будут получены, то они не избавят от потребности в выскокачественной системной инженерии.

В заключении авторы грозятся через 20 лет написать статью продолжение

We caution developers to learn from history. In other words, stand on the shoulders of those who came before and not on their toes. One of us will likely still be alive and out on bail in two decades, and thus fully expects to write a follow-up to this paper in 2044.

#Architecture #Software #DistributedSystems

Архитектура в Т-Банке: вчера, сегодня, завтра — выступление на ArchDays 2024 (Рубрика #Architecture)

В этой статье я рассказываю про наши подходы к проектированию и построению архитектуры систем. Я в "Т" уже 8 лет и видел как эти процессы эволюционировали во времени, а также знаю к чему мы пришли. Я выделил следующие четыре стадии и объяснил как и почему они сменяли друг друга во времени
1. COTS (commercial of the shelf)
2. Свой собственный софт
3. Platform Engineering
4. Большие мегапроекты и governance

Напоследок я рассказал про подходы корпораций и технологических компаний к должностям/ролям архитекторов, а также поделился своим видением того, как нам дальше стоит развиваться. Эта статья является расшифровкой моего доклада на ежегодной конференции "ArchDays 2024", которая прошла в этом году уже в шестой раз.

#Architecture #Software #Evolution #Management

Database Internals Meetup #5 (офлайн + онлайн): 5 докладов на конференции ISPRAS Open

Последние пару дней у меня в канале посвящены базам данных, поэтому позволю себе порекомендовать посетить пятый митап российского сообщества разработчиков СУБД и распределенных систем, на котором будут доклады от основателей и ведущих разработчиков YDB, Picodata, Tarantool, openGauss и CedrusData. Мероприятие пройдет 11 декабря офлайн и оно будет частью конференции ISPRAS Open в Москве. Регистрация бесплатна и доступна здесь.

Программа митапа будет плотной и насыщенной:
- 13:00 - 14:00 - Эволюция архитектуры СУБД на примере YDB, Андрей Фомичев, Яндекс, основатель и руководитель YDB
- 14:00 - 15:00 - Blue/green deploy для хранимых процедур в кластерной СУБД на примере Picodata, Константин Осипов, Picodata, основатель Picodata
- 15:00 - 16:00 - Оптимизация подсказками: ускоряем запросы, не изменяя планировщик. Сергей Зинченко, OpenGauss, Инженер
- 16:30 - 17:30 - Columnar In-Memory в Tarantool: зачем нужно строить еще одну колоночную СУБД, да еще и в памяти? Николай Карлов, VK, Head of Innovations, tarantool.io
- 17:30 - 18:30 - Переписывание запросов на основе материализованных представлений в аналитической системе CedrusData. Владимир Озеров, Александр Блажков, генеральный директор и разработчик CedrusData

#Database #Architecture #Management #DistributedSystems #Software #Engineering

Code of Leadership #23 - Interview with Andrew Marchenko (Рубрика #Architecture)

В этом эпизоде ко мне пришел крутой гость, Андрей Марченко, мой бывший коллега, который сделал много хорошего для веба Tinkoff.ru. Андрей является software engineer высокого грейда с большим опытом разработки платформенных решений для внутренних разработчиков. Много лет он работал над тем, чтобы сделать разработчикам жизнь проще, а продукты качественнее на разных позиций от разработчика, до руководителя 16+ инженеров. В последнее время он перешел в продуктовую разработку в одной из FAANG компании на позиции инженера. Сейчас он с интересом изучает как все устроено внутри, находит отличия от Российского IT, а также ищет путь для быстрого роста и повышений внутри компании.

Мы поговорили про следующие темы
- Начало карьеры Андрея в общем
- Как Андрей оказался в Тинькофф
- Как выглядел рост Андрея в Т
- Важность взаимодействия с людьми
- Переход в платформенную команду
- Про Statist и продуктовую аналитику
- Инфраструктурные проекты Андрея
- Коммуникации и убеждение
- Высокоуровневые инженеры
- Опыт работы в Тинькофф и переезд зарубеж
- Работа в Booking и изучение баз данных
- Ведение блога и улучшение английского
- Переход в FAANG компанию и текущие проекты
- Проблемы роста в американской компании
- Планы на будущее и как пришел к желанию переехать
- Потеря влияния в новой компании (карма и доверие)
- Решение сложных задач как залог роста
- Изучение дизайна крупных и высоконагруженных систем FAANG компаний изнутри
- Личный опыт и советы Андрея о том, как стать таким же крутым
- Проблемы Андрея с учебой из-за дислексии и их преодоление
- Важность работы и упорства

Дополнительные ссылки
- Блог Андрея со статьями, которые он иногда пишет на тему инфрастуктуры/архитектуры
- Телеграм канал Андрея
- Выступление Андрея про tramvai - "Tramvai, модульный фреймворк для React-приложений от Tinkoff"
- Выступление Андрея "Пять лет эволюции React-приложения"

#Architecure #Software #SystemDesign #Management #Staff #Engineering #PlatformEngineering

Assessing IT Project Success: Perception vs. Reality (Рубрика #Management)

Эта статья была опубликована в сентябре в ACM Queue и она посвящена рассмотрению изменяющегося понимания успеха IT проектов. Раньше эту тему активно педалировали ребята из Standish Group, еще в 1994 году рассказывая в "The CHAOS Report" о том, что большая часть IT проектов проваливается. Они рассматривали успех с точки зрения не просто проекта, а проектного управления, а точнее попадания в проектный треугольник: сроки, бюджет и scope.

The project is completed on time and on budget, with all features and functions as initially specified.

Но авторы нового исследования задумались о том, а какие еще есть объективные показатели помимо этих метрик, по которым можно оценить успешность проекта. Они выбрали следующие дополнительные метрики
- Level of global success achieved
Level of compliance with the scope, time, and cost
- Level of vendor (supplier) satisfaction
- Level of client satisfaction
- Deliverables impact
- Achievement of benefits verified in the project.

Для проведения исследования использовались опросы с участием опытных менеджеров IT-проектов из различных отраслей и регионов. Респондентов попросили оценить один недавно завершенный проект с помощью детализированной анкеты, включающей как субъективные оценки, так и объективные критерии. Ответы предполагалось давать по шкале Лайкерта, а всего было заполнено порядка 200 опросов. Надо было выбрать проект, который закончился больше полугода назад - это позволяло ответить на дополнительные вопросы про
- Использование клиентом результатов проекта на постпроектной стадии.
- Найм клиентом специалистов для поддержки или обслуживания проекта.
- Заключение клиентом новых контрактов с тем же подрядчиком.
- Рекомендации клиента данного подрядчика другим.

Основными выводами исследования стало то, что вопреки распространенному мнению о частых неудачах IT-проектов (например, согласно отчетам Chaos Reports группы Standish) большинство IT-проектов достигают высокого уровня успеха. В частности, 90,16% опрошенных проектов получили оценки выше среднего уровня по глобальной шкале успеха, а 61,66% достигли двух верхних уровней. По расширенным критериям, описанным выше результаты проектов тоже показывают высокую долю успеха. Интересно, что обнаружена положительная корреляция между глобальным успехом проекта и такими факторами, как удовлетворенность клиента (ρ = 0.714), выгоды для клиента (ρ = 0.751) и удовлетворенность подрядчика (ρ = 0.653). Это подчеркивает важность ориентированности на результаты для клиента как ключевого индикатора успеха.

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

Итого, в этом исследовании дан более комплексный взгляд на успех IT-проектов, по сравнению с демагогией от Standish Group. И это исследование показывает, что многие IT-проекты достигают значительных успехов при всесторонней оценке, бросая вызов устаревшим представлениям о повсеместных неудачах в этой области. Исследование подчеркивает необходимость развития рамок оценки для учета многогранности современных IT-проектов:)

#Management #Processes #Leadership #Project #Product

Иллюстрация результатов опроса для исследования про успешность IT проектов. В этой диаграмме 7 считается полным успехом, 5 и 6 - это выше mid-level, а ниже 5 считается неудачей.

Observability in an Asynchronous World • James Eastham • GOTO 2024 - Part I (Рубрика #Architecture)

Интересное выступление от James Eastham, Serverless Developer Advocate из Datadog, на тему событийно-ориентированной архитектуры и тому, как в ней обеспечивать observability. В самом докладе нет ничего про Datadog, но есть сквозной пример пиццерии, архитектуру которой автор делает в EDA стиле и показывает как обеспечить ей наблюдаемость. Тезисы примерно такие

1) В распределенных системах сложно понять, что пошло не так при какой-то проблеме
2) В случае синхронный взаимодействий - это +/- понятно как делать, но в асинхронном мире наблюдаемость еще больше усложняется
3) В какой-то момент по мере роста масштаба систем мы пришли к большому количеству отдельных сервисов
4) При их построении принято стремиться к low coupling и high cohesion, условно связи между сервисами нужно делать несильными, а вот внутри сервиса логика должна быть сильно завязана друг на друга
5) Одним из вариантов решения проблемы связей между сервисами был переход на event-driven architecture. Тут автор показывает свою архитектуру для пицерии, где есть order processing service, kitchen service, delivery service, которые взаимодействую посредством событий
6) Дальше автор разбирает что такое событие (это непреложный факт, который нельзя изменить). Важно, что автора интересуют именно бизнес-события, которые приводят систему в движение. На эту тему рекомендую изучить технику event storming, про которую я рассказывал раньше
7) События - это разновидность сообщения, но событие уже произошло в прошлом. Также есть сообщение типа "команда", которое предписывает что-то сдлеать в будущем.
😍 События бывают трех видов: нотификации, события с передачей состояния (event-carried state transfer) и доменные события (это из event sourcing). Рекомендую почитать мой разбор главы про EDA и event sourcing из книги "Learning DDD" Влада Хононова
9) Собственно взаимодействие сервисов осуществляется через publish/subscribe шаблон, производители публикуют события с определенной схемой, а потребители могут их использовать (или не использовать)
10) Такое взаимодействие позволяет сделать асинхронную систему, что позволяет отвязать производителей от потребителей событий. Ответственность за контроль и потребление событий на консьюмерах

Продолжение в следующем посте.

#SRE #Architecture #DistributedSystems #Software