System versus Service Orchestration

This post is part of the "Automation-Orchestration" architecture series. Posts of this series together comprise a whitepaper on Automation and Orchestration for Innovative IT-aaS Architectures.

One of the most well-known blueprints for service orchestration is the representation as seen from the perspective of service oriented architecture (SOA).

The following figure in principle describes this viewpoint:

Operational components – such as “commercial off the shelf” (COTS) or custom applications, possibly with a high level of automated functionality (see previous chapters) – are orchestrated to simple application services (service components) which in turn are aggregated to atomic or composite IT services which subsequently support the execution of business processes. The latter are presented to consumers of various kind without disclosing any of the underlying services or applications directly. In well established service orchestration, functionality is often defined top-down by modelling business processes and defining its requirements first and then leveraging or composing necessary services to fulfil the process’ needs.

A different approach is derived from typical definitions in cloud frameworks; the following figure shows this approach:

Here, the emphasis lies on the automation layer building the core aggregation. The orchestration layer on top creates system and application services needed by the framework to execute its functional and operational processes.

The latter approach could be seen as a subset of the former, which will become more clear when talking about the essential differences between system and service orchestration.

Differences between system and service orchestration

System Orchestration

• could in essence be comprised of an advanced automation engine
• leverages atomic automation blocks
• eases the task of automating (complex) application and service operation
• oftenly directly supports OS scripting
• supports application interfaces (API) through a set of plugins
• may offer REST-based API in itself for integration and SOA

Service Orchestration

• uses SOA patterns
• is mostly message oriented (focuses on the exchange of messages between services)
• supports message topics and queues
• leverages a message broker and (enterprise) service bus
• can leverage and provide API
• composes low level services to higher level business process oriented services

Vendor examples of the former are vRealize Orchestrator, HP Operations Orchestration, Automic ONE Automation, BMC Atrium, System Center Orchestrator, ServiceNow (unsurprisingly some of these products have an essential say in the field of automation as well).

Service orchestration examples would be vendors or products like TIBCO, MuleSoft, WSO2, Microsoft BizTalk, OpenText Cordys or Oracle Fusion.

System orchestration key features

System orchestrators are mainly demanded to support a huge variety of underlying applications and IT services in a highly flexible and scalable way:

• OS neutral installation (depending on specific infrastructure operations requirements)
• Clustering or node setup possible for scalability and availability reasons
• Ease of use; low entry threshold for orchestration/automation developers
• Support quality; support ecosystem (community, online support access, etc.)
• Database dependency to minimum extent; major databases to be supported equally
• Built-in business continuity support (backup/restore without major effort)
• Northbound integratability: REST API
• Southbound integratability and extensibility: either built-in, by leveraging APIs or by means of a plugin ecosystem
• Plugin SDK for vendor external plugin development support
• Scripting possible but not necessarily needed
• Ease of orchestrating vendor-external services (as vendor neutral as possible, depending on landscape to be orchestrated/integrated)
• Self-orchestration possible
• Cloud orchestration: seamless integration with major public cloud vendors

Main requirements for a service orchestrator

In contrary to the above, service orchestration solutions would focus mainly on message handling and integration, as its main purpose is to aggregate lower level application services into higher level composite services to support business process execution. Typical demands to such a product would therefore involve:

• Support of major web service protocol standards (SOAP, REST)
• Supports “old-style” enterprise integration technologies (RMI, CORBA, (S)FTP, EDI, …) for integration of legacy applications
• Provides a central service registry
• Supports resilient message handling (mediation, completion, message persistence, …)
• Includes flexible and easy to integrate data mapping based on modelling and XSLT
• Supports message routing and distribution through topics, queues, etc.
• Integrated API management solution
• Integrated business process modelling (BPM) solution
• Integrated business application monitoring (BAM) solution
• Extensibility through low-threshold commonly accepted software development technologies

As a rule of thumb to delineate the two effectively from each other, one can say that it is – to a certain extent – possible to create service orchestration by means of a system orchestrator but it is (mostly) impossible to do system orchestration with only a service orchestrator at hand.

For this reason, we will continue with a focus on system orchestration as a way to leverage basic IT automation for the benefit of higher level IT services, and will address vanilla architectures for typical system orchestrator deployments.