Место BPMN и BPM-движков в ИТ-проектах
Если вы делали много ИТ-проектов, а про BPMN слышали лишь краем уха, то эта статья для вас. В этой статье рассказываю, как BPMN и BPM-движки могут облегчить вашу жизнь.
О BPMN и BPM-движках
BPMN — это нотация, набор значков и правил их применения. В отличии от UML, FlowChart, IDEF и прочих наборов значков, символы BPMN всегда однозначны и не допускают трактовки «или». Каждый значок означает одно и тоже на любой схеме, рисовал ли её студент 1 курса или ИТ-архитектор из банка.
Строгая семантика BPMN позволяет однозначно превращать значки в программный код. Получается визуальное программирование.
Часто BPMN используют, как средство описания бизнес-процессов. В этом применении строгость нотации для программирования теряет свой смысл, а авторы схем могут вытворять всякую ерунду (ведь компилятор не будет проверять верность составления схемы).
Из BPMN получаются вот такие схемы
BPM-движок — это приложение, которое превратит картинку BPMN в код.
Основные прелести BPMN и BPM-движков
BPMN простая и удобная нотация. В базовом виде её понимает 100% человек. Это упрощает коммуникации при разработке софта, процедур для сотрудников или бизнес-процессов на предприятии.
Это самые простые значки BPMN
Нотация обладает выразительной палитрой (больше 400 знаков и правил их использования), которая позволяет нарисовать вообще любые процессы.
А это все возможные события, которые предусмотрены BPMN.
Есть ваш софт имеет подходящие сценарии использования, то BPM-движки сильно экономят время и нервы при разработке:
- обучить правильно рисовать схемы быстрее, чем научить человека программировать;
- менять схемы быстрее, чем переписывать код;
- некоторые значки, типа компенсации, с наскока даже непонятно как реализовать в терминах классов, методов, вызовов и таблиц в базе данных;
- BPMN, как часть BPM-движка, позволяет очень мощно обрабатывать таймеры, исключения, падения.
У меня голова начинает болеть, когда думаю, как долго и дорого похожую логику можно писать на Java. А потом её менять.
- Как правильно движки поддерживают версионирование, т.е. если транзакция зашла в одну версию, то в ней и завершится.
Когда надо использовать BPMN и BPM-движки
1. Длительные бизнес-транзакции
Для получения какого-то бизнес-результата отработали несколько человек и информационных систем, запрос полежал в ожидании, какая-то система не ответила, ответ пришлось обработать вручную и т.д.
Хорошие примеры:
- подготовка коммерческого предложения;
- оплата счёта;
- согласование доступа в информационные системы.
- калькуляция стоимости билета;
- генерация документа по шаблону;
- конвертация данных из одного формата в другой.
2. Разработка в ультрараспределённой среде
У вас 45 разных информационных систем и их нужно собрать во что-то одно, создающее конечную ценность для бизнеса.
Еще BPMN поможет визуально понимать, как в точности работает тот или иной бизнес-процесс, отображая все очереди, хуки, хранилища и прочее. Это позволит быстрее понимать где вносить изменения, когда они появятся.
3. Микросервисная архитектура
BPM-движок выступит «надмозгом» над единичными операциями, сохранит контекст процесса, пока какой-то из сервисов лежит, и поможет реализовать многосервисные тразакции вида «Всё или ничего» (saga interaction pattern).
Примерно так этот паттерн выглядит в движке Camunda
В итоге
Занимаетесь чем-то похожим, а может и свой workflow-движок пишите? Заканчивайте и берите готовый — сэкономите тысячи часов разработки.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
Когда оправдано использование микросервисной архитектуры
Микросервисы – это разновидность сервис-ориентированной архитектуры (SOA), применяемая для формирования распределенных программных систем. Модули в микросервисной архитектуре взаимодействуют по сети, при этом выполняя единую цель. На данный момент микросервисы постепенно вытесняют монолитные приложения и превращаются в стандарт развития программных систем.
Важно понимать, что под сервисом понимается целый набор услуг и определенный функционал, который предоставляют потребителю. А микросервисы – это дробление функционала так, чтобы он был доступен другим частям системы. Причем дробление функционала настолько мелкое, что внутри каждого микросервиса реализовано совсем маленькое количество функций.
Микросервисная архитектура – это несколько функциональных модулей, взаимодействующих через сеть
Принципиальное отличие микросервисной архитектуры от монолитной
Микросервисная архитектура приложения родилась из монолитной архитектуры, когда та стала сложной и неудобной в работе. Главное отличие микросервисов от монолита – в использовании специализированных более простых программ (модулей) при выполнении сценария приложения. Тогда как в монолитной архитектуре использовались внутрипроцессные взаимодействия. И, что самое удобное, модули могут находиться на разных серверах и их взаимодействие происходит через сеть по протоколонезависимой технологии.
Микросервисная архитектура имеет ряд преимуществ перед монолитной:
- симметричная архитектура (в монолитных приложениях – иерархическая);
- взаимозаменяемость микросервисов;
- независимость микросервисов друг от друга;
- организация модулей вокруг отдельных функций;
- написание микросервисов с помощью любых программных средств, оптимальных для каждого конкретного модуля, при этом они хорошо «понимают» друг друга благодаря интерфейсу. Создание интерфейса является наиболее сложной задачей;
- микросервисы вызываются только потребителем, но не друг другом.
Различие микросервисной и монолитной архитектуры
Каждый микросервис – это небольшая монолитная программа, которая выполняет свою функцию. В программный продукт при разработке микросервисной архитектуры можно добавлять любое количество новых микросервисов, расширяя его функциональность. Чтобы добиться подобного в монолитной программе, необходимо вносить изменения в основной продукт.
Принцип работы микросервисной архитектуры можно рассмотреть на бытовом примере. Допустим, мы решили воспользоваться таким сервисом, как химчистка. Мы отдаем вещь, а через время получаем ее назад чистой, выглаженной и готовой к использованию, не задумываясь о том, как это достигается и какие сервисы выполняются внутри химчистки. А таких сервисов много: принять вещь, положить в стиральную машину, запустить стирку, достать вещь, погладить, выдать и так далее.
Так же и внутри программ есть автономные функции, микросервисы, которые ранее в монолитной архитектуре прятались от потребителя. Как в случае с химчисткой, потребители обращались к функциям программы и получали результат, не задумываясь, как все сделано.
Монолитная архитектура не справлялась с потребностью бизнеса ускоряться, так как крупные сервисы сложно быстро изменять и адаптировать. Чтобы добиться ускорения, разумным решением стало создание типовых микросервисов, по-разному реализованных в крупных сервисах и выделенных в самостоятельные компоненты. Теперь каждый крупный сервис может пользоваться микросервисами по необходимости. А так как отпала нужда в дублировании типовых функций, это сделало программы более легкими и гибкими.
При микросервисной архитектуре приложения можно обновлять ПО частями, что гораздо проще и безопаснее, чем обновление «монолита». Приложение не выйдет из строя, если произойдет сбой одного или нескольких микросервисов.
Причины возникновения микросервисной архитектуры
О проблеме в использовании монолитных приложений впервые заговорили в 2005 г. на конференции Cloud Computing. Большие цельные программы стали слишком неудобными в разработке, не давали нужной скорости внедрения и функциональности, сложно тестировались и долго вводились в эксплуатацию. Они не позволяли быстро вносить поправки и оперативно реагировать на изменения бизнес-требований.
Уже тогда микросервисы назвали новой ступенью развития архитектуры, которая обеспечит приложениям необходимую гибкость и легкость. Термин «микросервисы» закрепился в 2011 г. при разработке программного обеспечения, содержащего модули, – но это больше относится к SOA. В 2012 г. термин был принят окончательно, но значение, которое мы используем сегодня, приобрел недавно.
Микросервисы в современном понимании имеют следующие особенности:
- легкость и простота: каждый модуль выполняет уникальную функцию и имеет небольшой размер;
- конечность, атомарность;
- гибкость: модуль можно легко изменить, добавив в его работу необходимые опции;
- взаимозаменяемость;
- полиморфизм;
- комбинирование микросервисов для реализации разных функций.
Микросервисная архитектура устранила недостатки монолитного ПО, обеспечив:
- изоляцию и минимизацию изменений;
- ускорение разработки;
- возможность легко подстраивать ПО под структуру бизнеса.
Необходимость ускорения работы
Одна из ключевых особенностей современного бизнеса – динамичность. Кто первым вышел на рынок, тот и получает конкурентное преимущество. Кто быстрее вносит необходимые изменения и внедряет улучшения, тот получает большую долю рынка. Все это приводит к тому, что необходимо искать пути ускорения работы, в том числе и программных продуктов.
Как только в программе появляются повторяющиеся моменты или дублирующиеся функции, тогда и возникает необходимость в переходе на микросервисные компоненты. Чтобы не плодить в разных частях системы тысячи микрофункций, лучше разбить большой модуль на атомарные функции. Причем деление происходит до тех пор, пока не получается вычленить отдельные функции.
Если ранее монолитные сервисы реализовывали конкретные бизнес-функции, то сегодня микросервисы самостоятельных бизнес-функций не несут. Огромный плюс такой архитектуры в том, что можно реализовывать новые бизнес-функции, используя набор существующих микросервисов. Это преимущество микросервисного подхода объясняет его востребованность. Кроме того, каждый модуль можно строить индивидуально с использованием оптимальных средств разработки.
Разделяя «монолит» на микросервисы, девелопер получает возможность распараллеливания разработки, что значительно сокращает сроки выполнения.
Компоненты микросервисной архитектуры разрабатываются и работают параллельно
Когда разные модули разработаны, остается просто собрать их в единую систему. При этом каждый отдельный микросервис легко трансформировать в соответствии с меняющимися требованиями рынка, не мешая при этом работе всего приложения.
Быстрый ввод в эксплуатацию
Отладка работы ПО с микросервисной архитектурой – более быстрый процесс, чем отладка работы «монолита». Разработчик легко может отслеживать взаимодействие между разными микросервисами, быстрее находить и устранять ошибки.
Это позволяет в короткие сроки реализовать крупные программные продукты. Независимая эволюция подсистем дает возможность совершенствовать продукт, не изменяя при этом его сути.
Микросервисы обеспечивают эффективный подход к разработке, который дает возможность:
- разрабатывать одно приложение нескольким автономным командам;
- использовать разные стеки по необходимым задачам для единого продукта;
- осуществлять децентрализованное управление данными, если это требуется для бизнеса.
Необходимость подстраивать сервис под структуру бизнеса
С изменением структуры бизнеса почти всегда возникает необходимость в подстройке ПО под новые требования. Внесение изменений и последующая отладка монолитного программного обеспечения – трудоемкая задача. И сроки подстройки пропорциональны размерам и сложности приложения.
Но если бизнес изменился и в нем добавились новые функции, уже не нужно полностью переделывать старую программу или заказывать новое ПО. Достаточно создать несколько новых микросервисов, которые помогут реализовать необходимые задачи. Это быстро, дешево и удобно.
Когда назревает необходимость в модернизации микросервисной архитектуры, разработчики определяют модули, в которые надо внести изменения, выясняют, какие нужно создать уникальные микросервисы. Доработка отдельных компонентов и отладка их работы занимают меньше времени, чем модернизация монолитного ПО.
Перспективы использования микросервисов в бизнесе
Переход с монолитной архитектуры на микросервисы делает бизнес более мобильным и гибким. Компания получает в свое распоряжение программу-конструктор, которая может оперативно подстраиваться под нужды бизнеса.
Дополнительным плюсом использования микросервисов для реализации бизнес-функций является их одинаковая работа в разных системах. Например, используя в разных системах один и тот же микросервис, выдающий паспортные данные клиента по запросу, мы везде получим идентичный результат в одинаковом виде. Это является гарантией стабильного качества работы ПО.
Микросервисная архитектура позволяет легко переконфигурировать и усовершенствовать ПО
Для больших приложений корпоративного масштаба использование микросервисной архитектуры – оптимальное решение, позволяющее быстро реагировать на изменение рынка.
Внедрение микросервисов дает следующие преимущества бизнесу:
- оперативное расширение и совершенствование функций без затрагивания других микросервисов;
- тестирование новых функций без затрагивания рабочих – это возможно благодаря замене или добавлению микросервисов в систему;
- безопасное внедрение инноваций;
- взаимозаменяемость модулей;
- готовность к горизонтальному и вертикальному масштабированию;
- возможность распределения;
- бесперебойная работа всех компонентов и системы в целом даже при отказе ряда микросервисов;
- централизованное внесение изменений.
Использование микросервисной архитектуры оправдано, если какой-либо функционал приложения переиспользуется. Такой подход даст необходимую гибкость, мобильность и масштабируемость бизнесу.
Наша компания исследует ваш бизнес и предложит оптимальный вариант разработки программного обеспечения. Специалисты HHI быстро и качественно проведут тестирование и внедрение.