Архитектуры на акторах: простые системы

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті.

Архитектуры на акторах:
Вступление (Actors / Objects; Complexity; When to Distribute; Kinds of Actors)
Монолиты (Control/Data Flow; Reactor / Proactor / Half-Sync/Half-Async; Request State)
Простые системы (Notation for Diagrams; Sharding; Layers; Services / Pipeline)
Системы с моделью (Hexagonal / MVC; Blackboard / Message Bus; Microkernel / Plug-ins)
Фрагментированные системы (Mesh; SOA; Hierarchy; Design Space)

                                     What is not remembered never existed
                                                             (S. E. Lain)

В прошлой части посмотрели обработку событий внутри актора. Сейчас пробуем сложить несколько акторов вместе (или разрезать один актор на куски).

Нотация

Мы будем рисовать структурные диаграммы (какие компоненты существуют и как общаются в рантайме). По вертикали откладываем приближение логики к высокоуровневым бизнес-задачам (например, сверху — пользовательский код на Питоне, снизу — драйвера на ассемблере и железо), по горизонтали — доменные компоненты (например, для ОСи на разных частях оси х будут отображены диск, сеть, видяшка и звуковуха — в произвольном порядке), третье измерение — стопки шардов (одинаковых модулей). При этом иногда разбивку по горизонтали придется менять — например, на уровне ОС у нас будет разбивка по физический устройствам, а на верхнем уровне логики — по доменным сущностям. Горизонталь одна, а распределений нужно показать несколько.

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

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

Мы не ограничиваемся строго акторами — иногда есть смысл ослабить модель, чтобы включить в рассмотрение похожие системы с синхронными взаимодействиями, если у них сильно выражена модульность. Тем более, что RPC, блокирующий у вызывающей стороны, реактивно обрабатывается принимающей стороной. То есть, для принимающей — является сообщением, а сама принимающая сторона вдруг оказывается актором, питающимся входящими событиями.

Шардинг

Нарезка одинаковыми частями (как у батона), между кусочками ничего нет — они не общаются. Поднимаем несколько одинаковых монолитов (инстансов, шардов), на которые раздаются запросы.

Почему сложно делать общение между шардами? Из-за конкурентного доступа к данным. На рисунке видно петлю, когда нулевой шард пытается что-то изменить в первом. Если первый в это же время начнет менять данные в нулевом — мы наступим на хвост САР теореме [DDIA]. Получаем распределенный race condition, а их лучше обходить стороной. Проблема возникает большей частью, когда в control- / data- flow есть петли или противонаправленные потоки (условие дедлока). Если мы хотим относительно легко создать систему, которую можно будет годами развивать — грабли надо обходить десятой дорогой. Race conditions — как раз грабли.

А вот если мы движемся по системе в одном направлении (Pipeline [POSA1]) — ок, здесь нет конкурентных обновлений, приносящих данные из будущего. Если мы храним данные вместе (Layers [POSA1]), и временами дергаем периферию чтобы у нее что-то выяснить — тоже норм, хоть и не супер быстро работает. Раз мы владеем всеми данными, то можем их защитить, или все сразу обновить. Консистентность состояния системы и снепшотов не страдает.

Конечно, идеальный случай — когда вообще ничего делать не надо. Зеленые стрелочки на картинках приближаются к идеалу — мы быстро обрабатываем событие, потому что можем (сами знаем, как правильно, и никого не нужно спрашивать).

Плюсы (кроме указанных для монолита):

  • Можно масштабироваться до безобразия — сколько нагрузки, столько инстансов программы подняли. Если, конечно, она быстро поднимается. Ну или склонировали снепшот виртуалки.
  • Можно позволить себе делать синхронные вызовы, что упростит код. В таком варианте (Reactor [POSA1]) каждый актор (процесс) обрабатывает один запрос от начала до конца — не проблема, так как акторов плодим сколько хотим.
  • Отказоустойчивость — падение одного инстанса ничему не повредит. При условии, что его уронил не воспроизводимый баг в коде, и что мы не перепосылаем тот же запрос по кругу (как достойный метод положить все, что шевелится).
  • Возможность канареечного деплоя — можно поднять один инстанс новой версии, оставить на день работать, и если не упадет и выдает правильные результаты — обновить остальные инстансы.

Минусы (кроме указанных для монолита):

  • Неудобно шарить данные между шардами. Обычно шарды вообще не знают друг о друге (но смотрим ниже исключение — Leader/Followers). Не проблема для stateless шардов.
  • Кто-то должен распределять шардам запросы. Вот он может навернуть все всерьез и надолго (единая точка отказа, но тоже смотрим ниже).
  • Требует дополнительных усилий по администрированию (поднять и настроить шарды).

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

Общие названия: Instances.

Классика: Pooling [POSA3].

Бэкенд: Sharding, CGI/fCGI, FaaS.

Архитектура сходна с многопоточным реактором, только вместо потоков — независимые акторы (сервисы). Собственно, это различие и обусловило перечисленные плюсы и минусы.

В литературе описаны три варианта того, как распределяется работа между инстансами (но на самом деле нет):

Создание по запросу (эластичные инстансы)

Мы подозреваем, что инстансов будет много, но не знаем, сколько (инстанс обслуживает одного пользователя в многопользовательской системе). Или есть возможность размещать инстанс на пользовательском устройстве. В результате, шарды создаются при установлении соединения с пользователем, и удаляются при завершении соединения.

Примеры: фронтенд, объекты звонков на сервере телефонии, прокси для пользователей в мультиплеере. А также — наш реактор на корутинах, рассмотренный в прошлый раз (корутины как инстансы). Многопоточный stateless реактор тоже можно отнести сюда, считая инстансами акторов сами потоки — как обычно с архитектурой, все выворачивается любым удобным образом.

