Activiti Cloud是第一个云原生BPM框架，用于为云环境中的BPM实现提供可伸缩和透明的解决方案。
BPM规程的创建是为了更好地理解组织如何工作，以及如何以迭代的方式改进这些工作。BPM套件的设计基于公司将托管一个中央BPM服务器，该服务器将负责自动化和监视其业务流程。这种方法在现代组织中引起了一些挫折，下面的列表突出了采用BPM套件为中型组织所代表的一些痛点:
- BPM套件构建在组织内部的IT部门(软件)不需要知道的技术堆栈之上
- BPM套件通常不能很好地与其他生态系统集成
- 用户需要学习一个全新的工具集来完成这项工作
- 负责BPM套件将运行的基础设施的部门并不知道它的需求。对于需要了解BPM套件如何工作以优化数据库的dba来说也是如此。
- BPM套件提供的用户界面通常不够灵活。许多BPM实现最终需要多个用户界面的重新实现
- BPM套件采用通常是由业务推动的，而不是由组织内部的软件开发团队支持的，这种摩擦会导致实现过程中的延迟和问题。
大多数这些痛点的出现是因为BPM套件强加了一整套技术，推动组织适应这些技术。这当然会导致排斥、痛苦和沮丧。
随着云环境/平台和工具的兴起，这些环境(如微服务、容器和服务编排器)的采用越来越方便，BPM套件现在不得不重新设计自己，以便很好地适应这些环境。
容器有助于减轻技术方面的痛苦。我们现在负责的容器，隐藏了运行在其中的任何软件。但是容器是不够的。BPM套件的主要问题是，它们中的大多数都被设计为单体，促使采用者孤注一掷。另一方面，您将发现开源BPM框架的目标是尽可能通用，以支持广泛的开发和部署场景。通过这样做，这些项目在使用、维护和适应不同的体系结构方面都很麻烦。由于这种通用的方法，开源BPM框架将太多的决策委托给实现解决方案的人，迫使他们不仅要了解框架的内部，还要做出只有专家才能准确做出的复杂决策。
Activiti Cloud试图将Activiti流程引擎精简到最低限度，并尽可能保持它的单焦点。同时，Activiti Cloud为大多数BPM实现提供了一组定义良好且集中的服务。这些服务中的每一个都可以使用，但是它们都是相互独立的。您可以选择需要什么，不需要什么，如果提供的实现不符合您的需求，甚至可以替换实现。
从Activiti Cloud的角度来看，流程运行时的主要目标是理解(解析)BPMN 2.x业务流程定义并自动执行它们(运行时/流程执行)。
- 流程运行时不应该担心:
- 流程定义存储在哪里
- 处理流程版本和更改
- 身份管理
- 单点登录
- 工作执行
- 定时器机制
- 提供系统到系统的集成机制
- 发送邮件
- 存储历史记录/审计信息，并提供查询此信息的方法
- 使用引擎生成的数据的客户机的性能
- 推送关于系统状态变化的通知
基于此列表的过程运行时不应该做的事情,我们已经创造了一个不同的Activiti Cloud组件,采用第三方组件,将与流程交互运行时提供所有的这些功能,当我们想要实现一个BPM项目需要90%的时间。
Activiti Cloud的设计目的是支持零停机部署(例如kubernetes滚动更新、canary发行版、A/B测试)，并从您开始实现时就使用可生产的组件进行伸缩。Activiti Cloud使在现代基于云的平台上使用Activiti变得很自然。
我们还确保使用我们的工具对于不同的角色(开发人员/ DevOps /最终用户)来说是很自然的:
- Spring Boot / Spring Cloud:如果您已经在使用这些技术，那么将Activiti Cloud添加到组合中应该很简单
- 如果您正在研究Kubernetes和Docker等技术，那么我们的所有组件都可以使用，并与这些环境的需求保持一致。
- 如果您想更改/定制一些提供的开箱即用组件，您可以使用我们的* -cloud-starter。
- 如果您想更改底层技术堆栈，例如将RabbitMQ切换到ActiveMQ或Kafka，您可以这样做，因为我们依赖于Spring云抽象层。
- 如果您担心流程/应用程序迁移和更新，您可以依赖行业标准的方法来处理容器版本和数据迁移，而不是处理显式为流程运行时编写的复杂迁移工具。
- 如果您已经拥有了一个持续集成/部署管道，那么您可以使用这些工具集成BPM特定的块。