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

Аудиоподкаст "Code of Leadership" на Я.Музыке

Многие просили сделать аудиподкаст в каком-то удобном месте. Я сначала завел его на podster.fm, а потом заполнил заявку в Яндекс Музыке на добавление подкаста и ... забыл об этом. Но ребята из Я.Музыки не забыли ... Вчера после очередного комментария на Youtube на тему того, что нужна аудиоверсия в VK или Яндекс Музыке, я решил проверить как поживает моя заявка и увидел, что подкаст уже есть:) Так что теперь можно слушать аудиоверсию подкаста в фоне и в привычном интерфейсе.

#Management #Leadership #Processes #Software #Engineering #Architecture

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

Gregor Hohpe (AWS Senior Principal Evangelist и автор популярных книг)

В продолжении предыдущего поста про доклад "Build Abstractions Not Illusions" хотелось вспомнить в общем про Грегора, который
1) Больше 20 лет назад написал книгу "Enterprise Integration Patterns", про которую я уже рассказывал. Эта книга описывала паттерны интеграции и до сих пор концепции из нее достаточно полезны
2) Успел поработать в Google, а сейчас работает в AWS в области FaaS (function as a service) и евангелирует использование AWS
3) Написал книгу "Cloud Strategy", но я ее еще не читал
4) В 2020 году написал книгу "The Software Architect Elevator ", про которую я тоже рассказывал. Книга посвящена роли архитектора в современных условиях, когда крупные компании занимаются переводом на цифру всего и вся
5) Недавно написал книгу "Platform strategy", что я только планирую прочиать

Но Грегор не только пишет книги, но и выступает на конференциях, причем про пару выступлений я уже рассказывал раньше
- The Magic of Platforms
- I Made Everything Loosely Coupled. Does My App Fall Apart?

#Architect #Person

Practitioners guide to MLOps: A framework for continuous delivery and automation of machine learning - Part I

Постоянные читатели канала могли заметить, что я часто говорю про инженерные процессы и упоминаю так или иначе DevOps, SRE, Platform Engineering. Но у термина DevOps, который был про сближение разработки и эксплуатации очень быстро появлялись похожие по смыслу термины, но из своих областей: DevSecOps, DataOps, FinOps, ..., MLOps. Подробнее про эти метаморфозы можно посмотреть в докладе "The Pipeline-Driven Organization • Roy Osherove • GOTO 2022", про который я уже рассказывал. Но сегодня я хотел рассказать про простенький whitepaper 2021 года от Google Cloud на тему MLOps, раз уж у нас сейчас расцвет AI и ML:)

Сам документ состоит из трех частей
- Overview of MLOps lifecycle and core capabilities
- Deep dive of MLOps processes
- Putting it all together

В первой части приводится определение MLOps

MLOps is a methodology for ML engineering that unifies ML system development (the ML element) with ML system operations (the Ops element). It advocates formalizing and (when beneficial) automating critical steps of ML system construction. MLOps provides a set of standardized processes and technology capabilities for building, deploying, and operationalizing ML systems rapidly and reliably.

И показывается четкая связь между data engineering, app engineering и собственно ml engineering. Причем выстроенные процессы работы с данными нам нужны как пререквизиты для эффективной работы над ML моделями, а app engineering нужен для того, чтобы обученные модели хорошо работали в проде и сервили свои запросы.
В документе рассказывается про этапы процесса, которые напоминают стандартные истории из app engineering и devops, но с небольшой спецификой
- ML development - эксперименты с данными, выбор модели и архитектуры, оценка вариантов и выбор лучшего
- Training operationalization - выстраивание пайплайна обучения модели
- Continuous training - непрерывное обучение в ответ на новые данные, изменения кода или просто по расписанию
- Model deployment - развертывание модели (очень напоминает развертывание обычных приложений)
- Prediction serving - модель работает в проде и обрабатывает запросы (онлайн/оффлайн)
- Continuous monitoring - мониторинг работы модели (тут как обычные параметры работы приложения, так и отслеживание метрик эффективности модели, дрифта данных, изменения распределения процесса, что мы предсказываем)
- Data and model management - это центральная, сквозная функция управления артефактами ML, обеспечивающая возможность аудита, отслеживания и соответствия требованиям. Эта функция помогает с совместной работой, повторным использованием,и возможностью обнаружения какие ML модели уже есть и работают.

