Modern Platform Engineering: 9 Secrets of Generative Teams • Liz Fong-Jones • GOTO 2023

Интересный доклад от Liz Fong-Jones, Field CTO из Honeycomb. Сначала Liza вспоминает что такое DevOps, потом SRE, а потом переходит к теме Platform Engineering.
В части про devops идет речь про стремление к culture, automation, lean, measurement и sharing. А DORA метрики позволяют измерить насколько хорошо это получается у команд. Но эти метрики имеют ряд проблем:
- Путь улучшений не слишком ясный
- Сами улучшения сложно померить (плюс мы измеряем запаздывающие показатели)
- Есть дилемма с самой моделью зрелости и непрерывными улучшениями (модели зрелости предполагают, что можно попасть на определенный уровень зрелости, а дальше уже улучшаться не требуется - кстати, в "Accelerate" для решения этой проблемы предлагали использовать capabilities model - я рассказывал про это в обзоре книги)
- Как достигать консистентности в разных командах

В итоге, Liz предлагает модель с 9 секретами, что способствуют генеративной культуре по Веструму (я уже писал про этот подход к типизации культур)
1. Reproducible deploys (If it ain't in Git it don't exist!) - нам нужна повторяемость в сборках и деплоях. Про это шла речь еще во времена появления 12 factor app, а сейчас это стандарт де-факто:)
2. Fast CI/CD (I wanna go fast!) - ускоряем циклы обратной связи, помогаем разработчикам быстрее видеть результаты своего труда.
3. Observability (Don't drive with snow on your windshield!) - дефолт для понимания того, что происходит с нашим приложением. Без этого не ясно как определять наличие проблем, а также траблшутить их.
4. Feature flagging (Smaller boom, less fear!) - в комплекте с TBD (trunk-based development) позволяет правильно делать CI (подробнее в докладе)
5. Code ownership (You build it, you run it! (with a twist)) - мантра, которая убирает забор между dev и ops (sre) командами. По-факту, SDEs (software development engineers) владеют не только кодом, но и самим приложением, что крутится в продакшене
6. Blameless culture (No one wins the shame game!) - здесь посоветую сразу несколько статей и выступлений
- Google's Project Aristotle - исследование, которое ответило на вопрос "What makes a team effective at Google?"
- A typology of organisational cultures - интересное исследование про типологию организационных культур (pathological, bureaucratic, generative)
Мои выступления на связанные темы
- Культура постмортемов
- От монолита к микросервисам и обратно
7. Service level objectives (SLOs) (If you liked it you shoulda put an SLO on it!) - про это я говорил в докладе "Проектируем надежные системы - стоит ли игра свеч"
8. Chaos Engineering (Test your assumptions!) - рекомендую на эту тему глянуть выступление Kelly Shortridge "Practical Magic: The Resilience Potion & Security Chaos Engineering"
9. Platform teams (to tie it all together and systematise it) - рекомендую почитать книгу Team Topologies про team-first подход при проектировании архитектуры программных систем, так и организации. В ней очень хорошо рассказывается про платформенные команды. А вот как сама Liz характеризует эти команды

Platform teams outsource as much as possible, write as little code as possible.
Platform teams are experts in outsourcing. It’s a very high-leverage role; they use their infra expertise to offload as much operational burden as possible.

В итоге, в модели Liz платформенные команды помогают всем остальным 8 пунктам и позволяют построить генеративную культуру и высокоэффективные команды.

#Engineering #SystemEngineering #SystemDesign #SoftwareArchitecture #Software #Devops #PlatformEngineering #Process #Culture #SRE

Build Abstractions Not Illusions • Gregor Hohpe • YOW! 2023

В этом докладе Gregor Hohpe говорит про абстракции и их пользу, а также как чрезмерное абстрагирование и исключение важных вещей приводит к созданию иллюзий (и протекающих абстракций).
- Intro - автор показывает свой стандартный пример с различными географическими картами, которые отличаются в зависимости от цели и аудитории.
- Platform abstraction - автор переходит к platform abstraction и вспоминает про уменьшение когнитивной нагрузки для пользователей платформы. И тут появляется аналогия с машинами и платформами, которые использовались в автомобильной индустрии для выпуска машин разных марок на базе одной "платформы". Это позволяло экономить, разработав качественную платформу и переиспользовать ее для разных продуктов
- Abstractions vs composition - Автор продолжает приводить примеры из области автомобилестроения и говорит про педаль газа (хотя это скорее не педаль газа, а педаль ускорения, что еще очевиднее, если мы рассматриваем элетрические автомобили). Дальша он приводит SQS-Lambda-SQS из AWS, а потом переходит к паттерну scatter-gather pattern, который изначально назывался broadcast aggregate. Проблема в том, что в этих случаях описывается не сама абстракция, а ее реализация. Дальше автор рассказывает про электрическую розетку, которая является отличной абстракцией и автор объясняет почему (разделение интерфейса и реализации, стандартизация интерфейса, ...). Но даже электрическая розетка протекает как абстракция, если происходит глобальное отлючение энергии (в розетке заканчивается ток). Ну и напоследок автор говорит про абстракцию сокетов (sockets и packet routing). В итоге, автор говорит про то, что композиция бывает полезна, но она отличается от абстракции, так как объединение элементов в этом случае не предоставляет новую абстракцию
- Abstractions vs Illusions - Автор описывает абстракции, которые зашли слишком далеко. Например RPC (remote procedure call), который он описывает так, как было принято в начале 2000х, когда RPC пытались сделать похожим на локальный вызов и скрыть всю сложность. С тех пор утекло много воды и так никто не делает, но вьетнамские флешбеки Грегора тут выглядят странно. В итоге, проблема описывает так, что в иллюзиях мы выкидываем важные детали или излишком обобщаем до состояния, когда наша модель начичнает вводить людей в заблуждение. Дальше автор рассказыывает про абстракцию платформ. Интересно, что как представитель AWS он катит бочку на создателей IDP (internal developer platform) внутри компаний поверх публичных облаков - по мнению Грегора часто это не добавляет никакого value, а только отнимает его (мне эти аргументы кажутся очень biased). И дальше Грегор показывает хорошую по его мнению абстракцию в виде ledger database из двух dynamo db и event bridge pipes посередине. Суть этих размышлений сводится к тому, что IDP внутри компаний должны не просто уменьшать возможности публичных сервисов, закручивая гайки, а скорее создавать новые абстракции, которые полезны для пользователей внутри компании. И дальше автор говорит, что "good abstractions support broad usage".
- Distributed system abstractions - В этой части автор напирает на асинхронную работу с сообщениями (asynchronous messaging) и добавляет к абстракции data flow еще и control flow, который бывает полезно понимать. Речь идет примерно про puller, pusher, pool и driver
Ну а дальше Грегор показывает как понимание работы control flow позволяет сделать стандартные абстракции полезными
- Summary - в заключение Грегор подводит итог и говорит, что

Good abstractions reduce cognitive load because they form a cohesive language and a mental model.
Omitting relevant details is tempting but leads to dangerous illusions.

#Conference #PlatformEngineering #SystemEngineering #Software #Architecture #DistributedSystems

Code of Leadership 9 - An Elegant Puzzle - System of Engineering Management (часть 1)

Девятый выпуск Code of Leadership посвящен обсуждению крутой книги "An Elegant Puzzle: Systems of Engineering Management", про которую я уже рассказывал. Эту книгу написал Will Larson, технический директор Carta, который до этого работал в Calm, Stripe и Uber. В этой книге автор рассказывает про подходы к engineering management.
Саму книгу я обсуждаю с Eugene Sergueev, senior engineering manager во Flo health, приложении для женского здоровья. У Жени больше 15 лет опыта в индустрии, из которых 7 лет в менеджменте. Он успешно руководил небольшими командами, так и компанией 50+ человек на позиции СТО. Женя любит системный подход к решению проблем, поэтому он и выбрал эту книгу для обсуждения.

В этом выпуске только первая половина обсуждения, так как весь выпуск получился длинной больше трех часов:) А если кратко, то за час мы успели поговорить про книгу в общем и обсудить полностью вторую главу и часть третьей главы книги:
2. Organizations - здесь идет речь про определение размера команд, как оставаться на пути к высокоэффективным командам, как не оптимизировать сверху вниз (часто это работает плохо), как быть продуктивным в быстрорастущих компаниях, как планировать успех
3. Tools - здесь автор рассказывает про системное мышление и упоминает Медоуз с ее "Азбукой системного мышления" (про которую я писал ранее), как быть исполняющим обязанности продакт менеджера, как формлировать vision и strategy, как драйвить технические миграции.

