对于简单应用的需求，自定义脚本可以充分地设置基本编排。脚本就可以实现隐藏在业务逻辑背后的工作流。举个例子，当数据文件被写到临时目录时，数据库加载脚本应该运行一次。

　　同样你的云工作流也可以会变得很复杂，随着你忍不住地向编排脚本中添加更多的逻辑。打个比方，你可能需要添加逻辑以确保一些进程在其他进程开始前完全执行成功。此外，你可能需要修改运行在其他服务器上应用中的错误。这样的方式可能会很快地变得不可管理——随着进程数量的增加，进程间的依存性将变得越来越难以跟踪。

　　管理解耦的云工作流

　　减少来自管理多种云应用(不得不共同使用)的挑战的一种方式就是，最小化应用间对直接连接的需求。举个例子，不要假设在某事件发生后进程A将被进程B调用，你可以编写进程B将数据写到消息队列，显示事件已经发生，同时包括所有相关数据。

　　这个例子中，进程B不需要任何有关进程A的信息，不需要A同时运行来写消息。这允许你运行进程B——或它的多个实例——直到队列中有足够数量的消息。接着，进程A将运行并在结束前完成队列中的所有消息。这是很有用的，万一进程A完成消息快于进程B所积累的。

　　使用消息队列的解耦架构，相比自定义脚本更适合于复杂流程。在需要扩展某些部分的工作流时，它也工作的很好，但其他方面不一定奏效。如果队列中存在过多的消息，已超过单个实例可以在规定时间内处理的数量，举个例子，另外的实例可以被带上线。这里并不需要改变代码或改变系统架构。

　　然而，由于这个技术在整个系统内处理工作流的工程中散发逻辑，它可能存在一些问题。应用的一部分植入了一些逻辑，并书写消息队列，同时另一部分从队列读出消息，并为处理数据结构嵌入逻辑。这里不存在业务逻辑的单个全局存储仓库。

　　Amazon Simple Workflow Service和候选方案

　　另一种实现云编排的方法就是使用工作流系统，诸如Amazon Simple Workflow Services(SWS)。该服务以参与者执行任务的方式实现了工作流。参与者是抽象的，它包括将被执行的代码和启动工作流、实现工作流的决策逻辑并执行程序完成任务的代理。

　　任务被分为两种：活动任务和决策任务。活动任务运行程序完成特殊的活动;决策任务使用有关工作流状态的信息来控制下一组的任务。Amazon SWS还实现了真实工作流所需的其他设计，如任务列表，工作流——执行——关闭服务以及记录相关工作流历史的数据。它也可以为事件驱动处理和任务轮询发信号。SWS包括能实现与控制已编排工作流的API。

　　SWS与其他工作流服务的主要优势就在于工作流逻辑被单个单元管理。使用管理控制台或API指定工作流，意味着它们与语言无关。SWS工作流是泛化的，允许使用面向多工作流的机制。

　　当你使用专利云服务时，会有被供应商锁住的风险。一种方案就是选择Amazon SWS，你可以使用工作流引擎，例如由Ruby编写的开源应用Route。RightScale正是使用了SWS与Route的组合，实现了自己的编排服务。其他的开源云选择包括jBPM和Apache ODE(Orchestration Director Engine)。

　　云计算可以被用来高效部署服务器，但是需要运行复杂的业务流程。你需要优化如何使用云中的实例。对于相对简单的工作流，你可以使用自己的脚本，但当业务逻辑变得越来越复杂时，你可能会发现消息队列和工作流引擎在实现更加结构化的工作流上更有说服力。