Designing Distributed Systems

Автор книги является сооснователем kubernetes, поэтому его опыт в проектировании распределенных систем является довольно актуальным:) Книга мне показалось хорошей, но одновременно слишком простой. Но за счет этого она отлично подойдет новичкам вступающим на запутанную дорожку distributed systems:)

Книга состоит из 3х частей:
- одноузловые паттерны проектирования
- паттерны проектирования обслуживающих систем
- паттерны проектирования систем пакетных вычислений

Все паттерны даются в контексте контейнеров и их оркестрации, книга содержит практические примеры, для реализации которых используется инсталляция kubernetes и его примитивы, такие как pods, deployments, services, etc. Ближе к концу книги вы попробуете использовать helm для разворачивания etcd, kafka и иже с ним.

В первой части рассматриваются паттерны:
- sidecar: для https, динамической конфигурации и метрик
- ambassador: для использования шардированного сервиса и для сплита трафика для тестирования разных версий
- adapters: мониторинг, журналирование

Во второй части рассматриваются:
- репликация: для stateless сервсиов, sticky sessions, кеширование, …
- шардирование: консистентный хеш, шардирование реплицированных сервисов, …
- scatter-gather: распределенный поиск по документам
- FaaS и events: преимущества и недостатки FaaS, реализация декораторов на функциях
- ownership election: локи для распределенных систем

В третьей части рассматриваются паттерны проектирования систем пакетных вычислений:
- системы на основе очередей задач
- событийно-ориентированная пакетная обработка
- координированная пакетная обработка

#DistributedSystems #Architecture #SoftwareArchitecture #SystemDesign #Software #SoftwareDevelopment

Сегодня вечером в 18:00 по Мск будет шестой выпуск клуба "Code of Architecture" по книге "Распределенные системы" ван Стина и Таненбаума, в котором мы обсуждаем главу про именование. Предыдущие выпуски были посвящены общему обзору книги, обсуждению архитектуры, процессов, коммуникаций, координации, а теперь мы дошли до обсуждения следующих важных вопросов
 - Зачем нужны имена, идентификаторы и адреса
 - Что такое плоское именование (flat naming). Здесь в качестве примеров рассмотрим Distributed Hash Tables
 - Что такое структурированное именование (structured naming). Здесь в качестве примеров рассмотрим работу DNS и Unix FileSystems
 - Что такое основанное на атрибутах именование (attribute-based naming). Здесь вспомним про LDAP
 - Что такое named-data networking

Встречаемся на ютуб-канале IT's Tinkoff.

#SoftwareArchitecture #DistributedSystems #Architecture #SystemDesign #Software #CoA

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

Chaos Engineering. Building Confidence in System Behavior through Experiments

Эту книгу я прочитал лет 5 назад и мне она понравилась: отличная обложка и очень здравый и взвешенный подход для работы с комплексными системами

Книга начинается с главы "Зачем заниматься инженерией хаоса" и ее достаточно для того, чтобы определиться стоит ли читать книгу дальше. В первом абзаце авторы рассказывают о том, что Chaos Engineering используется для эмпирического исслледования поведения систем при помощи экспериментов. Чем-то этот подход напоминает мне лабораторные работы по физике/химии в университетские времена:) Основная цель эксперииментов узнать о потенциальных слабостях системы заблоговременно, а не в момент, когда они приводят к реальным проблемам. Хаос иненерия кардинально отличается от тестирования системы, т.к. в тестировании есть специфичные условия и ожидается специфичное поведение, тесты обычно имеют бинарную природу. В итоге, тесты не дают нам новой информации о системе.

В свою очередь, хаос инженерия в свою очередь при помощи экспериментов поззволяет нам лучше понять систему и узнать об особенностях ее функционирования.
В этой же главе рассказывается о пререквизитах для Chaos Engineering: для определения степени готовности вашей организации к использованию Chaos Engineering вам требуется ответить на 1 вопрос:"Достаточно ли устойчива ваша система к событиям реального мира, например, отказам сервисов или пикам сетевых задержек (network latency)".
Если ответ "нет", то до вы знаете что вам стоит сделать до того, как изучать данную книгу:) Думаю, что большая часть читающих книгу отсеивается на данных пререквизитах:)
Но представим, что мы ответил "Да" - в этом случае вы попадаете в прекрасный мир chaos engineering, который помогает контролировать сложность систем и спать спокойно:)
Если тема вас заинтересовала, то предлагаю вам самим ознакомиться с этой книгой:)