Leader / Followers [POSA2] (самоуправляемые инстансы)

Инстансы заранее подняты и объединены в список. Один инстанс (Leader) ждет, пока из сокета выпадет какашка. Другие инстансы ждут пинка. Когда какашка выпадает, лидер дает пинка следующему инстансу, и начинает обрабатывать свой запрос. Следующий инстанс, получивший пинка, садится на сокет ждать какашку, становясь лидером. Когда любой инстанс закончил со своим запросом — он становится в конец очереди на достижение лидерства.

Типа, круто, но не масштабируется на несколько серверов. Если проблемы в железе — бекенд мертв.

Load Balancer aka Dispatcher [POSA1] (внешнее распределение задач)

Кто-то внешний (nginx) распределяет запросы между заранее созданными инстансами. Все хорошо, можно раскидать инстансы по разным серверам. Но оно хорошо только до тех пор, пока живой балансировщик.

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

Смеси

И тут не обошлось без комбинаций.

  1. Load Balancer распределяет запросы между серверами, на каждом из которых бежит система Leader/Followers. Позволяет полностью загрузить несколько серверов.
  2. Все инстансы на сервере ждут на одном объекте операционной системы или фреймворка. Когда приходит сообщение, оно достается только одному из них. В этом случае Load Balancer спрятан где-то в кишках фреймворка или ОС.

Слои

Нарезка на коржи, между ними — мягкий коричневый крем (асинхронный интерфейс). Режем монолит по высокоуровневости кода. Верхний слой командует солдатиками, нижний — отрисовывает их движения.

Плюсы:

  • Не теряется связность на каждом уровне абстракции: один солдатик может синхронно говорить с другим. Довольно простой дебаг в рамках одного уровня.
  • Отвязка высокоуровневого кода от низкоуровневого по логике: ИИ для солдатика пофиг, как его будут рендерить. И зависимость от рендерера (теоретически) не может протечь через асинхронный интерфейс в слой ИИ, с которым нет общих данных. Код стал понятнее (в идеальном мире).
  • Отвязка высокоуровневой и низкоуровневой частей по свойствам (силам): солдатик может секунду размышлять над планом действий, а рендерер отрисовывает картинку каждые 15 мс.
  • Параллельное выполнение всех частей (когда хватает ядер проца).
  • Слои можно по-разному шардить, если на один из них больше нагрузка, и он не имеет значимого для логики системы состояния.
  • Слои можно деплоить по-отдельности, если постараться (обновления в ОС как реальный пример).
  • Более простая и быстрая обработка событий, затрагивающих только один слой: рендерер рендерит последнее, что прислали, не обращаясь напрямую к полной модели мира и к солдатикам.

Минусы:

  • Очень плохо описывать и отлаживать сценарии, у которых логика или данные размазаны между слоями.
  • Теряется скорость реакции или передачи данных по вертикали (когда для правильной реакции на событие нужно вовлечь несколько слоев).
  • При росте проекта какой-то (вероятно — верхний) слой все равно станет слишком жирным — от роста сложности слои надолго не спасут.

Итого: имеем довольно дешевое «разделение труда» с энкапсуляцией для случаев, когда код может быть запутан на каждом уровне абстракции, но сами уровни относительно независимы (как логика игры и рендерер). Используется повсеместно (идея — простая, накосячить — сложно).

Общие названия: Layers [POSA1].

Бэкенд: n-Tier.

И снова есть пара вариантов, хотя вторые неочевидны):

Многоуровневая система

Обычно под слоистой системой понимают разбиение по уровню абстракции бизнес-логики. Например, для 3-tier у нас наиболее «человечным» будет фронт-энд с удобовразумительными кнопочками и читаемыми ползунками, и без всяких математических формул или сложных деревьев решений. Бек-энд уже с формулами и полотнами if...elseif...else, но старается как-то орудовать понятиями бизнес-домена [DDD]. Еще глубже лежит Data Layer с индексами и таблицами, структуру которых решает производительность и размер, а не читаемость, здравый смысл или документы с требованиями. При этом каждый слой будет написан на своем языке: который лучше подходит для данной задачи (в идеале), или который хотят попробовать программисты (если они понимают, что делают), или который хоть кто-то думает, что знает (в оставшихся случаях). Разделение языков (и имплементации в целом) достигается тем, что интерфейсы между слоями описаны в языконезависимой форме (HTTP и SQL для нашего 3-tier случая). Подобным образом (документированный бинарный интерфейс) отделяется рантайм операционной системы от ядра и от программ пользователя — еще один случай разбиения на слои.

Благодаря четким интерфейсам данная архитектура одинаково хорошо работает для объектов и акторов, и позволяет их смешивать: например, фронтенд и бэкенд могут общаться не блокируясь (как акторы), а обращение бек-энда к базе будет блокироваться (RPC как у объектов). Или наоборот.

Та же 3-tier система использует два варианта шардинга: эластичное создание шардов на фронтэнде, балансировщик с пулом инстансов на бекенде, и один экземпляр data layer.

На картинке мы пропустили load balancer так как он маленький (не несет особой бизнес-логики) и непонятно, куда его пихнуть: над бэкендом чтобы проще рисовать стрелочки, или в самый низ как слой без бизнес-логики. В дальнейшем также будем опускать детали — иначе в диаграммах нереально разбираться. Too much information is no information.

Собственно с акторами слои используются в эмбеддеде для разделения на «головной мозг» и «спинной мозг» (часто даже с разнесением на разные процессоры). Головной мозг отвечает за целеполагание, спинной — управляет железом. Или на MMI (общение с пользователем), SDK (логика среднего уровня) и FW (железозависимый код).

