Code of Architecture - Continuous Architecture in Practice - IV

Завтра в 18:00 мы закончим разобр книги "Continuous Architecture in Practice" и поговорим про три главы
- Resilience as architectural concerns - я достаточно подробно уже разбирал эту главу в своем посте пару месяцев назад
- Software architecture and emerging technologies - тут авторы говорят про AI и blockchain и их влияние на архитектуру софта
- Conclusion - здесь авторы подводят итоги книги, что сделаем и мы на своем стриме

Гостями выпуска станут два эксперта
- Евгений Пешков, техлид, независимый эксперт и консультант, увлеченный созданием продуктов, построением эффективных команд и внедрение практик технического совершенства в мире разработки и архитектуры ПО, основатель сообщества DDDevotion.
- Сергей Баранов, архитектор, основатель конференции ArchDays. Сергей ведет каналы по распределенным системам и Event Storming, пишет статьи в блоге agilemindset.ru.

#CoA #Software #Architect #SystemDesign #Philosophy #SoftwareArchitecture #Processes #Management

Дополнительные материалы для выступления на дне Тинькофф в МФТИ

Сегодня я еду в МФТИ, вспоминать студенческие времена (я на кампусе не был уже лет 5), а также рассказывать про современные подходы к разработке программного обеспечения на дне Тинькофф. По старой традиции в день выступления я публикую пост с дополнительными материалами в этом канале и в качестве последнего слайда презентации показываю QR-код. Это неплохо повышает конверсию в подписки и просмотр этих самых материалов:)

- Современные подходы к разработке программного обеспечения
- Совершенствование потока разработки программного обеспечения
- Проектируем надежные системы — стоит ли игра свеч
- Про управление проектами и продуктами
- Devops культура: мифы и реальность
- Как RnD появляется в крупных ИТ-компаниях
- The Pipeline-Driven Organization • Roy Osherove • GOTO 2022
- Курс Essential Architecture #Code
- Курс Essential Architecture #Data
- Code of Architecture — “Distributed Systems, 4th Ed” #2 (Architecture)
- Как подготовиться и пройти System Design Interview

P.S.
И сразу после выступления я поеду домой, чтобы успеть к началу нашего онлайн-стрима "Code of Architecture", про который я писал вчера.

#SoftwareDevelopment #Software #SoftwareArchitecture #Engineering #SystemThinking

По традиции при посещении МФТИ зашел в книжный магазин и не смог выйти без покупок - купил пачку книг Фейнмана
- Фейнмановские лекции по физике. Современная наука о природе (The Feynman Lectures on Physics. The New Millenium Edition (1-7))
- Радость познания (The pleasure of finding things out)
- Не все ли равно, что думают другие (What do You Care What Other People Think?)
- Дюжина лекций: шесть попроще и шесть посложнее (Six Easy Pieces. Six Not-So-Easy Pieces)

Но я покупал не только книги, но захватил и кружку с символикой МФТИ, что выпущена на 75-летие:)

P.S.
До этого я уже рассказывал про другие книги Фейнмана
- Вы, конечно, шутите, мистер Фейнман
- Характер физических законов
- КЭД - странная теория света и вещества
И они действительно были хороши, думаю, что и пополнение моей библиотеки меня не разочарует.

#PopularScience #Physics #Math #SelfDevelopment

Inside Envoy: The Proxy for the Future [OFFICIAL FILM]

Крутой документальный фильм про Envoy, который начинается с рассказа Matt Klein, создателя Envoy. Мэтт рассказывает про
- Свой опыт работы с TSA (Twitter Streaming Aggregator), который можно считать предшественником Enovy
- Дальше Мэтт немного нафакапил с настройкой обработки дат, а дальше миллионы людей оказались разлогинены
- Дальше Мэтт нашел искать новые возможности и ушел в Lift, куда до этого ушел его руководитель
- В Lift Мэтт занялся созданием нового прокси сервера, который из коробки давал observability и performance, сравнимый с Nginx
- Потом Envoy был выложен в open source и начался поиск adoption
Дальше рассказ переходит к сотрудникам Google, которые рассказывают как они планировали в это время делать service mesh, который потом стал Istio. И они выбрали Envoy в качестве data plane для этого нового service mesh. Интересно описывается как принималось решение о выборе в пользу Envoy по сравнению с Nginx, где одним из вопросов был, а что это за продукт, где было всего 6 пул реквестов в репозитории. Но плюсы Envoy перевесили и дальше Google засетапила 10 инженеров в отдельную команду, которая начала развивать Envoy и дальше использовать его внутри Google Cloud. И дальше проект пошел в бурный рост ...

