# Enabling Role-Based Orchestration for Cloud Applications
## 3 TOSCA Model-Based Approach to Cloud Application Orchestration
### Architectural Design of a Topology Model-Based Orchestration System
#### 3.1.1 TOSCA Modeling  
We have defined a set of customized TOSCA types that are categorized into two groups. One group represents workload capabilities for application developers who are concerned about workloads, where the application resides, as well as the runtime configuration of the workloads. The second group models operational capabilities for application operators who are responsible to attach operational characteristics to workloads. In the motivational scenario introduced in the previous section, the WordPress server resides inside a Kubernetes Deployment and relies on a Kubernetes Service to deliver its service to users. A combination of Deployment and Service is a typical workload capability that represents an instantiation of runtime environment for containerized applications equipped with a scaler and a load balancer. Auto-scaling capability represents an operational capability that can dynamically scale workloads to a growing demand. Similarly, rollout capability is another example of an operational functionality that gradually introduces a new version to a group of replicas. Based on the motivational scenario, we introduced extension node types for each capability, including _dcc.workload.containerized_ derived from _dcc.workload.root_ for the combination of Kubernetes Deployment and Service, and _dcc.operational.autoScaling_ and _dcc.operational.simpleRollout_ derived from _dcc.operational.root_ for auto-scaling and rollout capability, respectively. As shown in Listing 2, the node _dcc.workload.containerized_ contains a set of properties to specify the runtime configuration of a containerized application whose service is accessible through exposed container ports. Its _image_ field defines the container image used to run the service, while its _ports_ field defines the container port used to access the service. The definition of two operational capability node types is shown in Listing 3. The node _dcc.operational.autoScaling_ represents the auto-scaling capability. From the perspective of application operators, the _dcc.operational.autoScaling_ should provide properties to specify basic auto-scaling rules. Some important fields include _maxReplicaCount_ and _minReplicaCount_ for replica count constraints, and _promThreshold_ to indicate the threshold of triggering a scaling action. The node _dcc.operational.simpleRollout_ represents the operational capability that can control the application behavior during its progressive delivery. The _maxUnavailable_ is the maximum number of replicas that can become unavailable during rolling out. The _replicas_ is the final number of replicas once progressive delivery completes. Additionally, the _batch_ defines the number of replicas that should be created in each round of rolling. We have chosen to model operational capabilities as TOSCA Node types rather than TOSCA Policy types. An operational capability allows us to define operation interfaces for application operators to manipulate operational characteristics. Additionally, one instance of an operational capability is only allowed to attach to one instance of workload. In other words, multiple workloads cannot share operational capability instances. TOSCA Policy is designed to apply non-functional constraints to a group of nodes and does not provide a means to define operation interfaces. Therefore, modeling operational capabilities as node types rather than policy types is more suitable in our approach and treats operational capability and workload capability in the same way. Two root Node types, _dcc.workload.root_ and _dcc.operational.root_, indicate several common Requirements and Capabilities of workload and operational capabilities. The Workload nodes derived from _dcc.workload.root_ have the _workload_ capability in common, which means that an operational capability node can be attached to it or other workload capability nodes can connect to it. In addition, a common requirement _connect-to_ indicates that they can connect to another workload node.