Пул обработчиков

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

  • Могут сразу занять все свободные ядра процессора
  • Могут бежать с более низким приоритетом, не мешая основному потоку
  • Делают работу параллельно до победного конца, и асинхронно сообщают о результате вычислений
  • Берутся за любую работу, не обладая собственным статическим состоянием или логикой

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

Пул навыворот

Мы уже рассмотрели корутины в разделе реакторов, но на самом деле (с одной из возможных точек зрения при одном из возможных уровней детализации) реактор на корутинах принадлежит к слоистым системам (на что указывает классическое название архитектуры: Half-Sync/Half-Async [POSA2]). Она позаимствована из операционных систем, где Sync layer — это пользовательские процессы, создаваемые юзером по желанию, а Async layer — само ядро ОС со стабильными структурой и потреблением ресурсов.

Бекенд с Load Balancer из шардинга (выше в тексте) — тоже пул навыворот: маленький низкоуровневый кусочек может по надобности создавать и уничтожать компонеты (CGI), содержащие всю бизнес-логику системы, и распределяет нагрузку между уже существующими шардами.

Еще схема напоминает движок оркестраторов [MP], но это — уже отклонение от нашей темы.

Сервисы

Нарезка кусочками (порционный торт), переложенными грязной бумагой (асинхронный интерфейс). Разрезали монолит по границам между субдоменами в надежде, что сценарии обычно крутятся внутри одного субдомена и редко перепрыгивают между субдоменами.

Плюсы:

  • Есть шанс в несколько раз уменьшить сложность кода на проекте — если кусков получится с десяток.
  • Удобно писать и отлаживать код внутри субдомена, даже когда высокоуровневая логика мешается с низкоуровневой.
  • Отвязка субдоменов по логике (модульность); зависимостям тяжело пересекать асинхронный интерфейс.
  • Субдомены отвязаны по свойствам: в одном можно имплементить реал-тайм сценарии, в другом — медленные.
  • Параллельное выполнение кода во всех субдоменах.
  • Возможность шардить субдомены независимо, если на них разная нагрузка и нет связки по состоянию.
  • Возможность деплоить код для субдоменов независимо.
  • Быстро работают сценарии, не пересекающие границу между субдоменами.

Минусы:

  • Очень плохо описывать и отлаживать сценарии, у которых логика или данные размазаны между субдоменами.
  • Если несколько сервисов зависят от одних данных, может потребоваться хранить и синхронизировать копии таких данных в каждом сервисе.
  • Теряется скорость реакции или передачи данных по горизонтали (когда в обработку события или информации вовлечены несколько сервисов).
  • Требуются усилия по администрированию сервисов и инфраструктуры.

Итого: позитивно, если в процессе обработки данных или событий можно выделить относительно независимые блоки. Иначе — возрастание сложности (и тормознутости) сценариев из-за асинхронных интерфейсов сможет окупиться только при очень большом и запутанном проекте — когда без хоть какого-то разделения разработка просто остановилась по причине размера и сложности кода, а разбивка на модули не помогает (Monolith Hell [MP]).

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

Классика: Actors (telecom), Pipes and Filters [POSA1].

Бэкенд: Microservices [MP], Pipelines [DDIA].

Как обычно, варианты:

Акторы / Микросервисы (разделение по доменным областям)

Если наш домен делится на несколько субдоменов, мы можем хотеть надеяться, что бизнес-логика внутри каждого субдомена более связна, чем между субдоменами. То есть, бухгалтерии не надо знать, что творится внутри ХР — им достаточно уметь спросить должность, дату выхода на работу, и дату увольнения. Код каждого субдомена / сервиса не зависит от других, может разрабатываться отдельной командой и жить в своем репозитории. Запросы внутри субдомена (увольнение сотрудника из-за performance review у ХР, или TCP пакет с данными у сетевого драйвера) могут обрабатываться очень быстро и эффективно, пока они не требуют сложного взаимодействия с другими субдоменами (акторами). Например, ХР может сообщить бухгалтерии, что сотрудника уволили. Это простое взаимодействие: fire and forget, результат события никак изменить нельзя, обратной связи никто не ждет. А вот если у ХР появляется метрика, по которой нужно повысить зарплату не более чем 10% программистов, и при этом не выйти за бюджет $5000/mo, то начинается сложный обмен бумагами с бухгалтерией (ХР не помнит все зарплаты), причем оба отдела в это время заняты более важными делами, и в результате все так запутается и затянется, что зарплату никому не повысят. Такое взаимодействие слишком сложное для данной модели (независимые отделы).

Доменные акторы/микросервисы могут использоваться как для data flow (энтерпрайз) так и для control flow (телеком). Они идеальны, когда большинство сценариев обработки данных/событий решаются локально в пределах субдомена, чуть хуже — когда нужно еще рассылать нотификации соседям. В принципе, можно переправлять сообщение по цепочке кому-то умному.

А вот когда нам для какого-либо решения нужно собрать информацию от нескольких сервисов — начинается трэш, угар, и вьюшки [DDIA] с оркестраторами и хореографией [MP] (потому что все общение асинхронно, и пока мы готовим бумаги, чтобы уволить сотрудника за несоответствие политике партии, он сам находит новую работу с повышением. И что теперь делать с бумагами?). Дебажить такую систему нереально — каждый актор живет своим потоком, и сценарий будет состоять из кучи кусков, запускающихся в разных местах в разное время, а возможно — даже из разных репозиториев. А еще — распределенные сценарии будут адово тормозить. Если честно, умные люди называют такой случай «распределенный монолит» [MP] и рекомендуют вначале сделать и довести до ума обычный монолит [MP], потом — посмотреть, где в реальности проходят границы между субдоменами, и какие из них реально (а не в нашем представлении исходя из документации) мало взаимодействуют друг с другом [DDD], и только затем — резать этот монолит на микросервисы вот по вот этим вот самым местам слабой связности [MP].

