Annotating CoupoNet with Performance and Workflow Parameters

Chapter 4 uses the CoupoNet example to demonstrate the capabilities of StratusML to specify a cloud application service model, deployment configuration, provider specifications and adaptation rules and actions. In this section, the same CoupoNet example is used to demonstrate how the StratusPM components introduced in this chapter can be used to specify the CoupoNet service model further with performance parameters and workflow details.

Recall, that the CoupoNet example presented in Section 4.5 has three types of users (i.e., Coupon Providers, Coupon Customers and CoupoNet Administrators). Figure 5.7 shows two workflows (i.e., W1: fetch coupon and W2: create coupon) that represent two of the interaction scenarios for two of the CoupoNet users. Those are the coupon customers and coupon providers. The figure shows the workload generators  W orkload  , which specify the classes of interactions. It also shows the tasks involved in each of these interac- tions, the interconnections between the tasks (i.e., endpoints and connections (pipes)), the specification of the provider specific virtual instances that host these tasks (e.g., medium azure A2 instance) - which consist of the memory, number of cores and the virtual CPUs clock speed - and the activities that run within each task.

Both workflows (i.e., W1 and W2) start with a request sent to the request handler, which accordingly distributes the request to the appropriate activity. For simplification, in this scenario there is only one type of request directed to each of the tasks. W1 (i.e, fetch coupon workflow) consists of a sequence of seven activity incidents that are distributed into three different tasks. The workflow represents an example of a synchronous blocking client server communication. On the other hand, W2 (i.e., create coupon workflow) consists of a sequence of eight activity incidents that are also distributed between three tasks. The workflow is an example of a non-blocking asynchronous communication. The activity that submits the coupon does not need to wait for the coupon to be stored and can continue to accept new requests from users. The pull coupon activity will determine the appropriate location that is close to the target customer and save it when the storage is available.

As shown in the figure, the two workflows (W1 and W2) share the resources of two tasks. Using the performance components, each of the connections between two task endpoints can be annotated with the network data-flow performance parameters  N etwork . On the other hand, the calls between two activities can be annotated with the number of visits and message size  Call . Note that when data-flow parameters are not available, delays can be estimated as part of the system performance calibration and can be modeled as delay centers. This is common in the cloud, as network traffic depends on where the

cloud provider places the tasks within each region and the datacenter infrastructure (i.e., routers and switches) used by each particular provider. This information is hidden from the SaaS users. To keep the model clean, only two connections (pipes) and one call have been annotated as an example.

Finally, each activity is annotated with its service demand using the activity perfor- mance component  AP . Moreover, each workflow is annotated with the workload (i.e., close, open) parameters applied to it. In this figure a closed workload is applied on each of the workflows. The workload is specified by the number of users and the think time (i.e., average time between two requests).

5.5.2

Applying the Transformation Rules to the CoupoNet Ex-

ample

In this subsection, we show how to generate an LQN model for the annotated CoupoNet example presented in section 5.5.1. For the purpose of presentation, the transformation process is explained through representative examples and in steps.

Level 1: Generating LQN Structural Model

Figure 5.8 shows the results of applying the rules in step 1 of the first level of transfor- mations, which aims to generate the LQN structural model from a StratusML core model. The StratusML core model in Figure5.8(a) corresponds to part of the CoupoNet example presented earlier (Figure5.7). Figure5.8(b) shows the corresponding Azure service defini- tion file, while Figure 5.8(c) shows the LQN model generated, as a result of applying the rules in step 1.

In Figure 5.8(c), the LQN tasks are presented with bold rectangles with entries that represent atomic microservices attached to them (i.e., the non-bold rectangles). The service entries use lower layer services through request and reply interactions indicated by call arcs between the entries. The LQN host processors are represented as ellipses following the LQN notations.

The LQN tasks (CoupoNet.Web) and (CoupoNet.Worker.Login) in addition to their LQN processors have been generated from applying the rule L1-S1-R1. Each processor is annotated with the “vmsize” value (e.g., small ). An entry placeholder (e.g., FetchCoupon, RetrieveCoupon) is created for each of the generated LQN tasks (e.g. CoupoNet.Web, CoupoNet.Worker.Login) by applying the rule L1-S1-R2. The created entry placeholders

are dummy entries; they do not specify any performance parameters (e.g., service time). The name of each dummy entry is determined from the inbound endpoint name. The name appears in the endpoint specification in StratusML (not shown in the figure). The same name appears in the specification of the inbound endpoint as shown in the Azure service definition (Figure5.8(b)). Following the rule L1-S1-R3, a reference task placeholder with its pure delay processor is created for the web task (CoupoNet.Web). Only one placeholder is created as the web task has only one external endpoint. Based on rule L1-S1-R4 the connection between the two tasks (i.e., CoupoNet.Web and CoupoNet.Worker.Login) is transformed into a pseudo task with a pure delay processor. A synchronous call from the entry of the task with the outbound endpoint to the entry of the created pseudo task is created. The communication overhead will be determined in a later step.

To specify the multiplicity of the processors in addition to the replication of the tasks the rules in step 2 are applied as shown in Figure5.9. First the multiplicity of each of the processor (i.e., number of cores) is specified by applying the rule L1-S2-R1. Since the size of each of the tasks hosting server is small and the target provider is Azure, the multiplicity, which corresponds to the number of cores, will be set to two and the processor speed factor will be set to 1.6 GHz, which corresponds to the specifications of Azure medium (A2) instance. Second, the replication of each task is specified based on the number of instances of the task according to L1-S2-R2.

The multiplicity of the reference task (#n) refers to the number of active users (popu- lation) circulating in the system. This number is specified in the workflow model as shown in the next step. Similarly, the multiplicity of the task refers to the number of concurrent threads. This is a run-time parameter that is specified in the workflow model.

Level 2: Generating LQN Analytical Model

Figure5.10shows the complete analytical LQN model that corresponds to the first workflow (W1) in the CoupoNet example. The analytical LQN model has been generated from applying the second level of transformation rules to the fetch coupon workflow.

Using rule L2-R1 the reference task placeholder (RefTask CoupoNet.Web) will be re- placed with a concrete reference task. The entry parameters of the reference task will be specified based on the W1 workload parameters. Here, we have a closed workload with 100 users and 3 seconds think time. Accordingly, the multiplicity of the LQN reference task will be set to 100 and the think time parameter (Z) will be set to 3 seconds.

Using the rule L2-R2 the set of entries (e.g., Fetch Coupon, Retrieve Coupon and Get Info) and the number of calls to and from these entries are determined. Then, depending

Figure 5.9: Applying the Rules of Multiplicity and Replication

on the different cases explained as part of L2-R2, the entry demand is calculated. The entry demand of the FetchCoupon entry is specified by applying the L2-R2-Case1 rule. This is because, the WebTask receives external requests from the (reference task) through the external endpoint FetchCoupon. Then, it executes a series of activities and returns a response (i.e., case1). The entry demand of the FetuchCoupon entry is equal to the sum of the demand of the WebTask activities (i.e., (Request Handler, 2 ms), (Fetch Coupon, 4 ms) and (Send Response, 2 ms)). The same rule (i.e., L2-R2-Case1) is used to calculate the entry demand of both the Retrieve Coupon and Get Info entries.

Rule L2-R3 is used to assign the demand for the entries of both Pipe Pseudo1 and Pipe Pseudo2 tasks.