#Engineering #Management #Leadership #Processes #SystemDesign #SystemThinking #SystemEngineering

Code of Leadership #10 - An Elegant Puzzle - System of Engineering Management (часть 2)

В десятом выпуске Code of Leadership заканчивается обсуждение крутой книги "An Elegant Puzzle: Systems of Engineering Management" (начало в выпуске 9), про которую я уже рассказывал. Эту книгу написал Will Larson, технический директор Carta, который до этого работал в Calm, Stripe и Uber. В этой книге автор рассказывает про подходы к engineering management.
Книгу мы продолжаем разбирать с Eugene Sergueev, senior engineering manager во Flo health, приложении для женского здоровья. У Жени больше 15 лет опыта в индустрии, из которых 7 лет в менеджменте. Он успешно руководил небольшими командами, так и компанией 50+ человек на позиции СТО. Женя любит системный подход к решению проблем, поэтому он и выбрал эту книгу для обсуждения.

В этом выпуске только вторая половина обсуждения, так как весь выпуск получился длинной больше трех часов:) А если кратко, то за 2 часа мы успели обсудить все темы со второй половины третьей части по окончание книги, а точнее

3. Tools - как проводить инженерную реорганизацию (и стоит ли это вообще делать), как формировать свои карьерные нарративы, как подходить к продвижению сложных тем без формального authority с использование подхода model-document-share, как делать презентации топ-менеджменту и управлять своим временем
4. Approaches - как не погрязнуть в управлении исключениями к собственным policies, как говорить нет, формулировать свою философию менеджмента, как понимать где у engineering managers возникают проблемы, как быть в партнерских отношениях со своим менеджером, находить себе зону ответственности и устанавливать направление развития организации
5. Culture - как формировать культуру инклюзивной организации с использованием возможностей и membership, как выбирать лидов проектов, делать своих peers первой командой, как балансировать positive и negative freedoms в культуре компании, отказаться от культуры героев в пользу устойчивого роста
6. Careers - как выстраивать процесс интервью, как проводить холодный sourcing, работать над воронкой найма, использовать performance management для развития уже нанятых сотрудников через понятные карьерные лестницы, как создавать специализированные роли вроде SRE или TPM (technical product manager), как проектировать циклы собеседований для желаемых позиций
7. Appendix - как оперировать в растущей оранизации: на уровне линейного менеджмента, уровне middle management и дальше менеджмента всей организации, а напоследок автор приводит список книг и white papers по интересным для него темам