Продолжение про capabilties ML платформ во второй части поста.

#ML #Devops #Data #AI #Software #Architecture #Processes

Practitioners guide to MLOps: A framework for continuous delivery and automation of machine learning - Part II

Продолжая первый пост про этот whitepaper, надо рассказать про capabilities ML платформ, которые нужны для того, чтобы выстроить хорошие MLOps процессы:
- Experimentation - совместное выполнение исследовательского анализа данных, создание архитектуры прототипов моделей и реализация процедур обучения
- Data processing - возможность обработки данных, что позволяют готовить и преобразовывать большие объемы данных в конвейерах непрерывного обучения
- Model training - возможность эффективно и экономично запускать мощные алгоритмы для обучения моделей машинного обучения
- Model evaluation - возможность оценки модели в интерактивном режиме во время экспериментов
- Model serving - возможность развертывать и обслуживать модели в продакшен
- Online experimentation - возможность провести онлайн-эксперименты, чтобы понять, как недавно обученные модели работают в продакшене по сравнению с текущими моделями (если таковые имеются) перед выпуском новой модели в производство
- Model monitoring - возможность мониторинга моделей позволяет отслеживать эффективность и результативность развернутых моделей для обеспечения прогнозируемого качества
- ML pipelines - возможность выстроить сложные пайпланы для тренировки и эксплуатации моделей в проде
- Model registry - централизованный реестр моделей (регистрация моделей, описание зависимостей, документации и метаданные, интеграция с экспериментами и мониторингом, а также раскаткой и откаткой моделей)
- Dataset and feature repository - хранилище наборов данных и фичей позволяют унифицировать определение и хранение данных для ML моделей. Наличие центрального хранилища свежих высококачественных данных обеспечивает возможность совместного использования, обнаружения и повторного использования.
- ML metadata and artifact tracking - хренение различные типов артефактов ML, что создаются в разных процессах жизненного цикла MLOps, включая включая описательную статистику и схемы данных, обученные модели и результаты оценки

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

P.S.
Конечно читая между строк этого документа можно понять, что внутри Google Cloud есть ML платфома со всеми этими возможностями, что позволяет из коробки выстроить MLOps ... если вы используете нужное облако:) Но это не умаляет хорошего описания фреймворка для MLOps, который приведен в этой статье

#ML #Devops #Data #AI #Software #Architecture #Processes

Инструменты надежности Такси \ Александр Фишер, Яндекс Такси