P.S.
- Помню как лет 15 назад я работал сначала с Apache Http Server (apache httpd), где сервер на обработку запроса форкал процесс или использовал пул префоркнутых процессов
- Примерно в то же время я увидел Nginx и его модель работы показалась мне прорывной по сравнению с httpd - в Nginx были master и worker процессы, где worker processes могли обрабатывать много зпросов, используя state machine (подробнее тут)
- А теперь у нас есть Envoy, который гораздо лучше подходит к cloud native миру. Подробнее схему обработки запроса можно посмотреть здесь

#Linux #Kubernetes #Networking #DistributedSystems #SystemDesign #Software #Engineering #Architecture

Материалы к выступлению на YaTalks про то, как формировать структуру команд под запросы бизнеса

Сегодня в 12.00 я выступаю на YaTalks и традиционно выкладываю сюда материалы, которые я рекомендую для изучения после доклада
Сначала список инструментов, которые я считаю полезными в этом вопросе
- Про backcasting мы обсуждали в серии Code of Architecture про Technology Strategy Patterns
- Про working backwards написана целая книга
- Про управление проектами я рассуждал в статье про три П "Проект, продукт, процесс"
- Про закон Конвея можно почитать в wikipedia
- Обратный маневр Конвея в 2014 году попал в техрадар от ThoughtWorks
- Про team topologies можно почитать мои краткие саммари: Teams as means of Delivery, Team Topologies that work for flow, Evolving team interactions for innovation and rapid delivery
- Про управление изменениями классно написано в книге "Наш айсберг тает", про которую я уже писал

Дальше идут ссылки на материалы, в который я подробнее рассказывал про изменения, о которых упоминаю в докладе на YaTalks
- Доклад на Teamlead Conf 2018 про масштабирование фронтовых команд Tinkoff.ru с управленческой точки зрения
- Доклад на ArchDays 2019 про эволюцию всей связки фронт - бек - система a/b тестов, где фокус больше на архитектурных изменениях
- Доклад на Techlead Conf 2021 про платформизацию мобильного банка Тинькофф с целью создать автономные мобильные команды для каждой бизнес-линии (есть текстовая версия в моем блоге)
- Доклад на Highload++ 2022 про создание stream-aligned команд на базе отдельных мобильных и api команд, которые уже больше похоже на кросс-функциональные, передачу их под руководство CTO бизнес-вертикали и некий technical governance от платформы мобильного банка (и текстовая версия в моем блоге)
- Книга "Learning DDD", в которой хорошо изложены стратегические концепции DDD и которую я активно использовал при проектировании новой оргсхемы своего юнита почти на тысячу человек

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

#Management #Leadership #Project #ProjectManagement #SoftwareDevelopment #Software

В этот понедельник мы провели четвертый стрим клуба Code of Architecture по книге "Continuous Architecture in Practice". Он был посвящен в большой степени resilience, но кроме этого мы упомянули про emerging technologies и сделали выводы целиком по книге. Собственно вся дискуссия была вокруг надежности, отказоустойчивости, resilience как архитектурной характеристики. Я уже раньше писал про эту глааву отдельный пост.

У нас в гостях были два гостя:
- Евгений Пешков, техлид, независимый эксперт и консультант, увлеченный созданием продуктов, построением эффективных команд и внедрение практик технического совершенства в мире разработки и архитектуры ПО, основатель сообщества DDDevotion.
- Сергей Баранов, архитектор, основатель конференции ArchDays. Сергей ведет каналы

