Este é um artigo traduzido originalmente publicado no blog do Kai Waehner: "Apache Kafka as Workflow and Orchestration Engine". Assine a newsletter do Kai para se manter atualizado com novas publicações.
A automação de processos de negócios com um mecanismo de workflow ou conjunto de BPM existe há décadas. No entanto, usar a plataforma de streaming de dados Apache Kafka como a espinha dorsal de um mecanismo de workflow oferece melhor escalabilidade, maior disponibilidade e arquitetura simplificada. Esta postagem explora estudos de caso em vários setores para mostrar como empresas como Salesforce ou Swisscom implementam automação e orquestração de fluxo de trabalho com estado com Kafka.
A automação de processos de negócios com um mecanismo de workflow ou conjunto de BPM existe há décadas. No entanto, usar a plataforma de streaming de dados Apache Kafka como a espinha dorsal de um mecanismo de workflow oferece melhor escalabilidade, maior disponibilidade e arquitetura simplificada . Esta postagem explora os conceitos por trás do uso do Kafka para persistência com processamento de dados com estado e quando usá-lo em vez disso ou com outras ferramentas. Estudos de caso em vários setores mostram como empresas como Salesforce ou Swisscom implementam automação e orquestração de workflow com estado com Kafka.
O que é um mecanismo de workflow para orquestração de processos?
Um mecanismo de workflow é um aplicativo de software que orquestra atividades humanas e automatizadas . Ele cria, gerencia e monitora o estado das atividades em um processo de negócios, como o processamento e a aprovação de uma reclamação em um caso de seguro, e determina a atividade extra para a qual deve fazer a transição de acordo com os processos de negócios definidos. Às vezes, esse software é chamado de mecanismo de orquestração.
Os mecanismos de workflow têm faces distintas . Algumas pessoas se concentram principalmente em suítes de BPM. Outros veem as ferramentas de integração de codificação visual, como o Dell Boomi, como um workflow e um mecanismo de orquestração. Para streaming de dados com Apache Kafka, o Confluent Stream Designer permite a criação de pipelines com uma abordagem de baixo código/sem código.
E Gestão de Processos de Negócios (BPM)?
A workflow engine is a core business process management (BPM) component. BPM is a broad topic with many definitions. From a technical perspective, when people talk about workflow engines or orchestration and automation of human and automated tasks, they usually mean BPM tools.
“ O gerenciamento de processos de negócios (BPM) é uma abordagem disciplinada para identificar, projetar, executar, documentar, medir, monitorar e controlar processos de negócios automatizados e não automatizados para alcançar resultados consistentes e direcionados alinhados com as metas estratégicas de uma organização. O BPM envolve a definição, melhoria, inovação e gerenciamento deliberados, colaborativos e cada vez mais auxiliados pela tecnologia de processos de negócios de ponta a ponta que impulsionam resultados de negócios, criam valor e permitem que uma organização atinja seus objetivos de negócios com mais agilidade. O BPM permite que uma empresa alinhe seus processos de negócios à sua estratégia de negócios, levando a um desempenho geral eficaz da empresa por meio demelhorias de atividades de trabalho específicas dentro de um departamento específico, em toda a empresa ou entre organizações . “
Ferramentas para automação de workflow: BPMS, ETL e iPaaS
Um conjunto de BPM (BPMS) é um conjunto tecnológico de ferramentas projetadas para ajudar os profissionais de BPM a atingir seus objetivos. Há cerca de 10 anos, tive uma palestra na ECSA 2014 em Viena: “ A próxima geração de BPM para um mundo de big data: suítes inteligentes de gerenciamento de processos de negócios (iBPMS) ”. Portanto, você vê há quanto tempo essa discussão já existe.
Trabalhei para TIBCO e usei produtos como ActiveMatrix BPM e TIBCO BusinessWorks. Hoje, a maioria das pessoas usa mecanismos de código aberto como Camunda ou SaaS de provedores de serviços em nuvem. A maioria dos BPMS legados proprietários que vi há dez anos não tem mais presença nas empresas. E muitos fornecedores relevantes hoje não usam mais o termo BPM por razões táticas 🙂
Alguns fornecedores de BPM, como a Camunda, também avançaram com serviços de nuvem totalmente gerenciados ou novos mecanismos (mais nativos da nuvem e escaláveis) como o Zeebe. Como nota lateral: gostaria que Camunda tivesse construído Zeebe em cima de Kafka em vez de construir seu próprio motor com características semelhantes. Eles devem investir muito em escalabilidade e confiabilidade, em vez de se concentrar em uma ótima ferramenta de automação de workflow. Não tenho certeza se isso compensa.
Traditional ETL and data integration tools fit into this category, too. Their core function is to automate processes (from a different angle). Cloud-native platforms like MuleSoft or Dell Boomi are called Integration Platform as a Service (iPaaS). I explored the differences between Kafka and iPaaS in a separate article.
This is NOT Robotic Process Automation (RPA)!
Before I look at the relationship between data streaming with Kafka and BPM workflow engines, it is essential to separate another group of automation tools: Robotic process automation (RPA).
RPA é outra forma de automação de processos de negócios que depende de robôs de software. Essa tecnologia de automação costuma ser vista como inteligência artificial (IA), embora geralmente seja uma automação mais descomplicada de tarefas humanas.
Nas ferramentas tradicionais de automação de workflow, um desenvolvedor de software produz uma lista de ações para automatizar uma tarefa e interface com o sistema de back-end usando APIs internas ou linguagem de script dedicada.
Por outro lado, os sistemas RPA desenvolvem a lista de ações observando o usuário executar essa tarefa na interface gráfica do usuário (GUI) do aplicativo e, em seguida, executam a automação repetindo essas tarefas diretamente na GUI . Isso pode reduzir a barreira ao uso de automação em produtos que, de outra forma, não apresentam APIs para essa finalidade.
O RPA é excelente para automação de workflow herdado que requer repetição de ações humanas com uma GUI . Este é um problema de negócios diferente. É claro que existem sobreposições. Por exemplo, o Quadrante Mágico do Gartner para RPA não inclui apenas fornecedores de RPA como UiPath, mas também BPM tradicional ou fornecedores de integração como Pegasystems ou MuleSoft (Salesforce) que entram neste negócio. As ferramentas RPA se integram bem ao Kafka. Além disso, eles estão fora do escopo deste artigo, pois resolvem um problema diferente dos mecanismos de workflow Kafka ou BPM .
Fluxo de dados com mecanismos de workflow Kafka e BPM: amigos ou inimigos?
Um mecanismo de workflow, respectivamente um conjunto de BPM, tem diferentes objetivos e pontos ideais em comparação com tecnologias de streaming de dados como o Apache Kafka . Portanto, essas tecnologias são complementares . Não é surpresa que a maioria das ferramentas de BPM tenha adicionado suporte para Apache Kafka (o padrão de fato para streaming de dados) em vez de apenas oferecer suporte à integração de solicitação-resposta com interfaces de serviços da Web como HTTP e SOAP/WSDL, semelhante a qualquer ferramenta ETL e Enterprise Service Bus (ESB) tem conectores Kafka hoje.
Este artigo explora estudos de caso específicos que utilizam Kafka para orquestração de processos de negócios com estado. Não vejo mais mecanismos de BPM e workflow iniciando muitos novos projetos. Muitas tarefas de automação são feitas com streaming de dados em vez de adicionar outro mecanismo à pilha “apenas para automação de processos de negócios” . Ainda assim, embora as técnicas se sobreponham, elas são complementares. Por isso, eu digo que são um pouco dos dois, amigos e inimigos.
Quando usar Apache Kafka em vez de BPM Suites/Workflow Engines?
Para ser bem claro inicialmente: o Apache Kafka não pode e não substitui os mecanismos BPM! Muitas nuances devem ser avaliadas para escolher a ferramenta ou combinação certa. E ainda vejo clientes usando ferramentas de BPM e integrando-as ao Kafka.
Camunda fez um ótimo trabalho semelhante ao Confluent, trazendo o núcleo de código aberto para uma solução corporativa e, finalmente, um serviço de nuvem totalmente gerenciado. Portanto, este é o mecanismo de BPM número um que vejo no campo; mas não é como se eu visse isso toda semana em reuniões com clientes.
Kafka como hub de dados com estado e BPM para interação humana
Portanto, com mais de 10 anos de experiência com integração e mecanismos de BPM, aqui está meu guia para escolher a ferramenta certa para o trabalho:
O streaming de dados com Kafka tornou-se o hub de dados em tempo real escalável na maioria das empresas para processar dados e desacoplar aplicativos. Portanto, muitas vezes esse é o ponto de partida para olhar para a automação de um novo processo de negócios, seja um pequeno ou grande volume de dados, sejam dados transacionais ou analíticos .
Se o seu processo de negócios for complexo e não puder ser facilmente definido ou modelado sem o BPMN, vá em frente . Os mecanismos de BPM fornecem codificação visual e implantação/monitoramento do processo automatizado. Mas não modele todos os processos de negócios da empresa . Em um mundo muito ágil, o time-to-market e as estratégias de negócios em constante mudança não são mais fáceis se muito tempo for gasto em diagramas (desatualizados). Esse não é o objetivo do BPM, é claro. Mas já vi muitas visualizações antigas e imprecisas de BPMN ou UML em reuniões com clientes.
Se você ainda não tem o Kafka e precisa apenas de alguma automação de alguns processos , pode começar com um mecanismo de workflow BPM . No entanto, tanto o streaming de dados quanto o BPM são plataformas estratégicas. Uma ferramenta simples como IFTTT (“If This Then That”) pode fazer o trabalho bem para automatizar alguns fluxos de trabalho com interação humana em um único domínio.
O ponto ideal de uma ferramenta de orquestração de processo é um processo de negócios que requer tarefas automatizadas e manuais . O mecanismo de workflow BPM orquestra a interação humana complexa em conjunto com processos automatizados (seja interfaces de streaming/mensagens, chamadas de API ou processamento de arquivos). As ferramentas de orquestração de processos oferecem suporte aos desenvolvedores com recursos agradáveis para gerar UIs para formulários humanos em aplicativos móveis ou navegadores da web.
Streaming de dados como o mecanismo de workflow com estado ou com outra ferramenta de BPM?
TL;DR: Via Kafka como hub de dados, você já acessa todos os dados em outras plataformas . Avalie por caso de uso e projeto se ferramentas como Kafka Streams podem implementar e automatizar o processo de negócios ou se um mecanismo de workflow dedicado é melhor. Ambos se integram muito bem. Muitas vezes, uma combinação de ambos é a escolha certa.
Dizer que Kafka é muito complexo não conta mais (na nuvem), pois está a apenas um clique de distância por meio de pagamento conforme o uso totalmente gerenciado e suportado com ofertas SaaS como o Confluent Cloud.
Neste blog, quero compartilhar algumas histórias em que os fluxos de trabalho com estado foram automatizados nativamente com streaming de dados usando Kafka e seu ecossistema, como Kafka Connect e Kafka Streams.
Para saber mais sobre os estudos de caso de BPM, consulte Camunda e fornecedores semelhantes. Eles fornecem excelentes estudos de caso de sucesso e alguns casos de uso combinam o mecanismo de workflow com o Kafka.
Apache Kafka como mecanismo de workflow e orquestração
O Apache Kafka se concentra no fluxo de dados, ou seja, integração de dados em tempo real e processamento de fluxo. No entanto, a funcionalidade principal do Kafka inclui características de banco de dados como persistência, alta disponibilidade, ordenação garantida, APIs de transação e recursos de consulta (limitados). Kafka é algum tipo de banco de dados, mas não tenta substituir outros como Oracle, MongoDB, Elasticsearch, et al .
Apache Kafka como camada de persistência com estado e confiável
Algumas das funcionalidades do Kafka permitem implementar a automação de fluxos de trabalho . Isso inclui processamento com estado:
O log de confirmação distribuído fornece persistência, confiabilidade e ordem garantida . Armazenamento em camadas (disponível apenas por meio de alguns fornecedores ou serviços em nuvem atualmente) torna o armazenamento de big data de longo prazo econômico e escalável.
A reprodutibilidade dos dados históricos é crucial para retroceder eventos em caso de falha ou outros problemas no processo de negócios. Timestamps de eventos, em combinação com um design inteligente dos Tópicos Kafka e Partições relacionadas, permitem a separação de preocupações.
Enquanto um tópico Kafka é a fonte da verdade para todo o histórico com ordenação garantida, um tópico compactado pode ser usado para pesquisas rápidas do estado atual atualizado . Essa combinação permite o armazenamento de informações para sempre e atualiza as informações existentes com o estado atualizado. Além disso, consultando os dados por meio de solicitação de chave/valor.
O processamento de fluxo com Kafka Streams ou KSQL permite manter o estado atual de um processo de negócios no aplicativo , mesmo a longo prazo, por meses ou anos. As consultas interativas sobre os aplicativos de streaming permitem consultas de API em relação ao estado atual em microsserviços (como uma alternativa centrada no aplicativo ao uso de tópicos compactados).
Kafka Connect com conectores para SaaS nativo da nuvem e sistemas legados , clientes para muitas linguagens de programação (incluindo Java, Python, C++ ou Go) e outras interfaces de API, como o REST Proxy, integram-se a qualquer fonte de dados ou coletor de dados necessários para automação de processos de negócios.
O Schema Registry garante a aplicação de contratos de API (= esquemas) em todos os produtores e consumidores de eventos.
Algumas distribuições Kafka e serviços em nuvem adicionam governança de dados, aplicação de políticas e recursos avançados de segurança para controlar o fluxo de dados e questões de privacidade/conformidade.
O Saga Design Pattern para Stateful Orchestration com Kafka
O Apache Kafka oferece suporte à semântica e transações exatamente uma vez no Kafka . As transações geralmente são necessárias para automatizar processos de negócios. No entanto, uma infraestrutura escalável nativa da nuvem como Kafka não usa transações XA com o protocolo two-phase commit (como você deve saber do Oracle e do IBM MQ) se transações separadas em diferentes bancos de dados precisarem ser executadas. Isso não escala bem. Portanto, esta não é uma opção.
Saiba mais sobre transações em Kafka (incluindo as compensações) em uma postagem de blog dedicada: “ Apache Kafka for Big Data Analytics AND Transactions “.
Às vezes, outra alternativa é necessária para automação do workflow com requisitos de transação. Bem-vindo a um padrão de design de fusão que se originou com arquiteturas de microsserviço: O padrão de design SAGA é um conceito crucial para implementar a orquestração de estado se uma transação no processo de negócios abrange vários aplicativos ou chamadas de serviço. O padrão SAGA permite que um aplicativo mantenha a consistência de dados em vários serviços sem usar transações distribuídas .
Em vez disso, o padrão SAGA usa um controlador que inicia uma ou mais “transações” (= chamadas de serviço regulares sem garantia de transação) e só continua depois que todas as chamadas de serviço esperadas retornam a resposta esperada:
O Order Servicerecebe a POST /ordersrequisição e cria o Create Orderorquestrador da saga
O orquestrador da saga cria um Orderno PENDINGestado
Em seguida, ele envia um Reserve Creditcomando para oCustomer Service
As Customer Servicetentativas de reserva de crédito
Em seguida, ele envia de volta uma mensagem de resposta indicando o resultado
O orquestrador da saga aprova ou rejeita aOrder
Encontre mais detalhes do exemplo acima na explicação detalhada de microservices.io sobre o padrão SAGA .
Estudos de caso para automação de workflow e orquestração de processos com Apache Kafka
Reading the above sections, you should better understand Kafka’s persistence capabilities and the SAGA design pattern. Many business processes can be automated at scale in real-time with the Kafka ecosystem. There is no need for another workflow engine or BPM suite.
Learn from interesting real-world examples of different industries:
Digital Native: Salesforce
Financial Services: Swisscom
Insurance: Mobiliar
Open Source Tool: Kestra
Salesforce: Web-scale Kafka Workflow Engine
Salesforce built a scalable real-time workflow engine powered by Kafka.
Why? The company recommends to “use Kafka to make workflow engines more reliable”.
At Current 2022, Salesforce presented their project for workflow and process automation with a stateful Kafka engine. I highly recommend checking out the entire talk, or at least the slide deck. Salesforce introduced a workflow engine concept that only uses Kafka to persist state transitions and execution results. The system banks on Kafka’s high reliability, transactionality, and high scale to keep setup and operating costs low. The first target use case was the Continuous Integration (CI) systems.
Uma demo do sistema foi apresentada:
Parallel and nested CI workflow definitions of varying declaration formats
Real-time visualization of progress with the help of Kafka.
Chaos and load generation to showcase how retries and scale-ups work.
Pontos de extensão
Comparando a implementação com outros mecanismos de workflow populares
Aqui está um exemplo da arquitetura do workflow:
Tópicos compactados como a espinha dorsal do mecanismo de workflow com estado TL;DR da apresentação do Salesforce: Kafka é uma escolha viável como a camada de persistência para problemas em que você precisa fazer o processamento da máquina de estado .
Algumas notas sobre as vantagens que o Salesforce apontou para usar o Kafka em vez de outros bancos de dados ou ferramentas de CI/CD :
O único componente com estado é Kafka -> Dominando a configuração de confiabilidade
Kafka was chosen as the persistence layer -> SLAs / reliability better than with a database/sharded Jenkings/NoSQL -> Four nines (+ horizontal scaling) instead of three nines (see slide “reliability contrast”)
Restart K8S clusters and CI workflows again easily
Kafka State Topic -> Store the full workflow graph in each message (workflow Protobuf with defined schemas)
Compacted Topic updates states: not started, running, complete -> Track, manage, and count state machine transitions
A implementação do Salesforce é de código aberto e está disponível no Github : “Junction Workflow é um mecanismo de workflow futuro que usa tópicos Kafka compactados para gerenciar transições de estado de fluxos de trabalho que os usuários passam para ele. Ele foi projetado para aceitar vários formatos de definição de fluxo de trabalho.”
Swisscom Custodigit: Investimentos seguros em cripto com streaming e orquestração de dados de estado
Custodigit é uma plataforma bancária moderna para ativos digitais e criptomoedas . Ele fornece recursos e garantias cruciais para investimentos criptográficos seriamente regulamentados:
Armazenamento seguro de carteiras
Enviando e recebendo no blockchain
Negociação através de corretoras e bolsas
Ambiente regulamentado (um aspecto fundamental e nenhuma surpresa, pois este produto vem da Suíça; um mercado muito regulamentado)
Infelizmente, os diagramas de arquitetura a seguir estão disponíveis apenas na Alemanha. Mas acho que você conseguiu os pontos. Com o padrão SAGA, a Custodigit aproveita Kafka Streams para orquestração de estado .
A arquitetura de microsserviço Custodigit usa microsserviços para integração com corretoras financeiras, bolsas de valores, blockchains de criptomoedas como Bitcoin e trocas de criptomoedas:
Custodigit implementa o padrão SAGA para orquestração de estado . A lógica de negócios sem estado é verdadeiramente desacoplada, enquanto o orquestrador de saga mantém o estado para coreografia entre os outros serviços:
Swiss Mobiliar: dissociação e orquestração do workflow
A Swiss Mobiliar (Schweizerische Mobiliar, também conhecida como Die Mobiliar) é a seguradora privada mais antiga da Suíça. O Event Streaming alimentado por Apache Kafka com Kafka oferece suporte a vários casos de uso na Swiss Mobiliar:
Aplicativo orquestrador para rastrear o estado de um processo de cobrança
Kafka como banco de dados e Kafka Streams para processamento de dados
Agregações stateful complexas em contratos e recálculos
Monitoramento contínuo em tempo real
A arquitetura da Mobiliar mostra o desacoplamento de aplicativos e a orquestração de eventos:
Aqui você pode ver as estruturas de dados e os estados definidos nos contratos de API e aplicados por meio do Schema Registry:
Além disso, confira o webinar sob demanda com Mobiliar e Spoud para saber mais sobre o uso do Kafka.
Kestra: mecanismo de workflow Kafka de código aberto e plataforma de agendamento
Kestra é uma plataforma de orquestração e agendamento infinitamente escalável, criando, executando, agendando e monitorando milhões de pipelines complexos. O projeto é de código aberto e está disponível no GitHub:
🔀 Qualquer tipo de workflow: fluxos de trabalho podem começar simples e progredir para sistemas mais complexos com ramificação, tarefas paralelas e dinâmicas, dependências de fluxo
🎓 Fácil de aprender: os fluxos estão em linguagem simples e descritiva definida em YAML — você não precisa ser um desenvolvedor para criar um novo fluxo.
🔣 Fácil de extensão: os plug-ins estão por toda parte no Kestra, muitos estão disponíveis na equipe principal do Kestra, mas você pode criar um facilmente.
🆙 Quaisquer gatilhos : o Kestra é baseado em eventos - você pode acionar uma execução de API, programação, detecção, eventos
💻 Uma interface de usuário avançada: a interface da Web integrada permite que você crie, execute e monitore todos os seus fluxos - não é necessário implantar seus fluxos, apenas editá-los.
⏩ Aproveite a escalabilidade infinita : Kestra é construída em torno das principais tecnologias nativas da nuvem - dimensione para milhões de execuções sem estresse.
Este é um excelente projeto com uma interface do usuário legal de arrastar e soltar:
Copiei a descrição do projeto. Confira o projeto de código aberto para obter mais detalhes.
E o Apache Flink para orquestração de workflow de streaming e BPM?
Esta postagem abordou vários estudos de caso para o ecossistema Kafka como um mecanismo de orquestração de workflow com estado para automação de processos de negócios. O Apache Flink é uma estrutura de processamento de fluxo que complementa o Kafka e tem uma adoção significativa.
Os estudos de caso acima usaram o Kafka Streams como o mecanismo de processamento de fluxo com estado. É uma escolha brilhante se você deseja incorporar a lógica do workflow em seu próprio aplicativo/microsserviço/contêiner .
O Apache Flink tem outros pontos positivos: poderosa análise de estado, lote unificado e processamento em tempo real, suporte ANSI SQL e muito mais. Em uma postagem de blog detalhada, explorei as diferenças entre Kafka Streams e Apache Flink para processamento de stream .
Apache Flink para processamento de eventos complexos (CEP) e consultas entre clusters
Os seguintes recursos diferenciadores tornam o Flink uma excelente escolha para alguns fluxos de trabalho :
Processamento de eventos complexos (CEP) : o CEP gera novos eventos para acionar a ação com base em situações que detecta em vários fluxos de eventos com eventos de diferentes tipos (situações que se acumulam ao longo do tempo e do espaço). O Event Stream Processing (ESP) detecta padrões sobre fluxos de eventos com eventos homogêneos (ou seja, padrões ao longo do tempo). A poderosa API de padrões do FlinkCEP permite que você defina seqüências de padrões complexos que você deseja extrair de seu fluxo de entrada para detectar possíveis correspondências .
“Ler uma vez, escrever muitas” : Flink permite análises diferentes sem precisar preparar o tópico Kafka várias vezes. Por exemplo, duas consultas no mesmo tópico Kafka como “CTAS .. * FROM mytopic WHERE eventType=1” e “CTAS .. * FROM mytopic WHERE eventType=2” podem ser agrupadas . O plano de consulta fará apenas uma leitura. Isso difere fundamentalmente dos mecanismos de processamento de fluxo nativos do Kafka, como Kafka Streams ou KQL.
Consultas entre clusters : o processamento de dados em diferentes tópicos Kafka de clusters Kafka independentes de diferentes unidades de negócios é um novo tipo de oportunidade para otimizar e automatizar um processo de negócios de ponta a ponta existente. Tenha cuidado ao usar esse recurso com sabedoria, no entanto. Pode se tornar um antipadrão na arquitetura corporativa e criar “integrações espaguete” complexas e incontroláveis.
Você deve usar o Flink como um mecanismo de automação de workflow? Depende. O Flink é ótimo para cálculos e consultas com informações de estado. O design orientado ao domínio habilitado pelo streaming de dados permite escolher a tecnologia certa para cada problema de negócios . Avalie Kafka Streams, Flink, BPMS e RPA. Combine-os conforme fizer mais sentido do ponto de vista comercial, custo, tempo de lançamento no mercado e arquitetura corporativa. Uma malha de dados moderna abstrai a tecnologia por trás de cada produto de dados. Kafka como o coração separa os microsserviços e fornece compartilhamento de dados em tempo real .
Kafka como mecanismo de workflow ou com outras ferramentas de orquestração
BPMN ou fluxogramas semelhantes são ótimos para modelar processos de negócios. As equipes de negócios e técnicas entendem facilmente a visualização. Ele documenta o processo de negócios para alterações e refatorações posteriores. Vários mecanismos de workflow resolvem a automação: BPMS, ferramentas RPA, plataformas de integração de dados ETL e iPaaS ou streaming de dados .
A postagem do blog explorou vários estudos de caso em que Kafka é usado como um mecanismo de workflow escalonável e confiável para automatizar processos de negócios. Esta nem sempre é a melhor opção. Interação humana, processos de execução longa ou lógica de workflow complexa são sinais de que escolher uma ferramenta dedicada pode ser melhor. Garanta a compreensão do padrão de design subjacente, como o SAGA, avalie a orquestração dedicada e os mecanismos de BPM, como o Camunda, e escolha a ferramenta certa para o trabalho.
Combinar streaming de dados e um mecanismo de workflow separado às vezes é melhor. No entanto, o exemplo impressionante do Salesforce provou que o Kafka pode e deve ser usado como um workflow confiável e escalável e um mecanismo de orquestração de estado para os casos de uso adequados . Felizmente, conceitos modernos de arquitetura corporativa, como microsserviços, malha de dados e design orientado a domínio, permitem que você escolha a ferramenta certa para cada problema. Por exemplo, em alguns projetos, o Apache Flink pode ser um ótimo complemento para desafios que exigem processamento de eventos complexos para automatizar o workflow com estado.
Como você implementa a automação de processos de negócios? Quais ferramentas você usa com ou sem Kafka? Conecte comigo e com o Kai no LinkedIn e vamos discutir isso! Mantenha-se informado sobre as novas postagens do blog assinando a newsletter.