Интересное выступление Александра Фишера насчет процессов и инструментов по повышению надежности. Выступление короткое и состоит из шести частей
1. Такси и надежность
Вводная про критичность сервисов такси, профиль нагрузки, кратко про архитектуру, используемые технологии. Дальше про метрики надежности:
- Стандартные: SLO в девятках, MTTR (mean time to recovery)
- Интересные: MTTRC (mean time to root cause) - насколько быстро находится корневая причина сбоя, ROCOF (rate of occurrences of failures) - частотность сбоев
В общем, дальше посыл такой, что в следующих пунктах автор рассказывает про инструменты борьбы со сложностью
2. Хаос
Подход ребят в том, что они используют fault injection, где data plane этого хаоса реализован через lua скрипты для nginx, которые балансируют трафик, а также есть control plane для управления конфигурацией этих инжектированных ошибок. Этот инструмент позволяет
- Замедлять сервис (но укладываясь в propogation deadline)
- Моделировать метастабильное состояние сервиса, когда сервис упал под нагрузкой и встать не может, ждет он кто ему поможет:)
- Выдача 500 ошибок с заданным процентом
3. Срезание нагрузки: деградация, retries, limits
У ребята есть
- Gracefull degradation mode, где неосновной функционал можно отключить (это добавляет 20% мощности, но в планах 50%)
- Управление retries для решения проблемы амплификации запросов во время сбоев
- Есть классификация сервисов по уровням, где уровень зависит от критичности сервиса для возможности выполнить основную функцию (уехать на такси)
4. Виртуальные заказы
Рассказ про тестирование нагрузки на систему через моделирование нагрузки виртуальными заказами, которые позволяют проверить нагрузку не API endpoint, а холистически для всей системы. Крутой инструмент, который решает проблему проверки нелинейных зависимостей и непредсказуемого поведения реально сложной системы в зависимости от разного типа нагрузки.
5. Observability и eventboard
Тут автор показывает и рассказывает про дашборды для observability + интересный eventboard про события на проде, а также кнопку "откатить все за последние n минут", что помогает уменьшить MTTR (mean time to recover) и ускорить восстановление после сбоя.
6. Симуляция инцидентов
Тут идет рассказ про координаторов сбоев + про симуляцию сбоев и тренировки по устранению сбоев, что идут каждую неделю

Ну и в конце выступления автор рассказывает про экспериментальные инструменты
- Autorecovery - робот, что автоматически чинит инциденты (он пока в dry run работает и проходит обкатку)
- SRE GPT - инструмент для помощи в поиске root cause

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

#SRE #DistributedSystems #Reliability #Architecture #Software #Processes #Management

Как выглядит роль SDE в tech компаниях

Сегодня выступаю на нашем мероприятии для студентов из МФТИ, где я учился много лет назад.
У меня есть полчаса и я планировал обсудить кучу тем:
- Современные процессы разработки и инженерные практики в российских tech компаниях - расскажу про то, как все начиналось, потом появилась история с devops, потом shift-left everything и X+Ops:)
- Как выглядит карьерный путь SDE (software development engineer) с развилкой в менеджмент и путь individual contributor высоких грейдов
- Как выглядит матрица компетенций для SDE в Tinkoff
- Как выглядит процесс роста сотрудников внутри (Tinkoff рост)
- И другие полезные мысли про саморазвитие и рост внутри компании:
-- Как использование Cynefin фреймворка
-- Как работать над сложной проблемой (и создавать артефакты RFC/ADR)
-- Как приоритизировать задачи используя матрицу Эйзенхауэра
-- Как работать со своей мотивацией
-- Как планировать работу используя backcasting (это примерно тоже самое, что working backwards от Amazon)
-- Как работает мантра "You build it, you run it" и почему она помогает инженерам расти над собой быстрее

Интересно, что многое из сегодняшнего доклада мы обсуждали с Алексеем Тарасовым в рамках выпуска Code of Leadership пару недель назад.

P.S. Материалы к выступлению

Материалы по процессам разработки
- Современные подходы к разработке программного обеспечения
- Совершенствование потока разработки программного обеспечения
- Проектируем надежные системы — стоит ли игра свеч
- Про управление проектами и продуктами
- The Pipeline-Driven Organization • Roy Osherove • GOTO 2022
- Code of Architecture — “Distributed Systems, 4th Ed” #2 (Architecture)
- Архитектура в масштабе на ArchDays 2020
- Devops культура: мифы и реальность
- Про MLOps
- The State of Application Security 2023 • Sebastian Brandes • GOTO 2023
- Как RnD появляется в крупных ИТ-компаниях

Материалы по проектированию и system design
- Статья про System Design Interview в общем
- Статья про то, как мы оцениваем System Design Interview
- Статья о том, как подготовиться и пройти System Design Interview
- Публичное System Design Interview на C++ Russia 2022
- Публичное System Design Interview на конференции ArchDays 2022
- Статья со списком книг о проектировании программного обеспечения
- Курс Essential Architecture #Code
- Курс Essential Architecture #Data