#Engineering #Management #Leadership #Processes #SystemDesign #SystemThinking #SystemEngineering

CTO Day Light от Yandex

Вчера была интересная тусовка для технических директоров от Yandex в центре Москвы.
Мероприятие получилось для меня очень интересным, так как удалось пообщаться с умными людьми и обсудить интересные вопросы от полушуточных до серьерзных, например
- Как выстраивать end-to-end процессы продуктовой разработки и какие проблемы тут могут быть
- Как выстраивать оргструктуру под требования бизнеса и как понять оптимальна ли структура под текущие запросы
- Что такое культура компании и как она влияет на взаимодействие команд и процессы
- Как подходить к процессам архитектуры и проектирования - тут и про написание дизайн доков, про нотации моделирования, про описание стейта архитектуры vs изменений, про TLA+ и не только
- Кто такие системные аналитики и что они делают в командах разработки
- Как выглядит работа в европейской компании vs российской:)
- и так далее

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

P.S.
Спасибо организаторам, что позвали в гости на это мероприятие.
Кстати, оно было продолжением того, что было на CTO Day в Дубае, про которое я рассказывал раньше.

#Engineering #Software #Management #SystemDesign #SystemEngineering #Leadership

The Engineering Executive's Primer: Impactful Technical Leadership

Сегодня друг подарил мне эту книгу Will Larson в бумаге, которая больше квартала ехала из США. Я уже предвкушаю как прочитаю эту книгу для инженерных топ-менеджеров:) Суть в том, что мне нравится бложик Вилла Ларсона lethain.com и его предыдущие книги
- Staff Engineer - эта книга является классным источником информации по карьерному пути для инженеров, которые переросли уровень senior и отправились покорять новые моря. Я про нее уже рассказывал: 1 и 2
- An Elegant Puzzle. Systems of Engineering Management - крутая книга для engineering managers, про которую я рассказывал раньше, а потом было две серии подкаста "Code of Leadership" с разбором этой книги вместе с Eugene Sergueev, senior engineering manager из Flo health: 1 и 2