#Chaos #Engineering #SystemEngineering #SystemDesign #SoftwareArchitecture #Software #SoftwareDevelopment

Agile Patterns

В свое время читал перечень этих паттернов в карточке с DZone, плюс есть сайт agilepatterns.org

Если кратко, в первой половине статьи с DZone автор выделяет шаблоны, которые помогают организовывать разработку по agile. Про них все всегда рассказывают и поэтому я не буду их здесь перечислять. А вот на последних страницах автор рассказывает об антипаттернах, которые могут пох...рить всю нашу работу по выстраиванию процессов:)
Среди таких антипаттернов присутствуют
- Cherry Picking - выбор членами команды самых "вкусных" задач из беклога вместо самых приоритетных
- Death March - продолжение проекта, который уже не нужен, но на который потратили много сил и его жалко закрыть
- Disguised Project - проект, который заказчик пытается пропихнуть как рутинные задачи
- Micromanagement - ну тут все ясно:)
- Unbounded Timebox - неопределенные границы для завершения проекта
- Undefined Done - ху..к-х..к и в продакшен:) и куча техдолга на выходе
- Unlimited WIP - неограниченный объем задач в работе
- Unresolved Proxy - много заказчиков без одного ответственного за продукт
- Waterscrumfall - гибрид из waterfall и scrum, признан нежизнеспособным в открытой природе:)

В общем, хорошая статья и читается легко:)

#Management #Processes #Scrum #Kanban #Agile

От основ к созданию роботов

Лет 5 назад я купил эту книгу для обучения сына премудростям создания роботов. Я ее конечно прочитал, но воплотить план обучения в жизнь не получилось, но это не проблема книги, которая отлично написана и оформлена иллюстрациями. Её приятно даже просто пролистать.Если переходить к сути книги, то авторам удалось весело и с простыми практическими занятиями раскрыть заявленную в названии тему:)
В первых главах были описаны разнообразные роботы и дана качественная характеристика, отличающая робота от радиоуправляемой игрушки:)
Дальше авторы рассказали о:
- программировании алгоритма работы робота
- булевой логике
- датчиках как органах чувств роботов
- беспроводной связи
- adruino и управления моторами при помощи ШМИ
В общем, книга действительно интересная и подходит для практических занятий робототехникой с сыном:)

#Robotics #ForKids #SoftwareDevelopment #Engineering

Software Engineering для Финтех Школы

Мы в компании уделяем достаточно много сил и времени обучению. Мы учим как сотрудинков внутри, так и будущих сотрудников, начиная со школьной скамьи и продолжая в университете. В этом году мне надо было записать для Финтех Школы лекцию про облачные вычисления и я решил посмотреть как мои коллеги рассказывали о Software Engineering в предыдущих циклах обучения. Так я наткнулся на доклад Игоря Маслова, директора базовых технологий, который он читал для студентов в 21 году. Доклад мне понравился тем, как Игорь разбирает эволюцию подходов в разработке софта и демонстрирует, что это очень динамичная сфера, в которой подходы постоянно развиваются и то, что было нормой еще 10 лет назад может к текущему моменту безвозвратно устареть. Ну и из этого обзора видно, что наша молодая дисциплина идет от ремесленного к инженерному подходу, обрастая практиками, которые позволяют обеспечить повторяемый результат хорошего качества.

P.S.
Подробнее про наши образовательные программы можно прочитать на сайте https://fintech.tinkoff.ru/

#SoftwareDevelopment #Software #Engineering #SystemEngineering #Processes

В этот понедельник мы провели шестой стрим клуба Code of Architecture по книге “Distributed Systems”, в котором мы обсудили вопросы именования. А точнее мы поговорили про
- адреса, идентификаторы и имена
- плоское именование, влючая распределенные хеш таблицы и consistent hashing
- структурное именование, включая unix filesystem и DNS
- attribute-based naming, включая триплеты RDF из семантического веба и LDAP как комбинацию структурного и attribute-based подхода
- name-data networking, экспериментальный подход, который хочет занять место протокола IP в современном интернете

Гостем стрима был
- Алексей Квак, руководитель разработки из Тинькофф

Артефакты с этого стрима доступны по ссылкам
- Статья с кратким обзором
- Запись стрима
- Miro доска с презентацией

#SoftwareArchitecture #DistributedSystems #Architecture #SystemDesign #Software #CoA

Writing an engineering strategy

