In part 1, we introduced how Cisco Process Orchestrator can provide a service oriented orchestration platform. We continue this topic, by looking at how we align to IT standards.
Aligning IT Standards
While Service-Oriented Automation is open, allowing any model, it aligns to IT best practices such as the IT Infrastructure Library (ITIL). ITIL prescribes a configuration management database (CMDB) as a central tenet which allows high level services to be decomposed into their supporting lower level services and ultimately to the lower level systems and devices. In ITIL, each element in the model is called a Configuration Item since it is a unit of configuration. This provides a mapping of how lower level elements support business services. Service-Oriented Orchestration allows automation to be driven through a model of current and desired IT services, aware of their relationships and interdependencies. In this aspect, the principles of service modeling are substantially the same as modeling services within ITIL and CMDBs.
However, the implementation bypasses many of the negatives and weight of typical CMDB implementations. Process Orchestrator can integrate with a CMDB if it is there. Targets provide a natural synchronization point to exchange data with a CMDB, and target events allow that synchronization to be externalized from other processes. However, Service-Oriented Orchestration does not require a CMDB; one does not have to have a CMDB to enable orchestration to function. Often orchestration needs a reduced model vs. what is in the CMDB, and it is therefore much easier to keep the smaller data set current. For example, resource management can be more efficient when externalized. Moreover, a CMDB typically represents actual elements and not potential elements, and since orchestration is often responsible for provisioning, the orchestrator may have data prior to its life in the CMDB, which it might write to the CMDB as it is instantiated. Even if Process Orchestrator service models leverage data in CMDBs, performance is improved by keeping this data in Process Orchestrator target properties to optimize queries. Process Orchestrator allows a local representation of only those services that relate to what you want to automate, so that the implementation is right-sized and lighter than complete CMDBs. Updates are more real time and targeted to the need of automation. A conceptual alignment to ITIL and CMDB principles creates the flexibility to right size the implementation and unify with CMDBs when needed.
Also, ITIL prescribes key process records such as alerts, incidents, and change requests that drive the IT operations process. Process Orchestrator provides a native representation for these concepts. This allows content to be abstracted from how these concepts are provided in a company. For example, content that detects an IT incident does not have to encode the specific service desk used by a particular customer.
Content that enriches incidents with further diagnostic data can also do so independent of tool selection. Process Orchestrator alerts, incidents, and change request records allow reusable content independent of tool selection and company-specific ITIL extensions. A separate body of content can integrate orchestrator incidents with a specific service desk like BMC Remedy. Processes can trigger when incidents are created or changed in general automation and push those changes to Remedy. Updates within Remedy such as incident closure trigger synchronization processes which update the Process Orchestrator incident. Processes in general automation can then proceed from incident resolution. For example, the incident can be verified to prove that the problematic behavior no longer manifests. Moreover, ITIL prescribes that these records have a relationship to the element which failed so one knows what services may be impacted. Process Orchestrator incidents provide a link to:
- The target defined by the target type for the service
- A secondary configuration item field to link arbitrary external CMDB references when a CMDB is present
Related Service-Oriented Orchestration Terms and Concepts
The following table summarizes how Service-Oriented Automation blends aspects of these industry standards as well as common best practices like object-oriented programming. Users who are familiar with one of these domains might find it easiest to map the concepts with which they are familiar to Service-Oriented Orchestration features. As you can see, the feature synthesizes similar concepts that have very disparate terms across the industry. Process Orchestrator attempts to provide the most intuitive terms within orchestration, and especially with prior Process Orchestrator users.
|Object-Oriented Programming||IT Infrastructure Library (ITIL)||Cisco Process Orchestrator||Cisco Prime Service Catalog||Common Information Model (CIM)||Topology and Orchestration Specification for Cloud Applications (TOSCA)|
|Object Model||Service||Collection of related targets||Model||Service, Service Template, Topology Template|
|Configuration Item Hierarchy|
|Class||Configuration Item type, or more loosely asset classes||Target Type||Service Item Definition, Service Standard Definition||Class||Node Type|
|Instance, object||Configuration Item, Service||Target||Service Item, Service Standard||Object derived from Managed Element||Node|
|Inheritance,||(loosely) Configuration Item categories and classification||Inheritance||Inheritance,||Inheritance (subclassing)||Inheritance,|
|Parent / child / ancestor / descendant||Parent / child / ancestor / descendant||Parent / child / ancestor / descendant|
|Subclass / superclass, subtype / super-type|
|Attribute, field||Configuration Item attribute||Property||Attribute||Property||Property|
|Relationship type||Future: Relationship Type (achievable through Target Types - see above)||Relationship type|
|Links and associations||Configuration Item relationship||Relationship||Relationship||Relationship, association||Relationship|
|Method, operation||Process||Action, Associated Services, Tasks||Method||Plan|
|From Target Type: Process Action|
|Event or Message||Event||Event||Indication (stop, Alert, Threshold, and others)|
|From Process: Trigger from Event||Rules for “On Event”|
|Some use of the term “Trigger”|
|Selection by Configuration Item Category||Target Group, Target Selection||... Rule|
|Event (related to Configuration Item)||Alert (Related to Target)|
|Incident (related to configuration item)||Incident (Related to Target)|
|Change Request (related to configuration item)||Change Request (Related to Target)|
|Automation Pack||Cloud Service Archive (CSAR)|
|Files in an Automation Pack||Artifact|
|Class Interface||No explicit term||Class Interface||Interface|
|The collection of all processes that act on a Target Type, including their input and output parameters|
|“This” reference in a method||Process Target|
|Abstract class||“Targets of this type can be created” check box on a Target Type||Abstract type|
|Dynamic binding, overriding, polymorphism||Achievable in processes|
Service Definition Examples
A Distributed Application and Product as a Service
An example of the usefulness of Service-Oriented Orchestration is the ability to model a distributed application and provide its provisioning and ongoing operations. To the business, an application and its elements are not important by themselves; the application is important for the service it provides to the business. For example, an application may provide customer support, order entry, or partner billing. Let’s pick one of these, say customer support. The customer support service in this example is provided by a distributed application that consists of a number of web servers behind a load balancer, a database, a cluster of application servers, and an LDAP repository for user credentials. Each application server ultimately runs on a UCS blade, which is in turn related to a UCS Manager. Moreover, each of these topology nodes fit within some network, with each tier separated by firewalls, and these nodes require specific firewall configuration, so the application topology has relationships to a network topology. All of this combines to form the service topology.
In a Platform as a Service solution, the customer must enable not only provisioning but ongoing operations and eventually deprovisioning of services or applications, as opposed to IaaS where individual virtual machines are provisioned. The leap involves treating a service or a collection of virtual machines and their networks as a package. Applications or other services are provisioned and configured on these VMs and networks. It involves an ordering experience that allows customers to deploy and use those services.
To this end, there is a need to define service or application blueprints so they can model their services and make them orderable and support provisioning, operations, and de-provisioning of those services. These blueprints capture what the customer needs to deploy some application. Customers want to receive these blueprints from Cisco, or possibly from partners or a community. They also need to be able to build these blueprints themselves and move them from development to test to production.
Service-Oriented Orchestration allows one to define, package, ship, and receive these models, as well as to create instances of the service from that model. In this way, the company can drive a standardized deployment of the service across development, test, and production systems. For example, a target type could be created for a web server, while the specific web server target is an instance created from that web server target type. This might have a relationship to the Linux server that hosts the web server.
A level 1 help desk operator might not know or care what specific database or LDAP instance supports the customer support service, or what UCS blade actually runs a certain instance of the web server. They want to do things against the customer support service. Say they want to authorize a new user to access the customer support service and provision whatever they need. They would generally run an add-user process, acting on the customer support service.
A Build process that acts on the customer support service is responsible for provisioning of the whole of the service. This process might call the Build process for each target type in the topology, building the service up an element at a time. This process might use files, like an OVF for a server, to stand up the specific service element, or might invoke a tool such as Puppet or Chef.
Other examples of processes that act on the service or its elements are things like site disaster recovery, that may need to make changes to many parts of the customer support distributed application to move it to another site. These processes need to act on the customer support service as a whole, but leverage the topology and relationships to traverse to other actions, possibly calling similar processes that act on those elements. For example, a request to back up the overall service might invoke a backup of each server in the topology as well as the database.
Through Service-Oriented Orchestration, processes can act on the customer support service. As necessary, the process can traverse relationships to lower level infrastructure and tool elements on which it takes action. For example, a process that queries capacity might traverse to the database target, and perform Process Orchestrator activities against that database.
A Cisco TelePresence Service
A TelePresence system has a number of components that automation can act on through SSH, stop, or a web service. Prior to Process Orchestrator 3.0, to act on a service, one was required to browse through all of the processes, filter by category or automation pack, then run a process and specify the terminal, stop, or web service target. One had to understand the underlying implementation to know what target to provide.
Now, using Service-Oriented Orchestration:
1. An external team provides an automation pack that defines a TelePresence target type, with:
– Relationships defined for terminal, stop, and web service target types
– Properties such as a phone number or escort name
– Process actions for TelePresence systems
2. The automation pack can add properties such as a location property to the built-in network device target type.
3. The customer installs the automation pack and configures TelePresence service instances by calling a constructor process called Create.
4. The process not only creates the TelePresence target, but also creates the terminal, stop, and web service targets as well as the relationships that unify them into the model.
5. The end user can browse the target views or operations views and filter for targets with the TelePresence type. When they select a type, they can see:
– All of the available user-startable actions (processes).
– All automation running against the TelePresence system. These results are filterable by a time range or by a specific process.
6. When the end user runs a process action, internally the workflow traverses the relationship to find the SSH, etc. target required by the action. The user sees this and other automation running against the TelePresence system.
In conclusion, Cisco Process Orchestrator (CPO) is a mature platform which can be used as the basis for an “Orchestrator of Orchestrators” topology, and Metsi has delivered many solutions with CPO at the heart of the orchestration layer. Cisco is leading the way in service orchestration with the natural evolution of CPO towards the CloudCenter Suite Action Orchestrator (AO). Watch out for our next post on the exciting features of AO!