Часть 1. Введение

Часть 1. Введение
Часть 2. Пусконаладка предприятия
Часть 3. Администратор данных
Часть 4. Администратор процессов
Часть 5. Структура приложения
Часть 6. Публикация в GCP

Данная статья является путеводителем по тому как строить приложения в SYNRC и как выглядит наша концепция управления программным комплексом предприятия. В этой серии статей я покажу как разработывать бизнес приложения для предприятий задействовав максимальное количество библиотек нашего стека (по делу).

Для примера построим дашбоард аутсорсингового предприятия PLM с возможностью инвестирования и учётом опционов программистов.

Цели проекта:

— Дашборд директора, работников и инвесторов
— Попроектная отчетность
— Управление опционами программистов
— Инвестирование в проекты (со страхованием)

Бизнес процесы:

— Главный бизнес-процес модуля — долгоживущий проект (PLM)
— Создание проекта с запланированной страховой суммой, которая собирается начальными инвесторами либо откусываетсяч от существующих проектов, проект находится в стадии бейкинга до собрание всей суммы, после чего переводится в активное состояние по которому можно совершать инвестиции. До этого проект просто проедставляет отчеты P&L и CashFlow.
— Учет CashFlow, детализация до часов на человека на проект но без зарплатных ведомостей
— После вычитания зарплат из инвойсов по CashFlow мы формируем список статей, на которые будут откусываться деньги после вычисления Revenue: 1) страховой фонд (который откусывается если мы используем этот проект как залог для кредита на другой проект. 2) Опционы программиистов которые выдаются автоматически людям которые работают на этом проекте, но любые другие могут тоже учавствовать. 3) Наш заработок (свободный пул или резервация) 4) R&D отчисления (обязательные).

Управление сложностью

Главная концепция нашего стека — управление сложностью. Основное философское направление в разработке программного обеспечения — фундаментальный минимализм. Мы не придумываем ничего нового лишь показывааем как разложить устоявшиеся понятия в отрасли в виде простого и удобного набора примитивов которыве можно реализовать практически. Наше именование 8.3 совместимо с файловыми системами прошлого CP/M, TRS-80, Atari, DEC. Первые версии Erlang, на котором написана наша система были в 1988 году. Что сказать, мы помним как строить приложения. Кратко называем модули, как в SAP, BAAN и системах прошлого, но при этом мы так же лаконичны и в имплементациях. У нас строгое ограничение на размеры модулей в LOC — 1K для библиотек, и 2К для приложений. Мы используем только бинарные протоколы, и полнодуплексные каналы связи для наших приложений реального времени. В качестве асинхронных протоколов мы зафиксированы на TCP, MQTT и WebSocket, а также UDP, QUIC. Для персистентных стримов мы используем синхронный HTTP/2. Наши системы обслуживают суточную норму пользователей на одном компьютере за 7 секунд в самом большом банке восточной Eвропы и при этом их скомпилированный код помещается на дискету 2.88". А сама система написана на языке которому 30 лет и который не потерял совсместимости со своей 10-летней версией! Если это не технологическая стабильность, то нам вам нечего предложить более устоявшегося. Добавьте бесплатный ASN.1 компилятор и 80% GSM трафика проходящего через этот язык, и станет понятно, что выбор этот безальтернативен.

SYNRC ENTERPRISE O7 TRUSTED CA ----------- ----------- ----------- ----------- active acc bud n2o.dev bert bank chat n2o.space bpe chat plm synrc.com form crm sample synrc.space fs db kvs ent mach erp mad fin n2o fix nitro ldap pie mq rest pay sh pm review rocksdb sample scm sys tic tms wms xio

Пока вы занимались пониманием того, что Scala не взлетит, и на Go вы не получите никакого технологического преимущества, кроме разве что латенси — мы создали систему управления предприятия старым дедовским способом. Да мы поддерживаем микросервисы и можем разнести компоненты нашего предприятия, но предпочитаем устанавливать наши системы на монолитах, исключение разве что уместно для CA ауторити или Identity Server, в качестве которого можно использовать наш in house LDAP сервер SYNRC.