В общем, еще до прочтения книги, я могу ее порекомендовать своим читателям.

#Engineering #Management #Leadership #Processes #SystemDesign #SystemThinking #SystemEngineering

Обсуждение книги "Learning Domain-Driven Design" вместе с ребятами из клуба { между скобок } (Рубрика #Architecture)

Сегодня вечером в 19:00 я приду к ребятам в гости, чтобы обсудить последнюю, четвертую часть книги, которая называется "DDD и другие методологии и паттерны". Вся книга очень интересна и я рассказывал об этом раньше. Кроме того, последние главы мне настолько понравились, что я даже в свое время сделал отдельные разборы каждой главы
14 глава. DDD и микросервисы
15 глава. DDD и event-driven architecture
16 глава. DDD и data mesh
Поэтому я с большой радостью откликнулся на приглашение Гриши Скобелева обсудить эту книгу вместе.

#Management #Architecture #SoftwareArchitecture #DDD #SystemDesign #Leadership #DistributedSystems #SystemEngineering #SoftwareDevelopment

Архитектурный чекап здоровья систем - Андрей Шалунов, Яндекс Плюс (Рубрика #Architecture)

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

P.S.
Выступление мне зашло по трем причинам
1) Я на этой неделе выступал внутри на бизнес-стендапе с 10 минутным рассказом про эволюцию архитектуры Т-Банка и направлении дальнейшего развития. И это выступление начиналось с того, что я объяснял почему строительная метафора вредна, а метафора природы и живых организмов полезна, правда я там говорил про леса и рисовые поля, где как и в архитектуре часто сложно узнать что происходит за поверхностью воды или интерфейса:)
2) Я в последнее время много времени уделяю медицинским процедурам и прохожу этакий чекап, посещая невролога, кордиолога, окулиста, ... И кажется, что чекап надо было делать раньше, а не забивать на него.
3) Недавно у меня был выпуск подкаста "Code of Leadership" с Антоном Костериным, заместителем технического директора в Т-Банке, про наш процесс управления архитектурными изменениями и при желании часть активностей оттуда можно было бы назвать архитектурным чекапом

#Management #Architecture #SoftwareArchitecture #SystemDesign #SystemEngineering #SoftwareDevelopment

