Comments 11
Почему вы не взяли за основу своего оркестратора какой-нибудь готовый опенсорсный BPM-движок типа Comunda? Вы их смотрели, изучали?
Спасибо за комментарий! Camunda - один из проектов, на который мы опирались при реализации своего решения. На момент начала реализации этот движок лучше всего работал с самописными JS-нодами, причем у них были и есть серьезные ограничения по правилам написания блока. В нашей платформе получилось обойтись куда меньшими ограничениями: система должна знать функцию первичного запуска блока run, а подключение зависимостей и доступ по API - делаются и предоставляются нативно.
Спасибо, за пост, было интересно читать!
У Вас получилась сильно урезанная версия KNIME или яндексовской нирваны. Проблема всех таких систем в мире Data Science заключается в том, что построение моделей - это 5-10% времени любого проекта машинного обучения, остальное - это работа с данными: поиск, анализ, обработка/подготовка. И именно этот этап зачастую невозможно перенести на low/no code solution. Пробовали в IBM (Watson Studio) и в Microsoft (Azure ML), в итоге получались проекты стоимостью в миллионы долларов, которые могут решать только тривиальные задачи, который чаще всего не встречаются в крупных компаниях. Проблема заключается в том, что зачастую под каждый проект нужно писать много специфичных функций для обработки данных, которые потом вряд ли будут использованы где-то ещё. Делать это в no/low code обычно либо дико неудобно, либо просто невозможно.
Если говорить про создание микросервисов, то обычно всё куда проще. Можно в докере создать контейнер с api наружу и разойтись. Проверку данных и прочие вещи можно легко реализовать внутри этого контейнера.
Спасибо за комментарий!
KNIME - это, грубо говоря, отправная точка, чем можно было вдохновляться. Нирвана от Яндекса - это уже тот сервис, который по своей сути мы и хотели реализовать для свободного доступа и без ограничений инфраструктуры одной компании. Причем область применения теперь не ограничивается исключительно ML-задачами. Вы можете хоть обработчик изображений реализовать в блоке, хоть трейдинговый бот, решение о сделке которому будут давать разные и легко заменяемые ноды. Любой бизнес-процесс проверок/обработок можно выстроить из таких блоков, а потом при надобности модифицировать его.
Что касается докера и микросервисов - полностью согласен, мы туда и идем :)
Для любого проекта/микросервиса будет создаваться контейнер, а API наружу уже есть для каждого пайплайна, именно так и происходит продовое обращение к ним в текущем боевом режиме.
Кроме того, хотя задача и казалась интересной, моих знаний катастрофически не хватало, а единственным спасательным кругом стал термин «линейная регрессия», который и послужил отправной точкой в путешествие по миру Data Science.
Нью-Васюки не только на корпоративной сервере но и в вашем персональном десктопе. Не нужно знаний и опыта, вас научат решать задачи методом Data Science словоблудия.
Весеннее обострение?))
Похоже на то:
Это подход, при котором единое приложение строится как набор небольших сервисов, каждый из которых работает в собственном процессе и коммуницирует с остальными используя легковесные механизмы, как правило HTTP.
HTTP же просто супер легковесный механизи коммуникации. В сочетании с:
технологии создания ПО с помощью визуального редактора с минимальным написанием кода или без написания кода вообще.
причем на всех языках сразу:
сервисы могут быть написаны на разных языках и использовать разные технологии хранения данных.
Вот так вот Нью-Васюки и строятся. Супер технология!
Спасибо за комментарий! Про НTTP - это может и не самый легковесный, но самый универсальный способ коммуникации. Про low-code парадигму: в нашей платформе вы можете создавать каждый блок самостоятельно или же модифицировать его исходный код без ограничений, поэтому создать что-либо "бездумно" не получится. А выстраивание микросервиса в виде пайплайна - это скорее большое преимущество для владельца процесса-менеджера (+нативная документируемость получается).
А выстраивание микросервиса в виде пайплайна - это скорее большое преимущество для владельца процесса-менеджера
пайплайн строится из компонент или модулей или как вы называете такие сущности?
Это круто конечно что микросервис у вас состоит из компонент, только в этом ничего нового нет, это все как бы само сабой разумеется. Так же как и:
в нашей платформе вы можете создавать каждый блок самостоятельно или же модифицировать его исходный код без ограничений
это просто общие слова которые какждый уважающий себя разработчик будет заявлять о своей платформе, системе, ... не зависимо от того на каком уровне реализации или даже понимания способов реализации таких возможностей он находится.
Кстати без ограничений оно не бывает - это вы погорячились, нет ничего абсолютно универсального, как и ничего бесконечного в этом мире.
Это круто конечно что микросервис у вас состоит из компонент, только в этом ничего нового нет, это все как бы само сабой разумеется.
Суть в том, что этот процесс можно организовать на визуальном уровне (об этом, кстати, в статье говорится).
это просто общие слова которые какждый уважающий себя разработчик будет заявлять о своей платформе...
Нет, это вполне конкретное заявление: вы можете создать на платформе блок, основываясь на своем исходном коде.
Кстати без ограничений оно не бывает - это вы погорячились
Что имеется в виду, если мы не говорим о философском подтексте?
по конкретным заявлениям дискутировать не имеет смысла, очень жаль.
в рамках языка С можно создать модуль - это концепция из прошлого столетия, что в этом нового? То что мы модуль назовем блоком?
Из С-шного кода тоже можно вызвать функции-модули-компоненты написанные на другом языке, при желании и при необходимости можно это автоматизировать как то, но, видимо это не особо востребованная возможность, или возможность не поддающаяся достаточной унификации что бы создать одно решение подходящее всем. Поэтому попытки не имели успеха. Конечно можно надеятся что вы сделали прорыв в унификации нашли то что всех удовлетворит, но, извините, из статьи этого не видно, к сожалению.
Как мы делали скоринг на микросервисной архитектуре руками не-программистов