Pipeline (pipes and filters)

Частный случай предыдущей системы, узкоспециализированный, но очень распространенный. Если у обычных доменных акторов ((микро-)сервисов) возможны взаимодействия всех со всеми, то пайплайн относительно линейный: каждый актор (их здесь любят называть «фильтры») получает из входящей трубы пакет данных, обрабатывает как хочет, и нотифицирует переработанным пакетом следующий фильтр (отправляет обработанные данные в исходящую трубу). Данные текут в одном направлении. Фильтры стараются делать простыми и отвечающими за один определенный логический шаг. Их можно независимо разрабатывать, деплоить, отлаживать, улучшать [DDIA]. Можно записать данные, которые проходили когда-то в пайплайне, а потом их скармливать разным пробным версиям одного фильтра, и сравнивать результаты и скорость обработки [DDIA]. Иногда пайплайн может ветвиться, крайне редко — менять форму в рантайме. Сам пайплайн обычно собирается фабрикой на старте, вероятно — исходя из конфиг файла.

Так как у фильтров одинаковый интерфейс (может отличаться тип данных), и они вообще ничего не знают друг о друге — то они полностью независимы (недостижимый идеал микросервисов).

Исключительно data flow вариант. Но если он подходит под требования — часто можно дальше не сильно думать. Кроме случаев, когда важна скорость ответа (приборы ночного зрения, очки виртуальной реальности, роботехника), а не пропускная способность.

Плюсы:

  • исключительная простота разработки и поддержки.
  • фильтры работают параллельно, загружая все свободные ядра процессора.

Минусы:

  • нужно отслеживать, чтобы ни на каком этапе не скопилось слишком много данных, если один из фильтров тормозит. То есть — появляется потребность в обратной связи. В результате моська превратится в слона, если задача была слишком сложной для решения «в лоб» через pipeline.
  • возможно избыточное копирование данных, и каждый пакет данных в каждый момент обрабатывается только одним ядром проца. Значит — монолит быстрее проработает каждый конкретный пакет, особенно если там применили service thread pool и разбивку пакета на части для вычислений на всех ядрах одновременно. С другой стороны — пайплайн эффективно распределяет нагрузку по доступному железу вообще без усилий или синхронизации в коде.

Если фильтры обрабатывают данные с разной скоростью, и данных много — нужен фидбек (congestion control), чтобы не насыпать в трубу настолько много отходов, что она захлебнется от недостатка памяти для хранения скопившихся промежуточных данных. Для этого можно дать фильтрам возможность отсылать в обратном направлении подтверждение на каждый пакет, или сообщения о том, сколько в очереди лежит пакетов, или номер пакета, который сейчас в работе. Получится интересная система, у которой пакеты данных (data flow) и пакеты управления (control flow) бегут в противоположных направлениях. Либо можно добавить надзирателя, собирающего статистику и устанавливающего скорость или качество / битрейт (звук, картинки, видео) входящего потока. Либо можно логику контроля скорости зашить в трубы.

Сравнение с пространством масштабирования

В литературе [MP] встречается scale cube как координаты масштабирования систем по производительности:

  1. Клонирование монолита (у нас — шардинг бекенда)
  2. Разделение по функциональности (микросервисы)
  3. Data partitioning (у нас — шардинг data layer)

Наши измерения эволюционирования (evolvability) систем как уменьшение связности:

  1. Разделение по уровню абстракции логики
  2. Разделение по субдоменам
  3. Шардинг

Если сравнить, то два наших измерения (по абстрактности и по субдоменам) соответствуют одному в data cube (по функциональности), а два из data cube (cloning, partitioning) — одному нашему (шардинг).

Кабанчик [DDIA] приводит 2 измерения масштабирования: scaling up (увеличение мощности процессора, рамы и диска) vs scaling out (распределение данных по нескольким машинам).

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

Итого:

Мы научились превращать шарлотку в:

  • нарезной батон (шардинг),
  • слоеный пирог,
  • тортик (сервисы) или
  • сосиски (пайплайн).

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

Если предложите примеры хорошо описанных в интернете систем (когда понятно, как оно работает, и какие там есть модули / сервисы), — попробую их проанализировать в пятой части.

Литература

[DDD] Domain-Driven Design: Tackling Complexity in the Heart of Software. Eric Evans. Addison-Wesley (2003).

[DDIA] Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems. Martin Kleppmann. O’Reilly Media, Inc. (2017).

[EIP] Enterprise Integration Patterns. Gregor Hohpe and Bobby Woolf. Addison-Wesley (2003).

[MP] Microservices Patterns: With Examples in Java. Chris Richardson. Manning Publications (2018).

[POSA1] Pattern-Oriented Software Architecture Volume 1: A System of Patterns. Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad and Michael Stal. John Wiley & Sons, Inc. (1996).

[POSA2] Pattern-Oriented Software Architecture Volume 2: Patterns for Concurrent and Networked Objects. Douglas C. Schmidt, Michael Stal, Hans Rohnert, Frank Buschmann. John Wiley & Sons, Inc. (2000).

[POSA3] Pattern-Oriented Software Architecture Volume 3: Patterns for Resource Management. Michael Kircher, Prashant Jain. John Wiley & Sons, Inc. (2004).

Архитектуры на акторах:
Вступление (Actors / Objects; Complexity; When to Distribute; Kinds of Actors)
Монолиты (Control/Data Flow; Reactor / Proactor / Half-Sync/Half-Async; Request State)
Простые системы (Notation for Diagrams; Sharding; Layers; Services / Pipeline)
Системы с моделью (Hexagonal / MVC; Blackboard / Message Bus; Microkernel / Plug-ins)
Фрагментированные системы (Mesh; SOA; Hierarchy; Design Space)

