Conway's law in action
Nov. 5th, 2021 10:10 amИз сабжевого закона можно сделать спорное следствие, что каждый пытается решить задачу теми средствами, которые под рукой, и по минимуму задействовать что-то за пределами зоны контроля.
Вариант №1. У приклада есть три сервера, а в клиент зашита логика ходить по ним по очереди. Потому что балансера не было. Ну точнее был, но за его настройкой надо идти в другую группу и ну его нафиг.
Вариант №2. К прикладу прикручен отдельный сервак, на котором крутится, по сути, система синтетических тестов и сбора метрик из специальных ручек, которая отписывается в почту, если что не так. Потому что мониторинг, конечно, есть, но за ним надо идти вообще за океан, там будут месяцами судить и рядить, так что ну его нафиг.
Вариант №3. Был сервачок с обычным сервисом. За полтора года это настоялось до того, что вокруг сервачка еще несколько с килотонной других сервисов, а изначальный сервис работает мультиплексором. Потому что для него есть боярский доступ на файре, а делать дырку целое дело, обивать пороги и все такое, так что ну его нафиг.
Есть у этого подхода, кроме производства изрядной дичи в архитектурном отношении, одно на самом деле полезное свойство. Твоя система будет взрываться, а причину взрыва и способы его исправления куда как проще искать в своей зоне контроля, чем в чужой или, того хуже, на стыке.
В этом, кстати, изрядный бич пропагандируемого современного serverless - у тебя код раскидан по тонне сущностей, которые соединяют сущности, которые ты вообще не контролируешь, и если что-то пошло не так, то как понять, это твой баг, это неучтенный нюанс связки, это взрыв связки или это вообще какая-то неведомая долбаная.
Это я к тому, что одну планируемую штуку, которую мы специально дорабатывали, чтобы она идеально контейнеризовалась и распиливалась, мы будем разворачивать... старым добрым монолитным способом на инстансе со всем нужным на борту в одном флаконе. Потому что в этой ситуации у нас ноль лишних внешних зависимостей, а все косяки интеграции будут в нашей зоне контроля, потому что инстанс наш. А поскольку я здесь выступаю в роли "сраного разраба, который опять багов наплодил", то я очень хочу иметь возможность ловить и чинить их сам... потому что вне зависимости от причин проблем крайним буду я. А так хоть к обязанностям права прилагаться будут.
Вариант №1. У приклада есть три сервера, а в клиент зашита логика ходить по ним по очереди. Потому что балансера не было. Ну точнее был, но за его настройкой надо идти в другую группу и ну его нафиг.
Вариант №2. К прикладу прикручен отдельный сервак, на котором крутится, по сути, система синтетических тестов и сбора метрик из специальных ручек, которая отписывается в почту, если что не так. Потому что мониторинг, конечно, есть, но за ним надо идти вообще за океан, там будут месяцами судить и рядить, так что ну его нафиг.
Вариант №3. Был сервачок с обычным сервисом. За полтора года это настоялось до того, что вокруг сервачка еще несколько с килотонной других сервисов, а изначальный сервис работает мультиплексором. Потому что для него есть боярский доступ на файре, а делать дырку целое дело, обивать пороги и все такое, так что ну его нафиг.
Есть у этого подхода, кроме производства изрядной дичи в архитектурном отношении, одно на самом деле полезное свойство. Твоя система будет взрываться, а причину взрыва и способы его исправления куда как проще искать в своей зоне контроля, чем в чужой или, того хуже, на стыке.
В этом, кстати, изрядный бич пропагандируемого современного serverless - у тебя код раскидан по тонне сущностей, которые соединяют сущности, которые ты вообще не контролируешь, и если что-то пошло не так, то как понять, это твой баг, это неучтенный нюанс связки, это взрыв связки или это вообще какая-то неведомая долбаная.
Это я к тому, что одну планируемую штуку, которую мы специально дорабатывали, чтобы она идеально контейнеризовалась и распиливалась, мы будем разворачивать... старым добрым монолитным способом на инстансе со всем нужным на борту в одном флаконе. Потому что в этой ситуации у нас ноль лишних внешних зависимостей, а все косяки интеграции будут в нашей зоне контроля, потому что инстанс наш. А поскольку я здесь выступаю в роли "сраного разраба, который опять багов наплодил", то я очень хочу иметь возможность ловить и чинить их сам... потому что вне зависимости от причин проблем крайним буду я. А так хоть к обязанностям права прилагаться будут.