> :supervisor.which_children(:n2o) [ {{:tcp, '/ldap/tcp/4'}, #PID<0.985.0>, :worker, [:n2o_tcp]}, {{:tcp, '/ldap/tcp/3'}, #PID<0.984.0>, :worker, [:n2o_tcp]}, {{:tcp, '/ldap/tcp/2'}, #PID<0.983.0>, :worker, [:n2o_tcp]}, {{:tcp, '/ldap/tcp/1'}, #PID<0.982.0>, :worker, [:n2o_tcp]}, {{:ws, '/chat/ws/4'}, #PID<0.985.0>, :worker, [:n2o_ws]}, {{:ws, '/chat/ws/3'}, #PID<0.984.0>, :worker, [:n2o_ws]}, {{:ws, '/chat/ws/2'}, #PID<0.983.0>, :worker, [:n2o_ws]}, {{:ws, '/chat/ws/1'}, #PID<0.982.0>, :worker, [:n2o_ws]}, {{:mqtt, '/erp/mqtt/4'}, #PID<0.977.0>, :worker, [:n2o_mqtt]}, {{:mqtt, '/erp/mqtt/3'}, #PID<0.976.0>, :worker, [:n2o_mqtt]}, {{:mqtt, '/erp/mqtt/2'}, #PID<0.975.0>, :worker, [:n2o_mqtt]}, {{:mqtt, '/erp/mqtt/1'}, #PID<0.974.0>, :worker, [:n2o_mqtt]}, {{:mqtt, '/bpe/mqtt/4'}, #PID<0.977.0>, :worker, [:n2o_mqtt]}, {{:mqtt, '/bpe/mqtt/3'}, #PID<0.976.0>, :worker, [:n2o_mqtt]}, {{:mqtt, '/bpe/mqtt/2'}, #PID<0.975.0>, :worker, [:n2o_mqtt]}, {{:mqtt, '/bpe/mqtt/1'}, #PID<0.974.0>, :worker, [:n2o_mqtt]}, {{:caching, 'timer'}, #PID<0.969.0>, :worker, [:n2o]} ]

В качестве системы хранения мы используем локальные BTree таблицы под управлением bdb, leveldb, rocksdb как делали наши деды в Fox Pro и Paradox. А распределённые транзакции делаем в духе выделенного сервера как Microsoft DTSC. Таким образом вы получаете сразу нормальное (CoSQL) представление всех цепочек, и любому программисту будет понятна система управления ими, при условии, что он знает, что такое BTree. А распределенным коммитом вы управляете сами и сами выбираете протокол оракула.

> :kvs.all :writer [ {:writer, '/bpe/proc', 2, [], [], []}, {:writer, '/erp/group', 1, [], [], []}, {:writer, '/erp/partners', 7, [], [], []}, {:writer, '/acc/synrc/Kyiv', 3, [], [], []}, {:writer, '/chat/5HT', 1, [], [], []}, {:writer, '/bpe/hist/1562187187807717000', 16, [], [], []}, {:writer, '/bpe/hist/1562192587632329000', 1, [], [], []} ]

Да мы предлагаем вам чуть более прямой и непосредственный путь кодирования данных, для совершения продвинутого репортинга вы по прежнему будете должны иметь офлайновые бекофис системы аналитики на SQL. Но в рантайме и операционной части этого не должно быть. Оно не только сжирает ресурсы, но и плохо масштабируется, специалисты по профилированию SQL запросов редкие и дорогие. SQL имплементации пишутся идиотами, поэтому системы состоят из 7 слоев заплаток. Даже MySQL или PostgreSQL который вы любити использовать в качестве Key-Value стораджей невозможно скейлить нормально, так как там везде проблемы с каскадной репликацией, много дополнительных ненужных слоёв, текстовый (!) протокол по сокету со своим парсингом и т.д. и т.п. Мир стартапов уже вернулся в NoSQL, Google например, поэтому бизнесу пора тоже подтягиваться, а софт для бизнеса пока еще старше чем Google в два раза!

Наши протоколы вкатываются с типовыми аннотации и генерируются для следующих языков: Java, Swift, JavaScript, Google Protobuf V3, ASN.1. Также мы генерируем валидаторы данных по этим типовым спецификациям и встраиваем эти валидаторы в тракт наших распределенных протоколов, поэтому мы никогда не позволим клиентам испортить сторадж. Для веб приложений у нас развитая система валидации как для JavaScript так и на стороне сервера. Бизнес логика полностью изолирована в нашей системе управления бизнес процессами, где каждый бизнес процесс является процессом виртуальной машины. Все цепочки модифицируются атомарным образом, поддерживают flake адресацию и не требуют дополнительной изоляции в своём принимитивном использовании. Поэтому вы можете трактовать базу как распределенный кеш и использвать её из фронт приложений для примитивных случаев.

Мы за шесть лет непрерывной эволюции стабилизировали наши АПИ и вкатали не только в Erlang и Elixir но и в Standard ML, Haskell, C#, Clojure и даже Agda! Все имплементаторы согласились, что интерфейсы наши хороши, вы можете в этом убедиться лично! А наши библиотеки стали настолько популярны, что их начали использовать даже в Elixir сообществе, хотя мы и не поддерживаем ни Phoenixframework ни Ecto, ведь у нас есть N2O и KVS! Только имея имплементации на семи языках можно убедиться в хорошоми дизайне библиотеки. Мы создавали специальные выпуски N2O MQTT и KVX но всегда со временем мержили их с апстримом. N2O по-прежнему будет развиваться и периодически ломать совместимость, но мы ведём летопись и это не сложно, так как кодовая база всего 1К LOC.

В отличе от наивных детских стеков мы предлагаем испытанную в боях гетерогенную платформу которая работает со множеством протоколов и форматтеров при этом предлагая вам старый добрый набор сервисов в духе CORBA и Web Services. Подключайте свои XML и даже WBXML форматеры с легаси системами на здорорвье. Гибкость на уровне Apache Camel или WCF в 100 строчках кода.

Отзывы

Мы намеренно пытались создать стек, для управления которым хватит зананий обычного 1С/PHP программиста, так мы вступаем в конкуренцию с 1С но на рынке програмиистов индивидуальных автоматизаторов предприятий. В стартапах они были бы минимум СТО компании-предприятия. Обычно это человек-оркестры которые могут совершать ассесмент, выступать в роли системных аналитиков и делать прототипы на PHP/1C или в рамках своих технологических предпочтений.

Вот, что пишет один из таких системных аналитиков, Саша Пальчиковский:

Я 20 лет работаю с 1С и отлично знаю ее достоинства и недостатки.

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

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

Почему мне нравится Erlang и N2O:
— Мало кода — 1000 LOC на очень функциональное приложение — это невероятно! У меня один сложный запрос может содержать строк кода в два раза больше.

— Let it crash — я так устал трястись по поводу возможных ошибок после внедрения и последующего геморроя по их исправлению.

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