👍ПодобаєтьсяСподобалось18
До обраногоВ обраному17
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Pipeline (pipes and filters)

Сейчас осваиваюсь в новом проекте с таким подходом
При этом:
каждый «фильтр»: конектор, мапер, фильтр, и т.п. — реализуется AWS лямбдой
Pipeline описывается конфигом. Поэтому фильтры могут учавствовать в разных видах пайплайнов, и в общем случае — в произвольном порядке и количестве их типов.
И для каждого пользователя запускаются свои лямбды, чтобы:
— ни на каком этапе не скопилось слишком много данных
если и случится — пострадает только обработка этого конкретного входящего запроса

Конечно, есть ядро-оркестратор, которое собственно связывает по сценарию «фильтры» и запускает их, прокидывая ответы на входы следующему и запуская еще запуск фильтра (аля паджинация у фильтра)
и конечно все логируется, мониторится, и сами «фильтры» имеют состояние по уникальности сценарий-пользователь-запрос-«порция работы в процессе/уже полностью закончил» чтобы не выедать память, и не стопориться на больших объемах, «паджинация»

Обратной связи нет

Правда, и сама задача — ложится на такой подход.

Тут надо предохранители, чтобы лямбды не выели за день годовой бюджет)

с клаудами всегда так

или плати им
или решай эти задачи самостоятельно, «кубернетесом на Hetzner»

что выгоднее — считать надо... и не забыть про время разработки и саппорта

ну то есть помнить классику о 3ех практически НЕвзаимозаменяемых ресурсах:
люди, время, деньги

и не забыть про время разработк и саппорта

правильно, которое у облаков также имеется и совсем немалое
чтобы правильно собрать к примеру компоненты облаков да так, чтобы не вынести у заказчика весь бюджет на и-ру ... нужен очень квалиф. персонал
равно как и затраты на решение ряда спец. для облаков проблем — к примеру известные проблемы с балансировщиками у AWS или шумные соседи и так далее
«взула и забула» работает в очень ограниченных условиях

нужен очень квалиф. персонал

ну да.
потому и «джуны никому не нужны». не только в клаудных проектах :)

равно как и затраты на решение ряда спец. для облаков проблем — к примеру известные проблемы с балансировщиками у AWS

проблемы с балансировщиками будут и с лично написанными :)

считать надо...

коллеги, о которых говорят — «тру инженер!» не умеют этого считать :)
поэтому — уверенно могут предлагать свой лисапед, там где выгоден клауд, и наоборот, предлагать клауд, где можно сделать все на обычых впсниках.

проблемы с балансировщиками будут и с лично написанными :)

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

он никак не выжрет килобак за час работы.

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

Ну где-то логика ушла в вечный цикл.

ессно, и такое бывает.
поэтому — лямбда ограничена в времени жизни, и будет потушена, независимо от ...
— есть обязательная практика от аналога дед лока, и т.п.

ну и мониторинг и прочая.

то интернет полон таких историй

интернет полон историй когда БД без паролей в него смотрит. с продакшн данными :)
что ж теперь, и БД низя использовать? :)

А провайдер за ваши деньги рад этот цикл масштабировать)

Чаще подлые истории с клаудами звучат так
Заюзали кекое А в тестовом режиме. И Б, в тестовом режиме юзало это А.
А В юзало Б
Попробовали, отключили Б. А про А, забыли, или «оно ж теперь юзаться не будет»
А оно, А это — по прежнему в работе! и снимало денежку.

С клаудами да, за все надо платить. в том числе и аккуратностью работы:
ОРМ фигачит лишние запросы — так нам пофик, у нас же БД своя.
Перешли на клауд — нате вам счет за это, с таким подходом.

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

Почему архитекторы не борятся со сложностью проекта, а только ее привносят.

Потому что задача архитектора — подложить соломки туда, куда проект падать будет. Соломка никогда не бесплатная.

Другими словами: сделать проект гибким в тех местах, где в будущем его, предположительно, нужно будет нагибать.

Другая задача — заделиверить в доступные сроки доступными программистами. Если у тебя питонеры и неделя времени — ты не будешь писать новый эффективный драйвер под линукс.

Потому что задача архитектора — подложить соломки туда, куда проект падать будет.

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

Почему архитекторы не борятся со сложностью проекта, а только ее привносят.

бывает и такое

но чаще — нельзя сделать систему проще чем задачи которые она должна решать
а далее идут пункты — стабильности работы системы, читабельности кода и дизайна решений, и как следствие выход на те самые буковки в SOLID, простые акторы, и прочая

Иногда мне кажется, что роль современных архитекторов

«да все ж все просто!» — на открытке Эвереста.
увидеть там, на открытке например «кислородное голодание» невозможно.
как и понять, с открытки этой, почему на каждого альпиниста надо бы еще два шерпа

Один придумал какую-то вундервафлю

Pipeline наверное самая простая конструкция описанная в цикле статей by Denys Poltorak

К нему, если есть возможность — всегда надо стараться сводить архитектуру.
Известный пример — React где FB предприняли такую попытку:
сделать направление потока данных и управление — однонаправленным

Ессно — а фик так красиво выйдет на практике, и появятся костылики.
А их количество может указать что задача не сводима к однонаправленному pipeline

А их количество может указать что задача не сводима к однонаправленному pipeline

Кстати, в следующей статье есть кусочек о превращении пайплайна в гексагоналку. Объеднинением фильтров в монолитный слой.

Мне прихоидлось слепливать несколько акторов: отрезать обслуживание железа от бизнес-логики, и потом мержить куски логики в синхронную систему — тоже получилась гексагоналка.

Объеднинением фильтров в монолитный слой.

да, интересно, зачем такое понадобилось

дробленные фильтры ж — 1 простые 2 легко тестируются.

