Service designs describe subscription options, provider resources, and the processes that realize the requests. Service designs encapsulate manual IT processes to deploy, modify, and retire a variety of services in an automatic and repeatable manner. Today, HP supports two types of model design templates - Sequential Model and Topology Model.
The Sequenced model is used when developers want total control of the components and actions used within the lifecycle of a service. This model works well when automating and aligning an IT process with a customer business process. But for today, I want to focus on Topology-based modelling and compelling reasons that HP CSA is investing to make it successful.
Topology model is all about:
Declarative design methodology
Focusing on creating the building blocks(components)
Defining relationships supported between component types
Using component hierarchy to guide and validate designs
Allowing time to value development of services
Aligned with TOSCA convention and standards
Graphical topology represents the end state
HP CSA provides out-of-box topology (OOTB) components to build your design templates. These are infrastructure components like server or network provisioned by VMWare vCenter, Amazon EC2 or HP Helion OpenStack.
Besides the OOTB components, CSA can load/import content from other systems, representing it as components, for use while designing topology. Currently, HP Operations Orchestration flows, HP Service Automation policies and Chef cookbooks are supported.
Topology component lifecycle
Each component provides simple lifecycle capability to wrap up IT tasks/actions to perform infrastructure or platform provisioning. Topology components support the deploy, deployFailure, undeploy, and undeployFailure lifecycle. Components operation can be mapped to these lifecycle actions.
Relationship between components
Topology design captures components dependencies and connections by using the concept of relationship between components. The trickiest part of topology design development is setting up the component relationship. Component comes with set of parameters. The parameter mapping esp. “Relationship Target property” between components decides the direction of relationship. The relationship of components determines dependency, property value propagation and the order of component realization.
These relationships enables you to pass on output results of a component into other components. Consider a simple case where a MYSQL Database component needs an IpAddress of a server for deployment.
The MySQL component has a “hostedOn” relationship on targeting Server capability. During the provisioning, the MySQL reads the server IP address using the hostedOn relation.
Consider a two stack LAMP stack design as shown. The My PHP App needs to know the ipAddress of the App Layer server, so that it can be installed on it. The same application component needs to know the ipAddress of the DB Layer server, so that the application can connect to the MySQL. In both cases, the ipAddress flows along two relations using hostedOn relationship.
Note that each of these components is created from various sources. App and DB layers are default server components. Apache components are embraced from Server Automation policy. My PHP App and MySQL Database are Chef Components.
Watch our video on topology designs and service application portability, as we design and orchestrate for full stack services acorss a vendor neutral ecosystem. For more information on HP Cloud Service Automation, you can also visit us at our product page http://hp.com/go/csa