Platform Strategy - Gregor Hohpe & James Lewis - GOTO 2024 (Рубрика #Architecture)

Это интересное интервью ребят из книжного клуба GOTO с Gregor Hohpe, который написал недавно очень интересную книгу "Platform Strategy". Gregor - тертый калач и я уже как-то рассказывал про его достижения, среди которых написание книг "Enterprise Integration Patterns" (мой пост о книге), "The Software Architect Elevator" (мой пост о книге), "Cloud Strategy", которую я ее еще не читал и "Platform strategy", которую я читаю сейчас и о которой идет речь.

Основныые тезисы в интервью следующие
- Платформы важны, потому что они помогают снизить когнитивную нагрузку на инженеров
- Классификация платформ: base platform (навроде AWS), а также кастомные платформы внутри компаний, которые должны не повторять AWS, а закрывать специфичные для компании сценарии. На эту тему Грегор рассказывал доклад "Build abstractions not illusions", про который я уже рассказывал. В общем, платформы могут создавать иллюзии простоты, но на самом деле могут быть сложными и требовать принятия решений.
- Платформы должны предоставлять полезные абстракции для создателей приложений и не вводить в заблуждение. Здесь автор вспоминает про книгу "The Software Architect Elevator" и говорит о том, что если для правильного использования платформы требуется погружаться в детали реализации абстракции, то что-то не так с платформой
- Грегор рассказывает про переименование разнообразных систем в платформы. И для того, чтобы понять платформа ли перед вами надо помнить, что платформы не должны делать все за вас, а должны облегчать выполнение задач.
- Во время создания платформ важно общаться с командами разработчиков и наблюдать за тем, что они делают, чтобы понять, как они решают проблемы. А сам Грегор часто помогает командам понять, что они на самом деле сделали, и как это может быть использовано в других контекстах.
- Метафоры могут помочь людям мыслить по-другому и повысить прозрачность в общении. Собственно, сам Грегор использует автомобильные метафоры для рассказа о платформах - в автоиндустрии уже давно начали использовать платформы для шасси, а сверху лепили чуток отличающиеся кузовы. Затраты на создание шасси фактически разделяются между разными моделями автомобилей
- Собственно хорошие платформы гармонизируют основу, а поверх нее позволяют расцвести инновациям - так было в мире автомобилей и то же самое мы видим в мире облачных платформ
- Стандартизация может быть инструментом для инноваций, но важно не превращать ее в самоцель. Это просто инструмент для достижения целей
- Когда мы задумываемся об изменениях, то надо понимать как ограничения, которые устраняются, могут влиять на мировоззрение людей и их работу. Этот переход к новой парадигме может быть трудным для людей, но это может привести к новым возможностям и ограничениям. Одновременно важно задавать вопросы о том, а какие новые ограничения возникают вместе с новыми технологиями.
- При создании внутренней платформы разработки в компании надо создать платформу, которая будет полезна для бизнеса, а не просто для инженеров. Она должна быть сосредоточена на том, что важно для бизнеса, а не на технических аспектах.
- Экономика внутренней платформы может быть хуже, чем у облачного провайдера, из-за меньшего масштаба. Кроме того, она может быть связана с вопросами ценности и долговечности продуктов.

В будущем Грегор планирует написать книгу о стратегии API и интеграции, которая будет учитывать границы и поможет людям усвоить эти концепции. Это будет в некотором роде продолжение книги "Enterprise Integration Patterns", которая вышла больше 20 лет назад.

#Conference #PlatformEngineering #SystemEngineering #Software #Architecture #DistributedSystems #Management

Дисциплины в университете: что изучают студенты ФКН (Рубрика #Career)

Недавно вышел интересный эпизод подкаста "Уютный ФКНчик", в котором обсуждается прикладное значение курсов, которым обучают в университете и их полезность в дальнейшей карьере. Подкаст интересен темой и своим звездным составом
- Евгений Соколов - ведущий подкаста, а также научный руководитель Центра непрерывного образования ФКН, академический руководитель образовательной программы «Прикладная математика и информатика» ФКН
- Иван Пузыревский - гость подкаста, а также директор по технологиям в Yandex Cloud
- Игорь Маслов - гость подкаста, а также директор базовых технологий в Т-Банке

Ребята за час успевают обсудить кучу вопросов, которые могут помочь не только студенту, но и уже сложившемуся инженеру понять как ему прокачиваться дальше
- Сколько и каких языков программирования надо знать хорошему специалисту;
- Что нужно знать про операционные системы, чтобы устроиться в Yandex Cloud;
- Зачем на собеседованиях требуют знания алгоритмов и структур данных;
- Почему необходимо изучать математику и как она пригождается на практике;
- Нужно ли машинное обучение классическим разработчикам;
- Как писать безопасный код и что для этого надо знать.

Подкаст организован Центром непрерывного образования ФКН совместно с Т-Банком.

P.S.
Я с большим интересом послушал этот подкаст, но еще интереснее общаться на эти темы с ребятами вживую:)

#Career #Software #Architecture #SystemEngineering #Engineering