о превращении пайплайна в гексагоналку

это всегда можно :)
а вот с гексагоналки сделать пайплайн — ой не всегда.

зачем такое понадобилось

 Ну это если оказывается, что независимые фильтры не так уж и независимы. Мне не понадобилось, но раз у меня была подобная история с субдоменными акторами — вполне могу предположить, что соседу завтра надо будет мержить фильтры в пайплайне — архитектуры же похожи.

да, интересно, зачем такое понадобилось

Кстати, вспомнил юз кейс из малознакомой области. Компьютерное зрение. У пайплайна высокое время отклика (прохождение пакета) и плохо конторолировать происходящее.

Например, нужен робо-пылесос, уворачивающийся от котов. Мы подняли пайплайн с компьютерным зрением (допустим, 5 фильтров, начиная от нормализации яркости и контраста и заканчивая распознавание объектов и трекером уже известных). Оно-то работает, но задержка пол-секунды от камеры до трекера объектов, и этому делу нужен десктопный проц с видяхой. И че? Проект в мусорку?

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

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

Привет, монолит. Прощай, пайплайн.

ну, реалтайм с такими нагрузками по CPU то конечно

это ж все та же история про «5 миров».

Но прикол, что разрабатывать и отлаживать алгоритмы было проще в пайплайне. А вот в прод пойдет гексагоналка.

разрабатывать и отлаживать алгоритмы было проще в пайплайне

да, тем он славится

А вот в прод пойдет гексагоналка.

ну да, и вокруг React придется накручивать либо редакс либо мобикс :)
либо какой другой стейт менеджер.

вот где ломается пайплайн — когда стейт-контекст нужен его элементу.

ну или, как вы привели пример — стоимость вызова становится недопустимой.

В нас на дроні подібна задача.

Цікаво самому, до якої кінцевої реалізації вона дійде в продакшині.

До гексагоналки, бо пайплайни:
1) мають велику затримку
2) погано керовані
Себто, власне зір може буть одним монолітом; система керування — гексагоналкою; інтелект-планувальщик маршруту — blackboard чи моноліт.
Отримуєте щось на зразок картинки для іграшки на початку цієї статті. Або як тут — знову гексагоналка hillside.net/...​/2020/papers/poltorak.pdf
Гексагоналка усюди (навіть структура ОС), і кажуть, що будь-який проект з часом перетворюється на ОС.

Гексагоналка усюди (навіть структура ОС), і кажуть, що будь-який проект з часом перетворюється на ОС.

В точку.

но чаще — нельзя сделать систему проще чем задачи которые она должна решать

Ну если работает могильщик проекта, то действительно нельзя. Ты сделай так чтоб на глупую очередь с фильтрами не нужны были пять девелоперов лямбды амазон и девопсы.

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

В ситу сложности задачи.

Самая сложная задача это написать туже задачу но просто.

из теории
Сложность кибернетических систем определяется двумя факторами.
Первый фактор — это так называемая размерность системы, т. е. общее число параметров, характеризующих состояния всех её элементов.
Второй фактор — сложность структуры системы, определяющаяся общим числом связей между ее элементами и их разнообразием.

если речь о пайплайне — ну расскажите что проще него, чтобы не начал увеличиваться вес фактора 2 :)
а фактор 1 — «написанием кода» невозможно уменьшить. он уменьшается на уровне бизнес-анализа, «урезанием хотелок» как я говорю. архитектура уже как правило — следствие решений принятых уровнем выше, там, в бизнес-анализе. даже когда его формально и не было, а сразу начали писать код, минуя и архитектурные раздумья тоже

либо, сложность фактора 2 выносится за пределы кода. в инфраструктуру, и гордый упрощением заявлет — я упростил задачу, у меня вот код видите какой простой стал!

ну а главная характеристика любой сложной системы — наличие эмерджентности
ее вот и не видно на фоточках Эвереста, и холмик этот видится простым. Восхождение потому — тоже, делов то, по снегу я что-ли не ходил!

Вот я про это говорил в своем первом посте. Люди которые упрощают системы, делают сложное простым — на вес золота. 99% на рынке вот такого «умного лица», которое будет тебе аргументировать, почему элементарная очередь с фильтрами должна быть завернута в лямбды, конфиги, маперы и еще хрен знает что. А после этого, когда прийдут новые логичные требования о развитии системы, например, о обратной связи в пайплайне, окажется что в вундервафле это не продумано.
И когда ты рассказываешь нам что «что может быть проще пайплайн», у меня встречные вопросы.
Ты продумал
1. Деплой, прайс на поднятие лямбд
2. Продумал как ты свои лямбды будешь тестировать локально
3. Продумал как все это должно коммуницировать между собой и что должно произойти с очередями в результате сбоев и багов в самих обработчиках.
4. Продумал как это все должно логироваться и так далее.
5. Сколько в твоей усложненной системе появилось новых точек отказа

И как ответишь для себя на эти вопросы, вспомни что на собеседовании по Литкод, очередь с фильтрами пишут за 5 минут как «медиум» если не изи задача. Но если конечно амазон не привлекать.

Люди которые упрощают системы, делают сложное простым — на вес золота.

неправда. может чуть дороже, да и все.

которое будет тебе аргументировать, почему элементарная очередь с фильтрами должна быть завернута в лямбды, конфиги, маперы и еще хрен знает что

ну то есть вы уже протелепатировали проекты, и уверены что «понили в чем Инштейн ашипся».
Я потому и более простую аналогию привел — фоточки Эвереста.
чтобы проилюстрировать «цену» типичного уверенного в своем познании.

А после этого, когда прийдут новые логичные требования о развитии системы, например, о обратной связи в пайплайне

