Cisco Process Orchestrator (CPO) introduces a set of features providing Service-Oriented Orchestration that enable a paradigm shift vs. traditional run-book automation and IT process automation. This shift enables automation to align to the high-level services provided by IT, and models how a high level service is supported by a topology of lower level services, systems, and devices.
Planning for services and their desired state are the initial focus of automation design. Focus then moves to defining process actions against these services, with implementation of specific process workflows that traverse these services to act on lower level elements as a final implementation step.This enables a declarative approach to automation, focusing primarily on what is desired instead of how it is achieved.
The capabilities are additive and complimentary to traditional orchestration definitions and approaches, so Cisco Process Orchestrator provides both service-oriented and process-based orchestration. This means that you can still program Process Orchestrator as usual, so you can ease into the new concepts or not use them at all. This guide, however, will demonstrate the service-oriented orchestration approach.
Service-Oriented Orchestration combines several industry trends to synthesize a fresh approach to orchestration
- Defining new, higher-level services in the system, and deploy new services quickly.
- In real-time, after these new types of services have been defined, creating real-time instances of those new services.
- Using events to watch for patterns in these services, enabling policy-driven automation.
- The feature delivers many of the capabilities of object-oriented design and programming into the RBA / ITPA world. The shift from traditional orchestration to Service-Oriented Orchestration is similar to the shift from procedural to object-oriented programming. Today, virtually all programming is done with object-oriented languages, and object-oriented design has transformed the industry to higher levels of productivity and quality. Service-Oriented Orchestration holds the same promise.
- The IT Infrastructure Library (ITIL) prescribes a service-centric approach for IT. Configuration Management Databases (CMDBs) model IT services and their relationship to other IT assets. Service-Oriented Automation allows automation to be driven through a model of current and potential IT services, aware of their relationships and interdependencies. In this aspect, the principles of service modeling in Process Orchestrator are essentially the same as modeling services within ITIL and CMDBs. While Process Orchestrator can integrate with an available CMDB, there is no requirement to have a CMDB to enable orchestration.
- The feature aligns to industry standards like the DMTF Common Information Model (CIM) and the Topology and Orchestration Specification for Cloud Applications (TOSCA).
- Model-based automation is becoming popular via script-based tools, especially in the configuration management space. Process Orchestrator combines the capability to model services with the openness to integrate with these tools to leverage their strengths. Moreover, the feature allows model-driven orchestration atop legacy tools to bring the full power of model-driven approaches to integrate with other IT tools.
Service-Oriented Orchestration allows automation to focus on higher level IT services, possibly specific to the customer’s business and unknown by Cisco when the product is built. User interaction shifts to services on which to act and what you can do to them. The approach to defining automation shifts from having to first decompose automation into a sequence of processes, to decomposing high-level services into their components, and then defining actions that are possible on each of the component services.
This inversion in approach is simple, yet powerful. Cisco Services, partners, and customers can model services and extend others’ services without coding. Extensions and automation can be packaged, shipped to customers or moved from development to test to production, versioned, and upgraded. The approach delivers several key benefits. Service-Oriented Orchestration provides the agility to model and act on IT services. These features make creating orchestration active and dynamic, and allow for:
- Service modeling capabilities of a service catalog are now available in the orchestrator layer. Process Orchestrator provides fluid mechanisms to exchange service information with the Cisco Prime Service Catalog, advancing the integration of these systems.
- Greater ease of use in combining Process Orchestrator with Prime Service Catalog.
- The Prime Service Catalog adapter simplifies the exchange of service requests and service items to and from the orchestrator. It is easy to create targets from incoming service requests. Process Orchestrator helps push service items back to the catalog as needed by allowing users to pick the right moments in a flow to synchronize data. Using active catalog connection in the Prime Service Catalog adapters optimize user experience. The Prime Service Catalog adapter easily reads, writes, or creates service items, and is CP schema-aware. When a service item definition is created in the catalog, the desire is to set up integration rapidly. The property browser exposes the catalog definition to enhance ease of use. Get Service Item properties can be followed by Update Target to save properties in a single step. One can write directly through the Create Service Item or Update Service Item activities using property references.
- It provides operational views of automation by service.
- It allows simpler, more readable workflows.
- Data defines desired services, and the service instance drives automation to achieve the desired state. This separates the desired state from the implementation (the “what” from the “how”).
- It acts on the higher-level service rather than its technology elements. Services can span tools, and workflows can navigate service topologies to lower-level elements on which they act.
- It lets you monitor the environment vs. the service definition and bring them in line with policy.
- It provides federated storage, including push objects and relationships to and from Service Catalog, CMDB, and Service Assurance tools when needed.
- Automation becomes easier to extend and customize.
Process Orchestrator Supports Service-Oriented Orchestration
Several features in Process Orchestrator combine to bring these capabilities:
- Service instances are targets. A target type allows you to define a new service; all new targets are created based on a target type. Target types can be based on the DMTF Common Information Model, but this is not required.
- Relationships allow modeling of topologies of lower level services assembled to offer higher-level services; that is, relationships allow lower-level objects to be bound together to achieve a larger whole. Automation can navigate from a higher-level object, such as a service, to lower-level objects against which they can perform automation.
- Processes provide actions that can be executed against targets. Process Orchestrator allows you to view a target to see what actions are possible, or what automation is being done against those targets.
The target types that a process can accept define the services on which a process can act.
- Targets and target types have events. These can be internal process events or the open Advanced Message Queuing Protocol (AMQP) protocol. Triggering processes in response to patterns in underlying processes provides policy.
- Extensible by services, partners, customers. The content, not the platform, defines service models. The platform is open to model any IT service topology within automation content. For example, some types, actions, properties, etc. may come from the packaged product, some from team 1, some from team 2, some from a partner, and some from a customer. Using this capability you can assemble a complex solution from parts. Each author controls the version control and lifecycle of the elements they deliver so they can deliver upgrades.
- A consistent API, even if elements come from different authors. Users and automation pack authors can control which target types are published to the NorthBound Web Service (NBWS; see the Northbound Web Services Guide). For published objects, Process Orchestrator exposes the type uniquely in the NBWS. As content teams, services, partners, or customers extend types, these APIs are maintained to provide a consistent format for APIs across all types of objects. However, each type of object is uniquely supported.
- Authors can also configure which properties are exposed in the NBWS as optional parameters in the per-type WSDL.
In the part 2 of this post, we will look at how this discussion aligns with IT standards.