В рамках обсуждения мы упоминали дополнительные материалы
- Моя статья "Проектируем надежные системы — стоит ли игра свеч", которая целиком посвящена теме надежности
- "Site Reliability Engineering" - книга от ребят из Google, с которой началась серия SRE книг и они рассказывают про процесс в общем
- "Building Secure and Reliable Systems" - книга от ребят из Google, где они рассказывают про принципы проектирования надежных систем (продолжает серию SRE книг)
- "AWS Fault Isolation Boundaries" - интересный white paper от AWS на тему границ изоляции сбоев в AWS (здесь интересно написано про инфраструктурные абстракции: зоны, регионы, globl, а также про разделение control plane и data plane при проектировании сервисов и концепцию static stability)
- "A Model-based, Quality Attribute-guided Architecture Re-Design Process at Google" - интересный white paper от ребят из Google, где показано как редизайнится система для повышения ее надежности, причем сам редизайн выполняется достаточно формально, чтобы по модели оценить позитивное влияние на надежность
- "Deployment Archetypes for Cloud Applications" - интересный white paper от ребят из Google, в котором они рассказывают про разные модели deployment приложений, которые позволяют достигать разных уровней availability (зональный, региональный, мультирегиональный, глобальный, гибридный, мультиоблачный)
- "Philosophy of Software Design" - отличная книга про то, как бороться со сложностью систем
- "503 Подкаст - System Design в разрезе надежности" - подкаст с Андреем Дмитриевым из JUG Ru Group, где я был гостем и мы обсуждали проектирование надежных систем
- "Architecting for Scale: High Availability for Your Growing Applications" - интересная книга Lee Atchison, где он обсуждает проектирование для масштабирования и затрагивает вопросы обеспечения availability. Книга пережила второе издание и это пошло ей на пользу.
- "Собеседование SRE: Troubleshooting и System Design" - моя статья про найм SRE инженеров в Tinkoff, и про тип интервью, в котором мы проверяем на практике работу инженеров в рамках инцидента
- "Публичное интервью по troubleshooting для SRE-инженеров на конференции Devoops" - публичное интервью с разбором инцидента
- Крутой доклад "Паттерны отказоустойчивой архитектуры" ребят из Яндекса про отказоустойчивые системы
- Выступление Сергея Баранова "Как принимать инженерные решения в условиях неопределенности" - упоминали в контексте связи с принципами всей книги "Continuous Architecture"
- Miro доска со всеми нашами слайдами, что мы демонстрировали все 4 серии

#Software #Architect #SystemDesign #Philosophy #SoftwareArchitecture #Processes #Management #SRE #Reliability #DistributedSystems

10 Learnings From Running Production Infrastructure at Google • Christof Leng • GOTO 2023

Хороший доклад от Christof Leng, Lead for Google's SRE Engagement Model and SRE Review Programs. Доклад отлично структурирован и может служить некоторой выжимкой из SRE книг Google, которые доступны на их сайте и про которые я уже рассказывал: SRE Book и Building Secure and Reliable Systems. Если возвращаться к самому докладу, то он состоит из следующих частей

0. Culture - начинается все с знаменитой фразы "Культура ест стратегию на завтрак". Но это еще и инженерная проблема, на которую можно смотреть с точки зрения доступного тулинга, методологии, которую могут использовать инженеры для повышения надежности.
1. Reliability can't be taken for granted - про это же я рассказывал в самом начале своем докладе "Проектируем надежные системы - стоит ли игра свеч", но суть в том, чтобы помнить про надежность и риски того, если система будет недостаточно надежна - на это можно смотреть с точки зрения рисков. Плюс надо помнить, что добавить надежность после создания системы бывает невозможно или слишком дорого, поэтому требования по надежности надо обсуждать в нужный момент
2. Cattle vs. Pets - популярная метафора про то, что нам надо относиться к своим системам не как домашним животным, а как к животным из стада. Это позволяет автоматизировать действия по поддержке стада и масштабировать подходы, что не возможно с домашними животными:)
3. Blamelessness - история про правильный подход к обвинениям. Про это подробнее можно почитать у Веструма, который писал про типологию культур - "A typology of organisational cultures", а также про поток информации в них и отношение к ошибкам - "The study of information flow: A personal journey"
4. Measure what matters - рассказ про SLO (service level objectives) и что они действительно должны быть тем, что важно для пользователей сервиса
5. Failure modes - история про то, что участие в инцидентах в рамках oncall позволяет понять как системы разваливаются, почуствовать пороху и понять, что на кону многое стоит. Это не передается при чтении постмортемов ... даже в слух и по ролям:)
6. No heroes - про то, что культура героев, спасающих всех - это плохо для всех. Нас интересует не преодоление проблем, а их предотвращение.
7. Automation - тут идет речь про посто автоматизацию своей работы, которая позволит делать более сложные задачи и меньше заниматься рутинным ручным трудом - лень двигатель процесса.
8. Change is No. 1 reason for outages - все вокруг постоянно меняется и зачастую это является причиной перебоев в работе. И надо быть готовым к этому. Надо минимизировать риск каждого отдельного изменения и автоматизации их проверки и применения (например, используйте GitOps)
9. Outages are inevitable - проблемы неизбежны и надо быть к ним готовым, ограничивая импакт, частоту и вообще управляя риском.
10. No haunted graveyards - не заводите кладбищ с привидениями, под которыми Chistof понимает важные приложения, которые никто уже не трогает и на знает как они работают, а значит не может починить их в случае проблем с ними.