если элемент пайплайна простой, то проблема будет решаться на уровне его, сборщика пайплайна, и сценария сборки пайплайна. никакой революции не потребуется

Ты продумал
1. Деплой, прайс на поднятие лямбд

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

2. Продумал как ты свои лямбды будешь тестировать локально

уже тестирую. локально. с этого начинается план онбоардинга.

Продумал как все это должно коммуницировать между собой и что должно произойти с очередями

уже работает, не один год. при этом некоторые «фильтры» на питоне, некоторые на ноде. движку и архитектуре пофик. хоть на расте их пиши.

Продумал как это все должно логироваться и так далее.

логируется. как на уровне движка, так и AWSом
каждый запуск «фильтра» поэтому можно воспроизвести локально.

И как ответишь для себя на эти вопросы

Вы лучше ответьте себе — отчего вы решили что думать умеете только вы?

вспомни что на собеседовании по Литкод, очередь с фильтрами пишут за 5 минут как «медиум» если не изи задача

я на литкоде решал только задачки по SQL, интересно было
и считаю что умение решать там задачки — такой себе скил. для старта в программировании.

Я потому и более простую аналогию привел — фоточки Эвереста.

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

Что делает Лысак в своей архитектуре. Собирает обоз на трех квадратных колесах в котором размещает все свои пожитки.Надевает кеды, на кеды лыжи, на лыжи ходули. Сверху панамку, ушанку. Пытается выдвинуться с лагеря и уже при первом ветре начинает сильно дуть. Много багов. «Нам нужно еще 20 девелоперов, телега слишком плохо едет на квадратных колесах по снегу». Ребята сзади негодуют. Какого хрена. Но бодрый штурман рассказывает про «теорию сложности кибернетических систем» и без телеги на квадратных колесах никак нельзя. Этож вершина Эверест йопта !

По мере сложностей решает сопутствующие проблемы.

когда он выяснит что снаряжение не то, на 6000+ метрах, он там и останется.
ледяным памятником

Что делает Лысак в своей архитектуре

Лысак выясняет бизнес требования, прежде чем браться за архитектуру
Затем — бюджет и допустимые сроки
Затем — изучает домен, писанные, а главное неписанные правила. Ищет — аналогичные решения, кто как делал, и на что нарвался.
и т.д.
и где-то на пп 10* начинает думать про архитектуру.

Вы такой же херовый телепат как и мыслитель :)

Этож вершина Эверест йопта !

Холмик это! украшенный ватой, как новогодняя йолка!
«Я точно знаю»! — непоколебимо и гордо вещает нуб

когда он выяснит что снаряжение не то, на 6000+ метрах, он там и останется.
ледяным памятником

Это удивительно. Но у человека с легким рюкзаком больше шансов поднятся на высокую гору перед тем, кто выяснив «все требования» собрался на Эверест с тремя чемоданами.

Лысак выясняет бизнес требования, прежде чем браться за архитектуру

Причем здесь бизнесс требования к технической реализации. Там что в бизнесс плане было записано, лямбды на амазон обязательны к применению для обычных очередей ? Или ты создал себе полосу препядствий и героически ее преодолеваешь ?

Но у человека с легким рюкзаком больше шансов поднятся на высокую гору перед тем, кто выяснив «все требования» собрался на Эверест с тремя чемоданами.

Нулевой шанс. Горняжкой накроет при подъеме. Поэтому и существует Everest base camp где народ тусит и тренируется пару месяцев, чтобы привыкнуть к высоте и окружению. И там вот эта вот вся снаряга из тележки остается перед подъемом. Но тележку с собой берут с запасом на пару месяцев, и оборудование для выяснения прогноза погоды — тоже. Потом — тренируются и ждут окна в погоде. А когда окно — выходят в полночь, чтобы к утру уже где-то на гору карабкаться. После тренировок, и с планом действий. И со спутниковой связью. И большинство — с кислородным баллоном.

Нулевой шанс. Горняжкой накроет при подъеме.

Первыми без кислорода достигли вершины итальянец Рейнхольд Месснер и немец Питер Хабелер в 1978 году. В 1980 году Рейнхольд Месснер, на этот раз в одиночку, снова поднялся на Эверест и установил сразу несколько рекордов.

да. есть народ что и на плотике океаны пересекает.
И?

Есть пример и как Южный полюс покоряли.
Скотт, Роберт — герой.

И какой их % по сравнению с толпами взошедших?
meduza.io/...​srazu-posle-voshozhdeniya

Не правильно формулируешь мысль. Какой процент людей с тремя чемоданами за плечами удалось зайти на эверест.
Их нет.
С такой архитектурой можно зайти разве что на горку на подоле. И то, если с погодой повезет.
github.com/...​FizzBuzzEnterpriseEdition

Чемоданы нужны для подготовки. Инфраструктура. Чтобы в черную пятницу магазин работал, а не лежал.

магазин работал, а не лежал

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

Это просто шутка года. За последние 5 лет я этих облаков от ажур и до амазона насмотрелся предостаточно. Там все что до прода, препрод, де, кью, стейдж лежит больше чем работает. А прод работает какимто чудом, молитвами девопсов.

Это всё от избытка баблоса. Но грядёт кризис, а значит 1) нехватка баблоса 2) нехватка энергии 3) нехватка комплектующих 4) избыток криворуких повсюду.
Вот тогда на AWS-решения и поглядим.

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

Но грядёт кризис

и программистов выкинут на мороз, оставшимся зарплаты урежут в разы, а потом и вообще — «программисты станут не нужны»

Вот тогда на AWS-решения и поглядим.

поглядим и на тех , которые бытенько «все перепишут правильно» :)

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

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

программистов выкинут на мороз, оставшимся зарплаты урежут в разы, а потом и вообще — «программисты станут не нужны»

