1С это проприетарный вендорский продукт. Меняем шило на мыло. lsFusion вообще маргинален крайне и по сообществу и по рынку присутствия - Беларусь и по подходу к разработке
Бизнес-логика и требования производительности я бы все-таки разделял. Может быть система с совершенно "адской" бизнес-логикой расчета - типа оптимальный раскрой чего-нибудь, но нагрузка на уровне 1000 бизнес-транзакции в день. Такую систему вряд-ли потребуется писать на чем-то специализированном. Python разработчик вообще прекрасно справится.
Возможно я как-то непонятно объяснил, поэтому приведу жизненный пример. Предположим в жестокой иерархической структуре, которая занимается товарно транспортными операциями нефти или газа, стартовал проект по созданию системы управления транспортными потоками на основе микросервисной архитектуры естественно. Для реализации проекта создана отдельная проектная структура, там архитектора, самоуправляемые команды, гибкие практики и все такое. Повезло и они правильно определили границы сервисов и вот одна команда разрабатывать и совершенствует сервис планирования загрузки трубы на основании откуда-то поступивших заявок, которые делает другая команда, и передает данные о порядке организаций партий продукта в какой-то другой микросервис. Вдруг, происходит сбои и в результате по какой то причине в трубе оказался избыток или недостаток углеводородов для поддержания технологического давления. Первыми как правило идут на плаху АСУТПшники и метрологи. Но выясняется, что там все ок. Приборы поверены, а в системе управления нет ошибок и все идет в плановом режиме. Вопросы к планово-диспетчерской службе, а те говорят - слушайте мы вот сюда что-то вбиваем, а там дальше микросервисы и вон в той agile структуре самоуправляемые команды какие-то. Я вас уверяю, после этого инцидента эта самоуправляемая команда будет ликвидирована, потому что иерархическая структура не умеет этим управлять. И будет создан большой такой монолитный сервис планировщик транспортных потоков, владельцем которого будет руководитель планово-диспетчерской службы, которому абсолютно плевать на архитектуру и не плевать на свое рабочее место. Конец истории.
В реале это легко достижимо, так как многие организации давно таки и работают. Все очень просто. В организации часто есть линейная структура, которая абсолютно традиционна и есть дерево по сути, и "проектная", когда под конкретную задачу нарезаются люди в "проект" с подчинением ПМу. Поэтому получить "команды на две пиццы" в организациях с традиционной структурой научились уже давно
Нет, это не достижимо и не просто. Приведу простой пример из жизни. Большие компании в погоне за снижением риска коррупции и конфликта интересов используют простое решение - вводят в организационную структуру собственные отделы внутренней безопасности. Как Вы думаете это снижает уровень возникновения рисков коррупции и конфликтов интересов при трудоустройстве родственников на хорошие посты? Правильно - не снижает, а просто создает для этого новые правила - мутации, красиво "обмазанные" регламентами. Так же и с отдельными "проектными" офисами в жестко зарегулированных структурах. Первым признаком мутирования таких "проектных" групп является появление в них системного аналитика. Вы в курсе, что это вообщем-то чисто российский прикол, что в проекте появляется бизнес-аналитик и системный аналитик. За кордоном нет такой выделенной функции - она интегрирована в PM или лида. А у нас есть. И знаете зачем? Чтобы кого-то оставить крайним, потому что в жестких иерархических структурах - он должен быть. Если косяк с тем, что получилось - системный аналитик неправильно описал бизнес-требования или неправильно передал требования в разработку. Тут никаких самоуправляемых команд нет, как нет и продуктового мышления также им свойственного. Традиционная организационная структура синтезирует "крайних" даже в проектных командах, хотим мы этого или нет. Поэтому в жесткой иерархической структуре не может быть самоуправляемых команд, так как в принципе отсутствует культура коллективной ответственности за результат, но есть культура "крайнего". Как найти крайнего в распределенной самоорганизущейся микросервисной архитектуре? Закон Конвея работает.
Вот тут я не понял, почему это заблуждение. Ну смотрите. При проектировании "логической" части приложения мы выделяем домены. Если есть время, даже прописываем связи и решаем, как их будем реализовывать, чтобы зависимости были явно прописаны, как и методы борьбы с негативными последствиями из-за отказов. Ну я, как архитектор, обычно до начала разработки прописываю для себя модули, их функции, связи/сервисы. Это нужно в том числе, для проверки того, что решение покрывает все то, что уже известно сейчас о бизнес требованиях и насколько принятые технические решения по стеку адекватны. Понятно, со временем может что-то меняться, но так как домены и логика - это отрадение реального мира, есть большая вероятность не промахнуться
Формулировка автора выглядит категоричной. Полагаю, что в первом пункте акцент именно на границах модулей, которые являются зонами повышенной неопределенности и собственно отношению команды к риску дополнительных затрат из-за overengineering. Если отношение к риску консервативное - грубо говоря проект на стадии MVP и денег три копейки, то зачем брать на себя дополнительные риски на выстраивании дорогой микросервисной архитектуры. Но еще раз - это спорно. Как всегда "it depends". Во втором пункте полагаю автор хотел сказать, что только руководствуясь этим допущением нельзя принимать решение о построении всего приложения на микросервисной архитектре. Большую часть проекта, который изменяется с равной скоростью, разумнее сделать монолитом.
В статье хотели сделать акцент на проверку соответствия возможностей команды и планируемой архитектуре. Разговор не о том, что у микросервисов и монолитов нет проблем - везде есть свои за и против. Просто в определенном классе задач, приведенном в статье, монолит более эффективен, чем микросервисы. И конкретно при миграции легаси приложений монолит почти всегда выйгрывает. Согласны?
сколько вакансий на HH.ru?
1С это проприетарный вендорский продукт. Меняем шило на мыло. lsFusion вообще маргинален крайне и по сообществу и по рынку присутствия - Беларусь и по подходу к разработке
Бизнес-логика и требования производительности я бы все-таки разделял. Может быть система с совершенно "адской" бизнес-логикой расчета - типа оптимальный раскрой чего-нибудь, но нагрузка на уровне 1000 бизнес-транзакции в день. Такую систему вряд-ли потребуется писать на чем-то специализированном. Python разработчик вообще прекрасно справится.
Видео прикольное. Но по-моему это про разработку на JavaScript*)
Зачем мне Битрикс, если я пишу на Vue?
Возможно я как-то непонятно объяснил, поэтому приведу жизненный пример. Предположим в жестокой иерархической структуре, которая занимается товарно транспортными операциями нефти или газа, стартовал проект по созданию системы управления транспортными потоками на основе микросервисной архитектуры естественно. Для реализации проекта создана отдельная проектная структура, там архитектора, самоуправляемые команды, гибкие практики и все такое. Повезло и они правильно определили границы сервисов и вот одна команда разрабатывать и совершенствует сервис планирования загрузки трубы на основании откуда-то поступивших заявок, которые делает другая команда, и передает данные о порядке организаций партий продукта в какой-то другой микросервис. Вдруг, происходит сбои и в результате по какой то причине в трубе оказался избыток или недостаток углеводородов для поддержания технологического давления. Первыми как правило идут на плаху АСУТПшники и метрологи. Но выясняется, что там все ок. Приборы поверены, а в системе управления нет ошибок и все идет в плановом режиме. Вопросы к планово-диспетчерской службе, а те говорят - слушайте мы вот сюда что-то вбиваем, а там дальше микросервисы и вон в той agile структуре самоуправляемые команды какие-то. Я вас уверяю, после этого инцидента эта самоуправляемая команда будет ликвидирована, потому что иерархическая структура не умеет этим управлять. И будет создан большой такой монолитный сервис планировщик транспортных потоков, владельцем которого будет руководитель планово-диспетчерской службы, которому абсолютно плевать на архитектуру и не плевать на свое рабочее место. Конец истории.
Накину пару комментариев.
Нет, это не достижимо и не просто. Приведу простой пример из жизни. Большие компании в погоне за снижением риска коррупции и конфликта интересов используют простое решение - вводят в организационную структуру собственные отделы внутренней безопасности. Как Вы думаете это снижает уровень возникновения рисков коррупции и конфликтов интересов при трудоустройстве родственников на хорошие посты? Правильно - не снижает, а просто создает для этого новые правила - мутации, красиво "обмазанные" регламентами. Так же и с отдельными "проектными" офисами в жестко зарегулированных структурах. Первым признаком мутирования таких "проектных" групп является появление в них системного аналитика. Вы в курсе, что это вообщем-то чисто российский прикол, что в проекте появляется бизнес-аналитик и системный аналитик. За кордоном нет такой выделенной функции - она интегрирована в PM или лида. А у нас есть. И знаете зачем? Чтобы кого-то оставить крайним, потому что в жестких иерархических структурах - он должен быть. Если косяк с тем, что получилось - системный аналитик неправильно описал бизнес-требования или неправильно передал требования в разработку. Тут никаких самоуправляемых команд нет, как нет и продуктового мышления также им свойственного. Традиционная организационная структура синтезирует "крайних" даже в проектных командах, хотим мы этого или нет. Поэтому в жесткой иерархической структуре не может быть самоуправляемых команд, так как в принципе отсутствует культура коллективной ответственности за результат, но есть культура "крайнего". Как найти крайнего в распределенной самоорганизущейся микросервисной архитектуре? Закон Конвея работает.
Формулировка автора выглядит категоричной. Полагаю, что в первом пункте акцент именно на границах модулей, которые являются зонами повышенной неопределенности и собственно отношению команды к риску дополнительных затрат из-за overengineering. Если отношение к риску консервативное - грубо говоря проект на стадии MVP и денег три копейки, то зачем брать на себя дополнительные риски на выстраивании дорогой микросервисной архитектуры. Но еще раз - это спорно. Как всегда "it depends". Во втором пункте полагаю автор хотел сказать, что только руководствуясь этим допущением нельзя принимать решение о построении всего приложения на микросервисной архитектре. Большую часть проекта, который изменяется с равной скоростью, разумнее сделать монолитом.
В статье хотели сделать акцент на проверку соответствия возможностей команды и планируемой архитектуре. Разговор не о том, что у микросервисов и монолитов нет проблем - везде есть свои за и против. Просто в определенном классе задач, приведенном в статье, монолит более эффективен, чем микросервисы. И конкретно при миграции легаси приложений монолит почти всегда выйгрывает. Согласны?