Напоследок автор говорит, что не надо делать сложные системы. Вместо этого надо стараться делать простые системы, хотя это гораздо сложнее, чем сделать сложную систему:) Автор превозносит simplicity и говорит, что boring is beautiful:)

#Software #Engineering #Architecture #SoftwareArchitecture #SystemDesign #DistributedSystems #SRE #Reliability #Conference

ICPC Northern Eurasia Contests

В воскресенье еду в Питер, чтобы в понедельник поучаствовать в мероприятиях студенческого командного чемпионата по программированию ICPC в Северной Евразии, который пройдет с 11 по 13 декабря. Судя по расписанию мероприятия, оно будет плотным и насыщенным не только с точки зрения самого программирования, но и с точки зрения side активности, но мне точно надо будет присутствовать на разных церемониальных частях: Opening Ceremony, Awards Ceremony for RTO HSPC, Awards Ceremony for NEF (что удобно подсвечивается желтым в расписании если нажать Ctrl + F и поискать "Ceremony"). Правда, я думаю, что мероприятие будет интересным и я почти все 3 дня проведу на площадке, общаясь с людьми, что увлечены разработкой софта и которые могут стать отличной свежей кровью для нашей технологической компании.

#Software #SoftwareDevelopment #Conference #Engineering

Как мы в Тинькофф делали игру «три в ряд» для 3 млн клиентов

Интересное выступление от Вадима Гончарова, руководителя отдела проектных и игровых решений внутри моего юнита. В этом выступлении Вадим рассказал про то, как он и его команда создали игру "Ряд наград":
- как сделали свой детерминированный движок match3
- разработали бэкенд с системой валидации ходов, системой выполнения заданий, выдачи призов и уведомлений
- как на фронтенде не стали использовать Unity или iOS/Android
- как пошли путём применения HTML5-технологий: взяли связку Pixi.js для игры и React.js для обвеса
- как использовали технику dependency injection с помощью DI-контейнера, чтобы подружить огромное количество модулей между собой

P.S.
Помню как уговаривал Вадима выступить на Python Conf и рассказать про эволюции Тинькофф Журнала, за который он отвечал до проектов и игр. С тех пор Вадим сильно прокачался, но драйв остался все на том же высоком уровне. Кстати, Вадим ведет интересный канал, на который можно подписаться.

#Management #Software #Engineering #ProjectManagement #Architecture

Code of Architecture - Новогодный выпуск

18 декабря в 18.00 у нас будет новогодний выпуск с обсуждением white paper от Google на тему их гибридного подхода к RnD. Эта статья так и называется "Google's Hybrid Approach to Research" и вышла она в 2012 году (статья доступна в pdf версии здесь). На этот выпуск к нам придут два крутых гостя:
- Игорь Маслов, мой коллега, директор базовых технологий, вице-президент Тинькофф
- Станислав Моисеев, мой колллега, директор инженерных исследований в Тинькофф