Нет. Всегда когда был технологичесский скачок от машинных кодов к ассемблеру, си, джаве, sql, количество только росло.
А вот плодить плохие решения это рак отрасли. Будут относится как к индусам. Или увольнять пачками, или кодить за копейки с видео контролем

Это удивительно. Но у человека с легким рюкзаком больше шансов поднятся на высокую гору перед тем,

ничего удивительного.
тот кто не был в горах — не в курсе что там нет магазинов докупить снаряжение. и доставка не работает...

Причем здесь бизнесс требования к технической реализации

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

Там что в бизнесс плане было записано, лямбды на амазон обязательны к применению для обычных очередей ?

В бизнес плане описана требуемая функциональность.
По домену задачи понятно направление развития.
и т.п.

Или ты создал себе полосу препядствий и героически ее преодолеваешь ?

в данном проекте я себе ничего не создавал.
уже давно все работает.

но вы поделились результатами своего дара телепатии, и нубского мнения по открыточке Эвереста — как вы будете собирать снаряжение, и радостно двинетесь на тот холмик, что вы видели на фоточке.

то есть аналогия оказалась настолько удачной, что нуб ее и не понял, и показл пример — размышления нуба :)

в данном проекте я себе ничего не создавал.
уже давно все работает.

Да потому что таких свадебных архихекторов и берут на проекты, где не надо ничего делать. Вот наговнокодили два года назад этих лямбда очередей, еще год эти несчастные очереди чинили и отлаживали и довели до состояния «не дуть». Написали кучу инструкций «он боардинг», как всего за три дня пройти полосу препядствий, запустить и отладить.

а пет проекты, за свой счет, ессно, делайте как хотите

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

Да потому что таких свадебных архихекторов и берут на проекты, где не надо ничего делать

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

как всего за три дня пройти полосу препядствий, запустить и отладить.

почему три дня?
в первый день локально и запустил.

опыт с клаудами у меня — нулевой. это в первый раз их вживую щупаю

Так с этого надо начинать.

да как бы это ж по дефолту: заказчик платит — программист делает.

На пет проекте так не получится

кому интересно что там и как делается на пет проекте, кроме самого автора?

и еще девелоперов новых 50 штук не дадут разгребать фавелы амазона ...

если есть деньги на этих 50 девелоперов — то значит проект успешный.
если проект провальный, то денег нет, и никаких девелоперов на нем тоже в итоге не будет.

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

разгребать фавелы амазона ...

зато оплату обещают больше, чем умеющим преодолевать на плотике океаны :)
платят неплохо за это.
а вот за разгребание фавелов в лисапеде гения — обычно нет.

на местном фрилансе даже практика частая
каждый фрилансер получив такой проект — выкидывает это творение к чертовой матери, и ставит либо свой лисапед, либо что-то стандартное :)

рынок труда — всем нам судья.

бывал и в таких. когда проект проедал все деньги инвесторов, но бизнесово оказывался несостоятельным.

Это кстате я хотел спросить отдельным прямым вопросом, так сказать по сути. В скольких проектах ты работал которые просто развалились. Вижу что сам проговорился.
К слову за всю карьеру я был только в одном проекте, который развалился. И там были вот такие кадры с «теория сложности кибернетических систем». Как я говорил — это могильщики проектов. Даже самый прибыльный бизнесс не всегда сможет вытянуть такое на своем горбу. Если такое видите — бегите, или вскоре будете искать новую работу попутно публикуя статьи на доу про выгорание.

В скольких проектах ты работал которые просто развалились

Не считал.
Много таких было

И причины были — бизнесовые, а не технические.

К слову за всю карьеру я был только в одном проекте, который развалился.

Гы. Я даже работал на предприятиях которые дошли до банкротства, с распродажей оборудования, зданий и земли :)

А стартапы — по статистике, мрут что-то там в 90% случаев.
на самом деле больше, это смертность по тем, кто попали в статистику, а не померли раньше
тоже бывал. интересные были проекты.

Как я говорил — это могильщики проектов

да мало ли что вы говорите :)
я вот разбанил временно, и вижу — такую же туфту говорите что и обычно :)

Даже самый прибыльный бизнесс не всегда сможет вытянуть такое на своем горбу

Когда бизнес видит что надо оптимизировать расходы на айти
он и ставит задачу программистам — оптимизируйте.
программисты и оптимизируют.

У меня давняя «дружба» поэтому с ОРМами, потому что не раз на такой задаче и зарабатывал себе копеечку

Вобщем я вас понял. Вы еще и оказались глубоким телепатом, как по вскольз упомянутым деталям конкретного проекта уже все просекли, так и какого-то Лысака — насквозь прозрели. в бане вам таки место :)

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

Просто на создание надо пять лет, а на поднятие готовой — два месяца. Кто займет рынок: тот, кто пять лет пытался сделать качественно, или тот, кто за два месяца сделал быстро, и следующие 4 года продавал продукт, понемногу обрабатывая напильником?

Разные есть варианты и разные задачи. Кто имеет цель, тот добивается.

вы не научились даже презентовать свои мысли — а беретесь поучать других как им делать их работу?
за которую еще и удивительно — платят

за ваши гениальные идеи — вам много заплатили?

какую полезную работу в разработке вы умеете делать?
когда ее делали в последний раз?

Казалось вот тут две плюшки возьмем, тут добавим запятую и все взлетит

мдя, очередной насмотревшийся на фоточки Эвереста взялся рассуждать о простоте...

вы не научились даже презентовать свои мысли — а беретесь поучать других как им делать их работу?

Где я учу. Работайте.

+1 к отменным тех. статьям. спасибо огромное !

+1 к любым тех статьям, а то весь форум забит политотой

Спасибо, интересная статья. Читаю сейчас Designing Data-Intensive Applications.

Підписатись на коментарі