#Management #Software #Processes #Project #ProductManagement #Engineering #Processes #Leadership #Staff #Architecture #Career

The 12 Factor App for Data • James Bowkett • GOTO 2023

Интересное выступление James Bowkett на тему хороших подходов для работы с данными. В названии он делает отсылку к 12 факторам, которые в свое время сформулировали ребята из Heroku и которые стали предвестником подходов cloud native приложений. James предлагает 12 факторов, которые помогут сделать более качественным пайплайн работы с данными, которые часто называют сейчас big data и используют для обучения ML моделей:) Мне принципы Джеймса понравились, а особенно понравилось то, как он их структурировал

-> Architecture & Design - факторы, относящиеся к проектированию решений
1. Data structures as code - универсальный совет не полагаться на UI, а конфигурировать настройки для управления данными через код. Это стандартный совет в духе IaC (infrastructure as a code), GitOps и так далее.
2. Append-only data structures - использование таких структур данных добавляет историчность и позволяет time travel.
3. Optimise for access and retrieval - автор рекомендует не делать кладбище данных (data graveyard), а думать про то, как денормализовать данные так, чтобы их было удобно использовать
4. Separate data from logic - автор предостерегает от использования протекающих абстракций (leaky abstraction), навроде магических значений, которые требуют специальной обработки на стороне потребителя. Это приводит к запутанности в данных, а также куче дополнительной лапши в коде у потребителей
5. Strongly type your data columns - автор призывает думать про типы данных и использовать их. Это позволяет получать более качественные данные в хранилище + сами движки хранения эффективнее работают если нам не нужно непрерывно кастовать данные между типами (что, кстати, тоже является протекающей абстракцией)
-> Quality & Validation - факторы, относящиеся к качеству данных и валидации
6. Architect for regression testability - наше решение должно быть спроектировано с учетом потребности в регрессионном тестировании отгружаемых данных, что является пререквизитом для CD (continuous delivery)
7. Track changes in your test data - автор рекомендуют хранить лог изменений, который применялись к тестовым данным, а также применять их консистентно между средами
-> Audit & Explainability
8. Mind your metadata: Data-Cataloguing - автор рассказывает про каталогизирование данных, что позволяет управлять метаданными. Мельком он упоминает OpenMetadata и Apache Atlas
9. Mind your metadata: Code Traceability - автор рекомендует организовать трассировку от данных к коду, системам, людям, которые их сгенерировали. Это позволяет понять происхождение данных, что может быть полезно при траблшутинге и не только
-> Consumption
10. Defined APIs for accessing data - автор рекомендует специфицировать API, отделить внутреннюю модель данных от внешней и никогда-никогда не открывать доступ к вашему внутреннему хранилищу (избегайте интергаций через шаренную базу данных)
11. Defined SLAs (& SLOs) for data - у API должен быть определен уровень обслуживания и ожидания для потребителей
12. Treat data as a product - данные надо воспринимать как продукт. А дальше стоит думать про потребителей продукта, их потребности, сценарии использования, ... В итоге данные начинают работать и организация становится data-driven.

#Data #DataOps #Databases #Software #Engineering #Management #Processes #Devops

Software development engineers в tech компаниях

Вчера я выступал на конференции "IT PurpleConf" с докладом для студентов про современные ожидания от software development engineers в технологических компаниях. Само выступление в виде трансляции будет еще не скоро, поэтому я ближе к ночи записал выпуск подкаста и выложил на свой youtube канал TellMeAboutTech:) Подробнее про темы выступления во вчерашнем посте и там же есть список рекомендованных материалов.

#Management #Software #Processes #Project #ProductManagement #Engineering #Processes #Leadership #Staff #Architecture #Career