Я думаю, что выпуск получится огненным и мы поговорим про подходы Google, а также расскажем как это соотносится с тем, как выглядит RnD в Тинькофф. Чуть ближе к делу я напишу анонс с ссылкой на трансляцию и обложкой, а пока можно почитать мой обзор этого whitepaper, а также вспомнить прошлый новогодний стрим, где мы говорили про Манифест про распределенные системы от команды Аmazon, который тоже был вокруг whitepaper и позволил нам обсудить много интересного:)

#RnD #SoftwareDevelopment #SystemDesign #Engineering #Management

Если с ребенком трудно

Эта книга Людмилы Петрановской написана простым и понятным языком про детей и для родителей. Для родителей, у которых не получается найти общий язык со своим ребенком. Сама книга состоит из 2 частей и кучи миниглав, каждая из которых с простой мыслью, примером и интерпретацией происходящего. Такая структура позволяет легко двигаться по книге и воспринимать ее как смесь теории и решебника:)

В первой части книги, которая называется "Прощай, оружие, или make love, not war" автор высутпает в качестве сапера и показывает как можно уйти от конфронтации с собственным ребенком, втянуть шипы, избавиться от дежурных фраз и негодования. Когда эта цель достигнута, то автор переходит ко второй части книги "Трудное поведение: перезагрузка" и показывает
- как можно повлиять на трудное поведение ребенка
- чем трудное поведение отличается от плохого
- в чем причина этого поведения - это зачастую самый простой способ достижения хороших целей (а сложным и конструктивным способам дети часто не успевают научиться)
Дальше автор предлагает алгоритм из 7 шагов для перезагрузки поведения
1. Определяем цель - надо выбрать то поведение ребенка, которое мешает жить больше всего. У нас должна быть одна или две цели, на которых мы решили сфокусироваться
2. Что именно происходит? - надо собрать симптомы и попробовать собрать информацию о трудном поведении (что, где, когда, ...)
3. Ищем пружину - надо понять что именно является ключевой причиной трудного поведения.
4. Объясняем, что не так - тут надо объяснить в чем проблема, используя "Я-высказывания", где мы говорим про свои чувства, потребности и проблемы. Не используем "Ты-высказывания" навроде "ты не прав" или "ты плохой"
5. Даем наступить последствиям - важно, чтобы при наступлении последствий родители не злорадствовали, а продолжали поддерживать детей, оставались на их стороне и помогали разгребать последствия. Главное, чтобы последствия не были подстроены, а наступали естественным путем
6. Помогаем добиваться своего по-другому - суть в том, что трудное поведение - это обычно примитивные технологии достижения желаемого. Поэтому нам надо показать на примере правильное поведение. Причем главное - это что вы делаете, а не что говорите. Важно быть изобретательным и помогать ребенку находить разные варианты решения проблем.
7. Закрепляем достижения - для закрепления нового поведения требуется поддерживать детей, проявлять симпатию, говорить уверенно и позитивно о будущих изменениях, хвалить и обнимать детей.

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

P.S.
Если немного модифицировать советы из книги, то их можно использовать для работы с трудными сотрудниками:)

#ForParents #ForKids #Management #Leadership #Psychology

Ruby on Rails: The Documentary

Интересная история создания фреймворка для веб-приложений на языке Ruby, которую преимущественно рассказывает сам создатель фреймворка, David Heinemeier Hansson. Сам фреймворк для своего времени был действительно прорывным - он повышал удобство и скорость разработки, позволял разработчику в одиночку накидать прототип или даже довести его до продукта.

Правда, у продукта поверх Ruby on Rails было несколько проблем:
- производительность решения - когда приложение становилось популярным и получало прирост нагрузки, то чеки за используемые мощности железа становились негуманными
- подход conventions over configurations - этот подход про имплицитно принятые решения, которые скрыты от разработчиков, но торчат наружу в виде некоторых guidelines. И все классно работает пока все коллеги разделяют и следуют конвенциям. Но по мере роста решения и команды появляется кто-то, кто, например, используя метапрограммирование (спасибо Ruby) неявно меняет базовое поведение и вся наша стройная схема ломается и надо тратить время на нетривиальный дебаг. В итоге, я персонально больше скланяюсь к мантре "Explicit is better than implicit" из The Zen of Python.