Интересная статья про инженерную стратегию от Will Larson, автора книг An Elegant Puzzle (про engineering management, я про нее как-то рассказывал) и Staff Engineer (про высокоуровневых SDE, у меня есть обзор этой книги в двух частях: 1, 2).
В этой статье автор рассказывает про то, как писать engineering strategy, являясь engineering executive, используя структуру которую предложил Richard Rumelt в книге "Good Strategy, Bad Strategy". В этой структуре 3 составляющих:
1. Diagnosis - объяснение в чем вызов и корневая проблема, которую мы решаем
2. Guiding policies - подходы, которым стоит следовать для решения вызовов. Эти руководящие policies могут быть как явными, так и неявными компромиссами (tradeoffs) между вариантами действий.
3. Coherent actions - набор действий, которые направляются принципами для решения challenge. Эта самая важная часть стратегии.

Дальше автор рассказывает про
- Процесс написания
- Когда ее стоит писать
- Что делать с отсутствующими бизнесовой и продуктовой стратегией, которые должны учитываться в инженерной стратегии
- Как структурировать руководящие принципы
- Как поддерживать нужный уровень руководящих принципов
- Как сформировать перечень конкретных действий
- Почему стратегия - это про top-down approach
- И как начать писать стратегию

#Strategy #Engineering #Management #Leadership #Process #SystemEngineering

Руководитель разработки медиапроектов Тинькофф

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

Интересно, что само направление медиа для меня не чужое, так как еще до Tinkoff я успел принять участие в разработке медиа-проектов, будучи руководителем команд разработки в Woman.ru и Banki.ru. А в первый день выхода на работу в Тинькофф я познакомился с первым программистом Тинькофф Журнала (Т—Ж), так как мы одновременно устраивались на работу. Дальше я никогда напрямую не отвечал за Т—Ж, но часто помогал с консультациями и выделением времени инженеров из моих команд. Но теперь настало время платформизировать Т—Ж и сделать его основой всех наших медиа.

В итоге, я ищу опытного руководителя, который возьмёт на себя роль технического директора медиапроектов Тинькофф: он возглавит команду отдел из 40 инженеровспециалистов, запустит новые направления и выстроит процессы. Сейчас в разработку медиапроектов входит три больших продукта:
- Журнал
- Помощь
- Бизнес-секреты
- Помимо этого есть и другие продукты поменьше: образовательные Учебник и Школа бизнеса, блоги продуктов, платформа для медиа. Продукты представлены в вебе и мобильных приложениях. Всё это поддерживают и развивают семь продуктовых команд и две сервисные. Продуктовые команды кросс-функциональные, в их состав кроме технарей входят продакты, дизайнеры, редакторы и другие специалисты. Сервисные команды — тестирование и инфраструктура.

В планы медиапроектов на 5 лет входит
— Создать большое сообщество, где пользователям будет легко создавать и загружать контент в разных форматах: видео, изображения, длинные и короткие статьи, а модераторам — проверять его
— Прокачать админку, чтобы редакторы сами выпускали статьи и публиковали другой контент без участия специально обученных верстальщиков.
Помимо этого надо будет
— Разработать собственную CMS на основе текущих наработок Т—Ж, чтобы запустить новые контентные проекты и пересадить на неё существующие.
— Запустить и поддержать 10 новых контент-проектов. Сделать всё так, чтобы каждый проект не был ограничен возможностями платформы, а мог по необходимости расширяться собственной функциональностью.

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

В моих глазах идеальный кандидат:
— Несколько лет руководил отделом или командой разработки больше 30 человек.
— Работал в крупной продуктовой компании. В идеале, ещё и успел поработать в медиа.
— Умеет оптимизировать процессы: ускорять релизы, повышать пропускную способность команды.
— Имеет широкий технический и архитектурный кругозор. Знаком с концепцией микрофронтендов, эволюционного дизайна, монолитов, сервисов, микросервисов, чистых функций и вот этого всего. В идеале, уже однажды спроектировал и воплотил переход технического решения из продуктового в платформенное.
— Знаком с большей частью стэка команды: React, React Native, FastAPI, Postgres, Redis, Docker, Kubernetes.
— Умеет планировать на разные горизонты: от спринта до нескольких лет. Способен синхронизировать эти планы между бизнесом и технарями. Различает роадмапы и бэклоги, CJM и user story.

P.S.
Если вы считаете, что подходите на эту позицию, то пишите мне в личку.

#Vacancy #Engineering #Management #Leadership