5 rzeczy, które powinieneś wiedzieć o Camunda 8
Platforma Camunda może pochwalić się ustabilizowaną pozycją na rynku. Jej początki sięgają 18 marca 2013 roku, kiedy to po raz pierwszy wydana została jako otwarte oprogramowanie i udostępniona szerokiemu gronu odbiorców. Od tego czasu jej właściciele (niemiecka firma o tej samej nazwie) stale rozwijali platformę, dodając nowe funkcjonalności i ulepszając już istniejące. Obecnie Camunda jest jednym z najpopularniejszych i najczęściej stosowanych narzędzi BPM, z tysiącami użytkowników i setkami wdrożeń na całym świecie.
12 kwietnia 2022 r. Camunda ogłosiła przełomowe wieści: wydanie zupełnie nowej wersji platformy, czyli Camundy 8, określonej mianem The Universal Process Orchestrator. Wydawcy platformy postanowili sprostać dzisiejszym wymaganiom biznesowym, w których centrum znajdują się takie aspekty jak wydajność, dostępność i skalowalność rozwiązań software’owych. W nowej wersji Camunda umożliwia zarządzanie różnymi typami procesów biznesowych, w tym procesami przepływu pracy (workflow), procesami decyzyjnymi (decision) oraz procesami zdarzeniowymi (event-driven). Integruje się również z różnymi systemami, dzięki czemu może działać jako narzędzie do zarządzania procesami biznesowymi na wielu poziomach organizacji, niezależnie od rodzaju procesu i używanych technologii.
Efektem prac nad nową wersją platformy było przede wszystkim zaprojektowanie i wdrożenie całkowicie nowego silnika procesowego, Zeebe (nowoczesne rozwiązanie cloud-native, od samego początku stworzone z myślą o pracy w chmurze).
Camunda 8. Nowe komponenty
Camunda w wersji 8 składa się z kilku rodzajów komponentów.
Komponenty skierowane do użytkownika:
- Modeler (modelowanie i wdrażanie diagramów procesów BPMN i DMN),
- Tasklist (zarządzanie pracą ludzką),
- Operate (monitoring, analiza i rozwiązywanie problemów z uruchomionymi procesami),
- Optimize (wykorzystywanie danych procesowych do analizy obszarów wymagających poprawy, np. znajdowanie wąskich gardeł w procesach).
Komponenty podstawowe (corowe):
- Workflow Engine, zasilany przez Zeebe (silnik procesowy, odpowiadający za automatyzację procesów na szeroką skalę),
- Decision Engine (silnik decyzyjny, pozwalający na automatyzację podejmowania decyzji w ramach procesów biznesowych),
- Helm charts (zestaw plików służących do zautomatyzowania procesu wdrażania aplikacji w środowisku Kubernetes),
- Connectors (komponenty oprogramowania umożliwiające integrację różnych systemów, baz danych, aplikacji itp.).
1. Camunda Zeebe – nowy silnik procesowy
Największą różnicą między Camunda 7 a Camunda 8 jest wprowadzenie nowego silnika procesowego o nazwie Zeebe. Silnik został zaprojektowany z myślą o skalowaniu w poziomie (horizontal scaling), co oznacza, że można go łatwo dostosować do rosnących potrzeb i wymagań biznesowych. Umożliwia elastyczną obsługę dużych i skomplikowanych procesów biznesowych, a także zapewnia większą niezawodność i wydajność w środowiskach rozproszonych.
Do budowy Zeebe wykorzystano architekturę sterowaną zdarzeniami (Event-Driven Architecture / EDA), co oznacza, że procesy biznesowe wykonywane są w oparciu o przepływ zdarzeń, a nie sztywny sekwencyjny proces. Dzięki temu można łatwo dodawać lub usuwać węzły w klastrze, a procesy biznesowe będą automatycznie przypisywane do dostępnych węzłów. Taki elastyczny model skalowania poziomego umożliwia osiągnięcie wysokiej dostępności, wydajności i skalowalności, co jest kluczowe dla złożonych procesów biznesowych.
Architektura Zeebe składa się z trzech głównych elementów:
- Broker Zeebe — centralny serwer w architekturze Zeebe, który odpowiada za zarządzanie procesami biznesowymi i komunikację z innymi serwerami w klastrze. Może obsłużyć wiele tysięcy procesów biznesowych jednocześnie, dzięki czemu jest skalowalny w poziomie.
- Worker — serwer aplikacji uruchamiany na maszynach, na których wykonują się zadania procesowe. Workerzy pobierają zadania z brokera Zeebe i wykonują je, a następnie zwracają wynik do brokera.
- Klient — aplikacja kliencka używana do modelowania, uruchamiania i monitorowania procesów biznesowych. Klienci komunikują się z brokerem Zeebe za pomocą protokołu gRPC, który zapewnia niskie opóźnienia i wysoką wydajność.
Broker Zeebe i Workerzy mogą być uruchamiani w kontenerach Dockera lub jako aplikacje w środowisku chmurowym, co pozwala na łatwe wdrażanie i skalowanie silnika procesowego Zeebe w różnych środowiskach.
2. Camunda Decision Engine – nowy silnik decyzyjny
Decision Engine (silnik decyzyjny) to jedna z najważniejszych nowych funkcjonalności w Camunda 8, która pozwala na integrację silnika procesowego z silnikiem decyzyjnym DMN (Decision Model and Notation). Wprowadzony został jako nowy moduł silnika BPMN oraz zintegrowany z silnikiem DMN 1.3, który pozwala na modelowanie i wykonanie złożonych decyzji biznesowych, opartych na regułach i danych wejściowych, analizowanych w czasie rzeczywistym.
Decision Engine w Camunda 8 umożliwia automatyczne wywoływanie modeli DMN z poziomu procesów BPMN i przekazywanie im danych wejściowych. W odpowiedzi silnik DMN wybiera najlepsze reguły decyzyjne na podstawie danych wejściowych i zwraca wynik do procesu BPMN. W ten sposób decyzje biznesowe podejmowane są w sposób szybszy, bardziej efektywny i mniej podatny na błędy ludzkie.
Innym ważnym elementem Decision Engine jest wbudowane narzędzie DMN Simulator, które pozwala na testowanie modeli DMN przed ich wdrożeniem. Umożliwia to symulowanie różnych scenariuszy biznesowych i sprawdzanie, jakie decyzje zostaną podjęte przez silnik DMN, co pozwala na lepsze zrozumienie i optymalizację procesów biznesowych.
3. Camunda 8 – no database
W poprzednich wersjach Camunda silnik BPMN oparty był na bazie danych, która przechowywała informacje o procesach biznesowych, zadaniach, historii zadań itp. Nowością jest fakt, że Camunda 8 nie wymaga już tradycyjnej relacyjnej bazy danych. W nowej architekturze dane o procesach biznesowych i instancjach procesów przechowywane są w tzw. Event Store, który jest specjalnym repozytorium zdarzeń, zapisywanych w sekwencji czasowej. Event Store przechowuje informacje o wszystkich zmianach, jakie zachodzą w procesach biznesowych, a te zdarzenia wykorzystywane są do tworzenia stanu aktualnego procesu.
Przejście na architekturę no database pozwala na uzyskanie większej elastyczności i skalowalności, ponieważ nie ma już konieczności utrzymywania tradycyjnej bazy danych i jej optymalizowania. Ponadto, dzięki zastosowaniu Event Store, można łatwo skalować procesy biznesowe w Camunda 8, co umożliwia obsługę większych obciążeń i zwiększenie wydajności.
4. Cloud-native deployment
Camunda 8 została zaprojektowana jako rozwiązanie cloud-native, co oznacza, że jest dostosowana do pracy w środowisku chmurowym i wykorzystuje wiele funkcjonalności chmury. Oto kilka cech, które pozwalają na klasyfikowanie Camunda 8 jako cloud-native:
- Elastyczność. Camunda 8 jest łatwo skalowalna, co oznacza, że może być dostosowana do różnych rozmiarów obciążeń i ilości danych.
- Bezstanowość. Nowa wersja Camundy nie wymaga przechowywania stanu między żądaniami, co ułatwia jej uruchamianie w kontenerach.
- Mikrousługi. Platforma składa się z wielu mikrousług, które można uruchamiać niezależnie od siebie (ułatwia to również skalowanie).
- Architektura oparta na zdarzeniach. Camunda 8 wykorzystuje architekturę opartą na zdarzeniach, co pozwala na integrację z innymi usługami i systemami.
- Obsługa kontenerów. Platforma została zaprojektowana w taki sposób, aby działać w kontenerach (np. Docker i Kubernetes), co ułatwia jej wdrożenie w środowisku chmurowym.
5. Zmiany w modelu licencyjnym w Camunda 8
W wersji Camunda 8 zaszły istotne zmiany dotyczące modelu licencjonowania. Dotychczas, korzystając z Camundy 7 w wersji Community, mogliśmy korzystać z silnika BPM oraz dostarczonych komponentów (Tasklist, Cockpit, Admin) niezależnie od tego, czy używaliśmy ich w środowisku testowym, czy produkcyjnym. Oczywiście komponenty miały pewne ograniczenia funkcjonalne, które utrudniały wykorzystanie Camundy na produkcji, ale nie uniemożliwiały tego całkowicie.
W wersji 8 Camunda Community wprowadzono zasadę, że dodatkowe komponenty (Task List oraz Operate, które zastąpiły Cockpit i Optimize) mogą być używane tylko i wyłącznie w środowisku nieprodukcyjnym. Zasada dotycząca wykorzystania samego silnika BPM pozostała niezmieniona. Co to oznacza w praktyce?
Niestety, aby używać Camunda 8 Community Edition w środowisku produkcyjnym i korzystać z wysokiej wydajności silnika BPM, musisz zakupić licencję Camunda Enterprise lub poszukać alternatyw dla wymienionych wyżej komponentów.
Przeczytaj też:
Przeczytaj więcej na ten temat