Интересно, что я впервые встретился с Ruby on Rails лет 10 назад в курсе "CS169 - Engineering Software as a Service" от Berkley. В этом курсе авторы
- с большим энтузиазмом использовали Ruby on Rails в качестве базового фреймворка
- промотировали TDD (test driven development) и высокий code coverage
- учиили использовать BDD (behavioral driven development) и именно там я познакомился с огурцом (Cucumber) и с тех пор разуверился в этом подходе (но это отдельная история)
- показывали как использовать Capistrano для деплоя кода в продакшен, потом я некоторое время использовал этот инструмент в своих продакшен проектах
- объясняли почему код, выглядящий как текст на том языке, что ты говоришь - это круто. Ну эту часть я ни тогда, ни сейчас не выкупил (хотя адепты 1С наверное прониклись бы этим объяснением)

В итоге, именно продакшен код на Ruby on Rails я особо не писал, но видел как концепции этого веб-фреймворка проникали в фреймворки на других языках (тот же паттерн ActiveRecord) и мне было интересно а куда он пропал с радаров. В этой документалке вы не найдете ответа на этот вопрос, но зато узнаете как этот фреймворк стал популярен. И вам про это расскажет не только David Heinemeier Hansson, но и куча других людей, приложивших руку к развитию этого фреймворка
- Jason Fried, Founder & CEO at 37signals
- Tobias Lütke, Co-founder and CEO Shopify (участник rails core team с 2004 по 2008 год)
- Jeremy Daer, разработчик в 37signals и участник rails core team с 2005 года
- Jamis Buck, сейчас в MongoDB (участник rails core team с 2005 по 2007 год)

#Software #Engineering #History #SoftwareDevelopment #Architecture #SystemEngineering

День рождения Насти

У моей любимой жены сегодня день рождения. За последний год она успела уйти с прошлой работы, решив сфокусироваться на учебе в Вышке. Правда, после старта магистратуры планы поменялись и Настя решила совмещать учебу с работой в качестве директора благотворительного фонда "Академия жизни", миссия которого звучит так

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

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

Информация о фонде
- годовой отчет фонда за 2022/2023
- telegram канал фонда
- группа вконтакте

#Charity

Архитектурные диаграммы с помощью LLMs (ChatGPT)

Ревьювил на выходных внутренние архитектурные документы и наткнулся на инструкцию о том как правильно писать RFC/ADR а также как можно визуализировать архитектурные диаграммы при помощи чатботов. Сама инструкция была дельной и выглядела так

Нарисуй на plantuml диаграмму

Есть postgres база. В ней есть таблица под названием XXX. Данные в эту табличку XXX пишет фронтенд YYY посредством обращения к бэкенду ZZZ, работающему с этой базой. Есть ETL процесс который перекладывает эту таблицу в clickhouse WWW, в таблицу VVV. При помощи Jupyter мы подключаемся к DWH и анализируем эту таблицу VVV

В принципе, таким макаром можно попросить LLM сгенерировать
- диаграммму классов, компонентную диаграмму, sequence или activity, если нам нужны UML диаграммы
- все виды диаграмм из C4 Model: Context, Containers, Components, and Code
- любые другие диаграммы: ER, DFD, IDEF, BPMN, ...

Правда, в этой инструкции авторы забыли, что на выходе из LLM иногда получается треш, а значит надо знать эти нотации самостоятельно и уметь их читать, а также желательно моделировать. В итоге, визуализировать с помощью ChatGPT конечно весело, но визуализация должна помогать + быть достаточно точной. А для того, чтобы проверить насколько она хороша, я бы рекомендовал не просто командовать чатботу, но еще изучить документацию пл моделированию, например, такую
- Стандарт по UML
- Документацию по platuml
- Документацию по C4 Model
- И любая другая документация по нужной вам нотации моделирования

Без таких базовых знаний сложно отвалидировать то, что выдала LLMка

#Software #SoftwareArchitecture #Architecture #Engineering #SoftwareDevelopment

Как RnD появляется в крупных IТ-компаниях

