QUALITY EVALUATION OF PAAS CLOUD APPLICATION DESIGN USING

QUALITY EVALUATION OF PAAS CLOUD APPLICATION DESIGN USING GENERATED PROTOTYPES 2017 IEEE International Conference on Software Architecture (ICSA) 2017/10/06 doi 1

Introduction Cloud is a model how IT services and resources are operated in organizations ■ Iaa. S(Infrastructure as a Services) providing with visual servers, storage and software defined network taking advantage of architectural and design patters in on-premise environment ■ Paa. S(Platform as a Services) lower costs and operates without servicing the platform for hindering the applicability of the current modeling and simulation approaches performance evaluation ■ Saa. S(Software as a Services) 2

Introduction The challenges associated with the Paa. S Cloud ■ Hidden complexity of platform ■ Multi-tenant environment ■ Updates of the environment Currently ■ Software architects → a costly manual implementation of application prototypes deployed to the Paa. S cloud 3

Introduction This paper 1. Understanding of the challenges, the guidelines and architectural patterns suited for the Paa. S Cloud 2. Introducing an evaluation method and tool 3. Supporting an automated quality evaluation of the Paa. S Cloud application design 4. Deploying to the cloud and evaluating with respect to various peformance-related quality attributes 4

RELATED WORK ■ Model- Driven Quality Predictions (MDQP) To predict the quality of the designed application ■ UML For object-oriented analysis and design ■ Palladio Component Model )PCM ( pecifically designed languages, ■ Markov Chain or Layered Queuing Network time the service time for each job at each service node is given by the response of a queueing network 5

RELATED WORK ■ SPACE 4 CLOUD implementing state-of-the-art metaheuristic techniques to effectively and efficiently explore the space of possible alternative configurations ■ Simu. Lizar a Palladio plug-in for analyzing self-adaptive systems, such as cloud computing systems ■ Stress. Cloud a tool for analyzing performance and energy consumption of cloud applications 6

KEY ASPECTS OF THE PAAS CLOUD A. Compute Services ■ Requiring hosting environment (Web server) →Web application and Worker process ■ Package application together with the hosting environment by using container services ■ Isolated operations hosted in fully managed environment without application 7

KEY ASPECTS OF THE PAAS CLOUD B. Storage ■ Storing data based on. Services their quality characteristics and type of stored data →performance, response time and scalability of the storage ■ Types of stored data/querying support and transaction/related implementation costs 8

KEY ASPECTS OF THE PAAS CLOUD C. Storing Message ■ in queue services. Services (send and load) ■ Provisioned with minimum effort and easily integrated into the application ■ Used in Internet of Things by using REST API →messages need to be transferred to the cloud 9

KEY ASPECTS OF THE PAAS CLOUD D. Data Analytics and Intelligence Services ■ Providing the developer with high-level services →analyze data stored in the cloud/design machine learning solution/take advantage of modern research in deep learning area ■ Based on throughput and response time after careful evaluation 10

APPLICATION MODEL A. Model Requirements ■ Use in an early design stage to omit and simplify details of application’s design without depreciation of quality evaluation results ■ Abstracting from the cloud provider to create platform- and cloud-independent application model + to include platform specific details so that the used services can be utilized up to their full potential and efficiency ■ Multiple types of applications REST API generating output to sent to the client Worker process running in an infinite loop or activated by specific trigger 11

APPLICATION MODEL A. Model Requirements ■ Identical resource consumption given type/frequency/executed operation →consumption of other Paa. S cloud services →impact on the throughput, response time and scalability of the designed application ■ Similar data complexity to use data entities of similar complexity in the model to work with a degree of complexity of the given data entity not with precise description of all attributes. 12

APPLICATION MODEL A. Model Requirements ■ Model extensibility easily added based on specific use-cases of modeled applications ■ Support for modeling of multiple interacting applications →applicable for analysis of impacts of deployment across multiple data centers or studies of micro service architectures ■ Abstracting from the programming language →to easily evaluate performance differences in frameworks that are considered to be used 13

APPLICATION MODEL B. Components of the model ■ Collection of applications with In REST API, the actions can be directly triggered by a URL associated the action In Worker application, every action is conditioned by a trigger which defines condition when the action will be automatically executed →providing mechanism to model ・operations synchronously executed by the client ・asynchronous dependencies often used to increase scalability of software components 14

APPLICATION MODEL B. Components of the model ■ Shared definitions of data entities To ensure that the modeled operations are processing similar amounts of data as in the real implemented application →Data entities can model data exchange between applications ■ Allocated Cloud Resources a set of allocated resources it consumes from execution environment where the application is hosted and can utilize its computing power 15

APPLICATION MODEL C. Maintaining platform abstraction and extensibility ■ To design an adequate level of abstraction easily used across multiple cloud providers easily converted to use difference platform services →The software architect can easily evaluate various services that can be incorporated into the application’s architecture ■ To achieve this high degree of abstraction and extensibility →using multiple levels of class inheritance in different parts of the model 16

APPLICATION MODEL C. Maintaining platform abstraction and extensibility 17

APPLICATION MODEL C. Maintaining platform abstraction and extensibility ■ All resources are inherited from the same parent class Resource ■ Multiple abstract types of resources leads to an abstraction of major types of cloud resources 18

PROTOTYPE GENERATOR A. Process of prototype generation 1. Creation of the model Providing all necessary information required for successful prototype generation 2. Validation of the model To check whether the resource of that name exists and is of a required type To check if all required code generators are present in the system and the application can be generated 3. Resource allocation requiring a connection string plugs-in to resource management of the tool and handles life-cycle management of resources from the same package 19

PROTOTYPE GENERATOR A. Process of prototype generation 4. Code Generation handling every application defined in the model separately Loading its model which includes the type of the application used programming language and defined actions a fully compatible Visual Studio solution which is ready for deployment 5. Application Deployment Deployed to the cloud manually or automatically by our tool (For every combination of application type and cloud provider ) 20

PROTOTYPE GENERATOR A. Process of prototype generation 6. Sample Data Generation all necessary sample data for the application is generated in storage services 7. Prototype benchmarks providing user with a list of URLs to defined actions of the deployed application →the throughput, /response time/the scalability of the application/its individual actions can be evaluated 21

PROTOTYPE GENERATOR B. Architecture of the prototype generator ■ Abstract Application Model ■ Resource Manager ■ Code Generator 22

CASE STUDY ■ To guarantee high scalability and low operation costs of the application hosted in the Paa. S cloud ■ To manually implement a prototype of the application, generate sample data and execute a set of benchmarks ■ To model two versions of the application at the same level of complexity as we did when we implemented the prototype ■ The throughput and scalability metrics measured for the API exposed to the client 23

CASE STUDY A. Designed Application ■ a private social network for elementary schools which should scale to sustain the load of 800000 student in the Czech Republic u handling such a heavy load generated by clients u loaded via REST API hosted in Azure App Service to web client written in HTML 5 and Java. Script u to use relational database (Azure SQL Database) as a primary and the only storage for application data 24

CASE STUDY A. Designed Application ■ asynchronous dependencies ■ sending a request to process this operation to the queue service ■ loading messages from the queue and processes them ■ storing the record in the database and queuing new operation to store new record also to No. SQL database ■ loading the data from highly scalable Azure Table Service 25

CASE STUDY B. Application Model 26

CASE STUDY C. General Prototype u a single Visual Studio solution ASP. NET Web API application/class library with Business Layer (BL)/a class library with Data Access Layer (DAL) ■ Employing Nu. Get packaging framework used to download the required frameworks to generated projects ■ using O/R mapper Entity Framework in the code-first mode 27

CASE STUDY C. General Prototype u a single Resource Group Azure SQL Database/Azure Storage Account/Azure Service Bus Queue/two applications in Azure App Service for hosting of the REST API and for the worker role ■ Nu. Get packages with clients for Azure Storage and Azure Service Bus →used in the DAL to load records from the No. SQL database and store requests to the queue service ■ a second solution with console application which hosts Azure Service Bus client to load messages from the queue because of Message. Received. Trigger 28

CASE STUDY D. Quality Evaluation of the Prototype ■ comparing the scalability of the read operations ■ production version →Fig. 10 →Fig. 9 29

DISCUSSION ■ Realistic results The quality of the hosting environment is fully reflected in the results of the evaluated prototype ■ Current version of the cloud environment to provide new functionality, increase efficiency and mitigate bugs → not having to pay attention to the service updates, 30

DISCUSSION n Simplifications in the model impacting on the throughput, response time and scalability of the service n Simplification of the operations simplified in comparison to all possible options that developers can actually use working with sample data sets n Unrepeatable results providing different and realistic results →mitigated by the automation of test runs →automatically executed in a significant number of repetition n Operation costs Service charges will occur depending on the variety of used Paa. S cloud services, duration of allocation, scale and generated load 31

CONCLUTION ■ a design-time quality evaluation technique for Paa. S applications based on automatically generated application prototypes →deployed to the cloud and assessed in real settings ■ generating prototypes that are taking full advantage of the Paa. S cloud ■ used for evaluation of the used architectural patterns in early design stages ■ focus on the employment of this technique for the evaluation of Paa. S cloud architectural tactics 32