Вот и вышла запись моего выступления на конференции Teamlead++ в треке техлидов про появление research and development в крупных компаниях. В этом докладе я рассмотрел это на примерах компаний Google, Amazon, Yandex и Tinkoff. Причем сначала я показывал как выглядел рост компании, показывал как работает бизнес-модель (часто это была модель платформы с двухсторонним сетевым эффектом), а потом делал вывод, что такой экспоненциальный рост требовал ррешения большого количества технических вызовов. И разные компании к этим техническим вызовам подходили по разному
- Google многие из решенных проблем заворачивал в whitepaper, которые дали старт многим open-source проектам
- Amazon скорее делал техпродукты для себя, а потом начал их продавать в AWS, причем статьи были не про внутреннее устройство, а про то, как пользоваться этими продуктами
- Yandex часто рассказывал про свои решения, но деталей почти не было, но в 2016 году появился в open source ClickHouse, в 2017 - CatBoost, а в 2022 и 2023 публикаций стало много, среди которых самое интересное - YDB и Ytsauru, и это если говорить только про официальный open source от Yandex:)

У нас в Тинькофф все начиналось с использования коробочных продуктов, потом мы стали писать много своего кода, года 4 назад стартовала разработка своей IDP (internal developer platform) и кучи технологических продуктов:
- Managed K8s - целевой runtime для low-latency приложений
- LBaaS - балансировщик как сервис, который доводит трафик до приложений внутри Managed K8s
- DBaaS (Postgres, Cassandra, Redis) - целевые базы данных
- Kafka as a Service - платформа для messaging
- Sage - наша obsesrvabilty платформа (логи, метрики, алерты) со своим языком Mage и планом перехода с Elastic на новосозданную базу данных
- Statist и a/b платформа - общее решение для продуктовой аналитики и a/b тестов
- Куча инструментов внутри нашей data платформы - тут инструментов очень много
- и так далее

И сейчас у нас собирается RnD лаба для инженерных исследований, которой руководит Станислав Моисеев, а находится она в нашей платформе базовых технологий, которой руководит Игорь Маслов, директор этой платформы и VP. В общем и целом, для нас развитие RnD направления является стратегическим и если вы хотите заниматься инженерными исследованиями, то можете писать мне в личку, а я познакомлю вас со Стасом и Игорем:)

P.S.
В ближайший понедельник в 18.00 на стриме Code of Arcitecture мы поговорим про подходы к RnD в Google и расскажем как мы планируем это делать в Тинькофф. На стриме мы будем обсуждать это с Вовой Чистяковым, Игорем Масловым и Станиславом Моисеевым.

P.P.S.
Материалы к докладу
- Статья с расшифровкой - текстовая версия выступления, но без части про Yandex (ее я добавлял именно к Teamlead Conf)
- White paper "Google's Hybrid Approach to Research" - хорошая научная статья 2012 года про гибридный подход Google к RnD
- Ключевые публикации с Google Research - подборка от меня ключевых whitepaper по техническим продуктам Google
- Invent and Wander. Избранные статьи создателя Amazon Джеффа Безоса - книга с историей Amazon через публичные письма Джеффа акционерам + другие ключевые выступления
- Письмо Джеффа Безоса акционерам 2010 года - интересно написано про важность общих подходов и инструментов для компании
- Статья от Yandex "Почему инфраструктура big tech обычно состоит из самописных решений" - крутая статья, в которой на пальцах объясняются причины и приводится примеры ввнутреннего облака и монорепозитория
- Yandex Platform Engineering - крутой ресурс с описанием технологий и команд отдела Yandex Platform Engineering, который делает инфраструктуру для разработки и эксплуатации продуктов Яндекса
- Whitepaper "Investigation of The Relationship Between Brand Value And R&D Activities: Fortune 500 Companies Analysis" - исследование про связь стоимости бренда и затрат на RnD

#Management #RnD #Leadership #Processes #Architecture #PlatformEngineering

ICPC Northern Eurasia Contests - победители

Не зря съездил на полуфинал ICPC - посмотрел как команда "Ёлки-палки" из МФТИ победила в соревнованиях второй год подряд. Ребята решили все задачи и выиграли очень уверенно. Ждем от них победы в финале ICPC.

#Software #Engineering